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

Начисление Абонплаты на пойнты.
http://forum.bitel.ru/viewtopic.php?f=16&t=2395		 Страница 1 из 1
Автор:  kompot [ 05 июн 2009, 11:33 ]
Заголовок сообщения:  Начисление Абонплаты на пойнты.
Имеется договор на услуги Телефонии (модуль phone) и Инета (модуль Dialup ).
В глобальных тарифах - только тариф на Инет.

Изображение


Имеется 1 ( остальные для наглядности временно удалены) пойнт:

Изображение

К пойнту привязан тарифный план:


Изображение

и абонентская плата:

Изображение

Вот, что представляет из себя секция тарифного плана, касающаяся абонплат:

Изображение


Вот какую наработку по догорову я получаю в итоге:

Изображение

800 рублей.

А должно быть, по моим представлениям, 140. Откуда остальное? помогите разобраться, пожалуйста.

(Периоды действия услуг, тарифов правильно проставлены.)
Автор:  Администратор [ 09 июн 2009, 12:17 ]
Заголовок сообщения: 
Версия какая ПО? Поставьте в data/log4j.xml
Код:
 <root>
                <priority value="DEBUG" />
                <appender-ref ref="ASYNC" />
        </root>

Потом запустите начисление абонок по этому договору и выложите, что в scheduler.log вывелось.
Автор:  kompot [ 09 июн 2009, 13:49 ]
Заголовок сообщения: 
BGBillingServer v 4.5 build 388 from 11.02.2009 18:49:32

В log4j_scheduler.properties устанвил DEBUG.

Результат:
Код:
DEBUG  09.06.2009 13:48:02  Looking tasks
INFO   09.06.2009 13:48:35  Running Task: Thread[Thread-48,1,main]
INFO   09.06.2009 13:48:35  PaymentRecalculator time: 01.05.2009 00
INFO   09.06.2009 13:48:35  [23:00:00; 0] Calculate past month
DEBUG  09.06.2009 13:48:35  [23:00:00; 0] Services: -1,11,12,13,14,106,68,69,70,71,93,94,95,96,97,98,99,100,101,102,103
INFO   09.06.2009 13:48:35  Memory total: 6 852 608; max: 266 403 840; free: 4 137 432
DEBUG  09.06.2009 13:48:35  [23:00:00; 0] Found service taker cid: 9526; sid: 14; date1: 01.05.2009; date2: ; col: 1
DEBUG  09.06.2009 13:48:35  [23:00:00; 0] After trimming cid: 9526; sid: 14; date1: 01.05.2009; date2: 31.05.2009
DEBUG  09.06.2009 13:48:35  [23:00:00; 0] Tariff period: 01.05.2009-
DEBUG  09.06.2009 13:48:35  [23:00:00; 0] Calculating item  01.05.2009-31.05.2009
DEBUG  09.06.2009 13:48:35  [23:00:00; 0] Reset request accepted => false relevance => -1 REQ: sid => 14 time => 01.05.2009 00:00:00 action => reset RESP: calc
_type => 0 calc_mode => month HIST:
DEBUG  09.06.2009 13:48:35  [23:00:00; 0] Depends from quantity: 1
DEBUG  09.06.2009 13:48:35  [23:00:00; 0] Request accepted => true relevance => -1 REQ: sid => 14 time => 31.05.2009 00:00:00 action => calculate month_days =>
 31 period_days => 31 RESP: cost => 520.0 HIST:
