skn писал(а):
попробуйте составить ПОЛНОЕ тех. задание на так называемые "абоненки с 15 по 15 число"
Не знаю, как насчет ТЗ, но общую идею, наверное не очень сложную в доработке и, пожалуй, достаточно для всех подходящую, я могу предложить.
Зная, что в inet есть такое понятие как учетный период, можно, по аналогии с
абонентками зависящими от наработки по объёму добавить поддержку модулем npay учетных периодов других модулей, например как-то так:
Код:
module.accounting.period.<id>.mid=<mid>
module.accounting.period.<id>.class=<class_name>
Например
Код:
module.accounting.period.1.mid=1
module.accounting.period.1.class=ru.bitel.bgbilling.modules.inet.npay.InetAccountingPeriod
Ну или нечто аналогичное.
Основная мысль в том, что благодаря подобной конструкции у npay в ветке появится "За учетный период модуля "<module.title>"" и абонентка будет учитываться на основе учетного периода модуля указанного в module.accounting.period.mid, а учетный период, если его реализовать скриптом, может быть произвольной величины.
Само собой разумеется, что для того чтобы это работало учетный период обязан быть проставлен.
Так же подразумевается, что module.accounting.period.mid == module.amount.mid и было бы неплохо, если бы можно было делать как-то так:
Код:
module.accounting.period.1.mid=1
module.accounting.period.1.class=ru.bitel.bgbilling.modules.inet.npay.InetAccountingPeriod
module.amount.1.title=Входящий трафик
module.amount.1.mid=1
module.amount.1.class=ru.bitel.bgbilling.modules.inet.npay.InetModuleAmount
module.amount.1.sids=2
Собственно если сделать нечто подобное, то подобная конструкция, наверное, может кому-то полностью заменить ежемесячные или даже ежегодные абонентки
stark писал(а):
калькулятор и задача закрытия статусов доходят только до первого узла и получают 0
вы же хотите, чтобы задача закрытия статуса шла пока не найдет цену
npay так устроен, что для определения цены в зависимости от объема у него должно быть больше одного узла (1-й узел - "от 0 до Х", 2-й узел - "от Х до бесконечности"), поэтому я считаю, что калькулятор обязан брать цену не из первого узла, а из последнего, т.к. там всегда последняя, финальная цена. Разумеется речь идет только про узлы с зависимостью от наработки.
stark писал(а):
по итогам обсуждения Амир предложил сделать отдельный узел чтобы при задача блокировки работала по другому.. Т.е по факту вам там нужно как бы 2 тарифа - один для начисления, второй для блокировки. Второй тариф как бы с одном узлом цена и все, а для начисления 2 узла
Но ведь это натуральный костыль с нагромождением излишних сущностей.
Впрочем, если это самый простой выход из сложившейся ситуации, то почему бы и нет? Соответственно возникает вопрос: когда ждать?