AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Функционал
DAX
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 14.11.2005, 11:48   #1  
Андре is offline
Андре
Moderator
Сотрудники компании GMCS
 
2,375 / 464 (20) +++++++
Регистрация: 03.12.2001
Thumbs up Пересчет между двумя единицами измерения на уровне партии
Добрый день.

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

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

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

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

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

Нажмите на изображение для увеличения
Название: one.jpg
Просмотров: 675
Размер:	29.4 Кб
ID:	1597

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

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

Нажмите на изображение для увеличения
Название: two.jpg
Просмотров: 721
Размер:	26.8 Кб
ID:	1598

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

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

Нажмите на изображение для увеличения
Название: three.jpg
Просмотров: 826
Размер:	32.2 Кб
ID:	1599

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

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

Буду рад, если кому то будет это будет или натолкнет на новые мысли.
Старый 14.11.2005, 11:59   #2  
xan is offline
xan
Участник
Ex AND Project
 
455 / 63 (3) ++++
Регистрация: 18.02.2003
Адрес: Пушкин
Андрей.

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

Александр.
Старый 14.11.2005, 12:08   #3  
Андре is offline
Андре
Moderator
Сотрудники компании GMCS
 
2,375 / 464 (20) +++++++
Регистрация: 03.12.2001
Цитата:
Идея хорошая, но тут, по моему мнению, проблема в другом: в одновременном учете в двух единицах.
Как я понял, ты имеешь в виду то, что мы не можем в складской проводке хранить количество сразу в двух единицах измерения. Да, это плохо. Хуже, что это уже не переделать .

Цитата:
Учет сахарного песка. Нужно одновременно знать и килограммы и мешки, при чем одно в другое пересчитывается однозначнно только в рамках партии. А планируется в килограммах .....
Ты имеешь в виду, что при планировании мы учитываем некий усредненный коэффициент пересчета? А как по другому? Ты же в момент планирования не знаешь, этот коэффециент пересчета для конкретной партии.
Старый 14.11.2005, 14:09   #4  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Андре
Вся реализация свелась к добавлению поля в таблицу UnitConvert (Type = InventBatchId), правке методов данной таблицы (добавлению еще одного опционального параметра - партии) и правки всех вызовов этих методов (перекрестные ссылки значительно упрощают данную задачу). Как правило, во всех методах, где вызываются методы UnitConvert получить значение партии не составляет труда.
Вообще говоря, правильно добавлять не unitConvert, а InventDimID
а также выбор аналитики, параметр в аналитике и прочую обертку вокруг складских аналитик.

Спасибо. Идея очень перспективная.
Надо подумать..
__________________
полезное на axForum, github, vk, coub.
Старый 14.11.2005, 14:32   #5  
Андре is offline
Андре
Moderator
Сотрудники компании GMCS
 
2,375 / 464 (20) +++++++
Регистрация: 03.12.2001
Цитата:
Вообще говоря, правильно добавлять не unitConvert, а InventDimID
Наверное ты хотел сказать "не InventBatchId". Все равно не согласен .

Пересчет единиц измерения мы делаем на уровне партии, а не на уровне "коомбинация складских аналитик". Потому, что на уровне партии данная операция имеет смысл, а на уровне этой самой коомбинации я его пока не вижу.
Более того, я вижу, когда это может помешать. Например, мы получили партию нашего цемента, но часть партии поместили на один склад, часть на другой. В результате у нас будет 2 inventDimId - но коэффициент пересчета для них один и тот же (партия одна и та же). То есть, в твоем варианте мы должны созать 2 строки в UnitConvert (для каждого inventDimId), вместо одной в моем случае.
Можно конечно придумать кучу красивой теории вокруг всего этого дела. Например, некие группы пересчета в котором указывать в разрезе каких складских аналитик мы ведем коэффициенты пересчета и для каждой номенклатуры указывать эту группу пересчета.
Можно, только в этом случае сложность доработки существенно возрастет и вероятность ее успешной реализации будет гораздо ниже . Хотя решение будет универсальным.
Старый 14.11.2005, 14:37   #6  
Андре is offline
Андре
Moderator
Сотрудники компании GMCS
 
