Какой смысл InventDim на строках заказа?

[IKA]

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

В системе во многих отчетах (напимер, delivery note) идет join CustPackingSlipTrans с InventDim.
Какой смысл InventDim на строках заказа/закупок и т.д, если по сути важно то, что указано на проводках, а не на заказе?
Это просто значение по умолчанию, которое лучше нигде в коде не использовать(если только конкретно указано в спецификации, что именно оно нужно) и не полагаться на его значения?
Я понимаю, что заказ по сути черновик(кот можно впоследствии даже удалить) и важны сами транзакции, привязанные к нему, но просто не понятно какой смысл этих полей, если на складских транзакциях могут быть совсем иные значения?

[twilight]

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

[S.Kuskov]

Цитата:

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

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

Угу. IKA, не забывайте, что в InventDim могут быть не только аналитики хранения, но и номенклатурные аналитики, типа цвет, размер и т.д.

P.S.:Флаги "Первичная аналитика" и "Обязательный" в аналитиках хранения

[sukhanchik]

Хотя ключевые моменты уже отметили - я хочу добавить еще одну мысль.
Резервирование производится в рамках тех аналитик, которые были указаны в строках заказа на продажу. Ну т.е. в исходной задаче указано, что товар может резервироваться по разным складам, если склад не указать, однако, в действительности склад часто может указываться, для того, чтобы резервирование (подбор товара) осуществлялось внутри именно этого склада. Например, в Москве у Вас такого-то товара 100 шт, а в С-Петербурге - 10 шт. А клиент у Вас отгружается из С-Петербурга. Система должна подбирать клиенту только тот товар, которые находится в С-Петербурге, т.к. товар из Москвы отгрузить нельзя со склада в С-Петербурге (без предварительного переноса).

Остальное следует по аналогии - номер партии, сайт и т.д. Конечно, смысла указывать ячейку или номер ГТД в заказе на продажу не имеет.

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

[EVGL]

"Резервирование производится в рамках тех аналитик, которые были указаны в строках заказа на продажу" ... и которые отмечены как "Primary" в группе складской аналитики.

[sukhanchik]

Цитата:

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

"Резервирование производится в рамках тех аналитик, которые были указаны в строках заказа на продажу" ... и которые отмечены как "Primary" в группе складской аналитики.

Не совсем так. Первичные (Primary) просто обязательные к заполнению. И без них мы просто не заполним аналитики в заказе на продажу. Поэтому хотим мы или нет, но резервирование будет производиться действительно в рамках аналитик "Primary".
Однако, нам ничего не мешает вручную "уточнить" дополнительные аналитики. Уточненные аналитики пробьются сразу в складские проводки и уже от них будет отталкиваться резервирование. Я помню код того select-а, который смотрит на "первичность" аналитик.
Однако, укажите в заказе на продажу ячейку, в которой нет товара (я предполагаю, что ячейка не является первичной аналитикой). И система не сможет автоматически зарезервировать товар, т.к. в этой ячейке она его не найдет.

AX 2009

[Starling]

Цитата:

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

Не совсем так. Первичные (Primary) просто обязательные к заполнению. И без них мы просто не заполним аналитики в заказе на продажу.
...
AX 2009

Возможно я чего-то не понимаю, но AX 2009 так никогда не работала. И я уже не первый раз читаю на форуме это утверждение.
Вы можете оставить пустой аналитику, для которой активен параметр «Первичные», вы НЕ можете оставить аналитику пустой для которой активен параметр «Обязательная».
Я для себя пришел к выводу, что параметр «Первичная» влияет на:
1. Процесс резервирования, если используется резервирование в заказанных.
2. Отображение аналитик в форме Резервирования при ручном резервировании.
Если не трудно скажите метод где происходит автоматическое резервирование с учетом этого параметра, я для себя ни каких отличий не нашел хоть активный параметр, хоть нет (резервирование в заказанных не в счет). Автоматическое резервирование всегда одинаково работало. Если аналитика указана, то резервирует только в ней, если аналитика не указан то резервирует в любой где есть остаток.

[sukhanchik]

Цитата:

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

Возможно я чего-то не понимаю, но AX 2009 так никогда не работала.
...
Автоматическое резервирование всегда одинаково работало. Если аналитика указана, то резервирует только в ней, если аналитика не указан то резервирует в любой где есть остаток.

Цитата:

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

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

Ээээ а мы разве не об одном и том же говорим? Мое возражение заключалось в том, что для автоматического резервирования достаточно указать аналитики в заказе на продажу, независимо от их первичности.
Я был неправ в том, что первичная обязательная к заполнению. Тут, да, признаю, был неправ.