forum.bitel.ru
http://forum.bitel.ru/

Непонятный баланс на границе месяца
http://forum.bitel.ru/viewtopic.php?f=5&t=2120		 Страница 1 из 3
Автор:  jack7 [ 03 апр 2009, 12:14 ]
Заголовок сообщения:  Непонятный баланс на границе месяца
Есть пользователь, с непонятным балансом
У него исходящий отстаток на март не равен входящему остатку на начало апреля

до цифры 560 (исходящий остаток на конец месяца) все верно, далее в начале месяца апреля должно было снятся 500 руб абонплаты за тариф и 50 за отдельную услугу, а снялось 910.
Автор:  Администратор [ 03 апр 2009, 12:29 ]
Заголовок сообщения: 
А если фиктивный приход занести-удалить за март, ситуация выравнивается?
Автор:  jack7 [ 03 апр 2009, 12:43 ]
Заголовок сообщения: 
Администратор писал(а):
А если фиктивный приход занести-удалить за март, ситуация выравнивается?


да, ситуация выравнялась
Автор:  Akhmat [ 03 апр 2009, 12:51 ]
Заголовок сообщения: 
Достали эти ошибки с балансом :evil:
Вчера изза таких ошибок(сообщили мне о нескольких таких случаях за день) проделал следующую операцию, снес записи в contract_balance по группе где интернет услуга предоставляется которые позже апреля месяца, в надежде, что при пересчёте сессий, входящий и исходящий остатки на границе месяцев будут совпадать. Пересчитал, надежды оправдались частично - исх. и вх. остатки совпадают, но все приходы за первые два дня апреля не посчитались. Пришлось дополнительно всем этим договорам нулевые платежи вносить.

Эти пикантные особенности биллинга, причем давно известные. Не одна тема поднята с данной проблемой, а разработчики чуть подправят, не проверят толком, и выдают обновления. Если что, клиенты отдебагят(если б по собственному желанию ещё), и ткнут носом очередной раз в одну и ту же ошибку. Чего напрягаться то, перепроверять. :evil:
Хотя бы пару месяцев спокойствия и безмятежности в работе биллинга.

Нето чтобы очень напрягает это, но такие операции проделывать, душа не лежит совсем, это же автоматическая система расчётов, а не полуавтоматическая.

PS
Уже говорил,
http://www.bgbilling.ru/forum/viewtopic.php?t=2026
что запрет вносить платежи/расходы будущим числом не помогают избежать появления записей в контракт_баланс будущими месяцами. Я просто забыл в конце прошлого месяца удалить их включая апрель месяц, ато б такого у меня не было.
Найдите где создаются эти записи.
Автор:  stark [ 03 апр 2009, 13:24 ]
Заголовок сообщения: 
Это не обязательно платежи. вы могли насчитать наработку за будущий месяц (запустит перобсчет), хотя вроде это запрещено ..расход повесить за будущее число ..Мы не против исправить эту ошибку , если вы нам сообщите как в это получили ..вытащите лог запросов по конртеному договору, где что-то не так.. мы не можем исправить то , что сами не можем воспроизвести .. можно сделать просто внешний скрипт, который будет удалять все балансы за будуще число и запускать его по крону(или планировщику виндовс в вашем случае) .. можно конечно при каждой опреации занесения платежа пересчитвать все баласны за все годы существования договора , но это не рационально
Автор:  Akhmat [ 03 апр 2009, 14:01 ]
Заголовок сообщения: 
stark писал(а):
Это не обязательно платежи. вы могли насчитать наработку за будущий месяц (запустит перобсчет), хотя вроде это запрещено ..расход повесить за будущее число ..

Это скорее всего не платежи и не расходы. Они не вносятся, т.к. запрещены. При переобсчёте он не пересчитавют поле приходов и расходов, (я думал что пересчитает, потому снёс все записи за апрель)

stark писал(а):
Мы не против исправить эту ошибку , если вы нам сообщите как в это получили ..вытащите лог запросов по конртеному договору, где что-то не так.. мы не можем исправить то , что сами не можем воспроизвести ..

