В теме http://sql.ru/forum/actualthread.aspx?tid=306700 заикнулся о проектировании. Выполняю свое обещание.
Я работаю с торговлей и склад у меня приложение к энтой теме.
Я встречал два способа проектировать подобные системы. В первом все пляшется от бухгалтерии, во втором от товара. Есть куча споров о том, что лучше, я ж не буду парить мозги и расскажу только о втором, с которым собственно и работаю.
Используемая мной схема очень проста (не один я такой умный), есть огромная таблица, под названием Movments в которой находятся все (все) документы, характеризующие движение товаров. У меня это Приходная накладная, Расходная, перемещение, возврат, возврат поставщику. Основные поля таблицы: ID, PR (Признак документа), Дата, Номер, Статус, валюта, курс (к основной, у меня это к зеленому), ID склада Начало, ID склада Завершения (0 у меня продано, всего складов 18 (с учетом транзитных)).
К таблице Movments привязана таблица с деталями (MovmentD), в которой содержатся детали: ID, Код товара, Цена, Cost (стоимость операции (с привязкой к специальной таблице, где есть детали по которым произошло данное начисление (по весу, цене, объему етс)), количество. Так же есть дополнительная таблица (у меня называется MovmentH), где содержатся ГТД, штрих код, страна происхождения, серийный номер, количество етс.
Есть таблица История Статусов, в которой содержится информация о точном времени перехода документа по статусу.
Для удобства работы применяется таблица MovmentI в которой содержатся текущие складские остатки по базе и которая используется для оперативного списания. Правильней было бы привязаться к таблице MovmentH, но в момент построения системы было не до таких мелочей и привязались MovmentD, что приводит к некоторым сложностям при работе (создали дополнительную таблицу, которая собственно делает верхнюю не нужной MovmentIH (штрих код, ГТД, место на складе, серийник, количество)). При операции Расход (к примеру) происходит следующее: Товар выписан (ушел из MovmentI), Комплектуется (происходит обработка (ушел из MovmentIH, при этом есть возможность обработать эту операцию как автоматом (с помощью сканера, так и вручную выбрав необходимые номера из списка )), Приостановлен, Собран (лежит на месте сборки), Намечен к доставке, Отгружен, Дорога (есть пять дополнительных статусов 1Д и 2Д етс характеризующих доставку с помощью сторонних организаций), Доставлен, Документы получены (у меня своя система статусов, для каждой операции, хотя и хранятся в одной таблице).
В общем, все просто, в любой момент времени можно определить нахождение товара.
Есть нюансы, характеризующие специфику деятельности. К примеру, у меня очень сложная система «Заказ» и приходная накладная формируется только на последнем шаге из 4х (предыдущие имеют свои статусы и сущности таблиц).
Движение по статусам работает с помощью универсальных хранимых процедур, внутри которых заложена логика перехода.
Таблица История Статусов чистится раз в год (можно открыть базу за прошлый год, сохранение происходит по годовой инвентаризации), сейчас думаю, что стоит почистить и остальные, так как за 7 лет они нехило заполнились. Скорей всего перейдем на "чистую" систему с 2009...
Сейчас с подобной системой работают 4 конторы, Сделана в MS Access 2003 (клиент 4 модуля) и MS SQL200 cервер, максимальное количество рабочих мест ограничено только возможностями сервера (практически вся логика на нем и реализованна). Мнага думал о другом клиенте, типа Неть, но эта штука часть используемых операций не потянет, надо было вовремя переходить на делфи (уберечься от обвинений в прямитявизме ;) ), но система не для продажи, так что данное не важно :)
Будут вопросы, Задавайте.

ЧиграбортиА денежные средства в вашей системе учитываются? Если да, то как оформляете поступление, расходование, перемещение - НАЛ\БЕЗНАЛ.
И очень бы хотелось услышать про статусы, а конкретно, о чего зависит смена статуса, т.е. какое условие должно выполниться чтобы ХП делала своё дело? Есть, схема очень простая и состоит из четырех таблиц. Оплаты (как наши, так и покупателей) и три для связи с оплатой отгрузок или предоплат (привязка к счетам покупателей) и предоплаты по нашим заказам.
Сложности идут на другом уровне и связаны с специфичными особенностями учета (как учитывать кредит поставщика и через какое место или стоимость работ с транзитными складами етс), но это уже другая история (нал или оплата откатов достаточно простая схема и идет в рамках этих таблиц).
Есть определенные процедуры (не все программные) определяющие работу и принципы учета. В системе только управленческий учет инфа в бухгалтерию (1це налоговая етс) идет с помощью конвекторов. Лучшее теоретическое обоснование работы конвекторов есть у господина Усова http://www.alexus.ru/russian/articles.htm
От себя добавлю, что можно повеситься определяя "план счетов" даже для работы с перемещениями (особенно с транзитных складов)...


