Розпізнавання накладних: ШІ для Syrve, Poster та BAS

Розпізнавання накладних прибирає повторне введення: ви завантажуєте фото, PDF або таблицю постачальника, система виділяє реквізити й товарні рядки, зіставляє їх із вашим довідником і готує дані для обліку. Людина перевіряє спірні місця та підтверджує результат. Для Syrve, Poster і BAS спосіб передачі та можливість зберегти саме чернетку перевіряємо на вашій версії.

Таке рішення можна розробити під ваші документи й правила приймання. Його цінність видно в обліку: правильний товар, кількість і закупівельна ціна потрапили на потрібний склад, а працівник не переписував усю накладну. Самого тексту, витягнутого зі скана, для цього недостатньо.

Де ручне введення затримує облік закупівель

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

Помилка виникає не лише через неуважність. У постачальника ціна вказана за пакування, у вас облік у кілограмах. Скорочена назва схожа на інший інгредієнт. Знижка стоїть унизу документа, а не в рядку. Навіть правильно переписані цифри можуть дати неправильне надходження, якщо працівник обрав не ту одиницю чи номенклатуру.

Коли документи вводять із запізненням, розрахунок собівартості спирається на неповні дані. Власник бачить звіт, але ще не знає, чи враховано останнє подорожчання. Прискорення починається з коротшого шляху між прийманням товару та перевіреним записом про нього.

Що можна отримати з паперу, фото, PDF та Excel

Паперову накладну спочатку фотографують або сканують. OCR, тобто оптичне розпізнавання символів, перетворює зображення на текст. Далі програма визначає, де постачальник, дата, номер, таблиця товарів і підсумки. ШІ може допомогти розібрати різне оформлення та запропонувати значення полів, але його припущення потребують перевірки.

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

Excel із заповненими клітинками краще читати як таблицю. Не потрібно фотографувати екран, щоб потім відновлювати вже наявні дані. Але й тут є нюанси: об'єднані клітинки, кілька аркушів, приховані рядки, окремі колонки з ціною до та після знижки. Для кожного джерела визначаємо, які саме колонки вважаються остаточними.

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

Як накладна проходить від завантаження до підтвердження

Практичний процес складається з послідовних дій, кожна з яких має видимий результат:

1. Отримати документ. Зберегти оригінал, перевірити читабельність і належність сторінок до однієї поставки. Одразу перевірити, чи його вже не обробляли.
2. Виділити поля. Зібрати постачальника, дату, номер, товарні рядки, кількість, одиниці, ціни, знижки, ПДВ і загальну суму, якщо вони є у джерелі.
3. Зіставити з обліком. Знайти ваші картки товарів та постачальника, перевести погоджені фасування в одиниці обліку, вибрати склад.
4. Підготувати перевірку. Показати оригінал поруч із результатом, виділити нові товари, незвичні ціни та розбіжності в підсумках.
5. Передати підтверджені дані. Створити чернетку в обліковій системі, якщо вона це дозволяє. Інакше перевірити дані до запису, а після передачі показати створений документ.

Чернетка тут означає запис, який ще не має остаточно впливати на облік. Режим її збереження залежить від програми. Якщо доступний метод одразу створює поставку, екран погодження потрібно розмістити перед цим кроком. Кнопка «підтвердити» має відповідати реальному моменту запису, а не бути декоративною дією після нього.

Чому зіставлення товарів складніше за читання цифр

Номенклатура означає ваш довідник товарів та інгредієнтів. Постачальник не зобов'язаний використовувати ті самі назви. Умовний приклад: у накладній написано «вершки кулінарні», а в базі є кілька карток із різною жирністю та пакуванням. Схожість слів не доводить, що це один продукт. Неправильний вибір змінить і залишки, і розрахунки страв.

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

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

Окремо погоджуємо, що робити з товаром, якого ще немає в довіднику. Автоматично створювати нову картку за кожною незнайомою назвою означає накопичувати дублікати. Краще запропонувати варіанти та дати відповідальному вибрати наявну позицію або свідомо створити нову. Довідник залишається керованим, а рішення можна пояснити пізніше.

Одиниці, ціни та ПДВ: що перевіряємо окремо

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

Далі перевіряємо, чи ціна вказана з ПДВ або без нього, як розподілена знижка, чи включені додаткові витрати. Не можна переносити загальний підсумок у поле ціни за одиницю. Рядок перевіряється арифметично, а сума рядків звіряється з документом за погодженими правилами округлення. Незбіг не приховується автоматичним виправленням останньої позиції.

