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

По поводу сертификата почему "(символьное поле)"? Как я понимаю слово "сертификат" это бумага с датой номером и кем выдан в котором указана дата реализации? Тогда имеем две даты и две строки.

EgorichКаждой позиции в накладной соответствует запись в таблице сертификатов
А так ли нужно хранить список сертификатов отдельно, т.е. может ли быть несколько партий с одним номером сертификата?

EgorichМои рассуждения: В данном случае идёт речь о напитках - пиве :) Оно имеет срок ограниченный срок хранения. Значит надо использовать метод отпуска ФИФО.
А если срок хранения кончился? ;) отпускать сначала просроченное?

EgorichУ меня не такие большие закупки, поэтому я подразумеваю, что сертификат будет соответствовать каждому товару. Может включить поля сертификата в подчинённую таблицу PrihodIT?
В данном случае правильная идея.

Единственная проблема что при списании

EgorichРешил попробовать вот так. Каждой позиции в накладной соответствует запись в таблице сертификатов.
Комментарий к картинке. Чем таблица PRIHOD(T) отличается от RASHOD(T)? Может не стоит плодить таблицы практически совпадающие по структуре, а ограничиться полем "тип накладной"?

EgorichПоэтому я и буду использовать FIFO :)
Это я к тому что может быть имеет смысл использовать FIFO по сроку годности и по партиям прихода, а не только по партиям? Правда это вопрос спорный.

LSV авторА так ли нужно хранить список сертификатов отдельно, т.е. может ли быть несколько партий с одним номером сертификата?Однозначно надо хранить список отдельно.
Номер сертификата это такая-же справочная информация как и срок реализации смысл в хранении "списка сроков реализации"?

LSVНикакой жёсткой привязки к ФИФО! Иначе высока вероятность, что фактический товар не будет соответствовать выданому по документам. Почему ? Обычные накапливающиеся ошибки выдачи/приёмки/возврата/замены.
Честно говоря не работал именно с торговлей, но в других областях, где используется LIFO-FIFO метод ручного выбора партии для списани является достаточно редким исключением. Трудно реализуемым и сложно поддерживаемым. Так что я бы не был настолько категоричен.

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

LSVСамое правильное в момент отгрузки вручную (!) переписывать сроки отобранного товара и подбирать под эти сроки сертификаты.
Ни кто не мешает списывать товар со склада в разрезе "приходных партий", а в перечень накладной забивать номера (руками или автоматом) подходящих по срокам сертификатов (если вообще это надо).

2:Egorich Вообще партионный учет достаточно сложная в реализации вещь, особенно если принимать во внимание частичный возврат, потери, инвентаризацию и пр, и используется в бухгалтерии для правильного расчета балансовой стоимости и прибыли/убытков. Так ли это вам надо?

LSV EstetsА вопросы с несоответствием, решаются "человеческим фактором" (строгостью учета)Да что Вы говорите ! ! ! Строгостью ? Сразу видно, что не работали в торговле. Ошибки учёта есть всегда и в немалом количестве.
Примите на склад нормального человека положите ему оклад в 800$ с условием раз в месяц аудит, есть несоответствие -50% зарплаты, 2 ошибки - увольнение. И знаете, "ошибки" исчезнут сами собой ;)))

Возьмите средний банк около 300 человек оперируют с большими суммами денег, а сколько ошибок? Очень мало. А почему? Компетентность, контроль и ответственность вплодь до уголовной. И это все "человеческий фактор".

LSVЕдинственный выход - в системе возможность привязки сертификатов к товару должна быть гибкой, а не жёстко вшитой.
Желательно иметь такую возможность, но выход не единственный. Пришла одна партия а списали другую??? Правилнее сделать документ, которым при нахождении ошибки, можно было бы изменить текущие партии на складе, а списать все равно FIFO.

Egorich Estets я уже думал над тем, чтобы приход и расход вести в одной таблице и добавить поле bit логическое - приход, либо расход. Будет легче писать запросы?
Практически на любых базах лучше всего не использовать поле bit. Для таких случаев я напимер использовал int 1, -1.
EgorichНеясно мне, как реализовать механизм FiFo. Либо хотя бы предоставлять выбор пользователю сертификатов.
Мда, но все равно в двух словах:



По введенной накладной вносим три записи
OP_TYPEOP_QTYGOODS_IDSERT_NOEXP_DATE110BAL70012301/05/06110BAL70044401/04/06110BAL70077701/05/06

Вносим накладную на продажу 15 бутылок балтики, для этого получаем список текущих партий:



QTYSERT_NOEXP_DATE100012301/05/06100044401/04/06100077701/05/06

Сортируем его по EXP_DATE, SERT_NO

QTYSERT_NOEXP_DATE100044401/04/06100012301/05/06100077701/05/06

Открываем курсор, или идем клиентом по записям
Напомню, списывается 15 штук.
Начинаем заполнять таблицу T_MOV записями по списанию, первая партия 10 штук, записываем в T_MOV данные из партии и нужное количество

OP_TYPEOP_QTYGOODS_IDSERT_NOEXP_DATE-110BAL70044401/04/06

Вторая партия 10 штук а нам надо списать всего 5

OP_TYPEOP_QTYGOODS_IDSERT_NOEXP_DATE-110BAL70044401/04/06-15BAL70012301/05/06

итого в таблице движения

OP_TYPEOP_QTYGOODS_IDSERT_NOEXP_DATE110BAL70012301/05/06110BAL70044401/04/06110BAL70077701/05/06-110BAL70044401/04/06-15BAL70012301/05/06

Проверяем остаток


получаем

GOODS_IDQTYSERT_NOEXP_DATEBAL750012301/05/06BAL7100077701/05/06

Это конечно сильно упрощенный, но рабочий механизм FIFO, LIFO получается сортировкой таблицы партий в обратную сторону, а "Возможность выбора партий вручную" реализуется как- показать пользователю список партий и пусть он сам нужную сумму по строкам раскидает ;)

Уф.

proposed amendment
теоретик... (это не подпись :)) )
Подпись подпись ;)))

xLock EstetsПрактически на любых базах лучше всего не использовать поле bit. Для таких случаев я напимер использовал int 1, -1.

Если не сложно, уточните почему именно "лучше всего не использовать" ?
А смысл? Никакой экономии пространства, все равно сервер будет хранить байт. Не все клиентские приложения понимают битовые поля, либо конвертируют их в int(shortint,tinyint). Зачем лишние расходы?
Плюс выше я описывал, как легко получить сумму приходов/расходов SUM(OP_QTY*OP_TYPE), при битовом поле это решается через CASE.

Курдль Ушастый
А что будет, когда в T_MOV накопится десять миллионов записей?

!!! Нельзя короткую операцию (списание одной единицы товара) основывать на запросах, длительность выполнения которых зависит от кол-ва записей в таблицах, которые растут линейно с течением времени !!!
Ээээээ, задача стояла "на пальцах" объяснить пример реализации работы LIFO-FIFO, а не дать его промышленную реализацию. Для решения вопроса производительности вводятся "опорные остатки" или "текущие остатки".

Но прошу заметить, если система позволяет проводить/отменять операции, не текущим днем, а залезать в прошлое, то без задействования T_MOV все равно невозможно корректно проводить операции LIFO-FIFO.

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

Можно еще попробывать добавить, если конечно память мне не изменяет