Добрый день!
Во вложении подробно изложила суть вопроса. Кратко изъяснюсь в тексте.
С покупателем спецификация и расчет в у. е.
Покупатель оплатил предоплату, мы выписали авансовый счет-фактуру, и при реализации товаров программа пересчет юаней в рубли проводит криво, т. е. в авансовом счете-фактуре по позиции № 1 НДС составил 10,25 руб., а при реализации программа округляет и ставит 10,26, как следствие счет-фактура на отгрузку в части НДС будет неверная, из-за чего возникнет разрыв в НДС.
Подскажите, как действовать в этом случае? Почему программа так считает? У нас массово проходят такие операции, и что теперь, постоянно так все выверять и корректировать? И правильно ли мы откорректировали, может, есть иные пути?
Все комментарии (7)
Комментарии закрыты.
Добрый день!
Спасибо большое за подробные скрины.
Насколько поняла, проблема в округлении на копейку по некоторым позициям. Всегда с контрагентом по предоплате работаете? Если ОСВ 62 по нему сформировать с полной аналитикой до документов расчетов, корректно все закрывается, каждая отгрузка к своей оплате? Это из возможного, почему курс не тот может тянуться.
Еще приложите скрин, пожалуйста, счета покупателю, какая цена за единицу товара, чтобы я аналогичный пример смоделировала.
Да, с контрагентом всегда по предоплате. Да, каждая отгрузка по ОСВ закрывается четко, так как общая сумма по АВ СФ и УПД сходятся, не сходится только сумма НДС и плавает сумма без НДС из-за этого, то на то и выходит, что общая сумма сходится.
Счет во вложении.
Спасибо за скрины.
Да, подтверждаю такое поведение программы. В части НДС 1С считает каждую строку отдельно, там же и округляет. Т.е. 1955,46 если отдельно каждую строку пересчитывать по курсу и складывать, 1955,44 если считать от общей суммы реализации по ставке.
Насколько знаю, такая проблема у пользователей уже давно.
А еще подскажите, при выписке авансовой счет-фактуры табличная часть заполняется у вас как по счету? Здесь ничего руками не правите?
У меня при моделировании вот такая ситуация с корректировкой (скрин).
По регистру «Раздельный учет НДС» нужно проверить или по поступлению, или универсальным отчетом (скрин), какие суммы на приход были, в той же сумме движение на расход должно быть, по идее, исправлять не нужно.
При выписке авансового счет-фактуры бывает возникает подобная картина с 0,01 копейкой, правила до этого, но теперь сразу для меня знак, что надо проверить все. По универсальному отчету посмотрю, я правильно поняла, это как раз про мой вопрос, что править во владке по раздельному учету?
Да, по универсальному отчету сверьте, если суммы приход-расход одинаковые, править не нужно.
По 0,01 коп. поняла, и по поводу непонятных округлений посоветуемся с программистом, как «внутри» программа считает, откуда что тянет и что можно с этим сделать.
По результату вам сообщим🌸🌸🌸
Спасибо, очень буду ждать
Юлия, добрый день!
Спасибо за ожидание.
Пришел ответ от нашего программиста. Да, это типовой механизм программы по округлению.
На цифрах: 392,50 всего с НДС, отсюда НДС = 65,4166666667, а не 65,42 ровно из-за того, что в денежных знаках ТОЛЬКО ДВА знака после запятой, она округляет, но это некорректное значение НДС 65,42. Если пойдем дальше, то исходя из этих данных обратный отсчет не даст корректную цену, поэтому округленный НДС, округленная сумма без НДС = 327,0833333333, а не 327,08, и всё это не дает в итоге получить нужную сумму в колонке «ВСЕГО» в рублях, то есть если поставить 4512,58 в 4-й строчке, то сумма будет больше, и программа ее корректирует на копейку, чтобы выйти по итогам в корректное значение.
Приведенная спецификация не будет корректно работать, элементарная проверка: если поставить цену для товара 19,62, это даст сумму 117,72, цена 19,63 — сумму 117,78.
Удобнее смотреть именно по НДС сверху, тогда не ошибешься, иначе программа, конечно, при НДС в сумме округлит, но будут ошибки в проводках, потому что программе ставят неразрешимую задачу: и округлить, и выйти при округлении в общую корректную сумму. Она сверяется с конечной суммой и если из-за округлений не попадает в нее, сама докидывает или снимает копейки так, чтобы итог бился.
Как я ранее писала, это повсеместная проблема и достаточно давно тянется.
Здесь варианты решения проблемы: или подбирать такие цены, чтобы погрешности не было, или дорабатывать с помощью программиста, в цене указывать не 2 знака после запятой, а десять, чтобы не корректировать вручную. Но там тоже нужно будет проверять, не будет ли ошибок при проверке в ФНС, т. к. там как раз по двум знакам после запятой округление идет.