Перейти до

Создать тариф как у Интертелокома


Рекомендованные сообщения

Вопрос может кто подскажет. Возможно ли сделать такой тариф как у интертелекома "вільний доступ"  за 5 гр  1000м. с ограничением в сутки.  

Відредаговано SVD
Ссылка на сообщение
Поделиться на других сайтах

сори опечатался. исправил. Но для справедливости ради скажу что мне нужен тариф для ограничения по времени. 5 гр на сутки.

Ссылка на сообщение
Поделиться на других сайтах

Сам по себе stargazer в общем случае, если особо не вдаваться в детали - умеет снимать АП в режимах "раз в месяц" и "каждый день". За что отвечает опция SpreadFee. В случае SpreadFee=yes можно допустить, что тариф в месяце длиною в 30 суток будет стоить 150 денег либо в случае наличия 31-й сутки - 155 денег в месяц.

 

В любом случае использование SpreadFee вгоняет любого оператора в финансовый ад неучтенных копеек и наше отношение к нему четко обозначено в FAQ.

 

В случае использования Ubilling есть более "безкопеечный" вариант:

1. Создаем тег "5 денег в сутки"

2. Вешаем на него виртуальный сервис соответствующей стоимости

3. Дергаем снятие денег за виртуальные сервисы ежедневно через remote API

4. ????

5. PROFIT!

Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)

Огромное спасибо за ответ. на половину он решает вопрос покрайней мере очень просветлело в голове по решению данной темы.  Но дело усложняется тем что надо снимать только когда клиент поработал. Значит получается что трафик должен считаться четко что бы разница в 1 мегабайт была поводом для снять ап. И второе vserviceschargefee  снимает ап со всех кто  таблице tags. Жаль что нельзя указать параметр для конкретного юзера. Но я так понмаю  что выходом из этой ситуации заключаеться написать скриптец который будет проверять у тех пользователей для которых включена услуга, разницу мегабайт  за прошлые и текущие сутки добавлять их в таблицу tegs  делать vserviceschargefee  потом удалять из tegs. Поправте если что не так.


Відредаговано SVD
Ссылка на сообщение
Поделиться на других сайтах
  Цитата

 

 Но дело усложняется тем что надо снимать только когда клиент поработал

По поводу этого очень четко сказано в FAQ.

Ссылка на сообщение
Поделиться на других сайтах
  • 4 weeks later...

Ок. Вы создали тариф с АП в 10 денег и ночной ценой за мегабайт в 1 деньгу, по дороге указав, что цена не зависит от времени.

Ссылка на сообщение
Поделиться на других сайтах

Спасибо.

  Цитата

Вы создали тариф с АП в 10 денег

АП = какой период ? день ? месяц ? в мануалах ответ на этот вопрос не нашел, возможно и плохо искал.  

Буду признателен за пинок в нужное направление. 

  Цитата

и ночной ценой за мегабайт в 1 деньгу, по дороге указав, что цена не зависит от времени.

Как я понимаю нужно вместо 1 указать 0, исходя из поставленой задачи - правильно ?
Ссылка на сообщение
Поделиться на других сайтах
  Цитата

 

АП = какой период ? день ? месяц ? в мануалах ответ на этот вопрос не нашел, возможно и плохо искал.

100% плохо искали - это даже в FAQ есть.

 

  Цитата

 

Как я понимаю нужно вместо 1 указать 0, исходя из поставленой задачи - правильно ?

Если вы не собираетесь тарифицировать трафик - то да, нужно 0 + без порога + цена не зависит от времени.

Ссылка на сообщение
Поделиться на других сайтах
  В 18.10.2013 в 10:28, nightfly сказав:

 

  Цитата

АП = какой период ? день ? месяц ? в мануалах ответ на этот вопрос не нашел, возможно и плохо искал.

100% плохо искали - это даже в FAQ есть.

 

В факе убиллинга размыто написано об конкретно заданном вопросе, ине так показалось :)

  Цитата

 

 

Q: Как начисляется абонплата?

A: По умолчанию - снятие происходит при наступлении первого числа месяца, снимается полная АП тарифа абонента. Если запланирована смена тарифа - сначала меняется тариф, после чего снимается АП нового тарифа и производится ресет пользователя. Счетчики трафика обнуляются. Также существуют совершенно другие, менее адекватные и распространеные модели снятия АП, о них вы можете почитать в документации по stargazer - там очень много еще интересных вещей описано и разжевано.

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

Спасибо за понимание.

Відредаговано dnet
Ссылка на сообщение
Поделиться на других сайтах
  Цитата

 

