Kurt Hatlevik: Review of inventory II

[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-партнер ?

[George Nordic]

Цитата:

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

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

Угу. Уже проходили. Помниться, есть даже ряд решений по закрытию склада Средствами SQL...