Необходимо спроектировать БД для складской программы (складской учет в ресторанах).

Должны быть реализованы три типа списания: LIFO, FIFO и AVERAGE.

Может кто сталкивался с аналогичной задачей?

В данный момент есть таблица товаров и документов (приход, расход, вн. перем.).

Товары:
Id, Код, Описание, Ед. изм., Категория, Ставка налога и т.д.

Документы:
Id, Тип документа, Дата, Поставщик, Получатель, Склад (куда), Склад (Откуда), Товар, Кол-во, Цена

Вопрос: Как лучше спроектировать БД, чтобы реализовать быстрый расчет себестоимости, при том, что документы могут изменяться задним числом.

Я хочу, чтобы себестоимость расчитывалась на момент сохранения документа и сидела в базе. Чтобы потом можно было быстро сформировать необходимые отчеты.
С AVERAGE всё понятно:

После сохранения документа записываем в какую-нибудь табличку данные:
Id Документа, Id Товара, Id Склада, Остаток на складе, Сумма остатка, Себестоимость.

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

А вот как быть с FIFO и LIFO? Нам придется запоминать сколько товара и по какой цене у нас осталось. Не представляю как это будет выглядеть.

Может кто-нибудь консультантом хочет поработать? (Москва, ВДНХ)

Что значит закрой Delete и Update?
Представь себя на месте бухгалтера, если ты обнаружил ошибочку в документе, который три недели назад забили.
Что будешь делать, переустанавливать программу и данные с начала года забивать?

zassДа, но если, например, Вы поставили неправильно складские цены и две недели у Вас уже отработал ресторан - ВОПРОС: Как Вы работаете с налоговой инспекцией?????????????????
Я так понимаю, что документы как раз правят, чтобы перед налоговой отчитаться в конце месяца. Ведь бухгалтер полезет документы проверять и править, когда у него суммы не сойдутся. Иначе нахрена кому-то в эти документы лезть...

Николай МВ
А вот это уже называется партионный учет -- немного сложновато, но вполне реализуемо. Запоминать сколько товара и по какой цене осталось необязательно -- это можно просчитывать. Впрочем можете и запоминать -- как Вам больше нравится.
Т.е. любой товар у вас будет разбит по партиям:
Редиска 10 кг по 5 руб. -- партия № 1, дата
Редиска 15 кг по 4 руб. -- партия № 2, дата
Редиска 5 кг по 6 руб. -- партия № 3, дата

И продаваться будет не просто редиска, а редиска из определенной партии, по определенной цене. Вообще-то это точнее и правильнее, чем AVERAGE. Но в случае изменения документов задним числом, придется последующие пересохранять (не все).

Вот-вот, совершенно верно!
Партия - это то, что пришло по одной приходной накладной, правильно?
Т.е. номер партии - это фактически номер документа.

Вопрос в том, какая при всем этом должна быть структура БД.

Если у кого-нибудь есть опыт написания подобных проектов, хорошее знание предметной области и опыт работы с ресторанами, то мы можем предложить постоянную работу в качестве продакт-менеджера или в качестве консультанта.
Продукт будет "коробочный". Реализован на MS SQL + Sybase PowerBuilder (знание PowerBuilder-а не обязательно).
С компанией можно ознакомится на сайте (адрес указан профайле).
Резюме на e-mail (в профайле).