Расхождение накладной и фактуры на копейку

[EVGL]

Хотел поделиться "решением": бывает так, что при ценах в иностранной валюте (евро, доллар) в накладной образуются "ошибки округления в основной валюте" (рублях). Копейка приходит, по-видимому, из округлений в налогах. Активируется копейка параметром "Максимальное допустимое расхождение". Если параметр не активировать, то накладная попросту не разносится.

Как выяснилось, после разноски все проблемы как раз и начинаются. Следствием копейки является несоответствие суммы по строкам и итоговой суммы накладной. Если теперь по накладной один-в-один сформировать фактуру и печатать обе "в основной валюте", то ее сумма не бьется с суммой накладной как раз на одну копейку, что связано с тем, что фактура формируется как раз не из заголовков, а из отдельных строк накладных.

Бухгалтерия - в шоке: "Как же так, на целую копейку различаются накладная и счет, нам такую отгрузку никто не примет!"

Мое решение: бороться с копейкой на уровне разноски - дело безнадежное. Зато можно сделать так, что накладная и фактура покажут одинаково [неправильную] сумму. Для этого можно обесточить метод в отчете, который пытается раскидать расхождения между суммой строк и заголовком накладных по отдельным строкам. Метод называется \Classes\SalesPurchReport_RU\adjustDynamicData().

После того, как поставить в начале метода Return(); документы становятся идентичными... и печатные формы накладных перестают биться с суммой в их заголовках. Но тут уж работает мое правило "прагматичного бухгалтера": пусть документы будут неверными, зато систематически и последовательно неверными.

[Ivanhoe]

В общем случае вы не решите проблему соответствия сумм по строкам и по столбцам в ТОРГ-12/Фактуре, которые изначально валютные, но печатаются в "основной валюте". И там расхождения уже могут быть не на копейку.

[EVGL]

Безусловно: это еще повезло, что пока на копейку. Могу себе представить, что при должном количестве строк ошибка вырастет.

С учетом того, что фактура поглощает строки накладной без дополнительных преобразований, есть надежда получить моим способом идентичные накладные и фактуры при любых условиях. В конечном итоге эти суммы должны без изменений перекочевать к книгу продаж, поскольку она работает по строкам фактур.

[d&m]

Цитата:

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

После того, как поставить в начале метода Return(); документы становятся идентичными... и печатные формы накладных перестают биться с суммой в их заголовках. Но тут уж работает мое правило "прагматичного бухгалтера": пусть документы будут неверными, зато систематически и последовательно неверными.

в итоге напечатаете для клиента вы одну сумму, а в задолженности (custtrans) сумма будет уже другая (= сумме шапки накладной) - так?

как будете такие задолженности закрывать платежами? в итоге могут остаться висеть эти самые копейки...

[EVGL]

Именно так. В модулях клиентов и поставщиков есть свои пороги сопоставления. Если установить их теми же самыми, что и в ГК (а лучше - чтобы больше), то проводки успешно сопоставятся.

[d&m]

в своё время писал запрос в МС на аналогичную ошибку (сумма при печати в первичной валюте СФ и накладной расходилась).

ответ был следующий:

Цитата:

по результатам исследования было выявлена корневая причина ошибки, связанная с ограничением текущего дизайна. Исправление данной ошибки требует большых изменений кода, которые не могут быть выпущены в рамках запроса на исправление (hotfix). Группой разработки было принято продолжить работу по данному внутреннему запросу (хххх) как запросу по изменению дизайна, которое будет включено в один из выпусков обновлений для AX.

запрос был еще для 4.0, но судя по всему воз и ныне там. инцидент кстати в статусе "Текущее состояние: Closed - Ожидание устранения ошибки", что означает:

Цитата:

так как данное исправление может занять несколько месяцев, я считаю необходимым закрыть данный запрос как "ожидающий решения" с возможностью переоткрытия в течение 12-ти месяцев

12 месяцев естественно уже прошло, ждем-с dax-2012 - может хоть дедлайн перед концом света заставит их исправить старые косяки...

[Alexius]

Цитата:

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

Именно так. В модулях клиентов и поставщиков есть свои пороги сопоставления. Если установить их теми же самыми, что и в ГК (а лучше - чтобы больше), то проводки успешно сопоставятся.

Ага, а потом начинаются очередные разборки с бухами, которым мозолят глаза все эти копеечки в Актах сверки, да ловля глюков в них, уже не копеечных

Class / RCalcExtraCustVendTransaction / processingPennyDifference

...
        select firstonly RecId, AmountMST, AmountCur
            from  localTrans
            where localTrans.Voucher    == custVendTransPostingLog.Voucher   &&
                  localTrans.TransDate  == custVendTransPostingLog.TransDate &&
// Этого условия не хватает для корректного выбора проводки
                  localTrans.TransType  == LedgerTransType::PennyDifference  &&
// ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                  localTrans.AccountNum == custVendTrans.AccountNum;

...

[mnt_dx]

Всем привет.
В 2012 R2 натолкнулся на эту ошибку (уже забыл о такой). Есть ли фикс у МС? Или может можно взять код с более старшей версии?