Kurt Hatlevik: Review of inventory II

[mazzy]

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

насчет того, что и стандартный подход можно развалить - согласен.

[vc]

Вебкаст очень интересный.
В принципе лектор в самом начале говорит, что технические детали он освещать не будет, но все же два архитектурных момента там проскочили.
Первое, описывая систему резервирования, где то на отметке 1 час 12 минут вебкаста:
В складские проводки добавлены "системные" складские измерения лот прихода и дата прихода.
Каждая расходная проводка непосредственно связывается с лотом приходной проводки - в вебкасте показывается как это происходит при обработке отборочной накладной по заказу. Уже на этом этапе - до обработки накладной в проводке можно посмотреть сопоставление (открывается форма с текущей проводкой, и сопоставленной ей приходной) и будущую себестоимость.
В сочетании с постоянно работающим в фоне пересчетом и закрытием склада, таким образом наверное можно добиться того, чтобы число открытых проводок в ImTrans, по которым формируются значения текущих складских остатков было относительно небольшим.
Второе, где то на отметке 1 ч 30 минут лектор описывает возможность расчета сводного плана на фоне активной работы пользователей. Речь идет о том, что результат такого расчета был бы несогласованным при стандартной реализации: Допустим расчет идет один час (условно говоря с высших уровней иерархий спецификаций вниз по компонентам), в течение этого часа меняются и остатки по спецификациям и по компонентам и т.д. Решение - в момент запуска расчета сводного плана снимается снэпшот остатков. А технически - в момент запуска расчета запоминается наибольший на данный момент watermark, и в расчете плана не учитываются никакие проводки с watermark с бОльшими значениями.
По моему это подтверждает гипотезу о том, что watermark это просто монотонно увеличивающиеся идентификаторы транзаций типа - сторнировали предыдущее значение инвенттранса, записали будущее значение инвенттранса.

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

[George Nordic]

Цитата:

Сообщение от vc

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

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

С Уважением,
Георгий

[vc]

Цитата:

Сообщение от 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?