1С:Управление торговлей: возможности и что автоматизирует ИИ-агент поверх системы

Компания вела опт в «1С:Управление торговлей 11»: заказы клиентов, поставки поставщиков, склад, цены и скидки, деньги — всё это жило в одной системе. Менеджер видел остаток и срок, снабженец — потребность по заказам, коммерческий директор — отчёт по продажам и марже. Не делала система одного — не собирала из этих данных решение. Что заказать у поставщика на следующей неделе и что не заказывать вовсе; какую цену держать по конкретному клиенту, чтобы не потерять маржу и не отдать заказ конкуренту; какие заказы рискуют уйти в просрочку и почему. Это собирал человек — в Excel, в переписке и в собственной голове. Именно этот разрыв — между данными и решением — закрывает ИИ-агент: программа, которая по заданному правилу сама читает данные из учётной системы и выполняет шаги.

«1С:Управление торговлей 8» вендор описывает как инструмент, который позволяет «в комплексе автоматизировать задачи оперативного и управленческого учёта, анализа и планирования торговых операций», а главной его особенностью называет универсальность: поддержаны все основные виды торговли — розничная, оптовая, продажа в кредит, по предварительному заказу и комиссионная (solutions.1c.ru). Это вендорское описание продукта, а не независимая оценка эффективности. Но из него хорошо видно главное для нашего разговора: система рассчитана на то, что торговое предприятие уже принимает решения по закупке, цене и клиентскому запасу, а её задача — эти решения аккуратно провести и посчитать.

Полнота торгового контура подтверждается уже не описанием, а документацией. В официальном описании редакции 11.5 перечислены тринадцать разделов: нормативно-справочная информация, планирование, работа с клиентами и маркетинг, продажи, обеспечение потребностей, склад и доставка, закупки, казначейство, управленческий учёт затрат и финансовый результат, отчёты и мониторинг, регламентированный учёт, ввод начальных остатков и настройки интеграции (its.1c.ru). В программе регистрируются не только уже совершённые, но и планируемые операции — иначе она не смогла бы считать потребность в закупке (solutions.1c.ru). То есть данные для решений в торговле есть по каждому процессу: от заказа клиента до платежа. Не хватает не данных, а регулярной процедуры, которая эти данные превращает в решение.

Коротко

«1С:Управление торговлей 11» — это контур торгового предприятия: заказы клиентов, поставки, цены и условия, склад, закупки, казначейство, отчёты. Решения по закупке, цене и клиентскому запасу система не принимает: их собирает человек вручную. ИИ-агент читает заказы, остатки, поставки и цены, находит дефицит, просрочку и отклонения по марже и возвращает разбор с обоснованием. Решения остаются за человеком.

Содержание

• Что закрывает «1С:Управление торговлей»
• Где границы системы
• Почему решения по закупке и цене видно поздно
• Что съедает время между данными и решением
• Что делает ИИ-агент поверх «1С:Управление торговлей»
• Какие риски это снимает
• Сколько часов это возвращает
• Что остаётся за человеком
• Чеклист: что проверить в своей базе до подключения агента
• Как это выглядит на практике
• Как внедрить поэтапно
• Источники

Что закрывает «1С:Управление торговлей»

Разбираться в возможностях системы лучше по документации, а не по рекламным обещаниям: там перечислены ровно те процессы, данные которых дальше и понадобятся агенту. Пройдёмся по разделам описания редакции 11.5 (its.1c.ru).

Нормативно-справочная информация. Товары, характеристики, цены поставщиков, банки и контрагенты, склады, договоры, скидки. Это фундамент: без единых карточек товара и клиента никакое сравнение не работает.

Планирование. Планы продаж по направлениям и менеджерам, планирование закупок под эти планы, сценарный подход. Здесь система отвечает на вопрос «сколько мы собираемся продать», но сам выбор цифры остаётся за человеком.

Работа с клиентами и маркетинг. Воронка сделок, работа с потенциальными клиентами, сегменты, маркетинговые мероприятия, рассылки. Клиентская база ведётся рядом с заказами, а не в отдельном файле.

Продажи. Заказы клиентов по всем видам торговли — опт, розница, комиссия, продажа в кредит, по предварительному заказу; согласование условий, отгрузка, счета и закрывающие документы, возвраты.

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

Склад и доставка. Остатки по складам и ордерная схема, приёмка и размещение, отбор и отгрузка, инвентаризация, доставка до клиента.

