Обмен 1С с сайтом: схемы, узкие места и типичные ошибки

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

Что обычно обменивается между 1С и сайтом

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

• Из 1С на сайт. Номенклатура (наименования, описания, характеристики), цены, остатки, категории, иногда изображения и статусы заказов.
• С сайта в 1С. Заказы, данные покупателей, способ оплаты и доставки, информация о платеже.
• В обе стороны. Статусы заказов и оплат, возвраты, корректировки.

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

Схемы обмена: какие бывают

Файловый обмен в стандартном формате

Платформа 1С умеет формировать файлы выгрузки каталога и заказов в формате обмена с сайтами (XML). Сайт или его модуль забирает файлы и разбирает их. Плюсы: распространённость, готовые модули для популярных CMS, понятная логика. Минусы: ограничения формата, сложность нестандартных полей, трудности при больших объёмах и при ошибках посреди обмена.

HTTP-сервисы 1С

Вы публикуете в 1С собственный интерфейс (HTTP-сервис) и обращаетесь к нему с сайта, либо 1С вызывает API сайта. Гибкость высокая: можно передавать только нужные данные, использовать JSON, возвращать понятные ошибки. Как устроены такие сервисы, описано в статье про HTTP-сервисы в 1С. Минус: придётся проектировать и поддерживать интерфейс самостоятельно.

Обмен через промежуточное звено

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

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

Узкие места и где они возникают

Я чаще всего вижу сбои в следующих местах.

1. Сопоставление товаров. Если нет надёжного идентификатора (уникальный код или артикул, неизменяемый ключ), после редактирования названия в 1С на сайте появляется дубль. Договоритесь об идентификаторе до первого обмена.
2. Остатки и резервы. Сайт показывает свободный остаток, а 1С учитывает резервы по складам. Нужно понимать, какой остаток отдаётся: учётный, доступный к заказу или по конкретному складу. Рассинхронизация приводит к продаже товара, которого нет.
3. Объём и время выгрузки. Полная выгрузка каталога каждый раз перегружает обе стороны. Лучше передавать изменения, а полную выгрузку использовать как резервный механизм.
4. Таймауты и ограничения хостинга. Ограничения по времени выполнения скрипта и размеру запроса обрывают обмен на середине. Требуется разбиение на порции.
5. Кодировки и формат данных. Проблемы с кириллицей, спецсимволами в описаниях, форматом дат и чисел.
6. Доступность 1С. Если база недоступна (обновление, обслуживание, сбой), заказ с сайта не должен потеряться.
7. Ручные правки на сайте. Если менеджер правит описание на сайте, а при следующем обмене оно перезаписывается из 1С, возникает недовольство. Определите, какие поля принадлежат какой системе.

Как передавать заказы надёжно

Заказы это самая чувствительная часть: потеря заказа стоит дороже, чем неактуальная цена. Рекомендуемые принципы:

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

Упрощённая схема очереди на стороне сайта выглядит так:

Заказ создан -> статус "new"
  -> воркер берёт заказы "new" / "retry"
  -> отправка в 1С (с внешним ID)
  -> успех: статус "sent", запись в журнал
  -> ошибка: статус "retry", счётчик попыток +1, пауза
  -> лимит попыток: статус "failed", уведомление ответственному

Оплата и статусы заказов

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

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

Чек-лист перед запуском обмена

1. Определены потоки данных и «главная» система по каждой сущности.
2. Выбран уникальный неизменяемый идентификатор для товаров, клиентов, заказов.
3. Проверено поведение при недоступности одной из сторон.
4. Настроены повторные попытки с ограничением и уведомление об окончательных ошибках.
5. Включено журналирование с возможностью поиска по номеру заказа.
6. Проверен обмен на тестовой копии базы и тестовом сайте, а не на рабочих данных.
7. Описан сценарий ручного исправления: как повторно отправить заказ и как сбросить зависший обмен.
8. Учтены обновления 1С: после смены релиза обмен проверяется отдельно, см. материал про обновление типовой конфигурации.
9. Закрыты права: учётная запись обмена имеет только необходимые права в 1С.

Мониторинг обмена: как узнавать о сбоях вовремя

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

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

Канал между сайтом и 1С должен быть защищён: только HTTPS, отдельная учётная запись с минимальными правами, секреты вне репозитория, ограничение доступа по адресам там, где это возможно. Входящие данные нельзя считать доверенными: проверяйте формат, размеры и обязательные поля, а в журнал не пишите персональные данные в открытом виде. Если сервис 1С доступен из интернета, проверьте, какие методы опубликованы, и отключите лишнее.

Частые вопросы

Какой обмен выбрать для небольшого интернет-магазина?

Если используется типовая конфигурация и популярная CMS, начните со стандартного файлового обмена, это быстрее и дешевле. Если нужны нестандартные поля, сложные цены или обмен в реальном времени, смотрите в сторону HTTP-сервисов.

Как часто нужно синхронизировать остатки?

Зависит от скорости оборота и риска продать отсутствующий товар. Для быстро расходуемых позиций остатки обновляют чаще, для редких реже. Хорошая практика: передавать изменения по событию или по короткому расписанию, а полную сверку выполнять периодически.

Что делать, если в 1С и на сайте разные данные?

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

Можно ли обойтись без программиста для настройки обмена?

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

Если нужно наладить или починить обмен между учётной системой и сайтом, посмотрите страницу про доработку и интеграции 1С или напишите мне в Telegram.