Использование ИИ в 1С: закупки, номенклатура и заказы в УТ, КА и ERP

Использование ИИ в 1С для торговли и производства — это подключение модели к данным «1С:Управление торговлей», «1С:Комплексной автоматизации» или «1С:ERP». Модель читает справочники, документы и историю движений и готовит черновики для закупщика, менеджера и владельца справочника. В операционном контуре ей можно поручить четыре процесса: прогноз спроса и заказ поставщику, чистку дублей в номенклатуре, сопоставление позиций поставщика со своими при приёмке и разбор входящих заказов клиентов в документ «Заказ клиента». Проводить заказы, объединять карточки и подтверждать сопоставления модель сама не должна. Она надёжно делает повторяющуюся работу и уверенно ошибается там, где у компании свои справочники, правила закупки и исключения.

Ниже по каждому из четырёх процессов разобрано, что модель делает надёжно, где ошибается и почему без доступа к вашим справочникам и регламентам результат не совпадает с практикой. Отдельно показано, что из этого уже закрывают сервисы 1С и где они упираются в типовую конфигурацию. Бухгалтерский контур, вопрос о том, куда уходят данные, и ответственность за ошибку здесь даны коротко, со ссылками на отдельные статьи. В конце — что подготовить до старта и почему коробочный помощник закрывает только часть задачи. Генерацию кода для программистов 1С статья не разбирает.

Какие операционные задачи ИИ берёт в УТ, КА и 1С:ERP?

ИИ берёт задачи, где много однотипных решений, есть история правильных ответов и ошибку можно поймать до проведения документа. В операционном контуре таких процессов четыре, и в каждом модель готовит черновик: прогноз и заказ поставщику, список вероятных дублей, предложенное сопоставление, заполненный заказ клиента. Решение остаётся за сотрудником, который отвечает за этот участок.

Обработка заявок — самый частый объект автоматизации в российских компаниях. По исследованию «СберАналитики» и «Сбер Бизнес Софт» (ноябрь 2025 года, 559 респондентов) документооборот и обработку заявок автоматизируют 70% компаний, продажи — 25%. Среди инструментов автоматизации ИИ-агентов и ассистентов используют 39% компаний, ERP — 24%.

Как ИИ прогнозирует спрос и готовит заказ поставщику?

Модель считает прогноз продаж по истории и предлагает количество к закупке, а закупщик проверяет и проводит заказ. Для прогноза у 1С есть официальный облачный сервис, и в УТ, КА и ERP он подключается штатно. Заказ поставщику из прогноза получается только через правила закупки, которые у каждой компании свои.

По описанию сервиса 1С:Прогнозирование продаж на портале 1С:ИТС он доступен в «1С:Управление торговлей» с версии 11.5.19, в «1С:Комплексной автоматизации» и «1С:ERP» с версии 2.5.19. Сервис получает данные о продажах из базы, подбирает модель автоматически и даёт прогноз на срок от одного до тридцати периодов вперёд: по дням, неделям или месяцам. Среди моделей названы скользящее среднее, сезонная модель, экспоненциальное сглаживание, градиентный бустинг и рекуррентные нейросети. Прогноз строится в разрезе номенклатуры, характеристик, складов или магазинов и клиентов. Как дополнительные данные сервис может учитывать производственный календарь и скидки, а готовый прогноз можно поправить вручную, например под планируемую рекламную кампанию.

Расчёты идут в облаке 1С, и по заявлению компании в процессе прогнозирования она не передаёт данные третьим лицам. Сервис платный. На странице сервиса на сайте 1С:УТ указаны бесплатный тестовый тариф на тридцать дней и платные тарифы по квоте, а программа должна быть на официальной поддержке.

Где модель ошибается, видно по истории продаж:

• Дефицит в истории. Товара не было на складе три недели, продажи в эти недели нулевые. Модель видит падение спроса, хотя спрос был, и занижает прогноз.
• Новые позиции. Истории нет или она короче сезона. Прогноз строится по аналогам, а какая позиция считается аналогом, знает закупщик.
• Акции и разовые сделки. Один крупный тендер или распродажа поднимают ряд. Если их не отметить, модель ждёт повторения.
• Дубли номенклатуры. Продажи одного товара разбросаны по трём карточкам, и по каждой прогноз получается втрое ниже реального.

