3-way matching — сверка заказа (PO), приёмки (GRN) и счёта — вручную занимает 8–15 дней и стоит до 2500 руб. за документ. IDP сокращает цикл до 2–4 часов для автоакцептов и снижает cost per invoice на 60–80%. Этот playbook — операционная инструкция: модель данных, чеклист готовности, tolerance-правила, очередь исключений и пилот за 6 недель. Почему производство — особый случай В типовом AP-процессе три документа сравниваются по нескольким полям. На производстве всё сложнее: • Частичные поставки. Один PO закрывается несколькими GRN — счёт может прийти после первой партии, а не после финальной. • Двойная номенклатура. Артикул поставщика и внутренний код в 1С — разные строки; без таблицы маппинга IDP не может сопоставить позиции. • Единицы измерения. Поставщик выставляет счёт в тоннах, склад принимает в килограммах. Округление создаёт технические расхождения. • Транспортные расходы. Часто включены в счёт отдельной строкой, которой нет в PO. • ОТК и серийный учёт. Часть позиций может быть возвращена после приёмки — GRN корректируется постфактум. Именно поэтому западные playbook-и (NetSuite, QuickBooks) не переносятся напрямую: они не знают УПД, Диадок и специфику производственного учёта в 1С. Модель данных: что извлекает IDP и куда это идёт Ключевой вопрос перед внедрением — не «какую платформу выбрать», а «какие поля нужны и откуда они берутся». Ниже — минимальная модель для 3-way matching на производстве. Поле | Источник в документе | Объект в 1С:ERP Номер PO | УПД / счёт-фактура / ТОРГ-12 (реквизит «Основание») | Заказ поставщику ИНН поставщика | УПД (продавец) | Контрагент (мастер) Дата документа | УПД / счёт-фактура | Дата счёта Артикул поставщика | Табличная часть УПД / ТОРГ-12 | Таблица маппинга → Номенклатура Внутренний код | Таблица маппинга (IDP-обогащение) | Номенклатура 1С Количество | Табличная часть | Количество в PO / GRN Единица измерения | Табличная часть | Единица в PO / GRN Цена за единицу | Табличная часть | Цена в PO Сумма строки | Табличная часть | Расчётная сумма PO × GRN НДС | УПД / счёт-фактура | Ставка НДС в PO Итоговая сумма | УПД / счёт-фактура | Сумма к оплате Номер GRN | Реквизит «Основание» или внешний ID | Поступление товаров и услуг Важно: поле «Артикул поставщика → Внутренний код» — самое проблемное. Без актуальной таблицы маппинга в 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%, и команда закупок разочаровывается в системе. Тип расхождения | Порог автоакцепта | Маршрут эскалации | Ответственный | SLA Цена за единицу | ±2% от PO | Менеджер закупок | Закупки | 4 часа Количество | ±0,5% от GRN | Кладовщик / ОТК | Склад | 4 часа Единица измерения (пересчёт) | Автоматически при наличии коэффициента | — | — | — Транспортные расходы | До 1,5% от суммы PO | Менеджер закупок | Закупки | 8 часов Частичная поставка | GRN < PO, счёт = GRN | Автоакцепт частичного | — | — Отсутствие GRN | Любое | Блокировка счёта | Склад + закупки | 1 рабочий день Расхождение артикула | Нет маппинга | Обогащение вручную | Закупки / НСИ | 1 рабочий день Дублирующийся счёт | Совпадение номера + ИНН + суммы | Автоотклонение | — | — 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%. Метрики: до и после Метрика | Ручной процесс | Цель (IDP) | Best-in-class Invoice cycle time | 8–15 дней | 2–4 часа (автоакцепт) | < 2 часов Touchless processing rate | 0% | >60% | >80% First-pass match rate | н/д | >85% | >90% Exception rate | ~22% | <9% | <5% IDP field accuracy (УПД XML) | — | >97% | >99% IDP field accuracy (OCR/PDF) | — | 75–85% | >90% Exception resolution time | 3–5 дней | <1 рабочего дня | <4 часов Duplicate payment rate | 1–3% | 0% | 0% Cost per invoice | 800–2500 руб. | −60–80% | −80% Vendor dispute rate | высокий | снижение на 40–60% | — 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: когда данных достаточно». Ключевые факты • Средний цикл обработки счёта вручную — 8–15 дней; при автоматической сверке автоакцепты закрываются за 2–4 часа. • Industry average exception rate — 22%; цель после внедрения IDP — ниже 9%. • Cost per invoice при ручной обработке — 800–2500 руб.; автоматизация снижает показатель на 60–80%. • First-pass match rate ниже 70% — сигнал проблем с мастер-данными, а не с IDP-моделью. • Поставщики без ЭДО не должны выпадать из контура: OCR-канал IDP обрабатывает PDF и сканы с точностью 75–85% и требует отдельного tolerance-режима.