Обмен сайта с 1С: каталог, цены, остатки и заказы без потерь

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

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

Автор: Дмитрий Ковалёв, Backend Developer, 404gen.