Пересчет между двумя единицами измерения на уровне партии

[mazzy]

Цитата:

Сообщение от Андре

Вся реализация свелась к добавлению поля в таблицу UnitConvert (Type = InventBatchId), правке методов данной таблицы (добавлению еще одного опционального параметра - партии) и правки всех вызовов этих методов (перекрестные ссылки значительно упрощают данную задачу). Как правило, во всех методах, где вызываются методы UnitConvert получить значение партии не составляет труда.

Вообще говоря, правильно добавлять не unitConvert, а InventDimID
а также выбор аналитики, параметр в аналитике и прочую обертку вокруг складских аналитик.

Спасибо. Идея очень перспективная.
Надо подумать..

[Андре]

Цитата:

Вообще говоря, правильно добавлять не unitConvert, а InventDimID

Наверное ты хотел сказать "не InventBatchId". Все равно не согласен .

Пересчет единиц измерения мы делаем на уровне партии, а не на уровне "коомбинация складских аналитик". Потому, что на уровне партии данная операция имеет смысл, а на уровне этой самой коомбинации я его пока не вижу.
Более того, я вижу, когда это может помешать. Например, мы получили партию нашего цемента, но часть партии поместили на один склад, часть на другой. В результате у нас будет 2 inventDimId - но коэффициент пересчета для них один и тот же (партия одна и та же). То есть, в твоем варианте мы должны созать 2 строки в UnitConvert (для каждого inventDimId), вместо одной в моем случае.
Можно конечно придумать кучу красивой теории вокруг всего этого дела. Например, некие группы пересчета в котором указывать в разрезе каких складских аналитик мы ведем коэффициенты пересчета и для каждой номенклатуры указывать эту группу пересчета.
Можно, только в этом случае сложность доработки существенно возрастет и вероятность ее успешной реализации будет гораздо ниже . Хотя решение будет универсальным.

[Андре]

Цитата:

а также выбор аналитики, параметр в аналитике и прочую обертку вокруг складских аналитик.

Кстати, концепция складских аналитик теперь мне кажется не такой уж удачной. В OeBS, например, партии, серийные номера, сортность и т.д. - отдельные сущности, которые напрямую "протягиваются" в транзакции и справочные данные, а не ввиде "пучка" - InventDimId.

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

[mazzy]

Цитата:

Сообщение от Андре

Наверное ты хотел сказать "не InventBatchId". Все равно не согласен .

Да, извиняюсь.

Цитата:

Сообщение от Андре

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

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

Сейчас настраивается по каким аналитикам считать себестоимость, а по каким не считать.
Сейчас настраивается какие аналитики должны быть в прайсе, а какие нет.

Нужна аналогичная настройка - по каким аналитикам настраивать пересчет единиц, а по каким нет
Тогда для разных номенклатур можно будет по разному использовать номенклатурные аналитики при пересчете. Где-то не использовать вообще, где-то использовать только партию, где-то - партию+серийный номер, где-то размер и т.п.

[Андре]

Цитата:

Изначально опубликовано mazzy:
я же писал ...

Нужна аналогичная настройка - по каким аналитикам настраивать пересчет единиц, а по каким нет

Да, я понял. Я собственно это и имел в виду, когда писал:

Цитата:

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