Перейти к содержимому
Калькуляторы

Кто как включает абонентов в биллинге?

23 минуты назад, Andrei сказал:

Именно так и делаем. И обещанного платежа хватает максимум на 3 дня, в рублях - 60 руб, т.е. абонент уходит в минус максимум на 60 руб. Даже если свалит не оплатив, мы не обеднеем, но зато сильно повышает лояльность, а "сваливших-незаплативших" исчезающе мало.

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

единственный ( в моем случае ) работающий прием это чтоб я дату отключения знал неотвратимо и четко.  Чтоб она не плавающая была а например "в первый будний день месяца в 10 утра"

 

Поделиться сообщением


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

1 час назад, LostSoul сказал:

имеется ввиду "обещанный платеж".   За него в любом случае берутся деньги.

Какие деньги? Может кто-то и берет, но лучше не брать.

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

 

59 минут назад, LostSoul сказал:

чтоб я дату отключения знал неотвратимо и четко.  Чтоб она не плавающая была а например "в первый будний день месяца в 10 утра"

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

Поделиться сообщением


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

44 минуты назад, Saab95 сказал:

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

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

и 5-6 дней лишних оплаченных в году получается, и поддержка нагружается равномернее.

 

я в тех "малых бизнесах" где делал внедрения ,   старался раскидывать по 3 периодам - 1 , 10 и 20.   или по двум -  1 и 15

 

Поделиться сообщением


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

Поделюсь нашим опытом.

Есть тарифы с посуточной абонплатой. АП списывается каждый день (в 00:00), если средств недостаточно, услуга не предоставляется. Если лицевой счет пополняется на достаточную сумму, то АП списывается и услуга подключается. Если средств недостаточно, но очень надо, то можно подключить обещанный платеж на 3 суток (отправкой SMS), тогда АП будет списана в долг (в размере суточной АП, до трех раз).

Есть тарифы с месячной абонплатой, расчетная дата может быть как 1 число, так и любая другая. АП списывается наперед в 00:00, в остальном так же, как с посуточной абонплатой. Обещанный платеж предоставляется на 10 суток, АП будет списана в долг (в размере месячной АП).

Есть тарифы с большим периодом (более месяца). На некоторых обещанный платеж недоступен по условиям тарифа, на некоторых он автоматический (предоставляется автоматически при недостатке средств, сроком на 10 суток, следом высылается SMS, где указана величина этого обещанного платежа и сроки его погашения).

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

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

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

Поделиться сообщением


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

1 час назад, alibek сказал:

АП списывается каждый день (в 00:00)

может и субъективно, но не очень удобное время отключения абонентов... для абонентов.

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

Поделиться сообщением


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

Наша биллинговая система умеет отключать только на границе расчетного периода.

А расчетный период всегда гранулирован по суткам.

Да и не такое уж это неудобство, на самом деле, если с помощью обещанного платежа можно самостоятельно все включить.

Тут единственная проблема — это своевременно уведомить абонента о том, что у него заканчиваются средства на счету и счет нужно пополнить.

А вот это — своевременно — настоящая проблема, которую я до сих пор не могу решить.

Поделиться сообщением


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

3 hours ago, alibek said:

А вот это — своевременно — настоящая проблема, которую я до сих пор не могу решить.

 

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

 

Просить людей устанавливать какие-то программульки... вроде уже веремена не те.

Поделиться сообщением


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

три дня обещаный платеж через личный кабинет+ кнопочка у техподдержки включить инет на 30 минут.

Поделиться сообщением


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

4 часа назад, vop сказал:

Просить людей устанавливать какие-то программульки...

Я не про транспорт.

Само уведомление мы отправляем по SMS, плюс при отрицательном балансе клиенты подключаются, но перенаправляются на страницу блокировки (работает на ресурсах HTTP, а также замечательно работает на смартфонах/планшетах).

Вопрос в том, когда отправлять SMS.

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

Поделиться сообщением


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

ну таки расчитать? что будет со счетом через 2 дня, и если там минус, то отправитить уведомление.. в пятницу расчитать за 3 дня вперед, чтобы на выходные не попало.. перед НГ запустить руками чуть заранее на побольше срок :)

Ну сумма списания и сроки же у Вас есть ? 

Поделиться сообщением


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

В 20.01.2020 в 23:44, st_re сказал:

ну таки расчитать? что будет со счетом через 2 дня, и если там минус, то отправитить уведомление.. в пятницу расчитать за 3 дня вперед, чтобы на выходные не попало.. перед НГ запустить руками чуть заранее на побольше срок :)

