Логика списаний в UTM 5.3-002-update9

cyb3r_ang31

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

Есть новый абонент, при заведении в биллинге ему создается ЛС, и сразу этот ЛС переводится в Административную блокировку.

В последующем к ЛС привязывается Тариф с сервисными связками,
в сервисных связках действуют следующие политики списания:

Списание только при системной блокировке:

Не списывать при любой блокировке:

В дальнейшем после добавления всех необходимых данных через некоторое время абонента подключают и с ЛС снимают Административную блокировку.

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

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

Вопрос: Почему? Ведь в политике списания четко сказано, не списывать абонентскую плату при Административной блокировке.
Не понимаю логики этого списания.
Как сделать так, что с абонента начинают списываться средства только в момент его непосредственного подключения?[/img]

serjk · Сообщение **serjk** » Чт ноя 27, 2014 11:31

Проверим этот случай, отпишу.

banec · Сообщение **banec** » Чт ноя 27, 2014 14:43

+1 тоже самое up9 (обновлялись в начале месяца - правда со старой 008)
сразу не обратили внимание по началу месяца - суммы маленькие.

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

kamae1ka

banec писал(а): ЗЫ выкручиваемся ставя безлимитный режим - снимая админскую блокировку и только потом убираем безлимит

у меня это уже в обыденность вошло :lol:

Magnum72

serjk писал(а):Проверим этот случай, отпишу.

Проверили ? Когда ждать патч?

serjk · Сообщение **serjk** » Чт ноя 27, 2014 18:51

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

banec · Сообщение **banec** » Пт ноя 28, 2014 00:27

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

cyb3r_ang31

banec писал(а):у нас заблокированные принудительно абоненты и снятие с них админской блокировки тоже снимается!!! (т.е. услуги уже давно заведены и по ним уже были списания раньше,
причем они были заблокированы ещё на старом биллинге 008 до апдейта на 5.3)

Да, подтверждаю, тоже такая же ситуация происходит.

Будем с нетерпением ждать нового апдейта.

banec · Сообщение **banec** » Вт дек 30, 2014 10:04

up12
что-то всё ровно косяк со списанием !!!!

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

т.е. в любом случае абонент платит за полный месяц!!!

Magnum72

Походу та же проблема, кто нибудь решил ее ?

banec · Сообщение **banec** » Вт фев 17, 2015 09:29

ААААА
А то такое ощущение было что сам собой тут веду беседы.

Надеюсь уже к Магнуму прислушаетесь.

Magnum72

Нашел кажись где собака порылась (пока это только догадки я ничего не проверял и не тестировал):

Касается только некоторых абонентов:
Если абонент был заблокирован еще в старой версии биллинга, то в таблице periodic_service_links поля: `start_block_unabon`, `start_block_unprepay`, `start_block_untel` могут содержать 0

Соответственно если в новом биллинге разблокировать счет, то биллинг посчитает что блокировка стоит без перерасчета и спишет полную стоимость.

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

banec · Сообщение **banec** » Ср фев 18, 2015 08:16

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

Magnum72

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

Вот запрос для вывода неудачников:

Код: Выделить всё

SELECT
	us.passport,
	us.basic_account,
	sl.id
FROM
	UTM5.periodic_service_links psl,
	UTM5.service_links sl,
	UTM5.accounts ac,
	UTM5.users us,
	UTM5.blocks_info bi
WHERE
	psl.id = sl.id
	AND ac.block_id != 0
	AND psl.start_block_unabon = '0'
	AND sl.account_id = ac.id
	AND us.basic_account = ac.id
	AND ac.block_id = bi.id
	AND bi.block_type IN &#40;2, 3&#41;
	AND us.is_deleted = 0
	AND ac.is_deleted = 0
	AND sl.is_deleted = 0
	AND psl.is_deleted = 0;

Magnum72

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

Код: Выделить всё

UPDATE
	UTM5.periodic_service_links psl,
	UTM5.service_links sl,
	UTM5.accounts ac,
	UTM5.users us,
	UTM5.blocks_info bi,
	UTM5.discount_periods dp
SET
	psl.start_block_unabon = GREATEST&#40;psl.start_date, bi.start_date, dp.start_date&#41;
WHERE
	psl.id = sl.id
	AND sl.account_id = ac.id
	AND us.basic_account = ac.id
	AND ac.block_id = bi.id
	AND dp.id = psl.discount_period_id
	AND psl.start_block_unabon = 0
	AND bi.block_type = 2
	AND us.is_deleted = 0
	AND ac.is_deleted = 0
	AND sl.is_deleted = 0
	AND psl.is_deleted = 0;