Все услуги

одним списком

ART-FREsH ECOMMERCE SOLUTIONS

Интеграция интернет-магазина и «1С»: часть третья

Неверная настройка регламента обмена данными
Антон Каневский
Art-Fresh Ecommerce Solutions
В предыдущих статьях цикла мы обсуждали как избегать частых ошибок при организации обмена между интернет-магазином и учетной системой на базе «1С». Теперь коснемся правил организации обмена данными в автоматическом режиме или, как его еще называют, регламента обмена данными.
Другие статьи цикла
Обмен туда и обратно
Если не вдаваться в особенности всяческих индивидуальных проектов, между интернет магазином и «1С» существует два вида обмена: передача данных о товарах остатках и ценах из «1С» на сайт и передача заказов из интернет-магазина в «1С». У последнего есть и обратная связь: «1С» умеет сообщать интернет-магазину об изменении состава заказа и статуса обработки на стороне учетной системы.

Ещё раз, но проще: на сайт мы передаём товары, их цены и остатки на складах. С сайта мы передаём заказы.

На практике сложнее: даже администраторы «1С» зачастую не способны в деталях пояснить тонкости организации процедуры обмена. Тем не менее понимание этого процесса лежит в основе построения системы, работающей автоматически, непрерывно и надёжно.
Интернет-магазин и «1С» в одной картинке. Конечно же, очень упрощённо.
Выгрузка товаров, цен и остатков из «1С» на сайт
Каким бы громоздким и неуклюжим не казался протокол обмена CommerceML (CML), используемый обоими продуктами для взаимодействия, его разрабатывали далеко не глупые люди. В частности, этот формат предусматривает как полную, так и частичную передачу данных. Предположим, вы только что запустили интернет-магазин и теперь необходимо загрузить торговый каталог на базе данных из «1С». В этом случае, передают в интернет-магазин всё и сразу. В дальнейшем, цены на товары будут постепенно изменяться, складские остатки колебаться в зависимости от прихода и продаж, а ассортимент обновляться по мере появления новых предложений поставщиков. Нужны ли в этом случае полные данные о товарах, остатках и ценах из «1С»? Нет, не нужны ни для бизнес-процесса, ни для лишней нагрузки на информационные системы. Достаточно «докинуть недостающие данные».

Обмен данными — это всегда нагрузка на сервер, а если мы хотим добиться непрерывности бизнеса и избавиться от траты лишних ресурсов, нагрузки эти нужно снижать. В этом помогает частичный обмен: после первичной загрузки, из «1С» на сайт передаются только товары, затронутые изменениями. Правильная настройка интервала обмена минимизирует число обновляемых товаров до такой степени, что обмен будет происходить почти мгновенно, хоть и очень часто.

Полный обмен данными об ассортименте, остатках и ценах между «1С» и магазином относится скорее к разряду нештатных ситуаций и тщательно избегается. Когда избежать не получается (поменяли структуру каталога или попросту всё сломалось), полный обмен назначается в автоматическом режиме на наименее загруженные часы в сутках, например на 4:00 утра. Необходимость такой процедуры согласуется с компетентным аналитиком. Иначе рискуете провести обмен «ради обмена».
Рецепт: на стороне учетной системы «1С» ваши разработчики настраивают план обмена, который будет предполагать передачу данных об изменениях торговом каталоге. Интервал такого обмена рекомендуем настроить в диапазоне 5-20 минут. В результате, передаваемые пакеты информации будут минимальными по объему, а их обработка практически не потребует ресурсов со стороны сервера, на котором работает интернет-магазин.

Подводные камни: измерьте нагрузки, возникающие на стороне интернет-магазина в момент таких сеансов обмена. Если сервер не успевает обработать пакет данных до начала следующего сеанса обмена, у вас серьезные неприятности. Необходимо либо увеличить интервал обмена, либо нарастить производительность сервера интернет-магазина. Для крупных компаний проблема актуальна из-за интенсивного товародвижения, приводящего к быстрому изменению остатков и, как следствие, постоянной необходимости передачи эти данных на сайт. В этих случаях вопрос решается при помощи введение в архитектуру обмена промежуточного сервера. В других случаях достаточно провести грамотную настройку интервалов между сеансами и обеспечить достаточную производительность сервера интернет-магазина. Не делайте полный обмен без явной необходимости и оставляйте себе «запас производительности».
Противоречивость данных и конфликты интеграции
Архитектура процедуры обмена должна предусматривать следующее: данные из «1С» никогда не перезаписывают информационные свойства и параметры товаров, отображаемые на сайте. Исключение составляют данные об остатках и ценах, артикул товара, так как в этом случае, «1С» является мастер-системой (первоисточником данных).

