Cosbi

Как связать сделку CRM с оплатой и отгрузкой в 1С

Идентификаторы, распределение частичных оплат, возвраты и контрольные суммы: методика сопоставления CRM и 1С для аналитики.

Команда CosbiОпубликовано Обновлено 6 мин чтения

Методический материал. Все числовые примеры вымышлены и приведены для обучения; они не описывают результаты клиентов Cosbi.

Опишите цепочку, а не только обмен

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

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

Выберите устойчивые ключи

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

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

Учебная цепочка с частичными событиями

Рассмотрим вымышленную сделку на 1 200 000 рублей. В 1С ей соответствует один заказ, две реализации на 700 000 и 500 000, а также два платежа на 400 000 и 600 000. При условии, что обе оплаты распределены на этот заказ и дополнительных корректировок нет, отгружено 1 200 000, оплачено 1 000 000, разница составляет 200 000 рублей. Она ещё не обязательно просрочена: нужно сверить срок оплаты по договорённости.

До второй отгрузки картина была другой: отгружено 700 000, оплачено 1 000 000, поэтому 300 000 относятся к предоплате будущей поставки. Если свернуть весь месяц, это различие исчезнет. В отчёте на дату показывайте события, наступившие к этой дате. Платёж, распределённый по двум заказам, делится по подтверждённым суммам; всю оплату нельзя повторить в каждой сделке. Для примера мы используем одну валюту и единую налоговую базу, чтобы арифметика была прозрачной.

Как работать, если прямого ключа нет

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

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

Предотвратите размножение сумм

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

Учитывайте возвраты, отмены и перепроведение документов. Возврат может уменьшить отгрузку, но денежное возмещение появится позднее. Аванс не всегда имеет связь с реализацией, зато может быть отнесён к договору или заказу. Закрытие долга взаимозачётом отличается от банковского поступления. Если отчёт обещает «оплату», уточните, включает ли он такие операции. Для валютных документов согласуйте курс и дату пересчёта. Неполная история изменений требует маркировки ограничения, особенно если вы анализируете состояние на прошлую дату.

Что сравнивать после сопоставления

Полезные срезы — сумма успешных сделок, сумма связанных заказов, сумма реализаций и распределённая оплата. Между ними не требуется постоянное равенство: разрыв объясняют временем и процессом. Сделка закрыта, заказ не найден — вопрос к дисциплине обмена. Заказ есть, реализации нет — вопрос к исполнению поставки. Отгружено, оплата не наступила — вопрос к срокам и дебиторской задолженности. Не объединяйте эти ситуации под одним красным статусом.

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

Как принять первую финансовую цепочку

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

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

Источники и границы методики

Битрикс24 REST: сделки CRM

Исходные CRM-сущности и их связи; статья не утверждает наличие универсального ключа сделки в 1С.

Bitrix24 REST: Linking Orders to CRM Entities

Модель связи заказа интернет-магазина с CRM. Не тождественна всем заказам 1С.

Разобрать задачу в Cosbi

Сквозная аналитика CRM и 1С

Коннектор Битрикс24

Коннектор 1С:УТ

Сопоставление клиентов

Обсудить источники для пилота

Разобрать задачу на ваших данных

Состав пилота, определения показателей и доступность источников согласуем с вашей командой.

Обсудить источники для пилота