Остатки на дату InventSumDatePhysical

[Raven Melancholic]

Странная ситуация с остатками. Выполнил следующую последовательность действий:
1) Совсем новая номенклатура, по ней сделал закупку
2) По закупке создал отборочную накладную 20.03.2007 на 5 единиц.
3) При помощи поля "Немедленное получение" с минусовым количеством отсторнирвал её тем же числом - все 5 единиц.
4) Создал новую отборочную накладную 21.03.2007 на 5 единиц
5) Создан финансовую накладеную 21.03.2007 на 5 единиц
Я считал, что используя класс InventSumDatePhysical получу на 15.03.2007 остаток равный нулю, но не тут-то было: остаток -5 (минус пять).
Код в принципе простейший:

inventDimParm.initFromInventDim(_inventDim);
inventSumDate   = InventSumDatePhysicalDim::newParameters(_dateSaldo, _inventTable.ItemId, _inventDim, inventDimParm);
tmpQty          = inventSumDate.physicalQuantity();

Ползал отладчиком, в итоге пришел к выводу, что какая-то проблема с соответствием InventTrans и InventTransPosting по физическим разноскам (один ваучер, заданный в поле InventTrans в качестве физического, в таблице разноски идет по строке с финансовой разноской).
Вопрос: сталкивался ли кто-нибудь с подобным поведением? Пока не могу понять копать стандартный функционал или модификации приводят к такому?
Ax 3.0 SP 3 с некоторыми вытяжками из SP 5

[glibs]

А в отчете стандартном (Физ. наличие по складам) такая же картина?

[Raven Melancholic]

Да, та же самая (там же используется класс из той же иерархии).
Вчера просто не было возможности проверить. Сегодня получил доступ к стандартным SP3 и SP5 - на них ошибка не воспроизводится. В нашем приложении в InventTransPosting при сториноровании отборочной накладной по закупке создается на одну запись меньше, чем в стандартном приложении.
Так что сегодня буду искать, что там за 3 года "намодифицировали".

[Raven Melancholic]

Поспешил. Оказывается у меня не чистый SP3. Оказывается, ошибка была до SP4, о чем говорит такой код в методах updateTransPhysicalReturnedReceipt и updateTransPhysicalReturnedIssue класса InventUpd_Physical.

// START: 1947 SP4
inventTrans.voucher= _ledgerVoucher.lastVoucher();
localBuffer.Voucher         = inventTrans.Voucher;
localBuffer.VoucherPhysical = inventTrans.Voucher;
this.postingPhysical(true);
// END:   1947 SP4

Как только накатил это изменение, записи стали корректными. Так что, если кто столкнется с подобной ошибкой, то может мои мытарства помогут. Без этого методы selectInventTransPostingPhysical классов, наследников InventSumDate в случае, если было сторнирование отборочных накладных до создания финансовых, работают некорректно.
Осталось придумать, как исправить существующие записи.

[Lemming]

Raven Melancholic, во первых спасибо за то что подсказали, в чем причина "съехавших" остатков на дату и как пофиксить код.

Цитата:

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

...
Осталось придумать, как исправить существующие записи.

В данный момент я как раз пишу Job, который исправит последствия. Что удалось выяснить(только предположения, в складском контуре я не силен):
1. При создании сторно отборочной накладной в таблице InventTransPosting не создается запись с InventTransPostingType = InventTransPostingType::Physical.
2. Для складской проводки не прописываются DateFinancial, Voucher.

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

Если у кого то есть какие либо мысли по данному вопросу, заранее спасибо за информацию!

[Raven Melancholic]

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

[Lemming]

Спасибо за класс, он окончательно подсказал верное направление!