Доброго времени коллеги.
Дабы не открывать новую тему.

Есть необходимость организации простого складского учета («простой» - приход, расход, остаток.).
Поля:
«приход»: дата прихода, материал, количество, участок
«расход»: дата расхода, плавка, материал, количество, участок
«остаток»: материал, количество, участок

Чего уж проще :)
Но, я не занимался складскими системами, и тут вижу разные варианты.
1. как показано, но «остаток» это вьюшка – как разница между приходом и расходом. Смущает выборка в последствии – надо будет как минимум искать критерий отбора, что бы не сканить всю таблицу (ы). Имхо, на больших объемах не есть правильно.
2. та же схема, но «остаток» - таблица, корректируется триггерами при приходе/расходе.
3. варианты?

Мне надо привязать расход материалов в производстве, списание в автоматическом режиме (робот в системе АСУТП). Поступление – ручной ввод. Получение остатков и т.д. необходимо для отчетов и планирования.

Если есть мнения – буду благодарен за комментарии.

ОзверинБеда в том, что от тебя хочет бизнес.

Хотелка номер 1:
бизнес хочет динамику остатков на складе.
Пока движения у тебя немного , то это можно динамически рассчитывать, но как только данные копятся годами, возможно располагаются уже по разным таблицам, то динамический расчет может скромно уступить место понятию "Проводка".

Проводка - печальный факт большинства складов.
Суть:
есть таблицы

--------------------------------------
Примитвно так выглядят:
движениеТовара(отКого, Кому, ТипОперации(расход, приход), Товар, Кол-во, Дата)

остатокНаДату(склад, товар, кол-во)
остатокНаПоследнююДатуПроводки(дата, склад, товар, кол-во)
--------------------------------------

Почему 2 таблицы? Можно, в теории и 1, но кол-во записей в ней все равно будет рано или поздно безумным. Можно ввести партицирование, допустим, как в постгри. Кто как хочет, так и занимается ерундой.

И соответственно, в основном документы работают с таблицей текущего остатка.
Материалы не перемещаются, они расходуются.. :)
Есть два участка, на которых идет выплавка и доводка стали, для определенной марки стали требуется алюминий (проволока), известь и т.д. - разные сыпучие материалы.
Сегодня мы отслеживаем расход материалов на ед. продукции (в самой продукции), но требуется вести учет с точки зрения склада участка.
Возможно по приходу и понадобиться поставщик (это не критично сейчас), по расходу - только дата, материал, количество и какая плавка (номер).
О проводках наверно говорить не приходиться, пока не вижу смысла, хотя, прикрутить конечно можно :)
В общем, немного поковыряв сделал модельку..
Склад_ост2. Все операции проводятся при помощи не триггеров, а процедур. Процедуры же меняют таблицу текущих остатков.
(ИМХО) Замечание что всё делается в процедурах - верное отчасти. В процедуре можно реализовать логику. Но, неизбежны (точнее, возможны) коллизии связанные с нарушением целостности и противоречивости данных. Например: меняем остаток на складе материала, но в приходе и расходе не отражаем, или в приходе, или в расходе.. Транзакция не атомарная в этом случае, если она минует процедуру.
Я пока использовал и триггеры и процедуры:
// добавление нового материала
// изменение количества

В схеме отсутствуют не существенные поля.

