Битрикс24 и 1С: как связать заказ, оплату и отгрузку без потери статусов
Разбираем обмен заказами между Битрикс24 и 1С: владельцы данных, частичная оплата, отгрузки, повторы и проверка перед запуском.
Содержание статьи 7
Менеджер видит в Битрикс24 успешную сделку, бухгалтер в 1С ждёт доплату, а склад уже отгрузил часть заказа. Все трое могут быть правы: они смотрят на разные события. Интеграция начинает помогать, когда эти события связаны устойчивыми идентификаторами и понятными правилами переходов.
Я бы начинал проект обмена с одного заказа и его истории. Кто создал состав, где зафиксирована оплата, откуда берётся факт отгрузки? Такой разбор показывает, что именно нужно передавать между системами и какие действия должны оставаться за человеком.
Аванс и частичная отгрузка меняют разные показатели. Ни один не означает полное завершение заказа.
Сделка, заказ, платёж и отгрузка отвечают на разные вопросы
Сделка описывает работу с клиентом. Заказ фиксирует состав и условия поставки. Платёж подтверждает поступление денег, а отгрузка отражает движение товара. Названия объектов и доступные операции зависят от используемой конфигурации 1С и выбранного сценария Битрикс24.
Поэтому фразу «передавать все статусы» лучше заменить таблицей событий. Например, изменение коммерческого предложения ещё не должно менять проведённую реализацию. Отметка менеджера о согласии клиента тоже не равна банковской оплате. Эти различия нужно сохранить в интерфейсе, иначе красивый общий статус будет скрывать реальную задолженность.
В официальной инструкции по синхронизации заказов отдельно рассматриваются соответствия статусов отгрузок и платёжных систем. Наличие таких настроек не означает, что любой проект запускается одинаково: сначала сверяют версии, состав документов и поддерживаемое направление обмена.
Назначьте владельца каждого поля
Удобно выбрать систему, которая считается источником конкретного значения. Это не обязательно одна система для всего заказа. Клиентские договорённости могут появляться в CRM, остаток товара приходит из учётной системы, а подтверждённое поступление денег оформляет бухгалтерия.
| Данные | Возможный источник | Что возвращается второй стороне |
|---|---|---|
| Состав согласованного заказа | CRM до передачи в учёт | Идентификатор созданного документа |
| Контрагент и договор | Согласованный справочник 1С | Код найденной записи или задача на уточнение |
| Факт оплаты | Учётная система | Сумма, дата и связь с заказом |
| Отгрузка | Складской документ | Состав отгруженного и остаток к поставке |
Это пример распределения ответственности. В конкретной компании источники могут отличаться. Важно, чтобы два сотрудника не могли независимо переписать одно значение, а обмен затем выбирал победителя случайно.
Пример: заказ на 120 тысяч рублей
Представим поставку из десяти одинаковых позиций общей стоимостью 120 тысяч рублей. Клиент внёс 60 тысяч, склад отгрузил четыре позиции. В CRM полезно показывать как минимум три отдельных результата: заказ согласован, оплачено 50%, отгружено четыре из десяти. Стадия сделки сама по себе этих сведений не заменяет.
Если интеграция отправляет только итоговую сумму заказа, менеджер не узнает о частичной поставке. Если отправляет только признак «есть оплата», он может принять аванс за полный расчёт. Поэтому ещё до разработки согласуют, какие суммы и строки нужны человеку для следующего решения.
Повторное сообщение о том же платеже не должно увеличивать оплату до 120 тысяч. Для этого сохраняют идентификатор платежа и признак обработанного события. При исправлении документа передают его актуальную редакцию по тому же ключу, а не создают ещё один платёж.
Как не размножить контрагентов и документы
Телефон и название компании полезны для поиска, но плохо подходят на роль единственного ключа. Названия меняются, телефон бывает общим, а одна группа компаний использует несколько юридических лиц. Связь записей лучше хранить явно: идентификатор CRM, идентификатор 1С и правила их первоначального сопоставления.
Неопределённое совпадение отправляйте ответственному сотруднику. Например, у клиента найдено два договора, а в CRM договор не указан. Безопаснее поставить заказ в очередь уточнения, чем автоматически выбрать первый договор и создать документы с неверными условиями.
Журнал должен объяснять результат обычными словами: заказ принят, соответствие не найдено, документ обновлён, повтор пропущен. Техническая ошибка остаётся доступной специалисту, но менеджеру нужен ответ, может ли он продолжать работу и кому передать вопрос.
Проверьте исключения до реальных оплат
Для тестового прогона подготовьте обезличенные данные и заранее ожидаемый результат. Одного успешного заказа недостаточно. Проверка должна воспроизводить ситуации, которые вызывают ручную работу:
- Повтор одного сообщения после обрыва соединения.
- Частичная оплата и две последовательные отгрузки.
- Изменение количества после передачи заказа.
- Отмена документа, который уже был получен второй системой.
- Неизвестный товар или договор.
- Недоступность 1С и последующее восстановление связи.
По каждому случаю смотрят обе системы и журнал обмена. Число документов, суммы и строки должны совпадать с ожидаемыми. Отдельно проверяют, что повторная обработка не отправляет клиенту лишнее письмо и не запускает повторную задачу складу.
Что подготовить для обсуждения интеграции
Соберите по одному обезличенному примеру заказа, оплаты и отгрузки. Запишите версии систем, существующие подключения, владельцев справочников и пять самых частых исключений. Полезно показать нынешний ручной путь: где сотрудники переписывают данные и как узнают об ошибке.
С такой заготовкой можно обратиться в Aventra, чтобы разобрать подходящий механизм обмена и объём доработки. Сначала стоит согласовать один проверяемый процесс, затем переносить на него остальные заказы. Срок и состав работ определяются после проверки ваших конфигураций и документов.
Частые вопросы
Можно ли передавать только заказы, без остальных данных?
Да, если этого достаточно для рабочего процесса и поддерживается выбранным подключением. Но понадобится решить, как получатель найдёт товар, контрагента и договор. Отсутствие полного обмена справочниками не отменяет сопоставление используемых записей.
Где лучше менять состав заказа после согласования?
В заранее выбранной системе и по определённому правилу. Например, после передачи в учёт изменение может требовать подтверждения ответственного. Иначе две разные редакции будут перезаписывать друг друга, а склад и менеджер увидят разные условия.
Как понять, что интеграция работает правильно?
Проследить конкретный заказ от создания до оплаты и поставки, проверить суммы, строки и связи документов. Затем повторить отправку и воспроизвести ошибку. Зелёная отметка соединения показывает доступность, но не подтверждает правильность учёта.
Можно ли обойтись стандартным модулем?
Это проверяют на ваших версиях и сценариях. Стандартный обмен стоит испытать первым. Отдельная разработка нужна там, где подтверждённое правило компании не укладывается в его возможности, а не просто потому, что процесс выглядит сложным.