← усі кейси
Бухгалтерія / опт і виробництво Бухгалтерія / 1С ·

AI-розпізнавання первинки: від фото документа до прибуткової накладної в 1С

Бухгалтер фотографує або скидає документ - система розпізнає рахунок, накладну чи акт, формує строгий JSON і створює прибутковий документ прямо в 1С. Усе на локальному сервері, дані не виходять за периметр.

  • Вхід будь-якого формату: фото, PDF, Word, Excel - бот або інтерфейс у 1С
  • Розпізнавання у строгий JSON → готовий прибутковий документ в 1С
  • Документи створюються непроведеними - людина звіряє очима перед проведенням
  • 100% on-premise: дані не залишають сервер, робота за NDA, архів на вимогу
Python 3.12FastAPIAPSchedulerhttpxSQLiteTelegramQwen Vision (Ollama)GotenbergStirling-PDFDocker Compose

Постачальник привіз товар і лишив накладну. Поки хтось не перебʼє її в облік руками, для компанії цього товару фактично не існує.

На великій закупівельній накладній позицій - десятки. Кожну треба набрати: найменування, кількість, ціну. Це години уваги дорогої людини, витрачені на роботу, яку вона робить тим гірше, чим ближче кінець дня.

І документи не приходять рівним потоком. Щось на папері з водієм, щось файлом від постачальника, щось фото з телефону в месенджері - а зводити це все одно в одну облікову програму.

3
типи: рахунок, накладна, акт
4
формати входу: фото, PDF, Word, Excel
100%
on-premise, дані не виходять із сервера

Проблема: документ приходить будь-яким, а облік чекає одного

Документи в бухгалтерію потрапляють хаотично - паперова накладна із закупівлі, надісланий PDF, Excel від постачальника, фото з телефону. Усе це хтось мусить вручну перенести в 1С: реквізити, контрагента, кожну позицію, кількість, ціну.

Здається, що це питання дисципліни: попроси всіх присилати однаково - і проблеми немає. На практиці формат документа визначає не бухгалтерія, а постачальник.

Три причини, чому первинка не заводиться сама

📥 Вхід некерований

  • Папір, PDF, Excel, фото з телефону - усе одночасно
  • Постачальників багато, і кожен присилає по-своєму

⌛ Робота монотонна

  • Десятки позицій набиваються по одній
  • Це не думання, а введення - але робить його кваліфікована людина

⚠️ Помилка дорога

  • Помилка в кількості чи ціні йде далі в облік і в залишки
  • Втому ніхто не скасовував, а монотонність її множить

Як автоматизація це вирішує

Бухгалтер віддає документ у тому вигляді, у якому той прийшов: фотографує з телефону або кидає файлом. Далі система сама приводить його до єдиного вигляду, читає вміст і збирає з нього готовий документ в обліку.

На виході бухгалтер отримує не картинку й не текст, а заповнений прибутковий документ у 1С з усіма позиціями. Лишається пробігти його очима.

Конвеєр обробки документа
Фото або файл єдиний формат модель читає документ структуровані дані
перевірка даних непроведений документ в 1С бухгалтер звіряє

Два способи подати документ

Вхідні канали

📲 Telegram-бот

  • Сфотографувати документ прямо з телефону
  • Або скинути файлом (PDF, Word, Excel) як вкладення

🖥️ Інтерфейс у 1С

  • Окреме вікно прямо в обліковій програмі
  • Перетягнути фото або Office-чи-PDF файл - і він стає вхідним документом

Чому документ лишається непроведеним

Документи в 1С створюються непроведеними. Це свідоме рішення, а не незакінчена автоматизація: бухгалтер швидко проходить готовий документ очима й проводить його сам.

Система знімає виснажливе набивання десятків позицій. Фінальний контроль лишається за людиною - саме там, де ціна помилки висока.

Розподіл роботи

🤖 Робить система

  • Приймає документ у будь-якому форматі
  • Розпізнає реквізити й усі позиції
  • Формує строгий JSON і прибутковий документ

👁️ Лишає людині

  • Швидку звірку готового документа
  • Рішення провести / виправити
  • Контроль у складних випадках

Що це дало бізнесу

Роль бухгалтера в цьому місці змінилась повністю. Замість набивання позицій - перевірка вже заповненого документа, а це різні за вартістю і за втомою види роботи.

Ручне введення проти автоматичного (схематично)
Ручне введення накладної з багатьма позиціямидовгі хвилини
Автоматично: розпізнав → перевірив очимасекунди + контроль

Що змінилось у щоденній роботі:

  • документ можна віддати в облік просто з телефону, не доносячи папір до столу;
  • вхідний формат перестав мати значення: фото, PDF, Word, Excel обробляються однаково;
  • позиції накладної більше не набиває людина;
  • бухгалтер витрачає час на рішення, а не на введення.

Чесно про межі. Система працює з трьома типами документів - рахунком, видатковою накладною й актом виконаних робіт, вона нічого не проводить самостійно і не домальовує дані, яких у документі немає: некоректний результат відсіюється перевіркою ще до створення документа в обліку.

Дані нікуди не їдуть

Уся обробка відбувається на власному сервері з GPU. Документи не йдуть у хмарні OCR-сервіси й не потрапляють у зовнішні LLM - ані оригінали, ані розпізнаний текст.

Робота ведеться за договором про нерозголошення. За потреби всю розпізнану документацію можна віддати клієнту окремим архівом.

Як це влаштовано всередині

Далі - інженерна частина

Наступний розділ пояснює, чому системі можна довіряти. Якщо вас цікавить лише результат, його можна пропустити - нижче є розділ про те, кому це підходить.

Ключова ідея: усі формати зводяться до спільного знаменника - зображення сторінки. Word та Excel конвертуються в PDF через Gotenberg, PDF розкладається на PNG через Stirling-PDF, а фото вже є зображенням.

Далі Qwen Vision на власному GPU читає сторінку й повертає не вільний текст, а строгу структуру. Окремий крок валідації перевіряє коректність цієї структури, перш ніж щось потрапить в облік.

Шари системи
ВхідTelegram-бот (фото/файли) + інтерфейс усередині 1С
ОркестраціяВласний сервіс на FastAPI + APScheduler - роутинг за типом документа, черга в SQLite, статуси, повтори при помилках
КонвертаціяGotenberg (Office → PDF) і Stirling-PDF (PDF → PNG)
РозпізнаванняQwen Vision через Ollama на локальному GPU → строгий JSON
ВалідаціяПеревірка структури JSON до запису: некоректний результат не стає документом
Облік1С - створення прибуткових документів через інтеграційний модуль

Строгий JSON тут не технічна примха, а спосіб зробити результат передбачуваним. Модель не має права відповісти «приблизно так»: або структура правильна, або документ не створюється взагалі.

Кому це підходить

Бухгалтеріям із великим потоком вхідної первинки: опту, виробництву, дистрибуції, будь-якому бізнесу, де закупівельні накладні приходять пачками й від різних постачальників.

Ознака, за якою легко перевірити, чи це про вас: якщо на чиємусь столі лежить стос документів «на внесення» і він ніколи не буває порожнім - так, це про вас.

Бухгалтер не перестає контролювати облік - він перестає бути оператором введення. Машина набиває позиції, людина ухвалює рішення.

Потрібне схоже рішення?

Опишіть задачу - підберу архітектуру під ваш бюджет і дані.