Преветствую всех кто зашел в данный топик и прошу оценить / поправить / дать предложения по следующему вопросу.

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

Здесь я стараяюсь создать самый простой рабочий и логичный вариант склада (он же и магазин), минимум бухгалтерии (желательно вообще без бухгалтерской составляющей) - просто логику работы склада - прием / расход товара. Поэтому прошу не посылать на курсы бухгалтеров :)

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

Прошу помочь: можеть что забыл - не учел, может есть ошибки и предложите варианты реализовать поумнее. Наверника у многих есть свои наработки и опыть в таких проектах - поделитесь...





Задание на разработку автоматизированного программного комплекса "Учет движения товаров" или "Склад".

Программный комлекс "Учет движения товаров" или "Склад" (далее ПК) предназначен для автоматизации складских и торговых операций по приему, хранению и продаже товаров в фирме "ХХХХ".

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

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

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

Структура базы данных ПК представлена в сопроводительной документации. Желательно ознакомиться с ней перед дальнейшем чтением.

ПК состоит из следующих участков учета и формирования торговых операций:

Приход товара;
Расход (списание) товара;
Переоценка товара;
Резерв товара;
Внутреннее перемещение товара между складами.

Приход товара

Под приходом подразумеваем любое поступление товара на склад.

При приеме товара на склад в АРМ регистрируются следующие реквизиты (жирным выделены обезательные):

Оператор:

Код / наименование товара из справочника, справочник товаров (номенклатурный справочник) должен быть заранее заполнен администратором программы на центральном складе;
Наименование поставщика из справочника, если нет в справочнике - можно добавить;
Производитель из справочника, если нет в справочнике - можно добавить;
Тип операции: приход, приход (возврат товара), внутреннее перемещение (между складами);
Наименование склада с которого товар перемещен. Только для типа операции "перемещение"!!!
Номер накладной;
Закупочная цена за единицу продукции;
Количество единиц продукции;
Дата конечной реализации партии;
Суммарные накладные расходы по данной партии (доставка, разгрузка, тара и прочее)
Примечание.
Программа автоматически:

Код (ID) текущего склада;
Дата прихода - возможно надо сделать возможность редактирования оператором;
Расчитывается цена единицы товара (закупочная цена за единицу продукции + суммарные накладные расходы / кол-во единиц продукции).
Так как при таких связях при выборке остатков при больших объемах может тормозить, пердлагаю снизить тормоза след убразом: в таблицу прихода добавить поля фактическое кол-во товара, кол-во зарезервированного товара, оплачено польностью или нет. Эти поля будут изменяться исключительно триггерами таблиц прихода/расхода/резерва/оплаты...

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

Расход товара

Под расходом подразумеваем любо отпуск товара со склада.

При расходе товара со склада в АРМ регистрируются следующие реквизиты (жирным выделены обезательные):

Оператор:

Код / наименование товара из справочника, справочник товаров (номенклатурный справочник) должен быть заранее заполнен администратором программы на центральном складе;
Покупатель из справочника, если нет в справочнике - можно добавить;
Тип операции: расход, расход (возврат товара), внутреннее перемещение (между складами);
Наименование склада куда перемещается товар. Только для типа операции "перемещение"!!!
Номер накладной;
Количество единиц продукции;
Примечание.
Допонительно:

Дата оплаты, если была произведена оплата;
Сумма оплаты;
Примечание об оплате.
Программа автоматически:

Код (ID самого старого) прихода товара на текущий склад;
Внутренняя цена за единицу продукции (из табицы истории цен берем последнюю цену);
Дата расхода - возможно надо сделать возможность редактирования оператором;
Цена с наценкой по умолчанию из справочников наценок;
Скидка в процентах к цене в п.4., скидка рассчитывается атоматически в зависимости от кол-ва единиц товара и рейтинга клиента. Формула будет описана позже.
Расчитывается цена единицы товара (закупочная цена за единицу продукции + суммарные накладные расходы / кол-во единиц продукции).
Учет ведется по партиям. Представим следующую ситуацию: Товар ХХ имеется в 2х поставках - поставка №1 - 20 единиц по 10 гр и поставка №2 - 30 единиц по 15 гр. Клиент заказывает товара ХХ в кол-ве 25 единиц. Действия продавца: вводит код/наименование товара и видит обе поставки с кол-вом и ценами, говорит что по такой-то причине (правда) может продать только 20 единиц товара по 10 гр, а 5 единиц по 15 гр. Если клиент после недолгого недоразумения все же согласен - то продавец производит 2 списания товара - отдельно 20 ед по 10 гр и 5 ед по 15 гр. Проблему см в топике "Замечания".

