A2Billing v1.8+ BUGS

28.11.2004

#1

A2Billing v1.8+ BUGS

У кого не работает Dashboard а именно не рисуются графики - достаточно в корень www положить файл .htaccess добавив туда строчку "php_value display_errors Off"
или можно в глобальном конфиге php.ini эту опцию выключить (что не так элегантно по сравнению с первым примером)
ps: если кто знает как это поправить патчем просьба сообщить.

12.02.2008

#2

Не ожидал такого:

в процедуре cid_sanitize (это которая выбирает номер CID или DID для подстановки в CallerID) есть запрос
lib/Class.A2Billing.php
строка 2219

Код:

$QUERY .= "SELECT cc_did.did ".
" FROM cc_did ".
" JOIN cc_did_destination ON cc_did_destination.id_cc_did=cc_did.id ".
" JOIN cc_card ON cc_did_destination.id_cc_card=cc_card.id ".
" WHERE (cc_callerid.activated=1 OR cc_callerid.activated='t') AND cc_did_destination.activated=1 AND cc_did.startingdate => NOW() AND cc_did.expirationdate =" написан "=>", в запросе не делается выборка из cc_callerid а проверка полей из нее делается.
Одним словом CallerID из DID-ов никогда не будет выбран
Там наверное индусы код писать начали )))) чтоб в одном запросе, да 3 ошибки.... явно даже не проверяли.

Рекомендую заменить на

Код:

$QUERY .= "SELECT cc_did.did ".
" FROM cc_did ".
" JOIN cc_did_destination ON cc_did_destination.id_cc_did=cc_did.id ".
" JOIN cc_card ON cc_did_destination.id_cc_card=cc_card.id ".
" WHERE cc_did_destination.activated=1 AND cc_did.startingdate = NOW()".
" AND cc_card.username='".$this->cardnumber."' ";
$QUERY .= "ORDER BY 1";

_________________
.
..:

#3

Спасибо! Добавил в форк.
_________________
https://github.com/nixonch/a2billing

#4

checkout_confirmation.php
Строка 94

Код:

$amount_string=sprintf("%.3f",$total_amount);

Делаем оплату через epayment к примеру 5 евро. После подтверждения платежа для пользователей с русским интерфейсом указанная строка возвращает
значение '5,000' (!с запятой!) и в таком же виде ложит его в базу.
Когда с сервера приходит подтверждение транзакции то срока '5,000' из базы конвертируется из валюты в которой пришел платеж в базовую валюту.
Это делает функция convert_currency, которая находится в Misc.php, так вот она выдает для таких чисел результат 0!!!!!
И получается, что платеж прошел, на счет сумма пришла, а баланс абонента вырос на 0 у.е.
А все из-за того что формат '%.3f' локалезависимый и надо использовать '%.3F' который не зависит от настроек локали.

Надо поменять на

Код:

$amount_string=sprintf("%.3F",$total_amount);

_________________
.
..:

#5

Этот глюк давно уже исправлен.
Busc, какой версией а2б Вы пользуетесь?
_________________
https://github.com/nixonch/a2billing

#6

Я писал конкретно о A2Billing 1.8.1 (Corylus).
Ветка о багах 1.8.х, и далеко не все могут себе менять биллинг каждый месяц как Вы.
_________________
.
..:

#7

Прошу прощения... в заголовок не глянул.
_________________
https://github.com/nixonch/a2billing

#8

busc писал(а):

... менять биллинг каждый месяц как Вы.

Менять - не менять, но апгрейдить - святая обязанность каждого Wink

_________________
https://github.com/nixonch/a2billing

#9

Если б у Вас было столько кастомизировано сколько у меня...
Мне плохо от одной мысли сделать merge с новой версией
_________________
.
..:

#10

Давайте доступ к Вашему git или svn, чтоб слить. Попробую скрестить вдумчиво.
_________________
https://github.com/nixonch/a2billing

#11

