Коммерческие ремонты в 1С:ERP: почему ТОИР и давальческая схема не подошли и что мы сделали вместо них
Типовой функционал 1С:ERP предлагает для коммерческих ремонтов два варианта — подсистему ТОИР и давальческую схему. Оба оказались неприменимы для предприятия, ремонтирующего 40–60 приборов в месяц. В этой статье рассказываем, как мы спроектировали единый АРМ «Заявка на ремонт» на базе документа «Производство без заказа» — без модификации стандартного функционала и с сохранением поддержки конфигурации.
Исходная ситуация
Если ваше предприятие выполняет коммерческие ремонты, и вы пытаетесь уложить этот процесс в типовые сценарии 1С:ERP — скорее всего, вы уже столкнулись с теми же ограничениями, что и наш клиент. Подсистема ТОИР не рассчитана на чужое оборудование, а давальческая схема требует создания шести объектов на каждый ремонт. Ниже — наш опыт решения этой задачи.
Предприятие — производитель датчиков и приборов — выполняет гарантийные и коммерческие ремонты собственной и сторонней продукции. Ежемесячный поток — от 40 до 60 единиц оборудования.
При этом заявку на ремонт и оплату нередко оформляют разные контрагенты, что дополнительно усложняет учёт.
До внедрения 1С:ERP процесс не был автоматизирован. Заявки фиксировались разрозненно, контроль статусов отсутствовал, а себестоимость ремонта оставалась «чёрным ящиком».
Что требовалось от системы
- Единый интерфейс для всех операций ремонта (приёмка, ремонт, отгрузка)
- Связь с ранее выпущенной продукцией через серийные номера
- Контроль серийных номеров как собственной, так и сторонней продукции
- Статусная модель ремонта с автоматической установкой дат
- Автоматическое списание материалов и выпуск отремонтированной продукции
- Разграничение прав по ролям: приёмщик, мастер по ремонту, логист
- Уведомления сотрудникам о новых заявках и смене статусов
- Отчётность: история ремонтов, оценка качества, анализ брака
Почему типовой функционал не подошёл
Перед разработкой мы проанализировали три возможных подхода к автоматизации в рамках 1С:ERP.
Вариант 1. Подсистема ТОИР
Подсистема ТОИР в 1С:ERP ориентирована на обслуживание собственного оборудования предприятия — станков, линий, инфраструктуры. Она оперирует объектами эксплуатации, графиками ППР и нарядами на ремонт.
Наш сценарий принципиально иной: предприятие ремонтирует чужое оборудование, поступающее от клиентов. Нужна связка с заказом клиента, контролем оплаты, выставлением актов реализации — всё то, чего ТОИР не предусматривает.
Вариант 2. Давальческая схема
1С:ERP позволяет учитывать коммерческие ремонты через давальческие заказы. Однако моделирование сценария показало, что эта схема чрезмерно трудоёмка.
Рис. 1. Сравнение трудоёмкости: давальческая схема vs АРМ «Заявка на ремонт»
Для одного ремонта оператору нужно создать три элемента НСИ и оформить три документа — итого 6 объектов вручную. При потоке в 40–60 ремонтов в месяц это создаёт высокий риск ошибок.
Кроме того, конечных пользователей такой схемы сложно обучить: от них требуется качественный ввод НСИ и последовательное создание документов в строго определённом порядке.
Вариант 3. Расширение конфигурации
Мы также оценивали подход с полноценным расширением конфигурации — созданием собственной подсистемы ремонтов с нуля, включая новые документы, регистры накопления и собственную логику проведения.
Этот вариант давал максимальную гибкость, но был отвергнут по двум причинам. Во-первых, значительно возрастал бы объём разработки и тестирования. Во-вторых, собственные движения по регистрам потребовали бы дублирования логики типового производственного учёта — а значит, при каждом обновлении конфигурации возникал бы риск рассогласования данных.
Выбранный подход: почему «Производство без заказа»
После отсеивания трёх вариантов мы сосредоточились на поиске типового документа, который можно использовать как «движок» для ремонтных операций — не изменяя его, а управляя им программными средствами.
Кандидатами были два документа подсистемы «Производство»: «Заказ на производство» + «Этап производства» и «Производство без заказа».
От связки «Заказ + Этап» отказались: заказчику было достаточно учёта по заказам клиента, создание отдельного производственного заказа на каждый ремонт перегружало систему и не давало дополнительной ценности.
Документ «Производство без заказа» оказался оптимальным выбором: он уже используется в других бизнес-процессах предприятия (пользователи с ним знакомы), покрывает требования по списанию материалов и выпуску продукции, фиксирует трудозатраты, и при этом не требует предварительного создания заказа на производство.
Принцип: типовой функционал не модифицирован. Все движения по регистрам делают стандартные документы. «Заявка на ремонт» — только агрегирует их.
Архитектура решения
Рис. 2. Схема объектов метаданных: «Заявка на ремонт» и связанные объекты
Документ «Заявка на ремонт» программно создаёт типовые документы, передавая в них нужные параметры. Оперативные данные о ходе ремонта хранятся в специально разработанном регистре.
Это даёт два преимущества: конфигурация остаётся на поддержке (обновления от 1С не конфликтуют с доработкой), а пользователи работают в едином окне.
Как работает АРМ «Заявка на ремонт»
Документ представляет собой единое рабочее место с четырьмя вкладками. Каждая вкладка соответствует этапу процесса и доступна только сотруднику с соответствующей ролью.
Рис. 3. Статусная модель ремонта с автоматическими действиями
Ниже — сквозной процесс ремонта с разделением по ролям. Жёлтым выделены автоматические действия системы.
Рис. 4. Сквозной процесс ремонта по ролям в АРМ
Приёмка оборудования
Приёмщик фиксирует контрагента, плательщика и договор. В табличной части указывает продукцию с серийным номером.
Если ремонт гарантийный, поля плательщика и договора обязательны. Система позволяет сразу указать оборудование на замену.
При создании заявки автоматически уходит уведомление мастеру сервисного отдела.
Рис. 5. Форма приёмки — реквизиты контрагента
Рис. 6. Гарантийный ремонт — обязательные поля
Рис. 7. Продукция с серийными номерами
Выполнение работ
После передачи в сервисный отдел дата фиксируется автоматически. Статус меняется с «Принят» на «В работе». Команда «Передать в ремонт» блокируется — защита от дублирования.
Мастер фиксирует использованные материалы по факту. По завершении система создаёт «Производство без заказа» с номером заявки в комментарии.
Рис. 8. Статус «В работе»
Рис. 9. Перечень использованных материалов
Рис. 10. Автоматически созданный документ
Рис. 11. Фиксация даты завершения
Отгрузка и актирование
Логист создаёт черновик реализации и перемещает изделие на склад отгрузки. Затем подтверждает проведение реализации и счёт-фактуры. Даты актирования автоматически появляются на вкладке «Принятые в ремонт».
Рис. 12. Черновик реализации
Рис. 13. Подтверждение реализации
Рис. 14. Итоговый вид заявки
Отчётность
«Оборудование в ремонте» — сводка по всем текущим заявкам: статусы, даты, ответственные, материалы. Контроль сроков и загрузки сервисного отдела.
«Отчёт по серийному номеру» — полная история ремонтов изделия. Выявление систематических дефектов и принятие решений по технологии.
Рис. 15. Отчёт «Оборудование в ремонте»
Рис. 16. Отчёт по серийному номеру
Результаты
| Показатель | До внедрения | После внедрения |
|---|---|---|
| Время оформления ремонта | 30 минут | 15 минут |
| Ручных операций на 1 ремонт | 6 объектов | 1 документ |
| Контроль статуса | Отсутствует | Да, в любой момент |
| Учёт себестоимости | Ручной расчёт | Автоматический |
| Срок разработки | — | 1 неделя |
Ключевые эффекты для бизнеса:
- Единая точка входа — все операции ремонта в одном документе
- Снижение ошибок — автоматическое создание типовых документов
- Прозрачность — руководство видит статус каждого ремонта и себестоимость
- Сохранение поддержки — типовой функционал не модифицирован
- Быстрое обучение — один интерфейс вместо цепочки из шести объектов
Подход МСП
Этот кейс иллюстрирует наш подход к нестандартным процессам в 1С:ERP: максимально использовать типовой функционал, оборачивая его в удобный пользовательский интерфейс.
Если у вас похожая задача — ремонтное производство, сервисное обслуживание, специфический учёт — мы готовы обсудить варианты решения.
