Документация/Работы и качество
РУКОВОДСТВО VYRAB

Работы и качество

Сдача работ, приёмка ОТК, дефекты и учёт времени.

Назначение

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

  • Приём работ — мастер/оператор отмечает фактически сданное количество по шагу маршрута заказа (создаёт запись 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.

Типовые сценарии

  1. Принять работу. Оператор находит свою строку (или фильтрует по заказу/операции), нажимает «Принять» → диалог «Принять работу»: список сотрудников с чекбоксами (у того, кто вошёл под своим логином и привязан к Employee, этот сотрудник уже отмечен), поле для быстрого добавления нового сотрудника прямо из диалога («+ Добавить», без выхода на страницу «Сотрудники»), поле «Сдано, шт» (по умолчанию — весь остаток), «Смена» (справочник смен либо свободный текст, если справочник пуст). После сохранения: шаг переходит «Ожидает → Выполняется» при первой сдаче и «Выполняется → Готово», когда сдано набирается до плана — тогда строка исчезает из списка.
  2. Отметить ОТК. После того как что-то сдано, на той же строке — кнопка «ОТК» → см. вкладку «Журнал» ОТК ниже.
  3. Исправить ошибочную сдачу. Из этой страницы недоступно — шаг, дошедший до «Готово», выпадает из списка вовсе. Открывается через раздел «Заказы» (Номенклатура и заказы): в детальной карточке заказа у каждого шага есть меню «Другие действия» → «Сдачи» (полный журнал сдач по шагу, включая уже сделанные исправления) и там же — «ОТК» (доступно и для шагов в статусе «Готово», в отличие от «Приём работ», где кнопка ОТК видна только пока шаг ещё не ушёл из списка).

Особенности и ограничения

  • Список общий по всему предприятию, без фильтра «мой участок» — на большом производстве это может быть длинный список; единственный способ сузить его — фильтр по тексту над таблицей.
  • Принять работу может кто угодно с work-records.view за любого сотрудника — привязка «Исполнитель» из графика (Производство и планирование) не проверяется и не ограничивает выбор работников в диалоге.
  • Исправление («Исправить» в «Сдачах») не редактирует и не удаляет исходную запись: добавляется новая с отрицательным количеством и причиной, исходная остаётся в журнале с пометкой, что её исправили; повторно исправить уже исправленную запись нельзя (кнопка пропадает).
  • Архивные сотрудники (см. «Сотрудники», Справочники и доступ) не предлагаются при новой приёмке/ОТК, но остаются видны в истории старых записей — архив не переписывает прошлое.

Цеховой терминал — режим Kiosk

Что видно

Полноэкранный режим без бокового меню, без окон-панелей и без инспектора объектов (см. Начало работы) — включается кнопкой «Режим терминала →» на странице «Приём работ» и выключается собственной кнопкой «← Выйти из режима терминала» внутри самого Kiosk. Стартовый экран — два больших квадратных пункта: «Приём работ» и «Информация о партии». Центральный элемент каждого шага внутри Kiosk — одно большое текстовое поле, которое всегда в фокусе (клик мимо или потеря фокуса возвращают курсор в него автоматически) и реагирует на нажатие Enter — под сканер штрихкода/RFID-считыватель, который эмулирует клавиатуру и сам шлёт Enter после кода. Обычная клавиатура работает точно так же — специального оборудования для тестирования не нужно.

Типовые сценарии

  1. Приём работ на терминале. Экран 1 — «Отсканируйте или введите код сотрудника» (ищет по полю «Код» в справочнике «Сотрудники», точное совпадение). Экран 2 — «Отсканируйте штрихкод партии (маршрутный лист)» — ищет по префиксу ID работ-заказа: печатная форма маршрутного листа кодирует его штрихкодом Code128 (без дефисов, первые 20 символов), этот же префикс сравнивается при сканировании. Если по партии остался ровно один несданный шаг — он выбирается автоматически; если больше одного — список кнопок с операциями (сданные — неактивны). Дальше — количество (по умолчанию весь остаток), смена, кнопка «Принять», работающая через тот же POST /api/work-records, что и обычный диалог на «Приёме работ», но всегда с одним работником — тем, кто идентифицировался в начале. Кнопки внизу: сканировать другую партию, сменить работника, выйти.
  2. Справка о партии без идентификации. «Информация о партии» — сканируется только код партии, без входа по сотруднику; показывает таблицу «Операция / Сдано / Всего / Статус» по всем шагам этой партии и ничего не записывает — предназначено для того, чтобы посмотреть, на каком этапе партия, не отмечаясь как исполнитель.

Особенности и ограничения

  • В Kiosk нет группового приёма (несколько работников на одну сдачу) — только один отсканированный/введённый сотрудник за раз, в отличие от обычного диалога «Принять работу».
  • В Kiosk нет функции ОТК вообще — только приёмка и информационный режим; отметить брак по-прежнему нужно на «Приёме работ»/«Заказах» в обычном (не киоск) интерфейсе.
  • Нет учёта времени начала/окончания работы на конкретном рабочем месте — это отдельный механизм (WorkSession, «Работа с заданиями», Производство и планирование), никак не связанный с этим экраном; приёмка в Kiosk фиксирует только итоговое количество, а не когда именно человек стоял у станка.
  • Нет автоматической выгрузки управляющей программы ЧПУ на терминал/ флешку при взятии задания в работу — то, что описано в легаси-статье про CNC-файлы, в Vyrab не реализовано.
  • Поиск партии по коду — совпадение по префиксу ID (не по отдельному печатному номеру партии), в масштабе одного предприятия коллизия практически исключена, но это не «настоящий» штрихкод товара, а закодированный внутренний идентификатор.

ОТК: брак (/defects) — вкладка «Журнал»

Что видно

Фильтр по датам (по умолчанию — последние 30 дней), счётчик «Записей о браке за период» рядом с кнопкой «Показать», таблица: Дата, Результат (Принято/Брак), Кол-во, Тип дефекта, Контролёр, Комментарий.

Типовые сценарии

  1. Новая запись создаётся не с этой вкладки, а из диалога «ОТК», открытого либо кнопкой на «Приёме работ» (шаг ещё не «Готово»), либо через «Заказы» → «Другие действия» → «ОТК» (шаг в любом статусе, в том числе «Готово»): переключатель Принято/Брак, обязательный выбор контролёра (из «Сотрудники»), количество (по умолчанию — вся сданная партия по шагу), при «Брак» — необязательный тип дефекта (справочник «Типы дефектов», Справочники и доступ) и предупреждение прямо в диалоге: «Забракованное количество спишется из сделанного — шаг вернётся в «Приём работ» на пересдачу этого количества»; свободный комментарий.
  2. Просмотр истории брака за период, фильтрация по датам, ручной пересчёт счётчика бракованных записей.

Особенности и ограничения

  • «Принято» — чисто фиксирующая отметка, никаких количеств не меняет (сдача уже засчитана самим фактом приёмки на «Приёме работ»).
  • «Брак» вычитает указанное количество из handed_qty шага; если шаг уже был «Готово», а после вычитания сданное стало меньше плана — шаг принудительно возвращается в статус «Выполняется» (единственный предусмотренный в системе «откат назад» статуса шага, специально заведённый под этот случай).
  • Каждая отметка «Брак» автоматически открывает ровно одно несоответствие на вкладке «Несоответствия» — прямой связи «журнал → несоответствие» на этой вкладке не показано, искать нужно там.
  • Ошибочную запись ОТК нельзя удалить или отредактировать «в лоб»: как и везде в этой фазе, действует только компенсирующая коррекция, доступная через POST /qc-records/{id}/correct — из показанного здесь UI прямого входа в эту функцию нет (для сторно нужно попасть на связанное несоответствие и убедиться, что по нему ещё ничего не утверждено).

ОТК: брак — вкладка «Несоответствия»

Что видно

Слева — таблица несоответствий: Операция (id шага, сокращённо), Кол-во, Распределено (сумма утверждённых решений), Статус (Открыто/Закрыто/ Отменено). Клик по строке открывает справа карточку: заголовок с id, статусом и кнопкой «Закрыть» (пока открыто), таблица уже принятых решений (Решение, Кол-во, Причина, Статус: Черновик/Утверждено/Сторно, и кнопка «Утвердить» или «Сторно» по статусу), под ней — форма добавления нового решения: тип (Доработка/Списание/Как есть/Перевод в другую номенклатуру), количество, для «Доработка» — обязательное поле «ID целевой операции» (обычный текстовый ввод, id шага-приёмника вставляется вручную, без подбора из списка), причина, кнопка «Добавить решение».

Типовые сценарии

  1. После отметки «Брак» контролёр открывает появившееся несоответствие, вводит одно или несколько решений на всё забракованное количество (например, часть — в доработку, часть — списать), нажимает «Утвердить» на каждом.
  2. Утверждение решения «Доработка» автоматически создаёт заказ на доработку — он появляется на вкладке «Доработка», отдельного действия для его создания нет.
  3. Утверждение решения «Как есть» возвращает количество обратно в сдачу шага (handed_qty увеличивается) — деталь признана годной без всякой переработки.
  4. Когда сумма утверждённых решений сравнялась с количеством несоответствия (и, если было решение «Доработка», соответствующий заказ дошёл до статуса «Готово») — доступна кнопка «Закрыть».

Особенности и ограничения

  • Несоответствие нельзя создать вручную — только автоматически из отметки «Брак»; на этой вкладке доступны только операции над уже открытыми записями.
  • Только решение «Как есть» физически меняет количество сдачи (в обе стороны — утверждение прибавляет, сторно отнимает обратно); «Списание» и «Перевод в другую номенклатуру» в текущей реализации никакого автоматического эффекта на handed_qty не производят — это учётные пометки без побочного действия.
  • Сумма утверждённых решений не может превысить количество самого несоответствия — попытка утвердить решение сверх остатка отклоняется сервером.
  • «Закрыть» заблокировано, пока по несоответствию есть утверждённое решение «Доработка» с ещё не завершённым (не «Готово») заказом — нельзя закрыть несоответствие, не дождавшись результата доработки.
  • Поле «ID целевой операции» для доработки — сырой текст, а не выбор из дерева заказа; id шага нужно скопировать заранее (например, из инспектора объектов, Начало работы, или из адресной строки карточки заказа).

ОТК: брак — вкладка «Доработка»

Что видно

Слева — таблица заказов на доработку: Целевая операция (id, сокращённо), Кол-во, Статус (Черновик/Выпущен/В работе/Ожидает контроля/Готово/ Отменён). Справа, по клику на строку — карточка заказа: id, статус, кнопка перехода в следующий статус («В работу», затем «На контроль»), строка с id связанного шага доработки, таблица уже созданных сменных заданий (Дата/Участок/План), форма добавления задания (Участок и Смена — свободный текст, а не выбор из справочников участков/смен, Дата, Кол-во, кнопка «+ Задание на доработку») и — в статусе «Ожидает контроля» — форма повторного контроля: переключатель Принято/Брак, контролёр, при «Брак» — тип дефекта, комментарий, кнопка «Повторный контроль».

Типовые сценарии

  1. Заказ появляется на вкладке уже в статусе «Выпущен» (сразу после утверждения решения «Доработка» на предыдущей вкладке — «Черновик» в реальности не встречается, создание сразу минует этот статус). Мастер добавляет одно или несколько сменных заданий на доработку (участок, смена, дата, плановое количество) и переводит заказ «В работу».
  2. Когда доработка физически выполнена — заказ переводится «На контроль», и контролёр проводит повторную инспекцию: «Принято» закрывает заказ («Готово», после чего на вкладке «Несоответствия» становится возможно закрыть само несоответствие), «Брак» возвращает заказ в «В работе» — цикл может повторяться, пока доработка не будет принята.

Особенности и ограничения

  • В одном заказе на доработку — всегда ровно один шаг доработки (ReworkStep); многошаговый маршрут доработки не поддерживается.
  • Поля «Участок» и «Смена» при добавлении сменного задания — свободный текст, без валидации по справочникам «Участки»/«Смены» (в отличие от большинства других мест приложения, где эти значения выбираются из списка) — опечатка не будет поймана на этом экране.
  • Повторный брак не заводит новое несоответствие — тот же заказ на доработку просто возвращается «в работу» для следующей попытки.

ОТК: брак — вкладка «Статистика»

Что видно

Фильтр по датам (по умолчанию — 30 дней) и после «Показать» — шесть плиток: Выход годного с первого раза, % (first pass yield), Проверено, Принято, Брак, Открытых несоответствий, Отклонено при повторном контроле; ниже — таблица Pareto по видам брака (Вид брака / Кол-во) и список «Заказы на доработку по статусам» (счётчик по каждому статусу).

Типовые сценарии

Контролёр или мастер периодически проверяет тренд по участку/периоду: резкое падение «Выхода годного с первого раза» или рост определённого вида брака в Pareto — сигнал разобраться, что пошло не так; список по статусам доработки показывает, не скапливаются ли заказы в «Ожидает контроля» (значит, повторный контроль отстаёт от факта доработки).

Особенности и ограничения

  • Статистика намеренно минимальна: нет разбивки по участку, оборудованию, поставщику материала или времени закрытия несоответствия — это сознательно оставлено вне рамок текущей реализации, а не забытая функция.
  • «Отклонено при повторном контроле» считает только случаи брака именно на повторной инспекции доработки (вкладка «Доработка»), а не брак вообще — это отдельное число от общего счётчика «Брак» выше.
  • Более детальный статистический контроль процесса (контрольные карты I-MR, Cp/Cpk по числовым параметрам измерений ОТК) — не здесь, а на вкладке SPC раздела «Аналитика» (Обзор и аналитика), которая использует те же QcRecord/QualityMeasurement.

Табель (/timesheet)

Что видно

Фильтр по датам (по умолчанию — последние 30 дней), кнопка «Показать» и кнопка экспорта в Excel; если у оператора нет права timesheet.view_all — поясняющая строка «Показан только ваш табель — нет права «видеть все»». Таблица: Работник, Дата, Часы, Минуты, Отметок (сколько отдельных сдач попало в сумму за этот день).

Типовые сценарии

  1. Экономист с timesheet.view_all смотрит табель по всем сотрудникам за расчётный период, выгружает в Excel (tabel_<от>_<до>.xlsx, отдельный файл, не общий CSV-экспорт таблицы) для дальнейшего расчёта зарплаты.
  2. Мастер участка без 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, что показывает и «Табель».
  • Справочники и доступ — справочники «Сотрудники» (не путать с «Операторы» — логинами), «Смены», «Типы дефектов», используемые во всех диалогах этой фазы.