Интеграция сайтов и CRM с 1С

Сайт не подключается напрямую к таблицам базы 1С. Обмен происходит через согласованный интерфейс: HTTP API, CommerceML, OData, web-сервисы либо другой механизм, который подходит конкретной конфигурации.

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

В первом сценарии 1С является источником данных. Это типичная схема для интернет-магазина или каталога, где товарный учёт ведётся в 1С.

1. В 1С изменяется товар, цена, остаток или другой объект.
2. Модуль обмена формирует данные для сайта.
3. Запрос отправляется через API либо выгружается в формате CommerceML/XML.
4. Сайт проверяет полученные данные и находит объект по идентификатору или артикулу.
5. Изменения сохраняются в базе сайта.
6. В журнал обмена записывается успешный результат либо описание ошибки.

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

Обратный сценарий используется для заказов, заявок, клиентов, платежей и других данных, которые появляются сначала на сайте или в CRM.

1. Покупатель создаёт заказ на сайте.
2. Сайт проверяет состав заказа, клиента и обязательные поля.
3. Формируется запрос к 1С с уникальным идентификатором заказа.
4. В 1С выполняется поиск существующего контрагента.
5. При необходимости создаётся новый контрагент.
6. Создаётся документ заказа с товарными позициями.
7. 1С возвращает номер документа и результат операции.
8. Сайт сохраняет связь между своим заказом и документом в 1С.

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

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

1. Определяется организация.
2. Выбирается склад или источник обеспечения.
3. Создаётся заказ клиента.
4. Проверяется доступность товара.
5. Создаётся резерв.
6. Получается состояние оплаты.
7. Контролируется отгрузка.
8. Актуальный статус возвращается в сайт или CRM.

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

Передаём каталог, цены, остатки, резервы, клиентов, заказы, оплаты, документы, отгрузки и статусы. Состав объектов зависит от конфигурации 1С и процессов компании.

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

Формат обмена выбирается не потому, что один формат «лучше» другого, а исходя из существующей инфраструктуры и задачи.

JSON и HTTP API

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

XML и CommerceML

Часто применяется при интеграции 1С с интернет-магазинами: каталог, цены, остатки и заказы передаются в стандартной XML-структуре.

OData

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

Существующие веб-сервисы

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

Обмен необязательно происходит по кнопке. В рабочем проекте обычно используется один или несколько вариантов запуска:

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

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

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

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

Сайт отправил заказ, но не получил ответ из-за обрыва соединения. При повторной попытке 1С сначала проверяет внешний ID заказа и возвращает уже созданный документ, вместо создания второго.

API интеграции не должен быть общедоступным. В зависимости от проекта применяются HTTPS, токены доступа, отдельные технические пользователи, ограничения по IP, подпись запросов и журналирование операций.

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

Интерфейс выше показывает три основных класса интеграций: получение данных из 1С, передачу данных в 1С и многоэтапный ERP-процесс.

На этапе разработки интерфейса сценарии выполняются демонстрационно в браузере. После подключения тестовой 1С те же действия будут обращаться к реальному backend: значения будут считываться из 1С, заказ будет действительно создаваться в информационной базе, а журнал будет показывать фактические запросы и ответы.

В коммерческом проекте состав объектов и бизнес-правила определяются конкретной конфигурацией 1С, ERP-системой и процессами заказчика.