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 т. Того или иного» она права – но, задача данной системы – показать именно технологам что есть и как расходовалось. Как до этого? Да просто писались бумажки – справки, де есть столько то (на глазок масса)..
В общем, по поводу проектирования.. Делая заплатки, рассчитывать на что-то «правильное» не приходится. Или делать правильно пересматривая бизнес-процессы, или перекладывать счеты на калькулятор.
----------------------------
по теме:
"Движение" даёт на любую дату и период любые операции и остатки.
"Склады" дают текущую актуальность, и возможность реализовать логику не особо нагружая сервер.
Вроде закончил :)