Блин, не всё так гладко.. :(
Если удалить запись из «приход», то, вроде по логике надо корректировать и склад.
Но, если приход был месяц назад, и склад по данному материалу уж дважды наполнялся, то по сути, тот «приход» ну никак не влияет на текущий склад. С другой стороны, расход – это факт, и если он был, значит материал был на складе, корректировка прихода не может влиять на уже совершенный расход.
Но, если запись прихода ошибочна, её надо удалить и следовательно внести корректировку в склад (текущие остатки).. Мда.. Логистика есть оказывается наука, или я усложняю всё.

Dinamo...А еще бывает что материалы возвращают поставщику...
Да, да.. У меня сейчас и встала проблема - редактирование данных: изменить количество, удалить.
И что интересно, не требуется (и ой как не хочется) делать полноценную складскую систему.
Требуется:
Мастер вводит поступление материалов на участок.
Автомат (нижний уровень - контроллер) формирует список и количество материалов которые вошли в продукт, это и есть списание со "склада".
Диспетчер видит расход и остатки, кладовщик видит остатки но оба они уже ручками заносят в КИС (SAP R/3).

LUCIANВ моей программе(проекте) мастер не вводит поступление материалов , а получает автоматически на основании расхода со склада в цех

Дак, у него и есть тот самый склад. Если смотреть глобально, конечно откуда то везут, но нет возможности настолько глобально автоматизировать Приезжает машина, откуда - в данном случае не важно, и разгружает материал в бункер. Мастер должен записать что и сколько.
Возможно, он запишет не верно, возможно материал бракованный (но, что бы его выгребали из бункера - не припомню). Требуется корректировка к операции ввода.

LUCIANДля автоматического списания материалов в цеху в проекте предусмотрен справочник материалов по технологии,при этом каждому материалу(коду) из складского справочника материалов поставлен в соответствие материал(код) из справочника материалов по технологии
Справочник норм расхода материалов на изделия построен на основании справочника материалов по технологии
Да причем тут справочники? У меня есть схема НСИ, есть еще схемы, в работе порядка 400 таблиц, я что, все их должен приводить???
Понятно что целостность данных обеспечивается и машина с кодами работает а не словесными описаниями.
Если обратили внимание, схема называется TEST...

Сейчас думаю как организовать учет, и сложность не в его организации, а в операциях корректировки (не хочется употреблять сторнирование и т.д.). Как обеспечить баланс - склад, приход, расход, отсюда видать и структура должна строится, или, таки действительно всё чисто на процедурах.
На самом деле, я никогда не занимался складским учетом, отсюда и недоперепонимание.

Bogdanov AndreyПростейший вариант можно и триггерами - добавили приход, увеличили остатки, удалили приход - уменьшили остатки. С расходом аналогично.

Это первое что я сделал :) И если бы не реальная задача - всё отлично.
Bogdanov AndreyПравда в такой схеме может оказаться, что остатки в минус уйдут, но если корректировки задним числом требуются, то промежуточных минусов не избежать.

Вот, тут и начались вопросы.. Где определить то самое "заднее" или "переднее" число? Смысл:
1. Требуется посмотреть сколько осталось алюминия на участках, SELECT ** и всё.
2. Требуется посмотреть сколько расходовали алюминия, аналогичный селект ну и все остальные запросы по расходу - выполняется.
3. Требуется посмотреть сколько было загружено на склад алюминия, в первом приближении простой агрегированный запрос - работает. Но, тупо "сколько" не имеет смысла, спрашивают "сколько в мае" или за период а вот тут и начинаются траблы. Если без привязки к факту (расход, остатки) то вроде нормально. Но, если расход в мае был 30 т. а приход окажется 28 т. и остатки 60 т. баланс не сведется. Если вести корректировку за май: с мая трижды наполнялся склад, в "складе" нет даты, есть только материал и его количество. Если "убавить" приход на 50 т. то, эти же 50 т. снимать со склада нельзя. И еще, в мае приход был 50 т. но, эти 50 т. могли расходоваться 4 мес. а могли и за неделю, по периоду не привязаться.

Где границы "заднего"..? Редактирует/вносит человек данные, сохранил (склад изменился), возможно, пока он пил кофе, уже часть материала взято в производство. Вдруг он перепроверяя цифры обнаруживает, что не 8 т. а 6.. Надо корректировать. Разница "через 15 минут" и "через 15 дней" для редактирования отсутствует.

Блин, может, действительно гарантировать только "склад" и расход, а вот "приход" это чисто фиксация операции не более? Есть же бухгалтерия, там точно есть "сколько и чего". Потому что, без полноценной системы я пока не вижу ответов, а полноценная система не нужна.
Bogdanov AndreyНу а брак надо не корректировкой прихода выполнять, а отдельной операцией фиксации брака.
Спасибо, действительно это надо учитывать отдельно.
LUCIAN....
Спасибо, Ваше предложение интересно, но у нас несколько разные бизнес-логики. Я не могу сказать чего и сколько однозначно должно пойти на тот или иной продукт (недетерминированные процессы), а в расходе нет сложности - расход давно работает. На вашей форме показаны остатки (склад) и расход - это у меня есть.

