Некорректное формирование цены в накладной в печатной форме

[KpecT]

Всем привет.
Cледующая проблема:
1) Имеется накладная (рис. 1) состоит из 2-х строчекс одной и той же ценой.

Рис.1 Строки накладной

2) Формируем печатную форму накладной (рис. 2)

Рис.2 Формируем печатную форму

3) На печатной форме предстает такая картина (рис. 3). Все как бы корректно, но в цене одной из строчек появилась лишняя копейка.

Рис.3 Печатная форма накладной

Причина появления лишней копейки найдена. Происходит расчет цены в классе SalesPurchReport_RU метод prepareDynamicLine()

...
currentPrice                    = Currency::amount(abs((invoiceTrans.LineAmount
                                                       + salesTaxIncludedInLineAmount
                                                       + markupItemPosted
                                                       + markupExcise) / qty) * exchRate / 100);
...

Теперь вопрос: почему не взять цену прямо из накладной, зачем происходит пересчет цены (Сумма / Количетво) при формировании печатной формы?

[Sada]

А я такова не нашол. Это не модификация случаем?

[sukhanchik]

Причина - проста как 3 копейки. Округление.
Имеем:
1. Цена
2. Сумма без НДС
3. Сумма НДС
4. Сумма с НДС
5. Общая сумма по накладной.

Налоговики в общей своей массе требуют, чтобы соблюдалась формула для каждой строчки:
Цена * Кол-во = Сумма без НДС
ОКРУГЛ(Сумма без НДС * 0,18;2) = Сумма НДС
Сумма с НДС = СУмма без НДС + Сумма НДС

Общая сумма = Сумма всех строк сумм с НДС

