Частичная оплата сделки в Битрикс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.
- Компаниям, которым подходит вариант разработки отчетов на заказ.
Вот такое получилось исследование этого вопроса :-)
У меня есть подозрение, что может быть я зациклилась на этих трех вариантах и не вижу какого-то простого и очевидного решения. Поэтому буду рада, если кто-то поделится своим вариантам решения аналогичной задачи :-)
Поделитесь ссылкой на "ветку на форуме"? Очень мало ресурсов где обсуждают Б24..
ОтветитьУдалитьК сожалению, не могу. Форум по Битрикс24 раньше был доступен по ссылке https://forums.bitrix24.ru/, сейчас эта ссылка ведет на Поддержку24.
Удалить"Набор пользовательских полей в сделке. Количество наборов полей - количество этапов оплаты."
ОтветитьУдалитьДобрый день, делали такое?
Да, настраивала этот вариант как пробный для компании. Насколько я помню, он в итоге не подошел из-за того, что встроенными отчетами не смогли получить нужные данные.
УдалитьПосле того, как появился итератор в бизнес-процессах, пробовала ещё один вариант настройки частичной оплаты. Пример в моей статье https://luba-tinaeva-b24.blogspot.com/2018/04/blog-post.html.
Крутая статья! Спасибо!
ОтветитьУдалитьСтатья по делу, но проблемы она не решает. Как не было нормального инструмента в Битриксе так и нет его с рождения для нормального ведения рассрочки и нормального оперативного учёта. Функционал отчётов примитивный и смешной. Потому приходится лезть в код и писать свои модули. CRM Битрикс это детский сад и заново выдуманный велосипед. Очень сильно жалею что вляпались в покупку ихней ее коробки. Поддержка на запросы страждущих не реагирует и живёт своей жизнью изобретая то что никому почти не нужно.
ОтветитьУдалитьЗнаете CRM системы получше в тот же бюджет?
Удалитья предлагаю четвёртый способ:
ОтветитьУдалить- создавать два типа сделок в битриксе:
- одну сделку без товаров/услуг, с общей положительной суммой сделки, например 100 руб
- вторая сделка с товарами/услугами, но отрицательными ценами, например -1 руб. -9 руб и т.д.
- все частичные оплаты заносим либо как товары во вторую сделку, либо создаём ещё сделки второго типа
Можно попробовать, да.
УдалитьДа, проблема действительно актуальная...
ОтветитьУдалить2021 год на дворе. Столкнулся с такой же проблемой. Думаю подойдёт первый способ. Нужно тестить.
ОтветитьУдалитьСлучайно не появилось какое-то простое решение данной проблемы?
Пока делаю так же, только ещё в одном варианте для фиксации оплат использую список, привязанный к сделке. Так можно выгружать данные за период и смотреть статистику в Excel, например.
УдалитьКак это отражать, напрмиер в условиях договора? Предоплата n%%, что составляет .... руб
ОтветитьУдалитьДобрый день!
УдалитьИмеете в виду документ CRM?