Правила ПДВ задає ваш бухгалтер відповідно до обліку, який веде компанія. Програма переносить позначення та перевіряє узгодженість сум; вона не повинна самостійно обирати податковий режим за виглядом скана. Якщо потрібне поле відсутнє або документ містить різні ставки, це окремий випадок для погодження.

Як передавати результат у Syrve, Poster або BAS

API означає програмний спосіб обміну даними між системами. Для цієї задачі потрібен не просто доступ до API, а можливість працювати з потрібними довідниками та документом надходження. Її, права й умови підключення перевіряємо на вашій версії до обіцянки автоматичного запису.

Syrve: перевірити шлях до складського документа

Syrve публікує документацію для інтеграцій, зокрема Syrve Live API та Syrve POS API. Наявність інтерфейсу для роботи каси чи замовлень не підтверджує можливість записати накладну постачальника. Для вашої установки потрібно уточнити доступний інтерфейс складського обліку, права, ліцензійні умови та поведінку створеного документа.

Окремо виробник описує власне розпізнавання PDF із формуванням чернетки накладної. Спочатку варто перевірити його доступність і придатність для ваших документів. Якщо потрібне власне зіставлення чи інший канал отримання, оцінюємо доповнення. Конкретний метод запису та збереження без проведення підтверджуємо на тесті, без універсальної обіцянки для всіх версій Syrve.

Poster: поставка через API після перевірки

Офіційна документація Poster описує метод storage.createSupply, який створює поставку. Він приймає постачальника, склад, дату й позиції з ідентифікатором, кількістю та ціною; також описано необов'язковий параметр фасування. Перед передачею треба вже знати, яким об'єктам Poster відповідають рядки постачальника.

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

BAS/1С: імпорт або обмін під конфігурацію

Для платформи 1С офіційно описані файловий обмін, HTTP-сервіси та плани обміну. HTTP-сервіс дозволяє програмам передавати запити й дані, а план обміну задає учасників та склад даних обміну. Це механізми для розробки, а не готова кнопка імпорту будь-якої накладної в кожній конфігурації BAS.

Перевіряємо назву й версію конфігурації, доопрацювання, режим роботи та дозволені способи підключення. Можливим початком буде файл для наявної обробки завантаження; іншим варіантом є окремий сервіс або налаштований обмін. Чи створиться непроведений документ і які поля обов'язкові, перевіряємо саме у вашій базі на безпечних тестових даних.

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

Як точні накладні пов'язані з технологічною картою

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

Якщо надходження віднесли до іншої картки продукту, у рецептурі може залишитися стара вартість потрібного інгредієнта. Якщо переплутали кілограми з упаковками, помилковими будуть кількість і ціна одиниці. Тому важливий не тільки збіг загальної суми накладної: підсумок може зійтися навіть за неправильного розподілу між товарами.

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

Що залишається людині та як поводитися при збої

Людина підтверджує отриманий товар, вирішує розбіжності з постачальником і погоджує нові відповідності. Скан не доводить, що фактично привезли саме таку кількість або що якість прийнятна. Розпізнавання допомагає оформити результат приймання, а відповідальність за саме приймання залишається у команди.

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

Окрема небезпека: система прийняла документ, але відповідь загубилася. Сліпе повторення може створити другу поставку. У такій ситуації спочатку звіряємо стан в обліку за збереженим зв'язком або реквізитами, а вже потім дозволяємо повтор. Виправлений документ також не повинен непомітно перезаписувати погоджений запис.

Від чого залежить обсяг розробки

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

У пропозиції варто розділити початкову розробку й витрати під час роботи. Це можуть бути послуга розпізнавання, потрібний доступ до облікової системи та підтримка після оновлень. Конкретні умови сторонніх сервісів перевіряємо перед оцінкою. Обіцянка «один раз заплатили й забули» без перевірки цих залежностей не допомагає планувати бюджет.

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

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

Як почати під ваш облік і перевірити користь

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

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

На пілоті, тобто пробному запуску, порівнюємо час повного введення з часом завантаження, перевірки та виправлень. Рахуємо нерозпізнані рядки, помилкові відповідності й повторні документи. Перевіряємо результат у системі призначення: склад, товар, кількість, ціна, ПДВ та стан документа. Красивого розпізнаного тексту для приймання роботи замало.

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

CEO та провідний розробник Artbrain

Anton Kunashenko

Засновник Artbrain з 2018 року. Розробляє цифрові продукти для бізнесу: від лендингів до enterprise-систем.