При настройке интеграции интернет-магазина на платформе 1С-Битрикс и учетной системы 1С:Управление торговлей (УТ 11) одной из первых встает задача корректного учета розничных клиентов. Если для каждого розничного покупателя (B2C), сделавшего всего один заказ, создавать отдельную карточку в справочнике Контрагенты, база данных очень быстро раздуется до огромных размеров. Это усложнит поиск, увеличит объем базы и замедлит работу системы.
В этой статье мы подробно разберем, как правильно организовать учет розничных покупателей, куда записывать их персональные данные (ФИО, телефон, адрес доставки) в документе Заказ клиента и как решить частую проблему двусторонней интеграции — затирание отгрузок и оплат на стороне сайта.
Рассмотрим стандартную схему, которая заложена разработчиками 1С и Битрикс по умолчанию. Для всех розничных заказов с сайта в системе 1С:УТ 11 используется один предопределенный контрагент — например, «Розничный покупатель» (или «Физическое лицо»). Это позволяет держать справочник контрагентов в чистоте.
Возникает логичный вопрос: куда в таком случае записывать индивидуальные данные покупателя, чтобы менеджеры по продажам и служба доставки видели, кому и куда отправлять товар? Разберем по шагам, как распределяются эти данные в документе Заказ клиента:
Контактное лицо на главной вкладке заказа клиента. Это поле хранит текстовую информацию о конкретном человеке, совершившем данную покупку, не привязывая его к глобальному справочнику контрагентов как отдельное юрлицо.Адрес доставки, который находится на вкладке «Доставка» документа Заказ клиента. В зависимости от настроек это может быть как произвольная строка, так и структурированный адрес из контактной информации.Комментарий или записываются в Дополнительные сведения (свойства) документа.Таким образом, дорабатывать конфигурацию 1С и изменять структуру документа Заказ клиента не требуется. Все необходимые поля уже предусмотрены в типовом решении.
Выясним причину, почему данные могут не попадать в нужные реквизиты, и настроим их передачу. На стороне интернет-магазина 1С-Битрикс в административной панели необходимо правильно настроить Профили обмена. Проанализируем этот процесс:
Магазин -> Настройки -> Интеграция с 1С.Профили обмена. Настройки задаются отдельно для каждого типа плательщика (например, «Физическое лицо»).ФИО привязываем к полю XML Наименование или Полное наименование.
- Свойство Телефон привязываем к соответствующему полю XML-контактов.
- Свойство Адрес доставки связываем с реквизитом адреса в XML-пакете.При такой настройке Битрикс выгрузит данные в XML-файл в правильных тегах, а типовой модуль обмена в 1С:УТ 11 автоматически распределит их по реквизитам Контактное лицо и Адрес доставки внутри созданного документа.
Иногда бизнес-логика требует вести персональный учет каждого покупателя — например, для реализации накопительной системы скидок, отправки персональных триггерных писем или детального анализа повторных продаж. В таком случае нам придется создавать карточку клиента под каждого покупателя.
Чтобы избежать появления дублей (когда один и тот же человек оформляет заказы под именами «Иван», «Иван Иванов» и «И. И. Иванов»), настроим в модуле обмена 1С идентификацию контрагентов по уникальным полям:
E-mail или Телефону.При двустороннем обмене пользователи часто сталкиваются с критической проблемой: при изменении заказа в 1С (например, менеджер скорректировал количество или добавил товар) и последующей выгрузке обратно на сайт в Битриксе полностью «слетают» (удаляются) статусы оплат и отгрузок.
Проанализируем ситуацию и выясним техническую причину. Когда документ в 1С проводится, он регистрируется к обмену. Если в 1С еще физически не созданы подчиненные документы (такие как Реализация товаров и услуг или Эквайринговая операция), 1С отправляет на сайт XML-пакет заказа без информации об оплате и отгрузке. Система Битрикс, получая XML без этих блоков, считает, что в «мастер-системе» оплаты и отгрузки были удалены, и автоматически стирает их у себя.
Посмотрим на варианты решения этой проблемы:
Вариант 1. Административная настройка бизнес-процесса
Мы можем ограничить выгрузку документов обратно на сайт. Для этого в настройках обмена в 1С устанавливается фильтрация по статусам. Например, заказы в конечных статусах (Оплачен, К отгрузке, Закрыт) больше не должны выгружаться из 1С на сайт, чтобы менеджеры своими действиями не затирали актуальные данные интернет-магазина.
Вариант 2. Программный запрет удаления документов на стороне Битрикса
Для предотвращения удаления оплат и отгрузок при импорте из 1С разработчики используют кастомизацию через обработчики событий. Чтобы изменения не стерлись при очередном обновлении платформы Битрикс, напишем специальный код в файле /local/php_interface/init.php.
Разберем пример кода, который перехватывает событие удаления оплаты и блокирует его, если запрос инициирован со стороны модуля обмена с 1С:
// Файл /local/php_interface/init.php
use Bitrix\Main\EventManager;
EventManager::getInstance()->addEventHandler(
'sale',
'OnBeforeSalePaymentEntityDeleted',
'preventPaymentDeletionOn1CImport'
);
function preventPaymentDeletionOn1CImport(\Bitrix\Main\Event $event) {
// Проверяем, запущен ли в данный момент процесс импорта из 1С
if (defined('W_S_IMPORT_1C') && W_S_IMPORT_1C === true) {
// Возвращаем ошибку, запрещая удаление оплаты на сайте
return new \Bitrix\Main\EventResult(
\Bitrix\Main\EventResult::ERROR,
null,
'sale'
);
}
}
Аналогичный обработчик можно настроить и для предотвращения удаления отгрузок (документов доставки), используя событие OnBeforeSaleShipmentEntityDeleted. Это гарантирует, что менеджеры в 1С могут свободно редактировать состав заказа, не опасаясь нарушить финансовую историю и сорвать онлайн-оплату покупателю на сайте.