Остаток по партиям: требование к сроку годности клиента

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

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

Разберите нехватку при большом общем остатке

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

Такой результат нельзя объяснять сообщением «товара нет». Товар есть, но часть не соответствует выбранному условию, а по части данных недостаточно. Сотруднику нужны причины и конкретные партии. Иначе он начнёт искать физическую недостачу или исправлять общий остаток, хотя проблема находится в правилах подбора.

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

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

Дата товара и требование клиента — разные данные

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

Разделение партии и даты встречается и в стандартах идентификации. В официальном наборе идентификаторов GS1 AI 10 обозначает номер партии, а AI 17 — дату окончания срока. Это разные атрибуты. Наличие кода на упаковке само по себе не подтверждает, что ваш сканер и программа корректно извлекают все необходимые значения.

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

На какой момент нужен остаточный срок

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

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

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

Отбор требует конкретного состава

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

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

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

Изменение количества не исправляет качество данных

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

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

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

Повтор заказа не копирует прежнее подтверждение

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

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

Минимальный набор приёмки

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

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

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