Користувальницькькі налаштування

Налаштування сайту


Сайдбар

Розділи

Загальний опис
Історія змін
Рекомендації до оновлення
Плани на майбутнє
Відомі проблеми
Онлайн демо
Відео
Допомога проекту
Люди
Трохи про безпеку

FAQ



Редагувати сайдбар

doomsdaytariffs

Тарифи судного дня

Дозволяють:

  • Гнучко керувати життєвим циклом тарифів
  • Автоматично планувати міграцію користувачів між тарифами
  • Блокувати випадкові зміни тарифів користувачам для яких вже запланована зміна
  • Опціонально нараховувати абонплату за поточним тарифом
  • Опціонально встановлювати кредит користувачам, щоб вони продовжували роботу
  • Життєвий цикл тарифів може відбуватися в місяцях або днях
  • Виправляти персоналу свої помилки протягом якогось часу
  • Переглядати звіт про те, коли і з якого приводу це все відбувалося

Занадто складно, можна простіше?

Окей. Тарифи судного дня дають змогу вам нативно робити тарифи на кшталт таких:

Так зрозуміліше? Тоді поїхали!

Ввімкнення

Важливо! для роботи модуля обов'язково потрібен налаштований і працюючий Живи з цим.

Для нормальної роботи тарифів судного дня потрібні дві опції alter.ini:

DEALWITHIT_ENABLED=1
DDT_ENABLED=1

а також два відповідних виклики Remote API

10 2 * * *    /bin/ubapi "dealwithit"
42 * * * *   /bin/ubapi "ddt"

Налаштування

Уся конфігурація надалі здійснюються за допомогою такого модулю

Пояснимо на нетривіальному прикладі. У вас є тариф Fire-5 вартістю 100 грошей. Ви хочете, щоб він був доступний користувачам терміном на три місяці, після чого вони повинні бути переведені на тариф Unlim-5 вартістю 150 грошей. Ось така ось чудова акція з метою підвищення “лояльності” вашої абонбази.

Також ви хочете, щоб під час підключення цього тарифу, якщо поточне число місяця менше 25-го, було нараховано абонплату (після 25-го не жлобимось і вважаємо для себе, що 5 днів інтернету не варті 100 грошей) відповідно до тарифу Fire-5 у розмірі 100 грошей, і, в разі, якщо в абонента після цього не вистачатиме грошей для продовження роботи, йому встановили кредит до кінця місяця на суму, якої не вистачає (ну, припустімо, це новий абонент, і він повинен оплатити послугу до кінця місяця).

Складно, правда? Але цілком можливо, що вам саме хочеться це робити й автоматизувати. Ось як це має виглядати:

І власне результат:

Слід також зауважити, що чекбокс “Враховувати поточний період” впливає на те, чи буде розраховуватися дата зміни тарифу на тариф, який “Перевести на тариф після закінчення періодів”, зважаючи на “від поточного періоду” (у цьому разі місяця), чи вже починаючи з наступного, а в поточному періоді, вважатимемо, що користувача нібито “не було”.

Далі під час установлення одного з тарифів, описаних у довіднику “Тарифи судного дня”, буде показано повідомлення, що для цього користувача буде заплановано зміну тарифного плану відповідно до призначеного тарифу судного дня.

Що дає можливість, у разі “якщо користувач передумав” або “оператор помилився” швиденько змінити своє рішення і змінити вибір тарифу на необхідний. По закінченню якогось часу, залежно від періодичності виклику ddt з RemoteAPI, для користувача буде заплановано перехід на необхідний тариф, і операції ручної зміни тарифу будуть заблоковані. Планування завдання на зміну тарифу відбуватиметься в разі тільки якщо для користувача не було раніше заплановано жодного завдання на зміну тарифу. Можливо у вас вже є користувачі, яким ви вже щось запланували раніше в цьому контексті, і тарифи судного дня будуть їх просто ігнорувати.

Що буде також відображено у відповідних звітах за “Тарифами судного дня” і “Живи з цим”

Варто зауважити, що у звіті “Історія” тарифів судного дня, поле “Дата” позначає дату і час, коли користувач був “помічений” на одному з тарифів судного дня, а “Дата закінчення” позначає дату, коли буде проведена заміна тарифу. Для тарифів судного дня з періодичністю “Місяць” це буде завжди останній день необхідного місяця, для того, щоб Stargazer зміг нормально нарахувати абонплату вже за новим тарифом. Для тарифів з періодичністю “День” дату зміни тарифного плану буде встановлено на конкретний день місяця в майбутньому, порахованим за принципом “поточна дата/завтрашній день + тривалість*днів”.

Результат чого можна побачити у звіті за завданнями “Живи з цим”

З огляду на попередню конфігурацію нашого тарифу судного дня у вигляді Fire-5, у абонента на рахунку було 92 грошей, і йому було нараховано 100 грошей за поточний період використання тарифу Fire-5.

З огляду на те, що на його рахунку після цього утворилася заборгованість у розмірі -8 грошей, йому автоматично було встановлено кредитний ліміт у 8 грошей до кінця поточного місяця, і він нормально продовжить роботу.

У разі, якщо “Періодичність” у тарифів судного дня встановлено в “День” кредит, у разі включення відповідної опції буде встановлено на 3 дні.

Складно? Не зрозуміло?

Давайте розберемо інший, трохи частіше зустрічається кейс. У вас є тариф Zamanuha для нових користувачів за 50 грошей. Після 12 місяців користувач має бути переведений на “нормальний” тариф Dorogo за 200 грошей.

Ну або навпаки, ви хочете, наприклад, за рік компенсувати вартість підключення користувача, враховуючи її в підвищену вартість початкового тарифу, а потім уже перевести цього користувача на нормальний, людський тариф з адекватною вартістю. Усе точно так само.

Точно так само ви можете будувати ланцюжок переходів користувачів за тарифами якої завгодно довжини. Кількість можливих тарифів судного дня ніяк не лімітована. Тобто ви можете запланувати користувачеві зміну тарифів за принципом “Тариф1, 2 місяці → Тариф2, 60 днів → Тариф3, 6 місяців” або що завгодно інше, обмежене тільки вашою фантазією. Також ви завжди можете побачити повну історію судних днів користувача за допомогою відповідної іконки в “Чорній магії”.

Як це відбувається?

Під час кожного виклику ddt з RemoteAPI тарифи судного дня пробігають весь список користувачів, знаходять користувачів для тарифу, для тарифу яких призначено судний день, і, якщо для них ще не заплановано завдання в “Живи з цим”, рахують час зміни тарифу, у разі, якщо встановлені відповідні опції, проводять нарахування АП та кредитування, і вносять час, коли було помічено користувача, в “історію”. Далі зміна тарифу відбуватиметься сама собою вже засобами “Живи з цим”.

Слід також зауважити, що все це працює для тарифів з нормальною, не розмазаною тарифікацією. Як мінімум нарахування АП завжди відбувається в повному розмірі АП, зазначеної в тарифі, і ніяк не корелює з кількістю днів у місяцях, фазами місяця і тим, чи перебуває сатурн у стрільці.

Навіщо це все?

Для забезпечення гнучкої маркетингової політики вашого підприємства і максимальної автоматизації виробництва. Так, теоретично і практично можна робити все, що роблять “Тарифи судного дня”, і руками, користуючись календариком, калькулятором, логарифмічною лінійкою і записником.

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

doomsdaytariffs.txt · Востаннє змінено: 2023/06/27 12:30 повз nightfly