Рубрика: Кейсы

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

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

Две недели назад я сделал одному клиенту AI-агента в Telegram с набором предопределённых операций. Работало хорошо. В прошлую пятницу я переписал его на обычного кнопочного бота — оптимизация бюджета. В воскресенье я понял, что это была ошибка. В понедельник я подключил агента к MCP-серверу ERPJS — и получил то, чего не ожидал увидеть.

Этот пост — о конкретном диалоге, который произошёл после этого подключения. Реальный клиент, реальные данные, реальные вопросы. И неожиданный поворот, который я не программировал.

Контекст: малый бизнес с 1000+ счетами

Клиент — малый B2B-дистрибьютор. На ERPJS уже давно. Все продажи — в системе: 1000+ счетов-фактур за 2025 год, несколько валют, FIFO-себестоимость по каждой позиции.

Раньше у владельца был типичный выбор: или часами кликать в интерфейсе ERP, или просить меня сделать кастомный отчёт. Теперь он просто пишет в Telegram, как написал бы коллеге.

Раунд 1: запрос владельца

Владелец: Какой день недели самый прибыльный?

Агент: Достаточно данных — 1000 счетов с 2025 года. Суммирую выручку (fBaseSum4 в EUR) по дням недели…

🏆 Самый прибыльный день — Понедельник (~13 413 EUR за 2025 год)

Четверг и Вторник — близко (~12 156 и ~11 847 EUR соответственно).

⚠️ Суббота почти не работает (~1 067 EUR), Воскресенье — единичные счета.

💡 Данные за 2025 год, 1000 подтверждённых счетов.

Обратите внимание на формат ответа. Агент сам:

• Понял, что «самый прибыльный» нужно мерить в одной валюте — и выбрал EUR как базовую
• Сгруппировал по дням недели (подсказка: dayofweek — это не поле в системе, агент рассчитал)
• Выявил аномалию (Суббота почти не работает) и прокомментировал
• Честно указал ограничения (только 2025 год, только подтверждённые счета)

Никакого программирования этого запроса не было. В системе нет отчёта «прибыль по дням недели» — и не будет. Агент разобрался сам.

Раунд 2: уточнение

Владелец: Это выручка или прибыль?

Агент: Это выручка (сумма счетов-фактур, fSum4 = Total по счёту).

Прибыль (валовая) — это выручка минус себестоимость. Для этого нужен отчёт по GP (Gross Profit). Посмотреть?

Это самый важный момент диалога. Агент признал ограничения своего предыдущего вывода, не делая вид, что ответил на полный вопрос. Это разница между AI-помощником и AI-аналитиком: помощник даёт ответ, аналитик различает когда ответ не полный.

Раунд 3: пользователь обучает агента

Владелец: У тебя сч/ф обновляют склад? Если так, то там (в сч/ф) есть себестоимость по FIFO.

Агент: Есть что нужно! В матрице есть:

• fFIFO — себестоимость FIFO на единицу
• fFIFORowVal — себестоимость FIFO по строке
• fRowGP — валовая прибыль по строке

То есть данные для расчёта прибыли есть. Хочешь, чтобы я посчитал GP по дням недели?

Владелец объяснил архитектуру системы в одном предложении. Агент за секунду нашёл соответствующие поля в схеме и предложил следующий шаг. Это совместная работа, а не «я задаю вопрос — ты даёшь ответ». Агент усвоил новое знание и сразу его применил.

Детали про FIFO и финансовый учёт — в нашем посте про финансовый учёт.

Раунд 4: финальный ответ с аномалией

Владелец: Да, у тебя и GP есть по каждой позиции и по сч/ф в целом. За апрель 2026 посчитай.

Агент: Отлично — отчёт вернул детальные данные. Суммирую выручку (fBaseSum4) и GP (debet) по дням недели…

День	Выручка EUR	GP EUR	Маржа %
Понедельник	~2 200	~510	~23%
Вторник	~1 100	~240	~22%
Среда	~1 900	~490	~26%
Четверг	~1 700	~390	~23%
Пятница	~1 500	~360	~24%
Воскресенье	~8 900	~1 650	~19%

