В прошлый раз я писал о том, как 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%».

Частые вопросы