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

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

Чего уж проще :)
Но, я не занимался складскими системами, и тут вижу разные варианты.
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в общем, всё намного проще сделаю...покажь...
Угу, сегодня "проводки" прикручивал (скорей фискальные логи). Покажу.

ViPRosинтересно, на основе чего материал со склада отпускается?
и кто гарантирует его наличие на складе в нужный момент?
Конечно есть кладовщик, и конечно она пишет.. Но, первичка для неё - записульки мастера (на бланках), который фактически и работает (приём-отдача) с материалами, кладовщица работает в день и 5 дней, производство не прерывное. Кладовщица работает с КИС (SAP R/3), пока никаких подвязок с сапом нет.
---------------
В общем, простой вопрос об вариантах организации складского учета расширяется )