Интеграция сайта с 1С: сценарии обмена, ошибки и источник истины

# Интеграция сайта с 1С: сценарии обмена, ошибки и источник истины

Редакция SGI24. Практическая основа — реализованная интеграция DentPro с 1С; перенос на другую конфигурацию требует отдельного обследования. [О бюро](/company).

Интеграция сайта с 1С нужна, когда цена, услуга, остаток, заказ, договор или оплата не должны переноситься вручную. Но слово «синхронизация» скрывает десятки решений: какая система владеет полем, когда выполняется обмен, что считать успехом и как действовать при конфликте.

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

Спроектировать обмен сайта, CRM и 1С

Какие задачи решает обмен

Типовые сценарии:

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

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

Источник истины — основная система с исходными данными

Для каждого поля выбирается одна главная система.

Данные	Возможная основная система	Потребители
номенклатура	1С	сайт, CRM
цена	1С или отдельный продуктовый контур	сайт, договор
контент страницы	CMS сайта	сайт
первичная заявка	CRM	1С после квалификации
платёж	учётная или платёжная система	CRM, кабинет
статус исполнения	1С или профильная система	CRM, сайт

Таблица определяется по конкретной конфигурации. Главное — не допустить двух равноправных редакторов одного поля без правила конфликта.

Не выгружайте в 1С каждую форму

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

Рабочая цепочка:

text сайт → CRM → квалификация → подтверждённый клиент или заказ → 1С

Из 1С обратно приходят счёт, оплата, отгрузка или другой учётный факт.

Для простого интернет-магазина заказ может сразу попадать в 1С по утверждённому правилу. Для сложной B2B-услуги до этого нужен менеджер. Архитектура отражает процесс продаж.

Каталог

При обмене номенклатурой определите:

внутренний идентификатор;
артикул;
название;
категория;
характеристики;
единица;
ставка и цена;
остаток;
доступность;
изображение;
описание;
архивность.

Не все поля должны приходить из 1С. Учётное название «Услуга 000123» может быть непригодно для сайта. Сохраните связь с номенклатурой, а публичный заголовок и SEO-текст ведите в CMS.

Цены

Цена зависит от:

типа клиента;
региона;
договора;
количества;
акции;
периода;
налога;
валюты;
комплектации.

Передача одной цифры без типа цены создаёт ошибки. Сайт должен знать, какую цену показывать, когда считать её предварительной и когда запросить расчёт.

После изменения цена не должна задним числом менять уже подтверждённый заказ. Сохраняйте снимок условий на момент операции.

Остатки и доступность

Физический остаток, доступный к продаже и резерв — разные числа. Сайт показывает значение по правилу бизнеса.

Проверьте:

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

Фраза «в наличии» требует источника и допустимой задержки. При редком обмене лучше показать «уточнить наличие», чем обещать устаревший остаток.

Услуги и расписание

Для записи сайт может получать из 1С или профильной системы:

услуги;
специалистов;
подразделения;
даты;
свободное время;
длительность;
ограничения;
цену.

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

В стоматологическом сценарии сайт может получать из 1С список услуг, врачей, дат и времени, поддерживать авторизацию пациента и создавать запись через официальный API. Такая интеграция связывает сайт с расписанием, но не заменяет медицинскую информационную систему или отдельный обмен с ЕГИСЗ.

Заказ

Заказ содержит:

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

Перед записью 1С проверяет справочники и сумму по правилам. Если цена изменилась, система возвращает смысловую ошибку, а не молча создаёт заказ с другим итогом.

Контрагент и контактное лицо

Юридическое лицо и физическое контактное лицо — разные объекты. Сайт или CRM может получить ИНН, название, реквизиты и представителя.

Проверьте:

поиск существующего контрагента;
филиалы;
несколько контактных лиц;
плательщика;
договор;
полномочия;
дубли по ИНН и КПП;
изменение реквизитов;
историю.

Нельзя автоматически перезаписывать юридические реквизиты данными из неподтверждённой формы.

Счёт и документы

CRM передаёт в 1С подтверждённые данные. 1С создаёт документ и возвращает:

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

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

Оплата

Статус денег приходит из основной платёжной или учётной системы: банка; эквайринга; кассы; 1С после сверки; платёжного провайдера.

В CRM и кабинете отображается подтверждённое состояние. Менеджер не ставит «оплачено» вручную по фотографии перевода, если процесс этого не предусматривает.