Прогноз отвечает на вопрос, сколько продадим. Заказ поставщику отвечает на другой: сколько и когда купить с учётом остатка, резервов, товара в пути, срока поставки, минимальной партии, кратности упаковки и денег на закупку. Эти правила живут в головах закупщиков и в настройках обеспечения потребностей в 1С. Если их не записать, модель предложит заказ, который сходится по математике и не проходит по условиям поставщика. Почему остатки в базе расходятся с полкой и как это ломает любой расчёт закупки, разобрано в статье про учёт остатков на складе.

Может ли ИИ почистить дубли в справочнике номенклатуры?

Может найти вероятные дубли и объяснить, почему считает карточки одинаковыми. Объединять их должен владелец справочника. Типовой поиск дублей в 1С работает по правилам сравнения полей, а модель сравнивает карточки по смыслу и находит пары, которые правила пропускают.

В УТ, КА и ERP есть типовая обработка «Поиск и удаление дублей». Она сравнивает выбранные поля на точное совпадение или по похожим словам и хорошо ловит карточки, заведённые дважды под одним названием. Карточки с разным написанием она часто не видит: «Уголок 50х50х5 ст3», «Уголок стальной 50505» и «Уголок равнополочный 50 мм» для неё три разных товара. Языковая модель читает такие названия как человек и собирает их в группу вероятных дублей.

Типичные находки такого поиска:

• Разное написание размеров. «50х50», «50*50», «50 x 50», с пробелами и без.
• Наименование поставщика вместо своего. Карточку завели при приёмке из чужого документа, и рядом лежит своя карточка на тот же товар.
• Артикул в названии и без него. Одна карточка с артикулом производителя в начале наименования, другая без.
• Характеристика как отдельная карточка. Цвет или размер заведены отдельными позициями, хотя в справочнике для этого есть характеристики.

Ошибается модель на позициях, которые отличаются одним параметром, сокращённым в названии или вынесенным в реквизит. Марка стали, ГОСТ против ТУ, длина хлыста, класс прочности болта: для склада это разные товары с разной ценой, а для модели почти одинаковые строки. Поэтому каждая предложенная пара идёт с объяснением и с реквизитами обеих карточек, и решение принимает человек.

Объединение дублей стоит считать необратимой операцией. Ссылки из документов, остатки, цены и соответствия с номенклатурой поставщиков переходят на главную карточку, и разобрать их обратно через полгода почти невозможно. До запуска модели компания записывает правила наименования и решает, что заводится характеристикой, а что отдельной карточкой. Без этих правил модель будет предлагать объединения по своей логике, каждый раз немного по-разному.

Как ИИ сопоставляет номенклатуру поставщика со своей при приёмке?

Модель предлагает для каждой строки документа поставщика позицию из вашего справочника и пересчитывает упаковки в ваши единицы. Кладовщик или оператор подтверждает, и подтверждённое соответствие запоминается. Самая трудная часть — первое сопоставление: новый поставщик, новые позиции, чужие названия.

Запоминание соответствий в 1С есть давно. При загрузке документов по ЭДО программа хранит, какой позиции поставщика соответствует ваша, и при следующей поставке подставляет её сама. Сервис 1С:Распознавание первичных документов делает то же для сканов и файлов. По материалу экспертов 1С на buh.ru (30 октября 2025 года) он сопоставляет поставщиков и номенклатуру с объектами базы, а если название в документе отличается от справочника, предлагает вариант. После одного-двух подтверждений выбор запоминается. Сервис работает в УТ, КА, 1С:ERP и других решениях 1С.

Модель полезна там, где запомненного соответствия ещё нет. Она читает название, артикул производителя, единицу и цену строки и ищет свою позицию по смыслу, а не по совпадению символов. Новый поставщик присылает первую накладную на двести строк, и сейчас каждую из них подбирают вручную. Модель предлагает вариант для каждой строки, а человеку остаётся проверить.