Ну сумма списания и сроки же у Вас есть ? 

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

Поделиться сообщением


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

В ‎20‎.‎01‎.‎2020 в 23:44, st_re сказал:

ну таки расчитать?

Это не так просто.

Чтобы это сделать, нужно фактически продублировать биллинг в части расчета и начисления абонплаты — а это половина биллинга.

Кроме того, тут есть и принципиальные сложности.

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

Даже не говоря о том, что отправка SMS платная, столь частые уведомления делают их бесполезными, человек перестает обращать на них внимание.

Я же говорю, это непростой вопрос. Сейчас он у меня решен таким образом:

- по абоненту проверяется, есть ли на ближайшие 3 дня какие-нибудь списания;

- если в ближайшие 3 суток никаких списаний не ожидается, то данный абонент пропускается;

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

- в противном случае вычисляется примерная сумма списаний до конца месяца;

- если до конца месяца остается меньше 3 суток, то сумма списаний вычисляется до конца следующего месяца;

- при расчете суммы списаний абонплата посуточных и понедельных тарифы пересчитывается на месяц, абонплата других периодов суммируется как есть;

- вычисляется требуемая сумма доплаты (исходя их текущего остатка на лицевом счету), округляется вверх кратно 50 рублей;

 

Алгоритм далек от идеала (постоянно возникают вопросы по указанным в уведомлениях суммам), но ничего лучше пока не придумал.

Поделиться сообщением


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

4 часа назад, sashami сказал:

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

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

У них же и рассылки через вайбер 2р./за сообщение(доставленное) с длиной в 1000 символов + кнопки + картинки.

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

Поделиться сообщением


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

6 hours ago, alibek said:

Алгоритм далек от идеала (постоянно возникают вопросы по указанным в уведомлениях суммам), но ничего лучше пока не придумал.

 

Как все сложно... Списания... Вычисления.... :)

 

При балансовом ведении счетов абонента в биллинге, он - биллинг - знает, когда у клиента наступит нулевой баланс.  Он просто знает все, что будет в течении ближайшего года. Типа этого. В любую секунду админ, клиент или плагин-информер знает, что по текущей услуги последний оплаченный день - 19 января.

Помимо этого, клиент видит, насколько он должен пополнить счет, что бы оплатить работу до любого числа на год вперед.

 

Слово "Прогноз" в заголовке означает, что таблица изменится при пополнении счета, или при смене тарифа, или при включении услуги "Хочу в отпуск".

 

maaa2.png

Поделиться сообщением


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

1 час назад, vop сказал:

он - биллинг - знает, когда у клиента наступит нулевой баланс

Этого никто не знает.

Потому что кроме периодических услуг (абонплата) есть и разовые услуги.

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

Например, расчетная дата услуги 28 февраля, создана она была в не високосный год. Какая дата будет расчетной в високосном году, 28 или 29? Чтобы узнать ответ на этот вопрос, необходимо внимательно изучить исходники биллинга и узнать, как в нем этот момент реализован - и затем повторить это в скрипте.

Поделиться сообщением


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

Все эти извращения в виде плавающего тарифного периода и дней в месяце - это от маркетологов. Кто-нибудь считал, насколько абоненты платят больше за месяц абонплаты ? Если у них расчетный день не 1-го числа, а плавающий день по месяцу ? По моим расчётам приход не покроет фот маркетологов с тараканами, а деньга на биллинг, программеров биллинга, и его админа протрачена...

Поделиться сообщением


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

1 hour ago, alibek said:

Этого никто не знает.

Потому что кроме периодических услуг (абонплата) есть и разовые услуги.

 

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

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

 

1 hour ago, alibek said:

Например, расчетная дата услуги 28 февраля, создана она была в не високосный год. Какая дата будет расчетной в високосном году, 28 или 29? Чтобы узнать ответ на этот вопрос, необходимо внимательно изучить исходники биллинга и узнать, как в нем этот момент реализован - и затем повторить это в скрипте.

Всего этого нет при балансовом учете услуг.

 

1 hour ago, YuryD said:

Все эти извращения в виде плавающего тарифного периода и дней в месяце - это от маркетологов. Кто-нибудь считал, насколько абоненты платят больше за месяц абонплаты ? Если у них расчетный день не 1-го числа, а плавающий день по месяцу ? По моим расчётам приход не покроет фот маркетологов с тараканами, а деньга на биллинг, программеров биллинга, и его админа протрачена...

Кое где и кое у кого установлен тарифный период 28 дней. Это дает, как минимум, 13 тарифных периодов в году. :)

Поделиться сообщением


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