Переоценка товара

Под переоценкой подразумеваем любое изменение цены товара на складе.

Переоценка может проводиться при повышении/понижении цены на товар, при поступлении новой партии товара с новой ценой если надо у старой партии товара цену выровнять с новой и др.

Цены у каждой партии товаров хранятся с отдельной связанной табличке. При поступлении товара эта цена рассчитывается автоматически, а при списании в качестве текущей цены товара берется последняя запись о цене в этой табличке. Переоценка (если на это есть права у пользователя) представляет собой добовления новой цены (записи) в это табличку цен. Таким образом, на остатки товара будет действовать уже новая цена, т.к. именно она будет использоваться при опрации расхода (списания) товара.

Резерв товара

При работе с постоянными клиентами может понадобится резервирование товара, например, клиент из другого города смотрит прайсы - звонит или посылает резерв что завтра приедет за таким-то товаром. Оператор ставить этот товар в резерв чтоб он не кончился к приезду клиента. При этом заполняет следующие реквизиты:

Код прихода;
Наименование клиента;
Дата начала резервирования;
Дата окончания резервирования;
Кол-во зарезервированного товара;
Примечание.
По истечению скора резерва у оператора всплывает (сигнализирует) сообщение о истечении срока резерва. Это функция только для напоминания - оператор сам создает запись о резерве товара, сам ее редактирует / удаляет.

При подсчете кол-ва оставшегося товаров на экране АРМ отображается фактические остатки товара, резерв товара и кол-во свободного товара.

Перемещение товара между складами

В предыдущем топике рассматривался резерв товара для клиента.

Существует также другой резерв товара - резерв товара на другом (чужом) складе с целью внутреннего перемещения (перемещения к себе). Т.е. после синхронизации оператор склада №1 видит остатки товара на складе №2 и хочет себе на реализацию N кол-во товара ХХ. Он в спец таблице выбирает нужную ему партию склада №1, вводит желаемое кол-во единиц товара. После следующей синхронизации оператор склада №1 видит (программа сигнализирует) что у него оператор склада №2 просит N кол-ва товара ХХ. Если оператор склада №1 согласен - он выписывает товар (расход) с типом операции "перемещение" и экспедиторы доставляют товар на склад №2, где он записывается с приход с типом операции "перемещение".

При этом оператор склада №1 вне зависимости от его решения (передать или нет товар) может только снять пометку чтоб ему программа не сигнализировала. Снять (удалить запись) резерв товара может только тот оператор, который создал эту запись - оператор склада №2. У оператора склада №1 о действиях оператора склада №2 станет известно только после очередной синхронизации.

При подсчете остатков товара этот резерв для внутреннего перемещения никак не учитывается.

При перемещении товара между складами товар расходуется и приходуется по таким же правилам как и обычный расход и приход только с типом операции "перемещение". При этом заполняется поле НАИМЕНОВАНИЕ СКЛАДА куда перемещаем или откуда приходуем товар. Тип операции "перемещение" устанавливает несколько другие операции с ценами товара при перемещении. Об этих правилах будет рассказано позже.

