BiTel

Подскажите как биллинг так насчитал? Разница в 5 копеек с тем что должно быть при расчете руками
994000×29÷30×1,18=1133822,67

ps быстрая проверка приводит к подозрению что период снятия АП (29/30) как то неправильно округлился, в соответствии с тем что отображает биллинг это 0,96666663 хотя на самом деле 0,96666666... как так?

pps а сейчас заметил что в супердоговоре наработка этого договора - 63 копейки. WTF?

предвосхищая будущие вопросы:
1. Клиент: вер. 5.1 сборка 511 от 28.04.2011 19:00:59
os:Linux; java:Sun Microsystems Inc., v.1.6.0_22
Сервер: вер. 5.1 сборка 641 от 16.05.2011 21:23:46
os:SunOS; java:Sun Microsystems Inc., v.1.6.0_24

2.в contract_account 1133822.62500

Неплохо живете

Там на сколько я помню погрешность есть....но если чесно не совсем понял проблемы

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

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

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

up

up! как внедряться если биллинг свою основную задачу - считать правильно не делает правильно?

покажите результат запроса

И еще мы выложили обновление по этому поводу, но оно вам, возможно, не поможет, если таблица contract_account неверная - есть подозрение на это.

И еще включите режим debug в log4j и тогда в логах при начислении будет что-то типа вот этого


Покажите какой там cost . Скорее всего правильный .

Спасибо за наводку куда копать, я что то про дебаг и не подумал, надо было посмотреть шедулер - как он считает, да.
Обновился вчера под конец рабочего дня. Сейчас сделал откат и проверил. И в новой и в старой версии счиалось правильно.
07-06/17:27:43 DEBUG [pool-1-thread-1] Calculator - Add cost cache cid: 9734; sid: 1; cost: 1133822.66666666666666666666666666657
07-06/17:27:43 DEBUG [pool-1-thread-1] Calculator - Add detail amount cache cid: 9734; sid: 1; mid: 5; eid: 0; cost: 1133822.6666666667
А вот похоже проблема была с табличкой все-таки.
Сейчас:


А было (откатился и проверил):


Поле сумма было флоат, а после обновления - децимал. Ошибку убрало.

Ясно . Это наша ошибка . Вы скорее всего скачали с сайта сервер , поставили и не обновляли сразу . У нас там в dump-е неправильная таблица была , а потом при первом обновлении вызывалось

ALTER TABLE contract_account MODIFY summa DECIMAL(15,5);

Исправили, теперь dump актуальный.