BiTel

1. договор №1:
Бесплатный трафик: 132 120 576 байт.
Цена 1-ого МБ: 0.99 руб.
Прокачка за месяц: 350 244 145 байт.
!Наработка за месяц: 0.00 руб.

2. договор №2:
Бесплатный трафик: 300 000 000 байт.
Цена 1-ого МБ: 0.99 руб.
Прокачка за месяц: 1 074 451 393 байт.
!Наработка за месяц: 1.94 руб.


root@bgbilling:/usr/local/BGBillingServer# ./server_status.sh
BGBillingServer v 4.4 build 166 from 07.04.2008 19:28:34
Started: 28.04.2008 20:41:31 Uptime: 0 d 12:23:54
Memory total: 36 134 912; max: 266 403 840; free: 9 551 888
Connections pool status Idle: 4; Active: 0; maxActive: 300; maxIdle: 20

Ошибок в логах не найдено.

И еще вопрос BGBilling 4.4 это какая версия альфа или бета?
Может быть нам стоило поставить версию 4.3?

dialup вер. 4.4 сборка 50

Переобсчет ситуацию меняет?
4.4 текущая стабильная версия, в 4.3 такие же ошибки есть скорее всего тоже, т.к. данная подсистема не менялась уже давно.

нет не меняет

Прпробовал разные комбинации:
1. Убирал бесплатный трафик. Все считается правильно.
2. Убирал фильтр по месяцам. Не помогло.
3. Уменьшал бесплатный трафик. Наработка за месяц меняется, но все равно считает не правильно.

В первом фильтре по времени попробуйте сделать месяцы одной строкой.. Т.е. 1-6,9-12

Неправильно сказал, не пробуйте.

Собрал тариф похожий снова работает. Вроде все учел, в т.ч. ошибку при прошлом тестировании учел.
Кидайте в личку ССШ доступ к вашей базе, буду смотреть на месте.

Отправил.

Дайте название договора. 1 и 2 в вашей базе..

1. ISPU014/2008
2. ISPU066/2008

Починил. При переобсчете наработка корректная. Обновление у вас поставил. Просьба понаблюдайте, при дальнейшем обсчете как ситуация?

Да спасибо. Заработало.
У меня еще было несколько договоров с такой проблемой.
Проверил, все ок.
Естественно буду наблюдать дальше.
Скажите в чем была проблема?

Проблема была одна и та же сначала в радиуса, затем в переобсчетчике. Тарифный запрос перед отправкой в дерево не создавался заново, а использовался существующий с заменой атрибутов. Вроде как оптимизация. Реально копейки. А в запросе оставались атрибуты от предыдущего прохода по дереву, в частности фильтры по времени ставят там специальные маркеры, что вроде как запрос в фильтр попал уже. Ну и не "проходил" такой запрос второй раз.