Смена Inventory Dimensions в Intercompany Orders

[sukhanchik]

Цитата:

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

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

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

[Raven Melancholic]

Цитата:

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

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

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

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

Цитата:

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

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

[Falcon]

Цитата:

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

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

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