23.02.2011, 10:50 | #21 |
Microsoft Dynamics
|
Цитата:
Сообщение от mazzy
бог с ними - и с конкретным решением, и с конкретной компанией.
Вопрос как раз о подходе. Насколько оправдан такой подход? особенно с отменой inventDim в следующей версии аксапты. хочу также отметить, что существующий подход стандартной аксапты - редактирование складских проводок - противоречит общему подходу "запрет редактирования проводок, только сторно". а в Inventory II запрет редактирования распространяется и на складские проводки тоже. другими словами, подход "только сторно" обобщается. Последний раз редактировалось mifi; 23.02.2011 в 10:53. |
|
23.02.2011, 10:56 | #22 |
Microsoft Dynamics
|
Цитата:
Сообщение от mazzy
Гы... Прикольно.
Т.е. просто не искать ничего в ImTrans, а надеятся на консистентность базы... Т.е. при неумелом вмешательстве программиста и/или при doUpdate, doDelete, doInsert пойдут косяки... и никаких изменений в базе в обход аксапты... Что ж, интересный подход - скорость в обмен на надежность. хотя может быть они прямо в SQL-триггера код пишут... |
|
23.02.2011, 11:05 | #23 |
Moderator
|
Цитата:
Так что я бы сказал - это равнозначный обмен. А говоря насчет supportability то напомню участникам дискуссии что: 1. Софт поддерживается авторами, а не нанятыми индусами из Sonata Software. (Кстати - завтра еду к клиенту, у которого индус НЕДЕЛЮ лечил падение сервера, заставляя его ставить разные значения в размер буфера БД в AOS. Перепробовали около 15 разных волшебных значений - не помогло). 2. Какая принципиальная разница между этим решением (с виду довольно продуманным) и всеми этими, прости господи, вертикальными решениям партнеров MBS? Сравни то что мы видим здесь и то что в России получают клиенты, покупая "зарегистированное вертикальное решение".К слову сказать, тот же микрософт счас пытается ISV-партнеров продвигать. Чем тот же FSB-Development не ISV-партнер ? |
|
23.02.2011, 11:20 | #24 |
Участник
|
ой, я бы не хотел уводить разговор в политику - как хотят.
я бы оставил разговор в техническом русле. насчет того, что и стандартный подход можно развалить - согласен. |
|
23.02.2011, 12:35 | #25 |
Moderator
|
А еще у них есть полуторачасовой вебкаст про Inventory II:
https://fsbdev.webex.com/fsbdev/ldr....889183160758F8 Мне пока времени не хватило целиком посмотреть, но похоже что эндюзерскую функциональность они там достаточно полно показывают... |
|
23.02.2011, 17:05 | #26 |
Гость
|
в ах12 типа уменшают реданданси. инвенттранз разбили на две тоблицы,
в новой inventТransОrigin теперь хранитцо общая информация да и вообще много чего поменяли. код будет весело апгрейдить ) |
|
|
За это сообщение автора поблагодарили: fed (0). |
23.02.2011, 20:03 | #27 |
Участник
|
Вебкаст очень интересный.
В принципе лектор в самом начале говорит, что технические детали он освещать не будет, но все же два архитектурных момента там проскочили. Первое, описывая систему резервирования, где то на отметке 1 час 12 минут вебкаста: В складские проводки добавлены "системные" складские измерения лот прихода и дата прихода. Каждая расходная проводка непосредственно связывается с лотом приходной проводки - в вебкасте показывается как это происходит при обработке отборочной накладной по заказу. Уже на этом этапе - до обработки накладной в проводке можно посмотреть сопоставление (открывается форма с текущей проводкой, и сопоставленной ей приходной) и будущую себестоимость. В сочетании с постоянно работающим в фоне пересчетом и закрытием склада, таким образом наверное можно добиться того, чтобы число открытых проводок в ImTrans, по которым формируются значения текущих складских остатков было относительно небольшим. Второе, где то на отметке 1 ч 30 минут лектор описывает возможность расчета сводного плана на фоне активной работы пользователей. Речь идет о том, что результат такого расчета был бы несогласованным при стандартной реализации: Допустим расчет идет один час (условно говоря с высших уровней иерархий спецификаций вниз по компонентам), в течение этого часа меняются и остатки по спецификациям и по компонентам и т.д. Решение - в момент запуска расчета сводного плана снимается снэпшот остатков. А технически - в момент запуска расчета запоминается наибольший на данный момент watermark, и в расчете плана не учитываются никакие проводки с watermark с бОльшими значениями. По моему это подтверждает гипотезу о том, что watermark это просто монотонно увеличивающиеся идентификаторы транзаций типа - сторнировали предыдущее значение инвенттранса, записали будущее значение инвенттранса. Мне по прежнему еще не понятно, каким алгоритмом исходя из этого они получают быстрый расчет остатков на произвольную дату. |
|
25.02.2011, 17:21 | #28 |
Модератор
|
Цитата:
Сообщение от mazzy
Гы... Прикольно.
Т.е. просто не искать ничего в ImTrans, а надеятся на консистентность базы... Т.е. при неумелом вмешательстве программиста и/или при doUpdate, doDelete, doInsert пойдут косяки... и никаких изменений в базе в обход аксапты... Что ж, интересный подход - скорость в обмен на надежность. хотя может быть они прямо в SQL-триггера код пишут... |
|
25.02.2011, 17:25 | #29 |
Модератор
|
Цитата:
С Уважением, Георгий |
|
28.02.2011, 12:16 | #30 |
Участник
|
Цитата:
Разработчики утверждают что в результате этого:
То есть мне кажется , что архитектурно подход FSB Development скорее противоположен подходу, реализованному Navision, что с этой точки зрения есть какая-то такая градация (для примера беру заказ с одной строкой):
Сейчас ключевым мне кажется вопрос - как удается быстро получать информацию по остаткам на текущую дату без использования таких агрегатов как SIFT или хотя бы InventSum. Возможно, что этот алгоритм легко расширить и для получения остатков на произвольную дату. Сначала мне казалось, что бэкграунд процесс просто помечает все "неактивные" записи ImTrans. Но во первых не очень понятно, как их надежно определить, во вторых тут появляется UPDATE на ImTrans, который вроде бы не очень согласуется с предыдущими декларациями, в третьих есть опасение, что "активных" записей при этом окажется все же слишком много, чтобы можно было получить заявленный существенный прирост производительности, ну и наконец - совсем непонятно, их каких соображений такой традиционный алгоритм "закрытия" записей по складским остаткам можно назвать "революционной watermark технологией" Какие то догадки у меня зреют, постараюсь позже сформулировать. Интересно, а какая в этом плане архитектура у таких ERP как SAP и ORACLE? |
|
01.03.2011, 18:46 | #31 |
Участник
|
Мне кажется, что я сейчас представляю каким образом могла бы быть реализована технология Watermark с заявленными характеристиками. Хочу описать это, чтобы выслушать ваше мнение - какие недостатки этой реализации мне не пришли в голову.
Для начала повторение некоторых моментов, описанных в исходной статье или обсужденных в этой ветке. В основе технологии лежит отказ от принципа регистрации текущих значений остатков в таблице InventSum. Проведение складских операций не сопровождается операцией UPDATE над строкой какой-либо таблицы, в которой хранится текущее значение остатков. Вместо связки InventSum/InventDim для контроля остатков используется единая таблица ImTrans. При этом API модуля логистики меняется лишь минимальным образом. Текущие остатки (и остатки на произвольную дату) получаются путем суммирования по некоему набору строк в таблице ImTrans. При этом fact-sheet подчеркивается Цитата:
Все запросы отбирают лишь очень малую часть данных вследствие того, что строки таблицы весьма эффективно разделены на релевантную и нерелевантную часть без использования сложных индексных ключей, что ведет к непревзойденной производительности.
Непосредственным источником при вставке строк в 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). |
Теги |
как правильно, полезное |
|
|