Где модель ошибается при приёмке:

• Аналоги. Поставщик заменил товар аналогом другого производителя. Модель находит похожую позицию и не знает, что по договору замена не согласована.
• Похожие артикулы. У разных производителей одинаковые или почти одинаковые артикулы на разные товары.
• Единицы измерения. В документе «коробка», у вас «штука», а в карточке не указано, сколько штук в коробке. Пересчёт получится неверным, и остаток разойдётся на кратность.
• Ошибка в документе поставщика. Пересорт у поставщика модель перенесёт в вашу базу, если сопоставит по названию, а не по факту на полке.

Отсюда правило: предложение модели с низкой уверенностью уходит человеку, а подтверждённое соответствие записывается в справочник и дальше работает без модели. Потолок точности распознавания и порог окупаемости по потоку документов разобраны в статье про распознавание первички в 1С.

Как ИИ превращает письмо клиента в «Заказ клиента»?

Модель читает письмо, вложение или сообщение в мессенджере, находит клиента, позиции, количества и сроки и создаёт в 1С черновик документа «Заказ клиента». Менеджер проверяет его до резерва и отгрузки. Сложнее всего здесь сопоставить названия клиента с вашей номенклатурой и не дать модели подставить цену.

Заказы приходят в любом виде. Текст в теле письма, таблица Excel в своей форме клиента, PDF из его учётной системы, фото рукописной заявки, сообщение в Telegram. Модель вытаскивает из них одно и то же: клиента и контактное лицо, позиции, количества, единицы, желаемую дату и адрес доставки. Позиции она сопоставляет с вашей номенклатурой по истории заказов этого клиента. Если он годами пишет «саморез кровельный 4,8х35», модель уже знает, какая карточка за этим стоит.

Цены, скидки и условия оплаты модель не придумывает. В УТ, КА и ERP они берутся из соглашений с клиентами и договоров по правилам учёта, и черновик заказа заполняется так же, как если бы менеджер создал его руками. Модель, которая пишет цену из письма или из памяти, рано или поздно отгрузит товар по чужому прайсу.

Где модель ошибается на заказах:

• Расплывчатые заявки. «Как в прошлый раз, только гвоздей больше» требует знать прошлый заказ и решить, сколько это «больше».
• Упаковки вместо штук. Клиент пишет «10 уп.», а в базе цена за штуку.
• Правки к старому заказу. Ответ в цепочке писем меняет уже принятый заказ, а модель создаёт новый.
• Нет такой позиции. Клиент просит товар, которого нет в ассортименте, и модель подбирает ближайший похожий вместо того, чтобы спросить менеджера.

Любая готовая обработка для этой задачи знает типовой документ «Заказ клиента». Ваши доработки заказа, порядок согласования, правила резерва и то, через какие каналы приходят заявки, она не знает, и всё это приходится настраивать под базу. Как устроен весь путь от заявки до оплаты и где на нём теряются деньги, разобрано в статье «Автоматизация продаж».

Что умеют готовые сервисы 1С и где они упираются?

Готовые сервисы 1С закрывают прогноз продаж и запоминание соответствий в типовой конфигурации. Поиск смысловых дублей и разбор заказов из писем среди официальных сервисов для УТ, КА и ERP в этой статье не нашлись, их собирают под базу. Часть того, что пишут про «ИИ в 1С», к операционному контуру вообще не относится.

1С:Напарник на собственной странице описан как помощник для разработки, который входит в состав 1С:EDT 2025 и новее. Именно его чаще всего имеют в виду статьи, которые стоят в выдаче по запросу «ИИ в 1С», но закупщику и менеджеру он ничего не даёт.

Где готовые решения перестают работать:

• Доработанная конфигурация. Свои реквизиты заказа, свои статусы, свой порядок резерва. Типовое решение заполнит стандартные поля, а ваши оставит пустыми.
• Свои правила закупки. Прогноз сервис посчитает, а графики поставок, минимальные партии и лимиты денег на закупку по поставщикам знает только ваш закупщик.
• Несколько систем. Заказы приходят из CRM или личного кабинета, склад ведётся в WMS, а 1С получает данные обменом. Ответ на вопрос «почему заказ не встал в резерв» лежит на стыке систем. Как устроены такие связки, разобрано в материале про интеграцию систем.
• Обновления. Доработку под одну версию конфигурации при обновлении нужно проверять заново, и чем больше в базе своих изменений, тем чаще что-то ломается.

