villager писал(а): ↑16.03.2010 23:53
Sanchess писал(а): ↑15.03.2010 16:27
Я даже составил примерный список таблиц БД.
стоит предусмотреть справочник для классификации документов
тот же приход может быть:
от поставщика за деньги
на комиссию
возврат товара из гарантийного ремонта ...
расход:
продажа
возврат товара поставщику
передача для гарантийного ремонта ...и т.д.
как вариант - из шести таблиц (шапки документов+движение товара по ним) - сделать две.
1) шапка документа (содержит код документа, определяющий вид приход-расхо-внутреннее перемещение)
2) движение по документу (количество с минусом - для расхода, с плюсом - для прихода)
в этом случае остаток по любому товару на любую дату определяется простым суммированием количества
ну и таблицу с резервом тоже можно убрать, добавив в шапку документа признак резервирования
то есть можно будет видеть реальные остатки (без учета резервирующих документов), так и виртуальные - (с учетом резервирующих доков - а хватит ли товара, если все резервирующие накладные станут реальными)
Не поддерживаю.
Структура потеряет прозрачность, некоторую долю управляемости.
Для программиста/поддержки начнется ад.
Документ должен быть максимально прост, его данные должны быть отделены от его движений.
У меня много объектов в управлении и если бы я следовал этой логике, я бы сбрендил....
Особенно бредовое предложение: справочник для документов. Каждый документ сам по себе означает оддельную операцию или классифицированное подмножество. Многие документы имеют одинаковые движения, например:
Оприходование товара:
- Приходная накладная
- Возврат от покупателя;
- Оприходование излишков;
- Внутреннее перемещение;
- Прием в ремонт;
- Прием на комиссию;
и т.п. большинство этих документов делают не только оприходование товара.
Тем самым при добавлении документа вам придется переделывать все товарные отчеты, если перенесете хранение движений в документ, а не отдельно. И это только одна "Беда" которая вас ждет в случае принятия такого рещения.
Другая беда состоит в том, что вам придется делать все табличные части документов универсальными (т.е. добавлять избыточные атрибуты) и учитывать "знаки операции"-плюс и минус находу в зависимости от вида обрабатываемого документа.
Короче для простой и неизменяемой системы предложение может прохлять, но если систему планируется развивать, то не рекомендую...