MAXYappMAXYapp
· 7 мин· 16 июля 2026 г.

Интеграция MAX с 1С: заказы, остатки, цены и уведомления

Как связать чат-бот и Mini App в MAX с 1С: выбрать архитектуру, синхронизировать каталог, создавать заказы и возвращать клиенту статусы.

Интеграция MAX с 1С позволяет показывать в Mini App актуальные товары, цены и остатки, создавать заказы в учётной системе и возвращать пользователю статусы через чат-бота. Это устраняет ручное копирование и делает MAX полноценной точкой клиентского обслуживания.

Универсального способа подключения нет: архитектура зависит от конфигурации 1С, доработок, доступного API и бизнес-процесса компании.

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

Какие задачи можно автоматизировать

Каталог

Из 1С передаются номенклатура, категории, характеристики, изображения или ссылки на них. Mini App отображает данные в адаптированном виде.

Цены

Система может учитывать тип цены, регион, сегмент клиента, акции и персональные условия. Финальный расчёт выполняется на backend или в 1С, а не во фронтенде.

Остатки

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

Заказ

После подтверждения backend создаёт документ или заявку в 1С, получает номер и сохраняет связь с пользователем MAX.

Статусы

Изменения «принят», «подтверждён», «собран», «передан в доставку», «готов» отправляются ботом. Пользователь может самостоятельно открыть историю в Mini App.

Документы и B2B-сервис

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

Что выяснить о 1С до оценки

  1. Конфигурация: УНФ, УТ, ERP, КА или собственное решение.
  2. Версия платформы и режим работы.
  3. Типовая база или доработанная.
  4. Доступные HTTP-сервисы, OData, обмен или расширения.
  5. Наличие тестового контура.
  6. Структура номенклатуры и характеристик.
  7. Правила цен и скидок.
  8. Количество складов.
  9. Документ, который должен создаваться.
  10. Статусы и ответственные.
  11. Требования информационной безопасности.
  12. Владельцы и подрядчик по 1С.

Без этих данных нельзя корректно оценить интеграцию. Одинаковое название конфигурации не гарантирует одинаковую структуру.

Рекомендуемая архитектура

Для production обычно используется промежуточный backend:

Пользователь → MAX Bot / Mini App → Backend → Интеграционный слой → 1С
                                              ↓
                                         Очередь и логи

Backend:

  • валидирует пользователя MAX;
  • хранит токен бота;
  • адаптирует данные 1С для мобильного интерфейса;
  • кеширует справочники;
  • ставит операции в очередь;
  • контролирует повторы;
  • ограничивает нагрузку;
  • возвращает понятный статус.

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

Варианты обмена

Синхронный запрос

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

Плюс — пользователь сразу получает результат. Минус — интерфейс зависит от доступности 1С.

Асинхронная очередь

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

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

Периодическая синхронизация

Каталог, цены и остатки выгружаются по расписанию в отдельную базу. Mini App работает с быстрым backend, а перед заказом выполняется дополнительная проверка.

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

Как синхронизировать каталог

Определите устойчивые идентификаторы и не связывайте товары только по названию. Нужно учитывать:

  • GUID номенклатуры;
  • характеристики и варианты;
  • единицы измерения;
  • группы;
  • удаление и архив;
  • изображения;
  • видимость в MAX;
  • дату изменения.

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

Как создавать заказ

Последовательность:

  1. Пользователь подтверждает корзину.
  2. Backend повторно получает цены и наличие.
  3. Система фиксирует idempotency key.
  4. Создаётся внутренняя операция.
  5. Данные передаются в 1С.
  6. 1С возвращает идентификатор и номер.
  7. Backend сохраняет связь.
  8. Бот отправляет подтверждение.

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

Статусы и уведомления

Статусы 1С следует преобразовать в понятные клиенту формулировки. Внутренние значения вроде «К обеспечению» или «Ожидается подтверждение подразделения» могут требовать адаптации.

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

Уведомления могут инициироваться:

  • Webhook из интеграционного слоя;
  • регламентной проверкой изменений;
  • событием очереди;
  • действием менеджера.

Безопасность

  • не публикуйте 1С напрямую без необходимости;
  • используйте отдельного технического пользователя;
  • выдавайте минимальные права;
  • ограничивайте доступ по сети;
  • храните секреты вне кода;
  • шифруйте соединение;
  • маскируйте персональные данные в логах;
  • ведите аудит операций;
  • разделяйте тестовую и production-базы;
  • контролируйте объём и частоту запросов.

Как начать с пилота

Хороший пилот включает один процесс:

  • показать ограниченную категорию;
  • получить актуальную цену;
  • создать заявку или заказ;
  • вернуть номер;
  • сообщить один-два статуса.

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

Критерии приёмки

  • один товар имеет одинаковый идентификатор во всех системах;
  • цена и наличие проверяются перед заказом;
  • повтор не создаёт дубль;
  • потерянная операция восстанавливается;
  • пользователь получает корректный статус;
  • сотрудник видит источник MAX;
  • недоступность 1С не приводит к потере заявки;
  • логи позволяют найти операцию без раскрытия секретов;
  • нагрузка не мешает учётной системе.

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

Есть ли готовая универсальная интеграция MAX с 1С?

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

Можно ли подключить 1С без изменения базы?

Иногда — если уже доступны подходящие API и данные. В других случаях понадобится расширение, HTTP-сервис или отдельная выгрузка.

Нужно ли показывать остатки в реальном времени?

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

Что делать, если 1С недоступна?

Сохранить операцию в промежуточной системе, показать честный статус и повторить передачу по контролируемой политике. Заявка не должна исчезнуть.

Кто должен поддерживать интеграцию?

Нужны ответственные как за MAX/backend, так и за 1С. Изменение справочников, прав или конфигурации на одной стороне может повлиять на весь поток.

Подходит под ваш сценарий? Обсудим пилот.

Написать