BiTel

Скрипты в периодических процессах сложнее и зависят от большего числа API. И точно так же зависят от изменений в других местах биллинга. А в силу большей сложности чинить это будет еще гемморойнее. Когда для контроля сущности "балланс" достаточно одного события "балланс изменился", что позволит элементарно ловить ситуации "промаха".

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

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

Очень хочеться найти правильную "демаркационную" линию. Иначе получится дебетный режим, которым могут пользоваться далеко не все.
Что делать с абонентом, который каждый час бегает к платежному терминалу и платит по 10 рублей - например, мы разберемся самостоятельно.


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

смена статуса догвора меняет статус шлюза ..

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

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

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

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

Я не про то. Я про лишний шаг в алгоритме .
Приход платежа:
1.Начислить деньги
2. Сделать все что нужно - проверить баланс и если он больше лимита, то сменить статусы, считать абонку и т.п . Если баланс меньше лимита(платежа недостаточно), то ничего не делать .. вы же как-то усложнили

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

А может модуль абонплат может считать "виртуально"? Получить на вход договор, месяц, а на выход дать соответсвующую сумму, но баланс договора при этом не менять?

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

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

Именно так.

это скользская тема с откатом абонок до положительного баланса
т.е. допустим на балансе на 00:00 5 рублей, если снять абонку станет минус, что типа не правильно, но при этом договор и так и так должен заблокироваться - с какого числа ? с текущего ?
и еще, абонок может быть много и разных, откатывать все услуги модуля NPAY тоже не правильно

согласен ..

А в вашем алгоритме не совем понятно . допустим у него вначале дня (00:00 ) 5 рублей ..абонка 50 рублей в день. мы снимаем ему абонку, становится -45 . Со следующего дня статус ставим заблокирован . и клиент в минусе . Я правильно понимаю ?

Если в начале дня -45, то статус блокируется этим днем. Тоже минус останется после переначисления?

В алгоритме jimson-а блокировать нужно следующим днем . Так написано у него в 1-ом пункте. Я вот это и пытаюсь понять

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

вариант 1 -- вечер, зажглись фонари, юзер лезетв контанкт.ру искать развлечение на вечер, деньги заканчиваются, доступ в инет блокируется, баланс договора -Х копеек, договор блокируется с завтрашнего дня, что означает что завтра абонка уже не спишется и минус не увеличится

вариант 2 -- 00:00, юзер спит, на балансе +1 копейка, 00:01 пересчет абонок, договор блокируется с минус 100 рублей, вроде как не правильно, юзер не работал в этот день, полночь, но в чем разница с вариантом 1 учитывая что в BGB идеалогически периоды действия услуг с точностью до суток ?

воротить костыли для ситуации списания абонки в начале суток ? типа если наработки по услугам других модулей нулевая, и денег не хватает на списание абонки то блокировать договор ?
тогда возникает необходимость в изоленте
1) как разблокировать по простому договор при условии что баланс в этом случае положительный, а разблокировка только по платежу не есть правильно
2) что если абонок много и разных, а денег нехватает "чуть-чуть"
3) как посчитать наработку по другим модулям на момент 00:01 если в это время имеется активная VPN/VoIP/etc сессия ?

беру таймаут для подумать

По-моему, схема, предложенная Jimson-ом, отличная:



Только зачем запускать задачу раз в час? Нужно запускать её в конце дня. Максимум, что может случиться плохого - клиент потеряет один день (услуги отрубятся при снятии абонентки в начале дня или в середине, а статус будет активен до следующего).

Мы пытались ввести именно такую схему в августе, столкнулись с двумя проблемами:

1. Нужно сперва вычистить все абонплаты с помесячным снятием.

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

"Баланс не станет больше лимита" - ещё как станет. На собственной шкуре убедились.