В факе убиллинга размыто написано об конкретно заданном вопросе

 

 

  Цитата

 

Q: Как начисляется абонплата?

A: По умолчанию - снятие происходит при наступлении первого числа месяца, снимается полная АП тарифа абонента. Если запланирована смена тарифа - сначала меняется тариф, после чего снимается АП нового тарифа и производится ресет пользователя. Счетчики трафика обнуляются. Также существуют совершенно другие, менее адекватные и распространеные модели снятия АП, о них вы можете почитать в документации по stargazer - там очень много еще интересных вещей описано и разжевано.

 

  Цитата

 

Q: А можно начислять АП каждый день пропорционально, либо начислять ее неполностью учитывая время подключение абонента?

A: Да можно, это называется «размазанной абонплатой», но категорически не рекомендуется. Почему - почитайте, на форуме обсуждалось неоднократно. Такой подход однозначно вгоняет вас в финансовый ад неучтенных средств и вызывает эпилептические припадки при попытках разобраться почему у абонента на счету 1,666666667 денег а не 1,612903226 или 1,785714286 и как это все соотноситься с его тарифным планом.

 

  Цитата

 

Q: А как?

A: DayFee в конфиге. А вообще ссылку на документацию по stargazer можно заметить тремя сантиметрами выше.

 

Что, правда размыто? А если потыкать пальцем в 11 страницу http://stargazer.dp.ua/download/server/2.408/stargazer_help_v2.17.pdf ?

 

  Цитата

 

если я правильно понял - снимать абонплату каждый день ?

У вас что-то не так с пониманием. Давайте процитирую еще раз: По умолчанию - снятие происходит при наступлении первого числа месяца, снимается полная АП тарифа абонента.

Ссылка на сообщение
Поделиться на других сайтах
  В 18.10.2013 в 11:08, nightfly сказав:

 

  Цитата

В факе убиллинга размыто написано об конкретно заданном вопросе

 

 

  Цитата

Q: Как начисляется абонплата?

A: По умолчанию - снятие происходит при наступлении первого числа месяца, снимается полная АП тарифа абонента. Если запланирована смена тарифа - сначала меняется тариф, после чего снимается АП нового тарифа и производится ресет пользователя. Счетчики трафика обнуляются. Также существуют совершенно другие, менее адекватные и распространеные модели снятия АП, о них вы можете почитать в документации по stargazer - там очень много еще интересных вещей описано и разжевано.

 

я конечно извиняюсь, изначально спросил так - АП = какой период ? день ? месяц ?

Написано только что она снимается...

 

  Цитата

 

  Цитата

Q: А можно начислять АП каждый день пропорционально, либо начислять ее неполностью учитывая время подключение абонента?

A: Да можно, это называется «размазанной абонплатой», но категорически не рекомендуется. Почему - почитайте, на форуме обсуждалось неоднократно. Такой подход однозначно вгоняет вас в финансовый ад неучтенных средств и вызывает эпилептические припадки при попытках разобраться почему у абонента на счету 1,666666667 денег а не 1,612903226 или 1,785714286 и как это все соотноситься с его тарифным планом.

 

Вы сами-же не рекомендуете так делать :) 

 

  Цитата

 

  Цитата

Q: А как?

A: DayFee в конфиге. А вообще ссылку на документацию по stargazer можно заметить тремя сантиметрами выше.

 

Что, правда размыто? А если потыкать пальцем в 11 страницу http://stargazer.dp.ua/download/server/2.408/stargazer_help_v2.17.pdf ?

 

  Цитата

если я правильно понял - снимать абонплату каждый день ?

У вас что-то не так с пониманием. Давайте процитирую еще раз: По умолчанию - снятие происходит при наступлении первого числа месяца, снимается полная АП тарифа абонента.

 

Исходя из 11стр и задал вопрос - снимать каждый день :) умеет снимать каждый день ?

Исходя из задачи тариф/сутки получается АП = день, снимать так

  Цитата

 

3. Дергаем снятие денег за виртуальные сервисы ежедневно через remote API

Я правильно понял ?

 

Спасибо что разжевали.

Відредаговано dnet
Ссылка на сообщение
Поделиться на других сайтах
  Цитата

 

я конечно извиняюсь, изначально спросил так - АП = какой период ? день ? месяц ?

вроде вполне понятно написано

 

  Цитата

 

снятие происходит при наступлении первого числа месяца

Я в принципе не могу быть на 100% уверен, но в рамках данной планетарной системы, можно предположить, что "первое число месяца" наступает ежемесячно.

 

  Цитата

 

