Обещанное продолжение: если под одним номером ГТД и номером инвойса проходит несколько проводок InventTrans, а разноска идет на себестоимость, то рано или поздно при попытке разноски ГТД произойдет ошибка, связанная с округлением. Такая ситуация неминуемо возникнет, если идет учет по палетам или серийным номерам.
Опять-таки, я получил это на первой же наипростейшей реальной ГТД, состоящей из одной строки инвойса.
Программист метода
\Classes\CustomJournalGTDPostImport_RU\createInventAdjust наивно поставил throw error на случай, если ему не удалось до конца распределить сумму ГТД на проводки. При этом он совершил ряд логических и технических ошибок:
в строке 81 встречается пассаж
X++:
if (remainAdjustNow <= Currency::find(customCurrencyCode).RoundOffAmount)
{
adjustNow += remainAdjustNow;
remainAdjustNow = 0;
} в котором идет попытка скомпенсировать ошибку округления. При этом customCurrencyCode - это не что иное, как рубли, причем всегда. Проверяется параметр на валюте "рубль", который обычно на проекте выставляют в копейку. Легко понять, что эта проверка в описанной ситуации практически не работает.
Паллиативное решение заключается в том, чтобы поменять проверку на
X++:
if (remainAdjustNow <= LedgerParameters::find().MaxRoundingDifferenceMST)
которая будет срабатывать гораздо чаще.
Более элегантным решением было бы компенсировать ошибку округления на каждом шаге цикла или попросту закинуть ошибку округления на последнюю проводку, благо нормальные люди обычно не считают себестоимость на уровне палет или серийных номеров, и пропорция распределения коррекции себестоимости между отдельными проводками не играет роли.
Сам цикл, в котором идет поиск InventTrans для распределения, тоже неверен, поскольку не проверяется InvoiceReturned да и вообще знак проводки. Если в инвойс замешалась строка со сторно, жди очень интересных эффектов.