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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 23.02.2011, 10:50   #21  
mifi is offline
mifi
Microsoft Dynamics
Сотрудники Microsoft Dynamics
 
173 / 89 (3) ++++
Регистрация: 24.07.2002
Цитата:
Сообщение от mazzy Посмотреть сообщение
бог с ними - и с конкретным решением, и с конкретной компанией.

Вопрос как раз о подходе.
Насколько оправдан такой подход? особенно с отменой inventDim в следующей версии аксапты.

хочу также отметить, что существующий подход стандартной аксапты - редактирование складских проводок - противоречит общему подходу "запрет редактирования проводок, только сторно". а в Inventory II запрет редактирования распространяется и на складские проводки тоже. другими словами, подход "только сторно" обобщается.
На мой взгляд - это вроде лекарства от головной боли в виде гильотины. Т.е. да, от проблем (известных) стандартного склада избавляемся - стандартный код просто не работает, зато сколько всего нового открывается... А так, да - на изменение InventTrans пишут в свою imtrans. Деталей сказать не могу - не уверен,что NDA позволяет.

Последний раз редактировалось mifi; 23.02.2011 в 10:53.
Старый 23.02.2011, 10:56   #22  
mifi is offline
mifi
Microsoft Dynamics
Сотрудники Microsoft Dynamics
 
173 / 89 (3) ++++
Регистрация: 24.07.2002
Цитата:
Сообщение от mazzy Посмотреть сообщение
Гы... Прикольно.

Т.е. просто не искать ничего в ImTrans, а надеятся на консистентность базы...
Т.е. при неумелом вмешательстве программиста и/или при doUpdate, doDelete, doInsert пойдут косяки...
и никаких изменений в базе в обход аксапты...

Что ж, интересный подход - скорость в обмен на надежность.
хотя может быть они прямо в SQL-триггера код пишут...
Ну, в защиту можно сказать, что при неумелом вмешательстве программиста и стандартный склад развалить ничего не стоит. Написать "программисто-устойчивое" решение с открытым кодом вообще не очень просто.
Старый 23.02.2011, 11:05   #23  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от mazzy Посмотреть сообщение
Гы... Прикольно.

Т.е. просто не искать ничего в ImTrans, а надеятся на консистентность базы...
Т.е. при неумелом вмешательстве программиста и/или при doUpdate, doDelete, doInsert пойдут косяки...

Что ж, интересный подход - скорость в обмен на надежность.
Ну знаешь, если абсолютно стандартной аксапте делать doInsert()/doDelete()/doUpdate() по inventTrans, то inventSum/InventSumLogTTS (очень важный для сводного), тоже разъедутся так что мама не горюй...
Так что я бы сказал - это равнозначный обмен.

А говоря насчет supportability то напомню участникам дискуссии что:
1. Софт поддерживается авторами, а не нанятыми индусами из Sonata Software. (Кстати - завтра еду к клиенту, у которого индус НЕДЕЛЮ лечил падение сервера, заставляя его ставить разные значения в размер буфера БД в AOS. Перепробовали около 15 разных волшебных значений - не помогло).
2. Какая принципиальная разница между этим решением (с виду довольно продуманным) и всеми этими, прости господи, вертикальными решениям партнеров MBS? Сравни то что мы видим здесь и то что в России получают клиенты, покупая "зарегистированное вертикальное решение".К слову сказать, тот же микрософт счас пытается ISV-партнеров продвигать. Чем тот же FSB-Development не ISV-партнер ?
Старый 23.02.2011, 11:20   #24  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
ой, я бы не хотел уводить разговор в политику - как хотят.
я бы оставил разговор в техническом русле.

насчет того, что и стандартный подход можно развалить - согласен.
__________________
полезное на axForum, github, vk, coub.
Старый 23.02.2011, 12:35   #25  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
А еще у них есть полуторачасовой вебкаст про Inventory II:
https://fsbdev.webex.com/fsbdev/ldr....889183160758F8
Мне пока времени не хватило целиком посмотреть, но похоже что эндюзерскую функциональность они там достаточно полно показывают...
Старый 23.02.2011, 17:05   #26  
AX2009
Гость
 
n/a
в ах12 типа уменшают реданданси. инвенттранз разбили на две тоблицы,
в новой inventТransОrigin теперь хранитцо общая информация
да и вообще много чего поменяли. код будет весело апгрейдить )
За это сообщение автора поблагодарили: fed (0).
Старый 23.02.2011, 20:03   #27  
vc is offline
vc
Участник
Самостоятельные клиенты AX
Axapta Retail User
 
