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

[Андре]

Добрый день.

Я тут последнее время довольно плотно занимаюсь Oracle eBS. Заодно сравниваю, различные решения в той и другой ERP системе, а также что можно позаимствовать из OeBS в Axapta, а что наоборот.

Коэффициент пересчет из одной единицы измерения в другую на уровне партии - функциональность OeBS, используемая на практически всех предприятих, где есть непрерывное производство. Простейший пример: поставщики привозят нам цемент в вагонах, мы его храним в килограммах. Так как различные поставки цемента имеют различную влажность, то вывести единый коэффициент для перерасчета вагонов в килограммы не возможно. Но, после проведения тестов и определения влажности цемента мы всегда можем указать указать коэффициент пересчета для данной партии. Данная функциональность необходима там, где присутсвуют растворы и смеси различной концентрации: химической и пищевой промышленности, металлургии, нефтяной и газовой промышленности, life science и т.д. Это также могуть быть какие-то качественные характеристики партии - например, экстрактивность при производстве пива.

Несмотря на то, что функциональность довольно актуальна, как я понял, реализована она только в OeBS. Кстати, если кто-то знает, где еще присутсвует такая возможность - буду благодарен за информацию.
Я слышал, что SAP работает над данным функционалом (называя его catch weight), но как я понял это у них пока в стадии глубокой разработки. Впрочем, моя информация может быть устаревшей - если знает про это больше, опять же, буду рад услышать.

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

Собственно, вот форма пересчета единиц измерения:



Я добавил сюда номер партии.

Вот работа механизма на примере закупки:



То есть, в зависимости от номера партии система сама пересчитывает закупаемое количество из закупочных единиц измерения в складские.

Вот складские проводки, после разноски закупки:



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

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

Буду рад, если кому то будет это будет или натолкнет на новые мысли.

[xan]

Андрей.

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

Александр.

[Андре]

Цитата:

Идея хорошая, но тут, по моему мнению, проблема в другом: в одновременном учете в двух единицах.

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

Цитата:

Учет сахарного песка. Нужно одновременно знать и килограммы и мешки, при чем одно в другое пересчитывается однозначнно только в рамках партии. А планируется в килограммах .....

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

[Valery]

Цитата:

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

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

Ну почему же не переделать . Мы, автоматизируя одно предприятие, где каждая транзакция учитывалась как в объемных декалитрах, так и в декалитрах абсолютного алкоголя, сделали это. Не так уж и сложно хотя и не 1.5 часа

[Андре]

Цитата:

Не так уж и сложно хотя и не 1.5 часа

Да? И себестоимость нормально считается?

[mazzy]

Цитата:

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

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

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

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

[Андре]

Цитата:

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

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

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

[Андре]

Цитата:

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

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

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

[mazzy]

Цитата:

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

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

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

Цитата:

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

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

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

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

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

[Андре]

Цитата:

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

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

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

Цитата:

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

[mazzy]

Согласен.

[Андре]

Да, и еще, я тут вот что подумал пока обедал....

Цитата:

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

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

[mazzy]

Цитата:

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

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

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

Но не забывай, что в Аксапте аналитики цвет и размер можно переименовать.
И, кроме того, добавить новые складские аналитики.
Чего только народ не придумывает с этими аналитиками...

[Андре]

Цитата:

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

Ээээ... я имел в виду пример из реального бизнеса.

Учет по серийным номерам ведется как правило при учете техники, например сотовых телефонов или компьютерных комплекутющих. В общем тогда, когда c одной стороны нужно иметь возможость точно сопоставить поступление с расходом, а с другой стороны предмет учета достаточно ценен, чтобы брать на себя дополнительные телодвижения по отслеживанию серийных номеров. Как правило товары подобно рода имеют свойство сохранять свою массу/объем с течением времени и усушке/утряске мало подвержены. А значит, и возможность использования коэффициента пересчета на уровне серийного номера для них мало актуальна. Тот же OeBS (извини, что все к нему возвращаюсь, но идея все-таки оттуда) поддерживает склады двух типов: дискретные и процессные. И возможность учета в двух единицах измерения поддерживают только последнии.

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

[EVGL]

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

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

[EVGL]

Прошло... 8 лет. Пересчет единиц переписан заново, преимуществ для клиентов в результате переписывания = 0. Как и раньше, разные конфигурации товара (о партиях и не говорим) не могут иметь разный вес, разный объем. Натыкаюсь на это на каждом втором проекте: дискретное, процессное производство... Результат: невозможность использовать конфигуратор продукции для конфигурации длины и ширины.

Переписать, как и 8 лет назад, не представляется возможным: несмотря на кошерный RecId в таблице пересчета, RecId этот ссылается на продукт, а не на DistinctVariant. Все вызовы обросли преобразованием ItemId в ProductRecId, чтобы свести на нет, так сказать, выгоды в производетельности:

                qty = UnitOfMeasureConverter::convert(qty,
                                                      UnitOfMeasure::unitOfMeasureIdBySymbol(inventUnitId),
                                                      UnitOfMeasure::unitOfMeasureIdBySymbol(salesLine.SalesUnit),
                                                      NoYes::Yes,
                                                      InventTable::itemProduct(salesLine.ItemId));

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