Учёт сроков годности: партии, FEFO и доступность

Как автоматизировать учёт сроков годности в ERP: партии, FEFO, остаточный срок, резервы, блокировки, обмен и приёмочные сценарии.

Автор: Александр Поркулевич, CEO и основатель, 404gen.

Учёт сроков годности в ERP связывает каждую партию с датой окончания допустимого использования и проверяет её при резервировании, перемещении и отгрузке. Одного поля в карточке товара недостаточно: одинаковый артикул может одновременно находиться на складе в нескольких партиях с разными датами и состояниями. Система должна выбирать подходящий запас под конкретное обязательство и объяснять отказ.

Статья для руководителя склада, операционного директора и владельца ERP. Рассмотрим данные партии, FEFO, остаточный срок, исключения и проверку автоматизации. Условия хранения, допустимость продукции и обязательные отраслевые правила определяют специалисты компании; здесь разбирается программный процесс, который исполняет утверждённые требования.

Срок относится к партии, а не только к товару

Карточка товара может хранить типовой срок и признак необходимости контроля. Фактическая дата относится к конкретной партии или экземпляру. Если записать её единственным значением у артикула, новая поставка перезапишет старое значение, и система потеряет различие между запасами. Итоговый остаток останется верным по количеству, но непригодным для выбора отгрузки.

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

В учебном примере на складе лежит один артикул из трёх поставок. У первой партии осталось мало времени, вторая подходит обычному заказу, третья ещё не прошла внутреннюю проверку. Общая цифра «120 единиц» ничего не говорит о возможности отгрузить конкретному клиенту 50. Для решения нужен разрез партий и требований заказа.

Чем FEFO отличается от FIFO

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

До сортировки нужно исключить неподходящие партии. Заблокированный запас, неподтверждённое поступление и товар с недостаточным остаточным сроком не становятся подходящими только потому, что их дата ближе. Практическое правило состоит из двух частей: сначала допустимость, затем приоритет выбора. В интерфейсе полезно показывать обе причины отдельно.

Документация Microsoft описывает учёт срока в планировании и выбор по FEFO с учётом доступности и требований. Это пример модели, а не готовая настройка для любой компании: shelf life в Dynamics 365.

Правило выбора не должно оставаться тайной алгоритма. Кладовщик видит предложенную партию, доступное количество и основание: «самая ранняя дата среди подходящих». Если он выбирает другую, программа либо допускает это по роли и сохраняет причину, либо объясняет ограничение. Молчаливое автоматическое исправление сканирования запутывает фактическое движение.

Как описать данные и состояния

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

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

Для единицы учёта определите точность. Важна разница между календарной датой и моментом времени. Если на упаковке указана дата без часов, приложение не должно придумывать точный час окончания. Правило интерпретации, рабочая временная зона и момент проверки должны быть согласованы с ответственным за процесс.

Остаточный срок проверяют на нужную дату

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

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

В учебном расчёте клиент принимает товар только при остатке не менее 30 календарных дней на дату доставки. Доставка намечена на 20-е число. Система ищет партии, подходящие на эту дату, а не на дату создания заказа. Числа служат примером проверки программы и не являются рекомендацией для конкретной категории товаров.

При переносе доставки пересмотрите резерв. Ранее подходящая партия может перестать удовлетворять условию. Пользователь видит предупреждение до подтверждения нового обещания: «требуется другая партия» или «доступности недостаточно». Автоматическая замена допустима только в рамках согласованных правил и с сохранением истории.

Приёмка: получить дату без потери происхождения

Контроль начинается на входе. В ожидаемой поставке может быть указан артикул, но фактические партии становятся известны при приёмке. Интерфейс должен позволять разделить одну строку поставки на несколько партий, указать количество каждой и сопоставить данные упаковки. Запись одной даты на всю поставку часто стирает важные различия.

Сканирование сокращает ручной ввод только тогда, когда понятен формат кода. Стандарты GS1 разделяют идентификаторы данных, включая партии и даты; конкретный состав символов зависит от носителя и схемы. Программа должна разбирать поддерживаемый формат, а не искать похожие цифры в произвольной строке. Официальный справочник: GS1 Application Identifiers.

Покажите результат разбора до сохранения: распознанный товар, партия, дата и количество. Неизвестный код, неоднозначная дата и несовпадение с ожидаемым товаром требуют отдельного действия. Зелёный звук сканера не является доказательством правильной записи в ERP — нужно подтверждение сохранённого документа.