51 минуту назад, vop сказал:

начисление на которые зависит от количества потребленного количества учетных единиц

Кстати да, забыл про такое, у нас все тарифы безлимитные.

 

51 минуту назад, vop сказал:

Всего этого нет при балансовом учете услуг.

Во-первых, ради уведомлений менять биллинг мало кто решится.

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

Этот способ эффективен только при определенных условиях. Очевидно, что он потребует хранения (и расчета) дополнительных данных.

Например, у нас есть услуга с суточной абонплатой. Значит на каждую такую услугу нужно будет хранить 365 записей вспомогательных данных. И при любых изменениях лицевого счета вместо одного перерасчета нужно будет делать 365 перерасчетов. И вместо одного начисления абонплаты (на ближайший следующий период) нужно проводить 365 начислений.

Далее, у одного абонента у нас не одна услуга, а несколько одновременно: посуточный доступ в интернет, понедельный email, помесячное телевидение и квартальный IP-адрес. Мало того, что для такого набора услуг потребуется 433 записи вспомогательных данных, так еще и практическая польза от такого "расчета наперед" резко падает, потому что если средств на лицевом счету хватит только на часть услуг (например хватило на интернет и email, а на телевидение уже не хватило), то ранее посчитанные моменты сразу станут инвалидными и их нужно будет пересчитывать. Ну и наконец, при таком способе учета реализация кредитного лимита или обещанного платежа становится неочевидной — нужно будет либо пересчитывать все вспомогательные данные, либо хранить данные в дифференцируемом виде.

 

1 час назад, vop сказал:

меняется дата исчерпания баланса

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

И усугубим тем, что во-первых расчетные периоды разные (например сутки и месяц), а во-вторых при недостатке средств на списание абонплаты она не списывается. но и услуга не оказывается.

Как определить дату исчерпания баланса? Формулой это не посчитать. Необходимо именно что воспроизвести (симулировать) все начисления и списания абонплаты на год вперед.

Поделиться сообщением


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

3 hours ago, alibek said:

Во-первых, ради уведомлений менять биллинг мало кто решится.

 

Зачем? :) Каждому приходится иметь дело с тем, что он выбрал. И для смены нужны более серьезные основания.

 

Quote

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

Балансовый учет на то и нужен, что бы ничего наперед не рассчитывать.

 

Quote

Например, у нас есть услуга с суточной абонплатой. Значит на каждую такую услугу нужно будет хранить 365 записей вспомогательных данных. И при любых изменениях лицевого счета вместо одного перерасчета нужно будет делать 365 перерасчетов. И вместо одного начисления абонплаты (на ближайший следующий период) нужно проводить 365 начислений.

Начисление делается один раз в месяц. На счет абонента. Но то уже детали реализации.

 

Quote

Далее, у одного абонента у нас не одна услуга, а несколько одновременно: посуточный доступ в интернет, понедельный email, помесячное телевидение и квартальный IP-адрес. Мало того, что для такого набора услуг потребуется 433 записи вспомогательных данных, так еще и практическая польза от такого "расчета наперед" резко падает, потому что если средств на лицевом счету хватит только на часть услуг (например хватило на интернет и email, а на телевидение уже не хватило), то ранее посчитанные моменты сразу станут инвалидными и их нужно будет пересчитывать. Ну и наконец, при таком способе учета реализация кредитного лимита или обещанного платежа становится неочевидной — нужно будет либо пересчитывать все вспомогательные данные, либо хранить данные в дифференцируемом виде.

У меня на моем абонентском счету в одном из моих биллингов  сейчас - секундочку - 123 услуги. ip-адреса, mailbox'ы e-mail'ы, hostings, web-сайты и т.д. Учет и управление удобно вести.

 

Quote

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

Добро пожаловать в мир конвергентных биллингов.:) Ну да ладно. :)

 

Quote

И усугубим тем, что во-первых расчетные периоды разные (например сутки и месяц), а во-вторых при недостатке средств на списание абонплаты она не списывается. но и услуга не оказывается.

Как определить дату исчерпания баланса? Формулой это не посчитать. Необходимо именно что воспроизвести (симулировать) все начисления и списания абонплаты на год вперед.

Суть балансовой системы в том, что доступ абонента к услуге определяется не "списаниями", а балансом. В любую секунду биллингу известен остаток на счету, уровень затрат и стоимость. Балансировка ведется в посуточном режиме. Можно вести в почасовом режиме - но это никому нафиг не надо. В результате одним простым арифметическим целочисленным действием мы знаем прогнозируемый баланс на любой день хоть через год, хоть через 3 года. Прогноз меняется при изменении тарифа, либо с появлением нерегулярных затрат и услуг.

 

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