Вы сами-же не рекомендуете так делать :)

Да не рекомендую. Помесячное снятие ликвидирует очень много детских проблем.

С другой стороны - хотите выстрелить себе в ногу? Почему бы и нет?

Ссылка на сообщение
Поделиться на других сайтах
  В 18.10.2013 в 11:36, nightfly сказав:

 

  Цитата

я конечно извиняюсь, изначально спросил так - АП = какой период ? день ? месяц ?

вроде вполне понятно написано

 

  Цитата

снятие происходит при наступлении первого числа месяца

Я в принципе не могу быть на 100% уверен, но в рамках данной планетарной системы, можно предположить, что "первое число месяца" наступает ежемесячно.

 

При условии тариф/сутки не привязанный к календарному, извините не полностью мысль сначала озвучил,

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

Исходя из вышеизложенного АП может быть = и день и месяц смотря как приготовить.

 

Всего-то несколько пинков постов...спасибо на добром слове.

Ссылка на сообщение
Поделиться на других сайтах
  • 2 weeks later...

Продолжим, надо еще пинков, немного усложним задачу, тариф/сутки не привязанный к календарному, при использовании тегов

  В 21.09.2013 в 14:51, nightfly сказав:

В случае использования Ubilling есть более "безкопеечный" вариант:

1. Создаем тег "5 денег в сутки"

2. Вешаем на него виртуальный сервис соответствующей стоимости

3. Дергаем снятие денег за виртуальные сервисы ежедневно через remote API

При условии недоступности пользователю самому менять тарифный план через ЛК.

Собственно вопрос в том как дать возможность пользователю сменить тарифный план через ЛК ? мы же берем деньгу за доп сервис а не основной !? и доп. сервис пользователь менять не можеть.

И походу вопрос, при смене тарифного плана, стг умеет применять сразу и с нового учетного периода, что будет в нашем случае с убиллингом ? в вики был, по логике убиллинга с начала месяца, а как сделать сразу ? средствами стг ?

 

Если я не понятно излагаю, скажу по русски что мне нужно.

Дать пользователю например раз в месяц возможность изменить через ЛК тарифный план,

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

Ссылка на сообщение
Поделиться на других сайтах
  Цитата

 

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

Это упоротый концепт, который я сам же и озвучил.

Просто иллюстрирует  возможность как таковую. Заменять нормальные тарифные планы stargazer-а "виртуальными сервисами" - само по себе убогая идея.

По нормальному - следует просто выпросить/заказать у madf возможность отработки spreadfee=no и fullfee=yes ежесуточно, опцией.

Это позволит снимать АП тарифа таки не только раз в месяц целиком/от момента подключения или ежедневно пропорциональными кусками - как возможно сейчас, но и ежедневно полную АП указанную для тарифа.

 

  Цитата

 

Собственно вопрос в том как дать возможность пользователю сменить тарифный план через ЛК ?

Тарифный план он как раз и может менять.

 

  Цитата

 

мы же берем деньгу за доп сервис а не основной !? и доп. сервис пользователь менять не можеть.

Логично.

 

  Цитата

 

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

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

 

  Цитата

 

Дать пользователю например раз в месяц возможность изменить через ЛК тарифный план,

У него и так эта возможность есть - новый тарифный план вступает в действие первого числа нового месяца.

 

  Цитата

 

день начала потребления услуг = день пополнения счета, не 1е число

Слабо представляю как вообще взаимосвязаны сущности "потребление услуг", "когда там его подключили" и "абонплата".

Відредаговано nightfly
Ссылка на сообщение
Поделиться на других сайтах
  В 29.10.2013 в 16:57, nightfly сказав:

 

  Цитата

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

Это упоротый концепт, который я сам же и озвучил.

Просто иллюстрирует  возможность как таковую. Заменять нормальные тарифные планы stargazer-а "виртуальными сервисами" - само по себе убогая идея.

По нормальному - следует просто выпросить/заказать у madf возможность отработки spreadfee=no и fullfee=yes ежесуточно, опцией.

Это позволит снимать АП тарифа таки не только раз в месяц целиком/от момента подключения или ежедневно пропорциональными кусками - как возможно сейчас, но и ежедневно полную АП указанную для тарифа.

 

 Это вопрос времени, т.е. решаемый.

 

  В 29.10.2013 в 16:57, nightfly сказав:

 

  Цитата

Собственно вопрос в том как дать возможность пользователю сменить тарифный план через ЛК ?

