Hi All!
Занимаюсь с коллегами строительством очередной софтинки, претендующей на звание ERP. И возникла у нас междусобойная дискуссия про партионный учет. Борются две основные версии :
1) Достаточно построить динамический LIFO или FIFO, который просто вычисляется с некоторой периодичностью полностью и заново, на основании первичных данных (котрые заказчик с энтузиазмом великим правит задним числом)
2) Построить достаточно инеллектуальный мех-м, который по сути являлся бы учетом товара в разрезе характеристик , запретить заказчику править первичку задним числом и получить все профиты причитающиеся как следствие вычислений в момент внесения данных.

С моей точки зрения правилен и единственно возможен 2-й вариант, но может просто я ничего толком не понимаю в вопросах ERP-строения? Что скажете ?

P.S. sorry , если где-то уже есть такой топик.

2mazzy : Видимо я не очень четко выразился, говоря править я имел ввиду совершать разного рода UPDATE с данными проведенного документа. Более того , я сторонник политики при которой данные только добавляются (как данное я полгаю в данном случае атомарную операцию с ТМЦ), если надо изменить данные, то я считаю необходимо не сторно для ошибочной транзакции , а новая операция полностью аннулирующая, ту для которой надо выполнить сторно, а затам заведение новой правильной транзакции. Внесение данных задним числом, т.е. создание транзакции с датой раньше как минимум на один календарный день, чем текущие транзакции, ни в коей мере не противоречит концепции распределенной обработки, т.к. данные с удаленного сервера могут попасть в консолидированную базу с существенной задержкой.
Кроме того у первого варианта есть самый главный на мой взгляд минус : что делать с трансакциями, которые в результате построения FIFO напр. оказались НЕВАЛИДНЫМИ ? Есть и другие минусы : напр как быть со сроками хранения ?

2 Roman V :
Некоторое время назад автоматизировали крупную алогольную компанию.
Какая ситуация на сегодняшний день точно не скажу, но тогда было так:
1- Крупная поставка одной партии можт происходить в течении нескольких дней, напр. 10 фур одной водки, по одному договору, оплаченные разом, из одной заводской партии.
2- При выписке документов было просто необходимо указывать конкретную партию, т.к. поставка сопровождается сертификатами и разного рода спецификациями, где перечисляются акцизные марки на бутылках.
3- Естественным образом следует из 2-го

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

С моей точки зрения существует два вида бизне процессов :
1) когда ТМЦ строго сериализуются (ГТД/Сертификат/лицензя/срок годности и т.д.)
2) ТМЦ не сериализуются или это не принципиально для заказчика.

во 2-м случае вполне достаточно ФИФО/ЛИФО и даже при возврате ТМЦ можно его нарушить, не нарушая /* =0) */ , т.е. вернуть товар в самую последнюю партию, где была хоть она продажа или просто сздать новую партию с ценой продажи. Но, если возникает вопрос типа: "Мы торгуем куртками, а тут одну покупатели потоптали и ее надо уценить" - автоматически возникает задача идентификации ТМЦ вплоть до конкретного объекта.
Я знаю примеры из реальной жизни, когда кассир пробивает "№ чека, цена, кол-во", а клочке бумаги пишет : продано "то-то по том-то", а в конце дня специально обученный человек, ассоциирует выгрузку из той кассы, при помощи этих бумажек с учетной задачкой, с помощью нетривиальной тулзы, т.к. ассортимент у той фирмы ок 10000-15000 наименований . Оператор этот получает 200 у.е. в мес. или 2400 у.е. в год, а для фирмы в целом * 12 магазинов = 28800 у.е. в год. Вся эта :?;%:; оправдывается тем, что у них очень сложные бизнес-процессы, но мое мнение, что у них слабые программеры, которым просто страшно перейти на механизмы ведения учета в разрезе ПРОИЗВОЛЬНЫХ характеристик товара .
Я полагаю так: если задачка достаточно тривиальная, или ее пишут студенты, то действительно, достаточно построить надстройку из 3-х табличек и заполнять ее ночью по ФИФО/ЛИЛО и етц., а днем смотреть отчеты за прошлый день, что вполне жизненно, а если еще ввести закрытие периодов, то будет совсем хорошо.
НО.
Эта система категорически неспособна работать с такой конструкцией как брак. Пример: Есть фирма, которая закупает напр. стиральные машины с браком контейнерами и после сдувания пыли продает их из своего сервис-центра за реальные деньги. Им надо оценить эффективность продажи как контейнера в целом(тут годится простое ФИФО), так и понять с какими повреждениями и за какие деньги люди раскупают хлам быстрее( т.е. надо идентифицировать каждый объект персонально с учетом его характеристик).
Одновременно они продают стиральные порошки, и вот тут их идентификация конкретного мешка не интересует вообще.Но с другой стороны, если система автоматически обеспечит достоверную партионность, то можно в частности проанализировать эффективность работы с конкретным поставщиком(перестраиваемое ФИФО для этого не годится категорически).Оговорюсь, что для получения предметной партионности с порошками, у фирмы должно быть что-либо типа сканеров штрих-кода(чтобы различать мешки).

Мое мнение таково : Если строится продукт, который хочется продать больше одного раза, просто небходимо строить конструкцию, которая позволит вести учети учет в разрезе характеристик товара. Другой вопрос, что система должна сама строить ФИФО (напр.) где-то на заднем плане по умолчанию, но когда требуется сериализация надо давать возможность оператору влиять на план предлженный системой, причем разбиение на конкретные учетные единицы может происходить на разных этапах жизненного цикла документа.Напр. я могу пойти на склад фирмы и отложить конкретный товар, что бы завтра мне его отгрузили(напр. те же стир.машины разной степени убитости).
"Все украдено до нас". Примерно так сказали ребята из IBM, которые написали книжку IBM WareHouse. Их версия хранилща всасыват определнный набор данных из OLTP DB, причем если это будет даже очень красивое ФИФО, то данные эти будут бессмысленны.