Куда уходят данные и кто отвечает за ошибку модели?

Данные уходят туда, где работает модель, а отвечают за результат люди, которые и раньше отвечали за закупку, справочник и заказ. Для операционного контура это решается так же, как для бухгалтерии: модель предлагает, человек проводит, и это разделение закреплено в правах её учётной записи.

В операционной базе лежат закупочные цены, условия поставщиков, маржа и контакты клиентов. Это коммерческая тайна и персональные данные, и отправлять их в публичный зарубежный чат нельзя. Варианты размещения модели, от облака российского вендора до контура компании, разобраны в статье «Нейросети без утечки данных». Кто отвечает за ошибку, которую ИИ внёс в учёт, и как устроить права помощника, подробно показано в статье про ИИ в 1С:Бухгалтерии.

Закупщики сами проводят эту границу. По опросу пользователей ЭТП «ТендерПро» (CNews, 20 июля 2026 года) больше 75% компаний не рассматривают передачу ИИ полного цикла закупки, от анализа предложений до выбора поставщика и договора. Главные барьеры — риск потери контроля (73%), юридические риски (62%) и опасения утечки данных (56%). Вспомогательным задачам, обработке данных и подготовке документов компании доверяют.

В операционном контуре это переводится в четыре запрета для учётной записи модели:

1. Не проводить заказы поставщикам и клиентам. Модель создаёт черновик, проводит человек.
2. Не объединять карточки номенклатуры. Модель предлагает пары, объединяет владелец справочника.
3. Не менять цены, соглашения и условия поставщиков. Эти данные модель только читает.
4. Не работать без журнала. Что модель прочитала, что предложила и кто подтвердил, пишется в журнал, иначе через квартал не восстановить, откуда в базе взялась ошибка.

С чего начать?

С одного процесса из четырёх и с описания того, как выглядит правильный результат. Удобнее начинать с процесса, где поток большой, а эталон уже лежит в базе: подтверждённые заказы клиентов, сопоставления по крупным поставщикам, закупки по ходовым позициям. По этому описанию сразу видно, что закроет сервис 1С, а что придётся собирать под вашу базу.

1. Процесс с эталоном. Какой результат считается правильным: заказ поставщику, который закупщик провёл бы сам, заказ клиента в нужном статусе, решение по паре дублей. Несколько десятков таких примеров из вашей базы.
2. Порядок в справочниках. Номенклатура без задвоений, упаковки и единицы в карточках, клиенты и поставщики без дублей. Модель работает с тем, что есть в базе, и на грязном справочнике будет уверенно ошибаться.
3. Записанные правила. Сроки поставки и минимальные партии по поставщикам, правила наименования номенклатуры, порядок согласования заказа и резерва. То, что сейчас живёт в головах сотрудников.
4. Решение о данных. Какие разделы базы видит модель, какие не видит никогда (закупочные цены, маржа), где она работает: облако российского вендора или контур компании. Решение принимает бизнес, исполнитель переносит его в права.
5. Права и журнал. Отдельная учётная запись без права проведения, объединения карточек и изменения цен, журнал действий. Для официальных сервисов 1С программа должна быть на официальной поддержке.
6. Тестовая копия и интеграции. Копия базы, на которой модель проверяют до запуска, и перечень систем, с которыми 1С обменивается: почта, мессенджеры, ЭДО, CRM, склад.
7. Владелец после запуска и сопровождение. Сотрудник, который следит за справочниками, правилами и качеством предложений, и договор на поддержку. Ассортимент, поставщики и конфигурация меняются, и без хозяина помощник через квартал работает по старым правилам.

Первые три пункта компания закрывает своими силами, и уже они сильно влияют на качество ответов. Остальные четыре показывают, из чего складывается цена проекта: сколько в базе доработок, какие данные закрыты, с какими системами нужна связка. Общую рамку этапов и сметы даёт статья про этапы и стоимость внедрения ИИ.

