BiTel

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

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

В моем понимании задача формулируется следующим образом:
модули типа npay, rscm и тп должны производить списание с двойной тарификацией
1) таррифицируем услугу, вычисляем дельту между суммой которую насчитали и суммой которая уже списана
2) генерим событие, скрипт-обработчик которого должен иметь доступ к вычисленной дельте
3) таррифицируем услугу заново и записываем изменения в базу

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

это сложно реализовать ?

http://wiki.bgbilling.ru/index.php/%D0% ... 0%B0%D1%85

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

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

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

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

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

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



В этом сктипте я написал именно то что необходимо мне.

Ув. Jimson а в чем проблема? Почему вы не можете сам реализовать то что вам требуется?

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

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

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

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

О! Нашел четкое описание позиции разработчиков:


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

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

Разработчики же создали модуль NPAY для периодического начисления наработки. Без исключений - нет у тебя периодичности, то есть зависит факт начисления от других событий, чем таймер - этот модуль не для тебя. И все было бы как у математиков на воздушном шаре, если бы не одно обстоятельство - сердце то не каменное у людей - взяли и добавили учет статуса договора при начислении абонплаты. Для телефонистов это стало серьезным подспорьем, так как расчеты за телефонию регламентированы законом и БГБиллинг начал сам, без докрутки, следовать этому закону. А интернетчикам стало обидно - для юрлиц все работает нормально, а для физиков нужно делать скрипты, подменяющие пол биллинга.

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

обеими руками "ЗА!", а там ведь надо то сделать что-то в духе:


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

я пока не вижу универсального алгоритма . например как учитывать переобсчеты , из которых задним числом вдруг изменяется входящий остаток..Вы все мыслите в real-time . Давайте заблокируем пользователя если у него денег не счету нет . и разблокируем если есть, все просто . А ведь с точность до дня в биллинге потом сказать нельзя сколько денег у него было на счету в конкретный день месяца , баланс хранится одной цифрой за весь месяц и постоянно меняется .. Потом задним числом как вы будите ему объяснять почему вы его заблокировали , а потом разблокировали .

В wiki выложен пример для ежедневного списания. Т.е 5-го числа его заблокировали , а 10- го разблокировали . Клиент приходит и говорит - почему, какой у меня был баланс 5-го числа , и какой стал 10-го ..а вы говорите не знаем , т.к денежная наработка хранится за весь месяц целиком .

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

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

Теперь именно о дебетном режиме: проблема "баланс 0 - шлюз закрылся - через 2 дня нашли платеж - баланс изменился - шлюз открылся - теперь непонятно почему он закрылся два дня назад" не зависит от того, пытались ли мы применить схему "нет денег - нет услуги - нет снятия абонки" или пользуем систему как есть в ее дебетном режиме.
Проблема вернуть абоненту два дня (и не забыть об этом при пересчете), которые он не работал из-за непришедшего вовремя платежа возникает исключительно из-за автоматики "баланс 0 - шлюз закрылся". В свою очередь потерянный платеж порождает проблему даты платежа в биллинге: "дата принятия платежной системой или дата, проставленная в ведомости банка или дата внесения платежа в биллинг". Кстати, это отдельная больная тема - какой датой вносить платеж в биллинг. Но это я отвлекся.
Если коротко: проблема вызвана способностью БГБиллинга изменять историческую реальность в сочетании с неспособностью изменять реальность реальную.

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

Отсюда вопросы:
1) Возможно ли сохранять историю работы сервисных модулей (вкл/выкл доступа) аналогично истории статуса договора?
2) Если первый пункт возможен, возможно ли учитывать эту историю при начислении абонплат аналогично истории статуса?

Решили однажды сделать набор скриптов для ежедневного отключения (статус:=закрыт) тех, у кого баланс становится < лимита. Столкнулись с кучей нюансов:
- у таких клиентов не должно быть абонплат с помесячным режимом снятия, только подневной. Ну, это очевидно, если подумать
- при установке статуса нужно учитывать будущие статусы и статусы субдоговоров.
Например: клиент присылает письмо на приостановление услуг в будущем с числа x по y - ему менеджер выставляет на договоре статус "приостановлен". После этого уже нельзя без оглядки менять статус скриптами и руками. А если приостанавливается только один субдоговор, то трогать супердоговор вообще опасно.

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

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

В соответствии с документацией http://www.bgbilling.ru/v4.6/doc/ch01s18s09.html

Решил проверить это!
1. Статус активен с 10.11.2009 - 14.11.2009
2. Статус отключен с 15.11.2009 - 15.11.2009
3. Статус активен с 16.11.2009 - 24.11.2009 (в этот период оплачиваем)
4. Статус отключен с 25.11.2009 - ......


Далее картинка с приходами денег

Что написано в документации - не выполняется. Самостоятельно система по приходу платежа не меняет статус!
Статус по прежнему остается Активен на период обещанного платежа
Отключен после истечении периода обещанного платежа.
Разработчики пролейте свет на этот момент!

Не очевидно. Если помесячное снятие с учетом периода, то после переначисления такая абон. плата скорректируется согласно периоду активности договора.

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

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


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

