Работы и качество
Сдача работ, приёмка ОТК, дефекты и учёт времени.
Назначение
Эта фаза — исполнительный контур производства: здесь фиксируется, что реально сделано в цехе (в отличие от Производство и планирование, где формируются задания — что должно быть сделано). Три связанных процесса:
- Приём работ — мастер/оператор отмечает фактически сданное количество по шагу маршрута заказа (создаёт запись WorkRecord, см. глоссарий Начало работы); отсюда же — переход в режим цехового терминала (Kiosk) для установки на ПК прямо в цехе.
- ОТК: брак — контроль качества сданного: приёмка или брак (QcRecord), работа с открывшимися несоответствиями (Nonconformance → решение QualityDisposition: доработка/ списание/как есть/перевод), доработка брака по замкнутому циклу (ReworkOrder) и сводная статистика/Pareto по видам брака.
- Табель — агрегация того же журнала WorkRecord по работнику и дню (часы по норме, число отметок) для расчёта выработки/зарплаты.
Все три экрана читают и пишут один и тот же append-only журнал WorkRecord/QcRecord — ничего в нём не перезаписывается и не удаляется, исправления (сторно, коррекция ОТК) всегда добавляют новую компенсирующую запись, ссылающуюся на исходную.
Кто использует (роли)
Роли и права подробно описаны в Начало работы («Роли и права (RBAC)») — здесь только то, что относится к этой фазе:
| Роль | Что видит/делает здесь |
|---|---|
| Администратор | Всё |
| Мастер участка | Приём работ, режим терминала, сторно сдачи (work-records.correct), ОТК-отметки (qc.write), все вкладки «ОТК: брак», Табель — только свой (нет timesheet.view_all) |
| Контролёр ОТК | Видит «Приём работ» (work-records.view), но принимать работу может так же, как и любой обладатель этого права; основная задача — ОТК-отметки и все вкладки «ОТК: брак» (qc.write, defects.view). Без work-records.correct — сторно сдачи ей недоступно |
| Оператор цеха | Только «Приём работ» (work-records.view) — видит список, принимает работу, но кнопка «ОТК» и сторно ей недоступны |
| Экономист | Только «Табель» (timesheet.view), и только с timesheet.view_all видит табель всех сотрудников, иначе — только свой (сопоставление по Employee.platform_user_id) |
Как и в Начало работы: qc.write — отдельное право внутри «Приём работ»/«ОТК:
брак», не совпадающее с правом на просмотр самих разделов
(work-records.view и defects.view соответственно); work-records.correct
— отдельное право на сторно. Права также проверяются на сервере: вкладки «Несоответствия» и
«Доработка», а
также сам журнал ОТК целиком требуют qc.write —
право defects.view, которое открывает пункт меню «ОТК: брак», само по
себе действий на этих трёх вкладках не разрешает; на практике обе роли,
которым видна страница (Мастер участка, Контролёр ОТК), имеют оба права
одновременно.
Основные понятия
| Термин | Значение |
|---|---|
| WorkRecord (сдача) | См. глоссарий Начало работы — неизменяемая запись «работник(и) сдал(и) столько-то по шагу в такую-то смену». Каждый сданный работник получает полную нормативную трудоёмкость (Тман × количество), а не долю от неё — сдача бригадой из трёх человек не делит норму на троих, а начисляет её каждому |
| Сотрудник (Employee) | Физический работник цеха, который сдаёт/принимает работу или значится исполнителем ОТК — справочник «Сотрудники» (Справочники, Справочники и доступ). Это не то же самое, что «Оператор» — логин для входа в Vyrab (Начало работы); у большинства сотрудников логина нет вовсе. Связь Employee.platform_user_id — необязательная, используется только для автоподстановки «своего» сотрудника при приёмке |
| QcRecord (отметка ОТК) | Результат контроля партии/количества по шагу: «Принято» (ничего не меняет — сдача уже засчитана) или «Брак» (списывает забракованное количество из уже сданного, шаг при необходимости возвращается из «Готово» в «Выполняется») |
| Nonconformance (несоответствие) | Открывается автоматически при каждой отметке «Брак» — самостоятельно его создать нельзя. Живёт, пока по нему не распределено полное количество через решения |
| QualityDisposition (решение) | Решение по несоответствию: доработка, списание, «как есть» (брак признан годным, количество возвращается в сдачу) или перевод в другую номенклатуру. Черновик → утверждено (действие применяется) → при необходимости сторно |
| ReworkOrder / ReworkStep (заказ на доработку) | Создаётся автоматически при утверждении решения «Доработка» — заводить его вручную нельзя. Один заказ — один шаг доработки; жизненный цикл: выпущен → в работе → на контроле → готово (или отменён) |
| Режим терминала (Kiosk) | Отдельный полноэкранный режим без меню и окон — см. Начало работы |
| Табель | Не отдельный журнал, а агрегат журнала WorkRecord по (сотрудник, дата) — своей сущности не имеет |
Приём работ (/work-records)
Что видно
Таблица со всеми ещё не полностью сданными шагами по всем незавершённым
заказам (GET /api/worklist — плоский список, без разбивки по участкам):
№ заказа, Изделие, Операция, Исполнитель (кому назначен шаг в графике,
Производство и планирование — необязательно тот же человек, что сдаёт), Осталось (= план минус
уже сдано), Статус (Ожидает/Выполняется/Готово), и в последней колонке —
кнопки «Принять» и «ОТК» (последняя недоступна, пока по шагу не
сдано ни одной единицы). Над таблицей — поле фильтра и кнопка «Режим
терминала →» в правом верхнем углу, переключающая всё приложение в
полноэкранный Kiosk.
Типовые сценарии
- Принять работу. Оператор находит свою строку (или фильтрует по заказу/операции), нажимает «Принять» → диалог «Принять работу»: список сотрудников с чекбоксами (у того, кто вошёл под своим логином и привязан к Employee, этот сотрудник уже отмечен), поле для быстрого добавления нового сотрудника прямо из диалога («+ Добавить», без выхода на страницу «Сотрудники»), поле «Сдано, шт» (по умолчанию — весь остаток), «Смена» (справочник смен либо свободный текст, если справочник пуст). После сохранения: шаг переходит «Ожидает → Выполняется» при первой сдаче и «Выполняется → Готово», когда сдано набирается до плана — тогда строка исчезает из списка.
- Отметить ОТК. После того как что-то сдано, на той же строке — кнопка «ОТК» → см. вкладку «Журнал» ОТК ниже.
- Исправить ошибочную сдачу. Из этой страницы недоступно — шаг, дошедший до «Готово», выпадает из списка вовсе. Открывается через раздел «Заказы» (Номенклатура и заказы): в детальной карточке заказа у каждого шага есть меню «Другие действия» → «Сдачи» (полный журнал сдач по шагу, включая уже сделанные исправления) и там же — «ОТК» (доступно и для шагов в статусе «Готово», в отличие от «Приём работ», где кнопка ОТК видна только пока шаг ещё не ушёл из списка).
Особенности и ограничения
- Список общий по всему предприятию, без фильтра «мой участок» — на большом производстве это может быть длинный список; единственный способ сузить его — фильтр по тексту над таблицей.
- Принять работу может кто угодно с
work-records.viewза любого сотрудника — привязка «Исполнитель» из графика (Производство и планирование) не проверяется и не ограничивает выбор работников в диалоге. - Исправление («Исправить» в «Сдачах») не редактирует и не удаляет исходную запись: добавляется новая с отрицательным количеством и причиной, исходная остаётся в журнале с пометкой, что её исправили; повторно исправить уже исправленную запись нельзя (кнопка пропадает).
- Архивные сотрудники (см. «Сотрудники», Справочники и доступ) не предлагаются при новой приёмке/ОТК, но остаются видны в истории старых записей — архив не переписывает прошлое.
Цеховой терминал — режим Kiosk
Что видно
Полноэкранный режим без бокового меню, без окон-панелей и без инспектора объектов (см. Начало работы) — включается кнопкой «Режим терминала →» на странице «Приём работ» и выключается собственной кнопкой «← Выйти из режима терминала» внутри самого Kiosk. Стартовый экран — два больших квадратных пункта: «Приём работ» и «Информация о партии». Центральный элемент каждого шага внутри Kiosk — одно большое текстовое поле, которое всегда в фокусе (клик мимо или потеря фокуса возвращают курсор в него автоматически) и реагирует на нажатие Enter — под сканер штрихкода/RFID-считыватель, который эмулирует клавиатуру и сам шлёт Enter после кода. Обычная клавиатура работает точно так же — специального оборудования для тестирования не нужно.
Типовые сценарии
- Приём работ на терминале. Экран 1 — «Отсканируйте или введите код
сотрудника» (ищет по полю «Код» в справочнике «Сотрудники», точное
совпадение). Экран 2 — «Отсканируйте штрихкод партии (маршрутный
лист)» — ищет по префиксу ID работ-заказа: печатная форма маршрутного
листа кодирует его штрихкодом Code128 (без дефисов, первые 20 символов),
этот же префикс сравнивается при сканировании. Если по партии остался
ровно один несданный шаг — он выбирается автоматически; если больше
одного — список кнопок с операциями (сданные — неактивны). Дальше —
количество (по умолчанию весь остаток), смена, кнопка «Принять»,
работающая через тот же
POST /api/work-records, что и обычный диалог на «Приёме работ», но всегда с одним работником — тем, кто идентифицировался в начале. Кнопки внизу: сканировать другую партию, сменить работника, выйти. - Справка о партии без идентификации. «Информация о партии» — сканируется только код партии, без входа по сотруднику; показывает таблицу «Операция / Сдано / Всего / Статус» по всем шагам этой партии и ничего не записывает — предназначено для того, чтобы посмотреть, на каком этапе партия, не отмечаясь как исполнитель.
Особенности и ограничения
- В Kiosk нет группового приёма (несколько работников на одну сдачу) — только один отсканированный/введённый сотрудник за раз, в отличие от обычного диалога «Принять работу».
- В Kiosk нет функции ОТК вообще — только приёмка и информационный режим; отметить брак по-прежнему нужно на «Приёме работ»/«Заказах» в обычном (не киоск) интерфейсе.
- Нет учёта времени начала/окончания работы на конкретном рабочем месте — это отдельный механизм (WorkSession, «Работа с заданиями», Производство и планирование), никак не связанный с этим экраном; приёмка в Kiosk фиксирует только итоговое количество, а не когда именно человек стоял у станка.
- Нет автоматической выгрузки управляющей программы ЧПУ на терминал/ флешку при взятии задания в работу — то, что описано в легаси-статье про CNC-файлы, в Vyrab не реализовано.
- Поиск партии по коду — совпадение по префиксу ID (не по отдельному печатному номеру партии), в масштабе одного предприятия коллизия практически исключена, но это не «настоящий» штрихкод товара, а закодированный внутренний идентификатор.
ОТК: брак (/defects) — вкладка «Журнал»
Что видно
Фильтр по датам (по умолчанию — последние 30 дней), счётчик «Записей о браке за период» рядом с кнопкой «Показать», таблица: Дата, Результат (Принято/Брак), Кол-во, Тип дефекта, Контролёр, Комментарий.
Типовые сценарии
- Новая запись создаётся не с этой вкладки, а из диалога «ОТК», открытого либо кнопкой на «Приёме работ» (шаг ещё не «Готово»), либо через «Заказы» → «Другие действия» → «ОТК» (шаг в любом статусе, в том числе «Готово»): переключатель Принято/Брак, обязательный выбор контролёра (из «Сотрудники»), количество (по умолчанию — вся сданная партия по шагу), при «Брак» — необязательный тип дефекта (справочник «Типы дефектов», Справочники и доступ) и предупреждение прямо в диалоге: «Забракованное количество спишется из сделанного — шаг вернётся в «Приём работ» на пересдачу этого количества»; свободный комментарий.
- Просмотр истории брака за период, фильтрация по датам, ручной пересчёт счётчика бракованных записей.
Особенности и ограничения
- «Принято» — чисто фиксирующая отметка, никаких количеств не меняет (сдача уже засчитана самим фактом приёмки на «Приёме работ»).
- «Брак» вычитает указанное количество из
handed_qtyшага; если шаг уже был «Готово», а после вычитания сданное стало меньше плана — шаг принудительно возвращается в статус «Выполняется» (единственный предусмотренный в системе «откат назад» статуса шага, специально заведённый под этот случай). - Каждая отметка «Брак» автоматически открывает ровно одно несоответствие на вкладке «Несоответствия» — прямой связи «журнал → несоответствие» на этой вкладке не показано, искать нужно там.
- Ошибочную запись ОТК нельзя удалить или отредактировать «в лоб»: как и
везде в этой фазе, действует только компенсирующая коррекция, доступная
через
POST /qc-records/{id}/correct— из показанного здесь UI прямого входа в эту функцию нет (для сторно нужно попасть на связанное несоответствие и убедиться, что по нему ещё ничего не утверждено).
ОТК: брак — вкладка «Несоответствия»
Что видно
Слева — таблица несоответствий: Операция (id шага, сокращённо), Кол-во, Распределено (сумма утверждённых решений), Статус (Открыто/Закрыто/ Отменено). Клик по строке открывает справа карточку: заголовок с id, статусом и кнопкой «Закрыть» (пока открыто), таблица уже принятых решений (Решение, Кол-во, Причина, Статус: Черновик/Утверждено/Сторно, и кнопка «Утвердить» или «Сторно» по статусу), под ней — форма добавления нового решения: тип (Доработка/Списание/Как есть/Перевод в другую номенклатуру), количество, для «Доработка» — обязательное поле «ID целевой операции» (обычный текстовый ввод, id шага-приёмника вставляется вручную, без подбора из списка), причина, кнопка «Добавить решение».
Типовые сценарии
- После отметки «Брак» контролёр открывает появившееся несоответствие, вводит одно или несколько решений на всё забракованное количество (например, часть — в доработку, часть — списать), нажимает «Утвердить» на каждом.
- Утверждение решения «Доработка» автоматически создаёт заказ на доработку — он появляется на вкладке «Доработка», отдельного действия для его создания нет.
- Утверждение решения «Как есть» возвращает количество обратно в сдачу
шага (
handed_qtyувеличивается) — деталь признана годной без всякой переработки. - Когда сумма утверждённых решений сравнялась с количеством несоответствия (и, если было решение «Доработка», соответствующий заказ дошёл до статуса «Готово») — доступна кнопка «Закрыть».
Особенности и ограничения
- Несоответствие нельзя создать вручную — только автоматически из отметки «Брак»; на этой вкладке доступны только операции над уже открытыми записями.
- Только решение «Как есть» физически меняет количество сдачи (в обе
стороны — утверждение прибавляет, сторно отнимает обратно); «Списание»
и «Перевод в другую номенклатуру» в текущей реализации никакого
автоматического эффекта на
handed_qtyне производят — это учётные пометки без побочного действия. - Сумма утверждённых решений не может превысить количество самого несоответствия — попытка утвердить решение сверх остатка отклоняется сервером.
- «Закрыть» заблокировано, пока по несоответствию есть утверждённое решение «Доработка» с ещё не завершённым (не «Готово») заказом — нельзя закрыть несоответствие, не дождавшись результата доработки.
- Поле «ID целевой операции» для доработки — сырой текст, а не выбор из дерева заказа; id шага нужно скопировать заранее (например, из инспектора объектов, Начало работы, или из адресной строки карточки заказа).
ОТК: брак — вкладка «Доработка»
Что видно
Слева — таблица заказов на доработку: Целевая операция (id, сокращённо), Кол-во, Статус (Черновик/Выпущен/В работе/Ожидает контроля/Готово/ Отменён). Справа, по клику на строку — карточка заказа: id, статус, кнопка перехода в следующий статус («В работу», затем «На контроль»), строка с id связанного шага доработки, таблица уже созданных сменных заданий (Дата/Участок/План), форма добавления задания (Участок и Смена — свободный текст, а не выбор из справочников участков/смен, Дата, Кол-во, кнопка «+ Задание на доработку») и — в статусе «Ожидает контроля» — форма повторного контроля: переключатель Принято/Брак, контролёр, при «Брак» — тип дефекта, комментарий, кнопка «Повторный контроль».
Типовые сценарии
- Заказ появляется на вкладке уже в статусе «Выпущен» (сразу после утверждения решения «Доработка» на предыдущей вкладке — «Черновик» в реальности не встречается, создание сразу минует этот статус). Мастер добавляет одно или несколько сменных заданий на доработку (участок, смена, дата, плановое количество) и переводит заказ «В работу».
- Когда доработка физически выполнена — заказ переводится «На контроль», и контролёр проводит повторную инспекцию: «Принято» закрывает заказ («Готово», после чего на вкладке «Несоответствия» становится возможно закрыть само несоответствие), «Брак» возвращает заказ в «В работе» — цикл может повторяться, пока доработка не будет принята.
Особенности и ограничения
- В одном заказе на доработку — всегда ровно один шаг доработки
(
ReworkStep); многошаговый маршрут доработки не поддерживается. - Поля «Участок» и «Смена» при добавлении сменного задания — свободный текст, без валидации по справочникам «Участки»/«Смены» (в отличие от большинства других мест приложения, где эти значения выбираются из списка) — опечатка не будет поймана на этом экране.
- Повторный брак не заводит новое несоответствие — тот же заказ на доработку просто возвращается «в работу» для следующей попытки.
ОТК: брак — вкладка «Статистика»
Что видно
Фильтр по датам (по умолчанию — 30 дней) и после «Показать» — шесть плиток: Выход годного с первого раза, % (first pass yield), Проверено, Принято, Брак, Открытых несоответствий, Отклонено при повторном контроле; ниже — таблица Pareto по видам брака (Вид брака / Кол-во) и список «Заказы на доработку по статусам» (счётчик по каждому статусу).
Типовые сценарии
Контролёр или мастер периодически проверяет тренд по участку/периоду: резкое падение «Выхода годного с первого раза» или рост определённого вида брака в Pareto — сигнал разобраться, что пошло не так; список по статусам доработки показывает, не скапливаются ли заказы в «Ожидает контроля» (значит, повторный контроль отстаёт от факта доработки).
Особенности и ограничения
- Статистика намеренно минимальна: нет разбивки по участку, оборудованию, поставщику материала или времени закрытия несоответствия — это сознательно оставлено вне рамок текущей реализации, а не забытая функция.
- «Отклонено при повторном контроле» считает только случаи брака именно на повторной инспекции доработки (вкладка «Доработка»), а не брак вообще — это отдельное число от общего счётчика «Брак» выше.
- Более детальный статистический контроль процесса (контрольные карты I-MR, Cp/Cpk по числовым параметрам измерений ОТК) — не здесь, а на вкладке SPC раздела «Аналитика» (Обзор и аналитика), которая использует те же QcRecord/QualityMeasurement.
Табель (/timesheet)
Что видно
Фильтр по датам (по умолчанию — последние 30 дней), кнопка «Показать» и
кнопка экспорта в Excel; если у оператора нет права timesheet.view_all
— поясняющая строка «Показан только ваш табель — нет права «видеть все»».
Таблица: Работник, Дата, Часы, Минуты, Отметок (сколько отдельных сдач
попало в сумму за этот день).
Типовые сценарии
- Экономист с
timesheet.view_allсмотрит табель по всем сотрудникам за расчётный период, выгружает в Excel (tabel_<от>_<до>.xlsx, отдельный файл, не общий CSV-экспорт таблицы) для дальнейшего расчёта зарплаты. - Мастер участка без
timesheet.view_allоткрывает «Табель» и видит только свои собственные отметки (по связкеEmployee.platform_user_id↔ вошедший оператор) — удобно свериться со своей же выработкой, но не с чужой.
Особенности и ограничения
- Табель — не отдельно вводимые данные, а агрегат того же журнала WorkRecord, который наполняется на «Приёме работ»: строка появляется, как только по сотруднику есть хотя бы одна сдача за день; никакого собственного экрана ввода часов нет.
- «Часы» = нормативное время (Тман × сдано), а не фактически отработанное — при групповой сдаче (несколько сотрудников на одну запись, см. «Приём работ») каждый участник получает в свой табель полную норму по этой сдаче, а не долю от неё; сумма часов по бригаде за смену в табеле может заметно превышать длительность самой смены.
- Исправленные (сторнированные) сдачи учтены automatически: компенсирующая запись с отрицательным количеством уменьшает то же (сотрудник, дата) — отдельно проведённые исправления в табеле не видны как отдельная строка, только их итоговый эффект на сумму.
- Экспорт в Excel — единственный формат выгрузки для этого раздела
(унаследовано из легаси-VOGBIT); обычная CSV-кнопка таблицы
(
DataTable) для табеля недоступна.
Связанные разделы
- Начало работы — роли и права (в т.ч.
разбор
qc.write/work-records.correct), режим Kiosk как общий механизм окон, глоссарий (WorkRecord, ОТК). - Обзор и аналитика — виджеты «К сдаче на участках», «Брак за 7 дней», «Незакрытые несоответствия», вкладка SPC «Аналитики» — построены на тех же WorkRecord/QcRecord/Nonconformance, что и эта фаза.
- Производство и планирование — «График производства»
создаёт шаги (
OrderOperationStep), которые здесь принимаются и проверяются; «Работа с заданиями» — WorkSession (учёт времени начала/ окончания на рабочем месте), отдельный от WorkRecord механизм, не путать. - Номенклатура и заказы — «Заказы»: детальная карточка заказа — второй, помимо «Приёма работ», путь к ОТК и истории сдач («Другие действия» → «ОТК»/«Сдачи»), единственный путь к ОТК на уже «Готовых» шагах.
- Себестоимость и цены — себестоимость труда считается по тому же нормативному времени (Тман × сдано) из WorkRecord, что показывает и «Табель».
- Справочники и доступ — справочники «Сотрудники» (не путать с «Операторы» — логинами), «Смены», «Типы дефектов», используемые во всех диалогах этой фазы.