forum.bitel.ru • Просмотр темы - Начисление Абонплаты на пойнты.

Сообщения без ответов | Активные темы

Список форумов » BGBilling » Модули Абонплат и разовых услуг » Модуль NPay

Часовой пояс: UTC + 5 часов [ Летнее время ]

Начисление Абонплаты на пойнты.

Страница 1 из 1

[ Сообщений: 15 ]

Версия для печати

Пред. тема | След. тема

Автор

Сообщение

kompot

Заголовок сообщения: Начисление Абонплаты на пойнты.

Добавлено: 05 июн 2009, 11:33

Зарегистрирован: 11 май 2007, 16:17
Сообщения: 69
Карма: 19

Имеется договор на услуги Телефонии (модуль phone) и Инета (модуль Dialup ).
В глобальных тарифах - только тариф на Инет.

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

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

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

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

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

800 рублей.

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

(Периоды действия услуг, тарифов правильно проставлены.)

Вернуться к началу

Администратор

Заголовок сообщения:

Добавлено: 09 июн 2009, 12:17

Разработчик

Зарегистрирован: 27 ноя 2006, 20:36
Сообщения: 5715
Карма: 93

Версия какая ПО? Поставьте в data/log4j.xml

Код:

 <root>
                <priority value="DEBUG" />
                <appender-ref ref="ASYNC" />
        </root>

Потом запустите начисление абонок по этому договору и выложите, что в scheduler.log вывелось.

Вернуться к началу

kompot

Заголовок сообщения:

Добавлено: 09 июн 2009, 13:49

Зарегистрирован: 11 май 2007, 16:17
Сообщения: 69
Карма: 19

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

Разработчик

Зарегистрирован: 27 ноя 2006, 20:36
Сообщения: 5715
Карма: 93

Можно тарифные планы, чтобы периоды видны были. И перечень всех тарифов договора тоже откройте.
И выложите скрины раскрытых деревьев _всех_ назначенных в договоре тарифов.

Вернуться к началу

kompot

Заголовок сообщения:

Добавлено: 16 июн 2009, 09:45

Зарегистрирован: 11 май 2007, 16:17
Сообщения: 69
Карма: 19

Периоды:

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

Вернуться к началу

Администратор

Заголовок сообщения:

Добавлено: 16 июн 2009, 18:58

Разработчик

Зарегистрирован: 27 ноя 2006, 20:36
Сообщения: 5715
Карма: 93

Модуль npay последний апдейт стоит?
Выложите скрин "О программе".

Вернуться к началу

kompot

Заголовок сообщения:

Добавлено: 17 июн 2009, 09:20

Зарегистрирован: 11 май 2007, 16:17
Сообщения: 69
Карма: 19

Вернуться к началу

Администратор

Заголовок сообщения:

Добавлено: 17 июн 2009, 12:41

Разработчик

Зарегистрирован: 27 ноя 2006, 20:36
Сообщения: 5715
Карма: 93

Давайте начнем с обновления. Потом, если проблема не пропала, по возможности киньте ССШ доступ к серверу в личку. На месте разберемся быстрее.

Вернуться к началу

kompot

Заголовок сообщения:

Добавлено: 17 июн 2009, 16:29

Зарегистрирован: 11 май 2007, 16:17
Сообщения: 69
Карма: 19

Обновил 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

Зарегистрирован: 11 май 2007, 16:17
Сообщения: 69
Карма: 19

Вернуться к началу

Amir

Заголовок сообщения:

Добавлено: 20 июл 2009, 16:13

Разработчик

Зарегистрирован: 19 дек 2006, 21:04
Сообщения: 5970
Карма: 256

Не так давно выкладывали апдейт - при удалении пойнта не удалялась абонплата (потому что обычно просто закрывают период).
Попробуйте выполнить
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

Заголовок сообщения: Re: Начисление Абонплаты на пойнты.

Добавлено: 24 сен 2009, 14:07

Зарегистрирован: 11 май 2007, 16:17
Сообщения: 69
Карма: 19

Напомню, что у меня версия 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

Заголовок сообщения: Re: Начисление Абонплаты на пойнты.

Добавлено: 24 сен 2009, 16:59

Зарегистрирован: 11 май 2007, 16:17
Сообщения: 69
Карма: 19

Всё, тема исчерпана по сути: абонка начисляется почти правильно.
(Но по поводу потерявшихся и изменённых таблиц я всё-таки хочу получить ответ от разработчиков)
"Почти" вот почему: если вот эта строка имеется в конфиге

Код:

module.quantity.1.class=bitel.billing.server.npay.bean.PhoneModuleQuantity

то она действует и на договоры, у которых общий тариф на несколько номеров, и на договоры, у которых свой тариф на каждом номере.
Во втором случае каждому пойнту начислится абонка, кратная числу пойнтов на договоре. (проверено).
И что делать с этим? Заводить отдельную услугу?

Вернуться к началу

stark

Заголовок сообщения: Re: Начисление Абонплаты на пойнты.

Добавлено: 25 сен 2009, 19:16

Разработчик

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238

kompot писал(а):

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

как ругается ?покажите ошибку

Вернуться к началу

kompot

Заголовок сообщения: Re: Начисление Абонплаты на пойнты.

Добавлено: 26 сен 2009, 11:26

Зарегистрирован: 11 май 2007, 16:17
Сообщения: 69
Карма: 19

Ругалась, что таблица contract_parameter_type_9 не существует в базе. Я создал её уже, обновился до 422 и ругань прекратилась.
Авторитетные товарищи из другой организации подтвердили, что и у них такое было. Это обстоятельство внушает беспокойство: мало ли ещё каких таблиц нет? а что будет при переходе на более поздние версии?

Вернуться к началу

Страница 1 из 1

[ Сообщений: 15 ]

Список форумов » BGBilling » Модули Абонплат и разовых услуг » Модуль NPay

Часовой пояс: UTC + 5 часов [ Летнее время ]

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Перейти:

BiTel

Начисление Абонплаты на пойнты.

Кто сейчас на конференции