Закупки. Заказы поставщикам, согласование цен и условий, графики поступления, контроль исполнения, претензии по срокам и качеству.

Казначейство. Заявки на расходование денег, платёжный календарь, контроль лимитов, работа с дебиторской и кредиторской задолженностью.

Управленческий учёт затрат и финансовый результат — себестоимость, маржа по сделкам и направлениям, финансовый результат по периодам.

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

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

Где границы системы

Граница видна из той же документации — и её полезно знать до того, как считать эффект.

Система ведёт учёт, а не принимает решение. Отчёты показывают и «продажи за период», и «остатки на дату», и «дебиторскую задолженность». Но они отвечают на вопрос «что произошло», а не на вопрос «что делать с этим заказом к пятнице». Отчёт по закупкам не говорит, у какого поставщика сорвётся срок и чем это закрыть; отчёт по марже не говорит, по какой позиции цену пора поднять, а где скидка уже съела прибыль.

Потребность считается по заказу, а не по клиенту. Система честно сложит потребность по оформленным заказам. Но клиент, который заказывает раз в неделю по телефону и почте, в этот расчёт попадёт только тогда, когда менеджер успел завести заказ, — а решение о закупке надо принимать раньше.

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

Правила ведения учёта не равны правилам решений. В системе заданы скидки, договоры и цены поставщиков. Но пороги, при которых цена уже невыгодна, срок, при котором заказ считается рискованным, и допустимое отклонение поставки от графика в правилах не описаны — это держит в голове коммерческий директор.

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

Почему решения по закупке и цене видно поздно

Торговля — это место, где данных больше, чем времени, а цена ошибки видна через месяц. Разберём механику разрыва.

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

Работа со «статистикой» даёт инерцию. Планы и цены в системе опираются на прошлые периоды. Это правильный механизм, но он смотрит назад: позиция, которая в прошлом сезоне продавалась хорошо, и в этом получит закупку по старой логике. Отклонение видно, только если кто-то регулярно смотрит на динамику — а регулярного просмотра в регламенте отдела обычно нет.

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

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

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

Просрочка клиента видна как долг, а не как риск. Дебиторская задолженность в отчёте — это факт. Что за клиентом стоит, как он платил раньше, растёт ли его просрочка и стоит ли отгружать следующую партию — решение, которое принимается отдельно от отчёта.

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

Практический вывод: проблема не в отсутствии данных — в торговле их много и они подробные. Проблема в том, что между данными и решением нет регулярной процедуры, а ручная процедура не выдерживает масштаба ассортимента и числа клиентов. Смежные процессы устроены так же: как из истории продаж получается прогноз — в разборе прогнозирования спроса в 1С и WMS (WMS, Warehouse Management System — система управления складом), а как из потребности появляется заказ поставщику — в материале про закупки и снабжение.

Что съедает время между данными и решением

Разложим путь от «в системе всё есть» до «решение принято». В торговой компании он повторяется почти дословно:

• Выгрузка и сведение. Заказы клиентов, поставки, остатки по складам, цены — из двух баз и нескольких отчётов. Одна таблица для разбора собирается руками.
• Нормализация справочников. Один товар под двумя названиями, разные единицы измерения в одной карточке, клиенты-дубли, склады без признака зоны. Без этого любое сравнение даст мусор.
• Сверка поставок. Счёт против договора, приёмка против накладной, срок против графика. Самая неприятная работа: она всегда выявляет чужие ошибки.
• Разбор дефицита. Что заказано, но не обеспечено; где срок поставки позже срока клиента; что можно закрыть со склада другого юрлица.
• Разбор просрочки. Какие заказы рискуют уйти в просрочку на этой неделе и почему: нет запаса, сорвался поставщик, склад не успевает отгрузить.
• Разбор цен и маржи. Где скидка вывела позицию в минус, где цена закупки выросла, а цена клиенту осталась прежней, где условия отличаются от договорных.
• Расчёт денег. Сколько стоит просрочка по договору, сколько — замороженный запас, сколько — упущенная выручка от дефицита. Пункт пропускают чаще остальных: результат неприятен, а решение требует согласования.
• Подготовка решения. Что заказать у поставщика, что перекинуть между юрлицами, где пересмотреть цену, какие заказы предупредить.
• Согласование и передача. Решение нужно донести до менеджеров, снабжения и склада, оформить в системе и потом проверить, что получилось. История решений при этом нигде не остаётся.

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

