Версия билинга последняя 5.2.1-008.
Проблема в следующем: работаем с биллингом более 3-х месяцев, расчётный период с самого начала делал месячный. В нём 168 списаний в неделю, т.е. списания ежечасные. При анализе размеров таблицы списаний и кол-ва записей в ней немного ужаснулся, когда представил, что будет с базой через пол года...
Без задней мысли сделал ещё один месячный период, но уже с 56 списаниями в неделю, т.е. раз в 3 часа и...
... ни черта не понял, как его прикрутить к существующим тарифам.
Прошу помочь тех, кто уже сталкивался с этим бредом! При создании пользователей ребята, которые заводят новых абонентов уже начали выбирать новый период (при выборе тарифа предлагается указать расчётный период, а у меня их два - абсолютно одинаковые строки с разными id), т.е. пошла путаница - теперь есть абоненты, у которых списания через каждые 3 часа.
Я конечно могу похерачить всё прямо в базе, заменить id периода у косячных абнов на старый и удалить созданный мной расчётный со списаниями через 3 часа, но боюсь биллинг не выдержит такой трепанации да и проблему свою я не решу.
Как грамотно выкрутиться из данной ситуации?
PS
Если я в таблице discount_periods изменю значение поля discount_interval и перезагружу ядро биллинга, это будет работать без последствий?
Вопрос по расчётным периодам
Проще пареной репы. Абонов с левым расчётным было с десяток. Сохранил параметры каждого (логины в связке, vpn ip ...), удалил сервисную связку с тарифной и пересоздал их заново со старым расчётным периодом. Парням сказал, с каким ID надо выбирать период. Ну в след. месяце пустой расчётный период должен сам исчезнуть из интерфейса, т.к. к нему не привязана ни одна сервисная связка.
А про размеры базы - придётся чаще делать архивацию таблиц списаний.
Вот такой вот он - гибкий и юзабельный утм...
А про размеры базы - придётся чаще делать архивацию таблиц списаний.
Вот такой вот он - гибкий и юзабельный утм...