Для частичной оплаты храните сумму и остаток. Для возврата — отдельную операцию и связь с исходным платежом.

Статусы исполнения

У сайта, CRM и 1С могут быть разные статусы. Составьте таблицу соответствия:

1С	CRM	Кабинет клиента
заказ принят	оформлен	заказ принят
ожидается оплата	ожидается оплата	требуется оплатить
в производстве	исполняется	в работе
готов	готов к выдаче	можно получить
закрыт	завершён	выполнен

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

Направление обмена

Для каждого объекта укажите:

1С → сайт;
сайт → 1С;
CRM → 1С;
1С → CRM;
двусторонний обмен с правилами.

Двусторонняя синхронизация сложнее: нужно определить порядок версий и разрешение конфликтов. Если поле редактируется только в 1С, обратную запись запрещают на уровне прав и в интерфейсе.

Частота

Варианты:

По событию

Сразу после заказа, оплаты или изменения статуса.

По расписанию

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

По запросу

Проверка актуального слота, цены или документа перед действием.

Пакетно

Большие выгрузки в согласованное окно.

Не всё должно работать в реальном времени. Но задержка должна быть известна пользователю и бизнесу.

Идентификаторы

Для каждого объекта сохраняются: внутренний ID сайта или CRM; ID 1С; версия; дата изменения; источник изменения; ключ операции.

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

Идемпотентность

Повтор запроса не создаёт второй заказ, запись, счёт или платёж. Операция получает ключ, а принимающая система:

ищет существующий результат;
возвращает его;
не повторяет побочный эффект;
журналирует повтор.

Для изменения используется версия или условие, чтобы старый запрос не перезаписал новые данные.

Ошибки

Разделите:

Временные

Недоступность сети, тайм-аут, краткий сбой. Возможен ограниченный повтор.

Авторизация

Истёк ключ, недостаточно прав. Требуется техническое вмешательство.

Смысловые

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

Конфликт версии

Данные изменились после начала операции. Система не должна молча перезаписывать более новую запись.

Каждая ошибка связывается с объектом, временем и действием. Персональные данные в журнале маскируются.

Очередь

Для критичных операций используется очередь состояний:

подготовлено;
отправлено;
принято;
обработано;
временная ошибка;
требуется решение;
завершено.

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

API, файлы или промежуточный шлюз

API

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

Файловый обмен

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

Интеграционный шлюз

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

Выбор зависит от конфигурации, нагрузки и допустимой задержки.

Безопасность

Проверьте:

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

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

Тестовый контур

Перед боевым запуском нужны:

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

Тестовый заказ не должен попадать в реальную отгрузку или отчётность.

Приёмка

Для каждого сценария проверяется полный путь.

Пример заказа:

Сайт показывает актуальную позицию и цену.
Пользователь оформляет заказ.
CRM получает обращение.
После подтверждения 1С создаёт заказ.
ID связываются.
Оплата меняет подтверждённый статус.
Кабинет показывает понятный результат.
Повтор не создаёт дубль.
Ошибка видна ответственному.

Успешный HTTP-ответ не доказывает создание правильного документа в 1С.

Мониторинг

Отчёт показывает:

операции за период;
успешные;
ожидающие;
повторные;
смысловые ошибки;
задержку;
несопоставленные объекты;
расхождение итогов;
последний успешный обмен.

Сигнал должен вести к конкретному объекту и действию, а не сообщать абстрактное «интеграция сломана».

Частые ошибки

Не определена основная система.
В 1С создаётся каждый лид.
Публичное название берётся из учётного поля.
Остаток не учитывает резерв.
Цена не имеет типа и периода.
Название используется как идентификатор.
Повтор создаёт второй счёт.
Ошибка бесконечно повторяется.
Оплату отмечает менеджер.
Статусы не сопоставлены.
Тесты идут в боевой базе.
Интеграция имеет лишние права.

Как разделяется ответственность сайта и 1С

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

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

Обсудить интеграцию сайта, CRM и 1С

В обращении укажите конфигурацию 1С, объект обмена и систему, где он должен создаваться первым. Это задаст предмет обследования без обещания универсального коннектора.

Связанные материалы

Точный обмен зависит от конфигурации 1С, бизнес-процесса, нагрузки и действующих внешних систем.