Розбіжності

Тут показані розбіжності між вибраною ревізією та поточною версією сторінки.

--- doomsdaytariffs [2024/10/05 13:23]
nightfly
+++ doomsdaytariffs [2024/10/05 14:11] (поточний)
nightfly
@@ Рядок 12: / Рядок 12: @@
    * Виправляти персоналу свої помилки протягом якогось часу
    * Переглядати звіт про те, коли і з якого приводу це все відбувалося
+   * Автоматично знімати АП тарифів ваших нових свіжозареєстрованих користувачів
 **Занадто складно, можна простіше?**
@@ Рядок 52: / Рядок 53: @@
 Складно, правда? Але цілком можливо, що вам саме хочеться це робити й автоматизувати. Ось як це має виглядати:
-{{:ddt1.png?direct&|}}
+{{ddt1.png|}}
 І власне результат:
-{{:ddt2.png?direct&|}}
+{{ddt2.png|}}
 Слід також зауважити, що чекбокс "Враховувати поточний період" впливає на те, чи буде розраховуватися дата зміни тарифу на тариф, який "Перевести на тариф після закінчення періодів", зважаючи на "від поточного періоду" (у цьому разі місяця), чи вже починаючи з наступного, а в поточному періоді, вважатимемо, що користувача нібито "не було".
@@ Рядок 62: / Рядок 63: @@
 Далі під час установлення одного з тарифів, описаних у довіднику "Тарифи судного дня", буде показано повідомлення, що для цього користувача буде заплановано зміну тарифного плану відповідно до призначеного тарифу судного дня.
-{{:ddt3.png?direct&|}}
+{{ddt3.png|}}
 Що дає можливість, у разі "якщо користувач передумав" або "оператор помилився" швиденько змінити своє рішення і змінити вибір тарифу на необхідний. По закінченню якогось часу, залежно від періодичності виклику ddt з RemoteAPI, для користувача буде заплановано перехід на необхідний тариф, і операції ручної зміни тарифу будуть заблоковані. Планування завдання на зміну тарифу відбуватиметься в разі тільки якщо для користувача не було раніше заплановано жодного завдання на зміну тарифу. Можливо у вас вже є користувачі, яким ви вже щось запланували раніше в цьому контексті, і тарифи судного дня будуть їх просто ігнорувати.
-{{:ddt4.png?direct&|}}
+{{ddt4.png|}}
 Що буде також відображено у відповідних звітах за "Тарифами судного дня" і "Живи з цим"
-{{:ddt5.png?direct&|}}
+{{ddt5.png|}}
 Варто зауважити, що у звіті "Історія" тарифів судного дня, поле "Дата" позначає дату і час, коли користувач був "помічений" на одному з тарифів судного дня, а "Дата закінчення" позначає дату, коли буде проведена заміна тарифу. Для тарифів судного дня з періодичністю "Місяць" це буде завжди останній день необхідного місяця, для того, щоб Stargazer зміг нормально нарахувати абонплату вже за новим тарифом. Для тарифів з періодичністю "День" дату зміни тарифного плану буде встановлено на конкретний день місяця в майбутньому, порахованим за принципом "поточна дата/завтрашній день + тривалість*днів".
@@ Рядок 76: / Рядок 77: @@
 Результат чого можна побачити у звіті за завданнями "Живи з цим"
-{{:ddt6.png?direct&|}}
+{{ddt6.png|}}
 З огляду на попередню конфігурацію нашого тарифу судного дня у вигляді Fire-5, у абонента на рахунку було 0 грошей, і йому було нараховано 100 грошей за поточний період використання тарифу Fire-5.
-{{:ddt7.png?direct&|}}
+{{ddt7.png|}}
 З огляду на те, що на його рахунку після цього утворилася заборгованість у розмірі -100 грошей, йому автоматично було встановлено кредитний ліміт у 100 грошей до кінця поточного місяця, і він нормально продовжить роботу.
-{{:ddt8.png?direct&|}}
+{{ddt8.png|}}
 У разі, якщо "Періодичність" у тарифів судного дня встановлено в "День" кредит, у разі включення відповідної опції буде встановлено на 3 дні.
@@ Рядок 92: / Рядок 93: @@
 Давайте розберемо інший, трохи частіше зустрічається кейс. У вас є тариф Zamanuha для нових користувачів за 50 грошей. Після 12 місяців користувач має бути переведений на "нормальний" тариф Dorogo за 200 грошей.
