Бот подтвердил заказ, которого не было на складе: где нужна связь с 1С

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

заявка, которую бот подтвердил, а склад — нет

Интернет-магазин автозапчастей в Подмосковье поставил чат-бота на сайт перед Новым годом. В половине первого ночи покупатель спрашивает про тормозные колодки для конкретной модели Camry — бот отвечает «да, есть на складе» и предлагает внести предоплату. Покупатель платит. Утром менеджер открывает 1С, чтобы собрать заказ, и видит: последняя пара колодок ушла со склада три дня назад обычной розничной продажей в зале.

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

Дальше — звонок с извинениями, возврат предоплаты и покупатель, который уже оформил тот же заказ у конкурента, пока менеджер объяснял, что бот ошибся. Один такой случай стоит компании не только сорванной продажи и часа работы менеджера на разбор, но и отзыва в духе «обещали — не привезли», который читают следующие покупатели перед тем, как решить, писать боту или нет.

три способа подключить бота к 1С

Проблема из примера решается не фразой «просто подключите бота к базе», а выбором, как именно он туда ходит. У интеграции чата с 1С три рабочие схемы, и ведут они себя под нагрузкой по-разному.

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

Прямой запрос на каждое сообщение. Бот обращается к HTTP-сервису 1С при любом вопросе про товар. Данные всегда свежие, но каждый диалог — это ещё один запрос к той же базе, где параллельно работают кассиры, а бухгалтерия закрывает период или формирует накладные. При нескольких десятках одновременных чатов это ощутимая дополнительная нагрузка на систему, где люди в это время считают деньги.

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

что выбрать: сравнение трёх вариантов

Разница между схемами не в том, какая правильнее, а в том, для какого товара и какой нагрузки на базу она рассчитана:

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

когда бот обязан спрашивать 1С в реальном времени

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

остатки

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

цены

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

как устроена интеграция технически

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

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

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

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

сколько стоит подключить бота к 1С и с чего начать

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

Работу оцениваем после короткого аудита конфигурации — почасовая ставка на доработку и сопровождение 1С у нас от 3800 руб/час. Для типовой конфигурации вроде 1С:Управление торговлей публикация сервиса под остатки и цену обычно занимает дни, а не недели: большая часть логики хранения данных в базе уже есть, разработчику остаётся правильно её ограничить и отдать боту.

Аудит перед доработкой обычно включает несколько шагов:

• ✓проверяем версию платформы и конфигурации, смотрим, есть ли уже HTTP-сервисы;
• ✓прогоняем тестовую нагрузку, чтобы понять, выдержит ли база регулярные запросы от бота в рабочие часы;
• ✓публикуем сервис с точками под остаток и цену, ограниченными на чтение;
• ✓настраиваем кэш и расписание выгрузки для позиций, которые не требуют запроса в реальном времени.

Если на сайте уже стоит чат-бот, который отвечает по статичному прайсу, — это чаще всего правится точечной доработкой, без замены самого бота и без переноса базы на новое место.

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

Бот может ошибочно продать товар, которого нет на складе?

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

Нужно ли давать боту доступ на запись в 1С?

Нет, для проверки остатков и цен достаточно доступа только на чтение через HTTP-сервис. Запись заказов в базу — отдельная функция с дополнительными проверками, и её стоит внедрять только после того, как отработана логика чтения данных.

Как часто нужно обновлять кэш остатков для бота?

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

Что делать, если в 1С ещё нет HTTP-сервисов?

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

Сколько времени занимает подключение бота к остаткам и ценам в 1С?

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