IDP на производстве: автоматическая сверка закупок без ручного ввода

Почему производство — особый случай

В типовом AP-процессе три документа сравниваются по нескольким полям. На производстве всё сложнее:

• Частичные поставки. Один PO закрывается несколькими GRN — счёт может прийти после первой партии, а не после финальной.
• Двойная номенклатура. Артикул поставщика и внутренний код в 1С — разные строки; без таблицы маппинга IDP не может сопоставить позиции.
• Единицы измерения. Поставщик выставляет счёт в тоннах, склад принимает в килограммах. Округление создаёт технические расхождения.
• Транспортные расходы. Часто включены в счёт отдельной строкой, которой нет в PO.
• ОТК и серийный учёт. Часть позиций может быть возвращена после приёмки — GRN корректируется постфактум.

Именно поэтому западные playbook-и (NetSuite, QuickBooks) не переносятся напрямую: они не знают УПД, Диадок и специфику производственного учёта в 1С.

Модель данных: что извлекает IDP и куда это идёт

Ключевой вопрос перед внедрением — не «какую платформу выбрать», а «какие поля нужны и откуда они берутся». Ниже — минимальная модель для 3-way matching на производстве.

Важно: поле «Артикул поставщика → Внутренний код» — самое проблемное. Без актуальной таблицы маппинга в 1С IDP будет генерировать исключения на каждой строке с нестандартным артикулом. Это не проблема модели — это проблема мастер-данных.

Схема процесса

Входящий документ
  ├── ЭДО (Диадок / СБИС) → XML УПД 5.01/5.02
  └── Бумага / PDF → OCR-канал IDP
          │
          ▼
    IDP-экстракция полей
    (field-level accuracy: >97% XML, 75–85% OCR)
          │
          ▼
    Обогащение: артикул поставщика → внутренний код
          │
          ▼
    Сопоставление PO + GRN + Счёт
          │
    ┌─────┴─────┐
    │           │
  Match      Mismatch
    │           │
    ▼           ▼
Tolerance-   Классификация
проверка     исключения
    │           │
  Pass       Очередь HITL
    │           │
    ▼           ▼
Автоакцепт   Ревью + решение
    │           │
    └─────┬─────┘
          │
          ▼
    1С:ERP: счёт к оплате
          │
          ▼
    Платёжное поручение

Роуминг между Диадок и СБИС прозрачен для IDP: документ поступает в едином XML-формате вне зависимости от оператора отправителя.

Чеклист data readiness

Запускать IDP на «грязных» данных — главный anti-pattern. Система будет генерировать ложные исключения и дискредитирует автоматизацию задолго до того, как покажет результат.

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

1. Мастер поставщиков очищен — нет дублей по ИНН, у каждого контрагента один актуальный ИНН и КПП в 1С.
2. Таблица маппинга артикулов заполнена — артикул поставщика ↔ внутренний код номенклатуры для всех позиций пилотного потока.
3. Стандарт PO-номеров соблюдается — номер заказа поставщику фиксируется в реквизите «Основание» исходящего документа и воспроизводится поставщиком в счёте.
4. GRN обязателен — в 1С настроено требование: счёт не может быть акцептован без связанного документа «Поступление товаров и услуг».
5. Единицы измерения стандартизированы — в справочнике номенклатуры указана единица, в которой ведётся учёт; для пересчёта (кг/т) настроены коэффициенты.
6. Форматы ЭДО согласованы с поставщиками — пилотный поставщик подключён к Диадок или СБИС и выставляет УПД, а не счёт-фактуру + ТОРГ-12 раздельно.
7. Исторические данные PO загружены — открытые заказы поставщикам за последние 90 дней доступны через API или выгрузку для сопоставления.
8. Права доступа настроены — IDP-сервис имеет read-доступ к PO и GRN в 1С и write-доступ для простановки статуса счёта.
9. Ответственные за исключения назначены — для каждого типа расхождения определён владелец и SLA (см. следующий раздел).
10. Хранение данных соответствует 152-ФЗ — персональные данные контрагентов (ФИО подписантов в УПД) обрабатываются и хранятся на серверах в РФ.

Tolerance-правила: что акцептовать автоматически

Нулевой tolerance — второй по частоте anti-pattern. Каждое округление уходит на ручную проверку, touchless rate остаётся на уровне 10–15%, и команда закупок разочаровывается в системе.

Tolerance-правила — живой документ: первые 4 недели пилота они корректируются по фактическому распределению исключений.

Типичные исключения на производстве

Частичная поставка. Поставщик привёз 80% от PO, выставил счёт на фактически поставленное. GRN закрыт на 80%. Система должна сопоставить счёт с частичным GRN, а не с полным PO — иначе каждая частичная поставка уходит в исключения.

