Частичная оплата в CRM: как контролировать аванс и остаток

Частичная оплата в CRM - это учёт нескольких поступлений по одному обязательству клиента с отдельным контролем остатка. Сигнал о первом платеже подтверждает только этот платёж. Он не доказывает, что клиент рассчитался полностью, работа выполнена и сделку можно закрывать.

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

Сначала разделите три состояния сделки

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

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

Опишите правило словами до настройки автоматизации: «После подтверждённого аванса разрешаем запуск работы; следующий платёж контролирует назначенный сотрудник; окончание продажи не снимает его задачу». Если этапы уже смешивают оплату и исполнение, сначала пересмотрите правила ведения воронки.

Выберите источник подтверждённых поступлений

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

Успешный статус платёжного сервиса тоже имеет конкретный смысл. Например, ЮKassa различает ожидание списания и успешно завершённый платёж. Поэтому формулировка «появился платёж» недостаточна для технического задания: нужно назвать состояние, которое интеграция признаёт подтверждением. Не переносите названия статусов одного сервиса на другой без проверки.

Зафиксируйте, какие сведения приходят в CRM:

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

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

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

Определите остаток и не прячьте исключения

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

Условный учебный пример: согласованная сумма заказа составляет 100 единиц, первый платёж - 30, второй - 50. После первого поступления остаток равен 70, после второго - 20. Статус «Первый платёж получен» верен, а «Полностью оплачено» после любого из этих двух событий - нет. Предполагается одна валюта, без возвратов и пересмотра заказа.

Отдельно задайте поведение для сложных случаев:

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

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

Назначьте следующий платёж и ответственного

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

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

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

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

Выберите способ реализации по контрольным сценариям

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

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

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

Примите настройку на ошибках, а не на одном успешном платеже

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

1. Первый частичный платёж уменьшает остаток, но не снимает контроль следующей части.
2. Второй платёж дополняет первый, а не заменяет его сумму в карточке.
3. Повторная доставка той же операции не увеличивает полученную сумму второй раз.
4. Платёж с неподтверждённым состоянием не запускает действие, требующее подтверждения.
5. Несопоставленное поступление попадает в очередь разбора и имеет ответственного.
6. Полный расчёт закрывает контроль оплаты, сохраняя историю поступлений.
7. Возврат или изменение заказа запускает предусмотренную проверку, а не скрывает расхождение.
8. После перерыва связи сверка восстанавливает факты без повторного учёта уже обработанных операций.

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

Частые вопросы

Нужно ли держать сделку открытой до последнего платежа?

Это зависит от определения завершённой продажи в компании. Можно закрывать продажу раньше, если остаток, срок и ответственность продолжают контролироваться в связанном процессе. Недопустима потеря контроля из-за того, что карточка исчезла из рабочей воронки.

Можно ли обойтись одним полем с общей суммой оплат?

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

Что делать, если в CRM сумма отличается от учётной системы?

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

Источники

• ЮKassa: процесс платежа и входящие уведомления.
• Поддержка24: частые вопросы о центре продаж.