КРИТИЧЕСКАЯ ошибка с ежемесячным расчетным периодом

Instruktor

У меня большинство тарифов с плавным списанием.
Вчера думал над проблемой.
Есть предположение, что баланс пользователям восстанавливать таки не нужно т.к. количество списаний в РП ограничено, просто будет неравномерность по скорости списания. И концу октября все должны выйти на правильную сумму.
Поправьте если ошибаюсь.

Magnum72

Instruktor писал(а):У меня большинство тарифов с плавным списанием.
Вчера думал над проблемой.
Есть предположение, что баланс пользователям восстанавливать таки не нужно т.к. количество списаний в РП ограничено, просто будет неравномерность по скорости списания. И концу октября все должны выйти на правильную сумму.
Поправьте если ошибаюсь.

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

Vans · Сообщение **Vans** » Ср окт 01, 2008 08:30

Пропустил нахрен сий замечательный момент м глюком.
Пользователи с плавным списанием, на данный момент (9:27) со всех списалось как за пол дня если бы период длился реальный месяц (т.е. до 1 ноября).

Yasasha

Так какое-же значение должно быть canonical_len ?. По расчетам выходит 31*24*60*60 = 2678400.
И нужно ли его менять?

Instruktor

Не завидую тем, кто впервые засечёт эту проблему завтра!

AndrewE

блин за такой косяк минимум литр ставить нужно

Или предупреждать за пару недель.
-10000

Voronok

Я так понимаю, что ошибка затрагивает только тех абонентов, которые были подключены 27, 28,29,30 сентября и 1 октября, т.к. именно им назначается укороченный расчетный период?

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

Vans · Сообщение **Vans** » Ср окт 01, 2008 08:46

Vans писал(а):Пропустил нахрен сий замечательный момент м глюком.
Пользователи с плавным списанием, на данный момент (9:27) со всех списалось как за пол дня если бы период длился реальный месяц (т.е. до 1 ноября).

И при том это по отчетам. А реально списалось какбудто месяц за два дня пройдет.

Voronok

У меня, например, поле canonical_len выглядит следующим образом:

Код: Выделить всё

mysql> select id,start_date,end_date,canonical_len from discount_periods where id>919;
+-----+------------+------------+---------------+
| id  | start_date | end_date   | canonical_len |
+-----+------------+------------+---------------+
| 920 | 1221854400 | 1222171001 |       2592000 |
| 921 | 1222200000 | 1224792000 |       2592000 |
| 922 | 1222286400 | 1224878400 |       2592000 |
| 923 | 1222372800 | 1224964800 |       2592000 |
| 924 | 1222459200 | 1225054800 |        432000 |
| 925 | 1222545600 | 1225141200 |        345600 |
| 926 | 1222632000 | 1225227600 |        259200 |
| 927 | 1222718400 | 1225314000 |        172800 |
| 928 | 1222804800 | 1225486800 |         86400 |
+-----+------------+------------+---------------+
9 rows in set &#40;0.01 sec&#41;

mysql>

Все кроме последнего думаю поставить в 2592000, а последнее в 2678400. Вопрос в том, стоит ли это делать?

mikkey finn

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

Voronok

Я только изменил окончание расчетного периорда и все (ибо нетаповцы в первом посте сказали сделать только это). Абонентка у затронутых абонентов перестала списываться вообще. Я так понимаю, из-за того, что теперь остаток средств биллинг будет "растягивать" на месяц. Пока наблюдаю.

jack7 · Сообщение **jack7** » Ср окт 01, 2008 11:05

Magnum72 писал(а):пиляд, порнография какая то..
решил проверить не ошибся ли я с канонической длиной периода
дождался часа ночи, создал период длиной в 1 месяц начинающийся 1 октября в 01:00:00, он мне создал период с датой начала 1 октября в 01:00:00 и датой завершения 1 ноября в 00:00:00
я понимаю переход на зимнее время, но фигали он дату завершения поставил в 00 часов а не в 01.
Скажите правильную какноническую длину расчетного периода.

у себя поставил 2682000, вычисленное как 1225479600 - 1222797600

то есть было

Код: Выделить всё

+------+------------+------------+---------------+-------------------------+---------------+------------+-----------------+-----------+-------------------+
| id   | start_date | end_date   | periodic_type | next_discount_period_id | canonical_len | is_expired | custom_duration | static_id | discount_interval |
+------+------------+------------+---------------+-------------------------+---------------+------------+-----------------+-----------+-------------------+
| 6893 | 1222797600 | 1225479600 |             3 |                       0 |         86400 |          0 |               1 |         2 |                 0 |

стало

Код: Выделить всё

+------+------------+------------+---------------+-------------------------+---------------+------------+-----------------+-----------+-------------------+
| id   | start_date | end_date   | periodic_type | next_discount_period_id | canonical_len | is_expired | custom_duration | static_id | discount_interval |
+------+------------+------------+---------------+-------------------------+---------------+------------+-----------------+-----------+-------------------+
| 6893 | 1222797600 | 1225479600 |             3 |                       0 |      2682000  |          0 |               1 |         2 |                 0 |

то есть секунд на 31 день

Код: Выделить всё

bash-3.1$ echo "2682000/3600/24" | bc -l
31.04166666666666666666

jack7 · Сообщение **jack7** » Ср окт 01, 2008 11:32

это все для периода с 0 часов 1 числа до 0 часов 1 числа седующего месяца

Код: Выделить всё

bash-3.1$ ptime -h 1222797600
Wed Oct  1 00&#58;00&#58;00 2008
bash-3.1$ ptime -h 1225479600
Sat Nov  1 00&#58;00&#58;00 2008

mikkey finn

протупил, не прочел первый пост.
Перекрестился, что не обновился, если открыли доступ к обновлениям, оплаченный недели две или три назад.
5.2.1-005 вычислило длину рассчетного периода 2682000...
Видимо, у меня на 005 такой проблемы нет... и слава яйцам.

Voronok

Вопрос к нетаповцам: за что отвечает длина периода в поле canonical_len? Просто есть подозрение, что оно отвечает за частоту списывания абонплаты. Таким образом, если при дате окончания расчетного периода 2-го октября абонплата списывалась слишком быстро, то при изменении даты окончания она должна списываться медленнее, чем положено. Так вот, мне интересно, если изменить вручную длину периода, не станет ли абонплата списываться в обычном режиме и не поведет ли это в дальнейшем к корректировке баланса абонента? И чем чревато в будущем то, что у абонента расчетный период с правильными датами начала и окончания, но с уменьшенным значением canonical_len?