Хотелось бы уточнить:
Организации, использующие АСР можно поделить на два вида:
1) Операторы, у которых сначала принято согласовывать всякие телодвижения, связанные с расчетами по услугам с людьми, отвечающими за АСР. Соответственно в таких организациях за подобные косяки отвечает (и расхлебывает) тот, кто этот косяк допустил.
2) Операторы, у которых не принято согласовывать "а мы можем это реализовать в биллинге?" с ответственными за АСР. В таком случае отдуваются всегда биллингисты.

У вас какой случай?

А почему нельзя было просто менять тарифы? У кого переплата - ставить новый тариф будущей рассчитанной датой, у кого нет - датой ввода нового тарифа. В КТВ вроде тарифы не часто меняются, следовательно не так критично менять сумму не только периодом в тарифе. (Мы КТВ только начинаем заниматься, так что могу рассуждать только хиппотетически)

А почему нельзя было просто менять тарифы? У кого переплата - ставить новый тариф будущей рассчитанной датой, у кого нет - датой ввода нового тарифа. В КТВ вроде тарифы не часто меняются, следовательно не так критично менять сумму не только периодом в тарифе. (Мы КТВ только начинаем заниматься, так что могу рассуждать только хиппотетически)

Так это я так понимаю руками предлагаете делать ?... А если их очень много ?

Распишите схему подробнее. Как то, что вам нужно выглядело в старой системе?

Я пока ничего конкретного не предлагаю, потому как не знаю, как у вас это все должно работать. Это был теоретический вопрос к разработчикам, так как они уже делали такую реализацю и у них были какие-то причины не использовать такую очевидную схему со сменой тарифов. Вот эти причины мне и интересны в первую очередь.

Что касается "их очень много" - БГБ позволяет решать большинство задач массовых изменений несколькими способами разной степени автоматизации, поэтому в вашем случае вопрос именно в выборе алгоритма "годится ли эта схема если мы будем менять тарифы раз в год? раз в три месяца? раз в день?"

Да ну там все было очень просто, в ACCESS в соответствующие месяцам колонки проставлялась принятая абонплата, допустим 120р. до конца года уже было проставлено, перепроставлять абонентку не было средств, соответственно это была фича, а не баг

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

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

у вас насколько вперед платили ? до 2100 года ?

может просто дать всем бонус какой-то сразу при переносе ?

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

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

В современых условия конвергентных услуг, оплаты через терминалы и т.д. она не жизнеснеспособна.

Я полностью с вами согласен конечно, но делать что-то придется....