Расхождение артикулов. Поставщик пишет свой код, в 1С — внутренний. Без таблицы маппинга IDP не может сопоставить строки. Решение: обогащение на этапе экстракции, до сопоставления.

Транспортные расходы в счёте. Отдельная строка, которой нет в PO. Tolerance-правило: автоакцепт до 1,5% от суммы PO; выше — эскалация на менеджера закупок.

Отсутствие GRN на момент прихода счёта. Счёт пришёл через ЭДО, а товар ещё в пути или на входном контроле. Счёт паркуется в статусе «ожидание GRN» с таймером: если GRN не появляется за 3 рабочих дня — эскалация на склад.

Округление единиц измерения. Поставщик выставляет в тоннах с двумя знаками, склад принимает в килограммах. Пересчёт даёт погрешность ±0,1–0,3%. Решение: коэффициент пересчёта в справочнике + tolerance на количество ±0,5%.

Метрики: до и после

First-pass match rate ниже 70% — не повод докручивать IDP-модель. Это сигнал: мастер-данные не готовы. Проверьте таблицу маппинга артикулов и стандарт PO-номеров.

Audit trail: прослеживаемость для ФНС и внутреннего контроля

Автоматическая сверка создаёт более полный след, чем ручной процесс, — при условии, что логирование настроено правильно.

Каждое событие фиксируется с таймстампом и идентификатором пользователя или сервиса:

• получение документа из ЭДО / OCR-канала;
• результат IDP-экстракции по каждому полю (значение + confidence score);
• результат сопоставления по каждому полю (match / mismatch / tolerance);
• решение системы (автоакцепт / эскалация / автоотклонение);
• действие пользователя в очереди исключений (одобрение / отклонение / запрос уточнения);
• финальный статус в 1С и дата передачи на оплату.

Лог хранится не менее 5 лет (требование НК РФ для первичных документов). При налоговой проверке ФНС инспектор получает не только сам УПД, но и полную цепочку: кто, когда и на каком основании акцептовал счёт. Это сильнее, чем подпись в журнале входящих счетов.

Пилот за 6 недель

Недели 1–2: подготовка данных и среды. Выберите одного поставщика: регулярные поставки (20–30 счетов в месяц), подключён к ЭДО, однородная номенклатура. Проведите data readiness по чеклисту выше. Настройте интеграцию IDP ↔ 1С:ERP (API или шина). Зафиксируйте baseline-метрики вручную: cycle time, exception rate, cost per invoice.

Недели 3–4: запуск в режиме shadow. IDP работает параллельно с ручным процессом. Каждое решение системы сравнивается с решением сотрудника. Цель — выявить расхождения и откалибровать tolerance-правила. Не переключайте оплату на автоакцепт до завершения shadow-режима.

Недели 5–6: боевой режим на пилотном потоке. Автоакцепты проходят без ручного вмешательства. Исключения уходят в очередь HITL. Измеряйте метрики еженедельно. Фиксируйте типы исключений — это материал для расширения таблицы маппинга и корректировки tolerance.

Критерии успеха пилота:

• Touchless rate >50% на 6-й неделе.
• First-pass match rate >80%.
• Ни одного задвоенного платежа.
• Exception resolution time <1 рабочего дня.
• Команда закупок подтверждает: ручных ошибок стало меньше, а не больше.

Если touchless rate <40% — не масштабируйте. Вернитесь к чеклисту data readiness: скорее всего, проблема в маппинге артикулов или нестандартных PO-номерах.

Интеграционная архитектура для РФ

Типовая схема для производственного предприятия:

• Входной канал ЭДО: Диадок или СБИС → webhook или polling → IDP-сервис. Роуминг между операторами прозрачен.
• OCR-канал: email / shared folder → IDP-сервис (для поставщиков без ЭДО).
• IDP → 1С:ERP: REST API или интеграционная шина (например, через 1С:Шину или самописный адаптер). IDP читает PO и GRN, записывает статус счёта.
• Очередь исключений: веб-интерфейс или интеграция с корпоративным мессенджером; ревьюер видит PO + GRN + счёт в одном экране.
• Хранение: документы и логи — на серверах в РФ (требование 152-ФЗ для персональных данных подписантов).

Если на предприятии уже есть SAP или самописная WMS — архитектура та же, меняется только адаптер. Принцип единый: IDP не заменяет ERP, а обогащает её данными из документов.

Вопрос выбора IDP-платформы и критерии её оценки — отдельная тема; если вы ещё на этапе «готовы ли мои данные для ИИ вообще», начните со статьи «BI: когда данных достаточно».