====== Знижки ======
Механіка знижок доступна починаючи з Ubilling 0.3.4. У версії Ubilling 1.3.4 (ага, після сотні стабільних релізів) її було вдумливо переписано, і вона більше не спирається на "додаткові поля профілю", як це було раніше.
Суть реалізації знижок, полягає в тому, що при відповідному виклику **discountprocessing** з [[remoteapi|Remote API]] відбувається наступне:
* Видобуваються суми усіх позитивних платежів за якийсь період часу (поточний чи попередній місяць, чи добу, опційно).
* У випадку, якщо для користувачів, що здійснили ці платежі встановлено ненульовий відсоток знижки, цей відсоток від суми всіх платежів користувача зараховується на його рахунок.
{{:discounts00.jpg?400|}}
====== Ввімкнення та налаштування ======
Вся конфігурація, відбувається за допомогою кількох опцій [[alteriniconf|alter.ini]]:
; Підтримку механіки знижок увімкнено?
DISCOUNTS_ENABLED=1
; якщо (чомусь?) необхідно внесення коштів знижки на рахунок як оплати а не коригуванням,
; дана опція може приймати значення ADD
DISCOUNT_OPERATION="CORR"
; ID типу платежів, під виглядом якого вноситимуться кошти на рахунок. За замовчуванням це типу "готівка".
DISCOUNT_CASHTYPEID=1
; розкоментування цієї опції, призведе до того, що при розрахунку знижок користувачів,
; будуть розглядатись оплати за "попередній місяць" замість "за поточний" як це є за замовчуванням.
;DISCOUNT_PREVMONTH=1
; Ввімкніть дану опцію, для щоденної обробки знижок. В цьому випадку, будуть розглядатись тільки платежі за поточну добу.
DISCOUNT_DAILY=0
та розміщенням необхідного виклику **discountprocessing** в якийсь певний час, в вашому crontab-і.
У випадку, якщо ви бажаєте розраховувати знижки, по платежах за поточний місяць, в останній день місяця, ви можете зробити якось так:
59 23 * * * /bin/ubapi "discountprocessing&lastday=1"
Що власне призведе до нарахування знижок, по платежах за поточний місяць, але тільки в 23:59 останнього дня місяця, за що відповідає параметр **lastday**.
Також вам може захотітись, нараховувати знижки скажімо тільки "чемним користувачам", котрі спромоглись оплатити послуги до середини місяця, ігноруючи всі платежі після 15-го числа. В такому випадку виклик в crontab може мати наступний вигляд:
59 23 15 * * /bin/ubapi "discountprocessing"
Ну або ж ви бажаєте нараховувати знижки по всіх платежах попереднього місяця, вночі першого числа нового місяця. В такому випадку, вам необхідно змінити чи розкоментувати відповідну опцію в значення "1"
DISCOUNT_PREVMONTH=1
Та використовувати виклик з crontab якось так:
20 1 1 * * /bin/ubapi "discountprocessing"
Також, з якоїсь причини, вам може захотітись обробляти знижки щоденно. Ну типу "пройшов день, користувачі щось там пооплачували, вони молодці, давайте нарахуємо їм знижок не в кінці місяця а наприкінці доби". Добре, без проблем. У цьому випадку нам необхідно увімкнути опцію DISCOUNT_DAILY в конфізі
DISCOUNT_DAILY=1
та здійснювати виклик з Remote API щоденно, наприкінці доби
59 23 * * * /bin/ubapi "discountprocessing"
====== Використання ======
Тепер, для того, щоб встановити знижку нашому абоненту в 10%, нам достатньо просто скористатись "Редагуванням користувача"
{{:paydiscounts0.png?500|}}
Клацнути на редагування знижки
{{:paydiscounts1.png?500|}}
Встановити необхідний нам відсоток
{{:paydiscounts2.png?500|}}
отримати очікуваний результат
{{:paydiscounts3.png?500|}}
та забути про це.
При наступних викликах discountprocessing з Remote API кошти будуть самі собі зараховуватись на рахунок абонента згідно нашої конфігурації та відсотків вказаних для абонента.
{{:paydiscounts4.png?500|}}
Слід також зауважити, що для зміни відсотку знижки абонентів, у вашого персоналу повинно бути встановленим відповідне право керувати користувацькими знижками - **DISCOUNTS**.
====== Міграція з старих знижок ======
У випадку, якщо ви раніше, в доісторичні часи, використовували стару механіку знижок, що спиралась на "Додаткові поля профілю" aka CF можемо тільки поспівчувати - з турботою про вас, зроблено простий [[onepunch|One-punch скрипт]] для міграції отого всього мороку в нормальний сучасний вигляд. Просто, після оновлення Ubilling до 1.3.4 чи новішого, разочок запустіть його в "PHP консолі розробника" і все в вас буде добре ;)
if ($ubillingConfig->getAlterParam('DISCOUNTS_ENABLED')) {
$discountCfId = $ubillingConfig->getAlterParam('DISCOUNT_PERCENT_CFID');
if ($discountCfId) {
$cfDb = new nya_cfitems();
$cfDb->where('typeid', '=', $discountCfId);
$allOldDiscounts = $cfDb->getAll('login');
if (!empty($allOldDiscounts)) {
$discountsDb = new nya_discounts();
$allDiscounts = $discountsDb->getAll('login');
foreach ($allOldDiscounts as $eachLogin => $eachOldDiscountData) {
if (is_numeric($eachOldDiscountData['content'])) {
if (!isset($allDiscounts[$eachLogin])) {
$newDiscount = ubRouting::filters($eachOldDiscountData['content'], 'int');
$loginF = ubRouting::filters($eachOldDiscountData['login'], 'mres');
$loginF = trim($loginF);
$discountsDb->data('login', $loginF);
$discountsDb->data('percent', $newDiscount);
$discountsDb->create();
show_success(__('User') . ' (' . $eachLogin . ') ' . __('Discount') . ' ' . $newDiscount);
} else {
show_warning(__('User') . ' (' . $eachLogin . ') ' . __('already have discount'));
}
} else {
show_error(__('User') . ' (' . $eachLogin . ') ' . __('have wrong discount value') . ' ' . $newDiscount);
}
}
$cache = new UbillingCache();
$cache->delete(Discounts::CACHE_KEY);
} else {
show_error(__('No old discounts found'));
}
} else {
show_error(__('No DISCOUNT_PERCENT_CFID option set'));
}
} else {
show_error(__('Discounts') . ' ' . __('is disabled'));
}
Всі ваші старі знижки, з додаткових полів профілю, буде сконвертовано для роботи в нову структуру даних, після чого ви зможете сміливо видалити це додаткове поле профілю і забути про нього як про страшний сон.