Сами озадачились подобной проблемой месяц назад. В итоге пришли к такому решению (через отрицательные расходы):
План организации пересчетов такой:
(Пусть
X – сумма пересчета, которую нужно вычесть из счетов в будущем
Y – наработка по услугам клиента за месяц)
1. Со стороны биллинга:
a. Менеджеры вносят отрицательный расход типа «пересчет», равный -X в тот месяц, начиная с которого нам нужно сделать пересчет клиенту. У клиента сразу возрастает баланс.
b. Клиент работает в течение месяца, к концу месяца его наработка составляет Y
c. Перед выставлением счетов после переобсчета за месяц запускаем скрипт, который проходит по всем договорам, имеющим расходы типа «пересчет» в прошлом месяце. Скрипт сравнивает наработку Y каждого договора с суммой пересчета X (считается, как минус сумма всех расходов типа «пересчет» за месяц). Если X>Y, то скрипт вносит за предыдущий месяц расход, равный (X-Y), чтобы уравнять сумму таких расходов и наработку и нулевой счет не выставлялся.
Одновременно скрипт вносит расход -(X-Y) в текущий месяц, перенеся таким образом остаток суммы пересчета с предыдущего месяца.
d. В счетах прописываем позицию, равную сумме всех расходов типа «пересчет» за месяц. Это отрицательная позиция – она будет урезать сумму счета.
e. Можно сделать дополнительное действие договора, переносящее бонус на следующий месяц для конкретного договора.
f. Набор отчетов для мониторинга таких «бонусов»
Проблемы/нюансы:
- пересчет работает только для предыдущего месяца. Если мы меняем наработку в других месяцах, то нужно будет руками править расходы и баланс
- аналогично, если мы уже перенесли остаток суммы пересчета на следующий месяц, потом наработка за прошлый месяц увеличилась, то переносить остаток суммы пересчета обратно нужно будет руками, затем снова запускать скрипт для этого договора.
- неудобный интерфейс запуска глобального скрипта (через «Глобальные скрипты поведения»), сложно отследить, кто это делал, логи выполнения придётся слать на email, настраивать права и прочее. Кроме того, как оказалось, глобальные скрипты может создавать и запускать вообще кто угодно
2. Со стороны 1С:
В 1С приходит счет с отрицательной позицией. На стыке между биллингом и 1С требуется преобразовывать эту позицию либо в процентную скидку ко всему счету, либо размазывать её по другим позициям. В первом случае необходима юридическая база в виде маркетинговой политики, а во втором – набор правил (из каких позиций мы можем вычитать и т.п.). Кроме того, во втором случае у клиентов будут вопросы, когда они увидят необычные суммы наработки по услугам.
Пока это всё на стадии реализации.
Обращаю внимание, что, в отличие от вашего варианта, перерасчет сразу увеличивает баланс клиента. Но на стыке месяцев баланс выравнивается для нормальной сверки с 1С.
Рассматривался также вариант создания внешней относительно биллинга тулзы, которая отдельно хранила бы суммы пересчетов и урезала наработку путём отрицательных позиций наработки RSCM. Но тогда к этой тулзе придётся делать обвеску в виде прав доступа, логирования и т.п.
Кстати, основной вопрос тут - как вы собираетесь указывать перерасчет в счете клиенту?