Интеграция сайта с 1С нужна, когда каталог, цены, остатки или заказы приходится переносить между системами вручную. Правильно спроектированный обмен убирает повторный ввод данных, но не начинается с выбора готового модуля: сначала нужно определить владельца каждого поля, направление синхронизации и правила обработки ошибок.
Ниже — практическая схема для интернет-магазина, B2B-каталога и корпоративного сайта с личным кабинетом. Она помогает подготовить требования к разработке без привязки к конкретной конфигурации 1С.
Интеграция сайта с 1С: что определить до разработки
Фраза «синхронизировать сайт с 1С» не описывает задачу. В одной компании 1С хранит только номенклатуру и цены, в другой — ещё контрагентов, договоры, склады и статусы заказов. Иногда карточки товаров редактирует контент-менеджер на сайте, а учётная система отвечает только за коммерческие данные.
Перед оценкой проекта составьте карту сущностей. Для каждой сущности укажите источник истины — систему, где данные создаются и считаются корректными.
| Сущность | Возможный источник истины | Что передаётся | Направление |
|---|---|---|---|
| Товар | 1С | код, название, единица измерения | 1С → сайт |
| Описание и медиа | CMS сайта | текст, фото, документы | внутри сайта |
| Цена | 1С | тип цены, валюта, период действия | 1С → сайт |
| Остаток | 1С | склад, доступное количество | 1С → сайт |
| Заказ | сайт | состав, контакты, доставка, комментарий | сайт → 1С |
| Статус заказа | 1С | принят, собран, отгружен | 1С → сайт |
Такой документ заранее выявляет конфликты. Например, если название товара разрешено менять в обеих системах, очередной обмен может затереть правку. Если у цены нет идентификатора типа, сайт не поймёт, какую цену показывать конкретному клиенту.
Какие сценарии обмена нужны бизнесу
Не все данные должны обновляться одинаково часто. Карточки товаров меняются редко, остатки чувствительнее к задержкам, а заказ должен попасть в учётную систему без потери состава и контактов.
Каталог и характеристики
Для каталога важны стабильные внешние идентификаторы. Название или артикул могут измениться, поэтому связывать записи только по текстовому полю рискованно. Вместе с товаром обычно передают категорию, единицу измерения, характеристики, налоговые признаки и состояние публикации.
Отдельно решите, что делать с товаром, который исчез из выгрузки. Автоматическое удаление способно создать неработающие URL и потерю поискового трафика. Безопаснее снять товар с продажи, сохранить страницу и предложить аналог, если это соответствует ассортиментной политике. При изменении адресов заранее подготовьте карту переноса и правила редиректов.
Цены и остатки
У B2B-компании может быть несколько типов цен: базовая, дилерская, договорная или зависящая от объёма. В требованиях нужно указать, кто имеет право видеть каждую цену и что показывать, если коммерческое условие не найдено.
Остаток тоже не всегда равен физическому количеству на складе. Для сайта может использоваться доступный остаток с учётом резерва. Если точное число раскрывать нельзя, интерфейс может показывать понятные состояния: в наличии, под заказ, уточняйте у менеджера. Формулировка должна соответствовать реальной логике учёта.
Заказы и контрагенты
Заказ с сайта должен передаваться идемпотентно: повторный запрос после сетевой ошибки не должен создавать дубль. Для этого сайту и 1С нужен общий внешний идентификатор операции.
Минимальный состав заказа включает:
- позиции, количество и цену на момент оформления;
- контакты и реквизиты покупателя;
- выбранный способ доставки и оплаты;
- комментарий клиента;
- источник и UTM-метки, если они используются в аналитике;
- технический идентификатор для повторной проверки.
Если лид до заказа проходит через CRM, полезно заранее согласовать общую модель данных. В статье об интеграции CRM и аналитики показано, как связать источник обращения, сделку и результат без ручных таблиц.
Как выбрать способ интеграции
Способ обмена зависит от конфигурации 1С, инфраструктуры и требований к актуальности. Универсального варианта нет.
| Подход | Когда подходит | Что проверить |
|---|---|---|
| Файловый обмен | пакетное обновление каталога и цен | формат, расписание, объём, повторная обработка |
| HTTP API | адресные запросы и частые операции | авторизация, лимиты, журнал запросов |
| Очередь сообщений | много событий и независимых систем | повторная доставка, порядок, мониторинг |
| Промежуточный сервис | сложные преобразования и несколько каналов | ответственность, резервирование, поддержка |
Готовый модуль ускоряет типовой сценарий, но не отменяет анализа. Он может не учитывать несколько складов, персональные цены или нестандартные справочники. До выбора решения запросите описание доступных интерфейсов у специалиста по 1С и проверьте их на тестовом контуре.
Правила данных, которые предотвращают дубли
Большинство проблем обмена связано не с транспортом, а с качеством справочников. Один товар может иметь разные артикулы, у контрагента встречаются несколько карточек, а обязательное поле оказывается пустым.
Зафиксируйте правила:
- Какой идентификатор связывает записи между системами.
- Какие поля обязательны для публикации или передачи.
- Кто исправляет ошибку и в какой системе.
- Как обрабатываются архивные записи.
- Можно ли повторно выполнить операцию без дубля.
- Где хранится история изменений и результат обмена.
До запуска полезно очистить справочники и договориться о единых значениях. Подход к такой подготовке разобран в материале про качество данных CRM и автоматизацию; те же принципы применимы к товарным и клиентским данным.
Безопасность и устойчивость обмена
Не публикуйте интерфейс 1С напрямую в интернет без необходимой защиты. Интеграции нужны отдельные учётные данные с минимальными правами, защищённый канал и ограниченный набор операций. Секреты не должны попадать в клиентский JavaScript или журнал браузера.
Для эксплуатации предусмотрите:
- журнал успешных и ошибочных операций;
- понятное сообщение о причине отказа;
- повторную отправку без создания дубля;
- уведомление ответственному при серии ошибок;
- резервный сценарий на время недоступности одной системы;
- контроль изменений формата данных.
Пользователь не должен терять заказ из-за временной ошибки. Сайт может сохранить операцию, показать подтверждение только после надёжной фиксации и передать данные повторно по заданному правилу.
Как тестировать интеграцию перед запуском
Проверяйте не только успешный обмен. Тестовый набор должен включать пустые поля, архивный товар, изменение цены, нулевой остаток, повторную отправку одного заказа и временную недоступность 1С.
Практичный порядок проверки:
- Подготовить тестовые товары и контрагентов.
- Выполнить полную первичную загрузку.
- Изменить по одному полю каждого типа.
- Создать заказ с разными позициями.
- Повторить тот же запрос и проверить отсутствие дубля.
- Отключить тестовый интерфейс и проверить очередь ошибок.
- Восстановить соединение и убедиться, что данные дошли один раз.
- Сверить карточки, суммы и статусы в обеих системах.
Результаты фиксируйте в протоколе приёмки: входные данные, ожидаемый результат, фактический результат и ответственный за исправление.
Что включить в техническое задание
Для предварительной оценки подготовьте версию и конфигурацию 1С, список сущностей, примеры выгрузок, владельцев доступов и описание бизнес-сценария. Также нужны правила авторизации, частота обмена, допустимое поведение при ошибке и критерии приёмки.
Не забудьте определить поддержку после запуска: кто меняет интеграцию при добавлении поля, где смотреть журнал и как тестировать обновления. Общую структуру требований можно взять из статьи о техническом задании на B2B-сайт.
Если нужен сайт, личный кабинет или каталог с обменом данных, изучите услугу разработки веб-систем и интеграций. Первый результат обсуждения — не обещание «подключить 1С», а согласованная карта данных, сценариев и ответственности.