2.(оффтоп) Переопределение будущих статусов договоров. Это отдельная проблема, но тут мы начинаем интенсивно дергать статусы и она проявляется как никогда. Сейчас в бг при задании статуса все установки статуса будущим числом просто затираются. У нас есть два случая установки статуса будущим числом:
а) Приостановление услуг по письму клиента. Клиент просит в определенный период приостановить ему предоставление всех услуг и начисление абонплат. Самый простой способ сделать это - проставить требуемым периодом статус "приостановлен". Но после этого мы не может устанавливать статус договора с открытым периодом - будущий статус будет затерт. Особенно проблемотично, когда нужно выставить статус для супердоговора - она затирает все будущие статусы на субдоговорах.
б) Временное включение закрытого за неоплату клиента. В конце месяца выставляется статус "закрыт" всем кредитовым клиентам не оплатившим предыдущий. После этого некоторые присылают гарантийные письма и их открывают, скажем, на 3 дня - статус "закрыт" сдвигается на будущее. Дальше происходит то, о чем писал коллега focus - в эти 3 дня приходит платеж, а будущий статус "закрыт" остается и клиент будет закрыт несмотря на положительный баланс.
Интересно было бы услышать, у кого ещё есть подобные задачи, связанные с установкой статусов будущим числом.

Т.е. в случае а) нас не устраивает затирание статусов, а в случае б) его как раз не хватает.
Вижу 2 решения проблемы:
- Поправить стандартную обработку прихода платежа на кредитовый договор, чтобы проверялся не только текущий статус, но и будущие. Сделать стандартный механизм приостановления договора на другом уровне логики, чем статусы - дабы его можно было задать и снять только руками. Вообще говоря, это отдельная проблема, не имеющая прямого отношения к топику. Хотелось бы узнать, как это происходит в BGB у других организаций.
- Сделать отдельную табличку для будущих статусов, аналогично заданиям на возвращение лимита. Т.е. при установке статуса <= текущего числа он просто применяется, а для будущего - ставится в план. Аналогично заданиям лимитов, можно удалять запланированные статусы руками. Затем пользователь при необходимости пишет скрипт на удаление из плана установки статусов всех статусов "закрыт" при приходе платежа. Возможно бред, т.к. придумал это, пока писал..

Баланс не станет больше (лимита + требуемое_количество_денег для_активации)

Мм, а это откуда?

Это риторический вопрос?

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

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

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

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

Это, что касается конкретно нас и наших потребностей.

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

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

Расчет же "планируемой наработки" это вообще не задача "дебетной схемы". Это задача расчета "рекомендуемой суммы авансового платежа", что бы абоненту меньше раз бегать - доплачивать. То, что расчет "рекомендуемой суммы" важен при дебетной схеме - согласен. Но в дебетном алгоритме подобной "аналитике" не место.

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

Т.е уход в минус при снятии абонки вас устраивает ? в его алгоритме уход происиходит.. Т.е на одну абонку мы можем уходить в минус ?
А, например, vdd это не устраивает

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

Договор не активируется с 2 копейками. По приходу платежа договор активируется только если достаточно средств для активации. Если надо 50р, а на счету 1 копейка, то платеж еще на 1 копейку не активирует договор. То, что договор будет на секунду активирован для временного начисления баланса- это нигде не будет зафиксировано, так как БГБилинг оперирует сутками. Временного начисления балланса можно было бы вообще избежать, если бы NPAY предоставлял API "виртуального начисления".

В БГБилинге активирование по разным событиям производится, как "нативным" биллингом, так и пользовательскими скриптами. Вы же, вроде, один из авторов навороченных скриптов?
В любом случае наш алгоритм эти активации не отменяет. Мы рассматриваем отключение по исчерпанию лимита и подключение по платежу, как наиболее распространенные и нужные немедленно. Как use cases, которые должны быть реализованы в первую очередь и без них вообще не будет никакой дебетной схемы. Обещанный платеж уже как-то обрабатывается биллингом - предложенный алгоритм это никак не отменяет, потому как не требует никаких переделок от модулей биллинга.

Изменение тарифа - серезная операция в БГБ, она и так не тривиальна и будет не тривиальна и в дебете. Опять таки наш алгоритм оставляет сложность смены тарифа посреди месяца такой, как она уже есть в БГБ.

