Минулого разу я писав про те, як AI-агент знайшов аномалію в продажах у нашого клієнта. Тоді агент читав дані з ERPJS — статистику, рахунки, GP. Це read-операції: безпечні, без побічних ефектів.

Цього тижня ми зробили наступний крок — write-операції через MCP. Той самий клієнт, той самий Telegram-бот, але тепер агент створює документи в ERPJS. У моменті, коли я це писав, я не до кінця розумів, що з цього вийде. А вийшло — одне повідомлення → три готові документи в системі за 30 секунд.

Цей пост — про конкретний діалог, який стався 03.05.2026. Реальний клієнт, реальні податкові витрати, реальні документи в ERP. І чому це не “автоматизація рутинних задач” у класичному розумінні.

Контекст: ФОП, який платить три податки щомісяця

Клієнт — той самий малий B2B-дистриб’ютор з попереднього кейсу. У власника окремо від основної компанії є ФОП — як у багатьох українських підприємців. ФОП платить щомісяця три фіксованих податки:

• ВЗ — військовий збір
• ЄП ФОП — єдиний податок ФОП
• ЄСВ ФОП — єдиний соціальний внесок ФОП

У ERPJS це три витратних документи на місяць. Місяць закінчується — треба продублювати документи на наступний місяць, скоригувавши суми (бо ставки податків можуть змінюватися). Раніше це робилося руками: відкрити квітневий документ ВЗ → “Створити копію” → виправити дату на травень → виправити суму. Те саме з ЄП. Те саме з ЄСВ. 5-7 хвилин часу, 90% — рутинне клацання.

Раунд 1: запит власника

Власник, 09:56:
“Знайди 3 витрати: ВЗ, Єдиний податок, ЄСВ. І зроби дублікати на травень — зі зміненими сумами: 900, 1730, 2000”

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

Раунд 2: розвідка — агент знаходить 3 існуючі документи

Агент: Знайшов у квітні 2026:

• 🔍 №1432 — ВЗ ФОП · 750 UAH · квітень 2026
• 🔍 №1438 — Єдиний податок ФОП · 1 580 UAH · квітень 2026
• 🔍 №1444 — ЄСВ ФОП · 1 800 UAH · квітень 2026

Створювати дублікати на травень із сумами 900, 1730, 2000 UAH?

Агент сам розібрав запит: “ВЗ” → знайшов документ з типом “Військовий збір ФОП”, “Єдиний податок” → знайшов “ЄП ФОП”, “ЄСВ” → знайшов “ЄСВ ФОП”. Жодного програмування цього маппінгу не було. Агент знає схему реєстрів ERPJS і вміє шукати по типу документа + опису + контрагенту.

Зверніть увагу: агент не одразу побіг створювати. Він показав, що знайшов, і запитав підтвердження. Це принциповий момент — про нього нижче.

Раунд 3: створення — 3 нові документи як чернетки

Власник: Так

Агент: Готово. Створено 3 документи як чернетки:

• ✅ №1545 — ВЗ ФОП · травень 2026 · 900 UAH · Чернетка
• ✅ №1546 — Єдиний податок ФОП · травень 2026 · 1 730 UAH · Чернетка
• ✅ №1547 — ЄСВ ФОП · травень 2026 · 2 000 UAH · Чернетка

Документи не проводяться автоматично — переглянь і підтверди в системі.

Від моменту “Так” до моменту “Готово” — близько 30 секунд. Три документи в системі, з оновленими сумами, з оновленим місяцем, з правильними посиланнями на контрагентів і статті витрат. Власник відкриває ERPJS, бачить три чернетки, натискає “OK” на кожній — документи проводяться. Або одну з них хоче змінити — клацає “Скасувати”, чернетка видаляється.

Чому ми обрали саме такий UX: чернетки + підтвердження

Це принциповий момент кейсу. І тут важливо розставити акценти правильно.

Технічно MCP жодних обмежень на write-операції не накладає. Агент міг би створювати “проведені” документи напряму, без статусу чернетки і без підтвердження власника. Це питання нашого UX-вибору, а не протоколу.

Ми за замовчуванням робимо так: агент створює документ у статусі “Чернетка”, власник підтверджує одним кліком. Чому саме так?

Бо довіра до AI-агента в реальній ERP будується спостереженням. Власник бачить, що агент створив, як інтерпретував запит, які поля заповнив. Через тиждень-два звикає, переглядає чернетки побіжно. Через місяць може налаштувати автоматичне проведення для рутинних типів документів (наприклад, щомісячні податки ФОП). Це поступовий процес: спочатку “людина в петлі”, з часом — більше автоматизації там, де її довірено.