Что делает ИИ-агент поверх «1С:Управление торговлей»

Агент не заменяет систему и не становится ещё одним окном, которое надо открывать. Он читает то, что уже работает, и возвращает результат туда же — в рабочее место менеджера, снабженца и коммерческого директора.

1. Читает заказы клиентов и их сроки. Что заказано, когда должно уйти, чем обеспечено, что ещё висит без решения — по каждому клиенту, складу и юрлицу.
2. Читает поставки и приёмку. Договорные цены и сроки, фактические поставки, расхождения по количеству, цене и дате, открытые претензии.
3. Читает остатки и движение запаса. Что лежит на каждом складе, сколько лежит без движения, где заканчивается срок годности, что можно закрыть с другого склада вместо закупки.
4. Читает цены, скидки и условия. Цены по клиентам и договорам, скидки, условия оплаты, историю изменения цен закупки.
5. Сводит юрлица между собой. Две базы превращает в один разбор: где запас, который нужен другому юрлицу, где закупка идёт дороже, чем у соседнего подразделения.
6. Ищет отклонения. Заказы под угрозой просрочки, дефицит ходовых позиций, излишек и неликвид, сделки с маржой ниже плановой, просроченная дебиторская задолженность, срывы поставщиков.
7. Собирает разбор для руководителя. Не выгрузку на сотню строк, а короткий документ: что происходит, где это стоит денег, какое решение нужно и до какой даты оно актуально.
8. Ведёт журнал. «Отклонение → владелец → действие → результат»: кто получил сигнал, что решил, помогло ли. Журнал закрывает человек, и он же остаётся доказательной базой.

Меняется горизонт: заказ под угрозой просрочки видно за дни до срока, а не когда клиент звонит; дефицит ходовой позиции — пока её ещё можно добрать у поставщика; падение маржи — до того, как скидка разошлась по всему направлению. Важная деталь: система уже описывает и заказы, и потребность, и цены — значит, агенту есть на что опираться, и ни одна система при этом не заменяется. Если торговый контур связан с производством, рядом живёт ещё один слой данных — он разобран в материале про производственный блок 1С:ERP; а как агент подключается к учётной системе в целом — в разборе ИИ-агента для 1С.

Какие риски это снимает

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

Просрочка по заказу клиента и неустойка по договору

Заказ принят, срок назван, а обеспечение не собрано: склад не находит позицию, поставщик сдвинул отгрузку, снабженец ждёт подтверждения цены. Когда выясняется, что в срок не укладываемся, вариантов остаётся два — просить клиента подождать или платить по договору. В договорах с сетями и крупными клиентами просрочка стоит конкретных денег: неустойка, штраф за недопоставку, а при регулярных срывах — снижение объёма заказа на следующий период. В типовом расчёте ниже разбор заказов под угрозой просрочки занимает 12 часов в месяц — это 18 000 рублей при стоимости часа 1 500 рублей, потраченных на то, чтобы обнаружить проблему, когда договорный срок уже наступил.

Закупка по прошлому спросу: деньги, замороженные в запасе

Позиция заказана по прошлогодней логике и легла на склад. Дальше она либо продаётся со скидкой, либо стоит до следующего сезона, либо списывается. Цена вопроса двойная: деньги, замороженные в товаре, и место на складе, которое эта позиция занимает. Тот, кто видит расхождение между закупкой и спросом вовремя, выходит скидкой или перекидывает запас на другое юрлицо; тот, кто узнаёт об этом в конце года, списывает — а списание возвращает ноль. Отраслевой ориентир здесь — принцип X5: основной вклад в дополнительную операционную прибыль дали модели, встроенные в прогнозирование спроса и пополнение, ценообразование и управление ассортиментом, а не разовые акции (x5.ru).

Дефицит ходовой позиции: выручка, которой не будет

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

Расхождение по поставке, которое некому предъявить

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

Скидка, которая съела маржу направления

Менеджер дал скидку, чтобы удержать клиента, — решение выглядит разумным. Но если рядом не видно цены закупки последней партии, выросшей логистики и общей суммы скидок по направлению, решение принимается вслепую. Маржа уходит тихо: каждая отдельная сделка объяснима, а итог по направлению — минус. Именно так выглядит риск, который в отраслевых разборах называют главным: там, где ИИ внедряли отдельной технологией без привязки к операционной метрике, точность модели росла, а бизнес-показатель не менялся (cnews.ru).