DEBUG  09.06.2009 13:48:35  [23:00:00; 0] cost after quantity: 520.0001
DEBUG  09.06.2009 13:48:35  [23:00:00; 0] Tariff period: 14.05.2009-
DEBUG  09.06.2009 13:48:35  [23:00:00; 0] Trim left
DEBUG  09.06.2009 13:48:35  [23:00:00; 0] Calculating item  14.05.2009-31.05.2009
DEBUG  09.06.2009 13:48:35  [23:00:00; 0] Reset request accepted => false relevance => -1 REQ: sid => 14 time => 14.05.2009 00:00:00 action => reset RESP: HIST
:
DEBUG  09.06.2009 13:48:35  [23:00:00; 0] Found service taker cid: 9526; sid: 14; date1: 01.05.2009; date2: ; col: 1
DEBUG  09.06.2009 13:48:35  [23:00:00; 0] After trimming cid: 9526; sid: 14; date1: 01.05.2009; date2: 31.05.2009
DEBUG  09.06.2009 13:48:35  [23:00:00; 0] Tariff period: 25.02.2009-
DEBUG  09.06.2009 13:48:35  [23:00:00; 0] Calculating item  01.05.2009-31.05.2009
DEBUG  09.06.2009 13:48:35  [23:00:00; 0] Reset request accepted => false relevance => -1 REQ: sid => 14 time => 01.05.2009 00:00:00 action => reset RESP: calc
_type => 0 calc_mode => month HIST:
DEBUG  09.06.2009 13:48:35  [23:00:00; 0] Depends from quantity: 1
DEBUG  09.06.2009 13:48:35  [23:00:00; 0] Request accepted => true relevance => -1 REQ: sid => 14 time => 31.05.2009 00:00:00 action => calculate month_days =>
 31 period_days => 31 RESP: cost => 140.0 HIST:
DEBUG  09.06.2009 13:48:35  [23:00:00; 0] cost after quantity: 140.0
DEBUG  09.06.2009 13:48:35  [23:00:00; 0] Tariff period: 14.05.2009-
DEBUG  09.06.2009 13:48:35  [23:00:00; 0] Trim left
DEBUG  09.06.2009 13:48:35  [23:00:00; 0] Calculating item  14.05.2009-31.05.2009
DEBUG  09.06.2009 13:48:35  [23:00:00; 0] Reset request accepted => false relevance => -1 REQ: sid => 14 time => 14.05.2009 00:00:00 action => reset RESP: HIST
:
DEBUG  09.06.2009 13:48:35  [23:00:00; 0] Found service taker cid: 9526; sid: 14; date1: 01.05.2009; date2: ; col: 1
DEBUG  09.06.2009 13:48:35  [23:00:00; 0] After trimming cid: 9526; sid: 14; date1: 01.05.2009; date2: 31.05.2009
DEBUG  09.06.2009 13:48:35  [23:00:00; 0] Tariff period: 25.02.2009-
DEBUG  09.06.2009 13:48:35  [23:00:00; 0] Calculating item  01.05.2009-31.05.2009
DEBUG  09.06.2009 13:48:35  [23:00:00; 0] Reset request accepted => false relevance => -1 REQ: sid => 14 time => 01.05.2009 00:00:00 action => reset RESP: calc
_type => 0 calc_mode => month HIST:
DEBUG  09.06.2009 13:48:35  [23:00:00; 0] Depends from quantity: 1
DEBUG  09.06.2009 13:48:35  [23:00:00; 0] Request accepted => true relevance => -1 REQ: sid => 14 time => 31.05.2009 00:00:00 action => calculate month_days =>
 31 period_days => 31 RESP: cost => 140.0 HIST:
DEBUG  09.06.2009 13:48:35  [23:00:00; 0] cost after quantity: 140.0
DEBUG  09.06.2009 13:48:35  [23:00:00; 0] Tariff period: 14.05.2009-
DEBUG  09.06.2009 13:48:35  [23:00:00; 0] Trim left
DEBUG  09.06.2009 13:48:35  [23:00:00; 0] Calculating item  14.05.2009-31.05.2009
DEBUG  09.06.2009 13:48:35  [23:00:00; 0] Reset request accepted => false relevance => -1 REQ: sid => 14 time => 14.05.2009 00:00:00 action => reset RESP: HIST
:
INFO   09.06.2009 13:48:35  [23:00:00; 0] time=43 ms.
DEBUG  09.06.2009 13:49:02  Looking tasks





Вот откуда тут взялась тысячная копейки?

Код:
DEBUG  09.06.2009 13:48:35  [23:00:00; 0] cost after quantity: 520.0001

