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