Как ИИ готовит заказ поставщику в 1С

«Пусть ИИ посмотрит продажи за месяц и сам подготовит заказ поставщику». Такой процесс можно спроектировать для магазина, но начинать нужно не с доступа нейросети ко всей базе. Сначала определяют правила закупки: какой запас поддерживать, у кого заказывать, когда ждать поставку и какие решения оставлять человеку.

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

Опубликовано и обновлено: 2 октября 2026 года. Автор: Редакция B2C. Документация и расчётный пример проверены 2 октября 2026 года. Материал описывает методику пилота, не результат внедрения у конкретного клиента.

Что умеет типовая 1С и зачем здесь ИИ

В 1С:Управлении торговлей 11.5 уже предусмотрено рабочее место «Формирование заказов по потребностям». Оно помогает поддерживать запас и обеспечивать заказы на отгрузку. В документации описаны выбор источника обеспечения, дата поставки, ожидаемые поступления, упаковка заказа и минимальная партия. Перед разработкой следует проверить, какая часть задачи уже решается в вашей базе.

Это подтверждает руководство 1С:УТ 11.5 по формированию заказов. Оно не подтверждает наличие встроенного ИИ-закупщика. Объяснения обычным языком, уведомления по исключениям и управляемый сценарий записи в базу в этой статье относятся к предлагаемой интеграции B2C.

Например, закупщик сможет спросить: «Почему рекомендовано 30 единиц, если потребность только 28?» Вместо ответа «так посчитала модель» он должен получить исходные значения, применённый квант и правило округления. Если данных недостаточно, рекомендация не превращается в заказ.

Короткие разборы изменений 1С и рабочих процессов мы публикуем в Telegram-канале B2C: он помогает следить за тем, что стоит перепроверить перед обновлением или запуском интеграции.

Какие данные нужны для пополнения товарного запаса

Заказ начинается с проверяемого среза учёта, а не с текста запроса к ИИ. Для каждого товара нужны источник продаж, доступность, будущие поставки и действующие ограничения. Если документы поступают с задержкой или остатки отрицательные, сначала разбираются с данными.

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

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

Как рассчитать заказ и не превратить четыре дня в универсальное правило

Для простого учебного примера можно взять согласованный среднедневной спрос, умножить его на горизонт покрытия, добавить страховой запас и вычесть свободный остаток с подходящими поступлениями. Это прозрачная модель для обсуждения, а не точное воспроизведение всех алгоритмов 1С.

Учебная формула: потребность = максимум из нуля и значения «средний спрос × горизонт покрытия + страховой запас − свободный остаток − подтверждённые свободные поступления в срок».

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

В документации упрощённого обеспечения УТ 11.5 описан расчёт среднедневного потребления с обработкой дней неполных продаж. Такой показатель не всегда равен простому делению продаж на календарные дни. В пилоте нужно заранее выбрать источник и не смешивать разные способы расчёта.

Проверяемая строка заказа

Все значения ниже вымышлены для обучения и выражены в штуках. Проверена арифметика примера, но не внедрение в клиентской базе.

• Спрос: 300 единиц за 30 выбранных дней без дефицита и аномалий. Среднее для этого примера: 10 единиц в день.
• Цель: покрытие на 4 дня и страховой запас 12 единиц. Целевой запас: 10 × 4 + 12 = 52.
• Доступность: 18 свободных единиц и 6 подтверждённых свободных единиц, которые поступят в нужный срок.
• До округления: 52 − 18 − 6 = 28 единиц.
• Правило поставщика: квант 6 единиц, минимум 12. Тридцать единиц составляют пять полных квантов; это ближайшая допустимая партия не меньше 28.
• Решение: предложить 30 единиц и показать закупщику, что 2 единицы добавились из-за округления. Достаточность срока годности и места проверяется отдельно.

Если поставка 6 единиц ожидается поздно, она исключается из доступного покрытия: потребность становится 34, партия после округления равна 36. Это объяснение закупщик может проверить без доверия к непрозрачному ответу ИИ.

Как учесть квант поставки и календарь поставщика

Квант определяет кратность заказа, минимальная партия задаёт нижнюю границу, а календарь определяет допустимый день решения и получения товара. Это разные ограничения. Минимум 12 единиц не означает, что заказ нужно округлять по 12, если товар поставляется коробками по 6.

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

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

Если до плановой поставки возникнет дефицит, ИИ должен задать вопрос ответственному, а не сам менять график. В УТ есть режимы планового формирования и ожидания дня заказа; календарный сценарий нужно согласовать с ними, а не организовать параллельные дубли закупок.

Как подготовить правила в Excel и загрузить их в 1С

Excel удобен как согласуемая таблица правил поставщика. Но он не гарантирует правильный импорт в любую 1С. Нужно определить структуру файла, проверить строки и выбрать поддерживаемый либо разработанный механизм загрузки для конкретной базы.

Предлагаемая структура одной строки:

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

