Цех окраски: заказ клиента и партия обработки

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

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

Заказ и партия отвечают на разные вопросы

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

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

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

Сначала совместимость, затем подсчёт вместимости

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

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

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

Готовность к этапу хранится отдельно

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

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

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

Зафиксируйте состав фактического запуска

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

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

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

Завершение партии не делает все детали принятыми

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

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

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

Отгрузка является следующим событием

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

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

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

У сводки должен быть момент наблюдения

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

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

Проверка программы на небольшом наборе

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

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

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