Поделиться сообщением


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

8 часов назад, vop сказал:

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

Я видимо коряво выразился. Данный механизм удобен в том случае, когда услуга только одна, либо это все услуги объединены в пакет и подключаются/отключаются разом.

Попробую показать на примере.

Например у абонента подключена услуга1 с а/п 10 рублей в сутки и услуга2 с а/п 100 рублей в месяц. Баланс лицевого счета абонента 120 рублей.

Вариант 1 — расчетная дата по услуге2 наступает завтра. Вариант 2 — расчетная дата по услуге2 наступает через 3 дня. Вариант 3 — расчетная дата по услуге2 наступает через 5 дней.

Вариант 1

 

Вариант 2

 

Вариант 3

 

День 0

120

День 0

120

День 0

120

День 1

10

День 1

110

День 1

110

День 2

0

День 2

100

День 2

100

 

 

День 3

0

День 3

90

 

 

 

 

День 4

80

 

 

 

 

День 5

70

 

 

 

 

День 6

60

Так вот, при такой системе даже просто посчитать баланс по формуле (типа Б = Б - N*P1 - M*P2) нельзя. Необходимо итеративно считать каждый день, пока не кончаться средства, или пока не будет заполнен буфер.

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

Например в вариантах 1 и 2 средства на счете заканчиваются на 3 и 4 день соответственно, то есть услуга1 после этого должна быть приостановлена (поскольку средств для списания абонплаты недостаточно). Однако по услуге2 абонплата уже была списана и соответственно услуга должна оказываться. То есть прогноз остатка на день 5 будет нулевым, однако услуга2 должна оказываться. Чем тут поможет знание баланса?

В варианте 3 ситуация обратная — по услуге1 списания абонплаты происходят успешно и услуга должна оказываться, однако для списания абонплаты по услуге2 средств недостаточно и начиная с день 5 она должна быть приостановлена.

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

В нашей биллинговой системе используется иной принцип. Его можно выразить так — если абонплата была списана, то за соответствующий расчетный период услуга должна предоставляться. Ну и к этому дополнительно прикручивается довольно сложная логика списаний (когда списание производится, а когда нет).

Поделиться сообщением


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

17 часов назад, YuryD сказал:

Все эти извращения в виде плавающего тарифного периода и дней в месяце - это от маркетологов. Кто-нибудь считал, насколько абоненты платят больше за месяц абонплаты ? Если у них расчетный день не 1-го числа, а плавающий день по месяцу ? По моим расчётам приход не покроет фот маркетологов с тараканами, а деньга на биллинг, программеров биллинга, и его админа протрачена...

Средний чек - среднее арифмитическое по чекам.

АРПУ - среднее арифмитическое по чекам но разложенное на уникальных абонентов.

Типовой - 50ка. (самая частая сумма).

2020-1-31 14-41-27.jpg

 

550 - это "верхний" тариф. Видно что средний чек превышает его.

Поделиться сообщением


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

8 hours ago, alibek said:

Я видимо коряво выразился. Данный механизм удобен в том случае, когда услуга только одна, либо это все услуги объединены в пакет и подключаются/отключаются разом.

 

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

 

Откуда система блокировок возникла? Подсказываю - проблема "маленьких отдельных списаний" появилась не в провайдинге. Она появилась в банковской системе при создании процессинговых центров для платежей банковскими картами. Например, вы находитесь в - ээээ - на острове Хайнань (ирония). Вы гуляете, вам жарко, и вы покупаете мороженное. За 20 юань. Гуляете дальше, и опять покупаете мороженное за 20, колу за 10, опять мороэженое... и т.д. Т.е. делаете по 20 мелких покупок каждый день. Фишка в том, что эти покупки каждый раз с вашего банковского счета в Лондоне не списываются. Счет вообще не трогается. Вместо этого вашему счету выставляется блокировка на сумму ваших покупок. С каждой новой покупкой сумма блокировки растет. В результате, списаний с вашего счета нет, но вы уже не можете потратить свои деньги в рамках блокировки. Ну и потом, раз в неделю, или раз в месяц банк эквайер делает платежный батч. Т.е. списывает одним платежом всю накопленную сумму блокировок, одновременно снимая саму блокировку.

 

Quote

Попробую показать на примере.

Например у абонента подключена услуга1 с а/п 10 рублей в сутки и услуга2 с а/п 100 рублей в месяц. Баланс лицевого счета абонента 120 рублей.

