Розбіжності

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

--- doomsdaytariffs [2022/09/24 14:39]
127.0.0.1 зовнішнє редагування
+++ doomsdaytariffs [2026/03/24 16:39] (поточний)
nightfly
@@ Рядок 1: / Рядок 1: @@
-====== Тарифы судного дня  ======
+====== Тарифи судного дня ======
-[[http://ubilling.net.ua/?module=fnpages&pid=ubpay|{{ :buy-50.png?nolink&|}}]]
+**Дозволяють:**
+   * Гнучко керувати життєвим циклом тарифів
+   * Автоматично планувати міграцію користувачів між тарифами
+   * Блокувати випадкові зміни тарифів користувачам для яких вже запланована зміна
+   * Опційно нараховувати абонплату за поточним тарифом
+   * Опційно встановлювати кредит користувачам, щоб вони продовжували роботу
+   * Життєвий цикл тарифів може відбуватися в місяцях або днях
+   * Виправляти персоналу свої помилки протягом якогось часу
+   * Переглядати звіт про те, коли і з якого приводу це все відбувалося
+   * Автоматично знімати АП тарифів ваших нових свіжозареєстрованих користувачів
-**Позволяют:**
+**Занадто складно, можна простіше?**
-   * Гибко управлять жизненным циклом тарифов
-   * Автоматически планировать мигрирацию пользователей между тарифами
-   * Блокировать случайные изменения тарифов пользователям для которых уже запланирована смена
-   * Опционально начислять абонплату по текущему тарифу
-   * Опционально устанавливать кредит пользователям, чтобы они продолжали работу
-   * Жизненный цикл тарифов может происходить в месяцах или днях
-   * Исправлять персоналу свои ошибки на протяжении какого-то времени
-   * Просматривать отчет о том, когда и по какому поводу это все происходило
-**Слишком сложно, можно проще?**
+Окей. Тарифи судного дня дають змогу вам нативно робити тарифи на кшталт таких:
-Окей. Тарифы судного дня позволяют вам нативно делать тарифы типа таких:
 {{:ddtsample1.png?300|}} {{:ddtsample2.jpg?300|}} {{:ddtsample3.png?300|}} {{:ddtsample4.png?300|}}
-Так понятнее? Тогда поехали!
+Так зрозуміліше? Тоді поїхали!
 {{:apocalypsepony.gif?direct&|}}
-====== Включение ======
+====== Ввімкнення ======
-**Важно!** для работы модуля обязательно требуется настроенный и работающий [[dealwithit|Живи с этим]].
+**Важливо!** для роботи модуля обов'язково потрібен налаштований і працюючий [[dealwithit|Живи з цим]].
-Для нормальной работы тарифов судного дня требуются две опции [[alteriniconf|alter.ini]]:
+Для нормальної роботи тарифів судного дня потрібні дві опції [[alteriniconf|alter.ini]]:
 <code ini>
 DEALWITHIT_ENABLED=1
@@ Рядок 33: / Рядок 32: @@
 </code>
-а также два соответствующих вызова [[remoteapi|Remote API]]
+а також два відповідних виклики [[remoteapi|Remote API]]
 <code bash>
 2 * * *    /bin/ubapi "dealwithit"
@@ Рядок 39: / Рядок 38: @@
 </code>
-====== Настройка ======
+====== Налаштування ======
-Вся конфигурация в дальнейшем производится при помощи следующего модуля
+Уся конфігурація надалі здійснюються за допомогою такого модулю
 {{:ddt0.png?direct&|}}
-Объясним на нетривиальном примере. У вас имеется тариф Fire-5 стоимостью 100 денег. Вы хотите, чтобы он был доступен пользователям сроком на три месяца, после чего они должны быть переведены на тариф Unlim-5 стоимостью 150 денег. Вот такая вот чудесная акция с целью повышения лояльности вашей абонбазы.
+Пояснимо на нетривіальному прикладі. У вас є тариф Fire-5 вартістю 100 грошей. Ви хочете, щоб він був доступний користувачам терміном на три місяці, після чого вони повинні бути переведені на тариф Unlim-5 вартістю 150 грошей. Ось така ось чудова акція з метою підвищення "лояльності" вашої абонбази.
+Також ви хочете, щоб під час підключення цього тарифу, якщо поточне число місяця менше 25-го, було нараховано абонплату (після 25-го не жлобимось і вважаємо для себе, що 5 днів інтернету не варті 100 грошей) відповідно до тарифу Fire-5 у розмірі 100 грошей, і, в разі, якщо в абонента після цього не вистачатиме грошей для продовження роботи, йому встановили кредит до кінця місяця на суму, якої не вистачає (ну, припустімо, це новий абонент, і він повинен оплатити послугу до кінця місяця).
+Складно, правда? Але цілком можливо, що вам саме хочеться це робити й автоматизувати. Ось як це має виглядати:
+{{ddt1.png|}}
+І власне результат:
+{{ddt2.png|}}
+Слід також зауважити, що чекбокс "Враховувати поточний період" впливає на те, чи буде розраховуватися дата зміни тарифу на тариф, який "Перевести на тариф після закінчення періодів", зважаючи на "від поточного періоду" (у цьому разі місяця), чи вже починаючи з наступного, а в поточному періоді, вважатимемо, що користувача нібито "не було".
+Далі під час установлення одного з тарифів, описаних у довіднику "Тарифи судного дня", буде показано повідомлення, що для цього користувача буде заплановано зміну тарифного плану відповідно до призначеного тарифу судного дня.
+{{ddt3.png|}}
+Що дає можливість, у разі "якщо користувач передумав" або "оператор помилився" швиденько змінити своє рішення і змінити вибір тарифу на необхідний. По закінченню якогось часу, залежно від періодичності виклику ddt з RemoteAPI, для користувача буде заплановано перехід на необхідний тариф, і операції ручної зміни тарифу будуть заблоковані. Планування завдання на зміну тарифу відбуватиметься в разі тільки якщо для користувача не було раніше заплановано жодного завдання на зміну тарифу. Можливо у вас вже є користувачі, яким ви вже щось запланували раніше в цьому контексті, і тарифи судного дня будуть їх просто ігнорувати.
+{{ddt4.png|}}
+Що буде також відображено у відповідних звітах за "Тарифами судного дня" і "Живи з цим"
+{{ddt5.png|}}
+Варто зауважити, що у звіті "Історія" тарифів судного дня, поле "Дата" позначає дату і час, коли користувач був "помічений" на одному з тарифів судного дня, а "Дата закінчення" позначає дату, коли буде проведена заміна тарифу. Для тарифів судного дня з періодичністю "Місяць" це буде завжди останній день необхідного місяця, для того, щоб Stargazer зміг нормально нарахувати абонплату вже за новим тарифом. Для тарифів з періодичністю "День" дату зміни тарифного плану буде встановлено на конкретний день місяця в майбутньому, порахованим за принципом "поточна дата/завтрашній день + тривалість*днів".
+Результат чого можна побачити у звіті за завданнями "Живи з цим"
+{{ddt6.png|}}
+З огляду на попередню конфігурацію нашого тарифу судного дня у вигляді Fire-5, у абонента на рахунку було 0 грошей, і йому було нараховано 100 грошей за поточний період використання тарифу Fire-5.
+{{ddt7.png|}}
+З огляду на те, що на його рахунку після цього утворилася заборгованість у розмірі -100 грошей, йому автоматично було встановлено кредитний ліміт у 100 грошей до кінця поточного місяця, і він нормально продовжить роботу.
+{{ddt8.png|}}
+У разі, якщо "Періодичність" у тарифів судного дня встановлено в "День" кредит, у разі включення відповідної опції буде встановлено на 3 дні.
+====== Складно? Не зрозуміло? ======
+Давайте розберемо інший, трохи частіше зустрічається кейс. У вас є тариф Zamanuha для нових користувачів за 50 грошей. Після 12 місяців користувач має бути переведений на "нормальний" тариф Dorogo за 200 грошей.
+{{ddt9.png|}}
+Ну або навпаки, ви хочете, наприклад, за рік компенсувати вартість підключення користувача, враховуючи її в підвищену вартість початкового тарифу, а потім уже перевести цього користувача на нормальний, людський тариф з адекватною вартістю. Усе точно так само.
-Также вы хотите, чтобы при подключении данного тарифа если текущее число месяца меньше 25-го была начислена абонплата (после 25-го не крохоборствуем и считаем для себя, что 5 дней интернета не стоят 100 денег) соответственно тарифа Fire-5 в размере 100 денег и в случае если у абонента будет после этого недостаточно денег для продолжения работы, ему был установлен кредит до конца месяца на недостающую сумму (ну допустим это новый абонент, и он должен оплатить услугу до конца месяца).
+{{ddt10.png|}}
-Сложно, правда? Но вполне возможно что вам именно хочется это делать и автоматизировать. Вот как это должно выглядеть:
+Точно так само ви можете будувати ланцюжок переходів користувачів за тарифами якої завгодно довжини. Кількість можливих тарифів судного дня ніяк не лімітована. Тобто ви можете запланувати користувачеві зміну тарифів за принципом "Тариф1, 2 місяці -> Тариф2, 60 днів -> Тариф3, 6 місяців" або що завгодно інше, обмежене тільки вашою фантазією. Також ви завжди можете побачити повну історію судних днів користувача за допомогою відповідної іконки в "Чорній магії".
-{{:ddt1.png?direct&|}}
+====== Як це відбувається? ======
-И собственно результат:
+Під час кожного виклику ddt з RemoteAPI тарифи судного дня пробігають весь список користувачів, знаходять користувачів для тарифу, для тарифу яких призначено судний день, і, якщо для них ще не заплановано завдання в "Живи з цим", рахують час зміни тарифу, у разі, якщо встановлені відповідні опції, проводять нарахування АП та кредитування, і вносять час, коли було помічено користувача, в "історію". Далі зміна тарифу відбуватиметься сама собою вже засобами "Живи з цим".
-{{:ddt2.png?direct&|}}
+Слід також зауважити, що все це працює для тарифів з нормальною, **не розмазаною** тарифікацією. Як мінімум нарахування АП завжди відбувається в повному розмірі АП, зазначеної в тарифі, і ніяк не корелює з кількістю днів у місяцях, фазами місяця і тим, чи перебуває сатурн у стрільці.
-Следует также заметить, что чекбокс "Учитывать текущий период" влияет на то, будет ли рассчитываться дата смены тарифа на тариф, который "Перевести на тариф после окончания периодов" исходя из "от текущего периода" (в данном случае месяца) или уже начиная со следующего, а в текущем будем считать что пользователя как-бы "не было".
+====== Навіщо це все? ======
-Далее при установке одного из тарифов описанных в справочнике "Тарифы судного дня" будет показано уведомление, что для этого пользователя будет запланировано изменение тарифного плана соответственно с назначенным тарифу судным днем
+Для забезпечення гнучкої маркетингової політики вашого підприємства і максимальної автоматизації виробництва. Так, теоретично і практично можна робити все, що роблять "Тарифи судного дня", і руками, користуючись календариком, калькулятором, логарифмічною лінійкою і записником.
-{{:ddt3.png?direct&|}}
+**А можна просто встановити користувачеві необхідний тариф і забути про нього. Ось для цього, так.**
-Что дает возможность, в случае "если пользователь передумал" или "оператор ошибся" быстренько изменить свое решение и изменить выбор тарифа на требуемый. По прохождению какого-то времени, в зависимости от периодичности вызов ddt из RemoteAPI для пользователя будет запланирован переход на требуемый тариф, и операции ручного изменения тарифа будут заблокированы. Планирование задачи на смену тарифа, будет происходить в случае только если для пользователя небыло ранее запланировано ниодной задачи на смену тарифа. Возможно у вас уже есть пользователи которым вы уже что-то запланировали ранее в этом контексте и тарифы судного дня будут их просто игнорировать.
-{{:ddt4.png?direct&|}}
+====== Примусове нарахування ======
-Что будет также отражено в соответствующих отчетах по "Тарифам судного дня" и "Живи с этим"
+Стоп, а що за "Примусове нарахування тарифів" трішки нижче тарифів судного дня? Ось ці
-{{:ddt5.png?direct&|}}
+{{ddt11.png|}}
-Стоит заметить, что в отчете "История" тарифов судного дня, поле "Дата" обозначает дату и время когда пользователь был "замечен" на одном из тарифов судного дня а "Дата окончания" обозначает дату когда будет произведена смена тарифа. Для тарифов судного дня с периодичностью "Месяц" это будет всегда последний день требуемого месяца, для того, чтобы Stargazer смог нормально начислить абонплату уже по новому тарифу. Для тарифов с периодичностью "День" дата смены тарифного плана будет установлена на конкретный день месяца в будущем посчитанным по принципу "текущая дата/завтрашний день + длительность*дней".
+Ну припустимо в вас є тарифи MegaCopper та GigaPON, і ви не хочете їх кудись змінювати колись там, кудись там для нових користувачів. Просто собі реєструєте користувачів, вішаєте на них цей тариф і все.
-Результат чего можно увидеть в отчете по задачам "Живи с этим"
+Так як ви не благодійна організація, напевне ви хочете отримувати якийсь прибуток. Тому ви вирішили, що раз тариф GigaPON трішки дорожчий для вас в підключенні та утриманні (а ще витрати на мережу покривати і все таке) ви хочете отримувати при підключенні платіж в 1500 грошей а також повну абонплату тарифу, в незалежності від дня коли абонента підключено. А для тарифу MegaCopper в вас діє безкоштовне підключення і знімати повну абонплату тарифу ви будете тільки якщо абонента зареєстровано в першій половині місяця, тобто до 15 числа включно. Якщо вже в кінці - "на тобі, безкоштовно". Отака акція невиданої щедрості. Також ми хочемо, щоб абонент продовжував якийсь час роботу після цих всіх нарахувань, а не залишився без інтернету через пів години після його реєстрації. Тому ми в обох випадках будемо автоматично встановлювати кредит на три дні, у випадку, якщо сума на рахунку абонента після нарахувань стане меншою за нуль. У випадку якщо автоматичне кредитування не потрібно - можемо просто залишити поле про кредит порожнім або вписати туди 0. Також ви можете захотіти не нараховувати для нових абонентів абонплату згідно їхнього тарифу а власне знімати просто якийсь "реєстраційний платіж". У такому випадку, просто зніміть чекбокс "Нараховувати абонплату згідно поточного тарифу" та вкажіть суму нарахування в сусідньому полі "Також додатково знімати ось таку суму".
-{{:ddt6.png?direct&|}}
+Тобто робимо ось таке правило примусового нарахування для тарифу GigaPON:
-Учитывая предыдущую конфигурацию нашего тарифа судного дня в виде Fire-5, у абонента на счету было 92 денег, и ему было начислено 100 денег за текущий период использования тарифа Fire-5.
+{{ddt12.png|}}
-{{:ddt7.png?direct&|}}
+і ось таке для MegaCopper:
-В силу того, что на его счету после этого образовалась задолженность в размере -8 денег, ему автоматически был установлен кредитный лимит в 8 денег до конца текущего месяца, и он нормально продолжит работу.
+{{ddt13.png|}}
-{{:ddt8.png?direct&|}}
+Отримуючи два ось таких правила примусового нарахування.
-В случае, если "Периодичность" у тарифов судного дня установлена в "День" кредит, в случае включения соответствующей опции будет установлен на 3 дня.
+{{ddt14.png|}}
-====== Сложно? Не понятно? ======
+Що після реєстрації користувачів на цих тарифах
-Давайте разберем другой, чуть более часто встречающийся кейс. У вас есть тариф Zamanuha для новых пользователей за 50 денег. По прошествии 12 месяцев пользователь должен быть переведен на "нормальный" тариф Dorogo за 200  денег.
+{{ddt15.png|}}
-{{:ddt9.png?direct&|}}
+після наступного запуску виклику ddt з remoteAPI, дасть нам наступний ефект:
-Ну либо наоборот, вы хотите например за годик компенсировать стоимость подключения пользователя учитывая ее в повышенную стоимость начального тарифа а потом уже перевести этого пользователя на нормальный, человеческий тариф с адекватной стоимостью. Все точно так-же.
+{{ddt16.png|}}
-{{:ddt10.png?direct&|}}
+{{ddt17.png|}}
-Точно таким же образом вы можете строить цепочку переходов пользователей по тарифам какой угодно длины. Количество возможных тарифов судного дня никак не лимитировано. То есть вы можете запланировать пользователю смену тарифов по принципу "Тариф1, 2 месяца -> Тариф2, 60 дней -> Тариф3 6 месяцев" или что угодно другое ограниченное только вашей фантазией. Также вы всегда можете увидеть полную историю судных дней пользователя при помощи соответствующей иконки в "Черной магии".
+а також буде відображено в історії примусових нарахувань
-====== Как это все происходит? ======
+{{ddt18.png|}}
-При каждом вызове ddt из RemoteAPI тарифы судного дня пробегают весь список пользователей, находят пользователей для тарифа которых назначен судный день и в случае если для них еще не запланирована задача в "Живи с этим" считают время смены тарифа, в случае если установлены соответствующие опции проводят начисление АП и кредитование и вносят время когда был замечен пользователь в "историю". Дальше смена тарифа будет происходить сама собой уже средствами "Живи с этим".
+Так, воно просто дивиться в "зареєстрованих сьогодні" користувачів і запускає правила примусового нарахування для тарифу користувача, якщо власне для нього на момент запуску виклику з RemoteAPI створено це правило. Також контролюється унікальність нарахувань для унікальних логінів в рамках часового інтервалу "сьогодні". Тобто якщо ви спочатку виставили користувачу один тариф, потім відбулось нарахування, а потім змінили тариф на інший - для цього користувача вже нічого не відбудеться. Він помічається як вже "порахований".
-Следует также заметить, что все это работает для тарифов с нормальной, **не размазанной** тарификацией. Как минимум начисление АП всегда происходит в полном размере АП указанной в тарифе и никак не коррелирует с количеством дней в месяцах, фазами луны и тем находится ли сатурн в стрельце.
+Слід також помітити, що тарифи з правилами примусового нарахування не можуть бути тарифами судного дня та навпаки, ви не можете зробити тарифом судного дня тариф, для якого є правило примусового нарахування.
-====== Зачем все это? ======
-Для обеспечения гибкой маркетинговой политики вашего предприятия и максимальной автоматизации производства. Да, теоретически и практически можно делать все что делают "Тарифы судного дня" и руками, пользуясь календариком, калькулятором, логарифмической линейкой и записной книжкой.
-А можно просто установить пользователю требуемый тариф и забыть о нем. Вот для этого, да.

Ubilling Wiki

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

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

Розбіжності

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