Смена единицы измерения для хранения номенклатуры

[Geo]

Цитата:

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

Вопрос философский. Вы не найдете на него единого правильного ответа.

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

Цитата:

Я могу привести пример, когда смена складской единицы измерения не разрушит целостности данных.

Интересно. Приведите, пожалуйста.

Цитата:

Думайте перед сменой единицы измерения. Или вы хотите работать в системе не думая?
Если "козла пустить в огород", то он там и без таких проверок все разрушит до основания.

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

Цитата:

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

на самом деле, в АХ 2009 уже это изменили следующим образом - 2 проверки

Спасибо!

[glibs]

Цитата:

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

...
Интересно.
...

Смена штуки на рулон, например.

[Geo]

Цитата:

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

Смена штуки на рулон, например.

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

Цитата:

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

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

Это конечно да, нормальное сторнирование было бы лучше. Но в существующей архитектуре его не реализовать. При этом путь закрытия сомнительных операций через интерфейс гораздо проще, чем доработки архитектуры.

[glibs]

Цитата:

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

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

А вот с этим точно не согласен. Правильнее было бы иметь возможность сторнировать накладную. IMHO. Как в 4.0 появился некий убогий функционал сторнирования операций по клиентам, поставщикам и ГК, дающий дополнительный сервис в виде сопоставления и гарантии правильного указания суммы, валюты, и т.д. Так и в накладной должна быть возможность ее сторнирования с контролем корректности цен, себестоимости, и т.д. А сейчас сторинрование действительно трудоемко и чревато ошибками.