Как сделать такую связь?

[miklenew]

Есть такая задача.
Есть строка заказ(склад 1). Количества на складе 1 нет.
Под заказ создаётся журнал переноса. (склад2 -> склад 1)
Журнал резервируется.
Далее резервируем строку заказа , через InventUpd_Reservation::updateReserveLot(строка заказа, строка журнала).
Но вот вопрос. Связи не остаётся после этого.
И как консультанту тестить. Можно же запутаться. Че куда и от куда. Может вообще зарезервировалось в заказе не с его журнала.
Может есть у кого какие мысли, как можно сделать чтоб сохранялась связь строки заказа со строкой журнала переноса.
Может можно использовать для этого InventRefTransId?

[lev]

В проводках (InventTrans) есть два поля TransChildType - складская ссылка, и TransChildRefId - складской идентификатор. TransChildType это енум, в нем есть и пункт "Складской журнал". Может это подойдет?

[npokypatop]

Гм... если использовать поля *child*, перед разноской их придется очищать...
А какая связь нужна - строка заказа и строка журнала, или достаточно связать журнал и заказ? Если второе, то лучше поле в шапку журнала выносить. В противном случае - придется свое поле со ссылкой на inventtransid заказа в строке журнала (или проводке) делать

[raz]

Цитата:

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

Может можно использовать для этого InventRefTransId?

Можно и нужно. Так работает маркировка. Пользуясь мониторингом можно видеть движение.
Есть одно но, себестоимость будет идти по маркированной цепочке.

[kashperuk]

Я почему-то был уверен, что когда строка резервируется в заказанных, она маркируется с этим самым заказом/переносом.
Получается, что это не так/не работает?

[raz]

Цитата:

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

Я почему-то был уверен, что когда строка резервируется в заказанных, она маркируется с этим самым заказом/переносом.
Получается, что это не так/не работает?

Я тоже так думал. Проверять лень. Возможно у автора топика модифицировано приложение.

[miklenew]

Цитата:

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

В проводках (InventTrans) есть два поля TransChildType - складская ссылка, и TransChildRefId - складской идентификатор. TransChildType это енум, в нем есть и пункт "Складской журнал". Может это подойдет?

Нет, ссылка нужна на лот.

[miklenew]

Цитата:

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

Можно и нужно. Так работает маркировка. Пользуясь мониторингом можно видеть движение.
Есть одно но, себестоимость будет идти по маркированной цепочке.

Да, это поле мне не подайдёт.

[miklenew]

Цитата:

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

Я почему-то был уверен, что когда строка резервируется в заказанных, она маркируется с этим самым заказом/переносом.
Получается, что это не так/не работает?

Нет, не маркируется. Приложение не причём в стандарте также.

[miklenew]

Ладно хорошего варианта похоже нет.
Щас возник более сложный вопрос.
При ручном в форме(или кодом) удаления резервирования с лота.
Система идёт в метод InventUpdate.updateReserveAgain.
Находит первую попавшуюся открытую проводку зарезервированную в заказных не равной нашему лоту и уменьшает его резерв на нашу величину и забирает наше количество себе.
Т.е. есть лот1 - количество 10(зарезервировали физически)
Есть лот 2 - количество 60(зарезервировано в заказных).
В результате после разрезервирования(10).
Первый лот прийдёт в то состояние в которое нужно.
А из второй разделиться на 50(зарезервированно в заказанных) и 10(зарезервировано в заказанных).
Как ни ломал голову логику так и не понял.
Может кто просветит, что за мысль здесь была или есть.
Метод updateReserveAgain вызывается если какая нибудь аналитика при резервировании подбирается.
У нас это ГТД. Т.е. сделали строку журнала без ГТД. При резервировании система может найти остаток с ГТД.
А при откате(разрезервировании) ГТД в проводке снова исчезнет.

[Wamr]

Миш, обрати внимание, что это происходит при смене аналитики ПРИХОДНОЙ проводки.
Логика такая: при смене аналитики приходной проводки ищутся расходные проводки, которые зарезервированы (в заказаном) на исходной аналитике и они переводятся на новую аналитику прихода... тянутся за ней хвостом, так сказать.

[miklenew]

Вась, спасибо большое.
Теперь понял.
При разрезервировании меняется сначала аналитика в расходной проводке, она тащит за собой приходную. А то в свою очередь этот эфект.
Если я правильно понял мысль была такая, что пока приходная проводка находилась в статусе заказано, с неё мог кто-то зарезервироваться.
И таким макаром просто страхуются. Лучше меньше, чем резерв какой-нибудь потом сняться не сможет.
А так ведь можно играться этой ситуацией до тех пор пока приходный InventDimId c которого меняется приходная проводка совсем не разрезервируется и не повиснет на другой аналитике.
У меня уже так получалось.
Маленькая так сказать багофича.
Прийдёться наследник от класса InventUpd_Reservation делать для импорта.
Хотя ещё более правильно будет прям сюда вписать проверку
Если количество по этой аналитике в статусе заказано после списания нашего количества всё ещё будет больше количества зарезервированного в заказанных, то и не фиг париться.