89 / 23 (1) +++
Регистрация: 03.06.2005
Вебкаст очень интересный.
В принципе лектор в самом начале говорит, что технические детали он освещать не будет, но все же два архитектурных момента там проскочили.
Первое, описывая систему резервирования, где то на отметке 1 час 12 минут вебкаста:
В складские проводки добавлены "системные" складские измерения лот прихода и дата прихода.
Каждая расходная проводка непосредственно связывается с лотом приходной проводки - в вебкасте показывается как это происходит при обработке отборочной накладной по заказу. Уже на этом этапе - до обработки накладной в проводке можно посмотреть сопоставление (открывается форма с текущей проводкой, и сопоставленной ей приходной) и будущую себестоимость.
В сочетании с постоянно работающим в фоне пересчетом и закрытием склада, таким образом наверное можно добиться того, чтобы число открытых проводок в ImTrans, по которым формируются значения текущих складских остатков было относительно небольшим.
Второе, где то на отметке 1 ч 30 минут лектор описывает возможность расчета сводного плана на фоне активной работы пользователей. Речь идет о том, что результат такого расчета был бы несогласованным при стандартной реализации: Допустим расчет идет один час (условно говоря с высших уровней иерархий спецификаций вниз по компонентам), в течение этого часа меняются и остатки по спецификациям и по компонентам и т.д. Решение - в момент запуска расчета сводного плана снимается снэпшот остатков. А технически - в момент запуска расчета запоминается наибольший на данный момент watermark, и в расчете плана не учитываются никакие проводки с watermark с бОльшими значениями.
По моему это подтверждает гипотезу о том, что watermark это просто монотонно увеличивающиеся идентификаторы транзаций типа - сторнировали предыдущее значение инвенттранса, записали будущее значение инвенттранса.

Мне по прежнему еще не понятно, каким алгоритмом исходя из этого они получают быстрый расчет остатков на произвольную дату.
Старый 25.02.2011, 17:21   #28  
George Nordic is offline
George Nordic
Модератор
Аватар для George Nordic
Злыдни
 
4,479 / 1250 (50) ++++++++
Регистрация: 17.12.2003
Адрес: Moscow
Записей в блоге: 9
Цитата:
Сообщение от mazzy Посмотреть сообщение
Гы... Прикольно.
Т.е. просто не искать ничего в ImTrans, а надеятся на консистентность базы...
Т.е. при неумелом вмешательстве программиста и/или при doUpdate, doDelete, doInsert пойдут косяки... и никаких изменений в базе в обход аксапты...
Что ж, интересный подход - скорость в обмен на надежность.
хотя может быть они прямо в SQL-триггера код пишут...
Угу. Уже проходили. Помниться, есть даже ряд решений по закрытию склада Средствами SQL...
Старый 25.02.2011, 17:25   #29  
George Nordic is offline
George Nordic
Модератор
Аватар для George Nordic
Злыдни
 
4,479 / 1250 (50) ++++++++
Регистрация: 17.12.2003
Адрес: Moscow
Записей в блоге: 9
Цитата:
Сообщение от vc Посмотреть сообщение
Мне по прежнему еще не понятно, каким алгоритмом исходя из этого они получают быстрый расчет остатков на произвольную дату.
SIFT или что-то подобное. Т.е. вполне возможно, что пишут служебную инфу типа остатки на дату (в разрезе аналитик? а как иначе?). Таким образом, можно существенно поднять и скорость вычислений. Да, зато при коррекции итоги надо пересчитывать...

С Уважением,
Георгий
Старый 28.02.2011, 12:16   #30  
vc is offline
vc
Участник
Самостоятельные клиенты AX
Axapta Retail User
 
89 / 23 (1) +++
Регистрация: 03.06.2005
Цитата:
Сообщение от George Nordic Посмотреть сообщение
SIFT или что-то подобное. Т.е. вполне возможно, что пишут служебную инфу типа остатки на дату (в разрезе аналитик? а как иначе?). Таким образом, можно существенно поднять и скорость вычислений. Да, зато при коррекции итоги надо пересчитывать...
С Уважением,
Георгий
Поискал информацию по SIFT. Думаю, ничего подобного SIFT там быть не должно. Тут разработчики явно декларируют отсутствие каких либо изменений в "регистрах" в момент проведения складских операций. Явно указывается, что используются только операция вставки строк в "таблицу складских остатков" - ImTrans. Остаток при этом - это всегда сумма по подмножеству строк в ImTrans.
Разработчики утверждают что в результате этого:
  • Полностью решена проблема с блокировками при проведении складских операций.
  • Появляется возможность проводить процедуру сводного планирования не прерывая обычные операции.
  • Скорость выполнения запросов и отчетов по складу, а также проведения складских операций существенно повышается.
Я исхожу из того, что эти их утверждения обоснованы - на мой взгляд косвенно это подтверждается хотя бы тем, что они не боятся добавлять в (традиционно довольно тяжелую) форму "В наличии" весь тот функционал, который они добавляют - суммовые остатки, выверку с главной книгой, все новые возможности по группировке, остатки на произвольную дату и т.д.

То есть мне кажется , что архитектурно подход FSB Development скорее противоположен подходу, реализованному Navision, что с этой точки зрения есть какая-то такая градация (для примера беру заказ с одной строкой):
  1. Navision - В момент разноски заказа обновляются значения множества SIFT ключей.
  2. Стандартная Аксапта - в момент разноски заказа обновляется значение соответствующей строки в InventSum
  3. Inventory II - В момент разноски заказа вставляется пара строк в ImTrans.

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

