Мы подключили ИИ к 1С:Бухгалтерии 8.3 и проверяли не «отвечает ли API», а реальные бухгалтерские сценарии. Тесты шли в контролируемой базе 1С:Fresh на синтетических хозяйственных данных: расчёты с покупателями и поставщиками, авансы, НДС, банк, БУ/НУ, закрытие месяца, производство, себестоимость, основные средства, зарплата, НДФЛ, взносы, ЕНС и эквайринг.
Для каждого сценария использовали одну и ту же логику: боль → какие данные видит ИИ → как проверили причину → можно ли безопасно выполнить действие → что показал независимый read-back. Это важнее, чем HTTP 200 или флаг Posted=true: сложная бухгалтерская операция может технически «провестись», но не выполнить ту же прикладную логику, что штатная форма 1С.
Итоговый технический статус: STANDARD CONNECTOR TECHNICALLY ACCEPTED / READ_WRITE_PASS / MAIN_ACCOUNTING_PAINS_PASS_WITH_BOUNDARIES.
Боль → как проверяли → результат
| Боль / сценарий | Как проверяли | Результат |
|---|---|---|
| Не сходится дебиторка | Счета 62.01/62.02 → контрагент → договор → реализации → оплаты | PASS. Задолженность раскладывается до документов; долг можно отличить от аванса. |
| Не сходится кредиторка | 60.01/60.02 → поставщик → договор → поступления → платежи | PASS. Аналогичная трассировка до первичного документа. |
| Аванс попал не на тот счёт | Отдельные предоплаты покупателя и поставщику | PASS. Для детерминированной API-записи авансовые счета нужно задавать явно: 62.02 и 60.02. |
| Аванс не зачёлся | Предоплата → реализация/поступление → проверка способа зачёта и табличной части | PASS. Надёжный путь: ПоДокументу + точная ссылка на аванс и сумма зачёта. |
| НДС есть на 19-м счёте, но нет в книге покупок | Поступление → НДС предъявленный → полученный СФ → вычет | PASS. |
| НДС с полученного аванса | Аванс → СФ на аванс → реализация → зачёт → книга покупок | PASS полного цикла. |
| Неверная ставка НДС для даты операции | Проверили, можно ли raw OData провести документ 2026 года со старой ставкой | Риск подтверждён. Posted=true не является налоговой валидацией. |
| Расходятся БУ и НУ | Намеренно задали разные счета БУ и НУ | PASS. Можно пройти от расхождения до регистратора и исходного документа. |
| Дубли банковских операций | Два одинаковых входящих банковских документа по 7 777 ₽ | Боль воспроизведена: оба документа провелись, движение удвоилось до 15 554 ₽. |
| Документ изменили задним числом | Изменили дату и сумму уже проведённого банковского документа | Боль воспроизведена: документ изменился и сохранил Posted=true, старые проводки остались до повторного проведения. |
| Не закрывается месяц | Controlled fixture по счетам 20.01 и 25 + штатное «Закрытие месяца» | NATIVE PASS. Финальный чистый август: 6 стадий / 7 операций, 0 ошибок. |
| Непонятна себестоимость | 10 материалов × 100 ₽ → расход 4 → выпуск 2 → закрытие месяца | NATIVE PASS. Дт 20.01 Кт 10.01 = 400 ₽; Дт 43 Кт 20.01 = 400 ₽. |
| Амортизация не начисляется | ОС 120 000 ₽, СПИ 60 мес. → штатная амортизация и ведомость | NATIVE PASS. За сентябрь подтверждено 2 000 ₽. |
| Зарплата, НДФЛ и взносы | Синтетический сотрудник + начисление зарплаты + независимый read-back | PARTIAL PASS: 10 000 ₽ зарплата, 1 300 ₽ НДФЛ, 3 000 ₽ взносы и связанные движения подтверждены; есть граница кадрового OData surface. |
| Кадровый приём | Создали сотрудника штатным UI, должность, трудовую функцию и ОКЗ | Native HR state PASS. Но ожидаемая кадровая история не экспонируется стандартным OData так, как требовалось коннектору. |
| Не сходится ЕНС | 68.90 + «Корректировка ЕНС» + persisted read-back проводок | PASS с обязательным read-back. Raw payload после проведения может нормализоваться. |
| Эквайринг | Оплата картой 12 000 ₽ → поступление банка 11 760 ₽ → комиссия 240 ₽ | Clearing и net receipt PASS; generic API-запись комиссии не дала ожидаемый 91.02 workflow. |
| Исправленный счёт-фактура | Обычный СФ → direct OData исправленного СФ | Обычный СФ PASS; исправленный direct write стабильно HTTP 500. Нужен штатный/custom workflow. |
| УСН / КУДиР | Пробовали synthetic доход и USN surface | CONFIGURATION_NOT_APPLICABLE: текущая организация не является подходящей полноценно настроенной УСН-базой; налоговый режим ради теста не меняли. |
| Сверка с маркетплейсом | 1С marketplace surface + принятый Ozon read baseline | Оба read-path приняты, но в текущем наборе нет пересекающихся продаж; честный статус — NO OVERLAPPING DATASET. |
| Ошибка закрытия месяца / УдалитьОшибки | Несколько bounded fixtures, включая счёт 25 | NOT REPRODUCED. Штатное закрытие стабильно завершалось без terminal error; искусственно ломать базу не стали. |
Что показали бухгалтерские сценарии
Дебиторка, кредиторка и авансы
Для руководителя недостаточно увидеть итоговое сальдо. В тестах мы проходили цепочку счёт → субконто → контрагент → договор → документ → движение. Поэтому запрос «из чего сложилась дебиторка?» можно довести до конкретных реализаций и оплат.
Отдельно проверили авансы. Здесь проявилась первая важная граница: то, что форма 1С делает «автоматически», raw OData не обязан воспроизводить так же. Для стабильного writer-contract авансовые счета 60.02/62.02 и зачёт по конкретному документу нужно задавать детерминированно.
НДС: от предъявленного налога до книги покупок
Закупочный НДС проверили полным путём: поступление 10 000 ₽ + НДС 2 000 ₽ → НДСПредъявленный → полученный счёт-фактура → вычет → книга покупок. Сценарий прошёл.
НДС с полученного аванса проверили ещё глубже: аванс → 62.02 → СФ на аванс → 76.АВ/68.02 → последующая реализация → зачёт → вычет авансового НДС. Полный цикл подтверждён.
Но тест 2026 года показал опасный нюанс: raw OData технически позволяет провести документ со ставкой, которая не соответствует ожидаемой налоговой семантике периода. Значит, агент должен проверять не только Posted=true, но и дату реализации, режим, ставку строк и переходный сценарий.
БУ/НУ, дубли и задние даты
Мы намеренно создали расхождение бухгалтерского и налогового учёта. ИИ может обнаружить разные строки одного регистратора и дойти до исходного документа, а не ограничиться сообщением «БУ не равно НУ».
Два одинаковых входящих банковских документа по 7 777 ₽ успешно провелись и дали 15 554 ₽ движения. Это означает, что импорт нельзя строить на предположении «1С сама остановит дубль»: нужен собственный fingerprint до проведения.
Ещё показательнее задняя дата. У уже проведённого документа изменили дату и сумму. DataVersion изменился, сам документ остался Posted=true, но бухгалтерские движения сохранили старую сумму до повторного проведения. Следовательно, контроль должен сравнивать текущее содержимое документа и фактические движения, а для истории изменений нужен собственный snapshot.
Закрытие месяца, производство и себестоимость
Generic РегламентнаяОперация.Post() оказался недостаточным доказательством. Поэтому закрытие месяца запускали штатным интерфейсом 1С. Controlled расходы на 20.01 и 25 успешно прошли native close.
Самый показательный production-test: поступили 10 единиц материала по 100 ₽, на выпуск двух единиц продукции израсходовали 4 единицы. Документ выпуска создал правильную количественную топологию, но суммы появились только после штатного расчёта себестоимости при закрытии месяца: Дт 20.01 Кт 10.01 = 400 ₽ и Дт 43 Кт 20.01 = 400 ₽.
Это окончательно подтвердило архитектурное правило: сложную бизнес-семантику 1С нельзя принимать только по ответу REST/OData.
Основные средства и амортизация
Для ОС использовали стоимость 120 000 ₽, срок полезного использования 60 месяцев, счета 01.01/02.01 и расходы на 26-й счёт. Штатная операция «Амортизация и износ основных средств» выполнилась, а «Ведомость амортизации ОС» показала 2 000 ₽ за сентябрь. Generic OData-регоперация в предыдущем тесте такой результат не давала.
Зарплата, НДФЛ, взносы и кадровый контур
В bounded payroll-тесте начислили 10 000 ₽ зарплаты, 1 300 ₽ НДФЛ и 3 000 ₽ страховых взносов. Документ, бухгалтерские движения и связанные payroll/NDFL/contribution/ENS-регистры дали согласованный read-back.
Кадровую часть дополнительно проверили штатным UI: 1С потребовала должность, трудовую функцию, ОКЗ, организацию, подразделение и дату приёма. В штатном списке состояние сформировалось, но ожидаемый для коннектора стандартный OData surface кадровой истории не дал нужного отражения. Поэтому вывод здесь не «кадры не работают», а native HR-state работает, стандартная публикация данных имеет границу. Отправку сведений во внешние системы, включая СФР, мы намеренно не выполняли.
ЕНС, эквайринг, исправительные документы
По ЕНС проверили 68.90 и «Корректировку ЕНС». Проведение сформировало движение, но часть persisted-реквизитов после проведения отличалась от исходного payload. Поэтому для ЕНС правило особенно жёсткое: после записи читать обратно документ и проводки.
Эквайринг дал ожидаемые clearing-движения: Дт 57.03 Кт 62.02 = 12 000 ₽, затем Дт 51 Кт 57.03 = 11 760 ₽. Но комиссия 240 ₽ через generic OData не сформировала ожидаемый расходный workflow через 91.02. Сверять gross → net → комиссия агент уже может; write комиссии требует отдельного штатного/custom сценария.
Обычная реализация и исходный счёт-фактура прошли, а прямое создание исправленного СФ через generic OData стабильно завершалось HTTP 500. Значит, диагностика доступна, а исправление должно идти через прикладной workflow 1С, а не через попытку записать сложный документ «в лоб».
Что ещё проверили кроме отдельных бухгалтерских болей
Сам коннектор прошёл отдельный технический acceptance.
- Метаданные: authenticated
$metadata— HTTP 200; 1 566 EntitySet и 830 FunctionImport. - Финальный бухгалтерский smoke: 26/26 endpoint-ов — HTTP 200.
- Поиск и фильтрация:
$select, строковый фильтр, DateTime-фильтр, сортировка,$skip/$top, pagination — PASS. - Бухгалтерский регистр:
AccountingRegister_Хозрасчетный/BalanceAndTurnovers(...)— HTTP 200. - Права: без авторизации — 401; неизвестная authenticated entity — 404.
- CRUD: CREATE → READ → UPDATE → READ → DELETE → чтение удалённого объекта; коды 201 → 200 → 200 → 200 → 204 → 404.
- Параллельное чтение: 3 × 26 = 78/78 запросов, 0 failures. При этом обнаружен heavy tail до примерно 15,4 секунды, поэтому performance-классификация — LIMITED_PASS, а таймауты должны быть endpoint-specific.
- Пятидневная synthetic-бизнес-симуляция: покупки, продажи, оплаты, возвраты, AR/AP, остатки, отрицательные остатки, НДС и движения; после теста — cleanup.
Официальная документация 1С описывает автоматический REST-интерфейс платформы 1С:Предприятие. Наш тест показывает практическую границу этого транспорта: он отлично подходит для чтения и многих детерминированных операций, но сложные алгоритмы конфигурации нужно принимать по конечным регистрам и, где требуется, выполнять через штатные прикладные команды.
Что можно поручать ИИ — и где он обязан остановиться
После этих тестов ИИ можно использовать как диагностический слой над 1С: разложить дебиторку до документов, найти неправильный аванс, показать разрыв БУ/НУ, обнаружить дубль банковского документа, увидеть заднюю дату, проверить НДС, объяснить себестоимость, подтвердить начисление амортизации или разобрать эквайринговый clearing.
Для руководителя это не ещё один дашборд. Можно спросить: «Из чего сложилась дебиторка?», «Почему не сошёлся НДС?», «Какие документы меняли задним числом?», «Почему себестоимость такая?», «Начислилась ли амортизация?» — и получить трассируемый ответ сумма → счёт → движение → регистратор → документ → причина.
Но финансово значимый write-back должен оставаться управляемым: прочитать → доказать причину → предложить действие → получить подтверждение → выполнить принятый workflow → независимо проверить результат. Произвольные проводки, сторно, перепроведение прошлого периода, исправление НДС/счетов-фактур, изменение ЕНС и закрытие периода нельзя отдавать модели без action-specific contract и подтверждения.
Подробнее о том, как устроен коммерческий контур подключения, — на странице интеграции ИИ-ассистента с 1С. А общая модель работы руководителя с подключёнными системами описана в разделе ИИ-ассистента руководителя по продажам.
Итог: основные бухгалтерские боли в нашей тестовой 1С:Бухгалтерии 8.3 закрыты на уровне PASS_WITH_BOUNDARIES. Самое полезное, что дали тесты, — не список «зелёных API», а точная граница безопасной автоматизации: где ИИ может сам читать и диагностировать, где допустим принятый write-back, а где необходимо вызвать штатную бизнес-логику 1С и проверить её результат.