Про статусы можно говорить много, наверно стоит как нить расмотреть их более подробно и надеюсь мне кто нить в этом поможет.
В моем примере переход по статусам достаточно прост, есть только 2 места вызывающие проблемы. 1 - это переход в статус "Собрано". Документ должен находиться в статусе "Комплектуется" и товар из этого документа, должен быть "списан" из MovmentIH (обработан сканером), при этом есть возможность указать "вручную" из этой таблицы, что будем списывать. Документ обработанный вручную находится на контроле до "Документы получены".
2 - статус "приостановлен", данное ставится когда на этапе комплектации возникают проблемы, к примеру должны измениться строки накладной. Информируется кладовщик собирающий заказ и он переводится в этот статус (Только кладовщиком или администратором базы). Документ правится, при этом он висит в "Красном списке" до этапа "собрано" списание из MovmentIH должно быть подтверждено? отменено вручную.
Более интересна работа с приходами, но опишу в другой раз...

SokolNik???? /topic/529631&hl=
Сергей ВаскецовТекущие отстаки по базе (movementl) только количественные, или суммы тоже есть? Если есть суммы, зачем тогда валюты в складских документах?

Впрочем, я подумал еще раз, вопрос еще проще. Зачем валюты в складских документах, где они у Вас используются? Только количество. Все равно суммы нужно пересчитывать исходя из кучи параметров.
Система склад у меня приложение к торговле...

LSVЕсть ряд вопросов:
1. Как ведется учет задолженности поставщикам с учетом торговли "под реализацию" при условии, что товар может приходить от разных поставщиков ?
2. Как ведется работа с ошибками приёма/продаж (продажа в "отрицательное наличие") ?
3. Как отражается инвентаризация(устранение пересорта, приходование "излишков") на текущих(именно текущих) долгах поставщикам с учетом торговли "под реализацию" ? Хорошие вопросы...
1. Я не веду комиссионеров и мне не дают товара на таких условиях. Связано чисто с стремлением избежать лишнии проблемы. Теоретически проблем с вводом подобного у меня не возникнет, так как я храню всю историю товара.
2. Немного писал в теме закупка /topic/457172&hl=
Наверно стоит пройтись подробней...
а) У меня "жесткий" учет. Жесткий в том смысле, что наказание за пересорт жестокое как на уровне инструкций так и материально.
б) Схема прихода следующая: Есть инвойсы поставщика (документ показывающий сколько товара придет на мой склад), на основании нескольких инвойсов формируется приходная накладная и количество в ней соответствует количеству инвойса. Кладовщики принимают товар на основании приходной накладной. Если товара нет, то он удаляется и соответственно денег я должен меньше. Если товара меньше(больше) то правится и становится меньше. Если пришел иной товар, то создается новый инвойс и товар из него добавляется в приход.
Процедура достаточно отработана и проблемы редки.
г) Случилось страаашное... Возможны варианты: Один из последних примеров. От хорошего поставщика пришло меньше товара, чем в приходе, а кладовщик не пересчитал. Товар продали и отгрузили (опять не считая). Клиент выдвинул притензию, но на возврат не согласился (так бы сделали возврат и возврат поставщику). Пришлось делать левый приход с датой отгрузки и одновременно править приход от поставщика. Когда товар пришел сразу отгрузили этот товар поставщику "Пересорт", кладовщик потерял 50% премии. Описанное, простая схема действий. Есть приходы на склады Транзит, где отгрузки идут минуя нас. Там больше ошибок и приходится сильно отслеживать движение по таким складам.
3. Инвентаризация у меня "Перманентаная" и годовая. Перманентная заключается наличие в листе комплектации текущего количества на складе и инструкции для кладовщиков, где сказано, что отвечает не тот кто собирает текущую накладную, а предыдущий...
ЗЫ Поставщик отгрузил мне товар и не важно "На реализацию" или как. Если я его не проверил, это моя проблема (я попал на бабки).
ЗЫЫ Термин и схема перманентной инвентаризации придуманно andbary

iscrafmтексты про что угодно, но только не про некие "конверторы" Так я и не писал, что это там есть
Хотя там есть мысль о "Простоте"...
iscrafmникто не заметил, куда автор делся? Не поверишь... Верхнее сообщение я пишу третий день...

UrryMcA А что, между ними есть четкая граница ???? :)


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

UrryMcAНет, ребята! Пулемёта я вам не дам .. (с) О величайший!!!
Ничтожно прошу просвятить темных в вопросе "границ"!!!
Дай возможность невурущим ощутить всю глубину Вашей мудрости в вопросе, столь важном, что перед ним ничто, не только какая то ряволюция, но и селедка с хреном!!!

ЗЫ Говорят, что минута сммеха сохраняет год жисти... Ничтожно сумнящися, надеюсь продлить ее минимум на два года, прочитав ответ.

Нет у меня партионного учета в системе, нету...
И там где стоит эта система его нет, хотя одна из контор занимается медициной.
Учет средневзвешенный, а партионный только для склада. Никто из продавцов не парится по данному поводу, за счет чего достигается большая эффективность их работы.
Для склада же это реализованно, как в ПО, так и в инструкциях и проблем не вызывает.