Смена Inventory Dimensions в Intercompany Orders

[Falcon]

Прежде всего - прошу прощения за иноязычные названия, я просто не знаю, как они называются в локализованной версии. Хотелось бы услышать советы людей, имеющий опыт с Intercompany Orders.

Короче говоря, есть заказ на покупку в одной компании, заказ на продажу в ней же и заказ на продажу в другой компании. Классический IntercompanyOrder, где одна компания в рамках холдинга продает товар, который физически находится в другой компании. В AX 2012 R2 строка заказа на покупку и на продажу в рамках одной компании связаны через Marking. Допустим, потребовалось прогнать это все через склад, отличный от того, что был указан изначально в этих строках. Чтобы сменить склад на строке заказа покупки/продажи, связанной через marking - нужно сначала убрать этот самый marking. Но это невозможно, т.к. заказ - intercompany.

И как быть в этом случае? Ситуация ж вроде вполне рабочая. Не понимаю, почему Аксапта ее не обрабатывает корректно.

[Raven Melancholic]

Не знаю, сильно ли изменился в DAX2012 этот механизм по сравнению с DAX2009, но если в общем остался, то в сообщении описывается не просто внутрихолдинг InterCompany, а сочетание InterCompany и прямой поставки (DirectDelivery).
Внутрихолдинг. Автоматическая разноска накладных не работает
Изменить аналитики нельзя именно из-за прямой поставки, независимо от того, есть ли внутрихолдинг. То есть, при прямой поставки считается, что конечный клиент забирает товар непосредственно у нашего поставщика (внешнего по отношению к нам или наше же юрлицо из другой компании DAX). Видимо, в MS считается, что при прямой поставке каких-то физических перемещений между складами не осуществляется (в принципе, вполне логичное предположений) .

[sukhanchik]

Zitat:

Zitat von Falcon

Ситуация ж вроде вполне рабочая. Не понимаю, почему Аксапта ее не обрабатывает корректно.

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

[Raven Melancholic]

Zitat:

При прямой поставке я понимаю, почему нельзя менять склад. Но в данном случае - это обычная внутрихолдинговая покупка-продажа. И - все равно, поменять не дает без отмены marking, а marking не отменить, потому что intercompany.

Значит что-то изменилось в DAX2012. Раньше маркировка на уровне строк документов (movement) не зависели от того InterCompany это или нет (за исключением прямой поставки). Такая маркировка использовалась в трех случаях:

• Уже упоминаемой прямой поставке.
• При создании заказа на покупку из заказа на продажу (независимо от того, получался ли при этом обычный заказ на покупку или внутрихолдинговый).
• При маркировке вручную если маркировалось 100% количества потребителя (в нашем случае, заказа на продажу) на 100% источника покрытия потребности (в нашем случае заказа на покупку пусть и внутрихолдингового) и при этом в параметрах был включен определенный флаг.

Когда есть связь на уровне строки документа изменить аналитики с признаком финансового склада нельзя (и это в DAX2009 не зависит от intercomapny). Если нет связи на уровне строки документа, то вполне возможна маркировка на уровне складских операций. Но маркировки в DAX2009 (и ранее) что на уровне строк что на уровне складских проводок работают только при совпадении аналитик финансового склада потребителя и источника. Если сменить в складских операциях такую аналитику, то маркировка убивается.

Zitat:

Ситуация ж вроде вполне рабочая. Не понимаю, почему Аксапта ее не обрабатывает корректно.

Да, ситуация распространенная. Но, напрямую связать потребителя и источника на уровне строк документов с разными складами нельзя. Можно только через складские операции (например, зарезервировав в заказанных).
На мой взгляд, вполне объяснимый подход. Раз номенклатура приходит на один склад, а отгружается с другого, то явно между этими складами должно быть какое-то перемещение. Сводное планирование нормально обрабатывает эту ситуацию - под потребность будут созданы спланированные заказы на перемещение, а уже под потребность этих спланированных перемещений будет создан спланированных заказ на покупку (производство), ну или потребность будет покрыта из наличных запасов.
С другой стороны, мы у себя в процедуру создания заказа на покупку из заказа на продажу добавили создание между ними заказов на перемещение (используя те же настройки, что есть в сводном планировании). То есть, немного доработали возможность создания таких связок вне сводного планирования.

[Falcon]

Zitat:

Zitat von sukhanchik

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

Спасибо за ответ. Логику разработчиков я понимаю: им хотелось ограничить количество разных сценариев и сохранить целостность данных. Но они при этом сделали допущения, совершенно немыслимые в реальной жизни. Какими бы ни были конечными эти заказы - между моментом их размещения и отгрузки в реальной компании проходят недели, а то и месяцы. В течение которых может очень многое случиться. И что, получается - нельзя даже поменять склад, с которого будет грузиться клиенту товар в начальной точке? А если он, простите, банально сгорел? Удалять весь заказ и вводить снова? А если что-то случилось с промежуточными складами, когда товар уже был отгружен в начальной точке?... Вообще, предполагать, что данные не придется менять после ввода - это плохой дизайн, и того, кто писал спецификацию этой логики, надо бы отправить на реальное производсто годика на два, чтобы набрался уму-разуму.

[Vals]

Кстати, при утверждении Спланированного заказа есть настройка маркировки. Если её поставить, то потом всё - фиг чё изменишь

[Falcon]

Zitat:

Zitat von Vals

Кстати, при утверждении Спланированного заказа есть настройка маркировки. Если её поставить, то потом всё - фиг чё изменишь

Так это тоже плохо. Ну не бывает в реальной жизни, чтобы открытый (не отгруженный/не оприходованный) заказ не надо было поменять. И что, предлагается удалять все и заводить по новой? Глупо же.

[Vals]

Именно, я с этой хренью столкнулся и зарёкся пользоваться.
Работает как "жёсткое" резервирование: только так и больше никак.

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

P.S. ТОлько заметил: написал строчку, а подпись на страницу

[Ivanhoe]

Немного в сторону - мое мнение, что использование маркировки и для расчета себестоимости, и для связок продаж/закупок, и для сводного - один из главных архитектурных косяков стандарта. Наравне с жестким резервированием всех аналитик в версиях до 2012 R3 и гибким резервированием, но только с полным WMS, в 2012 R3.

[Raven Melancholic]

Zitat:

Zitat von Ivanhoe

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

Вот с этим абсолютно согласен. Поэтому уже в нескольких проектах делаю разное поведение (все равно больших изменений в DAX2009 от MS не будет, можно и поиздеваться).