В процессе вульгарного распития чая, найдено решение - операция "списание" и "проводка"..
Думаю, это простой выход.

Bogdanov AndreyЯ правильно понимаю, что в операциях "прихода" и "расхода" у вас даты нет? Вы все операции текущим временем выполняете?
Нет конечно. Смысл тогда городить?
"приход": ид_прихода, дата, ид_склада, количество
"расход": ид_расхода, дата, ид_склада, количество, участок
"склад": ид_склада, ид_материала, количество, ид_участка

фактически, ид_склада даёт нам и материал и участок.
В общем я сделал, конечно не есть правильно с точки зрения нагрузки, но обошелся без лишних сущностей. Всё базируется на процедурах и тригерах. Сейчас стоит вопрос сохранения логов транзакций - кто, когда и что менял (старое значение, новое, причина, владелец записи, хост, ссылка на ид ведомости прихода), но это не вопрос, это "пара минут" .

Вопрос сведения баланса стоял для, например: за май - сколько пришло и сколько расходовали. В условиях возможности редактирования "задним" числом, возникали сложности.
Сейчас вроде всё работает (в первом приближении).

Bogdanov Andrey...
Поясню..
Сейчас есть система которая полностью отслеживает всю технологию производства стали, наряду с прочим, формирует так называемый "паспорт плавки" где в том числе указывается и расход материалов.
Исходя из этого, сделать аналитику "по факту" элементарно. Но, в производстве возник вопрос по потерям.. "Вроде было 5 т. материала ХХХ", по паспортам ушло 4 т. где остатки? Ну и аналогичные вопросы..Как то - ну а сколько еще есть (даже если лазить в бункеры, сказать сложно) и т.д.

Конечно, достаточно было бы просто добавить "склад" без операций расхода (расход и так фиксируется) - это кстати, вариант раздумий.. Я пока делаю модель, надо обкатать её что бы добавить в продуктив - там и так хватит телодвижений, что бы добавить "незаметно" для существующей системы.
Когда я начинал строить систему, задача была гораздо проще Но до сих пор её развитие идет в условиях нечеткой логики (у технологов нет опыта в новой технологии и следовательно, алгоритмы приходится строить набегу).

в общем, всё намного проще сделаю.
Спасибо всем за проявленный интерес.

ViPRosинтересно, на основе чего материал со склада отпускается?
и кто гарантирует его наличие на складе в нужный момент?
в оперативном управлении на основании "ничего"
Просто, ПТК (машина) строит рецепт, технолог (человек), видя реальную ситуацию (химия, физика) делает корректировку к рецепту, машина (ну, или человек с лопатой - зависит какой материал) закидывают должное количество из [бункер, рулон проволоки и т.д. ]. Материалы поставляются на основании плана (месяц) и этот план весьма приблизителен. Потом, в конце месяца ответственные лица методом точного глаза делают инвертированию. Такое состояние дел не даёт точную картинку, и уж точно не может в каждый момент времени ответить на вопрос(ы) "сколько" - "что". Вроде немного устаканилось с бункерной системой, тут же появилось желание хоть как то привести в порядок.
В системе заложено это, точнее, есть затычки на этот случай
При проектировании системы, умышленно избегалось любое упоминание финансовой или иной бухгалтерской отчетности и документов, думаю, не стоит 2-3 уровень привязывать к деньгам - только технология. Для бухов и т.д. есть другой софт, в том числе SAP R/3.
Потому, выявляются нюансы, которые приходится обходить, которые бы не возникли если бы была полная цепочка...
ZezaMstells2в общем, всё намного проще сделаю...покажь...
Угу, сегодня "проводки" прикручивал (скорей фискальные логи). Покажу.