BiTel

Есть общепринятая форма работы с "простоями по вине оператора". В качестве единицы измерения выступает час, а цена этого часа есть 1/720 часть от СУММЫ платежей.

Фактически что бы посчитать компенсацию, надо взять сумму тарифов по всем абон платам (ну или перечню), поделить ее на 720 и умножить на кол-во часов простоя.
Я собирался реализовать это через единоразовые платежи с отрицательным тарифом, при этом данный единоразовый тариф задавать в тарифном плане где определяется абонка, все замечательно, но что если на договоре несколько абон пллат, скажем есть абон плата за интернет подключение, абонка за VOIP, и штук, скажем, 16 абонок за выделение гарантированной полосы пропускания (CIR 8kbit).

Сразу оговорюсь что реализовывать простои приостановкой договора статусом неправильно, так это приведет к уменьшению пропорциональных пределов. Ну например, на этом договоре есть тариф за трафик с неоплачевым порогом в 100 гиг пропорционально периоду. Если простой был по вине оператора, скажем 10 дней из 30, то в случае общего объема трафика в 80 гиг клиенту выставится доплата за трафик сверх лимита, а это неправильно. Более того, блокировка статусум уменьшит сумму списываемых абон план в том месяце когда были простои, и как следствие в актах будут суммы меньше, а это опять же не правильно, так как простои должны выставляться в следующем месяце, а в том месяце когда были простои клиент обязан оплатить все платежи в полном объеме.

Вообщем хотелось бы услышать какие мысли на тему как это можно реализовать и сталкивается ли с такой практикой еще, кроме меня

По сабжу:
viewtopic.php?f=19&t=1230

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

ps.


Эмм, а разве "пропорционально периоду" для пакета трафика зависит от статуса договора? Насколько я помню, там влияет только период действия абонплаты. Ну, в 5-ой версии вроде добавили "пропорционально периоду тарифного плана".

ну по логике статус "приостановлен" должен обрезать период действия договора, следовательно уменьшаются пропорционально пропорциональные тарифы абон плат и пропорциональные диапазоны IPN и тп

а на счет того топика, у вас там по сути разговор про бонусы на дебете, деньги которые расходуются на абстрактные услуги
в моем же случае "пеня" это отрицательная RSCM услуга, у которой тариф равен сумме тарифов включенных абон плат с указанными SID, в часном случае всех активных абон плат

но есть и одно "но": допустим простой был 25-го января, а на договоре есть одна абон плата активная весь месяц, а другая скажем только до 15-го января...

может какие то другие варианты решения есть, не через RSCM...

У нас этот вопрос ставится более широко: нужно производить любые пересчеты за предыдущие месяцы путём урезания счета клиенту в текущем месяце. Речь о случаях, когда по ошибке мы слишком много взяли с клиента, либо пошли ему на встречу и списываем определенную сумму.
Тут два момента:
1) Как посчитать сумму, которую клиенту нужно простить, не меняя тарифные планы и пр. в закрытом периоде?
2) Как внести эту сумму и размазать её по месяцам, если она окажется больше наработки за месяц?

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

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