Что бы хотелось увидеть в логике биллинга
1) В случае переодических списаний в начале расчетного периода не списывать абон плату по услугам если баланс меньше суммы списаний по всем услугам. Просто блокируем услуги без изменения баланса.
Например:
Тариф 500р+услуга аренды ip 100р., баланс на первое число 10р. Первого числа блокируем инет и ждем оплаты 591 руб.
2) В случае отрицательного баланса не разблокируем услуги пока не поступит полная сумма по услугам пользователя.
Например:
Тариф 500р. + услуга аренды IP 100р.. Списываем абонентку каждый день, а при наступлении отрицательного баланса блокируем инет и ждем поступления суммы платежей на 600 рублей.
3) Автоматический перерасчет абонентки в случае добровольной блокировки за дни в уже оплаченном расчетном периоде.
Например:
С ЛС первого числа списали абонентку, в середине месяца абонент блокирует ЛС. Далее в не зависимости от продолжительности блокировки абоненту возвращается сумма на ЛС прямо прапорциональная кол-ву времени блокировки за оплаченный период (например в момент разблокировки).
Расширение функционала. Обсудим?
опять мечты.3 пункт - ставим тип блокировки "не списывать абонентскую плату" или "не списывать абонентскую плату, уменьшать предоплаченный трафик"
1-2 пункт
Ставьте списание абонентки втечении всего РП
У всех пользователей ставьте "крыжик" "в заблокированном состоянии не списывать АП"
Что получается:
Абонентка списывается раномерно, пока баланс положительный - все работает. В случае блокировки все услуги блокируются все перодические услуги не списываются. Ближайший аналог логики работы - MTС (сотовая связь).
Все получится как Вы говорили, но без допила билинга, ненужных перерасчётов и плюс к этому абонеты буду приносить абонентку в течении всего РП, а не только 1-го числа.
1-2 пункт
Ставьте списание абонентки втечении всего РП
У всех пользователей ставьте "крыжик" "в заблокированном состоянии не списывать АП"
Что получается:
Абонентка списывается раномерно, пока баланс положительный - все работает. В случае блокировки все услуги блокируются все перодические услуги не списываются. Ближайший аналог логики работы - MTС (сотовая связь).
Все получится как Вы говорили, но без допила билинга, ненужных перерасчётов и плюс к этому абонеты буду приносить абонентку в течении всего РП, а не только 1-го числа.
Ну тогда кто-то из нас явно где-то чего-то недопонимает 
.
Единовременное списание абонентской платы делается только с одной единственной целью - увеличение дохода. Чтобы не вступать в явный конфликт с действующим законодательством обычно делают так:
Абонентскую плату списывают за один раз в конце месяца, если после списания сумма баланса и кредита отрицательная - абонент блокируется периодические услуги продолжают списывается.
Соответвтенно перерасчет за время блокировки в новом РП, в случае поступления платежа в этом РП не производится или вопрос решается индивидуально - например пересчитывается более 1 недели.
Соответственно все неплохо работает до той поры, покуда не попадется ушлый абонент и не подаст на Вас в суд Спорный момент - не перерасчет куска нового РП.
Если вы производите перерасчет - то вы теряете примерно те же деньги что и со списанием АП и блокировкой по ходу РП, за исключением части предыдущего РП. Зато в этом случае к Вам не придраться с точки зрения законодательства (весь предыдущий РП мы исправно предоставляли услуги и выставили счет за весь РП. В новом РП абонент оплачивает только тот период в котором предоставлялись услуги). Галка "в заблокированном состоянии не списывать АП" + списание абонентки в конце месяца Вас спасает полностью.
Если же производится перерасчет за весь период блокировки (что я так понимаю и пребывал главный оратор), то отличий от предложенной мной схемы в предыдущем посте нет.
В чем суть всего этого опуса:
Если Вы не хотите чтобы Ваши действия квалифицировались как мошенничество, то билинг легко настраивается на ту или иную политику списания средств
.Единовременное списание абонентской платы делается только с одной единственной целью - увеличение дохода. Чтобы не вступать в явный конфликт с действующим законодательством обычно делают так:
Абонентскую плату списывают за один раз в конце месяца, если после списания сумма баланса и кредита отрицательная - абонент блокируется периодические услуги продолжают списывается.
Соответвтенно перерасчет за время блокировки в новом РП, в случае поступления платежа в этом РП не производится или вопрос решается индивидуально - например пересчитывается более 1 недели.
Соответственно все неплохо работает до той поры, покуда не попадется ушлый абонент и не подаст на Вас в суд
Спорный момент - не перерасчет куска нового РП.Если вы производите перерасчет - то вы теряете примерно те же деньги что и со списанием АП и блокировкой по ходу РП, за исключением части предыдущего РП. Зато в этом случае к Вам не придраться с точки зрения законодательства (весь предыдущий РП мы исправно предоставляли услуги и выставили счет за весь РП. В новом РП абонент оплачивает только тот период в котором предоставлялись услуги). Галка "в заблокированном состоянии не списывать АП" + списание абонентки в конце месяца Вас спасает полностью.
Если же производится перерасчет за весь период блокировки (что я так понимаю и пребывал главный оратор), то отличий от предложенной мной схемы в предыдущем посте нет.
В чем суть всего этого опуса:
Если Вы не хотите чтобы Ваши действия квалифицировались как мошенничество, то билинг легко настраивается на ту или иную политику списания средств
Данный способ не подоходит хотя бы потому, что есть куча (более 5К) абонентов с действующими ТП, и в этом ТП стоит схема списания абонки отличной от "равными долями в течении расчетного периода".Arti писал(а):3 пункт - ставим тип блокировки "не списывать абонентскую плату" или "не списывать абонентскую плату, уменьшать предоплаченный трафик"
1-2 пункт
Ставьте списание абонентки втечении всего РП
У всех пользователей ставьте "крыжик" "в заблокированном состоянии не списывать АП"
Что получается:
Абонентка списывается раномерно, пока баланс положительный - все работает. В случае блокировки все услуги блокируются все перодические услуги не списываются. Ближайший аналог логики работы - MTС (сотовая связь).
Все получится как Вы говорили, но без допила билинга, ненужных перерасчётов и плюс к этому абонеты буду приносить абонентку в течении всего РП, а не только 1-го числа.
Если научите как изменить схему списания на рабочем ТП.
А то гиморой в виде заведения 2х десятков новых ТП, и перевод на них абонентов в полуручном режиме, это знаете ли, гиморой еще тот.
Было бы неплохо хотя бы добавить возможность изменять типа дефолтной блокировки абонента при уходе в минус.
Дифолтная блокировка как раз и определяется галками "В заблокированном состоянии ...."
Честно говоря не вижу проблемы в смене ТП.
Вариант 1:
Заводим каждому ТП пару и вперед. Смена делается либо руками из админки масово (поиск по ТП ID и установки TP следующего РП), правда к сожалению там нет возможности поиска по критерию "ТП следующего РП", по этому тех кто меняет ТП предварительно выудить из базы запросом:
И вот их придется руками.
Вариант 2:
Непосредственно редактированием базы - правда потребуется перезупксук билинга и пердварительный тест на стенде.
Вариант 3:
через урфаскрипт.
Если Вы создавали ТП в соответствии с документацией (о совместимости ТП) и знаете в каких случаЯХ не подключаются услуги при переводе ТП - проблем быть не должно.
Честно говоря не вижу проблемы в смене ТП.
Вариант 1:
Заводим каждому ТП пару и вперед. Смена делается либо руками из админки масово (поиск по ТП ID и установки TP следующего РП), правда к сожалению там нет возможности поиска по критерию "ТП следующего РП", по этому тех кто меняет ТП предварительно выудить из базы запросом:
Код: Выделить всё
SELECT account_id, tariff_id, next_tariff_id FROM account_tariff_link WHERE tariff_id<>next_tariff_id AND is_deleted=0;
Вариант 2:
Непосредственно редактированием базы - правда потребуется перезупксук билинга и пердварительный тест на стенде.
Вариант 3:
через урфаскрипт.
Если Вы создавали ТП в соответствии с документацией (о совместимости ТП) и знаете в каких случаЯХ не подключаются услуги при переводе ТП - проблем быть не должно.
to Arti
Вы наверное не внимательно читали первый пост или же не очень хорошо разбираетесь в алгоритмах работы биллинга netup.
Перечитайте ещё раз, описанные задачи не решаются действующим функционалом биллинга.
Варианты со списанием абон платы в конце месяца вообще не рассматриваются, абонент не должен уходить в минус (это плохо сказывается на бизнес задачах). Собственно это первая задача из первого поста.
Далее. При плавном списании средств в течении месяца мы имеем проблему не систематических платежей пользователей, грубо говоря есть часть пользователей которая кладет 50 руб 2 раза в месяц и не приносят дохода. Это уже речь о втором пункте, пользователь может платить хоть каждый день (если ему трудно оплатить за целый месяц сразу), но он должен стараться постоянно находиться в положительном балансе.
И по третьему пункту. При плавном списании ни каких проблем с перерасчетом не возникает, но все равно существуют тарифы по которым не представляется возможным списывать абонентку каждый день, это "трафиковые" тарифы (и мы помним, что списание в конце месяца мы не рассматриваем).
Вы наверное не внимательно читали первый пост или же не очень хорошо разбираетесь в алгоритмах работы биллинга netup.
Перечитайте ещё раз, описанные задачи не решаются действующим функционалом биллинга.
Варианты со списанием абон платы в конце месяца вообще не рассматриваются, абонент не должен уходить в минус (это плохо сказывается на бизнес задачах). Собственно это первая задача из первого поста.
Далее. При плавном списании средств в течении месяца мы имеем проблему не систематических платежей пользователей, грубо говоря есть часть пользователей которая кладет 50 руб 2 раза в месяц и не приносят дохода. Это уже речь о втором пункте, пользователь может платить хоть каждый день (если ему трудно оплатить за целый месяц сразу), но он должен стараться постоянно находиться в положительном балансе.
И по третьему пункту. При плавном списании ни каких проблем с перерасчетом не возникает, но все равно существуют тарифы по которым не представляется возможным списывать абонентку каждый день, это "трафиковые" тарифы (и мы помним, что списание в конце месяца мы не рассматриваем).
Изначально речь шла только о периодических услугах.
Второй пункт действительно прочитал невнимательно. Я бы эту политику назвал бы как "мягкий ненавязчивый шантаж" Вобще идея хорошая, и на мой непроффесиональный взгляд выдерживает критику с юридической точки зрения.
Вообще говоря предложенный мной вариант с плавным списанием (повторюсь я говорю только о периодических услугах) расходится с пунктом 2 только в моменте снятия блокировки. Задачу всеже можно решить штатными средствами, хотя и в довольно специфичных условиях:
Вариант 1
Т.к. пункт 2 нарушается в момент поступления платежа - то достаточно сделать собственную утилиту ввода платежей и изменить систему активации карты в пользовательском интерфейсе - добавить туда необходимые проверки и добавление блокировки по необходимости. Остается интеграция с платёжными системами - что с ними делать - не знаю.
Вариант 2
Т.к. все действия по зачислению средств по-умолчанию "дергают" функцию "включить интернет", что соотвественно вызывает событие, по которому возможно запускать пользовательскую программу, то в этой программе можно выполнять необходимые проверки. Более того на изменение типа блокировки тоде можно "подвесить" что-нибудь этакое... Возможно также это решит вопрос с платёжными системами
Если просить добавление функционала...
Просить конкретную логику на мой взгляд бессмысленно - у каждого оператора свои требования. На мой взгляд логичнее и значительно более гибким решением была бы возможность влиять на логику работы функции снятия блокировки.
Второй пункт действительно прочитал невнимательно. Я бы эту политику назвал бы как "мягкий ненавязчивый шантаж"
Вобще идея хорошая, и на мой непроффесиональный взгляд выдерживает критику с юридической точки зрения.Вообще говоря предложенный мной вариант с плавным списанием (повторюсь я говорю только о периодических услугах) расходится с пунктом 2 только в моменте снятия блокировки. Задачу всеже можно решить штатными средствами, хотя и в довольно специфичных условиях:
Вариант 1
Т.к. пункт 2 нарушается в момент поступления платежа - то достаточно сделать собственную утилиту ввода платежей и изменить систему активации карты в пользовательском интерфейсе - добавить туда необходимые проверки и добавление блокировки по необходимости. Остается интеграция с платёжными системами - что с ними делать - не знаю.
Вариант 2
Т.к. все действия по зачислению средств по-умолчанию "дергают" функцию "включить интернет", что соотвественно вызывает событие, по которому возможно запускать пользовательскую программу, то в этой программе можно выполнять необходимые проверки. Более того на изменение типа блокировки тоде можно "подвесить" что-нибудь этакое... Возможно также это решит вопрос с платёжными системами
Если просить добавление функционала...
Просить конкретную логику на мой взгляд бессмысленно - у каждого оператора свои требования. На мой взгляд логичнее и значительно более гибким решением была бы возможность влиять на логику работы функции снятия блокировки.
Тем неменее выше говорилось "описанные задачи не решаются действующим функционалом биллинга".
А насколько это костыль - можно поспорить. Конкретную логику под конкретного оператора врядли кто будет реализовывать в массовом продукте, особенно если вспомнить сколько было замечаний по тарификации...
Чтобы угодить всем, я предполагаю что максимум на что удастся "развести" core, это на запуск пользовательского скрипта ну или вычисление дополнительного выражения вида вида
или более сложного в момент "автоматической" разблокировки при поступлении на счет средств, где n1 и n2 можно задать в конфигурации.
Т.е. решение Вашей проблемы всеравно сведется к запуску пользовательского процесса и, что мало вероятно, обработки его результатов. Вариант с неким "универсальным выражением" на мой взгляд более фантастический, хотя и должен быть относительно легко реализуем, при этом если выбрать по-умолчанию значения n1=1 и n2=0 легко добиться "обратной совместимости" бизнес-логики.
Может у кого есть еще идеи решения задачи.
А насколько это костыль - можно поспорить. Конкретную логику под конкретного оператора врядли кто будет реализовывать в массовом продукте, особенно если вспомнить сколько было замечаний по тарификации...
Чтобы угодить всем, я предполагаю что максимум на что удастся "развести" core, это на запуск пользовательского скрипта ну или вычисление дополнительного выражения вида вида
Код: Выделить всё
n1*(стоимость подключенных периодических услуг) >= n2*(стоимость подключенных периодических услуг)Т.е. решение Вашей проблемы всеравно сведется к запуску пользовательского процесса и, что мало вероятно, обработки его результатов. Вариант с неким "универсальным выражением" на мой взгляд более фантастический, хотя и должен быть относительно легко реализуем, при этом если выбрать по-умолчанию значения n1=1 и n2=0 легко добиться "обратной совместимости" бизнес-логики.
Может у кого есть еще идеи решения задачи.
Я вот одно не понимаю, сейчас можно повесить запуск RFW на кучу разных событий, что мешает вместо Rfw вызывать тот же urfa скрипт и делать с пользователем что угодно ?Arti писал(а):Тем неменее выше говорилось "описанные задачи не решаются действующим функционалом биллинга".
А насколько это костыль - можно поспорить. Конкретную логику под конкретного оператора врядли кто будет реализовывать в массовом продукте, особенно если вспомнить сколько было замечаний по тарификации...
Чтобы угодить всем, я предполагаю что максимум на что удастся "развести" core, это на запуск пользовательского скрипта ну или вычисление дополнительного выражения вида вида
или более сложного в момент "автоматической" разблокировки при поступлении на счет средств, где n1 и n2 можно задать в конфигурации.Код: Выделить всё
n1*(стоимость подключенных периодических услуг) >= n2*(стоимость подключенных периодических услуг)
Т.е. решение Вашей проблемы всеравно сведется к запуску пользовательского процесса и, что мало вероятно, обработки его результатов. Вариант с неким "универсальным выражением" на мой взгляд более фантастический, хотя и должен быть относительно легко реализуем, при этом если выбрать по-умолчанию значения n1=1 и n2=0 легко добиться "обратной совместимости" бизнес-логики.
Может у кого есть еще идеи решения задачи.