Добавления поля для разноски в производственном журнале.

[fed]

Цитата:

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

fed, а можно спросить, может разбирался последний параметр в этом методе childBuffer он для чего.
static InventMovement constructNoThrow(Common buffer,boolean transferReceipt = false,Common childBuffer = NULL)
Чё-то полез смотреть, он практически нигде не используется, а там где используется не разрушив мозг я не смог понять что это.
Мысль была похоже красивая какая-то, но смысла так и не понял.
Спасибо.

Я до конца тоже не разбирался. Общая идея такая: В некоторых случаях, складское движение собирается ИЗ ДВУХ таблиц. Конкретнее - списание в производство собирается из спецификации производственного заказа (ProdBOM) и из собственно строк журнала отгрузочных накладных (ProdJournalBOM; Приемка из производства складывается из производственного заказа (ProdTable) и строк журнала приемки (ProdJournalBOM); Отгрузка по заказу или заказу на перенос из самого заказа (salesLine или InventTransferLine) и строк отгрузочной накладной (inventPickingListJournalLine). При этом, фактически 90% данных для движения берется из родительской таблицы (такой как строки заказа или спецификации ПЗ) и только 10% - из дочерней таблицы (типа строк журнала отгрузочных накладных). Вот для таких ситуаций и предназначен механизм дочерней таблицы (childBuffer). Фактически - в класс перемещения передаются обе таблицы.

По понятным причинам, подход жизнеспособен и применим только в тех видах складских движений, в которых допустимо частичное движение. Если мы все складское движение делаем сразу на полное количество - подход не сработает.

[miklenew]

Спасибо fed.
Помогло ключевое слово “дочерние”. Теперь мозги встали на место.
Если взять к примеру заказ.
Смысл параметр childbuffer имеет только если включена регистрация отгрузочной накладной.
При обычной разноске документа по строке сначала изменяется строка, изменение строки приводит к изменению проводок. А документ создаётся как бы рехешем(тавар вдогонку), непосредственно никак не влияя на проводки.
С salesPickingLisJournalLine дело обстоит по другому. При создании отгрузочной накладной (если включена регистрация. Если не включена, то всё происходит как с обычным документом по строке заказа) не происходит изменение строки и проводки. Просто происходит рождение шариков в буферной зоне salesPickingLisJournalLine при этом в строках документа и в проводках осталось всё по прежнему и только при регистрации отгрузочной накладной эти шарики перетекая начинают влиять на строку заказа изменяя проводки.
Поэтому и нужно главный буфер (salesLine) и дочерний буфер (salesPickingLisJournalLine), чтобы слепить эти шарики вместе, и получить другие шарики.

[ZVV]

Цитата:

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

При создании отгрузочной накладной (если включена регистрация. Если не включена, то всё происходит как с обычным документом по строке заказа) не происходит изменение строки и проводки.

А вот и не правильно!

Проводки меняются, там прописываются поля TransChildType и TransChildRefId.
И в случае когда эти поля прописаны, работать с этим "мувментом" можно только с использованием "ChildBuffer".
Резервировать, например - не зря ж там в классах InventUpdate везде условия "понатыканы" типа:

                      inventTrans.TransChildType        == movement.transChildType()   &&
                      inventTrans.TransChildRefId       == movement.transChildRefId()  &&

По этому, если отталкиваться от InventTrans, то если по движению есть childBuffer, то и "мувмент" надо брать с его использованием, если нет, то не надо. Примерно так:

movement = InventMovement::construct(inventTrans);
            if (movement.childBuffer().RecId)
            {
                buffer = movement.childBuffer();
                movement = InventMovement::construct(buffer);
            }

Ну и дальше его уже передавать в InventUpdate...

Сорри что старую тему поднял, просто случайно наткнулся...