Интеграция MAX с 1С позволяет показывать в Mini App актуальные товары, цены и остатки, создавать заказы в учётной системе и возвращать пользователю статусы через чат-бота. Это устраняет ручное копирование и делает MAX полноценной точкой клиентского обслуживания.
Универсального способа подключения нет: архитектура зависит от конфигурации 1С, доработок, доступного API и бизнес-процесса компании.
Перед собственной разработкой стоит проверить каталог партнёрских интеграций MAX. Готовый коннектор подходит только тогда, когда поддерживает нужную конфигурацию, поля, статусы и правила обмена.
Какие задачи можно автоматизировать
Каталог
Из 1С передаются номенклатура, категории, характеристики, изображения или ссылки на них. Mini App отображает данные в адаптированном виде.
Цены
Система может учитывать тип цены, регион, сегмент клиента, акции и персональные условия. Финальный расчёт выполняется на backend или в 1С, а не во фронтенде.
Остатки
Показываются доступность по складам, резерв и ограничения. Частота обновления зависит от бизнеса: для редких B2B-заказов достаточно периодической синхронизации, для быстро меняющихся остатков нужна проверка перед оформлением.
Заказ
После подтверждения backend создаёт документ или заявку в 1С, получает номер и сохраняет связь с пользователем MAX.
Статусы
Изменения «принят», «подтверждён», «собран», «передан в доставку», «готов» отправляются ботом. Пользователь может самостоятельно открыть историю в Mini App.
Документы и B2B-сервис
Для авторизованных партнёров можно показывать счета, спецификации и статусы. Такой сценарий требует строгой модели прав и аудита.
Что выяснить о 1С до оценки
- Конфигурация: УНФ, УТ, ERP, КА или собственное решение.
- Версия платформы и режим работы.
- Типовая база или доработанная.
- Доступные HTTP-сервисы, OData, обмен или расширения.
- Наличие тестового контура.
- Структура номенклатуры и характеристик.
- Правила цен и скидок.
- Количество складов.
- Документ, который должен создаваться.
- Статусы и ответственные.
- Требования информационной безопасности.
- Владельцы и подрядчик по 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С редко подходит для прямого отображения.
Как создавать заказ
Последовательность:
- Пользователь подтверждает корзину.
- Backend повторно получает цены и наличие.
- Система фиксирует idempotency key.
- Создаётся внутренняя операция.
- Данные передаются в 1С.
- 1С возвращает идентификатор и номер.
- Backend сохраняет связь.
- Бот отправляет подтверждение.
Если ответ от 1С потерян после фактического создания документа, повтор не должен создавать второй заказ. Нужен внешний ключ или поиск операции перед повторным созданием.
Статусы и уведомления
Статусы 1С следует преобразовать в понятные клиенту формулировки. Внутренние значения вроде «К обеспечению» или «Ожидается подтверждение подразделения» могут требовать адаптации.
Не каждое техническое изменение нужно отправлять пользователю. Сформируйте ограниченный клиентский набор и правила переходов.
Уведомления могут инициироваться:
- Webhook из интеграционного слоя;
- регламентной проверкой изменений;
- событием очереди;
- действием менеджера.
Безопасность
- не публикуйте 1С напрямую без необходимости;
- используйте отдельного технического пользователя;
- выдавайте минимальные права;
- ограничивайте доступ по сети;
- храните секреты вне кода;
- шифруйте соединение;
- маскируйте персональные данные в логах;
- ведите аудит операций;
- разделяйте тестовую и production-базы;
- контролируйте объём и частоту запросов.
Как начать с пилота
Хороший пилот включает один процесс:
- показать ограниченную категорию;
- получить актуальную цену;
- создать заявку или заказ;
- вернуть номер;
- сообщить один-два статуса.
Не обязательно сразу синхронизировать весь каталог, историю, бонусы и документы. Сначала подтвердите устойчивость обмена и пользу для клиента.
Критерии приёмки
- один товар имеет одинаковый идентификатор во всех системах;
- цена и наличие проверяются перед заказом;
- повтор не создаёт дубль;
- потерянная операция восстанавливается;
- пользователь получает корректный статус;
- сотрудник видит источник MAX;
- недоступность 1С не приводит к потере заявки;
- логи позволяют найти операцию без раскрытия секретов;
- нагрузка не мешает учётной системе.
Частые вопросы
Есть ли готовая универсальная интеграция MAX с 1С?
Существуют партнёрские коннекторы для отдельных задач, но универсальность зависит от конфигурации и процесса. Для доработанной 1С обычно требуется обследование и индивидуальный слой.
Можно ли подключить 1С без изменения базы?
Иногда — если уже доступны подходящие API и данные. В других случаях понадобится расширение, HTTP-сервис или отдельная выгрузка.
Нужно ли показывать остатки в реальном времени?
Не всегда. Требование зависит от скорости продаж и риска отмены. Для многих сценариев достаточно кеша с повторной проверкой перед заказом.
Что делать, если 1С недоступна?
Сохранить операцию в промежуточной системе, показать честный статус и повторить передачу по контролируемой политике. Заявка не должна исчезнуть.
Кто должен поддерживать интеграцию?
Нужны ответственные как за MAX/backend, так и за 1С. Изменение справочников, прав или конфигурации на одной стороне может повлиять на весь поток.
