Доброго времени, коллеги.
Подскажите возможные варианты..
Требуется организовать «склад». Учета материалов.
Вот примерный вариант:
"склад""накладная""ведомость" код склада код накладной код накладной материал дата материал количествокод складаколичествокод операции (приход; расход; перемещение и т.д.)кладовщик
склад – это по сути текущее остатки (состояние склада)

Далее «накладная» - это группировка для ведомости. Ну и зависимая от накладной «ведомость» - по сути, расшифровка содержимого накладной.

В общем то, выстроить логику не сложно – формируя ведомость обновлять склад..
Вопрос в другом:
Требуется отображать данные в виде:
Дата Склад материал на начало приход расход остаток на конец.

Вот тут я задумался.. Имея текущее состояние склада мы не имеем его историю, ответ на вопрос «что было со складом хх числа хх года» уже не так тривиален, потребуется перебирать таблицы движений (накладные + ведомости), не уверен что это есть хорошо в условиях большого количества записей.
Думал создать избыточную таблицу как просят Дата Склад материал на начало приход расход остаток на конец.
И писать её при движении материалов, но, такая таблица даст данные только на те даты, в которых было движение и то, по тем материалам по которым было движение.. Ну и вопрос «а когда её заполнять, если нет движения.. повесть задание на 12 ночи»?
Требуется:
датаскладматериал ост.на начало приход расход ост.на конец20/05/2010 0104-1 0005689 150 50 30 17021/05/2010 0104-1 0005689 170 0 0 17022/05/2010 0104-1 0005689 170 40 0 21023/05/2010 0104-1 0005689 210 0 50 160
Т.е. показать на любой период/число наличие материалов не смотря на их движение
Может кто вариант предложит?

я понимаю что есть отдельная ветка "проектирование БД", но тут вопрос не столько в организации БД, сколько в реализации на Orаcle.

По сути, можно обойтись и одной табличкой - "ведомость" и из неё вытащить всё что надо и на когда надо, вопрос в эффективности такого подхода..

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

Ramin, спасибо, полистаю.
просто сейчас вот подумал, а не добавить ли в "ведомость" поле "остаток на начало"..
При формировании ведомости, можно подтягивать остаток.
Это даст, имхо, много удобства..

Raminв чем сложность реализации? на дату проведение транзакции смотришь, если есть запись уже на эту дату обновляешь если нету обновляешь date_to на дата транзакции-1 и вставляешь новый с date_to = 31.12.3000
не очень понял со второй датой..

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

У мнея нет опыта в этом плане, и считаю что "хитрый" запрос, формирующий (пусть и в матвьюшку) неоходимые данные весьма тяжелый.. Дело не столько в нагрузке на сервер, там вроде есть ресурсы, сколько реакция приложения на действия пользователя...

Или, это в общем то нормально, и можно позволить это?
Просто, SELECT * FROM TBL - для рабочей бд мне кажется крайне жестоким и не допустимым, а тут, фактически перебор пойдет каждый раз от начала и до конца...

suPPLerФизическая модель всегда опирается на логическую. А у Вас пока и логической нет.

Сделайте две таблицы: остатки на закрытие дня и остатки на текущий день. Чтобы получить информацию на начало дня, достаточно глянуть, как закрылся прошлый день. Чтобы увидеть движение товара, достаточно информации на начало дня и накладных за день. Подход избитый и банальный.

Это лучше обсуждать в Проектировании БД.
да понял что в "проектирование БД" бежать надо..
Смена 8 и 12 часов.. взависимости кто смотрит, кто-то смотрит по утрам и требует остатки на 8 утра (с 8 утра прежних суток). Как такового "закрытия" нет. Производство круглосуточное.
Расход, наряду с кладовщиком, списывается и в автоматическом режиме системой (САУ).

логика.. гм, а как вы думаете я добрел до чисто практических вопросов? Не было бы логики, эти вопросы и не возникли бы, модель была построена и учитывала всё, как оказалось почти всё..
И даже начала работать, пока не появились "глупые" вопросы, о которых раньше и не подозревали.
Этот вопрос только часть...