Рассмотрим вопрос более полно. Раз мы посреди месяца отключаем дебетного клиента с помесячным снятием абонки по исчерпанию лимита, то скорее всего что-то тут не так.
Поэтому для начала смотрим с другого бока. В ночь с последнего дня месяца на 1 число следующего мы либо снимаем полную сумму за месяц, либо не снимаем, потому что денег не хватает. Во втором случае доступ к услуге блокируется и, согласно руководящим правительственным документам, мы должны прекратить начисление за блокированную услугу. Самый простой способ в БГБ для этого - поменять статус договора на неактивный.
Затем абонент все же платит деньги (раз снятие помесячное, то он должен принести денег, достаточных для работы весь остаток месяца), и мы активируем договор и разблокируем услугу. После переначисления абонка с помесячным снятием будет рассчитана верно.
Вернемся к первому случаю. Раз мы посреди месяца отключаем дебетного клиента с помесячным снятием абонки по исчерпанию лимита, то это может означать, что
1) мы имеем некий тариф с абонкой и наработкой, зависящей от объема услуги (например, дебетный помегабайтный тариф, с предоплаченным трафиком)
2) на начало месяца денег было достаточно для активации услуги на весь месяц, но абонент вышел за границу предоплаченного трафика и оставшиеся, после снятия месячной абонки, деньги кончились.
Мы блокируем услугу (хотя это очень спорно для приведенного тарифа, и может закончится скандалом с применением РосСвязьНадзора).
После пересчета начисленная абонка корректируется и на балансе абонента появляются положительные деньги. Ну и что?
Тех денег, которые появятся на балансе, не достаточно, что бы с учетом уже имеющейся наработки по объему, включить абонента.

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


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

По поводу классического дебета. Вся проблема в том, что в сотовой связи возможно все списания разбить на атомарные операции (звонки). И есть баланс до операции и после операции. Соответственно нет денег - операция запрещена.

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

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

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

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


Баланс на начало месяца и баланс на сегодня. Нам, например, этого достаточно. Баланс на начало месяца нам нужен в дебете только в двух случаях - когда в ночь с "31 на 1" принимается решение - активировать или нет услугу и для формирования бухгалтерской отчетности.
Баланс "на сегодня" нужен в дебете, при тарифах допускающих снятие денег сверх абонентской платы. По балансу "на сегодня" происходит блокировка доступа к услуге. Собственно с "31 на 1" доступ регулируется тем же балансом "на сегодня". Так что баланс на начало месяца это нам для отчетности, а для БГБ это возможность пересчитывать только один месяц, не лазя в данные за предыдущий месяц.
Мы видим только одну проблему - в "дебетном режиме БГБ" сервисный модуль блокирует услугу по исчерпанию денег, но история таких блокировок не учитывается при расчете абон. платы. Учитывалась бы история блокировок аналогично истории статуса - абонентская плата насчитывалась бы корректно.

я не понял в чем разница
у них звонок, в нашем случае - час, где проблема то ? и каком переначислении идет речь и зачем дробить VPN сессию если при ее открытии уже будет взведен таймер по истечении которого NAS прервет эту сессию ?
да, могут быть еще кучи услуг которые будут паралельно съедать деньги этого договора и в результате рассматриваемая VPN сессия уйдет в минус, ну и что с того, это в любом случае лучше чем полное отсутсвие функционала

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

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

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

Подумал. Впринципе, перерасчёт вообще не должен, как я понимаю, статусы менять. Т.к. ежели не было у него услуги - то уж и не было..



Да мы не против, просто скрипты пока лучше чем ничего. А кто-нибудь может функционал описать требуемый?

1) Сделать задачу в планировщике, которая в начале суток после снятия абонентской платы проверяет балансы и переводит в статус "Заблокирован" если у человека денег нет. Заблокирован с этой даты.
2) По приходу платежа разблокировать заблокированный статус если баланс превысил лимит.

Какие-то ещё нюансы есть? Всё это только для дебетовых договоров как я понимаю, должно работать.

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

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

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

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

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

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

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

Итого, задача в планировщике должна:
1) Поменять статус договора на "Отключен из-за недостатка средств" со следующего дня, если баланс стал меньше лимита
2) Поменять статус обратно если статус договора "Отключен из-за недостатка средств" и баланс больше лимита

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



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

Наш алгоритм (как он бы был реализован прямо сейчас, не дожидаясь никакой поддержки в самом билинге, кроме одного события) вот такой:
Договор находится в режиме биллинга "дебет"
1. В обработчике события "закрытие шлюза по исчерпанию лимита":
1.1 Сменить статус договора с момента закрытия на "приостановлен"
1.2 Вызвать переначисление абонентской платы
С этого момента получаем следующее состояние договора:
Шлюз закрыт. Абонплаты начисляются согласно правилам для статуса "приостановлен". Замечу, что любые абонплаты, даже месячные пропорционально периоду.
2. В обработчике платежа
2.1 Сменить статус договора эффективной датой платежа на "активен" (шлюз вроде не разблокируется, так как управляется лимитом, а не статусом договора, но даже если и разблокируется, то ничего старшного, см.)
2.2 Начислить деньги (баланс переобсчитаются)
2.3 Проверить баланс.
2.3.1 Если меньше нуля (то есть денег не хватает для активации услуги до конца месяца)- вернуть статус обратно в "приостановлен" и вызвать переобсчет.
Иначе открыть шлюзы.

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

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

Я писал про нашу ситуацию. Замените "шлюзы" на "сервисный модуль".

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

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

Это фактичкси тоже самое что и тут :
http://wiki.bgbilling.ru/index.php/%D0% ... 0%B0%D1%85

есть ньюнс при такой схеме . Нельзя снимать абонку только в начале суток . нужно доплнительно снимать либо в конец суток либо по событию прихода платежа . Один из наших клиентов на это наткнулся при использовании этого скрипта. вот цитата из helpdesk(Абонка 50 рублей в день):

Вопрос - когда снимать абонку при вашей схеме ? тоже каждый час ?

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