BiTel

Добрый день!

Потребовалась следующая фича: с какого числа подключился пользователь, с такого числа и начислять абонплату за месяц. Т. е. с 15 июля по 15 августа, например. И пользователь знает, что расчетный период у него 15 число месяца. В 5.0 (и 5.1, вроде), для этого существовал "расчетный период" и можно было написать собственный скрипт для абонплат. В 5.2 такого не нахожу. Нашел, что через шедулер и


могу реализовать что-то подобное, но, получается это создавать разные абонплаты. Есть ли другая возможность?

А как вы подобное решаете с бухгалтерией? у нас тоже хотели но я отговорил.
Ибо с 15 июня по 15 июля - 30 дней (не включая 15 июля)
с 15 июля по 15 августа - 31 день уже

или например с 15 января по 14 февраля - 31 день.
а с 15 февраля по 14 марта - 29 дней.

Бухгалтерия работает календарными месяцами.
Т.е. будет сплошная головная боль.
Либо я чего то не так допонял.

_________________
Цитаты великих людей
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn

Если это про модуль Dialup - то в модуле Inet есть очень схожий функционал.

А какие проблемы? В обоих приведенных Вами случаях клиент работает полный календарный месяц.

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

Проблема в том что вы говорите пользователю что у него тариф 300 рублей за месяц (например)
Из этого получается вот такая вот шляпа.


Хотя конечно я не исключаю что я вас не понял

_________________
Цитаты великих людей
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn

Я понял, Вы пытаетесь расписать месячную сумму как сумму ежедневных списаний. Причем вы разрываете период. В этом случае действительно будут проблемы. А списывать надо именно целым периодом.

"Скользящий/свободный месяц"? Какая старая тема (определенно это летнее обострение - та тема тоже июльская). Об этом тут столько раз говорили, просили и, наверное, даже угрожали, а воз и ныне там.

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

Добрый день!

А есть примерная дата выхода модуля? Агитирую одного прова за bgb, и ему этот модуль жизненно необходим. Может можно тестово попробовать?

тестовую версию постараемся запилить в течение августа....

P.S. Опишите как Вы планируете использовать модуль, прикину насколько он вам поможет и может, что то сразу запилим в него.

Собственно как мне рассказывает тот провайдер - основная идея у них это свободное назначение периода обсчета. Что важно особенно для пенсионеров. То есть человек знает, что денежку он получает например 15 числа месяца, он приходит в контору и говорит - хочу чтобы у меня абонплата рассчитывалась не с 1го по 1е, а с 16е - по 16е. Но тут возникает сразу же ньюанс - в остальных модулях тоже надо предусмотреть что начало периода у нас сдвинуто.
Ну и от себя еще - нужны дробные количества в модуле. А то есть цена размещения за 1U, пользователю надо 1,5U. Приходится извращаться

В inet есть понятие учетного периода

Он есть и в dialup, но с ним нечего делать, кроме как скрипты на событие его запроса писать. Он в тарифах не фигурирует, ЕМНИМС.

насчет начала периода с произвольного числа это понятно, не понятно, что делать если на момент окончания периода нет денег на следующий период...
варианты
1) загонять в минус
2) блокировать, и разблокировать по дате прихода, но учетный период считать с даты окончания предыдущего
3) новый период начинать с той даты когда пополнили баланс...
4) новый период активировать с даты первого обращения после окончания предыдущего
5) как то еще....

у вас как планировалось?

1) загонять в минус это плохо. Нам лично очень нравится система блокировки по недостаточному платежу
2) Нет. Учетный период назначается только пользователем. Если деньги пришли на заблокированный договор и их достаточно, то разблокировать договор но дату начала периода не менять.
3) Иногда нужна вот такая система. У пользователя абонплата пропорционально периоду. Но чтоб он сильно не расслаблялся, подключая и отключая себе абонплату когда захочет, было бы неплохо ввести некий минимальный порог активации или "штраф" за простой. В принципе система штрафов и сейчас уже реализуема в модуле NPAY, а вот порог активации нет. Под порогом активации я понимаю: для того чтобы договор разблокировался, абонент должен внести полную сумму абонентной платы за месяц.


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

Сразу нет.


Лично мне, как, наверное, и многим здесь, нравится идея заложенная в дебетовых абонентках, т.е. нет денег на абонентку и пока не положишь "$ >= абонентка", то "ты кто такой? давай, до свиданья!"(с).