При этом, цены, вообще говоря - не всегда задаются пользователями без НДС.
Т.о. по-любом происходит как минимум один раз потеря точности, что выливается в несоответствии на копейку в какой-нибудь сумме (например, Сумма НДС не равна ОКРУГЛ(Сумма без НДС * 0,18;2) или общая сумма не равна сумме строк построчно.
Каждая организация по своему решает проблемы с копейками (т.к. есть еще клиенты - которым могут не нравиться документы). Разработчики Аксапты пожертвовали ценой (т.е. последовали рекомендациям фискальных органов). Отсюда и копейки.

Есть еще нюанс. Если вы продаете товар, который предварительно сами растаможивали - то у вас есть ГТД (актуально, если ГТД является складской аналитикой).
В накладной - ГТД нет, а в счет-фактуре есть. Соответственно, в счет-фактуре происходит "дробление" сумм пропорционально количеству (если продается к примеру 2 позиции с разными ГТД). Дробление естественно не лучшим образом влияет на точность и поэтому лишние копейки тоже куда-нибудь "засовываются".

Соответственно - вам нужно принять решение - либо согласиться со штатным решением округления, либо придумать и реализовать свой (со всеми вытекающими).

[Sada]

Главное чтобы итоговые суммы в накладной и фактуре были правильные. Остальное не критично.

[sukhanchik]

Ну... мне так в свое время говорили бухгалтера. Может что-то конечно и поменялось с тех пор (за 7 лет) - но у бухгалтеров - свои тараканы в голове. В конце концов - аргумент "А у нас налоговая имеет претензии" или "клиент отказывается брать" оказывается весомее. Увы - у нас расплывчатое тут законодательство - и поэтому каждый считает что прав именно он

[KpecT]

Это модификация быстрей всего той фирмы, которая внедряла Аксапту.

Спасибо конечно за подробный ответ.
Ошибку округления я и сам нашел.
Накладная по заказу формируется с правильными ценами это видно на скриншоте. Не понятно зачем заново ведуться расчеты при формировании печатной формы накладной?
Спрашиваю, так как боюсь, что если исправлю класс (я хочу просто взять цену из строк накладных), а он используется еще, где-нибудь где на самом деле используются расчеты цены, то полезут ошибки

[sukhanchik]

Скорее всего - ваших бухгалтеров (или того, кто принимает решения в этой области) не устроил штатный механизм округления. Была сделана модификация "по другому алгоритму". Компания внедренец решила - что проще не лезть в код расчета цены накладной, а залезть в код печати накладной. Дело в том, что в первом случае при изменении алгоритма округления (а как я понимаю - каждый новорит придумать свой, "правильный" алгоритм) пришлось бы (и Вам в том числе) перелопачивать исторические данные. А так - только изменить код.
Кстати - если вы посмотрите стандарт - то при определенных условиях - цена тоже рассчитывается.

Если вы сделаете правку - то вы рискуете вернуться на этап до "изменения" алгоритма округления. Посмотрите - проверьте. Стандартный функционал - он все же более известен - нежели частное решение.

[KpecT]

Хотел узнать, почему плохо брать цену из строк заказа или накладной, и хорошо пересчитывать её каждый раз?

[glibs]

Цена из строк заказа (PurchasePrice/SalesPrice) — это не совсем то, что вы понимаете под термином "цена".

Посмотрите

АОТ\Classes\PriceDisc::calcNetAmount()

[KpecT]

Возникает вопрос, зачем вообще считать Цену отталкиваясь от суммы и количества?

[glibs]

Попробуйте сформулировать вопрос конкретнее.

Если речь идет о том, почему она так считается в печатной форме ТОРГ-12, то иначе она в общем случае посчитаться не может, с учетом описанных выше особенностей.

[KpecT]

Иначе посчитать не может? В смысле сделано так не дальновидно или наоборот дальновидно?
Я не понимаю почему при обработке накладной применяется метод цена * количество = сумма, а при формировании счет-фактуры используют другой метод Цена = Сумма / Количество? Также мне не понятно, что мешает использовать данные из накладной, зачем каждый раз пересчитывать цену (при печатной форме ТОРГ-12, при формировании счет-фактуры)?

[sukhanchik]

Не готов ответить по существу по коду (лазить надо). Но могу высказать предположение - что заполнением данных в таблице накладной занимается международный функционал, а заполнением ТОРГ-12 - российский. Счет-фактура же - чисто российский функционал. Поэтому - при печати с/ф расчет ведется до заполнения таблицы, а данные берутся из таблицы.
А у накладной - буржуйский функционал не трогали (который заполняет таблицу), а расчет делали уже при формировании отчета. Плюс - так удобнее - с т.з. потенциального изменения росс. законодательства. Фикс наложил и не надо править данные.

[Ivanhoe]

Вы забываете, что в СФ строки могут биться по ГТД. Вы забываете, что сумма по строке в заказе может быть введена руками (цена при этом будет высчитана, но из-за округления цена * количество не получится сумма итого). Вы забываете про округление по накладной...

В общем случае в накладной и СФ важна сумма по строке и налог по строке, а не цена.

[sukhanchik]

Цитата:

Сообщение от Ivanhoe

Вы забываете, что в СФ строки могут биться по ГТД. Вы забываете, что сумма по строке в заказе может быть введена руками (цена при этом будет высчитана, но из-за округления цена * количество не получится сумма итого). Вы забываете про округление по накладной...

В общем случае в накладной и СФ важна сумма по строке и налог по строке, а не цена.

2KpecT: Во... слушайте что умные люди говорят

[Raven Melancholic]

Цитата:

Сообщение от Ivanhoe

В общем случае в накладной и СФ важна сумма по строке и налог по строке, а не цена.

На самом деле, законодательно это не регулируется и при прямом прочтении правил ведения книг продаж и покупок вообще складывается впечатление, что главное это соответствие общей облагаемой сумме и суммы налога (возможно в разрезе ставок).
С другой стороны, Ivanhoe правильно заметил, что часто цену в с/ф игнорируют ради равенства по строке. Но есть и исключения - Метро, Ашан, Х5 Retail Group (в лице входящих в неё сетей) требуют равенства по все графам, в том числе, чтобы Цена*Количество четко давала сумму без НДС - если не сходится даже на копейку, могут штрафануть за некорректные документы.
Сомневаюсь, что правила по таким вещам когда-то будут закреплены хотя бы на уровне Минфина, поэтому каждый выкручивается как может. Некоторые даже в настройки клиента выносят правила, по которым нужно эти копейки учитывать в печатных формах.

[Ivanhoe]

Цитата:

Сообщение от Raven Melancholic

... Но есть и исключения - Метро, Ашан, Х5 Retail Group (в лице входящих в неё сетей) требуют равенства по все графам, в том числе, чтобы Цена*Количество четко давала сумму без НДС - если не сходится даже на копейку, могут штрафануть за некорректные документы.

Вот именно, что исключения. На таких исключениях можно и доработку сделать .

На самом деле тут еще от товара зависит. Если говорить про штучный товар, у которого есть нормальная цена - то претензии можно понять.

А вот если говорить, например, о тоннах бензина, при цене за кг или литр в евроцентах при закупке зарубежом, о щебне, о трубах на вес, где зачастую цена за единицу может быть очень маленькая (относительно), а количества - огромные, то подход Аксапты оправдан.