Коробка или система под свой процесс?

Готовое решение закрывает типовую часть: посчитать прогноз продаж, запомнить сопоставление позиции поставщика, заполнить заказ в типовой форме. Расходятся компании ниже этого уровня, потому что регламенты, справочники, права доступа и исключения у каждой свои.

На старте операционный контур у всех похож: закупить, принять, продать, отгрузить. Небольшой торговой компании с типовой УТ и аккуратным справочником сервиса прогнозирования и штатного запоминания соответствий часто хватает надолго.

Расхождения начинаются с правил. Одна компания закупает раз в неделю по графику поставщика, другая под заказы клиентов, третья держит страховой запас по ходовым позициям и закупает остальное под проект. У одной цвет заведён характеристикой, у другой отдельной карточкой. Одни клиенты присылают заявки в Excel своей формы, другие пишут в мессенджер, а заказ после этого согласует коммерческий директор. Коробочный помощник знает типовую модель данных, а ваши правила закупки, ваш справочник и ваш порядок согласования не знает. Развилку между готовым решением и системой под свой процесс мы разбирали отдельно — своя система или коробка.

INCUBE AI работает по договору, оставляет данные в России и собирает помощника под ваш контур в УТ, КА или ERP. Он работает с вашими справочниками и доработками, получает права по вашей матрице ролей, ведёт журнал действий и связан с почтой, мессенджерами, CRM и складом. После запуска система остаётся на сопровождении. Как такой контур выглядит на живом проекте, видно в проекте для оптово-производственной компании. Там заказы из почты и мессенджеров сводятся в одну очередь, заказ сразу видит остатки и ставит резерв, дефицит по заказам превращается в заявки на закупку и производство, а номенклатура, остатки, отгрузки и оплаты синхронизируются с 1С. Если закупщики и менеджеры у вас тонут в перепечатке и сверке, расскажите о задаче: возьмём один процесс, пройдём его на копии вашей базы и скажем прямо, где хватит сервиса 1С, а где помощника придётся собирать под себя.

Источники и ссылки

• 1С:Прогнозирование продаж, портал 1С:ИТС — доступен в УТ с версии 11.5.19, в КА и ERP с версии 2.5.19, в ERP. Управление холдингом с версии 3.2.3. Модели: скользящее среднее, сезонная модель, экспоненциальное сглаживание, градиентный бустинг, рекуррентные нейросети. Горизонт от одного до тридцати периодов, интервал день, неделя или месяц. Разрезы: номенклатура, характеристики, склады или магазины, клиенты. Дополнительные данные: производственный календарь и скидки; прогноз можно корректировать вручную. По заявлению 1С, в процессе прогнозирования данные третьим лицам не передаются.
• 1С:Прогнозирование продаж, сайт 1С:Управление торговлей — бесплатный тестовый тариф на тридцать дней, платные тарифы по квоте, расчёты в облаке; программа должна быть на официальной поддержке.
• buh.ru, 30 октября 2025 года: как автоматизировать ввод первичных документов с помощью 1С:Распознавания первичных документов — автоматическое сопоставление поставщиков и номенклатуры с объектами базы, запоминание выбора после одного-двух подтверждений, работа в УТ, КА, ERP и других решениях 1С.
• 1С:Напарник — помощник для разработки на 1С, входит в состав 1С:EDT 2025 и новее.
• CNews, 22 января 2026 года: исследование «СберАналитики» и «Сбер Бизнес Софт» — ноябрь 2025 года, 559 респондентов. Автоматизируют документооборот и обработку заявок 70% компаний, продажи 25%. Среди инструментов автоматизации ИИ-агентов и ассистентов используют 39%, ERP 24%.
• CNews, 20 июля 2026 года: опрос пользователей ЭТП «ТендерПро» об ИИ в закупках — больше 75% компаний не рассматривают передачу ИИ полного цикла закупки; барьеры: риск потери контроля 73%, юридические риски 62%, опасения утечки данных 56%.