Вообще-то если уход в минус при снятии абонки устраивает, то зачем что-то менять? Оно и сейчас так работает в "дебетном" режиме:
1. Абонка снялась.
2. Баланс ушел в минус. (Конечно же, исчерпался лимит. Но это не принципиально в данном случае)
3. Шлюз закрылся
4. Через две недели Абонент обнаружил, что у него нет интернета. Почему через две недели, мы не знаем. Может наконец-то пересмотрел все фильмы, которые накачал в прошлом месяце, может молочная кислота в мышцах руки наконец-то рассосалась. Может еще что-то. Не важно, мы доступ в интернет продаем, а не тотальным контролем сознания занимаемся.
5. Еще через день Абонент заплатил пол-абонплаты. Почему только половину? Потому что он умеет читать и настолько хорошо, что сумел прочитать "Правила оказания услуг связи..." и вычитал там что Оператор не имеет права брать деньги за непредоставленные услуги.
6. Деньги пришли, но ничего не включилось, так как система хочет вторую половину денег. Она абонку уже начислила за весь месяц, и ей все равно, что услугу то она заблокировала почти одновременно с начислением абонки. Она бы может и рада следовать "Правилам...", но статус договора "Активен", и все.
7. Абонент в бешенстве, потому что он умеет читать и ожидает от Оператора такого же умения. А Оператор то, оказывается, либо читать не умеет, либо забил на требования Закона. У него, видите ли, биллинг сертифицированный так работает, и все.
8. Сотрудник абон.отдела меняет статус договора, так что бы история статусов отражала реальную историю предоставления услуги.
9. Инцидент с конкретным Абонентом исчерпан, но "осадок остался".

я про статус -> активный и говорю
кто вам сказал что приход платежа на 1 копейку не переведет договор в статус активен ? переведет, БГБ сам по себе не будет оценивать сколько необходимо средств на счете что бы хватило на списание абонки, это вы щас делаете в скрипте

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

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

В "дебетном" режиме БГБ не трогает статус договора самостоятельно.


Нас текущая схема "дебета" не устраивает в первую очередь тем, что она не соответствует требованиям Закона. Собственно некорректно называть это "дебетным режимом договора". Это "режим автоматической блокировки сервисных модулей по превышению лимита". Не было бы в документации слова "дебет", наверняка было бы меньше "расстроенных" покупателей БГБ, так как тот "дебет", который есть сейчас в БГБ, подходит только пионерланам, не связанных операторскими лицензиями.
Скрипты же скриптам рознь. Одно дело реализовать собственную бизнес-логику, другое - переписать половину биллинга из-за того, что "чуть-чуть нехватило" функционала, а возможности поправить это "чуть-чуть" почему-то не предоставлено и в такой возможности отказывают даже "за деньги".
На примере:
а) Связь между статусами договора и CRM сугубо проблема покупателя биллинга, потому как это только его бизнес-процесс. Но никакого серьезного напряга самостоятельная реализация этой связи не вызывает, потому что есть нормальные точки выхода из нативного БГБ и входа в него.
Сложность скиптов тут в первую очередь определяется сложностью бизнес-логики.
б)"режим автоматической блокировки сервисных модулей по превышению лимита" вообще не имеет никаких точек выхода. Любой, кто попытается реализовать дебетную схему с ипользованием этого режима обречен на постоянную борьбу, потому как ему придется "гладить против шерсти" почти весь нативный БГБ. Сложность скриптов тут определяется в первую очередь направлением "глажения".


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

P.S. У меня одного такое чувство, что мы уже начали повторятся?

Подключусь к теме, и сразу попрошу прощения, что не изучил толком предыдущие сообщения. Читать их довольно сложно потому как писатели предлагают алгоритм словесный, зачастую с деталями, который надо изучить, понять.
Предложу следующую общую схему, и попрошу краем головы подумать о ней. Если такое предложение уже было, значит я его поддерживаю
Итак:
1.

2. Временные метки модуля абонплат. Можно использоваться имеющуюся систему статусов, или похожую. Ну и соответсвенно ТОЛЬКО при переобсчете их и учитывать

Спасибо за внимание
PS
Такая логика + оповещалка (или автодобавлялка услуг для модуля абонплат), которая будет говорить что для данного договора, для такого тарифа не назначена услуга абонплат (или автоназначение необходимой услуги)... Это все что мне нужно от модуля абонплат. Думаю другим нужно примерно тоже самое.

_________________
интеграция биллинга с 1с http://bgbilling-1c.ru/

2 Akhmat, т.е вы не против ухода в минус абонента . Т.е абонент у вас уходит в минус , и только потом с него перестают списывать абонплату ? так ?