Тарифный план он как раз и может менять.

 

  Цитата

мы же берем деньгу за доп сервис а не основной !? и доп. сервис пользователь менять не можеть.

Логично.

 

  Цитата

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

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

 

Не пинайте сильно, задача не совсем проста, еще раз повторюсь, моя/наша логика заключается в том что тариф не привязан к календарному месяцу, в связи с этим меня "вполне понятные причины" не совсем устраивают, можно это исправить ? варианты ?

 

  В 29.10.2013 в 16:57, nightfly сказав:

 

  Цитата

Дать пользователю например раз в месяц возможность изменить через ЛК тарифный план,

У него и так эта возможность есть - новый тарифный план вступает в действие первого числа нового месяца.

 

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

 

  В 29.10.2013 в 16:57, nightfly сказав:

 

  Цитата

день начала потребления услуг = день пополнения счета, не 1е число

Слабо представляю как вообще взаимосвязаны сущности "потребление услуг", "когда там его подключили" и "абонплата".

 

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

 

Спасибо.

 

ЗЫ: Могу в ЛС описать все пожелания сразу.

Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

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

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.

  • Схожий контент

    • Від camchatix
      Добрий день,
      створили запасний NAS із зайвою хромосомою, все працює але коли треба вбити сесію користувача - то у списку NAS серверів лише один (той що основний)
      переназначити швидкість теж не можу
      я так розумію пакети CoA Disconnect, CoA connect, PoD - ідуть на IP адресу старого NAS ?
    • Від grach_witch_cheese
      Вітаю, колеги!
      Маю наступну схему:
      DHCP-сервер: Accel-PPP (IPoE) DHCP-Relay: MikroTik RADIUS: Запущений безпосередньо на сервері uBilling Зараз авторизація абонентів здійснюється за MAC-адресою, але планується перехід на авторизацію через Option 82.
      У документації uBilling наведені приклади конфігурацій, коли DHCP-сервер працює локально (на самому uBilling) і містить відповідні шаблони для обробки Option 82.
      Однак немає чіткої інформації про використання Option 82 при віддаленому DHCP-сервері, зокрема, коли Accel-PPP використовується як DHCP-сервер у режимі remote та налаштований через Купаген.
      Питання:
      Чи можливо використовувати Accel-PPP як віддалений DHCP-сервер з авторизацією через Option 82? Якщо так, то де відбувається парсинг значень Remote-ID і Circuit-ID? Де в цьому випадку мають зберігатися шаблони для Option 82? Буду вдячний за роз'яснення або посилання на відповідні приклади.
    • Від nightfly
      Ubilling 1.5.2 rev 9302 Book of Endings
       
      Зміни в структурі БД. alter.ini: нова опція FASTPROFITCALC_ENABLED, що вмикає швидкий підрахунок прибутку. alter.ini: нова необов'язкова опція KARMA_IN_PROFILE що вмикає показ карми в профілі користувача. alter.ini: нова опція SWITCHES_AUTH_ENABLED, що вмикає довідник даних авторизації пристроїв. alter.ini: нова опція PON_SCRIPTS_ENABLED, що вмикає підтримку скриптів OLT в ПОНізаторі. alter.ini: нова опція PON_ONU_FDB_SELFFILTER, що вмикає фільтр MAC-ів при відображенні FDB за ONU. alter.ini: нова опція USERBYIP_ENABLED, що вмикає виклик userbyip в RemoteAPI. alter.ini: пачка нових опцій PB_FASTURL_*, що керують поведінкою модулю відсилання коротких посилань на оплату. Модуль PONizer: виправлена помилка зникнення PON інтерфейсів при опиті BDCOM GP3600 Модуль “Профіль користувача”: для опису плагінів профілю та оверлеїв на кшталт “чорної магії” тепер опційно можливо вказувати link_target. Модуль “Панель задач”: для опису елементів панелі задач, тепер опційно можна вказувати LINK_TARGET. Модуль Записи телефонних розмов: вирішено проблеми швидкодії, при перегляді списку записів дзвінків. Модуль “Записи телефонних розмов”: більше не призводить до вичерпання пам'яті процесу, при перегляді великих архівів дзвінків. Модуль “Записи телефонних розмов”: новий аудіо-плеєр для прослуховування записів з візуалізацією аудіо-хвилі. Модуль “Пошук оплат”: реалізовано можливість швиденького підрахунку прибутку по обраних чекбоксами платежах. Модуль УКВ: реалізовано можливість швиденького підрахунку прибутку по обраних чекбоксами платежах. Модулі Мапа обладнання та користувачів: трішки вичищено код. Ліпше не стало. Модуль “Мапа будинків”: поле пошуку при розташуванні будинку, тепер попередньо заповнено локацією, при переході за посиланням “розташувати на мапі”. Модуль “Панель задач”: опція TB_QUICKSEARCH_INLINE змінила свою поведінку, та може тепер приймати значення 0|1|2. Модуль “Звіт по трафіку”: виправлено проблему відображення графіків OphanimFlow для NAS на роздільних здатностях менше ніж FullHD. Кабінет користувача: в модулі “Відеоспостереження” відображення попереднього перегляду каналів користувача, стало трішки притомнішим. Сховище зображень: трішки покращено поведінку форми завантаження. RemoteAPI: новий виклик onusigcompressor, що радикально стискає розпухаючі дані історії сигналів ONU. RemoteAPI: новий виклик pbxmonrefill, що оновлює кеш записів телефонних розмов. RemoteAPI: новий виклик userbyip, що повертає дані про користувача за його IP. OpenPayz: в бекенді та фронтенді platon виправлено проблему диких заокруглень, при вказанні зовнішньої комісії.  
      Повний чейнджлог
      Оновлена демка
       

    • Від ppv
      Після оновлення до 1.5.1 не відображаються сигнали на
      OLT BDCOM P3310B (Device version10.1.0B)

      та
      P3608-2TE (Firmware Version10.1.0E). 

      3310C та P3608B ніяких проблем немає, знімає все добре. 
      З GPON3600-8 все зрозуміло будуть виправлення в Ubilling: 1.5.2.
       
      Може в когось було щось подібне? Хочу знати куди копати.
    • Від mac
      Глюк в тому, що один (так - тільки один) mac адрес onu існує в білінгу у вигляді строки. Це трохи заважає.
      olt - bdcom gepon.
      Наскільки зрозумів, це виключно проблема реалізації snmpwalk у freebsd, де snmpwalk може на свій розсуд віддати mac адресу не як hex-string, а як звичайний string.
      Можливо snmpwalk тригериться на якомусь символі, мені невідомо.
       
      # tcpdump -vv -i em0 udp port 161 and host olt and host ub | grep "3320.101.10.4.1.1.241 ... olt.snmp > ub.47940: [udp sum ok] { SNMPv2c C="*****" { GetResponse(44) R=93278354 E:3320.101.10.4.1.1.241="8LO"W*" } } ub.47940 > olt.snmp: [udp sum ok] { SNMPv2c C="*****" { GetNextRequest(34) R=93278355 E:3320.101.10.4.1.1.241 } } snmpwalk -c***** -v2c -t5 olt .1.3.6.1.4.1.3320.101.10.4.1.1 SNMPv2-SMI::enterprises.3320.101.10.4.1.1.241 = STRING: "8LO\"W*" snmpwalk -Ox -c***** -v2c -t5 olt .1.3.6.1.4.1.3320.101.10.4.1.1 SNMPv2-SMI::enterprises.3320.101.10.4.1.1.241 = Hex-STRING: 38 4C 4F 22 57 2A  
      Це стосується таких параметрів у snmp конфізі bdcom
       
      [signal] MACINDEX=".1.3.6.1.4.1.3320.101.10.4.1.1" [misc] ONUINDEX=".1.3.6.1.4.1.3320.101.11.1.1.3"  
      За для усунення глюку спробував трошки змінити код і завдати тип snmp параметру явно у ./api/libs/api.ponbdcom.php у function collect()
      Це працює. Мабуть станеться у нагоді:
       
      # diff api.ponbdcom.php{.new,.bak} 37c37 < $onuIndex = $this->snmp->walk('-Ox ' . $oltIp . ':' . self::SNMPPORT, $oltCommunity, $onuIndexOid, self::SNMPCACHE); --- > $onuIndex = $this->snmp->walk($oltIp . ':' . self::SNMPPORT, $oltCommunity, $onuIndexOid, self::SNMPCACHE); 91c91 < $macIndex = $this->snmp->walk('-Ox ' . $oltIp . ':' . self::SNMPPORT, $oltCommunity, $macIndexOID, self::SNMPCACHE); --- > $macIndex = $this->snmp->walk($oltIp . ':' . self::SNMPPORT, $oltCommunity, $macIndexOID, self::SNMPCACHE);  
      P.S. Створив тему, а зараз міркую: а може це глюк у ПЗ olt. Оновлю фірмваре olt та перевірю...
       

×
×
  • Створити нове...