Частичная оплата сделки в Битрикс24: фиксация платежей и отчетность

Достаточно давно слежу за веткой на форуме, где обсуждается реализация частичной оплаты сделки. Судя по количеству вопросов по этой теме, функционал востребованный и на данный момент хорошего решения этой задачи в Битрикс24 нет.

На днях я ещё раз столкнулась с вопросом, как фиксировать данные по этапам оплаты сделки и на основе этих данных формировать отчетность.

По ссылке "Подробнее" итоги моего исследования :-)


Информация, которую нужно зафиксировать по каждому этапу:

• "Оплачен (n-й этап)" - Да/Нет
• "Ожидаемая/полученная сумма (n-й этап)" - число
• "Ожидаемая/фактическая дата оплаты (n-й этап)" - дата

Самые распространенные требования по отчетам:

• Узнать, какая сумма получена компанией за период: по клиентам / по филиалам.
• Узнать, оплата какой суммы просрочена на текущий момент, и общий остаток по платежам: по клиентам / по филиалам.
• Узнать, оплата какой суммы ожидается к заданному числу: по клиентам / по филиалам.

3 способа, как зафиксировать данные:

• Одна сделка плюс несколько счетов на оплату. Количество счетов - количество этапов оплаты. 
• Несколько сделок. Количество сделок - количество этапов оплаты.
• Набор пользовательских полей в сделке. Количество наборов полей - количество этапов оплаты.

У всех трех способов есть и плюсы и минусы. Идеального решения пока я не нашла.

--------------------------------------------------------------

Одна сделка - несколько счетов на оплату. Количество счетов - количество этапов оплаты

Как фиксировать информацию по платежам:

• "Оплачен (n-й этап)" - статусы счета: "Ожидает оплату", "Оплачен", "Отклонен"
• "Ожидаемая/полученная сумма (n-й этап)" - сумма счета
• "Ожидаемая/фактическая дата оплаты (n-й этап)" - поле "Срок оплаты" для ожидаемой даты оплаты и поле "Дата оплаты" для фактической даты оплаты (заполняется автоматом при закрытии счета).

Как строить отчеты:

• Узнать, какая сумма получена компанией за период: по клиентам / по филиалам: суммы счетов в статусе "Оплачен", у которых "Дата оплаты" больше или равна заданному значению и меньше или равна заданному значению, сгруппированные по клиентам или филиалам.
• Узнать, оплата какой суммы просрочена на текущий момент, заданную дату или общий остаток по платежам: по клиентам / по филиалам: суммы счетов в статусе "Ожидает оплату", у которых "Срок оплаты" меньше сегодняшней даты, указанной даты или без ограничения по дате, сгруппированные по клиентам или филиалам.

Плюсы:

• Нет ограничений по количеству этапов оплаты. По одной сделке оплата может быть разделена на 2 этапа (= 2 счета), по другой - на 5 этапов (= 5 счетов).
• С помощью отчетов CRM можно получить необходимые данные по оплатам и задолженностям.

Минусы:

• Необходимость использовать товары, так как счет нельзя создать без товаров. При этом не у всех компаний использование товаров в работе является логичным.
• Необходимость использовать счета. Так же, не всем компаниям подходит функционал счетов CRM. В этом случае создание и ведение счетов - это достаточно большой и неоправданный объем работы для менеджеров.

Кому подойдет такой вариант:

• Компаниям, которые и так используют товары и счета. Для менеджеров в данном случае никакой дополнительной нагрузки не добавляется.
• Компаниям, которые не планировали использовать товары И/ИЛИ счета, но могут перейти на такую логику работы, так как сделки у них - это большие продолжительные проекты, которых в CRM немного, соответственно, заполнение данных по счетам и товарам не создадут большой нагрузки на менеджеров.

--------------------------------------------------------------

Несколько сделок. Количество сделок - количество этапов оплаты

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

Плюсы:

• Плюсы предыдущего способа
• Нет строгой необходимости использовать товары и счета CRM.

Минусы:

• Необходимость создавать несколько копий сделок - дополнительный объем работы для менеджеров и дополнительная сложность при настройке бизнес-процессов.

Кому подойдет такой вариант:

• Компаниям, у которых каждый этап оплаты соответствует самостоятельному этапу работы над проектом, у которого может быть другой ответственный, другая последовательность обработки и т.д. Только в этом случае создание нескольких однотипных сделок на один проект не увеличит нагрузку на менеджеров.

--------------------------------------------------------------

Набор пользовательских полей в сделке. Количество наборов полей - количество этапов оплаты

Как фиксировать информацию по платежам:

• В пользовательских полях сделки: "Оплачен (1-й этап)" - Да/Нет, "Ожидаемая/полученная сумма (1-й этап)" - число, "Ожидаемая/фактическая дата оплаты (2-й этап)" - дата, то же самое для 2-го и т.д. этапов.

Как строить отчеты:

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

Плюсы:

• Все данные заполняются в сделке, нет строгой необходимости использовать товары и счета CRM.

Минусы:

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

Кому подойдет такой вариант:

• Компаниям, которые категорически не хотят или не могут работать с товарами и счетами CRM. Например, в случае, если сделки - это небольшие и непродолжительные по времени проекты, которых в CRM достаточно много. 
• Компаниям, которым достаточно выгружать данные по всем сделкам, например, в Excel, и формирование сводных отчетов сделать на стороне Excel.
• Компаниям, которым подходит вариант разработки отчетов на заказ.

Вот такое получилось исследование этого вопроса :-)

У меня есть подозрение, что может быть я зациклилась на этих трех вариантах и не вижу какого-то простого и очевидного решения. Поэтому буду рада, если кто-то поделится своим вариантам решения аналогичной задачи :-)