Заставлять его лазить на статистику?
Пожалейте юзера, который никогда не знает о наступлении 1-го числа месяца, т.к. эта дата не известна 99% юзеров, а если добавить сюда еще и период, то я боюсь ухудшения статистики психических заболеваний.
Пожалейте ТП, которая должна будет отвечать "зайдите на статистику и установите себе период работы".

В dialup можно делать учетный период произвольной величины в момент 1-го подключения за пределами прошлого периода (сейчас - 1-е подключение в месяце), что давало полную автоматизацию процесса и если в inet прикрутят сюда автоматическую, т.е. без скриптов, установку периодов/статусов будет вообще класс.
Т.е. человек может положить деньги 1-го числа, а подключиться, т.е. начать пользоваться 10-го числа и если мы начнем ему считать $ за то время когда он не пользовался это его не очень обрадует.


А вот статус договора лучше всего не трогать и делать таким же, как и период - тогда пересчитывать будет удобно.
Вообще все эти периоды должны быть ж0стко привязаны к статусам, т.е. фактически модуль должен только читать статусы и на их основе считать, IMHO.


+1
Тут уже об этом писали и я считаю это хорошей, годной фичей.
Нет денег на 1++ (должно быть настраиваемо в дереве) полноценную абонентку - статус = закрыт/приостановлен, есть деньги - снимаем хоть каждый день, хоть сразу за весь период.

2) т.е. если клиент просрочил полмесяца(месяц, полгода), то он должен за него(них) все равно заплатить?
3) лично я всегда старался избегать быть клиентом компаний которые "заставляют", что то платить по ОБЯЗАТЕЛЬНОЙ схеме и еще грозят штрафами (по моему очень мало людей которым нравяться когда их что ли завтавляют делать и еще угрожают), предпочитаю те компании которые стимулируют клиентов "подарками", типа "заплати за полгода вперед и получи скидку", "проработал 5 месяцев подряд, шестой бесплатно" или если оплачиваете без перерыва, то с 1 по 3 месяц абонентка 100% с 3 по 6 месяц 90% ну и т.д.

не вижу смысла в описанной вами схеме, ее легко сдвинуть на 1 число месяца, пополнять можете хоть с 15 по последний день месяца, а в списываться будет 1. (почему дата списания нужно привязывать к дате получения денег, а если пенсию задержут, все "попал")
эта схема имеет смысл когда период не кратен месяцу (например клиент вахтовик и вахта 3 недели)

Смысл именно пенсионеры, бабушки - люди старой закалки, которые привыкли считать каждую копейку. Пенсию им приносят допустим 15го числа. 16го они идут платить за все услуги. Если сделать как Вы говорите и списывать абонплату 1го числа, то их, соответственно, 1го и заблокирует.

не понял... если они 16 пополнят баланс, почему их первого должно заблокировать?

ВНЕЗАПНО оказывается, что наши уважаемые разработчики любят бонусы! Скажите, пожалуйста, почему же тогда Вы не стали их запиливать в БГ? А то тут уже сколько копьев сломали на этот счет (небольшая часть линков которые вспомнил).
Наверное Вам надо стать клиентом оператора у которого стоит БГ и тогда я представляю ваш диалог:
- Почему у вас нет бонусов, которые мне очень нравятся?
- Потому что в нашем биллинге нет этого функционала.
- А что же у вас за биллинг такой, в котором нет бонусов?
- БГБ
- <фрустрация>

_________________
Цитаты великих людей
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn

плагин бонусов в разработке, выложим в конце месяца

wow. чур я бета тестер

_________________
Цитаты великих людей
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn

Встроить в БГ a-la дебетовые абонплаты никак не выйдет?

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

нет, но в разработке модуль "подписок" который возможно можно будет использовать как "дебетовые абонплаты"

и йа и йа

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

Проще приведу пример. Для простоты считаем что в месяце 30 дней
Абонплата 30р/месяц. Пользователь подключился 15 числа и положил на счет 30 рублей, чтобы ему хватило до 15 числа следующего месяца.
- Система по тарифу посчитала пользователю 15р в текущем месяце. Все хорошо, пользователь работает
- Наступило 1е число, система насчитала пользователю 30р абонплаты. И опа, денег то на счете не хватает
Сразу добавлю что вариант абонплаты "до текущего" дня не вариант, так как открывает поле для спекуляций.