Сабж - скорее всего не ошибка, а "фича", но все же приносит прилично неприятностей для "счастливых обладателей" пакетов с предоплаченными метрами. Пример: попользовал человек днем старый пакет, накачал скажем 80 мб, вечером перешел на новый - и ему ессно эти же 80 мб пошли как использованный траффик.
С датой активации/окончания - примерно те же грабли выходят. Активировал пакет в 23.00, через N дней - в 0.00 пакет пользовать не может...
Планируется ли добавление времени активации к дате, или эта доработка - за деньги?
Дата активации, без времени
эт да... оно предоплаченный с начала месяца считаетнакачал скажем 80 мб, вечером перешел на новый - и ему ессно эти же 80 мб пошли как использованный траффик
а так ли нада? просто нада разрешить смену пакета только с границы суток так например и на укртелекоме сделаноПланируется ли добавление времени активации к дате, или эта доработка - за деньги?
и эта правильна... а учётный период мож быть и суткиchtito2 писал(а):У вас включена возможность юзеру менять свой текущий план когда он захочет? Никогда не понимал ее целесообразности. Куда проще дать возможность менять только план следующего учетного периода, и производить смену в 00:00 часов даты окончания через periodic daily.
нет. с даты активации пакета.ran писал(а):эт да... оно предоплаченный с начала месяца считает
Все равно - допиливание биллинга.ran писал(а):а так ли нада? просто нада разрешить смену пакета только с границы суток так например и на укртелекоме сделано
1) будут жалобы мол "я тут взял анлим - мне он надо сегодня, чего я должен 2 недели ждать" - и они будут правы.chtito2 писал(а):У вас включена возможность юзеру менять свой текущий план когда он захочет? Никогда не понимал ее целесообразности. Куда проще дать возможность менять только план следующего учетного периода, и производить смену в 00:00 часов даты окончания через periodic daily.
2) делать отчетный период = 1 дню - тоже маразм, т.к. невозможно реализовать пакеты типа 1.2 гига на 30 дней.
отсюда и выводы...
-
~AsmodeuS~
- Site Admin
- Сообщения: 5749
- Зарегистрирован: Пт янв 28, 2005 3:11 pm
- Контактная информация:
в этом плане мне опять же нравится политика ОГО укртелекома (и я стараюсь у себя реализовать где-то так же): клиент может менять тп раз в сутки с границы суток. При смене на тп с более низкой стоимостью сниамется 20 с депозита. Это вполне реализуемо на существующем абиллсе при условии дневной абонплаты (не зря на укртелекоме учётный месяц - 30 календарных дней без выпендрёжев в стиле chtito1) будут жалобы мол "я тут взял анлим - мне он надо сегодня, чего я должен 2 недели ждать" - и они будут правы.
). А всё остальное - это правильное составление договора с клиентом-
~AsmodeuS~
- Site Admin
- Сообщения: 5749
- Зарегистрирован: Пт янв 28, 2005 3:11 pm
- Контактная информация:
ran, эта система хороша для анлима. И абсолютно неподходит для пакетов с предоплаченным траффиком. + ко всему - если есть пакет определенной стоимости, который действует фиксированное кол-во дней и по окончании которого пользователю блокируется локалка - то отчетный интервал в 1 день вызовет, мягко говоря, негативную реакцию у клиентов. Т.к. даже переход с помесячного учета в старой системе на 30-дневный вызвал достаточно возмущений.
Прийдется тогда править скрипты для блокировки возможности смены ТП мгновенно при наличии активного ТП, оставив только смену по расписанию. Ну и + в скриптах предупредить возможность соединения после 0.00 в случае, если в расписании присутствует смена ТП на этот день.
Прийдется тогда править скрипты для блокировки возможности смены ТП мгновенно при наличии активного ТП, оставив только смену по расписанию. Ну и + в скриптах предупредить возможность соединения после 0.00 в случае, если в расписании присутствует смена ТП на этот день.
А я не дал этому шквалу волнений произойти и просто поменял алгоритм просчета даты окончания плана в Abills/modules/Dv/webinterface (несмотря на название, функции оттуда вызываются из periodic ежедневно) чтобы считался ровно месяц. Теперь если юзер активировался 16-го числа, то следующее снятие у него произойдет 16-го числа следующего месяца независимо 28, 29, 30 или 31 день в данном месяце (используется логика Date::Calc).NiTr0 писал(а):даже переход с помесячного учета в старой системе на 30-дневный вызвал достаточно возмущений.
Один из недостатков абиллса: грануляция учетного периода одни сукти, а не с секундной точностью. Здесь могло и должно было использоваться точное время активации и активирование следующего плана происходить в момент окончания предыдущего (реакцией на RADIUS события, например).
2NiTr0:
) спасёт отца русской демократии 2chtito:
ran, эта система хороша для анлима
так и я об анлимебудут жалобы мол "я тут взял анлим - мне он надо сегодня
я имел ввиду не отчётный период а посуточное снятие абонплаты пакета... а насчёт 30 и скоко угодно дней: / Система/ Dialup / VPN/ Тарифные планы/Другое/Время существования (Дни): я думаю (но не уверенделать отчетный период = 1 дню - тоже маразм, т.к. невозможно реализовать пакеты типа 1.2 гига на 30 дней.
) спасёт отца русской демократии 2chtito:а я просто поменял сам договор с клиентом и поверь мне все поняли и никто не ушёл... я не собираюсь подбирать/настраивать биллинг под все возможные выпендрёжи клиентов, я определяю правила (в договоре) по которым мы работаем. Кто хочет тот работает, кто нехочет... пжалстаА я не дал этому шквалу волнений произойти и просто поменял алгоритм просчета даты окончания плана