Маркировка заказа на перемещение

[plumbum]

Вот разбираюсь с маркировками, и возник вопросик:

на строке заказа или производственном заказе или строке закупки есть 3 замечательных поля, указывающих на кореспондирующую строку (ну с которой этот, например, заказ смаркирован, будь то производственный заказ или закупка). Соответственно эти же поля заполнены в приходной строке (закупка, производство):

SalesLine.InventRefTransId
SalesLine.InventRefId
SalesLine.InventRefType

PurchLine.InventRefTransId
PurchLine.InventRefId
PurchLine.ItemRefType

соответственно в классе-наследнике InventMovement в методе inventRefTransId будет возвращена реальная ссылка на смаркированную строку.

Так вот, к моему удивлению, при том что заказ можно смаркировать с переносом, этих полей в строке переноса нет!

Постановка задачи следующая: при приходе на склад любого типа (закупка, перенос, возврат) определить, есть ли смаркированная строка заказа (заказа клиента, заказа на перенос) с этого склада и в зависимости от этого выполнить другое действие, а именно Cross Docking.

Не хочеться вылавливать эти связи из складских проводок, было бы намного удобнее иметь эти поля на InentTransferLine

Заранее спасибо за ответ!

[Maxim Gorbunov]

Цитата:

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

Постановка задачи следующая: при приходе на склад любого типа (закупка, перенос, возврат) определить, есть ли смаркированная строка заказа (заказа клиента, заказа на перенос) с этого склада и в зависимости от этого выполнить другое действие, а именно Cross Docking.

А что делать, если приход смаркирован сразу на несколько заказов?

Цитата:

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

Заранее спасибо за ответ!

Пожалуйста. А в чём был вопрос?

[plumbum]

Цитата:

Сообщение от Maxim Gorbunov

А что делать, если приход смаркирован сразу на несколько заказов?

Такого случая не будет, на административном уровне запрещено

Цитата:

Сообщение от Maxim Gorbunov

Пожалуйста. А в чём был вопрос?

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

[glibs]

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

Что касается переносов, то все зависит от версии. В 5.0 на заказ на перемещение выделяется 4 лота. В ранних версиях на лотах экономили, и насколько я помню, с маркировкой было проблематично.

[Maxim Gorbunov]

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

Ну а чем ваши собственные поля могут помешать Аксапте, я не знаю. Вы ведь логику под них переписывать не собираетесь. Они в большей степени просто информационные будут. Так что, не думаю, что это чему-то может сильно помешать. В целом, модификация, вроде бы, совсем не сложная.

[Raven Melancholic]

Цитата:

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

Так вот, к моему удивлению, при том что заказ можно смаркировать с переносом, этих полей в строке переноса нет!

В заказе на продажу, на покупку, производственном заказе, строках производственного заказа эти поля служат не только для маркировки, но и для связей между документами, созданными один из другого. Например, при помощи функций "Создать заказ на покупку", "Создать заказ на запуск в производство" и ваш Cross Docking (в терминах Аксы - Прямая поставка) и т.п. В переносах таких функций нет, вот и нет прямой связи, только через проводки.
Использую маркировки следует помнить, что на маркировки навешаны одновременно как логистическая функция (связь приходов с расходами), но и финансовая (расчет себестоимости). Если их использовать активно в логистических целях, то результат может не очень понравиться финансистам.

[plumbum]

Цитата:

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

Использую маркировки следует помнить, что на маркировки навешаны одновременно как логистическая функция (связь приходов с расходами), но и финансовая (расчет себестоимости). Если их использовать активно в логистических целях, то результат может не очень понравиться финансистам.

Если ограничить на данный момент Cross Docking следующими опциями:
Приход: Закупка - Расход: Заказ на перемещение
Приход: Заказ на перемещение - Расход: Заказ клиента

...заказ на перемещение не влияет на себестоимость (пресловутая галочка из 2012 "Non financial transfer")
Производства нет.
Создания закупки из заказа пока не рассматривается.

Где могут крыться подводные камни при закрытии? Модель - средневзвешенная на дату.

[Raven Melancholic]

То что заказ на перемещение не делает проводок не значит, что он не участвует в закрытии склада.
Если в него добавить поля InventRef* (причем, вам они нужны будут с обоих сторон) и добавить соответствующие методы в наследников InventMovement, то проводки будут смаркированы автоматом. В результате, приход по закупке бедет смаркирован с расходом по перемещению, а расход по заказу на продажу с приходом по перемещению. При закрытии склада эти смаркированные проводки будут выключены из расчета себестоимости по модели. То есть, себестоимость расхода по перемещению будут точно по себестоимости закупки, затем эта себестоимость будет переброшена через транзитный склад на сторону прихода и она же будет использоваться при расходе по заказу на продажу.
В вашем конкретном случае, я бы не стал завязываться на эти поля. Тем более, как написано в одном из постов сама функциональность прямых поставок ваша собственная. Это конечно, только мое мнение, но в данном случае, я бы сделал свою связку между документами.

[plumbum]

Закупки/Переносы будут созданны исходя из потребностей (что-то вроде Master Planing), но собственного посола

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

Собственно интересно было обсудить, почему сэкономили на заказе на перенос
Ведь есть же спланированные заказы на перенос уже в 4.0!

[plumbum]

Спасибо!
Вообще идея использования этих полей заключалась в универсальности.
Прямой цепи: Закупка - Заказ на перемещение - Заказ на продажу не будет 100%. Тоесть, после того, как закупка пришла на центральный склад, она будет отгружен по заказу на перемещение в один из магазинов, но без связи с заказом на продажу.

Цитата:

функциональность прямых поставок ваша собственная

Да, вы писали это, но, как я уже сказал, такой связи пока не предусмотрено. Собственно проблема, как я понял, возникает, если смаркированные приход и расход лежат в разных периодах, так?

Цитата:

Если в него добавить поля InventRef* (причем, вам они нужны будут с обоих сторон) и добавить соответствующие методы в наследников InventMovement, то проводки будут смаркированы автоматом.

это то и прельщает, так как сразу появиться статус "зарезервировано в заказанных" в расходной проводке плюс приходованное количество "стырить" не удасться.