ну и.. Oracl налагает ограничения которые надо учитывать - я немогу в тригере сама себя смотреть и/или что-то делать..

Raminstells2ну и.. Oracl налагает ограничения которые надо учитывать - я немогу в тригере сама себя смотреть и/или что-то делать..
с таким опытом я думаю вам пора рано писать систему складского учета
спасибо за мнение..
"не могу" не значит "не умею"..

suPPLerАнализируйте бизнес-процесс. При окончании смены должны быть сдача-приём остатков, этот документ и можно отразить в таблицу истории остатков. Если на практике такого документа нет, это не означает, что он не был заложен в порядок дня. Скорее, это будет свидетельствовать о том, что на производстве бардак. При автоматизации бардака получится не порядок, а автоматизированный бардак. Так что придётся в тесном сотрудничестве с заказчиком наводить порядок, а потом уже отражать это в Вашей системе.
Ваши слова до бога уши..
Бардак нельзя автоматизировать, верно.
Есть кладовщик, работает "в день" но, материалы списываются круглосуточно, и прийти могут в любое время - в зависимости от участка приход/расход оформляет мастер/бригадир. Потом, днем, кладовщик "подбивает бабки".. А утром, с 7 до 8, уже куча желающих посмотреть как прошли сутки/смена (как говорил, у каждого своя - 8, 12 часов)...
Насчет бизнес-логики согласен, копья уже поломаны пачками..

В общем, пока у меня работает так: при проведении проводки, я завершаю транзакцию после корректировки склада и "состояния склада" (было пришло ушло осталось).
Это даёт удобство в работе и не нагружает систему и тормозит приложения.
Но, меня это не устраивает + добавились требования, переписываю по новому, отсюда и вопросы..

stells2Это даёт удобство в работе и не нагружает систему и тормозит приложения.

описАлся
Это даёт удобство в работе и не нагружает систему и НЕ тормозит приложения.

suPPLerЯ не против того, чтобы возглавить изменения в бизнесе заказчика, если он согласится с моими требованиями и предложит адекватное вознаграждение.
Заказчик почти со всеми требованиями соглашается, за исключеним тех, с которыми он не хочет соглашаться например, в части планирования, ну не хочет он что бы ситема планировала..
Вот и тут, приходится находить компромисс с уже существующими процессами, и так сломано старого много.

Модератор: Тема перенесена из форума "Oracle".

_мод1. Хранить текущий остаток и от плясать
2. Хранить все остатки на дату(ежедневно или ежемесячно и т.д) и от них плясать
Оброты всегда считать за период

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

LSV3. В отдельной таблице движения хранить все обороты (в удобных единицах).
В отдельной таблице хранить сальдо на даты закрытых периодов.
Остаток на дату считать как
сальдо на ближайший закрытый период + обороты от этой даты до искомой.
Удаление первичного документа всего лишь удаляет обороты из таблицы движения.
Вот и появилась таблица "склад" - текущие остатки и "состояние склада" - движение на дату
склад дата было пришло ушло осталось


stepplerusЯ тут в 1С подсмотрел интересную идею.
Они пересчитывают остатки сразу при проведении операции.
Но! Хранят не одну запись об остатке, а несколько.
То есть, пытаются изменить текущую запись, и, если она заблокирована, то создают новую, которая отличается от текущей только, условно говоря, номером. Для получения полного остатка нужно сложить все записи на одну точку фиксации.
Если транзакции будут не очень длинные, то количество записей об одном и том же остатке должно быть не слишком большим. В любом случае - меньшим, чем число транзакций, которые этот остаток изменяли.
Честно признаюсь - сам такую схему не использовал и на практике не видел.
У меня именно так и организовано, не думал, что 1С подсмотрит.. ;)
Я транзакцию веду во временных таблицах, при явной (по кнопке) фиксации происходит перенос в постоянные, при этом делаются проверки дубля и рождаются ID-шники, но, проводка будет не закрытая пока её не закроют, кстати, совершенно неважно во временных или постоянных таблицах находится - незакрытая проводка материал покажет, но в работу не пустит, а закрытая уже не даст возможность корректировки.
Отличие от постоянных в том, что временные - сессионные.
Это сделано в первую очередь для удобства работы с шаблонами (множество материалов) или при отпуске/приёма на/с др. склад - и телодвижений кладовщику меньше и есть контроль наличия и количества материалов... Хотя, это так же не блокирует работу при одновременном доступе...

