Разбор счетов и УПД поставщиков: поля заполняются сами, бухгалтер проверяет

Типовой запрос из тендеров: первичка от поставщиков приходит на почту и фотографиями из ресторанов, бухгалтер перебивает её в 1С руками и пропускает ошибки. Нужно, чтобы поля заполнялись сами, ошибки поставщика (НДС, суммы, ИНН, дубли) ловились до оплаты, документ сверялся с заказом и уходил в 1С, а в журнале было видно, кто что исправил.

• Ящик входящих: почта, Telegram от шефов, ручная загрузка; вкладки по статусам и «С ошибками», поиск, фильтры, массовые действия.
• Разбор: текстовый PDF — правилами по текстовому слою за 0,04–0,11 с, без модели. Скан или фото сначала выравнивается, потом его читает модель. Повторный файл берётся из кэша по хэшу.
• Документ рядом с полями: у каждого поля уверенность и подсветка на документе, откуда оно взято; правка на месте, Enter сохраняет, Esc отменяет.
• Проверки — код, а не модель, у каждой формула: контрольная цифра ИНН, справочник, количество × цена, «Итого», НДС, ставка 2026 года, дубль, новый контрагент.
• Сверка с заказом поставщику по номеру из «Основания»: недопоставка, переплата в рублях, позиции не из заказа.
• Маршрут «оператор → главный бухгалтер» с журналом «было → стало»; пакет XML для 1С по структуре EnterpriseData и реестр в Excel.

• Оператор — ящик, загрузка, разбор, правка, отправка на проверку, отклонение
• Главный бухгалтер — плюс утверждение, возврат, выгрузка в 1С и Excel, новый контрагент в справочник
• Администратор — пользователи и права, лимиты, ошибки разбора, сброс демо

Скан УПД пришёл в Telegram, лист повёрнут на 3,5°. Оператор нажимает «Разобрать»: скан выравнивается, модель читает реквизиты и строки — около 18 секунд в проверке 06.11.2026. Поле «Сумма НДС» сразу красное, а в проверках формула: «10 547,00 ₽ × 10 / 100 = 1 054,70 ₽ ≠ 1 160,17 ₽ — переплата 105,47 ₽, похоже, налог взят от суммы уже с НДС». Модель только переписывает напечатанное, ошибку находит код, поэтому документ поставщика молча не «исправляется».

На демо-данных, методика указана в каждой строке. Реального клиента у демо нет, поэтому цифр «выручка выросла» здесь нет.

• Python 3.10
• FastAPI
• Jinja2
• pdfplumber, pypdfium2
• Pillow + numpy
• openpyxl
• SQLite (в проде PostgreSQL)
• gunicorn, Caddy

1. Файл → хэш → кэш. Есть текстовый слой — правила по подписям полей с координатами слов; нет — выравнивание, ужатие и модель.
2. Модель возвращает значения как напечатаны, уверенность и номер строки для каждого поля; рамка строится по реальной строке скана.
3. Проверки — чистый код, пересчитываются после каждой правки.
4. Статусы и журнал в базе, выгрузка — XML для 1С и XLSX.

В демо документы загружаются вручную, почта и Telegram показаны источником у исходного набора. В проде: почтовый ящик бухгалтерии по IMAP, бот в Telegram или MAX для шефов, справочник и заказы из 1С, загрузка в 1С:Бухгалтерию обменом или HTTP-сервисом. С ЭДО (Диадок, СБИС) УПД приходят уже в XML — им нужны только проверки и сверка.

• В демо изображения обрабатывает OpenAI. Для заказчика отдельно выбираем модель со зрением и согласуем размещение и правила обработки документов.
• Свой контрольный набор из 50–100 реальных сканов заказчика и такой же замер доли верных полей.
• Нагрузку и стоимость обработки оцениваем на контрольном наборе форм заказчика.
• Срок называю после разбора форм документов и интеграций.

Честно: XML для 1С повторяет структуру EnterpriseData, но на реальной базе 1С не загружался. Подсветка на скане — по строке, не по слову: примерно 4 рамки из 5 стоят на нужной строке.

Сборка демо: 1 день, 24.10.2026. Код пишу вместе с ИИ-агентами, проверка — автоматическая, в браузере на сервере. Сроки проекта у заказчика — в последнем пункте «Как было бы в проде» и в разделе «Процесс и сроки».