2,375 / 464 (20) +++++++
Регистрация: 03.12.2001
Цитата:
а также выбор аналитики, параметр в аналитике и прочую обертку вокруг складских аналитик.
Кстати, концепция складских аналитик теперь мне кажется не такой уж удачной. В OeBS, например, партии, серийные номера, сортность и т.д. - отдельные сущности, которые напрямую "протягиваются" в транзакции и справочные данные, а не ввиде "пучка" - InventDimId.

Как результат, мы просто не знаем про многие проблемы, присущие варианту "складских аналитик". В минусе у нас трудоемкость первоначальной настроки системы, когда для каждой номенклатуры мы должны указать не "коомбинацию складской аналитики", а несколько независимых сущностей. Однако, как я заметил, эта информация не вводится пользователем ручками, а закачивается в систему из внешних источников данных.
Старый 14.11.2005, 14:37   #7  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Андре
Наверное ты хотел сказать "не InventBatchId". Все равно не согласен .
Да, извиняюсь.

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

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

Нужна аналогичная настройка - по каким аналитикам настраивать пересчет единиц, а по каким нет
Тогда для разных номенклатур можно будет по разному использовать номенклатурные аналитики при пересчете. Где-то не использовать вообще, где-то использовать только партию, где-то - партию+серийный номер, где-то размер и т.п.
__________________
полезное на axForum, github, vk, coub.
Старый 14.11.2005, 14:40   #8  
Андре is offline
Андре
Moderator
Сотрудники компании GMCS
 
2,375 / 464 (20) +++++++
Регистрация: 03.12.2001
Цитата:
Изначально опубликовано mazzy:
я же писал ...

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

Цитата:
Можно конечно придумать кучу красивой теории вокруг всего этого дела. Например, некие группы пересчета в котором указывать в разрезе каких складских аналитик мы ведем коэффициенты пересчета и для каждой номенклатуры указывать эту группу пересчета.
Можно, только в этом случае сложность доработки существенно возрастет и вероятность ее успешной реализации будет гораздо ниже . Хотя решение будет универсальным.
Старый 14.11.2005, 14:55   #9  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Согласен.
__________________
полезное на axForum, github, vk, coub.
Старый 14.11.2005, 15:17   #10  
Андре is offline
Андре
Moderator
Сотрудники компании GMCS
 
2,375 / 464 (20) +++++++
Регистрация: 03.12.2001
Да, и еще, я тут вот что подумал пока обедал....

Цитата:
"выбор аналитики, параметр в аналитике и прочую обертку вокруг складских аналитик"
Помоему ты сейчас рассуждаешь с точки зрения программиста, а не с точки зрения консультанта.
Ты можешь сформулировать зачем может понадобиться зависимость коэффициента пересчета от любой из складских аналитик (кроме партии) в реальном производстве ? Если не сложно, приведи пример.
Можно конечно реализовать эту красивую обертку, очень правильную с точки зрения проектирования, вот только будет ли от этого полезный выхлоп.... Может стоит потратить это время на что нибудь другое? Например, реализовать механизм изменения этого коэффициента с течением времени, что позволит отражать изменение свойств веществ с течением времени (например, высыхание того же цемента).
Старый 14.11.2005, 15:25   #11  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Андре
Ты можешь сформулировать зачем может понадобиться зависимость коэффициента пересчета от любой из складских аналитик (кроме партии) в реальном производстве ? Если не сложно, приведи пример.
Из существующих только конфигурация, партия, и, может быть, серийный номер.
Для таких же целей, что и у тебя.

Но не забывай, что в Аксапте аналитики цвет и размер можно переименовать.
И, кроме того, добавить новые складские аналитики.
Чего только народ не придумывает с этими аналитиками...
__________________
полезное на axForum, github, vk, coub.
Старый 14.11.2005, 15:38   #12  
Андре is offline
Андре
Moderator
Сотрудники компании GMCS
 
2,375 / 464 (20) +++++++
Регистрация: 03.12.2001
Цитата:
Из существующих только конфигурация, партия, и, может быть, серийный номер. Для таких же целей, что и у тебя.
Ээээ... я имел в виду пример из реального бизнеса.

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