Замечания на которые вопросы еще не нашел:
Номер расходной накладной надо набивать тоже по каким-то правилам.
Щтрих-коды.
№ смены, продавца, экспедитора.
Правила подсчета скидки при рейтинге / кол-ве единиц товара
Правила возврата товара, возврата при ошибочном приходе, приход при ошибочном расходе.
Как вести себя при возврате после переоценки товара. Продавать выше/ниже себестоимости??
Как вести себя когда клиент или другой склад зарезервировал товар, и пока идет резерв меняется цена товара (переоценка). Они уже вряд ли захотят товар если он станет дороже. Потеренное время - хотя это приемлемо...
Возможна ситуация когда товар находится на складе в 2х поставках - старой и новой, например хлеб. Но старый (вчерашний) хлеб никто покупать не хочет, а все хотят покупать новый (сегодняшний) хлеб (или новая поставка более имеет более низкую цену чем старая). Если продавцу предоставить право выбора поставки для продажи, то он можел легко злоупотреблять не только старым или свежим хлебом, но и когда цены в поставках разнятся. Причем в случае с выбором поставки становится невозможным (проблематичным) пользоваться сканером штрих-кодов, если они появятся. Вечный вопрос - что делать?? Еще - что показывать в прайсах??
Как часть партии отправить в брак / сниить цену.
номер накладной наверное в отдельную таблицу - по приходу может быть сотня товаров в одной накладной. Надо подумать. Надо ли учет по накладным (общий поставщик, общие накладные расходы)?? Как, зачем и где учитывать??
Может в справочнике товаров (номенклатурный спр) добавить поле "ПРОИЗВОДИТЕЛЬ ПО УМОЛЧАНИЮ"??
В справочник товаров сейчас втянуты 4 таблицы: ед. измерения, номенклатурный справочник, таблица наценок и собственно сам справочник товаров S_GOODS. Можно сократить кол-во таблиц на одну. В номенклатурный справочник добавить поле - ссылку на таблицу наценок = таблица справочник товаров. Минус - номенклатурный справочник может понадобатся в других проектах без поля наценка. Плюс - меньше таблиц, связей - больше скорость. Можно тудаже добавить и производителя. Можно номенклатурный справочник разделить на 2 таблицы - типы товаров (с построением дерева) и наименованием товара.
Как быть если товар получаем пачками (сигареты) а продаем поштучно?? Или получаем 10 кг банку маслин, а продаем 8 кг по 100 - 200 гр и расол 2 кг сливаем в унитаз...??

Много конечно - но это решил записать на бумажку после недели пережовывания в голове.
Буду раз всем замечаниям/предложениям.

to вредный бык

пасибо - щас попробую дать объяснения / исправления

для этого и прошу критиковать

вредный бык 1) Зачем поставщикам и покупателям (как впрочем и самим складам) разные таблицы, вместо одной контрагенты?
и правда надо объединить

вредный бык
2) Почему приход и расход в разных таблицах?

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


вредный бык 3) Все резервы тоже в одну таблицу можно.
можно если добавить поле внутренний или внешний резерв. а при выборе остатков фактических/зарезервированных/свободных анализировать - если внутренний резерв - то не учитывать. возможно придется объединить

вредный бык 4) Из таблицы наценок группы скидок вынести вон - тогда их может и 4 и 104.
можно вынести. плюсы - наценок может быть 104, минусы - громоздкость при расчете скидки по кол-ву и при формировании прайсов (правда в прайсы публикуют только первые пару колонок). Как правило таких колонок цен в магазине не превышает 3-4 - я так и сделал. Это не принципиально но изменять думаю не стоит.

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

to вредный бык

спасибо за идею деревянного справочника, где на каждом уровне своя единица измерения и коэффициент пересчета. обезательно попробую прикрутить. учитывать вроде так: имеется товар - юочка 200 л, оператор хочет списать 3 стопарика - набирает 3 а в поле ед. изм выбирает из нескольких нужных единиц изм - стопарик. а при этом списание происходит следующим образом - 1 бочка = 20 ведер, 1 ведро = 10 л, 1 литр = 5 стаканов, 1 стакан = 2 стопарика.
Итого 20 ведер*10литров*5стаканов*2стопарика=2000 стопариков в 1 бочке, значит списываем 200/2000*3=0,0015 бочки. правильно?

вредный быкВ вашем примере, лучше использовать понятие "партия" как совокупность ТМЦ, приобретенных у любого поставщика по любому документу, но с одинаковым сроком реализации. То есть просто достаточно в приходных/расходных документах указать партию товаров.

т.е. предлагаешь следующую схему (немного додумал сам):

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

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

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

