Некорректное списание
Некорректное списание
Имеется тариф с двумя услугами - передача трафика (с включённым предоплаченным) и абонка (1000 руб), деньги списываются в начале расчётного периода (1 месяц, с 1-го по 1-е). В сентябре логину была сначала подключена услуга передачи трафика, а потом в конце месяца подключена и услуга абонки с датой начала 1 октября 0:00:00 в надежде на то, что в начале нового месяца будет списано ровно 1000 рублей. Первое списание по логину произошло 1 октября в 0:01:48, списалось 34,024 рубля. Следующим списанием (2 октября в 00:29) с лицевого счёта абонента сбрило круглую тысячу рублей и в итоге мы имеем, что по тарифу всего списано 1034 рубля. Как это понимать?
Более того, неоднократно замечено, что если абонплата списывается чуть позже начала расчётного периода, то трафик, посчитанный в период между началом периода и списанием, тарифицируется по цене перерасхода (то есть в этот момент ещё нету предоплаченных мегабайтов).
5.2.1-006 - апдейт последний.
Более того, неоднократно замечено, что если абонплата списывается чуть позже начала расчётного периода, то трафик, посчитанный в период между началом периода и списанием, тарифицируется по цене перерасхода (то есть в этот момент ещё нету предоплаченных мегабайтов).
5.2.1-006 - апдейт последний.
Я полагаю, сейчас на форуме начнется бойня, как все придут на работу и увидят, что сделал UTM 5.2.1-006 в ночь с 1 на 2 октября 
Проверьте свои расчетные периоды - для октября он создал расчетный период длиною в сутки. А следующий после него - до 1 ноября до 23:00.
Видимо, в связи с переходом с летнего времени в октябре.
Вопрос к разработчикам - как можно подредактировать списания в базе? Услуги перерасчет каждому добавлять не хочу.
Достаточно ли будет удалить строки из таблиц discount_transactions_all и поправить поле balance в accounts ? Или такие изменения сделают еще хуже?

Проверьте свои расчетные периоды - для октября он создал расчетный период длиною в сутки. А следующий после него - до 1 ноября до 23:00.
Видимо, в связи с переходом с летнего времени в октябре.
Вопрос к разработчикам - как можно подредактировать списания в базе? Услуги перерасчет каждому добавлять не хочу.
Достаточно ли будет удалить строки из таблиц discount_transactions_all и поправить поле balance в accounts ? Или такие изменения сделают еще хуже?
-
- Сообщения: 1612
- Зарегистрирован: Пт ноя 10, 2006 15:23
Про эту проблему я в курсе, в моей сборке баг уже пофиксен. Расчётный период создался как нужно - до 1 ноября сразу же.Alan писал(а):Я полагаю, сейчас на форуме начнется бойня, как все придут на работу и увидят, что сделал UTM 5.2.1-006 в ночь с 1 на 2 октября
Проверьте свои расчетные периоды - для октября он создал расчетный период длиною в сутки. А следующий после него - до 1 ноября до 23:00.
Видимо, в связи с переходом с летнего времени в октябре.
Вопрос к разработчикам - как можно подредактировать списания в базе? Услуги перерасчет каждому добавлять не хочу.
Достаточно ли будет удалить строки из таблиц discount_transactions_all и поправить поле balance в accounts ? Или такие изменения сделают еще хуже?
Реквестирую ссылку на utm5-багзиллуВитька писал(а):Всё-таки хотелось бы получить комментарии от официальных представителей Нетап. Если это известный баг, то как его решать, если неизвестный, то буду багрепорт катать.

Вообще, реакция суппорта UTM5 мне не понятна. Ни одного слова по этому поводу. Тем более, что косяк налицо.
Кстати, есть еще подозрение в интересном баге glibc2. Прошу всех "пострадавших" сообщить свою ОС, на которой вкалывает UTM5. Если Linux, то помимо utm'ки надо бы копать в сторону glibc (mktime() ). Для некоторых дат она накидывает лишний час.
У меня стоит на Debian'е (etch).
Код: Выделить всё
billing:~# apt-cache show libc6 | grep Ver
Version: 2.3.6.ds1-13etch9+b1
Version: 2.3.6.ds1-13etch7
- Lex
- NetUP Team
- Сообщения: 623
- Зарегистрирован: Ср мар 09, 2005 12:12
- Откуда: НетАП
- Контактная информация:
По описанию чего-то конкретного сказать нельзя. Нужны лог-файлы ядра и дамп базы.Витька писал(а):Всё-таки хотелось бы получить комментарии от официальных представителей Нетап. Если это известный баг, то как его решать, если неизвестный, то буду багрепорт катать.
Так что, если считаете что это баг, пишите багрепорт - посмотрим.
Логи? не вопрос. Адрес багрепорта, пожалуйста, в студию.Lex писал(а):По описанию чего-то конкретного сказать нельзя. Нужны лог-файлы ядра и дамп базы.Витька писал(а):Всё-таки хотелось бы получить комментарии от официальных представителей Нетап. Если это известный баг, то как его решать, если неизвестный, то буду багрепорт катать.
Так что, если считаете что это баг, пишите багрепорт - посмотрим.
дамп базы? Это шутка? Или нужны конкретные таблцы? А то приаттачить 18Гб данных, это немного неудобно... что ли...
- Lex
- NetUP Team
- Сообщения: 623
- Зарегистрирован: Ср мар 09, 2005 12:12
- Откуда: НетАП
- Контактная информация:
Раздел "Сообщить об ошибке" в личном кабинете у нас на сайте.vitalka писал(а): Логи? не вопрос. Адрес багрепорта, пожалуйста, в студию.
дамп базы? Это шутка? Или нужны конкретные таблцы? А то приаттачить 18Гб данных, это немного неудобно... что ли...
Прикреплять 18 гигабайт не нужно, достаточно заархивировать и выложить на ftp, http или сделать доступным для загрузки любым разумным способом(по scp, например).
Давайте тогда для начала пойдём от противногоLex писал(а): По описанию чего-то конкретного сказать нельзя. Нужны лог-файлы ядра и дамп базы.
Так что, если считаете что это баг, пишите багрепорт - посмотрим.

Как по логике UTM5 правильно осуществить задумку, если я при расчётном периоде в один месяц (с 1-го по 1-е число) хочу подключить абоненту услугу абонплаты в составе тарифного плана, и чтобы включилась она ровно 1 числа, и за неё биллинг списал целую круглую сумму по тарифу? Напишите верную последовательность действий.
Было замечено, что если выставить дату начала услуги на первое число, но не поставить "Пересчитывать абонплату", то биллинг проигнорирует дату начала, и в момент подключения услуги спишет за остаток месяца, в котором эта услуга подключена. Если же поставить галочку, то получилось как у нас - в начале месяца списаны непонятные 34 рубля, которые не вписываются никуда (услуга была подключена 30 сентября в 23:30, то есть за полчаса до конца расчётного периода), а потом уже списано по полной программе - 1000 рублей
-
- Сообщения: 1612
- Зарегистрирован: Пт ноя 10, 2006 15:23
То есть ровно в 0:00:00 и ни секундой раньше, ни секундой позже?mikkey finn писал(а):1000/30 будет примерно ваши 34 рубля. Оно списало за весь день, когда была подключена услуга. Предложение - привязывать услугу в тот момент, когда она должна начать действовать.
