Website, CRM and ERP Integration with 1C

Overview

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

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

1C → website

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

1. A product, price, stock level or another object changes in 1C.
2. The exchange module prepares data for the website.
3. Запрос отправляется через API либо выгружается в формате CommerceML/XML.
4. Website проверяет полученные данные и находит объект по идентификатору или артикулу.
5. The changes are saved in the website database.
6. В журнал обмена записывается успешный результат либо описание ошибки.

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

Website → 1C

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

1. The customer creates an order on the website.
2. The website validates the order contents, customer and required fields.
3. A request is created for 1C with a unique order identifier.
4. 1C searches for an existing counterparty.
5. A new counterparty is created if necessary.
6. An order document is created with product line items.
7. 1C returns the document number and operation result.
8. Website сохраняет связь между своим заказом и документом в 1С.

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

ERP scenario

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

1. The legal entity is determined.
2. A warehouse or supply source is selected.
3. A customer order is created.
4. Product availability is checked.
5. A reservation is created.
6. Payment status is retrieved.
7. Shipment is monitored.
8. The current status is returned to the website or CRM.

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

What data can be exchanged

JSON, XML, CommerceML and OData

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

HTTP API / JSON

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

CommerceML / XML

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

OData

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

Web Services / SOAP

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

How synchronization is triggered

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

• immediately after an event;
• on a schedule;
• through background queues;
• in batches;
• manually from the administration interface.

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

Errors and retries

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

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

Security

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

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

What this demo shows

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

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

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