На "классических" ТП (расчетный период месяц, АП списывается в начале), часто бывает ситуация, когда при заведении абонента в биллинге к нему привязывается тарифный план с услугами намного раньше, чем абонент начал реально работать. То есть, менеджеры завели абонента в понедельник в 10 утра, к нему поехали монтажники, что-то у них там по дороге сломалось или абонента внезапно не оказалось дома или еще что. И абонент реально вылез в интернет, скажем в четверг в 10 утра. Получается, что абонплата с него снялась в размере трех дней больше, чем он реально должен. Вариант: менеджерам-заводильщикам не прицеплять услугу АП сразу, при создании абонента, а включать ее руками потом, после его успешного выхода в онлайн. Доверять в этом отношении девочкам очень сложно, потому что голова дырявая и случается так, что АП они подключить забывают. Предлагаю такое решение:
при создании абонента АП не подключается, но каждый час по крону работает спец-скрипт, который ищет абонентов с неподключенной абонплатой и смотрит, не выходили ли они в интернет. Если да, то скрипт подключает услугу, биллинг снимает АП почти в тоже-самое время, когда абонент реально вышел в онлайн. (максимму с разницей в час)
p.s. что-то аттач файлов не работает, а то бы прицепил наш скрипт в качестве примера.
Списывание абонплаты до начала работы абонента
Скрипт выложил сюда: http://pastebin.com/FUaqWE7Q
база у нас в Pg, радиус внешний. Информацию с записи Start кладет в таблицу log_connect, собственно из нее же идет проверка, выходил ли пользователь онлайн (строки скрипта 31-37)
Скрипт писал не я, но на вопросы ответить думаю смогу.
база у нас в Pg, радиус внешний. Информацию с записи Start кладет в таблицу log_connect, собственно из нее же идет проверка, выходил ли пользователь онлайн (строки скрипта 31-37)
Скрипт писал не я, но на вопросы ответить думаю смогу.
Прошу прощения, недосмотрел... однако правильней будет так с учетомnikl писал(а):Скрипт не молотит всех пользователей, а только тех, у кого HAVING COUNT(s.service_id) = 1Pulse писал(а):и сколько времени скрипт молотит запросы по каждому юзеру в цикле?
Их обычно не больше десятка, потому что после первого выхода в интернет они из списка пропадают.
того, что может быть несколько аккаунтов у юзера.
Код: Выделить всё
SELECT u.login, u.id
FROM service_links as s, users as u, users_accounts ua
WHERE s.is_deleted = 0 AND u.id = ua.uid
and ua.account_id=s.account_id
GROUP BY s.account_id, u.id, login HAVING count(s.service_id) = 1
ORDER BY s.account_idдополнительная проблема решается тут viewtopic.php?t=6912dk писал(а):Как вариант, абонплату можно списывать не периодической услугой, а разовой. Это дополнительно решает проблему "меня полгода не было, а абонплата списывалась", справиться с которой самостоятельно UTM не в состоянии.
У наших абонентов всегда одио аккаунт, исторически сложилось..Pulse писал(а):Прошу прощения, недосмотрел... однако правильней будет так с учетомnikl писал(а):Скрипт не молотит всех пользователей, а только тех, у кого HAVING COUNT(s.service_id) = 1Pulse писал(а):и сколько времени скрипт молотит запросы по каждому юзеру в цикле?
Их обычно не больше десятка, потому что после первого выхода в интернет они из списка пропадают.
того, что может быть несколько аккаунтов у юзера.
До кучи ещё следует заметить, что у нас, например, есть тарифы, в которых 1 услуга, или тарифы, в которых 4 услуги. но в целом подход интересный.Код: Выделить всё
SELECT u.login, u.id FROM service_links as s, users as u, users_accounts ua WHERE s.is_deleted = 0 AND u.id = ua.uid and ua.account_id=s.account_id GROUP BY s.account_id, u.id, login HAVING count(s.service_id) = 1 ORDER BY s.account_id
а по поводу услуги - можно добавить проверку на тип (2)
Решается, да не так. Впрочем это политика списания абонплаты конкретной компании, полностью снимать а/п или частичноnikl писал(а):дополнительная проблема решается тут viewtopic.php?t=6912dk писал(а):Как вариант, абонплату можно списывать не периодической услугой, а разовой. Это дополнительно решает проблему "меня полгода не было, а абонплата списывалась", справиться с которой самостоятельно UTM не в состоянии.
