Когда сервис обслуживает крупного заказчика, отчётность о работах перестаёт быть внутренним делом: заказчик ведёт собственный учёт оборудования и хочет получать данные в свою систему, в своём формате и в оговорённые сроки. От качества этого обмена зависят и приёмка работ, и оплата. Разберём, как выстроить передачу и чем защититься от расхождений.
Зачем заказчику эти данные
- подтверждение выполнения обязательств по договору обслуживания;
- ведение истории по своему оборудованию;
- контроль соблюдения сроков реакции и восстановления;
- основание для оплаты;
- учёт затрат на содержание оборудования;
- планирование замены и модернизации.
Понимание цели определяет состав данных. Если заказчику нужен только факт выполнения — достаточно акта; если он ведёт историю надёжности — нужны причины отказов и заменённые узлы.
Что обычно передаётся
| Блок | Состав |
|---|---|
| Идентификация | Номер заявки у исполнителя и у заказчика, объект, адрес |
| Сроки | Регистрация, реакция, начало, завершение работ |
| Содержание | Выполненные работы, дефект, причина |
| Материалы | Запчасти с артикулами и количеством, снятые узлы |
| Трудозатраты | Исполнители, часы |
| Стоимость | Работы, материалы, итог |
| Подтверждения | Подпись представителя, фотоматериалы |
Первая строка содержит ключевую деталь: у заявки два номера. Заказчик оперирует своим, исполнитель своим, и их сопоставление должно храниться, иначе разбор любого спорного случая превращается в ручной поиск.
Форматы и способы передачи
- Веб-сервис заказчика. Исполнитель отправляет данные в интерфейс приёма. Наиболее контролируемый вариант: есть подтверждение приёма и код ошибки.
- Приём данных на стороне исполнителя. Заказчик сам забирает данные из опубликованного интерфейса.
- Структурированные файлы. Выгрузка по расписанию в согласованном формате. Просто, но нет подтверждения доставки.
- Электронный документооборот. Для юридически значимых документов — акты и счета.
- Портал заказчика. Ручной ввод оператором — рабочий вариант при малых объёмах и худший при больших.
Последний вариант встречается чаще, чем хотелось бы: сервис вводит данные в чужой портал руками, дублируя собственный учёт. Если объём заявок значителен, автоматизация этого ввода окупается быстро.
Сопоставление справочников — главная сложность
Технический обмен настраивается за дни, сопоставление справочников занимает недели. Три критичные точки:
- Оборудование. У заказчика свои инвентарные номера, у исполнителя свои карточки. Нужна таблица соответствия и правило для нового оборудования.
- Работы. Классификатор заказчика редко совпадает с вашим. Требуется сопоставление, а иногда — ведение работ сразу в его кодировке.
- Запчасти. Артикулы производителя, внутренние коды исполнителя и коды заказчика — три системы обозначений.
Практическая рекомендация: сопоставление ведётся в системе как справочник, а не как фильтр в коде выгрузки. Тогда добавление новой позиции — задача оператора, а не программиста.
Контроль качества передачи
- Проверка полноты до отправки. Обязательные для заказчика поля контролируются при закрытии наряда, а не при выгрузке.
- Подтверждение приёма. Фиксируется в системе с отметкой времени.
- Обработка отказов. Отклонённая запись попадает в список на исправление с указанием причины и ответственного.
- Контрольные суммы за период. Количество переданных заявок и итоговая сумма сверяются с данными заказчика.
- Регулярная сверка. Ежемесячный акт сверки по количеству и суммам до выставления счетов.
- Журнал обмена. С возможностью повторной отправки конкретной записи.
Первый пункт экономит больше всего сил. Если поле обязательно для заказчика, оно должно быть обязательным при закрытии наряда — иначе мастер уже уехал, а данные нужно восстанавливать.
Что зафиксировать в договоре
- состав передаваемых данных и формат;
- сроки передачи после выполнения работ;
- порядок сопоставления справочников и обновления соответствий;
- процедуру при отклонении данных и срок на исправление;
- порядок сверки и разрешения расхождений;
- ответственность сторон за недоступность интерфейсов обмена.
Итог
Передача данных о выполненных работах заказчику упирается не в протокол, а в сопоставление справочников оборудования, работ и запчастей — его нужно вести как справочник в системе, а не зашивать в код выгрузки. Обязательные для заказчика поля должны контролироваться при закрытии наряда, а не при выгрузке, а подтверждение приёма и регулярная сверка по контрольным суммам защищают от расхождений, которые иначе всплывают при оплате.
Формирование отчётности по выполненным работам для передачи заказчику есть в решении «1С:Сервисный Ремонт».
Компания «Сайфилд» настраивает обмен данными о выполненных работах между «1С» и системами заказчиков — от сопоставления справочников до контроля доставки и сверок. Опишите свой сценарий, и мы оценим объём работ.