Что же касается конфигурации, то в процессных производствах это пожалуй называется сортностью, но из за дискретной природы значений конфигурации использовать ее для этих целей довольно проблематично. То есть, опять же я не могу придумать такого очевидного примера, как например с цементом, когда в одной партии разные "конфигурации" чего-то имели бы различные коэфф. пересчета.
Старый 14.11.2005, 17:16   #13  
Valery is offline
Valery
Участник
 
381 / 10 (1) +
Регистрация: 28.02.2002
Адрес: Москва
Цитата:
Сообщение от Андре
Как я понял, ты имеешь в виду то, что мы не можем в складской проводке хранить количество сразу в двух единицах измерения. Да, это плохо. Хуже, что это уже не переделать
Ну почему же не переделать . Мы, автоматизируя одно предприятие, где каждая транзакция учитывалась как в объемных декалитрах, так и в декалитрах абсолютного алкоголя, сделали это. Не так уж и сложно хотя и не 1.5 часа
Старый 14.11.2005, 17:29   #14  
Андре is offline
Андре
Moderator
Сотрудники компании GMCS
 
2,375 / 464 (20) +++++++
Регистрация: 03.12.2001
Цитата:
Не так уж и сложно хотя и не 1.5 часа
Да? И себестоимость нормально считается?
Старый 14.11.2005, 19:47   #15  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Хотели пример из реального бизнеса? Пожалуйста. В упаковочном производстве (т.н. convertibles) конечная продукция может быть в рулонах (например, многослойная металлизированная пленка с логотипом маргарина, которая режется уже предприятием-клиентом). В зависимости от случайных флуктуаций рулоны одной и той же длины получаются легче или тяжелее, причем данные о весе существенны и необходимы при отгрузке. Продажа клиенту идет в метрах (единица складского хранения) или штуках. Так вот партия связана с производственным заказом (попросту номер произв. заказа), а серийный номер - это номер рулона, которых в одной партии много.

Нечто похожее на вашу модификацию пришлось сделать. Бесит то, что модификации приходится делать в десятках вызовов UnitConvert. При этом не забудьте про подлый класс InventItemUnitConvert.
Старый 22.10.2013, 00:26   #16  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Прошло... 8 лет. Пересчет единиц переписан заново, преимуществ для клиентов в результате переписывания = 0. Как и раньше, разные конфигурации товара (о партиях и не говорим) не могут иметь разный вес, разный объем. Натыкаюсь на это на каждом втором проекте: дискретное, процессное производство... Результат: невозможность использовать конфигуратор продукции для конфигурации длины и ширины.

Переписать, как и 8 лет назад, не представляется возможным: несмотря на кошерный RecId в таблице пересчета, RecId этот ссылается на продукт, а не на DistinctVariant. Все вызовы обросли преобразованием ItemId в ProductRecId, чтобы свести на нет, так сказать, выгоды в производетельности:
X++:
                qty = UnitOfMeasureConverter::convert(qty,
                                                      UnitOfMeasure::unitOfMeasureIdBySymbol(inventUnitId),
                                                      UnitOfMeasure::unitOfMeasureIdBySymbol(salesLine.SalesUnit),
                                                      NoYes::Yes,
                                                      InventTable::itemProduct(salesLine.ItemId));
Найти бы этого лентяя, который "улучшал", и ткнуть бы носом в запросы клиентов в производственном секторе.
За это сообщение автора поблагодарили: gl00mie (7), ikopyl (5).
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
пересчет значения цены при измении единиц измерения в заказе natterru DAX: Функционал 11 29.08.2011 18:24
Как в динамическом запросе использовать исловие OR между двумя полями? yooshi DAX: Программирование 12 07.08.2009 16:34
Как сделать AND между двумя датасорсами на одном уровне в query rkorchagin DAX: Программирование 15 15.01.2009 17:42
Пересчет единиц измерения Scherban DAX: Функционал 4 17.02.2005 21:29
Пересчет единиц измерения номенклатуры tolstjak DAX: Функционал 6 02.02.2005 14:08
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 17:28.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.