Недостатки перед моей схемой:
- у меня списание четко происходит с конкретного прихода и если остается недосдача (утеря, высыхание товара, слив рассола от маслин в унитаз) она видна сразу когда партия подходит к концу. у тебя же эта нестыковка (недосдача) тянется долго и откуда тянется неизвестно откуда (мож единичная операция). так будет происходить когда одна и та же партия объединяет в себе много идентичных партий;
- со временем несколько разных партий могут сливаться в одну (переоценка с установкой общей цены)

спасибо за хорошие идеи - кое-что взял на заметку. к завтрешнему дню думаю кое-что поправить и выложить вариант с поправками.

вредный быкЯ предлагаю сначала опредилиться надо тебе FIFO/LIFO или нет. А потом внедрять понития аля "недостачи по пратиям".

ну вот опять бухгалтерские понятия. без них никак?

FIFO - первый пришел, первый ушел
LILO - последний пришел, первый ушел

если учитывать срок годности, а в этом случае самая старая поставка как правило с самой меньшим сроком годности => надо самый старый товар продавать как можно быстрее => FIFO

или тут есть севсем глубокий смысл в моем случае без бухгалтерии???


вредный быкнадеюсь уже не в екселе?
да кстати, в чем вы делаете на этапе разработки структуры БД?? пробовал в office visio - фигня - не могу даже настроить какие поля отображать (мне надо поле описание). или я туплю... можно в сторонних визуальных построителях БД... пользуюсь FireBird с его IBExpert - там визуальный построитель БД мне не понравился, до этого использовал MS SQL - там редактор получше будет. да в этом случае сюда выкладывать картинку, а в екселе еще можно легко вести переписку с кем-то...

-=ALEX=-Итого 20 ведер*10литров*5стаканов*2стопарика=2000 стопариков в 1 бочке, значит списываем 1/2000*3=0,0015 бочки. правильно?

MGR
Это неправильная практика.
В принципе, я видел систему, в которой были в таблице предусмотрено 4 (или 5, уже не помню) единиц и именно так и перемножалось.
Они были по горизонтали, то есть в одной строке хранились все коэффициенты пересчета.


предлагается структура в виде дерева - бесконечное кол-во вложенных подьединиц продукции. все делается двума полями KeyID (он же и PK) и ParentID. А в спец процедурке уже вытягивать из основной единицы изм (в которой приходовался товар) шагая по уровням вложенности коэффициенты пока не дойдем до введенной ед. измерения. Премемножение и дает нужный коэф-т. Предлагаемый вами вариант здесь представлен двумя соседними уровнями.

Другое дело что этого надо стараться избегать. Напр кол-во знаков в кол-ве товара предполагается равным 3, тогда 0,0015 бочки округлится до 0,002 - что уже не верно.

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

Т.е. имея дерево пересчета единиц измерения, приход при сохранении в базу переводить в родные справочнику единицы измерения?
Получается что водяра в справочнике хранится в стопариках. Приход = 1 бочка - при сохранении в базе она автоматом переводится в стопарики и сохраняется как 2000 стопариков. Ну расход можно как и стопариками, так и ведрами - переводится в стопарики и списывается.

Правильно ли я понял?

кстати вчера вечером (переустанавливая товарищу винду) употребил N стопариков, поэтому поправки не успел сделать. К обеду, думаю, выложу.

-=ALEX=-Т.е. имея дерево пересчета единиц измерения, приход при сохранении в базу переводить в родные справочнику единицы измерения?

а как же тогда хранить (надо ли вообще) приход по накладной? т.е. хранить ли 1 бочку или забить на нее и в приходе сохранить 2000 стопарей?

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

вредный бык , покритикуйте эти варианты, скорее придется остановиться на первом варианте...

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

1 вариант

2 вариант

добрый быкРезерв товаров и товары на конкретном складе - это одно и тоже. Просто в первом случае они перемещаются на виртуальный склад-резерв, а во вторм на какойнить реальный склад. Физическая таблица должна быть одна.

не понял?? т.е. надо делать неподтвержденное списание товара? если резерв продается реально - утвердить списание, если нет удалить или что там еще... как учитывать сроки резерва??

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