Если бы Вы ещё были против исправить её :shock:
Да я бы сообщил как получается эта ошибка, но незнаю, пытался повторить, не получается. А ковырять аксес логи(даже не знаю что там искать и за какой период, вижу только что есть записи за будущие месяца, когда были созданы, пёс его знает), экспериментировать(дебагить), Вы уж извините, я не разработчик, всех мест не знаю, в которых создается запись эта, да и мне тоже есть чем заняться.
Это Ваш продукт, Ваши алгоритмы, Вы и разбирайтесь. Моё дело не дебагить, а сообщить о глюках, хотя по возможности готов дебагить, вынужден :evil:, Ваши проблемы, это уже и мои проблемы, технично перекинули отладку на клиентов.

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

Советуете подпорку? :) В праве ожидать от биллинга, что он сам будет какать, и сам за собой подтирать, большой уже вроде, 500 версий и обновлений вышло на него 8)

PS
Давайте подругому оформим вопрос, Вы мне скажите/объясните как убрать это, чтоб не повторялось, и я исправлю :D

Дебаг:
Пишу заново что готов проделать:
1. начисления/пересчёты наработок по всем модулям(DialUp VoIP, IPN, Абонплаты) за будущие месяцы
2. Просмотр сессий в клиенте, и в вебе за будущие месяцы.
Результат
1. Абонплата не вносится и не удаляется за будущий месяц, запись не создается, пересчёт сессий за будущие месяцы VoIP, DialUP, IPN не найдена таблица, запись не создаётся.
2. Просмотр сессий и в вебе и в клиенте, не создают запись.

Не зачто
Автор:  jack7 [ 03 апр 2009, 14:28 ]
Заголовок сообщения: 
У нас ситуация появилась так

тк ночью операторы и администраторы не работали (ночь на 1 число), в админке никто ничего не делал, бекапов в это время не было, поднял журнал запросов для данного договора - там ничего на момент ночи не было. У других пользователей того же тарифного плана подобных проблем с балансом пока не выявили.
Автор:  Akhmat [ 03 апр 2009, 14:36 ]
Заголовок сообщения: 
2 jack7
Выполни плиз
select * from contract_balance where yy>=2009 and mm>4

есть записи?
Автор:  jack7 [ 03 апр 2009, 14:41 ]
Заголовок сообщения: 
88 строк, а что это за записи?
Автор:  Akhmat [ 03 апр 2009, 14:44 ]
Заголовок сообщения: 
jack7 писал(а):
88 строк, а что это за записи?

Не у меня одного такое :lol:
Это балансы договоров за будущие месяцы, которые ещё не наступили. Когда этот месяц наступит, у этих договоров скорее всего не будут совпадать исходящий остаток на предыдущий и входящий на этот месяц. Короче косяк баланса будет железно
Автор:  jack7 [ 03 апр 2009, 15:00 ]
Заголовок сообщения: 
дак может сделать щас ?
Код:
update contract_balance set cid=0 where yy>=2009 and mm>4


пока не надо.
Автор:  skn [ 03 апр 2009, 15:01 ]
Заголовок сообщения: 
jack7 писал(а):
88 строк, а что это за записи?


можете выложить несколько строк их этой выборки?
Автор:  Akhmat [ 03 апр 2009, 15:04 ]
Заголовок сообщения: 
jack7 писал(а):
дак может сделать щас ?
Код:
update contract_balance set cid=0 where yy>=2009 and mm>4

Лучше
Код:
delete from contract_balance where yy>=2009 and mm>4
Автор:  skn [ 03 апр 2009, 15:06 ]
Заголовок сообщения: 
jack7 писал(а):
У нас ситуация появилась так

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


это не обязательно должно было произойти в ночь на первое, это могло случиться и 2 месяца наза и год...
Автор:  jack7 [ 03 апр 2009, 15:08 ]
Заголовок сообщения: 
skn писал(а):
можете выложить несколько строк их этой выборки?