Это требование написано кровью. Если по какой-то причине данные, отображаемые на витрине интернет-магазина, отличаются от введенных в «1С», неграмотно настроенная процедура обмена приведёт к постоянному «затиранию» корректных данных и замене их неактуальными. А это требует постоянного ручного контроля. А этого мы хотим меньше всего.
Рецепт: все данные, приходящие из «1С», за исключением цен, остатков и артикула, должны обрабатываться специализированными процедурами-обработчиками. Они проведут необходимые трансформации и разместят информацию в нужном виде, в нужные поля. При такой архитектуре, чтобы ни произошло с обменом, на витрине вашего интернет-магазина всегда будет актуальная информация.
Несвоевременная или неполная передача данных
Заказы в интернет-магазине появляются в случайный момент времени, поэтому в классической архитектуре обмена данными, инициатор сеанса всегда «1С». Эта система не в курсе возникновения новых заказов в интернет-магазине и обращается с запросами только по расписанию. Несколько лет назад в семействе продуктов «1С Битрикс: Управление сайтом» появилась возможность обмена данными о заказах в режиме реального времени. В этой ситуации, инициатором обмена является уже интернет-магазин, что означает мгновенную синхронизацию между системами.

Разберемся в каждой из схем. Оба варианта, даже классическая схема, дадут неплохие результаты. Вы можете сконфигурировать запросы с сайта на предмет появления новых заказов с интервалом, например, в 5 минут — это будет означать практически мгновенную в передачу новых заказов в «1С» для последующей обработки. Это куда проще, чем real-time вариант и функционально они не сильно отличаются. Сделать правильный выбор схемы обмена данными о заказах поможет квалифицированный консультант.
Обмен сеансовый и real-time
Во многих интернет-магазинах, первичная обработка заказов производится на стороне сайта. Кстати сказать, эту логику рекомендуем и мы. Обработка заказа происходит в административной части или в CRM, в результате чего заказы либо переходят в статус подтверждения, либо отменяются. Передаются в «1С» только те заявки, для которых нужны дальнейшие действия по обработке и комплектации. Остальные остаются на уровне сайта или CRM и обрабатываются там до подтверждения или полной отмены. Таким образом снижается нагрузка на оператора «1С», повышается уровень порядка в процессе обработки заказов. Отрицательной стороной такой организации передачи данных о заказах является то, что в этом случае, никогда не хранится полная база заказов, подтверждённых или нет. При применении такой схемы обработки заказов, классическая процедура сеансового загрузки заказов в «1С» работает весьма надежно.

Процедура передачи заказов из интернет-магазина в «1С» в режиме реального времени сложнее в настройке. Она способна обеспечить мгновенные уведомления «1С» о факте поступления нового заказа в интернет-магазин, что в ряде случаев очень критично. Использовать эту схему стоит в тех случаях, когда 5-10 минут для обработки заказа это слишком долго. Это например, товары со доставкой или товары с подтверждением заказа по звонку менеджера. За 10 минут клиент может и передумать.

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

  • Реквизиты покупателя: фамилия, имя, контактный телефон, e-mail;
  • Параметры доставки: адрес, способ, стоимость, время;
  • Состав заказа с указанием цены, примененных к товарам скидок. Важно проконтролировать, чтобы цена товара не изменялось при передаче в «1С».

Если в процессе обработки заказа вы используете нестандартные параметры, их также необходимо включить в процедуру обмена данными. По умолчанию, такие параметры в неё включены не будут.
Рецепт: Настройте сеансовый или real-time режим обмена данными о заказах и проконтролируйте, что все необходимые параметры корректно передаются из интернет-магазина в «1С».

Подводные камни: Убедитесь, что в момент передачи информации о заказах никогда не происходит никаких других процедур обмена данными. Для формирования пакета интернет-магазин использует общую временную директорию и при одновременном запуске нескольких процедур обмена, пакет может быть перезаписан, отчего часть данных будет утеряна.
В следующих статьях этого цикла мы продолжим знакомиться с распространенными ошибками в организации обмена между интернет-магазинами системами учета на базе «1С», а также со способами решения возникающих при этом проблем.

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