1С и Битрикс24: как организовать обмен заказами и проверить результат

Представим покупателя интернет-магазина одежды. Он заказал две футболки размеров M и L по 1500 рублей и худи за 4000 рублей. Менеджер оформил сделку в Битрикс24, а в 1С появился заказ на 7000 рублей. До отгрузки покупатель попросил заменить футболку размера M на XL, затем внес 3000 рублей.

Теперь нужно проверить, что в прежнем заказе изменился размер только одной футболки, сохранились вторая футболка и худи, а остаток к оплате составляет 4000 рублей. Если обмен создал новый заказ или отметил полную оплату, сотрудники получат неверные данные для сборки и расчетов с покупателем. На этом условном примере разберем, какие правила согласовать с исполнителем и что проверить до запуска.

В 42Clouds мы занимаемся интеграцией 1С с Битрикс24 и интернет-магазинами. В таких проектах нужно согласовать, где сотрудники меняют заказ, какие данные передаются между системами и как обрабатываются сбои. В этой статье сосредоточимся на проверках, которые помогают принять результат работы: от замены размера товара до повторной отправки заказа после потери связи.

Для примера возьмем 1С:УНФ 3.0 и Битрикс24. Названия объектов ниже относятся к этой схеме: сделка в CRM и заказ покупателя в УНФ. Это проект правил обмена, а не обещание, что любой установленный модуль выполняет все описанные действия.

Сначала выясните возможности выбранного решения

Уточните конфигурацию и релиз 1С, версию модуля, облачный или коробочный вариант Битрикс24, тариф и условия использования приложения. Затем проверьте совместимость и состав передаваемых объектов по документации именно этого решения.

Это особенно существенно для товарной части. В официальном обзоре интеграций Битрикс24 у приложения «Синхронизация Сделок и заказов в 1С:Предприятие 8» указано ограничение: товары из сделки не передаются в 1С. Для магазина, который рассчитывает получать готовый заказ со всеми строками, такая разница меняет объем работы. Наличие слова «заказ» в описании приложения еще не определяет состав обмена.

Открытие окна 1С внутри CRM тоже проверяют отдельно от синхронизации. Пользователь может видеть данные 1С, но это не означает, что они сохранены в соответствующих полях Битрикс24 и доступны его отчетам или автоматизации.

Для приемки сузим задачу до одной цепочки: сделка, заказ в УНФ, сведения об оплате и отгрузке в CRM.

Определите, где можно менять каждое поле

Двусторонний обмен требует правил приоритета. Если менеджер исправил телефон в CRM, а сотрудник учета в это время обновил ту же карточку в 1С, система должна понять, какое значение сохранить. Правило «побеждает последняя запись» иногда подходит, но оно должно быть осознанным решением с понятной обработкой конфликтов.

В нашей условной схеме продажи начинаются в Битрикс24. Справочник товаров и факты исполнения ведут в УНФ. Распределение можно зафиксировать так:

После передачи заказа на склад изменение состава требует отдельного маршрута. Иначе менеджер может убрать строку, которую уже отгружают. Договоритесь, до какого состояния заказ меняется автоматически и кто разбирает более поздние исправления.

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

Свяжите объекты по устойчивым идентификаторам

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

У товара с размерами проверяют и сам товар, и конкретную характеристику. Идентификатор общей модели футболки не различит размеры M и L. Для организаций ИНН может помочь первичному сопоставлению, но нужно учесть КПП, обособленные подразделения и структуру справочников. Покупателя-физлицо нельзя всегда надежно определить по номеру телефона: его могут использовать несколько человек.

В справке Битрикс24 о связанных идентификаторах описан механизм привязки объектов 1С к объектам портала. Там же показано, что привязки зависят от адреса портала. Для конкретного модуля стоит выяснить, где смотреть соответствия и что делать при смене адреса или переносе базы.

Сначала разберите спорные карточки, затем запускайте создание новых. Иначе первая синхронизация может закрепить дубли, которые потом будут использоваться в заказах и документах.

Договоритесь, что означает “успешная передача”

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

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

У времени обмена тоже должен быть измеримый смысл. Можно согласовать, например, появление обычного заказа в пределах пяти минут после смены стадии сделки. Это условие конкретного проекта, не заявленная скорость любого коннектора. Если обмен запускается по расписанию, учитывают период запуска и время обработки очереди.

Проверьте повторы и неполные операции

Вернемся к заказу из начала статьи: две футболки разных размеров по 1500 рублей и худи за 4000 рублей, всего 7000 рублей. В тесте отдельно фиксируют валюту, скидки и то, как в этих ценах учитывается НДС. При замене размера цена футболки в нашем примере остается прежней. После оплаты 3000 рублей остаток к оплате должен составлять 4000 рублей.

Самый показательный сбой возникает, когда принимающая система уже сохранила заказ, а отправитель не получил подтверждение. Если он без проверки создаст заказ снова, получится дубль. Механизм повторов должен находить результат предыдущей попытки или использовать другой способ защиты от повторного создания.

Также проверьте отмену и возврат, если они входят в согласованный обмен. Заранее решите, какой объект или статус представляет каждую операцию. Удаление сделки в CRM нельзя автоматически приравнивать к удалению уже проведенного учетного документа.

После сбоя нужна сверка, даже если обмен снова зеленый

В облачном Битрикс24 действуют ограничения REST API. В официальной документации описаны ограничения интенсивности запросов и времени их выполнения. Поэтому для обмена через API нужны обработка ошибок и управляемые повторы. Постоянная немедленная отправка одного и того же запроса может только продлить проблему.

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

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

В выборку включают только объекты, которые по правилам должны участвовать в обмене. Старые сделки, неподходящие стадии и исключенные организации нельзя считать потерями. Но каждый ожидаемый объект без пары требует объяснения. После восстановления связи сверяют и накопившиеся задания, и итоговые данные, а не только время последнего успешного запуска.

Что получить от исполнителя перед запуском

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

Запуск удобнее начать с ограниченной согласованной группы заказов. После проверки расширьте обмен и отдельно проследите за накопленной очередью. При обновлении 1С или модуля повторите критичные сценарии на тестовой среде, прежде чем переносить изменения в рабочую.

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

Реклама: ООО «ЭР Софт», ИНН 7716509296, erid: 2W5zFJvm3qC