Сайт, CRM и 1С: кто должен быть главным в данных

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

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

Пример распределения ответственности

Это пример, а не универсальная архитектура. Распределение нужно проверить на ваших продуктах, версиях и правилах работы.

Возможность обмена — ещё не готовая интеграция

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

Источник: 1С: механизмы интеграции платформы.

Что обязательно обсудить с разработчиком

• Идентификаторы: как системы понимают, что речь об одном товаре, клиенте или заказе?
• Повторы: не создаст ли повторная отправка дубль?
• Задержки: что видит пользователь до завершения обмена?
• Конфликты: что делать, если значение изменили одновременно с двух сторон?
• Удаление и отмена: как они передаются и можно ли восстановить историю?
• Контроль: кто получает сообщение об ошибке и где видит её причину?

Не прячьте сбои за словом «успешно»

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

Проектируйте очередь, повторные попытки и ограничение дублей там, где это необходимо. Журнал должен помогать найти конкретную операцию, а не просто сообщать «ошибка обмена». Для поддержки заранее определите, какие сведения можно записывать, не раскрывая лишние персональные данные и секреты.

Запускайте обмен поэтапно

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

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

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