BiTel

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

пробовал по всякому, "округленно", "выровнено".
или на событие активации\деактивации продукта вешать добавление\удаление услуги абонентских плат, поставить нулевую стоимость Продукта, а всю тарификацию вынести модуль аб. плат?

2. предположим, есть услуга модуля абонентских плат Интернет - 500 руб. и есть Продукт в модуле ТВ - 300 руб.
в начале месяца клиент уходит в минус, кладет 500 руб. на счёт - что разблокируется? останется ли договор заблокированным? или услуга интернета разблокируется? или активируется продукт?
а если как п.1 работать с услугами модуля аб. плат, а в модуле ТВ цена за Продукт будет нулевой - когда клиент уйдёт в минус, продукт деактивируется?

3. в конце месяца, рассылаем клиентам уведомления, с предрасчитанной аб. платой за Интернет. Делается это калькулятором модуля аб. плат, а можно ли модулем ТВ делать такой же предрасчёт?
или как в п.1 работать с модулем аб. плат и их услугами?

откоментируйте пожалуйста. нужно внедрить интеграцию, и пока что все встало на подневной(месячная, пропорциональная дням) тарификации.

1. В модуле TV обсчитывает не как абонплаты, а как подписку.
Хватает денег - списывает и продляет подписку, при этом не привязано к календарному месяцу.
В данном случае если доработать ветку (точнее сделать новую ветку) стоимость X руб за Y дней, чтобы Y высчитывался как кол-во дней до конца месяца, а X потом умножался на это кол-во - должно заработать так как хотите.
Т.е. будет ветка X руб за 1 день до конца месяца.

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

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

не совсем понял. это можно сделать сейчас?
т.е. если тариф 300 руб. в месяц, то сделать ветку:
30руб. за 1 день? тогда в феврале тариф будет стоить 28дн.(29дн.)*30руб., а в месяцах с 31 днем будет 31*30?

и как быть тогда в случае, если у абонента на счету 100рублей, наступает новый месяц, ему надо заплатить 500рублей по модулю абонентских плат, его договор блокируется статусом Закрыт? а Продукты в модуле ТВ будут продолжать реактивироваться из этого Входящего остатка на начало месяца? т.е. модуль ТВ понимает статус договора? или это надо будет учесть в дин. коде OrderManager'a?

Нет, сейчас сделать нельзя, нужно доработать.
Нет, в данный момент не учитывает статус договора, учитывает только состояние аккаунта (включен/отключен), которое зависит от статуса аккаунта (или баланса при включенном параметре конфигурации). Можем добавить, вроде бы не сложно.

Выкладывается обновление
TV: Отмена продления подписки, если статус договора среди значений contract.status.suspend.codes в конфигурации модуля.

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

скажите, а достаточно ли будет такой конструкции:



чтобы правильно менять статус аккаунта? т.е. чтобы его изменения увидел Фццесс\Аккаунтинг и деактивировал его и его продукты на устройстве?

мне кажется, что мы все таки вынесем тарификацию из модуля ТВ в Модуль абонентских плат, и будем управлять статусом аакаунта.

или нужно что то из ru.bitel.bgbilling.modules.tv.access.om.event кинуть?

в общем сделал как то так:



работает как хотелось.
повесил на события активации\деактивации продуктов добавление\прерывание аб. плат модуля NPAY. Прерывание делаем глобальным скриптом перед концом месяца или по статусу договора Закрыт\Приостановлен через Состояние\Статус аккаунта модуля TV.
какой то такой велосипед =)

Мы обычно рекомендуем вызывать наши сервисы, т.к. Dao работает только с БД, а сервисы сами бросают необходимые события.

P.S. Думаю добавим в TV в ближайшем будущем пропорциональное начисление. А также с начислением не в реальном времени решим вопрос.

Нужно реализовать такую же схему со списанием АбонПлаты за ТВ (полный и не полный месяц) - подскажите: как Вы это реализовали?

я так понимаю, это уже добавили в функционал, хотя сам еще не обновлялся и не смотрел.

у себя делал так:
в обработчик (OrderManager) для своей мидалвари добавил управление модулем абонентских плат. каждому продукту сопоставил через атрибуты id абонентской платы. ну и обработчик сам добавляет\приостанавливает абон.платы.

а как это работает? не могу понять, как задается пропорциональность?

есть какие то сроки с этим?