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