Просроченная дебиторская задолженность как сюрприз

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

Зависимость от человека, который «всё помнит»

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

Рынок стал менее предсказуемым

Третий год торговля работает в узком коридоре. По данным Росстата, индекс предпринимательской уверенности в торговле по итогам I квартала 2026 года составил минус 8 пунктов — вдвое ниже, чем годом ранее, и это минимальный уровень с 2006 года; весь 2025 год показатель держался в отрицательной зоне и в конце года опустился до минус 6 (business-gazeta.ru). Во II квартале 2026 года в оптовой торговле появились признаки локальной стабилизации, а индекс рискоустойчивости вырос к I кварталу на 0,3 п. п. до 101,0% (hse.ru). Практический вывод из этих цифр простой: когда план продаж пересобирается чаще, чем раз в квартал, ручной контур решений перестаёт успевать за изменениями — и ошибки копятся ровно там, где запас и цены.

Сколько часов это возвращает

Часы — следствие, но их полезно посчитать, чтобы понимать масштаб. Типовой расчёт для торговой компании с ассортиментом около 18 000 позиций, двумя юрлицами и сводом по филиалам раз в месяц. Вводные берите свои — методика не меняется.

Показатель	Вручную	С агентом
Свод заказов, отгрузок и остатков по клиентам и складам	20 часов в месяц	5 часов (проверка разбора)
Сверка поставок: счёт, приёмка, сроки и расхождения	16 часов в месяц	4 часа
Разбор дефицита и позиций с нулевым запасом при спросе	12 часов в месяц	3 часа
Пересмотр цен, скидок и условий по клиентам	10 часов в месяц	3 часа
Пересбор потребности и заказов поставщикам	14 часов в месяц	4 часа
Отчёт руководителю и разбор отклонений по филиалам	8 часов в месяц	2 часа
Всего в месяц	80 часов	21 час
Возвращённое время	—	59 часов в месяц
В деньгах при стоимости часа 1 500 рублей	—	88 500 рублей в месяц

Арифметика открытая: 20 + 16 + 12 + 10 + 14 + 8 = 80 часов в месяц. С агентом человек не собирает выгрузки и не сверяет таблицы вручную, а проверяет готовый разбор и решает по спорным позициям: 5 + 4 + 3 + 3 + 4 + 2 = 21 час. Разница — 59 часов в месяц, то есть больше семи рабочих дней одного сотрудника; при стоимости часа 1 500 рублей это 88 500 рублей в месяц. Масштаб виден на группе компаний: три юрлица или филиала дают в ручном контуре 240 часов в месяц, с агентом — 63 часа, то есть 177 часов и около 265 000 рублей в месяц, или порядка 3,2 млн рублей за год. Формулировка «типовой расчёт» здесь принципиальна: это математика на заявленных вводных, а не чей-то замер, и реальный эффект зависит от того, сколько позиций и клиентов приходится пересматривать и насколько чистые справочники. Возвращённые часы — не главный результат: главное в том, что решение по закупке и цене появляется в том же цикле, в котором изменился спрос, а не через месяц после него.

Что остаётся за человеком

Границу ответственности нужно задать до пилота, а не после первой просрочки:

• Решение по закупке и цене — только человек. Агент готовит разбор и варианты, снабженец, менеджер и коммерческий директор принимают решение.
• Права менять данные у агента отсутствуют. Только чтение и расчёт: без создания и проведения документов, изменения цен, скидок, договоров и закрытия заказов.
• Правила задаёт человек. Что считаем просрочкой, какое падение маржи считаем отклонением, какой срок без движения означает вывод позиции из закупки.
• Местные договорённости остаются в силе. Позиция, которая не двигается по данным, но нужна конкретному клиенту, остаётся в закупке: агент показывает факт, а не отменяет решение руководителя.
• Переговоры — за человеком. Агент находит расхождение и показывает, где оно возникло, но разговор с поставщиком и клиентом — работа людей.
• Полный журнал решений. Любое предложение объяснимо: на какой истории заказов, каком спросе и каком правиле оно построено. Это же и доказательная база для разговора с поставщиком и с клиентом.

Чеклист: что проверить в своей базе до подключения агента

Это тот же чеклист, с которого мы начинаем каждый проект в торговле. Он бесполезен как список «посмотреть», но работает как список работ: пункты 1–3 закрываются за день-два, пункты 4–6 обычно занимают неделю, и именно они определяют, насколько быстро появится первый разбор.

