Как организовать Приход/Списание/ Продажа/ Остатки на складе MYSQL?
Здравствуйте.
Есть своя разработка по программе доставки, работает уже около года и всех устраивает. Решил дальше развиваться и написать софт для розницы.
В общем есть задача хранить остатки, делать приходы и списания ( там еще куча другого, но пока это интересует)
Пока делаю складской учет. Компания занимается приготовлением еды и продажей ее в розницу и на доставку.
Весь функционал работы с заказом и т.д уже есть, просто надо сделать блок учета. С 1С пробывали связаться, кучу API Надо доделывать и в итоге постоянно не согласованность у нас. Поэтому решили сами написать. Все есть, кроме грамотной архитектуры базы для учета именно.
Много прочитал информации в интернете и материалов на форумах и похожие вопросы мои, но у всех разная специфика и каждый по своему делает
Пока пришел к такому:
-Хранить остатки в отдельной таблице с привязкой на торговую точку и на продукт
- Одна таблица для приемки товара ( там еще связные есть , список продуктов и т.д)
- Одна таблица для списания товара ( там еще связные есть , список продуктов и т.д)
- Одна таблица для продажи
В общем есть сомнения в реализации, особенно с хранением остатков, особенно когда меняют задним числом, либо в приемке старой поменяли количество.
Да и в общем, эффективно хранить остатки в отдельной таблице или стоит просто делать приход-расход-продажи
А может вообще объединить приход/списание/продажа и тогда остатки проще считать, но таблица получится при таком подходе просто огромная и подсчет остатков будет трудоемкой операцией.
В общем хотел у Вас спросить, может кто то работает с программами учета, есть какие удачные реализации? Я не жду развернутого ответа с описанием таблиц и т.д. Мне просто нужно узнать направление куда двигаться, так как на разных источниках говорят по разному
Я бы собрал примерно следующие сущности - таблицы.
1) Товар. Просто информация о нем, артикул, ну, в общем все то, что не меняется со временем.
2) Торговая точка. Собственно, то же самое. Ничего критичного - просто описание всех торговых точек, в которых осуществляется реализация товара.
3) Связующая таблица Товар-Точка. Здесь как-раз будет храниться вся нужная информация. Дата прихода, количество и так далее. Классическая связь многие-ко-многим в реляционной базе, только здесь pivot-таблица должна содержать всю необходимую информацию.
Мне кажется вы немного перемудрили и ваша система будет чересчур дублировать саму себя.
Если хотите - можно добавить триггер и лог-таблицу на списание товаров. Тут уже как ваша душа пожелает. Все что захотите)
Денис, Пожалуйста. У вас уже есть таблица-посредник. Списания - уменьшение значения одного столбца (при желании создается один столбец, который дублирует изначальный приход). Приход - добавление новой строчки.
Пример списания:
UPDATE items SET amount=amount-1 WHERE id=3;
Пример прихода:
INSERT INTO items (`колонка`, `колонка`) VALUES (`значение`, `значение`);
Пример извлечения остатка:
SELECT amount FROM items WHERE id=3;
Плюс повесьте триггер на событие update таблицы ITEMS, которое будет писать в таблицу ITEM_SELLS, какой конкретно товар продали, кому и когда, если это критично. Если нет - забейте.
Сергей Попов,
Спасибо ) я такую реализацию и задумал
Плюс еще таблицу движения товара, но мне простой мой подход кажется не идеальным, думал может кто то из реальной практики по складу подскажет, как это в боевых условиях. Где подводные камни при больших объемах
Денис, это и есть подход из боевых условий. Реально работающая модель та, которая предполагается самим устройством баз данных. То, что вы задумали - избыточно.
Большие объемы фиксятся добавлением индексов, шардингом и тому подобным безобразием, хотя на реляционных базах данных шардинг немного болезненный.
Средний
