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

Название, описание, изображение и базовая цена могут обновляться пакетно.

Но реальная цена может зависеть от:

контрагента;

договора;

объёма;

валюты;

акции;

региона;

условий оплаты.

Если сайт хранит упрощённую копию сложной логики 1С, две системы постепенно расходятся.

Поэтому мы отдельно определяем, что можно публиковать как данные, а что нужно рассчитывать или подтверждать при запросе.

Часть уже зарезервирована.

Часть находится на другом складе.

Часть недоступна по качеству.

Есть ожидаемое поступление.

Есть минимальный остаток.

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

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

Сайт знает:

состав корзины;

контакты;

адрес;

способ доставки;

способ оплаты;

промокод;

комментарий.

1С может дополнительно требовать:

контрагента;

договор;

организацию;

склад;

тип цен;

налоговые параметры;

служебные реквизиты.

AMPE переводит web-заказ в прикладную модель 1С через явное сопоставление, а не через случайный набор полей.

Пользователь нажал «Оформить».

Сайт успешно сохранил заказ.

Но в 1С может ещё происходить:

проверка контрагента;

подтверждение цены;

резерв;

проверка оплаты;

проверка возможности исполнения.

Если сайт сразу обещает конечный результат, которого back-office ещё не подтвердил, интеграция создаёт ложное ожидание.

Поэтому мы моделируем промежуточные состояния там, где они действительно существуют.

Платёжный сервис может сообщить об успешной операции.

Но финансовое состояние заказа в 1С должно измениться контролируемо.

Webhook от платёжного провайдера проверяется.

Событие связывается с конкретным заказом.

Повторная доставка не должна создать повторный эффект.

При необходимости итог сверяется с источником.

AMPE не считает внешний callback достаточным основанием для неконтролируемого изменения учётного состояния.

Сайт передал заказ в 1С — это только половина интеграции.

Клиенту дальше важно знать:

подтверждён;

оплачен;

собирается;

отгружен;

готов к выдаче;

отменён;

возникла проблема.

1С или связанные системы должны вернуть наружу подтверждённое состояние.

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

Публичный сайт имеет совершенно другой профиль нагрузки.

Тысячи просмотров каталога не должны превращаться в тысячи синхронных запросов в 1С.

Поэтому AMPE разделяет:

данные, которые можно кэшировать;

данные, которые обновляются событиями;

данные, которые действительно требуют online-проверки.

Так 1С остаётся защищённой от нагрузки frontend.

Интеграция проходит через контролируемую границу:

API;

integration service;

middleware;

очередь;

reverse proxy;

другой ограниченный интерфейс.

Авторизация, validation, rate limiting, secret management и logging здесь являются частью архитектуры, а не дополнительной защитой «потом».

Пользователь повторил действие.

Browser повторил запрос.

Frontend не получил ответ.

Интеграция должна распознать повтор бизнес-операции.

Идемпотентный ключ или другой устойчивый business identifier проектируется до появления первых дублей.

Из 1С на сайт:

номенклатура;

цены;

доступность;

статусы;

документы;

персональные условия;

данные личного кабинета.

С сайта в 1С:

заказы;

клиентские данные;

выбранные условия;

оплаты или подтверждения оплаты;

заявки на документы;

другие действия пользователя.

Конкретный состав всегда следует бизнес-процессу, а не желанию «синхронизировать всё».

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

Сайт получает подготовленные данные для быстрого отображения.

Критические значения подтверждаются в нужный момент.

Заказ имеет устойчивый идентификатор через весь путь.

Статус возвращается пользователю после фактических изменений back-office.

Публичный слой не знает внутренней структуры 1С.

Каталог меньше расходится с учётом.

Клиент получает более реалистичную доступность.

Заказы не приходится переносить вручную.

Повторные запросы не создают дубли.

Личный кабинет может показывать реальные документы и статусы.

1С не становится backend каждого page view.

И главное — то, что клиент видит на сайте, начинает соответствовать тому, что компания действительно способна исполнить.