Що саме має пройти перевірку
Розпізнавання накладних у BAS складається з кількох незалежних завдань. Спочатку система отримує файл, потім витягує поля, знаходить контрагента й товари, перевіряє арифметику та передає дані в облікову систему. Гарно прочитаний PDF ще не доводить, що прибуткова накладна створена правильно.
На сторінці розпізнавання документів описано можливі джерела та приймачі даних. Тут розберемо, як приймати таку роботу: власник має отримати відтворюваний тест, а бухгалтер — зрозумілий список того, що перевіряти. Методика підходить і для нового впровадження, і для перевірки вже наявного сценарію.
До початку тесту погодьте конкретну конфігурацію BAS, тип документа, правила округлення, валюту й місце зберігання оригіналів. Окремо запишіть, хто може змінювати довідники. Якщо ці рішення відкладені, помилки інтеграції легко помилково назвати помилками AI.
Як зібрати контрольну вибірку
Візьміть документи за звичайний робочий період, а не лише найчіткіші скани. Пропонований початок — 30–50 файлів від кількох постачальників. Це робочий розмір пілота, а не достатня вибірка для обіцянки певної точності.
Додайте багатосторінкову накладну, фото під кутом, печатку поверх рядка, повернення, знижку та документ із новою позицією. Якщо реально приходять Excel і листи, вони також мають бути в тесті. Збережіть зв’язок між кожним файлом і правильною відповіддю, яку перевірив бухгалтер.
Розділіть матеріали на налаштувальну та контрольну частини. На першій дозволено виправляти правила, другу показують системі лише після цього. Інакше команда демонструватиме запам’ятовані приклади замість роботи на незнайомих документах. Видаляйте зайві персональні дані, які не потрібні для перевірки.
Таблиця приймання
| Що перевіряємо | Контрольний випадок | Очікувана поведінка |
|---|---|---|
| Контрагент | Схожі назви двох компаній | Вибір за погодженими ідентифікаторами |
| Товар | Артикул постачальника відрізняється | Зіставлення через таблицю відповідностей |
| Одиниці | Упаковки та штуки | Перерахунок лише за відомим коефіцієнтом |
| Суми | Знижка й округлення | Збіг рядків і підсумку за правилами обліку |
| Дублі | Той самий файл із новою назвою | Повтор не створює другу накладну |
| Невідоме | Новий товар або нечітке поле | Запит людині, без вигаданого значення |
Не зводьте весь результат до одного відсотка. Помилкова кома в примітці та неправильний контрагент мають різну ціну. Виділіть критичні поля, для яких потрібна перевірка людиною або відмова від автоматичного продовження.
Чому найбільше часу займає номенклатура
Постачальник може називати товар «кава зерно 1кг», а в обліку він має іншу назву, фасування та артикул. Схожість тексту дає кандидата, але не завжди надійну відповідність. Для дорогих або схожих позицій потрібні додаткові ознаки: штрихкод, виробник, об’єм, одиниця.
Почніть із погодженої таблиці «постачальник — його артикул — наш артикул». Нові відповідності підтверджує відповідальна людина. Збережіть автора та дату зміни, щоб можна було пояснити, чому вчора система обрала одну позицію, а сьогодні іншу.
Невідомий товар не має автоматично ставати новою карткою в BAS. Інакше швидкий імпорт створить кілька довідникових записів для одного товару. Правило створення нових карток варто оцінювати окремо від розпізнавання.
Як рахувати час і помилки
Запишіть час ручного введення контрольних документів. Для автоматизованого варіанта рахуйте весь людський час: завантаження, очікування, перевірку, виправлення й повторну спробу. Порівнювати ручне введення з лише часом відповіді моделі некоректно.
У журналі для кожного документа потрібні його умовний номер, формат, кількість рядків, критичні помилки, хвилини перевірки та результат. Окремо позначайте технічні відмови: недоступна база, нестача прав, таймаут. Вони впливають на роботу, навіть якщо текст прочитаний правильно.
Після зміни моделі або правил повторіть контрольну вибірку. Зберігайте попередній результат, а не перезаписуйте його. Так видно, чи виправлення одного постачальника не погіршило обробку іншого. Не публікуйте узагальнений показник без опису складу вибірки.
Пілот, доступи та наступний крок
Перший запуск робіть у тестовій базі або погодженій копії. Інтеграційному користувачу потрібні лише необхідні права. Передавайте ключі окремим захищеним способом, а не в тексті накладної або загальному чаті. Оригінал, розпізнаний результат і створена чернетка повинні мати спільний ідентифікатор.
Умови приймання запишіть до розробки: які поля критичні, хто розбирає винятки, скільки часу дозволено витрачати на перевірку і що відбувається після збою. Після тесту виберіть один стабільний потік, а решту постачальників підключайте поступово.
Для оцінки підготуйте кілька знеособлених файлів, назву конфігурації BAS, місячний обсяг і перелік ручних виправлень. Якщо крім документів потрібні інші обміни, дивіться інтеграцію AI з обліком і CRM. Кошторис має окремо показувати розпізнавання, зіставлення довідників, запис у базу та супровід змін.
Часті запитання
Чи можна відразу проводити розпізнані накладні?
На пілоті створюйте чернетки. Проведення залишайте бухгалтеру, доки контрольна вибірка й обробка винятків не підтвердять прийнятну якість.
Скільки документів потрібно для першого тесту?
Практичний початок — 30–50 різних документів. Це запропонований обсяг пілота, а не статистична гарантія; важливі різні постачальники, формати й складні випадки.
Чим OCR відрізняється від інтеграції з BAS?
OCR читає текст. Інтеграція додатково зіставляє контрагентів і товари, перевіряє значення, знаходить дублі й створює документ потрібного типу.
