Механіка знижок доступна починаючи з Ubilling 0.3.4. У версії Ubilling 1.3.4 (ага, після сотні стабільних релізів) її було вдумливо переписано, і вона більше не спирається на “додаткові поля профілю”, як це було раніше.

Суть реалізації знижок, полягає в тому, що при відповідному виклику discountprocessing з Remote API відбувається наступне:

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

Вся конфігурація, відбувається за допомогою кількох опцій alter.ini:

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%, нам достатньо просто скористатись “Редагуванням користувача”

Клацнути на редагування знижки

Встановити необхідний нам відсоток

отримати очікуваний результат

та забути про це.

При наступних викликах discountprocessing з Remote API кошти будуть самі собі зараховуватись на рахунок абонента згідно нашої конфігурації та відсотків вказаних для абонента.

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

У випадку, якщо ви раніше, в доісторичні часи, використовували стару механіку знижок, що спиралась на “Додаткові поля профілю” aka CF можемо тільки поспівчувати - з турботою про вас, зроблено простий 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'));
    }

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