[vop]

5 hours ago, ~AsmodeuS~ said:

так опишите, вдруг комуто поможет

Работая второй десяток лет могу только сказать, что мало кто слушает какие-либо разумные доводы. Что засело в голове, то и долдонят, порой даже не могут объяснить, зачем "им так хочется". :)  Но вы же знаете, как все это должно работать! :)  Но раз вы советуете что-то описать, могу кратенько, тезисно.

 

1. Услуга интернета - это услуга НЕПРЕРЫВНОГО и РАВНОМЕРНОГО характера. Она предоставляется не разово и поштучно, как другой товар, а постоянно, увеличивая свою стоимость в постепенно возврастающем темпе (поминутно, почасово, посуточно).

 

2. Учет непрерывной услуги должен вестись таким же равномерным балансовым способом. Баланс услуги составляется из двух составных частей:

- статическая составняая часть - остаток на счету абонента;

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

 

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

 

3. Вся суть учета состоит в мониторинге состояния баланса относительно установленого лимита (предела предоставления услуги). По умолчанию лимит равен самой минимальной отрицательной величине учета. Например -0.01 рупь. При балансе = 0 вроде денег нет, но нет и "долга", поэтому услуга должна предоставляться. При желании, как вариант, может быть введена кредитная система методом снижения лимита. Например, при установке лимита в -20, клиент может "кредитоваться" на 20 рупей.

 

4. "Списание" абонплаты проводится в самый удобный момент в 00:01 первого числа каждого месяца. "Списание" заключается в занесении суммы уже предоставленных услуг за прошедший месяц в историю операций текущего счета. При этом, состояние счета уменьшается на абонплату, размер динамической части баланса увеличивается на ту же сумму за счет перевода предоставляемых услуг в статус "оплаченных", которые исключаются из мониторинга. В результате, баланс не изменяется в момент "списание", и предоставление услуг никак не зависит от этого момента списания. В этом и заключается посуточный непрерывный балансовый учет.

 

5. Поведение системы в момент снижения величины баланса ниже установленного лимита (-0.01) может отличаться в зависимости от "пожеланий начальства". Например, можно блокировать доступ, но продолжать считать стоимость услуги, увеличивая ее каждый день. Можно заморозить доступ, прекратив увеличения суммы услуги. А можно считать до конца месяца, заморозив услугу с начала нового месяца. Ну или еще что, не суть важно.

 

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

 

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

 

Вот как-то так. Что тут не понятного или загадочного - скзать сложно. Да и изобретать тоже, как по мне, нечего.

 

[vop]

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

 

Кстати, балансовая система широко применяется во многих странах при учете обычных коммунальных услуг. Например, в Китае по коммунальному пластику, или в Японии на серверах учета. Вода, газ, свет - закончилось, автоматом отрубилось, сбегал в ближайший терминал, или залез на банковский сервер, или вообще через WeChat денежек закинул - хлоп, водичка и пошла... :)

[disappointed]

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

И еще чуток.

У вас на сайте в логотипе ошибка - ManagEment, буква пропущена.

И эта же ошибка продублирована везде на сайте, где используется это слово.

[vop]

10 minutes ago, disappointed said:

У вас на сайте в логотипе ошибка - ManagEment, буква пропущена.

И эта же ошибка продублирована везде на сайте, где используется это слово.

Я знаю. Лень поправить. :)

[~AsmodeuS~]

18 hours ago, vop said:

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

 

Кстати, балансовая система широко применяется во многих странах при учете обычных коммунальных услуг. Например, в Китае по коммунальному пластику, или в Японии на серверах учета. Вода, газ, свет - закончилось, автоматом отрубилось, сбегал в ближайший терминал, или залез на банковский сервер, или вообще через WeChat денежек закинул - хлоп, водичка и пошла... :)

 

на мой взгляд эта схема ок для больших компаниц и с послеоплатой, для припейда это не подойдет

[Saab95]

В 12.10.2018 в 23:45, AlKov сказал:

Оно и есть - низзяяя.. Клиент может в суд обратиться за "загон в долг" без его царского согласия..

Это если вы с него долг требовать будете. Яркий пример тут такой - абонент ушел в минус и взял обещанный платеж, пользовался, допустим, 3 дня, после не оплачивал и не пользовался. Но по факту он услугу потреблял, а услуга помесячная, значит должен уже=) И вот если провайдер на это глаза закрывает и списывает эти 3 дня, то и проблем никаких.

[vop]