Код:
+------+----+------+----------+--------+--------+--------+
| yy   | mm | cid  | summa1   | summa2 | summa3 | summa4 |
+------+----+------+----------+--------+--------+--------+
| 2009 |  5 |  232 |  -350.21 |   0.00 |   0.00 |   0.00 |
| 2009 |  6 |  232 |  -350.21 |   0.00 |   0.00 |   0.00 |
| 2009 | 11 |  246 |     9.94 |   0.00 |   0.00 |   0.00 |
| 2009 |  6 |  275 |   159.63 |   0.00 |   0.00 |   0.00 |
| 2009 | 10 |  279 |     9.90 |   0.00 |   0.00 |   0.00 |
| 2009 |  5 |  328 |  -255.00 |   0.00 |   0.00 |   0.00 |
| 2009 |  8 |  328 |  -255.00 |   0.00 |   0.00 |   0.00 |
| 2009 | 12 |  341 |    13.15 |   0.00 |   0.00 |   0.00 |
| 2009 | 12 |  404 |   -14.10 |   0.00 |   0.00 |   0.00 |
| 2009 |  5 |  540 |  -484.50 |   0.00 |   0.00 |   0.00 |
| 2009 |  7 |  643 |   379.26 |   0.00 |   0.00 |   0.00 |
| 2009 |  7 |  648 |    32.28 |   0.00 |   0.00 |   0.00 |
| 2009 |  6 |  656 |   -50.14 |   0.00 |   0.00 |   0.00 |
| 2009 |  8 |  669 |   -32.07 |   0.00 |   0.00 |   0.00 |
| 2009 |  6 |  713 |   405.25 |   0.00 |   0.00 |   0.00 |
| 2009 | 11 |  746 |   -85.53 |   0.00 |   0.00 |   0.00 |
| 2009 |  5 |  747 |     4.24 |   0.00 |   0.00 |   0.00 |
| 2009 |  7 |  756 |  -499.34 |   0.00 |   0.00 |   0.00 |
| 2009 | 10 |  756 |  -499.34 |   0.00 |   0.00 |   0.00 |
| 2009 |  5 |  772 |   113.38 |   0.00 |   0.00 |   0.00 |
| 2009 | 12 |  772 |   113.38 |   0.00 |   0.00 |   0.00 |
| 2009 | 11 |  934 |  -346.86 |   0.00 |   0.00 |   0.00 |
| 2009 |  5 |  997 |    34.07 |   0.00 |   0.00 |   0.00 |
| 2009 |  6 | 1018 |  -225.80 |   0.00 |   0.00 |   0.00 |
| 2009 |  5 | 1039 |  -338.71 |   0.00 |   0.00 |   0.00 |
| 2009 |  5 | 1061 |  -345.41 |   0.00 |   0.00 |   0.00 |
| 2009 |  7 | 1100 |  -690.00 |   0.00 |   0.00 |   0.00 |
| 2009 | 12 | 1105 |  -468.79 |   0.00 |   0.00 |   0.00 |
| 2009 |  5 | 1143 |    30.26 |   0.00 |   0.00 |   0.00 |
| 2009 | 10 | 1147 |    -0.63 |   0.00 |   0.00 |   0.00 |
| 2009 | 11 | 1147 |    -0.63 |   0.00 |   0.00 |   0.00 |
| 2009 | 12 | 1147 |    -0.63 |   0.00 |   0.00 |   0.00 |
| 2009 |  5 | 1173 |   790.38 |   0.00 |   0.00 |   0.00 |
| 2009 |  6 | 1296 |   100.00 |   0.00 |   0.00 |   0.00 |
| 2009 |  6 | 1334 |  -407.79 |   0.00 |   0.00 |   0.00 |
| 2009 |  5 | 1366 |  -277.78 |   0.00 |   0.00 |   0.00 |
| 2009 |  7 | 1445 |    51.93 |   0.00 |   0.00 |   0.00 |
| 2009 | 12 | 1445 |    51.93 |   0.00 |   0.00 |   0.00 |
| 2009 | 12 | 1454 |    26.05 |   0.00 |   0.00 |   0.00 |
| 2009 | 11 | 1469 |    14.96 |   0.00 |   0.00 |   0.00 |
| 2009 | 12 | 1469 |    14.96 |   0.00 |   0.00 |   0.00 |
| 2009 |  5 | 1532 |  -591.00 |   0.00 |   0.00 |   0.00 |
| 2009 |  6 | 1532 |  -591.00 |   0.00 |   0.00 |   0.00 |
| 2009 |  7 | 1532 |  -591.00 |   0.00 |   0.00 |   0.00 |
| 2009 |  5 | 1567 |    -4.70 |   0.00 |   0.00 |   0.00 |
| 2009 | 10 | 1574 | -1751.75 |   0.00 |   0.00 |   0.00 |
| 2009 |  9 | 1631 |  -191.42 |   0.00 |   0.00 |   0.00 |
| 2009 | 12 | 1631 |  -191.42 |   0.00 |   0.00 |   0.00 |
| 2009 |  5 | 1690 |    -2.07 |   0.00 |   0.00 |   0.00 |
| 2009 |  5 | 1705 |    17.95 |   0.00 |   0.00 |   0.00 |
| 2009 | 11 | 1705 |    17.95 |   0.00 |   0.00 |   0.00 |
| 2009 |  5 | 1718 |     0.00 |   0.00 |   0.00 |   0.00 |
| 2009 |  7 | 1719 |  -226.33 |   0.00 |   0.00 |   0.00 |
| 2009 |  5 | 1733 |    49.27 |   0.00 |   0.00 |   0.00 |
| 2009 | 10 | 1744 |   -59.37 |   0.00 |   0.00 |   0.00 |
| 2009 |  8 | 1754 |   104.30 |   0.00 |   0.00 |   0.00 |
| 2009 |  5 | 1768 |    66.60 |   0.00 |   0.00 |   0.00 |
| 2009 |  5 | 2004 |    33.05 |   0.00 |   0.00 |   0.00 |
| 2009 |  5 | 2064 |   497.92 |   0.00 |   0.00 |   0.00 |
| 2009 |  6 | 2072 |     8.67 |   0.00 |   0.00 |   0.00 |
| 2009 |  5 | 2075 |  -346.72 |   0.00 |   0.00 |   0.00 |
| 2009 |  6 | 2075 |  -346.72 |   0.00 |   0.00 |   0.00 |
| 2009 |  9 | 2185 |  -683.35 |   0.00 |   0.00 |   0.00 |
| 2009 |  5 | 2221 |  -350.00 |   0.00 |   0.00 |   0.00 |
| 2009 |  6 | 2221 |  -350.00 |   0.00 |   0.00 |   0.00 |
| 2009 |  7 | 2221 |  -350.00 |   0.00 |   0.00 |   0.00 |
| 2009 | 11 | 2221 |  -350.00 |   0.00 |   0.00 |   0.00 |
| 2009 | 11 | 2232 |   204.48 |   0.00 |   0.00 |   0.00 |
| 2009 |  5 | 2298 |    98.03 |   0.00 |   0.00 |   0.00 |
| 2009 |  7 | 2322 |    -0.20 |   0.00 |   0.00 |   0.00 |
| 2009 | 11 | 2330 |  -195.80 |   0.00 |   0.00 |   0.00 |
| 2009 | 12 | 2330 |  -195.80 |   0.00 |   0.00 |   0.00 |
| 2009 |  5 | 2333 |   -83.21 |   0.00 |   0.00 |   0.00 |
| 2009 |  5 | 2397 |  -350.20 |   0.00 |   0.00 |   0.00 |
| 2009 |  6 | 2444 |    19.29 |   0.00 |   0.00 |   0.00 |
| 2009 |  5 | 2471 |   303.23 |   0.00 |   0.00 |   0.00 |
| 2009 |  6 | 2509 |  -144.99 |   0.00 |   0.00 |   0.00 |
| 2009 |  9 | 2562 |    92.64 |   0.00 |   0.00 |   0.00 |
| 2009 |  8 | 2651 |    69.38 |   0.00 |   0.00 |   0.00 |
| 2009 |  5 | 2668 |   -25.46 |   0.00 |   0.00 |   0.00 |
| 2009 |  8 | 2807 |  -368.52 |   0.00 |   0.00 |   0.00 |
| 2009 | 12 | 2807 |  -368.52 |   0.00 |   0.00 |   0.00 |
| 2009 |  5 | 2911 |  -198.73 |   0.00 |   0.00 |   0.00 |
| 2009 | 12 | 3026 |    29.58 |   0.00 |   0.00 |   0.00 |
| 2009 |  6 | 3169 |   141.36 |   0.00 |   0.00 |   0.00 |
| 2009 |  9 | 3232 |  -581.34 |   0.00 |   0.00 |   0.00 |
| 2009 |  6 | 3293 |  -106.70 |   0.00 |   0.00 |   0.00 |
| 2009 |  5 | 3533 |    -1.12 |   0.00 |   0.00 |   0.00 |
+------+----+------+----------+--------+--------+--------+
88 rows in set (0.00 sec)
Автор:  Akhmat [ 03 апр 2009, 15:11 ]
Заголовок сообщения: 
skn писал(а):
jack7 писал(а):
88 строк, а что это за записи?


