Інтеграція AI-воркфорсу із системами керування документами (ЕДО, Diadoc, SBIS)
Системи електронного документообігу накопили терабайти ділових документів, але не вміють їх розуміти—лише зберігати, маршрутизувати та підписувати. AI-воркфорс змінює це: агенти підключаються до ЕДО-систем і працюють з документами так само, як працював би досвідчений працівник—читають, аналізують, заповнюють, приймають рішення.
Архітектура інтеграції
Інтеграція AI-воркфорсу з ЕДО будується на моделі агентного шару над існуючою інфраструктурою. Жодної заміни Diadoc чи SBIS—AI-агенти підключаються як ще один учасник документообігу, але з автоматичною обробкою.
[ЕДО-система (Diadoc / SBIS / 1C EDI)]
↕ REST API / SOAP / Webhook
[AI Integration Layer]
├── Document Receiver Agent
├── Classification Agent
├── Extraction Agent
├── Validation Agent
└── Action Agent (підпис, відхилення, маршрутизація)
↕
[Внутрішні системи: 1C, ERP, CRM, База даних]
Diadoc: REST API інтеграція
Diadoc надає REST API з OAuth 2.0 аутентифікацією. Ключові эндпоінти для AI-воркфорсу:
-
GET /v1/GetNewEvents— отримання нових документів (polling або webhook) -
GET /v1/GetDocument— завантаження тіла документа (XML для формалізованих, PDF/DOCX для неформалізованих) -
POST /v1/PostMessage— відправка підписаного документа -
POST /v1/Delete— відхилення з коментарем
Для підпису документів AI-агент використовує CryptoPro DSP API або локальний крипто-провайдер. Агент не зберігає ключі—викликає підпис через окремий захищений сервіс.
SBIS: інтеграція через WebAPI
SBIS надає JSONRPC-based API (SBIS WebAPI). Аутентифікація через SID-сесію. Основні методи:
-
SBIS.WriteDocument— створення та відправка -
SBIS.DocumentList— отримання списку з фільтруванням -
SBIS.ReadDocument— отримання контенту
Специфіка SBIS: документи часто приходять у форматі SBIS-XML, що потребує власного парсера. Для AI-обробки потрібен проміжний конвертер у уніфікований JSON.
Класифікація та маршрутизація вхідних документів
Перший агент у ланцюгу—classifier. Його завдання: визначити тип документа та маршрут обробки.
| Тип документа | Дія агента |
|---|---|
| Рахунок-фактура (SF) | Вилучити реквізити → звірити з замовленням → направити на акцепт |
| UPD (рахунок-фактура + накладна) | Повний цикл: вилучення + звірення + бухучет |
| Акт виконаних робіт | Звірення з контрактом → перевірка форм → підпис або зауваження |
| Контракт | Направити до юридичного модуля для аналізу |
| Рекламація | Пріоритетна маршрутизація до відділу якості |
Класифікатор навчений на корпусі документів компанії (fine-tuned BERT або prompt-based з GPT-4o). Точність на типовому корпусі: 97–99% для формалізованих форматів, 90–95% для неформалізованих.
Вилучення структурованих даних
Формалізовані документи (SF, UPD) у форматі ФНС XML парсяться детермінчено—XPath/lxml без LLM. LLM підключається лише для:
- Неформалізованих документів (вільний PDF, Word)
- Документів з нестандартною структурою
- Верифікації та нормалізації даних
Для неформалізованих рахунків архітектура вилучення:
# unstructured.io для розбивки на елементи
from unstructured.partition.pdf import partition_pdf
elements = partition_pdf(filename="invoice.pdf")
# Промпт з extracted elements → LLM → Pydantic модель
class InvoiceFields(BaseModel):
seller_inn: str
buyer_inn: str
invoice_date: date
total_vat: Decimal
total_amount: Decimal
line_items: list[LineItem]
Триступеневе узгодження (3-way matching)
Ключове завдання AI-воркфорсу у фінансовому документообігу—автоматичне узгодження:
- Замовлення на закупку (Purchase Order з ERP)
- Товарна накладна / UPD з ЕДО
- Рахунок-фактура з ЕДО
Агент звіряє: номенклатуру, кількість, ціну, підсумкові суми. При розбіжності > допустимого порога—прапор для ручної перевірки, при узгодженні—автоматичний підпис та запуск оплати.
Типові пороги розбіжності:
- Сума: ±0.5% (похибка округлення)
- Кількість: 0% (точне збігання)
- Номенклатура: fuzzy matching з порогом 85% (назва може відрізнятися написанням)
Інтеграція з 1C
Двостороння синхронізація через 1C REST API (oData) або COM-об'єкти:
- 1C до ЕДО: автоматичне формування та відправка вихідних документів
- ЕДО до 1C: створення документів у 1C за прийнятими з ЕДО (UPD → Поступлення товарів, Акт → Поступлення послуг)
Для 1C:ERP використовується підсистема "Обмін електронними документами" з розширенням для AI-валідації перед проведенням.
Обробка винятків та людський контроль
Не всі документи проходять автоматично. Система маршрутизує винятки:
- Новий контрагент (немає у базі) → перевірка у ФНС/ЕГРЮЛ → ручне затвердження
- Сума вище порога (налаштовується) → обов'язкова ручна авторизація
- Розбіжність даних → сповіщення відповідальному + блокування до дозволу
- Закінчення строку відповіді → автоматичне продовження запиту або ескалація
Моніторинг та SLA
Ключові метрики для production:
- Straight-through processing rate — доля документів без ручного втручання: ціль 70–85%
- Processing latency — від отримання до рішення: ціль < 5 хвилин для типових документів
- Extraction accuracy — точність за ключовими полями: ціль > 98% для формалізованих
- False positive rate — доля коректних документів, помилково направлених на ручну перевірку: ціль < 5%
Безпека та відповідність вимогам
- Кваліфікований електронний підпис (КЕП) зберігається в HSM або захищеному крипто-сервісі
- AI-агент не має прямого доступу до ключів—лише викликає API підпису
- Повний audit trail для податкових органів: хто прийняв рішення (людина або AI), на якій основі
- Відповідність вимогам Федерального закону 63-ФЗ "Про електронний підпис"
Часова шкала впровадження
Тижні 1–3: Підключення до API Diadoc/SBIS, базовий receiver і classifier
Тижні 4–6: Extraction pipeline для пріоритетних типів документів (SF, UPD)
Тижні 7–9: 3-way matching, інтеграція з 1C, UI для винятків
Тижні 10–12: Пілот на реальних потоках, настройка порогів, промисловий запуск