столкнулся сейчас с очень неприятным моментом: заведено порядка 5000 аккаунтов препейд с идентичными настройками и все бы вроде хорошо, но заметил что бывают ситуации, когда с аккаунта производятся звонки, а деньги не списываются. К примеру есть аккаунт у него начальный баланс 3$, смотрю его историю звонков он назвонил уже на 25$, и при мне звонит в данный момент, заканчивает разговор, а у него все равно 3 бакса Evil or Very Mad

и таких случаев отскал уже 5 за посление три дня, из последних таких на балансе 10$ - звонит, поговорил с минуту, остаток такой же, в итоге вручную снял сумму, только после этого звонки этого абонента стали тарифицироваться
даже не знаю, где искать косяк Crying or Very sad

#12

Читать форум нужно регулярно стараться, тогда будете в теме. Эта проблема уже обсуждалась.
Но если "по быстрому", то советую обновить астериск - патч уже добавили на днях во все ветки в транк. или дождаться следующего релиза.

#13

так это баг астериска? у меня версия 1.6.2.15

#14

Да
http://asteriskforum.ru/viewtopic.php?p=46697#46697

#15

так как в логе постоянно валится ошибка:

Цитата:

You are *required* to use the date.timezone setting or the date_default_timezone_set() function

а также перестает отображаться дашборд после апгрейда php до 5.3 - решением было (как описано тут) вставить
в файлы
/var/lib/asterisk/agi-bin/a2billing.php и /var/www/localhost/htdocs/common/lib/Misc.php
строчки

Код:

date_default_timezone_set('Europe/Moscow');

второй строкой, в начале файла, сразу за

#16

а если в php.ini

Цитата:

[Date]
; Defines the default timezone used by the date functions
date.timezone = Europe/Moscow

Мне помогло
_________________
.
..:

#17

