Kurt Hatlevik: Review of inventory II

[Blog bot]

Источник: http://kurthatlevik.wordpress.com/20...-inventory-ii/
==============

  The company behind the inventory II Inventory II is an add-on module to Microsoft Dynamics AX, that focuses on improving and extending inventory management. Before I look deep into the product, I wanted to take a look at the … Continue reading →

Источник: http://kurthatlevik.wordpress.com/20...-inventory-ii/

[mazzy]

как интересно.
хоть и реклама, но оставляю в тематическом разделе.

что думаете об изложенном подходе?

[mifi]

Цитата:

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

как интересно.
хоть и реклама, но оставляю в тематическом разделе.

что думаете об изложенном подходе?

Пришлось столкнуться с одной инсталляцией Inventory II. Подход интересный, но.. Код и, более того, модель данных по расчету себестоимости у них свои, даже InventSum им не пригодился. Если возникают баги - а они возникают, то без поддержки разработчиков из этой самой FSB пофиксить их проблематично. Если правда, что разработчики FSB разрабатывали Inventory с самого начала, то стабильность Inventory II напоминает стабильность закрытия склада в Axapta 2.1. Так что думайте сами, но лично я бы не решился "truly recommend".

[mazzy]

бог с ними - и с конкретным решением, и с конкретной компанией.

Цитата:

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

Пришлось столкнуться с одной инсталляцией Inventory II. Подход интересный, но..

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

суть подхода, насколько я понял:

Цитата:

So the on-hand transactions are not a single record, but a SUM of the records. The watermark will make sure that you only fetch the latest values when you do reporting. So this solved the issue of the blocking lock when doing postings.

But will this not generate a gigantic table ? The answer is yes, it would, and the heart of the inventory II is therefore a background engine, that will eventually remove ImTrans records that no longer represents any valid data

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

[mazzy]

и еще одно:
а как в invenory II обстоят дела со вводом задним числом?
если ввести проводку в середину, то что будет?

а как вводить накладные расходы задним числом?

[mazzy]

блин, больше вопросов, чем ответов.

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

чистка должна быть очень-очень интеллектуальной. или я чего-то не понимаю?

============================
кстати, на скриншотах нет дат. корректирующие проводки делаются той же датой, что исходная проводка? другими словами, даты у проводок с разными watermark'ами совпадают или не совпадают?

[fed]

Мне вот больше интересно, к чему они эти самые ватерлинии привязывают. К лоту ? К номенклатура+аналитика финансового склада ? Или это как-то совмещено с их квазизакрытием склада, которое периодически архивирует старые данные и, надо полагать,как-то помечает именно те проводки, которые отвечают за текущее состояние склада...

[mazzy]

Цитата:

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

Мне вот больше интересно, к чему они эти самые ватерлинии привязывают. К лоту ? К номенклатура+аналитика финансового склада ? Или это как-то совмещено с их квазизакрытием склада, которое периодически архивирует старые данные и, надо полагать,как-то помечает именно те проводки, которые отвечают за текущее состояние склада...

похоже, некий код транзакции.
похоже, каждая транзакция генерит собственный ватермарк.

[mifi]

Цитата:

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

бог с ними - и с конкретным решением, и с конкретной компанией.

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

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

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

[petr]

Очень хорошая статья. Спасибо за ссылку.

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

Авторы же сделали подобное для склада, отличие в том, что у них процедура группировки и сжатия "старых" данных параметрезирована и работает как служба. Для финансовых итогов (LedgerBalancesTrans) такую функцию надо переодически запускать ручками.

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

Посмотрим, что будет в Dynamics Ax 2012. Может они еще более красивое решение придумают.

[mazzy]

Цитата:

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

Авторы же сделали подобное для склада, отличие в том, что у них процедура группировки и сжатия "старых" данных параметрезирована и работает как служба. Для финансовых итогов (LedgerBalancesTrans) такую функцию надо переодически запускать ручками.

А можно попросить вас рассказать ваше знание?

по-моему вовсе не "подобное".
в LedgerBalancesTrans - инсертятся/сжимаются ИТОГИ!!!
здесь же инсертятся/сжимаются ПРОВОДКИ!!!

здесь суть в том, чтобы от итогов отказаться вообще.

[fed]

Цитата:

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

А можно попросить вас рассказать ваше знание?

по-моему вовсе не "подобное".
в LedgerBalancesTrans - инсертятся/сжимаются ИТОГИ!!!
здесь же инсертятся/сжимаются ПРОВОДКИ!!!

здесь суть в том, чтобы от итогов отказаться вообще.

fed: Ledger Balance Data in DAX

