DAX4 Интеркомпани, ошибка разноски внутрихолдинговой накладной

[Raven Melancholic]

Ошибка проявляется в именно так, как описал JeS.
Ой, насчет:

Цитата:

Кроется она в классе IntercompanyTransferInventDim метод transfer

К сожалению это не одна ошибка в этом методе (даже если отбросить тот факт, что про ГТД в этом методе ничего нет).
Он неправильно отрабатывает в случаях, когда были кредит-ноты по строке, лечилось добавлением в выборки (те, которые зависят от того, какие аналитики включены) условий (то, что выделено комментариями):

select forceplaceholders sum(Qty) from fromInventTrans
     where fromInventTrans.InventTransId == _fromInventTransId
          &&    fromInventTrans.StatusIssue   <= _statusIssue
          &&    fromInventTrans.StatusReceipt == StatusReceipt::None
// ААК: МФД40_09_01_0013_001 11.07.2009 [Сторнирование и копирование документов] -->
          &&    fromInventTrans.InvoiceReturned        == NoYes::No
          &&    fromInventTrans.PackingSlipReturned    == NoYes::No
// ААК: МФД40_09_01_0013_001 11.07.2009 [Сторнирование и копирование документов] <--
          join InventLocationId, InventBatchId, InventSerialId, InventGtdId_RU  from fromInventDim
               group by InventLocationId, InventBatchId, InventSerialId, InventGtdId_RU
               where fromInventDim.InventDimId == fromInventTrans.InventDimId;

Одна трудно уловимая ошибка связана со вторым проходом метода, то есть тогда, когда вызван с параметром _registerReceipt равном true. При определении того, какие проводки связанной закупки уже отработаны, метод ориентируется на поле InterCompanyInventDimTransferred. В отработанных проводках он проставляет в это поле true и больше к ним не обращается. Но, когда вызывается регистрация InventTransWMS_Register, то естественно, процедура регистрации ничего не знает про это поле и регистрирует любую запись в InventTrans (естественно, с учетом аналитик), если их по лоту несколько. В результате получаем ситуацию, что признак обработки поставили в одной записи, а зарегистрированы другие. Соответственно на следующем проходе выборка:

select forupdate toInventTrans
     index hint TransIdIdx
     where toInventTrans.InventTransId                    == _toInventTransId
          &&    toInventTrans.StatusReceipt                    == StatusReceipt::Ordered
          &&    toInventTrans.StatusIssue                      == StatusIssue::None
          &&    toInventTrans.InterCompanyInventDimTransferred == false;

может ничего не найти.
Для воспроизведения этой ошибки нужно чтобы проводки по лоту были расщеплены как со стороны заказа на продажу, так и со стороны заказа на покупку. Причем, иногда везет и комплектуются те записи, по которым установили флаг, но везение не всегда случается. Эту проблему решили, но грубо (стояли отгрузки, поэтому было не до изящности):
вместо

inventTransUpd.InterCompanyInventDimTransferred = true;

поставили:

//lex 24.04.2009 при регистрации могла выбраться еще необработанная проводка и на пересечении...-->
if (!_registerReceipt)
{
      inventTransUpd.InterCompanyInventDimTransferred = true;
}
//lex 24.04.2009 при регистрации могла выбраться еще необработанная проводка и на пересечении...<--

А саму установку флага делаем после регистрации:

//lex 24.04.2009 при регистрации могла выбраться еще необработанная проводка и на пересечении...-->
update_recordset refInventTrans
     setting InterCompanyInventDimTransferred = true
     where refInventTrans.InventTransId      == inventTransUpd.InventTransId
          && refInventTrans.StatusReceipt == StatusReceipt::Registered
          && !refInventTrans.InterCompanyInventDimTransferred;
//lex 24.04.2009 при регистрации могла выбраться еще необработанная проводка и на пересечении...<--

[Raven Melancholic]

Еще один недостаток этого метода. Бывает, что в компании, в которой производится продажа конечному клиенту, требуются данные не только номера партии, а и то, что есть в таблице партий (например, дата производства, если существует контроль и предоставление клиенту информации о сроках годности), тоже может требоваться по серийным номерам и, естественно, нужна страна по ГТД. Однако, в методе создаются записи только с номером:

if (!InventBatch::exist(toInventTrans.ItemId,inventDimUpd.InventBatchId))
{
     inventBatch.clear();
     inventBatch.ItemId          = toInventTrans.ItemId;
     inventBatch.InventBatchId   = inventDimUpd.InventBatchId;
     inventBatch.insert();
}

Пришлось допиливать: в исходной компании запоминать данные из соотвествующих таблиц:

while (fromInventTrans)
{
     // ААК: МФД40_08_01_0003 19.03.2009 [Планирование сделок] -->
     inventBatchFrom     = null;
     if (fromInventDim.inventBatchId)
     {
          inventBatchFrom     = InventBatch::find(fromInventDim.inventBatchId, itemIdFrom);
     }
     ...

А создание в компании-продавце добавлять:

if (!InventBatch::exist(toInventTrans.ItemId,inventDimUpd.InventBatchId))
{
     inventBatch.clear();
     inventBatch.ItemId          = toInventTrans.ItemId;
     inventBatch.InventBatchId   = inventDimUpd.InventBatchId;
     // ААК: МФД40_08_01_0003 19.03.2009 [Планирование сделок] -->
     inventBatch.initFromInventBatch_OVK(inventBatchFrom);
     // ААК: МФД40_08_01_0003 19.03.2009 [Планирование сделок] <--
     inventBatch.insert();
}

В общем, вещи достаточно нужные, но почему-то нереализованные. А рука локализаторов вообще не касалась этого механизма. Помимо того, что в описываемом методе пришлось добавлять синхронизацию по ГТД, еще самостоятельно реализовывали настройки синхронизации росийских форматов адресов и использование этих настроек в методах InterCompanyMirror классов SalesTableType, SalesLineType и их же по закупкам, включая классы Ax*