Последний выдох ГПЖрасступись народ, тут знаток 3НФ пришел - сейчас всех новой жизни научит



А шо делать?

Вот представте ИС. У вас есть таблица справочник товаров. Есть склад.
вам надо учесть количество - остатки обороты и т.д.

вы делаете таблицу
склад (если больше одного разумеется)
товар - ключ к справочнику
учетная цена (обычно стоимость минус НДС)

каждая запись и есть партия.
если надо можете дописать серию или еще чего.
само собой id партий.


приходит накладная. Вы делаете движения по складу.(оборот)
вставляете каждую позицию в некую таблицу со структурой.
id сессии
количество.
ссылка на первичный документ как и полагается для всех хозяйственных операций.


приходит товар - вы пишете движение 20 штук этой партии. Затем по другой накладной 10 штук этой же партии.

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

Это в развернутом виде для понимания процесса. Можете таблицу движений и не заводить. Вся инфа у вас в накладной. То есть это по сути хранение детальной части (позиции из накладной). Вопрос только на любителя - будем лопатить по первичке или нормализуем БД. В любом случае нет смысла разбивать партии по накладным.

Тут два варианта раз уж зашел базар.
1. Хранить документы разложенными по таблицам шапка и детальная часть (отсюда частая проблема как хранить разнородные документы).
2. Создать таблицу движений, которая не будет зависеть от типа документа - достаточно ссылки на него и на партию (то есть товар+ учетная цена). Тут два профита - все доки можно паковать в блоб ( оставляя только номер, дату и тип дока.Можно еще общее стоимость для орентирования по журналу.) и хранить в одной таблице.
Второй профит - остатки и обороты по товарам(партиям) можно выполнять пересчетом по таблице движений и не парится хранением остатков (количеств в партии на начало периода). Напоминаю вычислительное железо за стоит дороже работы програмиста.
третий профит как следствие. Если добавить к партиям отпускную цену при передаче товара в магазин (а это другой - розничный склад то есть место хранения а значит отдельные записи в таблице партий в разрезе складов) - то мы получаем в одной записи входящую цену отпускную цену, количество и дату проданного товара (в движениях ссылка на розничную накладную или кассовый чек). А значит получаем все данные по затратам прибыли за период в разрезе товаров складов и закупочных цен. И никаких мучений с разбивкой по накладным фифо лифо средней цены и прочего гемора.

авторНапоминаю вычислительное железо за стоит дороже работы програмиста
блин, дешевле :)

ViPRoscaballero,

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

авторвы только что описали регистр накопления и окончательно добили 1с
Аминь

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

авторДа, небольшой минус - больше справочник, но огромный плюс - гибкость и простота.
фига се простота

авторЭто позволяет работать с любым типом товара - от фруктов, где качество пришедшего товара определяется даже тем, с какой стороны фуры он лежал, слева или справа, до скобяных изделий, которые вообще не портятся.
в моей системе вообще пофиг где что лежит - это и есть простота. На учете никак не сказывается с какой стороны вынули товар.

авторЕсли на руководство снизойдёт озарение, и оно решит на каждое яблоко прилепить штрих-код, то это меня нисколько не озадачит, я просто уберу в нужном месте галочку, а вот Вас гарантированно ввергнет в ступор, поскольку придётся всю Вашу систему переписывать, от БД до клиента.

чушь, я просто добавлю табличку со штрихкодами которая никак не повлияет на остальной учет

авторСерии и партии не одно и тоже. Лучше вести отдельный справочник серий.
Серии и партии связаны как М-M.

нет
авторВ одной поставке могут быть препараты из разных серий, одна серия может быть в нескольких поставках. И если поставщик вдруг препарат в нескольких сериях объединил в одну строчку накладной (что гипотетически может случится), провизор должен разделить их на отдельные партии.

пример того что глупо привязывать партии к накладным а тем более строчики

партия это - товар, цена, серия . Это перекрывает любой функционал.

автор Мы программисты, а не кладовщики. Если кладовщики всё сваливают в кучу, или засовывают 30 шкур в одно дупло, это их проблемы
ьак зачем вы пытаетесь решать их проблемы учитывая что с какой стороны лежит и какие бананы начали портится?