1. Данные и история — Заказы, отгрузки и поставки выгружаются с детализацией до строки и клиента минимум за 12 месяцев — без года истории сезонность не считается. — Остатки по складам доступны на конец дня и сходятся с фактическими хотя бы по основному складу. — Расхождения поставок доступны с причинами, а не одной строкой «корректировка».

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

3. Правила — Зафиксировано, что считаем просрочкой: день по договору, три дня или неделю. — Зафиксировано, какое падение маржи по сделке считаем отклонением. — Перечислены позиции и клиенты, по которым условия не меняются никогда.

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

5. Метрика — Названы четыре числа до старта: часы на свод и сверки, доля заказов, ушедших в просрочку, доля позиций с дефицитом при спросе, срок от появления отклонения до решения. — Известно, откуда эти числа берутся сейчас, — иначе через месяц не с чем сравнивать.

6. Права и границы — Права агента описаны явно: чтение и расчёт, без записи в систему. — Определён человек, который закрывает журнал и отвечает за решения по закупке и цене.

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

Как это выглядит на практике

В торговле наши проекты начинались одинаково — не с агента, а с инвентаризации данных. Мы сверяли, что действительно живёт в учёте, а что в таблицах сотрудников: где один товар заведён под двумя названиями, где остатки по складам расходятся с фактическими, где скидки живут только в переписке. Дальше фиксировали правила: что считаем просрочкой заказа, какое падение маржи считаем отклонением, по какой паре «клиент — позиция» решение о закупке принимаем автоматически. Запрос со стороны бизнеса звучал так: «мы узнаём, что позиция кончилась, когда клиент уже не пришёл за ней снова».

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

Основную работу в обоих случаях дали подготовка данных и правила, а не модель. Сравнивать филиалы с разной структурой заказов без нормализации бессмысленно, поэтому сначала данные и общие правила, потом сравнения: первый цикл «заказы → разбор → решение → проверка» запускался на одной категории товаров и одном складе. Как только справочники и правила сходятся, регулярный разбор заказов, поставок и цен становится процедурой, а не проектом на квартал. Смежные задачи устроены похожим образом: как управленческий контур строится в розничной сети — в разборе «1С:Розница», а как связываются сделки и учёт — в материале про Битрикс24 и 1С.

Как внедрить поэтапно

1. Выберите одну категорию и одно направление. Позиции с высокой оборачиваемостью или один филиал — там отклонение видно быстрее всего. Так результат проверяется за месяц, а не за квартал.
2. Сверьте данные. Заказы, поставки, остатки, цены минимум за год. Расхождения — не помеха, а первый список задач: именно они съедают время снабжения и коммерческого директора.
3. Зафиксируйте правила. Что считаем просрочкой, какое падение маржи считаем отклонением, какие позиции не трогаем никогда. Правило пишется один раз и переиспользуется.
4. Опишите контур данных. Что агент читает — заказы, поставки, остатки, цены, договоры, задолженность — и куда возвращает разбор: в рабочее место руководителя и снабжения, а не в отдельный чат.
5. Прогоните расчёт на закрытых периодах. Так появляется эталон: известно, какие заказы в тот период действительно ушли в просрочку и где были расхождения, — и видно, что агент пропустил или где ошибся.
6. Ограничьте права явно. Чтение и расчёт. Без права создавать документы, менять цены и скидки, закрывать заказы.
7. Померьте четыре числа. Часы на свод и сверки, доля заказов в просрочке, доля позиций с дефицитом при спросе, срок от отклонения до решения. Именно они, а не презентация, — основание расширять пилот на второе направление.

Что в итоге

«1С:Управление торговлей» — это контур торгового предприятия, и подтверждает это не реклама, а документация редакции 11.5: нормативно-справочная информация, планирование, работа с клиентами и маркетинг, продажи по всем видам торговли, обеспечение потребностей, склад и доставка, закупки, казначейство, управленческий учёт затрат и финансового результата, отчёты и мониторинг, регламентированный учёт. Всё, что нужно для ведения торговых операций, в системе есть. Чего в системе нет: решения по закупке, цене и клиентскому запасу, свода по нескольким юрлицам и регулярной процедуры, которая сама находит отклонения и называет их владельца.