🏆 Самый прибыльный день апреля 2026 — Воскресенье (~1 650 EUR GP)

⚠️ Но это почти полностью один счёт от 06/04 — плоттер на 6 678 EUR (маржа всего 17%). Без него лидирует Понедельник (~510 EUR GP, маржа ~23%).

💡 Среда имеет лучшую маржинальность (~26%) — мелкие розничные продажи без больших скидок.

Это тот момент, когда я понял, что произошло. Агент:

1. Нашёл аномалию в данных — один счёт исказил всю статистику
2. Пересчитал без аномалии — и дал второй, более честный вывод
3. Вытащил дополнительный инсайт — про маржинальность по дням, которого владелец не спрашивал
4. Без путаницы сменил таймфрейм — раунд 1 был за весь 2025 год (~13 К EUR/Понедельник), а тут апрель 2026 (~2 К EUR/Понедельник). Агент понимает «за апрель 2026» как новый контекст, а не «продолжай с теми же данными».

Владелец спросил «самый прибыльный день», а получил аналитическую разведку: вот номинальный ответ, вот откуда он, вот почему он не совсем правда, и вот что ещё интересного мы увидели.

Почему это не «ChatGPT с API»

Многие слышали про «AI-помощников», которые подключают GPT через API и дают ответы на вопросы. Это не то. Разница в трёх вещах:

1. Агент признаёт ограничения. Классический «GPT с API» выдаёт первый возможный ответ. Наш агент сам сказал: «это выручка, не прибыль. Хочешь посчитать прибыль?». Это не натренированное поведение — это следствие того, что у него есть доступ к структуре системы, а не к текстовому описанию.

2. Агент принимает новые знания. Владелец объяснил про FIFO в матрице. Агент не «забыл» это через 2 минуты — он нашёл соответствующие поля в схеме и использовал. Это не магия, а архитектура: MCP даёт агенту доступ к схемам регистров, поэтому объяснение на естественном языке мгновенно становится исполняемым планом.

3. Агент находит то, что вы не спрашивали. Аномалия, маржинальность, тренды — ничего из этого не было в вопросе. Агент сам понял, что «Воскресенье 8900 EUR» выглядит подозрительно, проверил, нашёл один большой счёт, и дал вторую версию ответа. Это поведение аналитика, который отчитывается не «что вы хотели услышать», а «что на самом деле в данных».

Как это работает: MCP в одном параграфе

MCP (Model Context Protocol) — стандарт, через который AI-агенты получают доступ к внешним системам. Вместо того, чтобы мы заранее программировали набор «tools» типа «проверить остаток» или «посчитать продажи» — мы выставляем агенту прямой доступ к системе через MCP-сервер. Агент сам выбирает, что нужно для ответа на запрос. Без дополнительного программирования под каждый новый вопрос.

Честная часть: это прототип

Я сделал этот MCP-сервер за один weekend. Он field-tested на одном клиенте. Это не reference architecture, это манифест намерений.

Что ещё нужно:

• Расширение write-операций — базовые уже работают: агент создаёт документы как черновики. На очереди — более сложные workflow (цепочки документов) и автоматические проводки.
• Multi-tenant изоляция — сейчас работает, но требует тестирования на большем количестве клиентов.
• Audit trail — все MCP-вызовы логируются, но формат требует консолидации.

Я выношу этот кейс публично, чтобы не ждать «идеального продукта». Если у вас есть ERPJS и хотите попробовать своего агента — пишите.

Что это означает для клиентов ERPJS

ERPJS и так — система с открытым кодом бизнес-логики для малого бизнеса. Теперь к ней добавляется открытый MCP-сервер. Это означает:

• Ваш агент — на ваш выбор. Claude, GPT, Gemini, кастомный — любой, что поддерживает MCP.
• Ваш канал общения — на ваш выбор. Telegram, WhatsApp, Slack, веб-чат, голосовой бот.
• Ваш сценарий — на ваш выбор. Аналитика, операционная работа, мониторинг, отчёты — всё через тот же MCP-доступ.

Вы не lock-in ни в одного вендора AI-моделей, ни в одну форму интерфейса. ERPJS поставляет данные и операции, вы поставляете язык.

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