Интересно, а какая в этом плане архитектура у таких ERP как SAP и ORACLE?
Старый 01.03.2011, 18:46   #31  
vc is offline
vc
Участник
Самостоятельные клиенты AX
Axapta Retail User
 
89 / 23 (1) +++
Регистрация: 03.06.2005
Мне кажется, что я сейчас представляю каким образом могла бы быть реализована технология Watermark с заявленными характеристиками. Хочу описать это, чтобы выслушать ваше мнение - какие недостатки этой реализации мне не пришли в голову.

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

В основе технологии лежит отказ от принципа регистрации текущих значений остатков в таблице InventSum. Проведение складских операций не сопровождается операцией UPDATE над строкой какой-либо таблицы, в которой хранится текущее значение остатков.
Вместо связки InventSum/InventDim для контроля остатков используется единая таблица ImTrans. При этом API модуля логистики меняется лишь минимальным образом.
Текущие остатки (и остатки на произвольную дату) получаются путем суммирования по некоему набору строк в таблице ImTrans.
При этом fact-sheet подчеркивается
Цитата:
Все запросы отбирают лишь очень малую часть данных вследствие того, что строки таблицы весьма эффективно разделены на релевантную и нерелевантную часть без использования сложных индексных ключей, что ведет к непревзойденной производительности.
Каждая складская операция сопровождается вставкой одной или нескольких (чаще всего двух) строк в таблицу ImTrans.
Непосредственным источником при вставке строк в ImTrans чаще всего являются изменения в таблице InventTrans (вероятно реализовано через тригеры в БД).
Изменение строки в InventTrans сопровождается вставкой двух строк в ImTrans. Первая строка сторнирует предыдущее состояние InventTrans, вторая соостветствует состоянию InventTrans после изменения.
При удалении и при вставке строки в InventTrans в ImTrans вставляется по одной строке, со сторно состояния удаляемой из InventTrans строки, или с новыми значениями, соответственно.
Строки каждой такой транзакции объединены кодом - watermark. Вероятно вотермарки это значения типа int64, хронологически увеличивающиеся в порядке фиксации транзакций.

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

Строки в ImTrans могут создаваться не только на основе изменений строк в InventTrans. Для реализации расчета себестоимости по "средней за период" в конце каждого периода в ImTrans добавляются строки типа "Закрывающих период" и "Открывающих период". При этом "Закрывающие период" строки списывают остаток в разрезе складских аналитик,
а "Открывающие период" возвращают его обратно.
(по данным видеодемонстрации)

Исходя их этих исходных данных для обеспечения эффективного расчета остатков (текущих и на произвольную дату) мне представляется примерно такая процедура.

В начале нового дня резервируется несколько служебных значений вотермарков. Например это может быть прописано в процедуре выдачи значения нового вотермарка - если дата изменилась, записать несколько служебных ватермарков на для этой даты.
Дальше в какой-то момент вступает в действие служебный процесс Inventory II. В отдельную служебную таблицу, со структурой аналогичной ImTrans сохраняются остатки по состоянию на полночь.
После этого единой тразнакцией в ImTrans вставляются все эти строки. У этих строк отдельный тип (вроде OnHand), единый вотермарк, из служебного диапазона, зарезервированного на предыдущем этапе. В этой же транзакции значение этого вотермарка записывается в качестве текущего параметра системы.
Возможен вариант, когда в транзакции вставляется два набора строк, первый с меньшим вотермарком списывает остатки, второй, с большим вотермарком - приходует их.
С этого момента текущие остатки это сумма всех строк ImTrans вотермарки которых больше или равны вотермарку приходования остатков.

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

Коррекции по пересчетам, накладным расходам, и т.д. попадают в ImTrans штатным образом, в результате срабатывания триггера при изменении поля Adjustment в InventTrans, и попадают в текущем периоде. Так что они на остатки в прошлом не влияют.

Вроде бы все. Хотелось бы услышать ваше мнение - каковы слабые стороны такой реализации?
Используется ли подобный подход в каких либо других системах?
За это сообщение автора поблагодарили: S.Kuskov (2).
Теги
как правильно, полезное

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Kurt Hatlevik: Warehouse Management and Distribution for Dynamics AX 2009 Blog bot DAX Blogs 0 04.05.2009 14:05
Kurt Hatlevik: Sneak preview of the WMS E&E Blog bot DAX Blogs 0 04.05.2009 14:05
Kurt Hatlevik: Warehouse Management and Distribution for Dynamics AX 2009 Blog bot DAX Blogs 0 20.11.2008 01:10
Kurt Hatlevik: Sneak preview of the WMS E&E Blog bot DAX Blogs 0 20.11.2008 01:10
Arijit Basu: Copenhagen Convergence Review | Episode II Blog bot DAX Blogs 0 12.11.2007 01:55
Опции темы Поиск в этой теме
Поиск в этой теме:

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

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

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

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