-{{:ddt9.png?direct&|}}
+{{ddt9.png|}}
 Ну або навпаки, ви хочете, наприклад, за рік компенсувати вартість підключення користувача, враховуючи її в підвищену вартість початкового тарифу, а потім уже перевести цього користувача на нормальний, людський тариф з адекватною вартістю. Усе точно так само.
-{{:ddt10.png?direct&|}}
+{{ddt10.png|}}
 Точно так само ви можете будувати ланцюжок переходів користувачів за тарифами якої завгодно довжини. Кількість можливих тарифів судного дня ніяк не лімітована. Тобто ви можете запланувати користувачеві зміну тарифів за принципом "Тариф1, 2 місяці -> Тариф2, 60 днів -> Тариф3, 6 місяців" або що завгодно інше, обмежене тільки вашою фантазією. Також ви завжди можете побачити повну історію судних днів користувача за допомогою відповідної іконки в "Чорній магії".
@@ Рядок 111: / Рядок 112: @@
 **А можна просто встановити користувачеві необхідний тариф і забути про нього. Ось для цього, так.**
+====== Примусове нарахування ======
+Стоп, а що за "Примусове нарахування тарифів" трішки нижче тарифів судного дня? Ось ці
+{{ddt11.png|}}
+Ну припустимо в вас є тарифи MegaCopper та GigaPON, і ви не хочете їх кудись змінювати колись там, кудись там для нових користувачів. Просто собі реєструєте користувачів, вішаєте на них цей тариф і все.
+Так як ви не благодійна організація, напевне ви хочете отримувати якийсь прибуток. Тому ви вирішили, що раз тариф GigaPON трішки дорожчий для вас в підключенні та утриманні (а ще витрати на мережу покривати і все таке) ви хочете отримувати при підключенні платіж в 1500 грошей а також повну абонплату тарифу, в незалежності від дня коли абонента підключено. А для тарифу MegaCopper в вас діє безкоштовне підключення і знімати повну абонплату тарифу ви будете тільки якщо абонента зареєстровано в першій половині місяця, тобто до 15 числа включно. Якщо вже в кінці - "на тобі, безкоштовно". Отака акція невиданої щедрості. Також ми хочемо, щоб абонент продовжував якийсь час роботу після цих всіх нарахувань, а не залишився без інтернету через пів години після його реєстрації. Тому ми в обох випадках будемо автоматично встановлювати кредит на три дні, у випадку, якщо сума на рахунку абонента після нарахувань стане меншою за нуль. У випадку якщо автоматичне кредитування не потрібно - можемо просто залишити поле про кредит порожнім або вписати туди 0. Також ви можете захотіти не нараховувати для нових абонентів абонплату згідно їхнього тарифу а власне знімати просто якийсь "реєстраційний платіж". У такому випадку, просто зніміть чекбокс "Нараховувати абонплату згідно поточного тарифу" та вкажіть суму нарахування в сусідньому полі "Також додатково знімати ось таку суму".
+Тобто робимо ось таке правило примусового нарахування для тарифу GigaPON:
+{{ddt12.png|}}
+і ось таке для MegaCopper:
+{{ddt13.png|}}
+Отримуючи два ось таких правила примусового нарахування.
+{{ddt14.png|}}
+Що після реєстрації користувачів на цих тарифах
+{{ddt15.png|}}
+після наступного запуску виклику ddt з remoteAPI, дасть нам наступний ефект:
+{{ddt16.png|}}
+{{ddt17.png|}}
+а також буде відображено в історії примусових нарахувань
+{{ddt18.png|}}
+Так, воно просто дивиться в "зареєстрованих сьогодні" користувачів і запускає правила примусового нарахування для тарифу користувача, якщо власне для нього на момент запуску виклику з RemoteAPI створено це правило. Також контролюється унікальність нарахувань для унікальних логінів в рамках часового інтервалу "сьогодні". Тобто якщо ви спочатку виставили користувачу один тариф, потім відбулось нарахування, а потім змінили тариф на інший - для цього користувача вже нічого не відбудеться. Він помічається як вже "порахований".
+Слід також помітити, що тарифи з правилами примусового нарахування не можуть бути тарифами судного дня та навпаки, ви не можете зробити тарифом судного дня тариф, для якого є правило примусового нарахування.

Ubilling Wiki

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

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

Розбіжності

Налаштування сторінки