Антидублирующая оплата

[Tris 1]

 В противоположность теме https://local.com.ua/forum/topic/94735-%D0%B4%D1%83%D0%B1%D0%BB%D0%B8%D1%80%D1%83%D1%8E%D1%89%D0%B0%D1%8F-%D0%BE%D0%BF%D0%BB%D0%B0%D1%82%D0%B0 была отмечена проблема:

 при мгновенном (точность до 1 сек. = предел точности отображения даты в MySQL) занесении нескольких (2+) платежей одному абоненту (например - при импорте банковских выписок) происходит следующее:

• в логе старгейзера присутствуют оба (или более) платежа,
• в БД, таблице bankstaparsed, присутствуют оба (или более) платежа,
• в БД, таблице payments присутствуют оба (или более) платежа (!!!), НО
• одновременно - в карточке пользователя отсутствуют все платежи, кроме последнего за эту дату (сужу по ID lifestory)
• как результат - не хватает средств у конкретной учётной записи => отключён инет.

 Такое ощущение, что где-то в скриптах, касасающихся карточки абонента, в SQL-запросах добавлен оператор GROUP BY  (или что-либо подобное) и происходит как раз вышесказанное (группирует-режет записи). При беглом осмотре файлов - такого не нашёл.

 Поэтому просьба к тем, кто более сведущ что с чем взаимосвязано в уБиллинге: где искать (в каких файлах-скриптах) проблему не учёта средств клиента, если:

• module=report_finance - отображает данные верно
• module=lifestory - отображает данные верно
• module=addcash - отображает данные верно
• module=pl_fundsflow - ошибка, потеря записей (с одинаковой датой)
• итоговая сумма средств абонента меньше, чем занесено в БД.

P.S.: модуль онлайн и что-то в карточке абонента "рихтовано", но не мной.

[Tris 1]

P.S.: Ubilling 0.8.7 rev 5918, файлы ../modules/general/pl_fundsflow/index.php & module.php от 2017-12-29. Эффект тот же.

Из выше упомянутых-переписанных модулей - pl_passive.

[Pautiina 29]

P.S.: Ubilling 0.8.7 rev 5918, файлы ../modules/general/pl_fundsflow/index.php & module.php от 2017-12-29. Эффект тот же.

Из выше упомянутых-переписанных модулей - pl_passive.

 

Ну чисто теоретически, проблема в этом файле: api/libs/api.fundsflow.php

 

При чем, там в нескольких местах.

            foreach ($allpayments as $io => $eachpayment) {
                $counter = strtotime($eachpayment['date']);

                if (ispos($eachpayment['note'], 'MOCK:')) {
                    $cashto = $eachpayment['balance'];
                }

                if (ispos($eachpayment['note'], 'BALANCESET:')) {
                    $cashto = $eachpayment['summ'];
                }

                if ((!ispos($eachpayment['note'], 'MOCK:')) AND ( !ispos($eachpayment['note'], 'BALANCESET:'))) {
                    $cashto = $eachpayment['summ'] + $eachpayment['balance'];
                }

                $result[$counter]['login'] = $login;
                $result[$counter]['date'] = $eachpayment['date'];
                $result[$counter]['admin'] = $eachpayment['admin'];
                $result[$counter]['summ'] = $eachpayment['summ'];
                $result[$counter]['from'] = $eachpayment['balance'];
                $result[$counter]['to'] = $cashto;
                $result[$counter]['operation'] = 'Payment';
                $result[$counter]['note'] = $eachpayment['note'];
                $result[$counter]['cashtype'] = $eachpayment['cashtypeid'];
            }

Вот часть кода которая формирует выборку, и проблема в том, что индекс массива формируется из даты.

$result[$counter]['date'] = $eachpayment['date'];

а дата, как я понимаю у вас по платежам совпадает.

[skybetik 134]

Там рихтовано ,там переписано ,не удивлюсь что вы еще и руками в базу лазили и правили профиля пользователей или еще что.

[Tris 1]

Вот часть кода которая формирует выборку, и проблема в том, что индекс массива формируется из даты.

$result[$counter]['date'] = $eachpayment['date'];

а дата, как я понимаю у вас по платежам совпадает.

 

Именно, а дата учитывается - всего лишь с точностью до целых секунд.

P.S.: если кому интересно, как такое может случиться - услуга Инет и услуга КТВ, по своей/ кассирской ошибке абонент платит 2 платежа на "Инет", потом выписка и ... точность до секунды в БД.

[Tris 1]

Там рихтовано ,там переписано ,не удивлюсь что вы еще и руками в базу лазили и правили профиля пользователей или еще что.

 А это ведь идея! (с)

Но нет, в данном случае не виноват - делал лишь выборки из БД, а также просматривал файлы логов - для проверки правильности занесения данных.

И да - что всё в уБиллинге контролируется ещё и старгейзером = не так просто отредактировать, при рабочем процессе stargazer, я так же в курсе.

[Tris 1]

Итого, как понял из сообщения Pautiina, буду ждать возможных исправлений со стороны nightfly и Со.

Вместо:

$counter = strtotime($eachpayment['date']);

Что-то наподобие:

$counter = strtotime($pl_fundsflow['ID'] & $eachpayment['date']);
или
$counter = strtotime($eachpayment['date']) & $GetData(pl_fundsflow['ID']);

Так как подобная ситуация - вполне реальна (как показала банковская практика ).

А пока что - придётся контролировать записи при импорте банковских выписок, на предмет сдвоенных (по времени) платежей на один логин в БД.

[Pautiina 29]

Итого, как понял из сообщения Pautiina, буду ждать возможных исправлений со стороны nightfly и Со.

Вместо:

$counter = strtotime($eachpayment['date']);

Что-то наподобие:

$counter = strtotime($pl_fundsflow['ID'] & $eachpayment['date']);
или
$counter = strtotime($eachpayment['date']) & $GetData(pl_fundsflow['ID']);

Так как подобная ситуация - вполне реальна (как показала банковская практика ).

А пока что - придётся контролировать записи при импорте банковских выписок, на предмет сдвоенных (по времени) платежей на один логин в БД.

То, что вы выше написали-полный бред. Там глобально нужно менять, и учитывать микросекунды или по другому строить логику формирования выборки

Добавлю в проблемы http://wiki.ubilling.net.ua/doku.php?id=bugtrack, а там посмотрим.

Відредаговано 2018-01-04 10:57:08 Pautiina

[Tris 1]

 Не бред, ибо

 

по другому строить логику формирования выборки

как раз можно, добавляя ко временной метке с целыми секундами ещё чего-нибудь - например ID из истории жизни, и таким образом формировать уникальный идентификатор записи. И конечно же - это изменение надо учитывать во всех зависимых элементах, т.е. глобально.

 Или - переходить к учёту до микросекунд, помня, что лог старгейзера ведётся "до секунд".

 

Подведя итог: "...а невестке всё однО - лишь бы было красивО" (с), как сделают - покажет время, главное - учёт и контроль в результате.