можете выложить несколько строк их этой выборки?

Уже выкладывал, в прошлом месяце
http://www.bgbilling.ru/forum/viewtopic.php?t=2026

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

PS
Сори за эмоциональность некоторую:) Решение данной проблемы слишком затянулось
Автор:  skn [ 03 апр 2009, 15:12 ]
Заголовок сообщения: 
выложите запись...
Автор:  Akhmat [ 03 апр 2009, 15:14 ]
Заголовок сообщения: 
Код:
select c.title, c.comment, cb.* from contract_balance as cb, contract as c where yy>=2009 and mm>4 and c.id=cb.cid


Код:
IR-3029   Рамонов А.В.   2009   5   722308   -1125.82   0.00   0.00   0.00
Автор:  skn [ 03 апр 2009, 15:17 ]
Заголовок сообщения: 
в contract_account есть записи для этого договора за май
Автор:  Akhmat [ 03 апр 2009, 15:19 ]
Заголовок сообщения: 
Код:
select * from contract_account where cid=722308 and yy>=2009 and mm>4

пусто

Код:
select * from contract_account where yy>=2009 and mm>4

И так пусто
Автор:  skn [ 03 апр 2009, 15:40 ]
Заголовок сообщения: 
а таблицах contract_payment и contract_charge
Автор:  Akhmat [ 03 апр 2009, 15:42 ]
Заголовок сообщения: 
Код:
select * from contract_payment where dt>='2009-05-01'