В общем, вижу что мысли совпадают..

Всем огромное спасибо за конструктивные мнения!

тогда вопрос, когда и как лучше организовать заполнение "состояние клада"
(дата, склад, было, пришло, ушло, осталось)
что бы не было пробелов в датах?
Понятно, что когда есть операции прихода/расхода - таблица заполняется, ну, или когда смотрим её на дату..
А вот если, наример, на выходных не было прихода/расхода, и мы хотим посмотреть пятница-вторник.. движения и остатка материала (ов) на определенном складе?

_модstells2остатками могут корректироваться при ревизии и тогда отличаться от расчетных.
Ревизия - это тоже бух. операция. Т.е. факт и бух. остатки - это одно и то же.
наверно, просто сейчас так:
бух. остатки - это расчетное между приходом и расходом.
Но, материалы разные, не штучные - там не довешали тут недосыпали а есть расход "лапаты".. (не, такой еденицы конечно нет но отдать могут и в лапатах, учет конечно в тоннах).. и в конце недели может появиться "+" или "-". Т.е. это вносится вручную "корректировка".
В проводках так же отображается эта операция (система определяет сама - минусовая или плюсовая проводка).
Так вот, требуется форма, которая бы отображала эти две величины - плановое (бух) и фактическое и разницу (точнее, дельта и нужна).
Потому, я учитываю фактическую массу а бух - рассчитываю.

сейчас с заполнением решил - повесил задание на 12:05 ночи.. мержуется состояние склада по складу.

ViPRos, да, примерно так
сама форма (GUI) есть, имелась ввиду форма / формат вывода. ;)

В общем, пока остановился и может надолго по сл. Схеме: (одна, первая версия работает давно уже)
1. «Движение» материалов – операции (приход [внешний, внутризаводской], расход [отпуск на сторону, технология], перемещение [приход/расход]) с датой, складом и т.д. и т.п. – в соответствии с нормализацией.
2. «склады» - текущие остатки, избыток конечно, но он компенсируется снижением сложности обработки
Почему так не спеша?
Дело в том, что расход пишется и всегда писался автоматически, и корректируется на участках в АРМах.
«Бухгалтерия» ведется в SAP, и мне до сих пор не очень понятно зачем делать промежуток нагружая людей лишней работой.. Но, было требование - что надо кроме расхода видеть и остатки (в виде «пришло/ушло/осталось») на участках. Сами участки это склады, которые получают материалы либо с центрального склада либо от внешних поставщиков непосредственно (машина/вагон)..
К тому же, внутренний учет материалов ведется по внутренним кодам, которые есть «расщепление» номенклатурных бухгалтерских номеров – что так же вносит хаос, я и так при проектировании системы, еще не зная что возникнет такая необходимость учета, заложил цепочку которая позволяет прозрачно все учитывать, но накладки есть:
Пример: приходит группа материалов по докам в номенклатурных № SAP.. но в бункерах учитывается внутризаводские названия, т.е. например выгруженный в бункер лом 3А 100 т. может легко превратится в 3 других лома (20т./40т./40т.) которые технологи обзывают по своему (связано чисто с технологией а не с хотелками), кладовщица спрашивает – «а как мне учитывать его?? Я не знаю сколько из 100 т. Того или иного» она права – но, задача данной системы – показать именно технологам что есть и как расходовалось. Как до этого? Да просто писались бумажки – справки, де есть столько то (на глазок масса)..
В общем, по поводу проектирования.. Делая заплатки, рассчитывать на что-то «правильное» не приходится. Или делать правильно пересматривая бизнес-процессы, или перекладывать счеты на калькулятор.
----------------------------
по теме:
"Движение" даёт на любую дату и период любые операции и остатки.
"Склады" дают текущую актуальность, и возможность реализовать логику не особо нагружая сервер.
Вроде закончил :)