Пока это так, компания платит рисками: просрочкой по заказу и неустойкой по договору; деньгами, замороженными в запасе, закупленном по прошлому спросу; упущенной выручкой от дефицита ходовой позиции; расхождением по поставке, которое некому предъявить; скидкой, съевшей маржу направления; просроченной задолженностью как сюрпризом в казначействе; зависимостью от человека, который всё помнит. На фоне рынка эти риски становятся дороже: индекс предпринимательской уверенности в торговле по итогам I квартала 2026 года составил минус 8 пунктов — минимум с 2006 года, и хотя во II квартале в оптовой торговле появились признаки локальной стабилизации, план продаж пересобирается чаще, чем раз в квартал.

Агент поверх «1С:Управление торговлей» закрывает именно разрыв между данными и решением: часы идут следом (59 часов в месяц, или 88 500 рублей при ставке 1 500 рублей в час, и около 3,2 млн рублей в год на трёх юрлицах, по типовому расчёту), а первым результатом становится управляемость — отклонение видно в момент появления, у каждого пункта есть владелец, решение принимается человеком и остаётся в журнале. Если хотите понять, где ваш торговый контур теряет на заказах, поставках и ценах, начните с одной категории и пройдите чеклист из шести пунктов. Остальные материалы по этому направлению собраны в рубрике Внедрение ИИ.

Источники

• «1С», описание решения «1С:Управление торговлей 8»: решение позволяет в комплексе автоматизировать задачи оперативного и управленческого учёта, анализа и планирования торговых операций; главная особенность — универсальность, поддержаны розничная, оптовая торговля, продажа в кредит, по предварительному заказу и комиссионная; вендорское описание продукта, а не независимая оценка эффекта: solutions.1c.ru
• «1С», страница возможностей того же решения: регистрация как совершённых, так и планируемых хозяйственных операций; автоматизация оформления практически всех первичных документов торгового предприятия; вендорское описание: solutions.1c.ru
• «1С», официальная документация «1С:Предприятие 8. Управление торговлей. Редакция 11.5»: перечень разделов — нормативно-справочная информация, планирование, работа с клиентами и маркетинг, продажи, обеспечение потребностей, склад и доставка, закупки, казначейство, управленческий учёт затрат и финансовый результат, отчёты и мониторинг, регламентированный учёт, ввод начальных остатков, настройки интеграции: its.1c.ru
• «БИЗНЕС Online» (по данным Росстата), «В России индекс предпринимательской уверенности в торговле упал вдвое — до минимума за 20 лет» (10 апреля 2026 года): по итогам I квартала 2026 года индекс составил минус 8 пунктов, снизившись на 4 пункта к предыдущему значению и вдвое год к году; минимальный уровень с 2006 года; в 2025 году показатель держался в отрицательной зоне и в конце года составил минус 6: business-gazeta.ru
• НИУ ВШЭ, Центр конъюнктурных исследований ИСИЭЗ, «Деловой климат в оптовой торговле во II квартале 2026 г.» (28 июля 2026 года) и сводка мониторинговых исследований: во II квартале 2026 года в оптовой торговле появились признаки локальной стабилизации деловой конъюнктуры после ухудшения в предыдущих кварталах; индекс рискоустойчивости вырос к I кварталу на 0,3 п. п. до 101,0%; обследования проводятся на основе ежеквартальных конъюнктурных опросов Росстата, охватывающих около 25 тыс. организаций промышленности, строительства, розничной и оптовой торговли: hse.ru
• CNews, «По итогам I полугодия 2026 года инструменты ИИ занимают 26% цифровых экосистем российских ритейлеров» (11.09.2026), данные аналитического центра проекта STAQ: доля ИИ-инструментов в цифровых экосистемах российских ритейлеров — 26%; около 60% прироста пришлось на операционные сценарии — управление заявками, обслуживание оборудования, поддержку персонала; устойчивый результат там, где ИИ встроен в сквозной процесс с операционной метрикой; заинтересованная вендорская оценка рынка: cnews.ru
• X5 Group, пресс-релиз «ИИ-решения принесли X5 5 млрд рублей дополнительной операционной прибыли»: совокупный экономический эффект от внедрения ИИ-решений — около 5 млрд рублей дополнительной операционной прибыли по итогам 2025 года; основной вклад в EBITDA обеспечили модели в прогнозировании спроса и пополнении, ценообразовании, управлении ассортиментом и рекомендательных механиках; для ключевых инициатив эффект валидируется A/B-тестами: x5.ru