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

[Андре]

Добрый день.

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

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

[mazzy]

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

[Андре]

Цитата:

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

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

[mazzy]

Закупщики пользуются складскими журналами? Во как!
Так бы и спросил – можно ли в складских журналах изменять единицы измерения?
Ну, тогда действительно. В складских журналах единицы измерения не изменяются. Жаль, конечно. Но пока так.

Теперь попробуем немного поразмышлять о том насколько хорошо изменять складскию единицу измерения задним числом. Уже введенная история – это история. Аксапта не позволяет редактировать уже введенную и разнесенную информацию. Подход такой. Этот подход работает для бухгалтерских проводок, счетов-фактур, накладных, предложений и… складских проводок. А почему складские проводки должны быть исключением?

Если хочешь изменить складскую аналитику, то выбери день Х, закрой все проводки по данной номенклатуре (пересчитается себестоимость), измени единицу измерения и выполни инвентаризацию этой номенклатуры. В результате все обороты до дня Х будут в старой единице измерения, после для Х в новой единице измерения, а в день Х ты увидишь трансформационные проводки. А на счете прибылей и убытков ты увидишь финансовый результат твоих действий (позаботься о соответствующем счете).

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

Выводы:
Если возникает задача изменить складскую единицу измерения задним числом, то стоит трижды подумать. И только после этого со всеми предосторожностями сделать.

Если хочется просто иметь возможность указывать единицу измерения в складских журналах, то можно подумать о модификации формы (перекрыть методы единиц измерения соответствующего класса InventMov_Journal*).


ЗЫ Хм… А в 3.0 складские журналы тоже только в складских единицах измерения. Интересно, а почему разработчики так настаивают на обязательной складской единице измерения в складских журналах? Из-за округления? Надо подумать. Подождем релиза.

[Андре]

Цитата:

Теперь попробуем немного поразмышлять о том насколько хорошо изменять складскию единицу измерения задним числом.

Нет. Вовсе не задним числом. Сейчас поймешь - смотри:

Цитата:

Если хочешь изменить складскую аналитику, то выбери день Х, закрой все проводки по данной номенклатуре (пересчитается себестоимость), измени единицу измерения и выполни инвентаризацию этой номенклатуры.

До этого я вроде дошел (если я все правильно понял..)

Цитата:

В результате все обороты до дня Х будут в старой единице измерения, после для Х в новой единице измерения...

И теперь я делаю оборотку, причем за весь период....

До дня Х я суммирую обороты в старой единице измерения, после дня X я начинаю прибавлять к ним обороты в новой единице измерения, то есть прибавлять к килограммам штуки, что не есть хорошо, а вернее совсем плохо.

Или я что-то не понимаю ?

[mazzy]

Все верно понимаешь.
Ключевой фразой является "ВЫБЕРИ день Х"
Выбери осознано и вдумчиво. Учитывая все факторы.
Взвесь и прими решение.

[Андре]

Цитата:

Все верно понимаешь.
Ключевой фразой является "ВЫБЕРИ день Х"
Выбери осознано и вдумчиво. Учитывая все факторы.
Взвесь и прими решение.

Как я понимаю, день Х, должен быть выбран таким образом, чтобы желаемые диапазоны дат, для построения оборотной ведомости не пересекали эту хитрую точку.
Обычно снабженцы строят оборотку за день, месяц, но как я понял не против посмотреть и на год. Таким образом идеальным моментом для данной операции является Новый Год.
Все бы хорошо, но до Нового Года далеко, а менять единицу измерения надо уже сейчас. Боюсь, что в данном случае и до конца месяца не дотянешь , не говоря уж о годе. Пожалуй проще поговорить с закупщиком, и объяснить ему, что всем будет лучше, если он будет сам, на калькуляторе пересчитывать новые единицы в старые, а в системе оставить все как есть

Может все таки есть еще какие нибудь способы решить эту проблему ?

[komar]

Слей старую номенклатуру, прими на склад новую, с новыми единицами.

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

[Андре]

Цитата:

Слей старую номенклатуру, прими на склад новую, с новыми единицами.

А что здесь нового. Обороты то я все равно буду получат неверные:

Цитата:

И теперь я делаю оборотку, причем за весь период....

До дня Х я суммирую обороты в старой единице измерения, после дня X я начинаю прибавлять к ним обороты в новой единице измерения, то есть прибавлять к килограммам штуки, что не есть хорошо, а вернее совсем плохо.

[Андре]

Цитата:

Слей старую номенклатуру, прими на склад новую, с новыми единицами.

Или ты имеешь в виду слить номенклатуру А, а принять номенклатуру Б ?

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

[komar]

Ну, лишнюю можно и скрыть, а сервер все выдержит.
Ну какое-то время будет сумма. Велика ли проблема?

[Андре]

Цитата:

Ну, лишнюю можно и скрыть, а сервер все выдержит

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

Цитата:

Ну какое-то время будет сумма. Велика ли проблема?

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

[komar]

Может, программизмом? Дабы в складских журналах можно было единицы менять (чем они хуже закупок-заказов). Стандартного решения больше не вижу.
Или оборотку переписать...

[Андре]

Цитата:

Или оборотку переписать...

Уже сделал.

[BigMike]

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

[BigMike]

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

[Geo]

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

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

[glibs]

Цитата:

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

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

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

Цитата:

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

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

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

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

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

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

[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.

[Geo]

Цитата:

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

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

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

Цитата:

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

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

Цитата:

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

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

Цитата:

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

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

Спасибо!