Переделки на производстве: попытки не равны выпуску

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

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

Проверьте показатели одной партии

В примере первая попытка была у всех десяти единиц, повторная — у двух. Финальный принятый выпуск составляет десять уникальных изделий. Отдельный показатель первых предъявлений даёт восемь принятых из десяти, то есть 80%. Эти числа отвечают на разные вопросы. Значение 100% по окончательному результату не означает, что повторной работы не было.

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

Четыре объекта учёта вместо общего статуса

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

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

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

Повтор должен сохранить свою причину

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

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

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

Изменённое задание и ошибка записи — отдельные случаи

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

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

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

Не теряйте остаток частично принятой партии

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

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

Отчёт должен раскрывать знаменатель

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

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

Расход на повтор не выводится из числа готовых изделий

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

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

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

Что проверить до запуска системы

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

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