Исправление даты после приёмки должно оставлять след. Сохраните прежнее значение, новое, основание и пользователя. Если по партии уже есть резервы или отгрузки, покажите влияние изменения и список затронутых документов. Простая правка поля без пересмотра зависимостей делает отчётность внутренне противоречивой.

Резервирование и отбор на складе

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

При отборе проверяйте фактически отсканированную партию. Совпадения артикула недостаточно, если заказу назначена другая дата. Приложение показывает требуемую партию и допускаемые альтернативы, а изменение оформляет явной операцией. Если сотрудник берёт коробку из соседней ячейки, это должно отражаться в истории движения.

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

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

Что делать с коротким остатком и блокировками

Отчёт «скоро истекает» полезен, если из него следует действие. Разделите количество в свободном запасе, зарезервированное и заблокированное. Иначе менеджер увидит большую цифру, начнёт предлагать товар клиентам, а затем узнает, что почти всё уже относится к действующим заказам или не разрешено к продаже.

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

Блокировка — состояние с основанием, а не удаление остатка. Количество остаётся на складе, но исключается из доступности. Разблокировка также должна иметь автора и причину. Если заблокировать уже зарезервированную партию, система создаёт задачу на пересмотр обязательств, а не оставляет заказ со старым зелёным индикатором.

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

Возврат, перемещение и повторная приёмка

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

Межскладское перемещение сохраняет идентичность партии и её дату. На время перевозки количество может быть недоступно для обычного отбора. Если принимающий склад создаёт собственный внутренний номер, нужна связь с исходным номером, а не потеря происхождения. Это особенно важно при обмене между разными учётными системами.

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

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

Обмен ERP, WMS и интернет-магазина

Витрине обычно нужна продаваемая доступность, а не полный список партий. ERP или WMS рассчитывает количество с учётом действующих ограничений. Если магазин получает только общий физический остаток, он может принять заказ на заблокированный или неподходящий запас. Опишите контракт доступности и явно укажите, на какой сценарий доставки он рассчитан.

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

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

Предусмотрите сверку: общий остаток по товару равен сумме его партий в соответствующих состояниях и местах. Дополнительно сравнивайте резервы с доступным запасом. Разница должна попадать в очередь разбора с исходными документами, а не исправляться автоматической записью произвольного «остатка для баланса».

Приёмочные сценарии и полезные показатели

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

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

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

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

Как организовать разбор исключений

Для неизвестной даты, короткого остатка и несовпадения партии создавайте разные причины. У каждой есть ответственный и допустимое следующее действие. Общий список «ошибки склада» быстро становится свалкой: оператор не понимает, какие сведения уточнять, а руководитель не видит, что именно мешает исполнению заказов.

Карточка исключения связывает наблюдение, поставку, текущий запас и затронутые обязательства. Пользователь видит, что произошло, какое правило сработало и какие данные нужны для решения. После исправления запускается повторная проверка зависимостей. Изменённая дата без пересмотра резервов не закрывает проблему полностью.

Ручное разрешение должно быть ограничено областью и сроком. Если допущено исключение для одной отгрузки, оно не меняет правило товара для всех клиентов. Сохраняйте основание и принявшего решение сотрудника. В отчёте исключённые операции выделяются отдельно, чтобы их не принимали за обычное автоматическое исполнение.

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

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

Частые вопросы

Достаточно ли добавить дату в карточку товара?

Нет, если один артикул поступает разными партиями. Нужен разрез партий, их количества, мест и состояний. В карточке товара можно хранить общие правила контроля, но не заменять ими фактические даты каждой поставки.

Всегда ли нужно отгружать самую раннюю партию?

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

Можно ли автоматически рассчитать срок по дате изготовления?

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

Как действовать, если дата неизвестна?

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

Нужно ли передавать все партии на сайт магазина?

Обычно достаточно согласованной продаваемой доступности и подтверждения при оформлении. Полный партийный учёт остаётся в ERP или WMS. Главное — не выдавать общий физический остаток за гарантированную возможность исполнить любой заказ.

Связанные материалы

Для проектирования входящего процесса пригодится разбор приёмки товара, а для единичных объектов — учёт серийных номеров. Эти механизмы связаны, но партия и серийный экземпляр решают разные задачи.

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