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

[Андре]

Добрый день.

Кажется этот вопрос сюда.

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

[BigMike]

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

[BigMike]

И, кстати говоря, почему не происходит такого пересчета при смене единиц?
Вот к примеру, закупили мы 5 000 штук номенклатуры.
Открытых проводок нет. Меняем единицу складского учета со "штуки" на "тысячу штук". В итоге в запросе "В наличии" получаем 5000 "тысяч штук" или 5 000 000 "штук". Разве это правильно?

[Geo]

Возможно, не самый умный вопрос, но всё-таки: с 2003-го года никаких подвижек не произошло? Всё так же система не хранит единицу измерения в складских операциях, и дает менять ее в карточке номенклатуры с миллиграммов на килотонны, и в отчетах бодро объединяет одно с другим, а себестоимость считает вообще "вслепую"?

Почему, всё-таки, менять складскую единицу можно только когда нет открытых проводок? Какой смысл в этом ограничении, если пересчетов всё равно нет как класса, а менять единицу, по логике, должно быть нельзя если есть как раз разнесенные операции?

[glibs]

Цитата:

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

...
Почему, всё-таки, менять складскую единицу можно только когда нет открытых проводок?
...

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

Цитата:

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

...
менять единицу, по логике, должно быть нельзя если есть как раз разнесенные операции?
...

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

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

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

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

[Geo]

Цитата:

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

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

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

Цитата:

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

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

Цитата:

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

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

Цитата:

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

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

Спасибо!

[glibs]

Цитата:

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

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

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

[Geo]

Цитата:

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

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

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

Цитата:

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

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

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

[glibs]

Цитата:

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

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

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

[kashperuk]

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

                if (InventTrans::transactionsExist(this.ItemId))
                    return checkFailed(strfmt("@SYS120463",this.ItemId));

                if (InventItemPrice::costPricesExistForItem(this.ItemId))
                    return checkFailed(strfmt("@SYS126703",this.ItemId));

где метки, соответственно, значат:

Цитата:

The inventory unit for item %1 cannot be changed because transactions exist. If the transactions cannot be deleted you will need to use a new item number with a new inventory unit.

и

Цитата:

The inventory unit for item %1 cannot be changed because activated cost prices exist. The cost prices can only be deleted by deleting the item.