В Excel можно ограничить ввод допустимыми числами, датами и списками значений; соответствующие средства описывает Microsoft. Такие ограничения помогают подготовить файл, но не заменяют проверку при загрузке.

1. Выгрузить согласованный шаблон и справочники идентификаторов. Не сопоставлять товар только по похожему названию.
2. Проверить положительный квант, допустимую минимальную партию, единицы и коэффициенты; найти повторяющиеся и пересекающиеся правила.
3. Показать предварительный протокол: какие правила добавятся, какие изменятся и какие строки отклонены. Ошибки не исправлять молча.
4. Выполнить пробную загрузку на копии выбранной базы, сравнить результат и сохранить исходную версию правил.
5. После подтверждения перенести правила штатным согласованным механизмом. Источником для регулярного расчёта становится утверждённая версия в учётном контуре, а не случайный файл в переписке.

В этой статье нет обещания универсальной кнопки загрузки квантов для УТ, Розницы, УНФ и ДАЛИОН. Место хранения и загрузчик определяют при обследовании. Если подходит штатный механизм, новый не разрабатывают только ради использования ИИ.

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

Как черновик попадает в 1С и что должен проверить закупщик

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

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

Для каждой строки предлагаем сохранять пять объяснений: спрос, доступный остаток, ожидаемое поступление, правило поставщика и причину ручной проверки. Это методика B2C для проверяемого решения, не заявление о готовом типовом продукте.

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

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

Когда ИИ должен остановиться и спросить человека

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

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

Уведомление может поступать в согласованный Telegram-бот, MAX-бот, на почту или в рабочее место 1С, если соответствующий канал реализован и проверен в проекте. Это не утверждение о встроенных каналах типовой УТ. Безопасное сообщение содержит ссылку на предложение и понятный вопрос, а не выгрузку всей базы или секреты подключения. Отсутствие ответа не считается согласием.

Как B2C предлагает внедрять такой процесс

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

1. Обследовать учёт. Проверить версию 1С или ДАЛИОН, движение продаж и остатков, настройки закупок и существующий механизм обеспечения.
2. Проверить входящие данные. Если продажи поступают с касс, проверить актуальность кассового обмена. Frontol в таком контуре является источником кассовых данных, а не заменой учётной системе или ИИ-закупщиком. Если фактическая приёмка выполняется на ТСД, включить в обследование соответствующий обмен, без обещания одинаковой поддержки для всех версий.
3. Согласовать правила. Выбрать период, горизонт, резервирование, квант, минимум, график и набор исключений. Разделить типовые возможности и необходимые доработки.
4. Проверить рекомендации. На обезличенном наборе сравнить ручной расчёт с машинным, проверить нулевую потребность, позднее поступление, округление и неверные правила.
5. Испытать запись. На копии базы проверить черновик, блокировку дублей, права и запрет внешней отправки до подтверждения закупщика.
6. Оценить пилот. Зафиксировать долю ручных правок, причины исключений и время проверки. Изменения дефицита и излишков оценивать с учётом сопоставимых периодов; заранее заявлять экономию нельзя.

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

Что проверить перед первым рабочим заказом

Готовность определяется не красивым ответом ИИ, а воспроизводимым результатом и контролем действий. До запуска проверьте одну обычную строку, одну строку с округлением и одно исключение, которое система обязана остановить.

• У каждой строки известны источник, время данных и применённая версия правил.
• Резерв и уже ожидаемые закупки не учтены дважды.
• Количество, квант, минимум и единицы можно проверить вручную.
• Запись не даёт права незаметно провести или отправить заказ.
• Повтор расчёта не создаёт дубль; изменившийся остаток требует обновления предложения.
• Закупщик может отклонить результат, а решение сохраняется в журнале.

Продолжение практической серии про остатки, приёмку и контроль ценников появится в канале B2C. Эти процессы стоит привести в порядок до того, как доверять автоматике регулярное пополнение.

Официальные источники и границы проверки

• 1С:ИТС, «Формирование заказов по потребностям», УТ 11.5: источники обеспечения, график, ожидаемые поступления, упаковки и минимальные партии. Текст документации получен через проектный MCP 2 октября 2026 года; дата редакции страницы в ответе не указана.
• 1С:ИТС, «Упрощённый вариант обеспечения потребностей», УТ 11.5: среднедневное потребление, свободный остаток и создание заказов. Проверено через проектный MCP 2 октября 2026 года; актуальную реализацию конкретного релиза нужно сверять на базе.
• Microsoft, «Apply data validation to cells»: ограничения ввода чисел, дат и списков в Excel. Страница проверена 2 октября 2026 года; она не подтверждает механизм импорта в 1С.

Формула, протокол пяти объяснений и маршрут пилота являются предложенной методикой B2C. Арифметика учебных примеров проверена отдельно; запись в клиентскую базу, каналы уведомлений и загрузка Excel в конкретную конфигурацию в рамках статьи не тестировались. Поддержка каждого компонента подтверждается перед внедрением. Описанный контур не является универсальной готовой функцией всех продуктов.