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

[Poleax]

Модуль Производство\Журналы(все) далее "производственные журналы".
В шапку журналов добавил поле Shift расширенного типа данных(поле Lookup на табличку рабочих смен) в таблицу ProdJournalTable.
Его значение надо разнести в журнал складские проводки (InventTrans), там тоже добавил поле Shift.

читаю Denis Fedotenko: Новые поля в складских проводках
"· В классе inventMovement создадим метод salesResponsible(), возвращающий значение типа emplId. В базовом классе этот метод будет возвращать пустую строку.
· В классе inventMov_sales (связанном со строкой заказа) переопределяем этот метод таким образом, чтобы он возвращал значение salesResponsible из шапки"

и не могу понять. Как выяснили что надо именно в классе inventMov_sales переопределять метод?
Для разностки производственных журналов таблицы ProdJournalTable какой надо класс использовать? InventMov_* ????
А если разностка складских журналов (таблица InventJournalTable) то какой дальше класс использовать? поля для разноски только в шапке журнала.

Мож кто знает где есть большое описание классов и для чего они нужны?

[fed]

Большого описания классов нет по определению А понять какой класс за какой вид складского документа отвечает, можно изучив метод inventMovement::constructNoThrow(). Он на входе получает таблицу, а затем по tableId создает экземпляр нужного наследника от inventMovement.

[Poleax]

fed
Да уж изучить.
Что то я там таблички ProdJournalTable не вижу
есть ProdJournalProd но что это не понятно?

так какие классы InventMov_* использовать для разноски для производственных(ProdJournalTable) и складских (InventJournalTable) журналов ?
Можно по точнее сказать?

[miklenew]

Цитата:

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

Большого описания классов нет по определению А понять какой класс за какой вид складского документа отвечает, можно изучив метод inventMovement::constructNoThrow(). Он на входе получает таблицу, а затем по tableId создает экземпляр нужного наследника от inventMovement.

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

[petr]

To Poleax
Вы плохо знаете функционал а затеваете достаточно сложную модификацию. Для начала советую почитать форум.

По существу.
1. Информационные поля в шапке журнала - значение по-умолчанию для строк (в 99% случаев так должно быть) - поэтому в нет класса InventMov_* для ProdJournalTable, поместите свое поля в строки журнала.
2. Прочитайте про класс InventHook.

[Poleax]

petr
ЧТо на все так сложно и опасно?
Форму читаю не первый день, но ответа на вопроса пока не нашел.

К сожалению по заданию только в шапку журнала добавить поле надо и разнести его в таблицу складские проводки.
Помоги мне с модификацией, а потом посмотрим на сколько она сложная.

[Poleax]

Может все надо сделать как описано в Запись в InventTrans данных и приёмка ???

[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). Фактически - в класс перемещения передаются обе таблицы.

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

[petr]

Цитата:

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

Может все надо сделать как описано в Запись в InventTrans данных и приёмка ???

Это, плюс упомянутая вами статья Дениса. Насчет сложной я неправильно выразился, точнее будет не сложная, а ответственная.

Что мне не понравилось, это то, что вы искали в InventMovement::constructNoThrow() таблицу ProdJouralTable. Это показывает, что вы не до конца понимаете разноску произв. журналов.

Если сказать грубо, то в Аксапте разносятся на шапки журналов, а строки, поэтому если вы хотите добавить новое поле в проводку, то оно должно быть в строке соотв. журнала, или возвращаться методом строки журнала.

[Poleax]

pert
Вот уже лучше..
а кто обьяснить если не вы..

Как я понимаю таблица строк ProdJournalBOM и дальше класс InventMov_ProdLine или InventMov_ProdLine_JournalBOM
в методе initInventTransFromBuffer и присваиваем поле?

про это: "в Аксапте разносятся на шапки журналов, а строки, поэтому если вы хотите добавить новое поле в проводку, то оно должно быть в строке соотв. журнала, или возвращаться методом строки журнала."
подробнее почитать как и что за чем и по порядку происходит в процессе разноски?

[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...

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