Чернетка в ERPJS зручна як точка перехоплення помилок: вона існує в системі, але не впливає на залишки, баланси, бухгалтерські проводки:

• Не рахується у P&L
• Не списує гроші з касового балансу
• Не з’являється у звітах для податкової
• Видаляється одним кліком без слідів у бухгалтерії

Якщо агент помилився (сприйняв “200” як “2000”, переплутав ВЗ з ЄП), власник бачить це до того, як ERP щось провела. Але це наслідок нашого workflow-дизайну, а не “технічна безпека MCP”.

Окремий випадок ризику — і як він вирішується

Що якщо агент помилився не у сумі, а в контексті? Наприклад, створив документи на неправильного контрагента.

У логах ERPJS записано:

• Хто створив документ → AI-агент від імені конкретного користувача
• На основі якого вхідного запиту → “Знайди 3 витрати ВЗ, Єдиний податок, ЄСВ…”
• Якими полями → з повним JSON-описом усіх атрибутів

Тобто навіть якщо помилку помітили через місяць — за аудит-логом видно, звідки прийшов документ, від кого, на основі якого запиту. Звичайний інструмент перевірки внутрішнього аудиту, але AI-операції підсвічуються окремо.

Чому це не “RPA” і не “макрос”

Класичний підхід до автоматизації цих задач — RPA (роботизована автоматизація) або макрос. У них є обмеження:

1. RPA закладається наперед. Хтось має заздалегідь налаштувати правило “копіюй три документи з минулого місяця в новий місяць, заміни такі суми”. Якщо власник раптом захоче не дублікати, а одразу 6 документів за два місяці — або іншу логіку — RPA треба переналаштовувати.

2. RPA не розуміє контекст. RPA не розрізнить “ВЗ” і “Військовий збір”. Йому треба точне ім’я. Агент розбирається сам.

3. RPA пропускає чернетки. Більшість RPA-сценаріїв одразу проводять документи (бо так простіше). Помилка → виправляти треба окремою процедурою. Агент із чернетками — кожен документ перевіряється людиною.

Те саме стосується “макросів”: “натисни на кнопку — створиться 3 документи” — це фіксована логіка. AI-агент же приймає довільне формулювання і вибирає, які документи створити, скільки, з якими сумами, для якого місяця.

Чесна частина: де ще треба робити роботу

Цей конкретний випадок працював. Але це не означає, що write-операції через MCP — закінчений продукт. Що ще треба:

• Підтвердження ризикованих операцій. Зараз агент чекає підтвердження тільки якщо вважає за потрібне. Хочемо настроюваний поріг: створення документа на суму > X UAH = автоматичний запит підтвердження від власника, незалежно від того, чи агент впевнений.
• Bulk operations. Якщо власник захоче створити 24 документи (на цілий рік уперед), потрібен підтвердження-всіх-одним-кліком, а не клацати по кожному окремо.

Я виношу цей кейс публічно, щоб не очікувати “ідеальний продукт”. Якщо у вас є ERPJS для малого бізнесу — пишіть, підключимо.

Що каже сам клієнт

“Привіт. Я майже повністю звільнив собі час ввечері на інші задачі. Вся основна моя робота в системі тепер робиться вдень. Дякую!”

— власник, повідомлення в Telegram, 06.05.2026

Контекст: основну роботу в системі — створення документів, перегляд звітів, керування цінами і залишками — клієнт тепер робить через AI-агента з MCP. Раніше це з’їдало вечори (бо вдень — клієнти, телефони, дзвінки). Тепер — паралельно з основною діяльністю, за хвилини. І таких повідомлень-подяк за останній місяць — багато.

Що це означає для клієнтів ERPJS

Раніше сценарій “AI-агент щось робить у моїй ERP” звучав як ризик. Тепер це передбачуваний workflow з очевидною роллю людини:

• Будь-які типи документів. MCP покриває весь спектр ERPJS — витрати, рахунки-фактури, транзакції, накладні. Це не вибірковий перелік “що поки доступно”.
• Агент створює — людина підтверджує. За замовчуванням: чернетки + один клік. UX, налаштований під поступове зростання довіри.
• Кожна операція має автора. Аудит-trail від конкретного користувача, не “робот зробив”.
• Жодних магічних RPA-сценаріїв. Власник пише природною мовою, агент розбирається.

Це не “AI замінив бухгалтера”. Це “AI зробив 90% роботи, людина приймає рішення на 10%”.

Часті запитання