Ты там еще долго упорствовал, доказывая что это вообще итоги. А оказалось что это таки обороты по документу ГК. И только после пересчета периода, они сворачиваются до итогов по счету+дата+аналитика+вид учета.

[fed]

Там переводить не надо, там вот на этой картинке все видно:


Обрати внимание на высоту полосок в двех табличках. В новой табличке, записи старше 182 дней (26 недель) суммированы в одну запись per-day.

[mazzy]

Цитата:

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

Там переводить не надо, там вот на этой картинке все видно:


Обрати внимание на высоту полосок в двех табличках. В новой табличке, записи старше 182 дней (26 недель) суммированы в одну запись per-day.

надо-надо переводить.
как это в "новой табличке", если на рисунке написано "Sold and Purchase transactions older then"?

как это "per-day", если в "новой табличке" дат вообще нет?

[mazzy]

Цитата:

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

В новой табличке

хотя... поверх зеленых столбцов большими буквами написано ImTrans Table.

может быть, вы и правы.

[mazzy]

и все-таки...

можно вопросы понимающим:
1. для того, чтобы вставить сторно в ImTrans нужно знать "предыдущее" значение. а как его получать? делая запрос на "последний watermark"?

2. а что все-таки происходит с "задним числом" при таком подходе?

[fed]

В общем, из текста этого не понятно, но я так подозреваю что они тупо повесили функцию на обновление inventTrans, и каждый раз когда статус меняется, они сначала пишут сторно старого статуса в этот ImTrans, а потом вставляют новую запись. Возможно, они также создают при этом новую ватерлинию.
Еще из интересного, на картинке написано что записи в статусе estimated (onOrder/Ordered) автоматически вычищаются из imTrans спустя какое-то время.
То есть - у них на каждое обновление inventTrans пишется пара записей и новая ватерлиния в imTrans.
Соответственно, для того чтобы получить текущее состояние склада, надо просуммировать все несторнировочные записи с текущими ватерлиниями.
Для того чтобы получить состояние склада на дату из недавнего прошлого, надо просуммировать все активные записи в imTrans на тот момент. (Вероятно они в imTrans таки пишут дату и время).
Еще более интересная фича, мы можем восстановить не только остатки в наличии на дату, но и более интересную информацию - типа сколько у нас было зарегистрировано или запиковано (забыл как это в русском переводе) НА ДАТУ, поскольку эта инфа остается в imTrans с неактивными ватерлиниями

Еще интересная вещь, о которой пишет автор, это разделение Inventory Reservation и Pick Reservation. Правда, он не пишет как это сделано и связано ли это с imTrans. Основная идея (правда я домыслил тут слегка из собственной практики): На ранних стадиях резервирования, когда нам нужно тупо привязать товар к заказу/журналу, нам не нужно знать на какой полке и в какой палетте этот товар лежит. Мы делаем inventory reservation, в котором физическая конкретика не указана. А тогда, когда мы реально собираемся товар собирать и грузить, мы делаем Pick Reservation, которая собственно привязывает резерв к конкретной полке и паллете.
Я кстати, делал на своем проекте одном что-то похожее. Только у нас первая стадия делалась на уровне группы складов (без привязки к конкретному складу). На этой стадии, складские могли возить товар между складами не парясь с проблемой переноса разерва. Потом перед отгрузкой, сейл блокировал этот товар от перемещения и он жестко закреплялся на неком складе, с которого складские его уже не могли увезти (только отгрузить клиенту).

[mazzy]

Цитата:

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

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

Гы... Прикольно.

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

Что ж, интересный подход - скорость в обмен на надежность.
хотя может быть они прямо в SQL-триггера код пишут...

[mifi]

Цитата:

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

Гы... Прикольно.

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

Что ж, интересный подход - скорость в обмен на надежность.
хотя может быть они прямо в SQL-триггера код пишут...

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

[fed]

Цитата:

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

Гы... Прикольно.

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

Что ж, интересный подход - скорость в обмен на надежность.

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

А говоря насчет supportability то напомню участникам дискуссии что:
1. Софт поддерживается авторами, а не нанятыми индусами из Sonata Software. (Кстати - завтра еду к клиенту, у которого индус НЕДЕЛЮ лечил падение сервера, заставляя его ставить разные значения в размер буфера БД в AOS. Перепробовали около 15 разных волшебных значений - не помогло).
2. Какая принципиальная разница между этим решением (с виду довольно продуманным) и всеми этими, прости господи, вертикальными решениям партнеров MBS? Сравни то что мы видим здесь и то что в России получают клиенты, покупая "зарегистированное вертикальное решение".К слову сказать, тот же микрософт счас пытается ISV-партнеров продвигать. Чем тот же FSB-Development не ISV-партнер ?