Вариант 1 — расчетная дата по услуге2 наступает завтра. Вариант 2 — расчетная дата по услуге2 наступает через 3 дня. Вариант 3 — расчетная дата по услуге2 наступает через 5 дней.

 

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

 

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

 

Размер блокированной суммы пересчитывается с частотой наступления финансовых евентов. Например, у нас белимит интернет. Стоимость безлимита, например, 30 рублей в месяц. Ну или рупь в день. Как часто расчитывается сумма блокировки? Один раз в сутки. Пока не происходит евент "наступил новый день". В результате в первый день блокировка составит 1 рупь, а 18-го = 18 рублей. Т.е. расчет примитивный.

 

Quote

Вариант 1

 

Вариант 2

 

Вариант 3

 

День 0

120

День 0

120

День 0

120

День 1

10

День 1

110

День 1

110

День 2

0

День 2

100

День 2

100

 

 

День 3

0

День 3

90

 

 

 

 

День 4

80

 

 

 

 

День 5

70

 

 

 

 

День 6

60

Так вот, при такой системе даже просто посчитать баланс по формуле (типа Б = Б - N*P1 - M*P2) нельзя. Необходимо итеративно считать каждый день, пока не кончаться средства, или пока не будет заполнен буфер.

 

 Теперь давайте посмотрим, что же у нас с балансом, например 21-го числа. Для интернета за 30 и вебхостинга за 15.

 

Остаток на счету = 200 рублей (этот остаток меняется при платеже на счет, либо при окончании платежного периода)

 

Услуги:

1. Интернет = 21 рубль.

2. Хостинг =  10.50

 

Итого баланс: 200 - 31.50 = 168.50

 

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

 

Наступает 22-е число. Остаток не меняется, Услуги просчитывают новые суммы блокировки - 22 и 11 рублей. Баланс = 167. При этом тут же видно, какая сумма добавляется к блокировке каждый день - 1.50. Как нам узнать, когда наступит 0? Просто:

 

167 / 1.50 = ~111 дней :)

 

Quote

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

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

 

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

 

Quote

Например в вариантах 1 и 2 средства на счете заканчиваются на 3 и 4 день соответственно, то есть услуга1 после этого должна быть приостановлена (поскольку средств для списания абонплаты недостаточно). Однако по услуге2 абонплата уже была списана и соответственно услуга должна оказываться. То есть прогноз остатка на день 5 будет нулевым, однако услуга2 должна оказываться. Чем тут поможет знание баланса?

В варианте 3 ситуация обратная — по услуге1 списания абонплаты происходят успешно и услуга должна оказываться, однако для списания абонплаты по услуге2 средств недостаточно и начиная с день 5 она должна быть приостановлена.

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

В нашей биллинговой системе используется иной принцип. Его можно выразить так — если абонплата была списана, то за соответствующий расчетный период услуга должна предоставляться. Ну и к этому дополнительно прикручивается довольно сложная логика списаний (когда списание производится, а когда нет).

 

В вашем рассуждении начинаются неточности. Во первых не могут средства заканчиваться "на услуге" в разные дни. Они там вообще не могут заканчиваться, так-как в модуле услуг нет никаких средств. Средства заканчиваются только на лицевом счет абонента. Он один, и средства там заканчиваются в один момент. Для всех услуг.

 

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

 

Вы можете спросить, что делать если на лицевом счета в нашем примере осталось 17 рублей. Когда у нас одна услуга стоит 30, другая 15. Напоминаю, что у нас балансовая система, и у нас нет учета отдельных услуг. Мы учитываем весь набор услуг, который нам обходится в 1.50. Поэтому если на счету 17 рублей - мы предоставляем доступ 11 дней, после чего рубим все услуги, если денежки не добавились на счету.

 

И последнее, как делать информер. Да все просто. Устанавливаем (разными способами) порог инофрмирования. Например, 20 рублей. Плагин информера пробегает по балансам клиентского счета раз в скока ему надо (раз в минуту, раз в сутки...), сравнивая баланс с предыдущим значением. Если баланс пересек установленный порог в минимальную сторону, то наступает евент информирования. Плагин, пробежав по балансам, запомнил новые значения у себя в линейном списочке, если этого не делает биллинг.

 

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

 

Ну где-то так.

 

Поделиться сообщением


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

On 1/18/2020 at 6:20 PM, Andrei said:

Именно так и делаем.

+1. У нас тоже, только по умолчанием дня на 2. Если хомяк решил оплатить для абонамент на месяц, списиваем етих 2 дня и все ОК.

Поделиться сообщением


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

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.