Битрикс24 и 1С: какие данные связать и что проверить при приёмке

Заказ на пути от продажи к учёту

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

Повторного набора реквизитов здесь быть не должно. Но у каждого изменения остаётся хозяин: бухгалтер отвечает за подтверждённую оплату, менеджер — за договорённость с клиентом.

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

Начните с заказа, который отдел уже обрабатывает: менеджер готовит состав, передаёт его в 1С и ждёт возвращения сведений об оплате и исполнении в CRM, чтобы продолжить работу с клиентом. Другие документы подключают отдельным этапом. Так руководитель оценит обмен до перестройки справочников и автоматических действий.

Совместимость до оценки работ

Фраза «у нас стоит 1С» слишком широка для оценки интеграции. Исполнителю нужны название конфигурации, её редакция, релиз и сведения о доработках. В справке Битрикс24 указано, что точное название видно в окне «О программе» в 1С. Эти сведения определяют, какой модуль выбирать и кому поручать адаптацию изменённой базы.

Что входит в выбранное решение

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

Релиз имеет значение. Официальная справка об интеграции предлагает проверять версию установленного модуля и доступные обновления через пункт «Битрикс24 → Проверить обновление».

Исполнитель уточняет облачную или коробочную версию CRM, вариант размещения 1С и доступность нужных функций на действующем тарифе, чтобы подтвердить применимость выбранного решения и отделить штатную настройку от дополнительных работ. В инструкции установки модуля автоматический подбор связан с анализом конфигурации; наличие установщика ещё не отвечает на вопросы о доработанных документах и требуемых полях заказа. Ответом станет их проверка на копии базы.

Владелец каждого поля

Двусторонний обмен не означает, что любое поле одинаково свободно меняется с обеих сторон. Когда менеджер исправляет реквизиты в CRM, а бухгалтер уточняет их в 1С, очередная передача способна затереть одну из правок, поэтому перед настройкой полезно записать, кто подтверждает значение и куда оно затем отправляется. Владелец данных — это система, из которой берут окончательное значение выбранного поля.

Контактный телефон для переговоров и реквизиты плательщика выполняют разные задачи, поэтому им необязательно назначать одного владельца.

Матрица для отдела продаж

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

Одно поле — один окончательный источник. Если сотрудникам нужны встречные правки, в задании появляется порядок согласования: кто получает запрос, где подтверждает изменение и что увидит инициатор.

В проекте цветочного гипермаркета ШТАБ ИТ работал над сайтом, Битрикс24 и программами 1С — УНФ и Бухгалтерией. Заказы передавались между сайтом и 1С, а учётная система была связана также с CRM. Приёмку такого набора связей разумнее проводить на одном заказе, потому что отдельные экраны не покажут, сохранились ли его данные при передаче между системами.

Клиент и реквизиты

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

Связь нового и прежнего клиента

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

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

Товар и цена

Товар в сделке должен указывать на определённую позицию учёта. Одного названия недостаточно, когда у изделия есть размеры, цвета или другие характеристики: менеджер выбирает вариант, а склад отгружает именно его. В описании складского обмена коннектора сказано, что товары передаются с характеристиками, а для хранения цен и остатков создаются вариации, в том числе у товара без характеристик.

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

Цена справочника и скидка заказа

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

Остаток и возможность продать товар тоже требуют объяснения. Руководитель согласует, какие склады видит продавец, учитывается ли резерв и когда обновляются сведения. При испытании меняют доступное количество в 1С и наблюдают, когда новое значение появилось в CRM, поскольку статичная цифра на экране не показывает, получит ли менеджер предупреждение до подтверждения следующего заказа клиенту. В акте остаётся измеренный срок для выбранного режима передачи, а не общее обещание работы «в реальном времени».

Связь сделки с заказом

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

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

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

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

Оплата и отмена

Отметка об оплате в CRM и подтверждённое поступление денег в учёте — разные события. В описанном отделе продаж окончательный источник оплаты находится в 1С. В CRM возвращаются сведения, по которым менеджер продолжает работу, а не повторно подтверждает деньги вручную. Какие документы и поля конкретный модуль передаёт для этого процесса, исполнитель устанавливает по выбранной конфигурации и показывает на испытании.

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

Отмена заказа разбирается отдельно от удаления записи. Если в учёте уже были движения, бухгалтер определяет порядок их изменения, а интеграция передаёт соответствующее состояние в CRM. Удалять связанную сделку как способ отмены неудобно: сотрудник потеряет переписку и основание первоначального заказа. Сохранённая связь помогает увидеть, что было отменено, кто это подтвердил и почему сумма больше не участвует в текущем исполнении.

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

Ошибка и повтор

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

Задержку замечает назначенный сотрудник. Менеджер видит, передан ли заказ, а сотрудник поддержки получает сведения, по которым найдёт причину.

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

Соединение после выхода сотрудника

Отдельный вопрос — работа соединения вне сеанса пользователя. В документации для файловой базы соединение Push&Pull связано с текущим сеансом, а для клиент-серверного варианта оно устанавливается в фоне, поэтому руководителю полезно получить от специалиста объяснение: что произойдёт после выхода сотрудника и как продолжится обмен. Следить за такими остановками помогает контроль интеграций CRM, включённый в обслуживание.

Схема обмена в ежедневной работе

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

Компания сохраняет порядок сопровождения. Вместе с ним передают матрицу владельцев полей, схему направлений обмена, сведения о версиях и доступах, а также порядок обращения при ошибке.

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

Рабочая интеграция даёт менеджеру связь заказа с учётом, бухгалтеру — подтверждённые исходные данные, руководителю — понятный порядок изменений и исправлений. За это и принимают первый этап. На странице внедрения и разработки Битрикс24 можно обсудить такой обмен с ШТАБ ИТ: начать с текущего пути заказа и определить, какие ручные действия он заменит.