Дозволяють:

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

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

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

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

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

Для нормальної роботи тарифів судного дня потрібні дві опції 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, у абонента на рахунку було 0 грошей, і йому було нараховано 100 грошей за поточний період використання тарифу Fire-5.

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

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

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

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

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

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

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

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

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

Стоп, а що за “Примусове нарахування тарифів” трішки нижче тарифів судного дня? Ось ці

Ну припустимо в вас є тарифи MegaCopper та GigaPON, і ви не хочете їх кудись змінювати колись там, кудись там для нових користувачів. Просто собі реєструєте користувачів, вішаєте на них цей тариф і все.

Так як ви не благодійна організація, напевне ви хочете отримувати якийсь прибуток. Тому ви вирішили, що раз тариф GigaPON трішки дорожчий для вас в підключенні та утриманні (а ще витрати на мережу покривати і все таке) ви хочете отримувати при підключенні платіж в 1500 грошей а також повну абонплату тарифу, в незалежності від дня коли абонента підключено. А для тарифу MegaCopper в вас діє безкоштовне підключення і знімати повну абонплату тарифу ви будете тільки якщо абонента зареєстровано в першій половині місяця, тобто до 15 числа включно. Якщо вже в кінці - “на тобі, безкоштовно”. Отака акція невиданої щедрості. Також ми хочемо, щоб абонент продовжував якийсь час роботу після цих всіх нарахувань, а не залишився без інтернету через пів години після його реєстрації. Тому ми в обох випадках будемо автоматично встановлювати кредит на три дні, у випадку, якщо сума на рахунку абонента після нарахувань стане меншою за нуль. У випадку якщо автоматичне кредитування не потрібно - можемо просто залишити поле про кредит порожнім або вписати туди 0. Також ви можете захотіти не нараховувати для нових абонентів абонплату згідно їхнього тарифу а власне знімати просто якийсь “реєстраційний платіж”. У такому випадку, просто зніміть чекбокс “Нараховувати абонплату згідно поточного тарифу” та вкажіть суму нарахування в сусідньому полі “Також додатково знімати ось таку суму”.

Тобто робимо ось таке правило примусового нарахування для тарифу GigaPON:

і ось таке для MegaCopper:

Отримуючи два ось таких правила примусового нарахування.

Що після реєстрації користувачів на цих тарифах

після наступного запуску виклику ddt з remoteAPI, дасть нам наступний ефект:

а також буде відображено в історії примусових нарахувань

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

Слід також помітити, що тарифи з правилами примусового нарахування не можуть бути тарифами судного дня та навпаки, ви не можете зробити тарифом судного дня тариф, для якого є правило примусового нарахування.