Cтрокa закупки - как убрать значение WMSLocation ?

[Lankey]

Доброго дня
AX2012.
Пользователь жалуется, что на строке закупки (purchLine) , когда убирает значение из поля WMSLocationID (местоположение), то никаких сообщений не выдается, но WMSLocationID не убирается. То есть, при обновлении записи строки закупки значение снова в поле видно, будто его и не убирали

Я дебаг кода делаю и вижу , что кастомизаций, вроде, нет, что на поведение бы влияли. Там при сохранении записи вызывается purchLineType->update и в нем вызывается стандартный класс InventUpd_Estimated и в нем уже updateAutoDimMovement , что и вертает WMSLocationID обратно. (берет его из default location для ItemId, то есть, вызывает WMSLocation:dafaultItemLocation())

Проблема в том, что я не понимаю, зачем это делается и как объяснить это, соответственно, пользователю?
Может кто-то объяснить с функциональной т.з., зачем так сделано, и почему сообщений никаких нет

Заранее благодарю

[twilight]

Я думаю, что в стандарте просто не предусмотрели такой сценарий, что кто-то будет убирать значение по умолчанию, а не выбирать другое.
А какой у вас бизнес-процесс? Когда вы используете значение по умолчанию, а когда удаляете?

[sukhanchik]

Цитата:

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

Доброго дня
AX2012.

Проблема в том, что я не понимаю, зачем это делается и как объяснить это, соответственно, пользователю?
Может кто-то объяснить с функциональной т.з., зачем так сделано, и почему сообщений никаких нет

Заранее благодарю

Ячейка по умолчанию на то и "по умолчанию", чтобы вместо пустого значения подставить значение "по умолчанию". Ну это как Вам сказали доехать от п.А до п.Б на автобусе №ХХХ, а не "на любом" или "там спросите".
Т.е. если пользователь хочет, чтобы ячейка определилась бы позднее - то не нужно ее определять по умолчанию. И пусть пользователь сам выберет, на каком автобусе ему ехать

[Владимир Максимов]

В общем случае, "значение по умолчанию" должно подставляться именно при первичном создании строки документа. Но, насколько я понимаю, тут невозможно отличить процесс создания аналитики при создании новой строки от процесса модификации аналитики, когда строка уже существует. Из-за специфики работы с аналитиками.

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

Отсутствие сообщений и визуальные спец.эффекты - это все то же. Просто "не заморачивались" из-за не стандартной ситуации.

Такие же эффекты наблюдаются в любых документах, где может быть указано местоположение. Т.е. это "общее место", а не что-то специфичное именно для закупок