5 hours ago, ~AsmodeuS~ said:

 

на мой взгляд эта схема ок для больших компаниц и с послеоплатой, для припейда это не подойдет

Как раз, наоборот, это чистая схема с предоплатой. Сколько заплатил - столько и работаешь. Услуга не только непрерывная, но и отключаемая. Это и позволяет ее контролировать балансом.

А вот если снижаешь лимит блокировки, то и появляется база постоплаты.

 

1 hour ago, Saab95 said:

Это если вы с него долг требовать будете. Яркий пример тут такой - абонент ушел в минус и взял обещанный платеж, пользовался, допустим, 3 дня, после не оплачивал и не пользовался. Но по факту он услугу потреблял, а услуга помесячная, значит должен уже=) И вот если провайдер на это глаза закрывает и списывает эти 3 дня, то и проблем никаких.

Риск "невозврата" долга за обещанный платеж в обмен на экскоммуникацию клиента, проживающего по фиксированному адресу адресу - пренебрежительно мизерная утрата, что бы о ней напрягаться. :) Ежели клиент извернется, и подошлет тёщу вместо себя, чтобы восстановить  услугу, то оплата нового подключения (нового лица) будет заметно больше, нежели неоплаченные пару дней обещанного платежа.

[alibek]

Как сделано у нас.

У расчетного периода есть три характеристики:

• период: сутки, неделя, месяц, квартал, код
• длительность периода (целое число)
• расчетное число (необязательное, целое число)

Это позволяет задать практически любой мысленный расчетный период. Например период сутки с длительностью 1 — это посуточные тарифы. Период месяц с длительностью 1 — это помесячные тарифы. А период месяц с длительностью 1 и расчетным числом 1 — 1 число каждого месяца.

 

Также задается тип начислений — предоплата, постоплата и ежедневное списание.

 

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

У нас препейд, при наступлении расчетного периода производится попытка списания средств с лицевого счета за подключенные услуги.

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

Если попытка неуспешная, то баланс не уменьшается (сумма начислений не списывается), но и услуга не оказывается.

Задолженность в такой схеме невозможна в принципе. Вернее она может возникнуть только при непогашенном обещанном платеже.

[NewUse]

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

[vop]

1 hour ago, alibek said:

У нас препейд, при наступлении расчетного периода производится попытка списания средств с лицевого счета за подключенные услуги.

 

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

 

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

 

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

[Saab95]

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

Если попытка неуспешная, то баланс не уменьшается (сумма начислений не списывается), но и услуга не оказывается.

А как это реализуется? Ведь с минусом все просто - нет денег нет и услуги. А тут получается допустим тариф 1000, у абонента на счету 100. В простой схеме после списания стал долг -900 все понятно, биллинг видит что сумма меньше 1 и блокирует доступ.

 

Ваш случай, на счету 100, тариф 1000 - списания нет. На счету по прежнему 100. Следовательно нужен какой-то дополнительный классификатор, который указывает включена ли услуга, или нет. То есть усложнение логики работы.

[alibek]

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

А как это реализуется? Ведь с минусом все просто - нет денег нет и услуги. А тут получается допустим тариф 1000, у абонента на счету 100. В простой схеме после списания стал долг -900 все понятно, биллинг видит что сумма меньше 1 и блокирует доступ.

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

У счета есть атрибут "Текущий баланс" и "Порог отключения", порог отключения по умолчанию равен 0 (если он положительный, то определяет сумму блокировки, если отрицательный, то означает кредит, если отрицательный со сроком действия, это обещанный платеж).

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

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

Если эта сумма меньше чем баланс-порог, значит средств недостаточно — услуга переводится в статус "Отключено", дата расчета не меняется.

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

Другими словами — если у услуги дата расчета больше текущей — значит услуга на текущий момент оплачена. Если дата расчета меньше текущей — значит услуга не оплачена.

 

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

Следовательно нужен какой-то дополнительный классификатор, который указывает включена ли услуга, или нет.

Не нужен. Достаточно атрибута "Дата расчета".

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

[Saab95]

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

[vop]

On 10/15/2018 at 7:41 PM, alibek said:

[....]
Другими словами — если у услуги дата расчета больше текущей — значит услуга на текущий момент оплачена. Если дата расчета меньше текущей — значит услуга не оплачена.

 

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

 

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

 

Ну это - не так принципиально. Вам удобно, значит все хорошо. :)

[alibek]

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

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

 

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

По сути - она не нужна, ибо для принятия решения достаточно других данных

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