Добавочные проводки по накладной на Заказ клиента

[Ингар]

Проблема следующая - жизненная необходимость заставляет формировать дополнительные проводки при разноске накладной по Заказу клиента.

Все было бы красиво и хорошо, если бы проводки которые были добавлены к voucher там бы и остались.
А именно - при разноске накладной добавляется пара проводок которая повязывается между собой бондом.
Но видимо в дальнейшем эта пара проводок для заказа пересматривается, так как в документе ГК по заказу этих проводок нет, но есть их следы (различная аналитика на дебетовой и кредитовой проводках).
Аналогичная схема доп.проводок примененная на Закупке привела к 100% успеху.
Вопрос - кто-то с таким сталкивался? А то Axapta уже пожрала мой моск, пока я пытался обозначить проблемное место...
Используется 3.0 SP3

[TasmanianDevil]

Вопрос - что за проводки ? По какой части закупки они образуются - по списанию номенклатуры со склада, по задолженности клиента, по налогам ?
Где вы делали их добавление ?

После ответа на эти вопросы будет яснее , где что и как ...

[Ингар]

Цитата:

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

Вопрос - что за проводки ? По какой части закупки они образуются - по списанию номенклатуры со склада, по задолженности клиента, по налогам ?
Где вы делали их добавление ?

После ответа на эти вопросы будет яснее , где что и как ...

Проводки
По списанию номенклатуры
Отражают внутрихолдинговые затраты (счет-в-счет с разной аналитикой)
Добавление - updateLedgerPhysical класса InventMovent
с условием mustBeBookedPhysicallyIntercompany(новодобавленное) для класса InvMov_Sales
Два раза _ledgerVoucher.addTrans с соответсвующими параметрами и суммами
Сразу после этого - подвязка бондом.

И что, собака, характерно, при обработке по addTrans проходит - как дети в школу. Счета правильные, аналитика - как должна быть, а в результате проводок нет и только и видно что разная аналитика в проводках по 36 и 73...

[TasmanianDevil]

1) InventMovement и его разноску трогать - IMHO, слишком грубо, там только то, что является общим для ВСЕХ типов движения номенклатуры. Мы поначалу тоже туда полезли, но вовремя спохватились и перенесли в переопределенные у соотвествующих потомков методы.
2) Все корректно выполнено с добавкой проводки? ledgerBondClient'у добавили новый объект (методом addNewLogObject), потом добавили проводку (2 записи), потом ledgerBondClient'ом скорреспондировали и очистили лог ledgerBondClient'а ?

P.S. про протоколирование разноски движения номенклатуры в InventTransPosting не забудьте В противном случае в момент пересчета/закрытия склада Вы по счетам второй проводки можете суммовой дисбаланс получить.

[Ингар]

Цитата:

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

1) InventMovement и его разноску трогать - IMHO, слишком грубо, там только то, что является общим для ВСЕХ типов движения номенклатуры. Мы поначалу тоже туда полезли, но вовремя спохватились и перенесли в переопределенные у соотвествующих потомков методы.
2) Все корректно выполнено с добавкой проводки? ledgerBondClient'у добавили новый объект (методом addNewLogObject), потом добавили проводку (2 записи), потом ledgerBondClient'ом скорреспондировали и очистили лог ledgerBondClient'а ?

P.S. про протоколирование разноски движения номенклатуры в InventTransPosting не забудьте В противном случае в момент пересчета/закрытия склада Вы по счетам второй проводки можете суммовой дисбаланс получить.

Странно, но может просто у меня сложилось такое впечатление, для движения мы на классе определяем какая разноска у нас должна сработать для нашего журнала, а сам процесс разноски производится в родительском.
Или вы перегружали метод и сначала super(), а потом уже свои модификации? Хм.. Так действительно долно получится элегантнее.

Хм... ledgerBondClient - проверю вечерком. Определенно - там сделал не так. Вяжемся на существующий и связываю две последние добавленные. Спасибо.

[TasmanianDevil]

Поглядите в стандартной части насчет ledgerBondClient'а, как там корреспондируются проводки в ГК после каждой пары вызовов _ledgerVoucher.addTrans().
А насчет места размещения разноски - смотрите, Ваше дело. Просто вызов Вашего метода mustBeBookedPhysicallyIntercompany() для проверки, насколько я понимаю, находится в методе разноски у родительского класса и будет выполняться у всех потомков, не имеющих переопределения этого метода разноски.

[Ингар]

Цитата:

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

Поглядите в стандартной части насчет ledgerBondClient'а, как там корреспондируются проводки в ГК после каждой пары вызовов _ledgerVoucher.addTrans().
А насчет места размещения разноски - смотрите, Ваше дело. Просто вызов Вашего метода mustBeBookedPhysicallyIntercompany() для проверки, насколько я понимаю, находится в методе разноски у родительского класса и будет выполняться у всех потомков, не имеющих переопределения этого метода разноски.

Уже посмотрел и собезьяничал. Заодно поправил в других таких же своих кусках. Спасибо.

Да. В методе разноски. Но он определен в родителе и для родителя и всех его потомков он по умолчанию - false. В потомках для которых необходимо произвести данный вид разноски он "перегружен" и возвращает true.
Таким образом мне для того что бы добавить такую же разноску по еще одному журналу достаточно для класса журнала "взвести" этот признак.