Представьте: ваш завод отгрузил партию насосного оборудования ключевому клиенту. Через неделю насосы начинают выходить из строя. Причина — разрушение подшипника вала. Клиент в ярости, выставляет многомиллионную претензию и требует заменить все насосы.
Вы вызываете начальника производства и снабженца. Задаете два вопроса:
1. Кто поставщик бракованных подшипников?
2. В какие еще заказы мы их поставили?
Если ваша учетная система работает в режиме обычных товарных остатков (SKU), вы не получите ответа. В базе просто числится «Подшипник 204 — 500 шт». Какие из них приехали от надежного поставщика А, а какие купили по дешевке у поставщика Б — неизвестно. На складе они лежат в одной куче. В итоге вам придется отзывать продукцию у всех клиентов за последний год. Убытки колоссальны.
Смерть «Котлового метода» и иллюзия FIFO
Большинство систем используют метод списания по средней стоимости или FIFO (первый пришел — первый ушел). Это чисто бухгалтерская математика, которая не имеет ничего общего с физической реальностью цеха.
Система может считать, что списала «первый» подшипник, а рабочий физически взял со стеллажа «последний» (потому что он лежал ближе). Когда дело дойдет до расследования брака или расчета реальной себестоимости, ваши данные будут бесполезны.
Как работает Batch-архитектура в ModernERP Pro
В ядре нашей системы мы разделили понятия «Номенклатура» (Material) и «Партия» (Batch). Партия — это независимая физическая сущность.
Когда снабженец принимает металл или комплектующие, система генерирует уникальный внутренний код (например, `B-2604-105`). К этому коду намертво привязываются:
- Конкретный поставщик (Supplier).
- Точная цена закупки именно этого объема (Purchase Price).
- Входящий сертификат качества и дата производства.
🛠 Глубокая интеграция движений (Stock Movement)
В ModernERP Pro ни одно перемещение не происходит без указания партии. Когда кладовщик выдает металл в цех (создавая `StockTransfer`), он сканирует штрихкод конкретной партии. В базе данных создается `StockMovement`, который связывает конкретный заказ покупателя с конкретным `Batch ID`.
Результат: алгоритм `getQtyByWarehouse()` в любой момент времени покажет директору, на каком именно складе или в каком цехе сейчас физически лежат остатки бракованной партии.
Три бизнес-выгоды от партионного учета
1. Хирургически точные отзывные кампании (Traceability)
Если выявляется брак, вам достаточно ввести номер заказа или серийный номер изделия. Система разворачивает историю «вниз» и показывает, из каких партий сырья оно собрано. Нажав на бракованную партию сырья, система разворачивает историю «вверх» и выдает список: «Эта партия использовалась в Заказах №45, №62 и №89». Вы отзываете три изделия, а не триста. Вы выставляете регрессный иск конкретному поставщику.
2. Честная маржинальность (Фактическая себестоимость)
В условиях прыгающих цен на металл усреднение убивает финансовую аналитику. Первая партия металла стоила 100 000 руб/тонна. Вторая — 130 000 руб/тонна. Если Цех №1 собрал изделие из первой партии, а Цех №2 из второй — их маржинальность должна быть разной. ModernERP Pro списывает в себестоимость заказа `purchasePrice` конкретной партии. Директор видит маржу без искажений.
3. Борьба с неликвидом и сроками годности
Для химических компонентов, красок или электроники критичен срок хранения. Партионный учет позволяет системе блокировать выдачу в цех сырья, у которого истек срок годности, или автоматически подсказывать кладовщику: «Возьми паллету из 3-го ряда, она испортится через месяц».
Резюме: Оцифровка ответственности
Внедрение партионного учета часто саботируется складом, потому что кладовщикам «неудобно» сканировать каждую паллету. Но для собственника это единственный способ сделать склад прозрачным. Вы перестаете платить за чужие ошибки. Если деталь бракованная — за нее платит поставщик. Если кладовщик выдал не ту партию — отвечает кладовщик. Система не прощает анонимности.