Код:
select * from contract_charge where dt>='2009-05-01'

Пусто
Автор:  skn [ 03 апр 2009, 16:39 ]
Заголовок сообщения: 
включить лог запросов mysql можете?
Автор:  Akhmat [ 03 апр 2009, 18:34 ]
Заголовок сообщения: 
Как это сделать и что это даст? Потом по логу найдёте то что надо?
Автор:  skn [ 03 апр 2009, 18:44 ]
Заголовок сообщения: 
можно будет определить когда были созданы записи. вместо лога попробуйте сначала добавить столбец в таблицу contract_balance
Код:
ALTER TABLE `contract_balance` ADD COLUMN `lu` TIMESTAMP  NOT NULL AFTER `summa4`;

в это поле автоматически будет сохраняться дата последней модификации записи
Автор:  Akhmat [ 03 апр 2009, 18:44 ]
Заголовок сообщения: 
уже четыре записи будущие месяцы
Автор:  Akhmat [ 03 апр 2009, 18:49 ]
Заголовок сообщения: 
skn писал(а):
можно будет определить когда были созданы записи. вместо лога попробуйте сначала добавить столбец в таблицу contract_balance
Код:
ALTER TABLE `contract_balance` ADD COLUMN `lu` TIMESTAMP  NOT NULL AFTER `summa4`;

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

Чёто мне сыкотно :) Там же чегото ещё надо записать, чтобы он сам писал автоматически дату последней модификации? тригер чегото, разве нет? не пользовался никогда, слышал чтото такое
Автор:  Akhmat [ 03 апр 2009, 18:58 ]
Заголовок сообщения: 
Короче, бекап снимается уже, через пару часов будет готов. после этого за альтерю эту тему, если чтото надо ещё, пишите сразу. Оставлю так на ночь, утром доразберёмся)
Автор:  skn [ 03 апр 2009, 19:16 ]
Заголовок сообщения: 
Цитата:
Там же чегото ещё надо записать, чтобы он сам писал автоматически дату последней модификации? тригер чегото, разве нет? не пользовался никогда, слышал чтото такое


не надо, это фича mysql
Автор:  Jimson [ 03 апр 2009, 21:00 ]
Заголовок сообщения: 
вы опять щас пытаетесь затыкать дырку носками
подобные проблемы результат ошибок проектирования базы, избавьтесь от избыточности, хотя бы частично, если вам нужны снапшот таблицы для ускорения пересчетов то сделаете ведение этих таблиц однозначным и прозрачным....
хотя я вообще слабо понимаю необходимость таких таблиц как contract_balance, взгляда на describe достаточно что бы понять что это ортопедическое решение каких то проблем.

без обид, я буду использовать этот биллинг в любом случае и ползать по граблям пока работаю на текущем месте работы, лучшего биллинга в данном ценовом классе я не знаю :)
Страница 1 из 3 Часовой пояс: UTC + 5 часов [ Летнее время ]
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/