В сделке стоит «Оплачено», а бухгалтерия видит только аванс. Или обратная ситуация: деньги поступили в 1С, но менеджер продолжает напоминать клиенту о долге. Часто причина не в скорости обмена, а в слишком простой модели: несколько документов пытаются заменить одним флажком.
Чтобы передавать оплаты из 1С в Битрикс24, сначала определяют источник финансового факта и связи между объектами. CRM может показывать менеджеру состояние расчётов, но не должна самостоятельно переопределять подтверждённую бухгалтерией оплату при случайном перемещении сделки по стадиям.
Сделка описывает коммерческую работу с клиентом. Счёт определяет, за что и сколько требуется оплатить. Платёж показывает поступившие деньги, но ещё требует распределения по обязательствам. Несколько счетов одной сделки или платёж за несколько заказов нельзя корректно представить связью «одна сделка — одна сумма».
Для обмена согласуют идентификаторы сделки, счёта, контрагента и организации. Номера документов недостаточно: нумерация может повторяться по годам и организациям. Связь должна переживать изменение названия клиента, перевыпуск печатной формы и повторную отправку данных.
В одном проекте источником будет банковская выписка, обработанная в 1С, в другом — иной согласованный учётный контур. Это определяют вместе с финансовой службой. Менеджер может инициировать проверку, но ручное поле CRM не должно без подтверждения менять проведённый документ.
В коннекторе 1С предусмотрена синхронизация смарт-процессов . Возможность связать нужные документы зависит от конфигурации 1С, версии модуля и выбранных правил. Наличие такой подсистемы не означает, что любой платёж уже автоматически связан с вашей сделкой. На обследовании проверяют конкретный состав объектов и направления записи.
Если стандартного обмена достаточно, его используют. Дополнительный обработчик оправдан распределением платежей, нетиповыми документами, несколькими организациями или специальными требованиями к журналу. Выбор делают по данным и ограничениям, а не по желанию заранее написать интеграцию.
Частичная оплата: считаем распределение, а не движение стадии #
Возьмём условный счёт на 120 тысяч рублей. По нему распределены два поступления: 30 и 50 тысяч. CRM должна показать 80 тысяч оплаты и 40 тысяч остатка. Если второй платёж относится ещё к другому счёту, в расчёт попадёт только выделенная этому обязательству часть.
Отдельно решают, как учитывать возврат, зачёт аванса, отмену проведения и исправление распределения. Эти операции меняют результат, даже если новый банковский платёж не появился. Поэтому обмен, реагирующий только на создание поступления, постепенно начнёт расходиться с учётом.
Это иллюстрация модели, а не формат стандартного API. В рабочем обмене денежные значения передают с согласованной точностью; вычисления не строят на двоичных float без контроля округления. Валютные документы сверяют в согласованных валютах и по правилам учётной системы, а не складывают как одинаковые рублёвые суммы.
Если обработчик не получил подтверждение записи в CRM, он может повторить отправку. Повтор должен обновить состояние известной операции, а не прибавить ту же сумму ещё раз. Для этого сохраняют ключ источника, версию данных и результат обработки. Дату последнего запуска обмена нельзя использовать вместо идентификатора платежа.
Нужна также защита от запоздавшего сообщения: старое состояние не должно затереть более новое распределение. В зависимости от источника применяют версию объекта, последовательность обработки либо повторное чтение актуального состояния. Договорённость об этом фиксируют до запуска, особенно если обмен работает сразу в двух направлениях.
Проблемные записи должны попадать в отдельный список: не найден счёт, несколько совпадений, другая валюта, недостаточно прав. Подставлять первую подходящую сделку опаснее, чем остановить конкретную операцию для разбора. В отчёте менеджеру показывают, что сведения не подтверждены, а не выдают последнее известное состояние за актуальное.
Сверка, которая обнаруживает реальные расхождения #
Сначала сравнивают суммы по документам и организациям, затем разбирают несоответствия по ключам. Один общий итог за месяц может совпасть случайно: лишняя оплата одной сделки компенсируется недостающей оплатой другой.
— Один счёт оплачен двумя частями: остаток пересчитан после каждого распределения.
— Один платёж распределён между счетами: общая сумма не размножилась.
— Проведение отменено: CRM получила исправленное состояние.
— Выполнен возврат: видны исходная операция и новое состояние расчётов.
— Отправка повторилась после сбоя: сумма не увеличилась второй раз.
— Обмен задержался: сотрудник видит время актуальности и причину ошибки.
Можно автоматически закрывать сделку после оплаты? #
Можно, если это соответствует процессу. Для услуг с последующим выполнением оплата не означает завершение работ. Лучше различать финансовое состояние и коммерческий результат, чем закрывать всю работу одним событием банка.
Сохранить её в очереди сопоставления и назначить ответственного за разбор. Нельзя терять поступление или привязывать его по одному только похожему названию компании. После выбора связи операция должна быть обработана повторно без дублей.
NetLab поможет спроектировать интеграцию Битрикс24 с 1С и системами учёта : определить состав документов, правила распределения и контроль расхождений. Обсудить обмен оплатами — приложите описание конфигурации и обезличенный пример сложного платежа, без банковских доступов и данных клиентов.