Это к вопросу, поднятому в теме http://www.bgbilling.ru/forum/viewtopic.php?t=2396
Автор:  Администратор [ 09 июн 2009, 19:06 ]
Заголовок сообщения: 
Можно тарифные планы, чтобы периоды видны были. И перечень всех тарифов договора тоже откройте.
И выложите скрины раскрытых деревьев _всех_ назначенных в договоре тарифов.
Автор:  kompot [ 16 июн 2009, 09:45 ]
Заголовок сообщения: 
Периоды:

Изображение
Изображение


Дерево второго ТП (дерево первого -- в обсуждении выше):

Изображение
Автор:  Администратор [ 16 июн 2009, 18:58 ]
Заголовок сообщения: 
Модуль npay последний апдейт стоит?
Выложите скрин "О программе".
Автор:  kompot [ 17 июн 2009, 09:20 ]
Заголовок сообщения: 
Изображение
Автор:  Администратор [ 17 июн 2009, 12:41 ]
Заголовок сообщения: 
Давайте начнем с обновления. Потом, если проблема не пропала, по возможности киньте ССШ доступ к серверу в личку. На месте разберемся быстрее.
Автор:  kompot [ 17 июн 2009, 16:29 ]
Заголовок сообщения: 
Обновил Npay до последней сборки для 4.5.

Код:
INFO   17.06.2009 16:25:11  Running Task: Thread[Thread-317,1,main]
INFO   17.06.2009 16:25:11  PaymentRecalculator time: 01.05.2009 00
INFO   17.06.2009 16:25:11  [23:00:00; 0] Calculate past month
DEBUG  17.06.2009 16:25:11  [23:00:00; 0] Services: -1,11,12,13,14,106,68,69,70,71,93,94,95,96,97,98,99,100,101,102,103
INFO   17.06.2009 16:25:11  Memory total: 6 893 568; max: 266 403 840; free: 4 567 912
DEBUG  17.06.2009 16:25:11  [23:00:00; 0] Found service taker cid: 9526; sid: 14; date1: 01.05.2009; date2: ; col: 1
DEBUG  17.06.2009 16:25:11  [23:00:00; 0] After trimming cid: 9526; sid: 14; date1: 01.05.2009; date2: 31.05.2009
DEBUG  17.06.2009 16:25:11  [23:00:00; 0] Tariff period: 01.05.2009-
DEBUG  17.06.2009 16:25:11  [23:00:00; 0] Calculating item  01.05.2009-31.05.2009
DEBUG  17.06.2009 16:25:11  [23:00:00; 0] Reset request accepted => false relevance => -1 REQ: sid => 14 time => 01.05.2009 00:00:00 action => reset RESP: calc
_type => 0 calc_mode => month HIST:
DEBUG  17.06.2009 16:25:11  [23:00:00; 0] Depends from quantity: 1
DEBUG  17.06.2009 16:25:11  [23:00:00; 0] Request accepted => true relevance => -1 REQ: sid => 14 time => 31.05.2009 00:00:00 action => calculate month_days =>
 31 period_days => 31 RESP: cost => 520.0 HIST:
DEBUG  17.06.2009 16:25:11  [23:00:00; 0] cost after quantity: 520.0001
DEBUG  17.06.2009 16:25:11  [23:00:00; 0] Tariff period: 14.05.2009-
DEBUG  17.06.2009 16:25:11  [23:00:00; 0] Trim left
DEBUG  17.06.2009 16:25:11  [23:00:00; 0] Calculating item  14.05.2009-31.05.2009
DEBUG  17.06.2009 16:25:11  [23:00:00; 0] Reset request accepted => false relevance => -1 REQ: sid => 14 time => 14.05.2009 00:00:00 action => reset RESP: HIST
:
DEBUG  17.06.2009 16:25:11  [23:00:00; 0] Found service taker cid: 9526; sid: 14; date1: 01.05.2009; date2: ; col: 1
DEBUG  17.06.2009 16:25:11  [23:00:00; 0] After trimming cid: 9526; sid: 14; date1: 01.05.2009; date2: 31.05.2009
DEBUG  17.06.2009 16:25:11  [23:00:00; 0] Tariff period: 25.02.2009-
DEBUG  17.06.2009 16:25:11  [23:00:00; 0] Calculating item  01.05.2009-31.05.2009
DEBUG  17.06.2009 16:25:11  [23:00:00; 0] Reset request accepted => false relevance => -1 REQ: sid => 14 time => 01.05.2009 00:00:00 action => reset RESP: calc
_type => 0 calc_mode => month HIST:
DEBUG  17.06.2009 16:25:11  [23:00:00; 0] Depends from quantity: 1
DEBUG  17.06.2009 16:25:11  [23:00:00; 0] Request accepted => true relevance => -1 REQ: sid => 14 time => 31.05.2009 00:00:00 action => calculate month_days =>
 31 period_days => 31 RESP: cost => 140.0 HIST:
DEBUG  17.06.2009 16:25:11  [23:00:00; 0] cost after quantity: 140.0
DEBUG  17.06.2009 16:25:11  [23:00:00; 0] Tariff period: 14.05.2009-
DEBUG  17.06.2009 16:25:11  [23:00:00; 0] Trim left
DEBUG  17.06.2009 16:25:11  [23:00:00; 0] Calculating item  14.05.2009-31.05.2009
DEBUG  17.06.2009 16:25:11  [23:00:00; 0] Reset request accepted => false relevance => -1 REQ: sid => 14 time => 14.05.2009 00:00:00 action => reset RESP: HIST
:
DEBUG  17.06.2009 16:25:11  [23:00:00; 0] Found service taker cid: 9526; sid: 14; date1: 01.05.2009; date2: ; col: 1
DEBUG  17.06.2009 16:25:11  [23:00:00; 0] After trimming cid: 9526; sid: 14; date1: 01.05.2009; date2: 31.05.2009
DEBUG  17.06.2009 16:25:11  [23:00:00; 0] Tariff period: 25.02.2009-
DEBUG  17.06.2009 16:25:11  [23:00:00; 0] Calculating item  01.05.2009-31.05.2009
DEBUG  17.06.2009 16:25:11  [23:00:00; 0] Reset request accepted => false relevance => -1 REQ: sid => 14 time => 01.05.2009 00:00:00 action => reset RESP: calc
_type => 0 calc_mode => month HIST:
DEBUG  17.06.2009 16:25:11  [23:00:00; 0] Depends from quantity: 1
DEBUG  17.06.2009 16:25:11  [23:00:00; 0] Request accepted => true relevance => -1 REQ: sid => 14 time => 31.05.2009 00:00:00 action => calculate month_days =>
 31 period_days => 31 RESP: cost => 140.0 HIST:
DEBUG  17.06.2009 16:25:11  [23:00:00; 0] cost after quantity: 140.0
DEBUG  17.06.2009 16:25:11  [23:00:00; 0] Tariff period: 14.05.2009-
DEBUG  17.06.2009 16:25:11  [23:00:00; 0] Trim left
DEBUG  17.06.2009 16:25:11  [23:00:00; 0] Calculating item  14.05.2009-31.05.2009
DEBUG  17.06.2009 16:25:11  [23:00:00; 0] Reset request accepted => false relevance => -1 REQ: sid => 14 time => 14.05.2009 00:00:00 action => reset RESP: HIST
:
INFO   17.06.2009 16:25:11  [23:00:00; 0] time=32 ms.


800 рублей по-прежнему насчитывается
Автор:  kompot [ 25 июн 2009, 11:54 ]
Заголовок сообщения: 
?
Автор:  Amir [ 20 июл 2009, 16:13 ]
Заголовок сообщения: 
Не так давно выкладывали апдейт - при удалении пойнта не удалялась абонплата (потому что обычно просто закрывают период).
Попробуйте выполнить
SELECT * FROM npay_service_object_66 as service
LEFT JOIN phone_client_item_73 as item ON item.id=service.eid
WHERE service.emid=73 AND item.id IS NULL

Вместо 66 - код модуля абонплат, а 73 - код модуля телефонии.
Автор:  kompot [ 24 сен 2009, 14:07 ]
Заголовок сообщения:  Re: Начисление Абонплаты на пойнты.
Напомню, что у меня версия 4.5.

У меня есть вот что:

Код:
select id,cid from phone_client_item_5
where cid=9526

 id     cid   
 -----  ------
 1768   9526   
 1922   9526   
 1923   9526   
 1924   9526   
 1938   9526   
 1939   9526


вот что:

Код:
select * from npay_detail_3_200908 where cid=9526

 cid     mid     eid     sid     summa   
 ------  ------  ------  ------  --------
 9526    0       0       12      4900     
 9526    5       1768    14      840     
 9526    5       1769    14      840     
 9526    5       1838    14      3120     
 9526    5       1938    14      3120     
 9526    5       1939    14      3120   


и вот что:

Код:
describe npay_service_object_3

 Field     Type     Null     Key     Default     Extra   
 --------  -------  -------  ------  ----------  --------
 csid      int(11)  NO       MUL                         
 oid       int(11)  NO                                   
 col       int(11)  NO               1                   



последняя таблица пустая.

Да, и вот ещё. Я обновился до последней сборки сервера 4.5, которая стала ругаться на отсутствие таблицы contract_parameter_type_9. Как я мог её потерять? Обновляся всегда по инструкциям.

Спасибо.

UPD.

Как я понял, привязка сущности npay_detail_3_200908.eid к договору выполняется посредством поля eid таблицы contract_service. Однако, при удалении из договора всех пойнтов, таблица contract_servcie не меняется:

Код:
 id      cid     sid     date1      date2     comment     lm     emid     eid   
 ------  ------  ------  ---------  --------  ----------  -----  -------  ------
 323784  9526    14      7/15/2009  (null)                (err)  5        1939   
 323783  9526    14      7/15/2009  (null)                (err)  5        1938   
 323116  9526    69      5/14/2009  (null)                (err)  5        1924   
 323115  9526    69      3/25/2009  (null)                (err)  5        1923   
 322487  9526    14      5/1/2009   (null)                (err)  5        1838   
 322486  9526    14      5/1/2009   (null)                (err)  5        1769   
 322391  9526    14      5/1/2009   (null)                (err)  5        1768   


несмторя на то, то eid 1939, 1938 и т.д. уже не существуют. Поэтому при пересчёте абонки в модуле Npay, у меня в таблице npay_detail_3_200908 появляются все те же индентификаторы пойнтов (1939б 1938), которых по идее, уже нет в договоре.

Что мне надо теперь делать? я обновился до последней сборки 422.
Автор:  kompot [ 24 сен 2009, 16:59 ]
Заголовок сообщения:  Re: Начисление Абонплаты на пойнты.
Всё, тема исчерпана по сути: абонка начисляется почти правильно.
(Но по поводу потерявшихся и изменённых таблиц я всё-таки хочу получить ответ от разработчиков)
"Почти" вот почему: если вот эта строка имеется в конфиге

Код:
module.quantity.1.class=bitel.billing.server.npay.bean.PhoneModuleQuantity


то она действует и на договоры, у которых общий тариф на несколько номеров, и на договоры, у которых свой тариф на каждом номере.
Во втором случае каждому пойнту начислится абонка, кратная числу пойнтов на договоре. (проверено).
И что делать с этим? Заводить отдельную услугу?
Автор:  stark [ 25 сен 2009, 19:16 ]
Заголовок сообщения:  Re: Начисление Абонплаты на пойнты.
kompot писал(а):
Да, и вот ещё. Я обновился до последней сборки сервера 4.5, которая стала ругаться на отсутствие таблицы contract_parameter_type_9. Как я мог её потерять? Обновляся всегда по инструкциям.



как ругается ?покажите ошибку
Автор:  kompot [ 26 сен 2009, 11:26 ]
Заголовок сообщения:  Re: Начисление Абонплаты на пойнты.
Ругалась, что таблица contract_parameter_type_9 не существует в базе. Я создал её уже, обновился до 422 и ругань прекратилась.
Авторитетные товарищи из другой организации подтвердили, что и у них такое было. Это обстоятельство внушает беспокойство: мало ли ещё каких таблиц нет? а что будет при переходе на более поздние версии?
Страница 1 из 1 Часовой пояс: UTC + 5 часов [ Летнее время ]
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/