извращение ибо костыль. там где много сайтов или несколько биллингов под разных клиентов будет уже проблема.
добавление опции в настройки само собой напрашивается (я кстати nixon'а уже давно прошу сделать это)

#18

Даже если несколько биллингов стоит... мне кажется серверное приложение (a2billing.php) должно работать во временной зоне сервера. Asterisk работает же в зоне которая в системе стоит и CDR конечно делает в той же зоне.
Могу ошибаться конечно, доказательств из кода не имею, пока Cool

.
Временная зона клиента должна быть учтена только при отображении данных у него в кабинете. Хранение данных должно быть в у всех в зоне сервера.
И по времени делится тарифный план на стороне сервера, потому что тарифы по времени дает аплинк, который про часовой пояс звонящего ничего не знает и авторизует звонок по своему часовому поясу.
_________________
.
..:

#19

Григорий, ты мыслишь слишком узко (извини если звучит грубо). а ведь ситуации могут быть разные.
именно поэтому я стараюсь, если есть возможность, не менять глобальные настройки сервера. под конкретную апликуху одно надо а под другую может завтра другое понадобится - получится конфликт. поэтому лучше предусматривать такие моменты заранее, тем более что конкретно в этой вот ситуации делов ровно на 15 минут - добавить в биллинг новую опцию и ключик в базе. я думаю я даже сам бы мог такое сделать, (правда у меня это займет уже все 3 часа а не 15 минут но думаю я бы справился).
вот пример для чего может понадобится такое - сервер стоит у более дешевого хостера в германии а клиент в мск и соответственно нужно чтобы биллилось все под клиента в Мск времени. могу еще с пяток причин выдумать.

#20

Баг в расчётах статистики

В дашбоарде в REFILLS INFO, не учитывает отрицательные суммы.

Как повторить: Например у клиента на счету $100, добавляем ему еще 70, но потом например передумали (какоето событие не случилось когда должно было бы. или по ошибке положили ему не 70 а 170, ну всякое бывает) и хотим минусовать на эти 70 назад. делаем ему платеж с суммой -70, тотал у клиента меняется назад на $100, как и должно было бы быть. НО. в статистиске дашбоарда REFILLS INFO в нашем случае покажет не 100 а 170 что не соответсвует истине. по логике выходит что этот кусок кода не считает минусовые суммы в статистике откуда он берет данные для расчета. явно баг...

#21

Не знаю, обсуждалось уже или нет, но в a2b версии 1.8.1 имеется следущий баг:
возьмем, к примеру два направления: Бельгия стац. код 32 по цене 0,01 и Бельгия моб код 3248 по цене 0,1
Набираем номер Бельгия моб. в следущем формте: 32__485123456 и наш биллинг определяет его как Бельфия стац. , так как он нашел соответстие в тарифах по коду 32

Добавил строку $phonenumber = preg_replace('(\D+)', '', $phonenumber); в файл lib/Class.RateEngine.php после 88 строки

function rate_engine_findrates (&$A2B, $phonenumber, $tariffgroupid)
{

Строка удалет все нецифровые символы из набранного номера

ps. возможно есть лучшие варианты, но у меня только базовые знания программирования

#22

рекомендую проапдейтиться. уже 1.9.4 с мая доступна. если не ставили какието свои собственные патчи то будет крайне легко - выполните все .sql апдейты "сверху" своей базы (это безопастно, но сделайте бэкап на всякий случай) а затем просто разверните новые .php файлы вместо старых. все должно заработать со старыми данными из базы без проблем. рекомендую ветку от nixon, это своего рода "расширенная" версия от арески и полностью совместима. к слову сказать он намного активнее работает над a2b чем сам арески в последнее время, за что честь и хвала ему. Smile

#23

Upgrade, конечно, делать нужно.
но пока других багов не видно, а в новой версии они, возможно, еще не обнаружены. Smile

К тому же уже сделанная частичная переделка интерфейса под свои нужды останавливает, так как некоторые изменения никак не задокументировал...

#24

Можно выкусить внесенные изменения скачав оригинальный архив с версией что и у вас и путем сравнения сделать патчи. Это нужно сделать в любом случае если не хотите остаться на бажной версии и через пять лет. Полученные патчи потом можно на любую версию натянуть я думаю если конечно они не меняют кардинально код. По крайней мере попробовать можно и нужно.

#25

almor писал(а):

К тому же уже сделанная частичная переделка интерфейса под свои нужды останавливает, так как некоторые изменения никак не задокументировал...

Более чем... Продолжая традиции areski, не писать талмуды, а писать подстрочные хелпы, всё должно быть интуитивно понятно. Кроме того, с удовольствием отвечу на вопросы.
Удачи!
_________________
https://github.com/nixonch/a2billing

#26

радостная новость: наконец-то в Asterisk-1.8.8.0-rc1 починили баг из-за которого биллинг криво считал, начиная считать с первого гудка а не после ответа вызываемой стороны. баг был именно в астериске - после апдейта с предыдущей версии все стало считать как надо.

#27

Какой биллинг? Может в CDR время неправильно записывалось?
_________________
Gentoo Linux || Asterisk 13.1-cert2
Решения телефонии на базе Asterisk || http://it-need.ru

#28

a2b. но дело было 100% в астериске (чтото с сигнализацией). впрочем уже не важно, так как починили.

#29

Странно - у меня 1.8.7, везде SIP-транки (МТТ, telphin, comtube)- только что проверил биллинг на предмет правильности подсчета - все ОК.
_________________
P4 3.0 + 1Gb CentOS 5.8 Aster 1.8.16
Не люблю gui-сборки: натуральный продукт вкуснее.
И еще: я ПРОФИ так как НЕ ЛЕНЮСЬ читать литературу.

#30

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

#31

ссылка до кучи. может кому будет полезна.
http://sysadminman.net/blog/2011/a2billi ... esale-2318
добавлю только что я ничего этого не делал, просто проапдейтил астериск до 1.8.8.0-rc1 и проблема решилась сама собой.

#32

Обнаружил баг в версии 1.8.1. Заглянул в git - там та же проблема сидит в последнем релизе.
Симптомы:
- Для всех абонентов в Receipt не включаются звонки за ночь предыдущего дня биллинга.
- Для всех абонентов в Receipt не включаются paid chrges генерированные системой (например a2billing_subscription_fee.php) ночью предыдущего дня биллинга.
- Для всех абонентов в Invoice не включаются unpaid chrges (которые ручками создаются) за ночь предыдущего дня биллинга.

Ночь предыдущего дня биллинга это начиная с 00:00:00 по время запуска скрипта Cronjobs/a2billing_batch_billing.php в день предыдущего биллинга. В CentOS 5.3 это время 06:00:00, т.е. с 00:00:00 - 06:00:00 услуги не будет посчитаны.

смотрим в Cronjobs/a2billing_batch_billing.php
Суть в том что дата-время предыдущего биллинга записывается в базу в момент записи т.е. CURRENT_TIMESTAMP, а это в моем случае cron делает в 06:00:00.
Когда приходит день биллинга, то скрипт формирует условие поиска звонков и chrges от даты последнего биллинга по текущий день но без указания времени.
Т.е. биллинговый период будет для прошлого месяца 2011-10-01 06:00:00 - 2011-11-01 00:00:00. если день биллинга установлен 1.
Итого мы теряем либо 6 часов прошлого либо 6 часов текущего периода. Смотря с какой стороны смотреть.

Выход как всегда есть простой.
Строка 203

Код:

$field_insert = "id_card";
$value_insert = " '$card_id'";

меняем на

Код:

$field_insert = "id_card, date";
$value_insert = " '$card_id', '$date_now'";

Это изменение будет писать в базу дату-время последнего биллинга со временем 00:00:00. Что позволит захватывать период полностью и не терять предоставленные услуги и деньги.
_________________
.
..:

#33

Полезно. Сенк!
_________________
https://github.com/nixonch/a2billing

#34

Мда.... Чем дальше в лес... Столкнулся с багом неприятным.
Проверял в версии 1.9.4 - баг присутствует.

Проявления:
Платеж Paypal на сумму например 100 долл. в биллинге, а в самом Paypal реально прошло 2 долл.

Как такое возможно?
Страница на которой делается переадресация на сервер Paypal содержит данные о предстоящей транзакции, эти данные уже сохранены в БД. Злоумышленник меняет в запросе сумму и отправляет сфабрикованный запрос на сервер Paypal. Когда от сервера Paypal приходит подтверждение - вызывается customer/checkout_process.php, в котором сначала делается проверка пришедшего платежа на сервере Paypal и если проверка прошла успешно, то платеж проводится в биллинге и пополняется баланс абонента. И тут главная засада! платеж проводится с суммой которая была указана при формировании запроса на сервер. Если было выбрано 100 долл. - то пройдет 100 долл., а злоумышленник мог вполне провести 2 долл. и за ночь вызвонить все в кубу.

Свой патч не ложу поскольку у меня там весь модуль переписан вдоль и поперек, но способ решения опишу. Надо читать из POST переменных mc_gross и в строках

Код:

case "paypal":
$currCurrency = $mc_currency;
if($A2B->config['epayment_method']['charge_paypal_fee']==1){
$currAmount = $transaction_data[0][2] ;
}else{
$currAmount = $transaction_data[0][2] - $mc_fee;
}

сделать

Код:

case "paypal":
$currCurrency = $mc_currency;
if($A2B->config['epayment_method']['charge_paypal_fee']==1){
$currAmount = $mc_gross;
}else{
$currAmount = $mc_gross - $mc_fee;
}

_________________
.
..:

#35

Цитата:

радостная новость: наконец-то в Asterisk-1.8.8.0-rc1 починили баг из-за которого биллинг криво считал, начиная считать с первого гудка а не после ответа вызываемой стороны. баг был именно в астериске - после апдейта с предыдущей версии все стало считать как надо.

Спасибо за новость. Очень полезно.

Но из за этого изменения при работе с мультифоном возникла следующая проблема: Мегафон заведен как DID. При входящем звонке скрипт обрабатывается и отправляет как положено далее по маршруту. Но сразу приходит отбой AGI Script a2billing.php completed, returning 4
Пришлось отправить мультифоны в отдельный контекст
[multifon-a2b]
exten => _X.,1,Answer()
exten => _X.,n,DeadAGI(a2billing.php,1,did)
exten => _X.,n,Hangup

#36

DeadAGI??? Shocked

уже давно не используется и наоборот - a2b уже давно с AGI работает корректно!
добавьте exten => h,1,Hangup

#37

busc, кажется paypal сменил API...