tokone

Я уже так делал, только начинается, если в одной учетной записи несколько услуг, то каждая обсчитывается заново и прибавляется к ней еще и сама сумма. Пример приведу ниже. Есть договор на нём 4 учетных записи, назовем их уз1, уз2, уз3, уз4, в каждой из них свои услуги, абонентская плата(ап) и внутигородские звонки(вг), где-то есть, где-то нету. Сумму "ап*" и "вг*" опишем как "сум*", далее: в уз1 есть ап1=сум1 в уз2 есть ап2 и вг2 в уз3 есть ап3 и вг3 в уз4 есть ап4=сум4 Наш запрос выдает почему-то следующие сложения ап+(ап2+вг2+cум2)+(ап3+вг3+cум3)+ап4=сум1+2сум2+2сум3+сум4=Итоговая сумму (которая мне нужна). Получается если в учетной записи больше одной услуги он начинает делать суммирование внутри цикла самой учетной записи. Хотя сумму %total% ("сум*") внутри учетной записи он считает верно, то есть ап2+вг3=сум3. Поэтому хотел вынести сумму по каждой учетной записи, в php можно описать это как $x +=, в sql я даже не знаю. Думаю надо делать дополнительную проверку чтобы он не делал цикл суммирования внутри учетной записи, только не понимаю как еще. Пока писал, нашел косяк, тут два цикла, я делал сумму во второму, который описывает услуги по учетной записи, вывел в первый, теперь все ок, спасибо himikrzn за наводки. итоговый в act4.txt act3.txt act4.txt

vg_id уже в цикл, по учетным записям все делит, тут проблем нет. Мне же надо чтобы переменную %total% (это сумма всех услуг по одной учетной записи) в цикле при прохождении каждой учетной записи можно было вынести и потом ее суммировать по всем учетным записям. Т.к. я минусанул в отчете лишние для меня услуги, то общая сумма по всем учетным записям не будет равна %total_summ%, забыл о ней сказать, это сумма всех услуг по всем учетным записям, которая описывается как round(o.curr_summ*@RATE,2) из таблицы orders, ее мне и надо актуализировать из-за выборки.

Всем привет. Переделываю шаблон ланбиллинга 2.0.18 для "Акта выполненных работ" под свою специфику для юр. лиц, убираю лишние категории звонков (входящую и все кроме внутригородских) и их начисления в отчете соответственно. Сумму оплаты по одной учетной записи теперь считает правильно, а вот все сумму за все учетные записи не могу сделать верную (с учетом минуса тех категорий, которые убрал). Не могу понять, как выкинуть из цикла переменную %total%, и суммировать по каждой учетной записи ее. Общую сумму хочу описать теперь как %total2%. В *sql не шарю, может быть кто подскажет куда копать. Код исходника (act.txt) и мой вариант (act2.txt) оставляю ниже в файлах. act.txt act2.txt

Квитанция годная, спасибо, работает на 2.0.18. Я использую кредитную схему на телефонию, при корректировки счета выставленного за прошедший месяц квитанция будет прописывать суммы такие, которые были до корректировки, т.к. она считает сумму из статистики (из таблиц отчетов в бд) и поэтому она будет не правильна, будет работать когда счет не трогают. Как вы в таких случаях поступает?

вот скрин док-ов которые надо было сформировать

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

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

Добрый день. Решил запустить тарификацию телефонии через кредитную схему по постоплате, для эмуляции создал: 1). Кредитный договор <> 1.png (день месяца, после которого счет считается неоплаченным - 20, порог блокировки по количеству неоплаченных счетов - 1); 2). Тариф с постоплатой со списанием ежемесячно <> 2.png; 3). Создал учетку, привязал ее к тарифу и договору, а так же включил ее задним числом 01.02.2016 <> 3.png и 3.1.png, чтобы увидеть как работает схема уже сейчас. 4). Сгенерировал через печатные формы "Счет кредитный" <> 4.png, на период 02.2016 от 01.03.2016 <> 5.png. 5). Закрыл период - март 2016 <> 6.png Предполагал что учетная запись имея два списания за 2 месяца и 1 неоплаченный счет, т.к. дата выставления его 01.03.2016, а уже 27.04.2016 уйдет по условиям кредитного договора, а именно порог блокировки по количеству неоплаченных счетов = 1, в блокировку, но данной процедуры не происходит. Вроде бы все условии учел: Счет считается неоплаченным, если: ❼ находится в закрытом периоде; ❼ прошло более дней с начала периода следующего за периодом выставления счета, чем определено параметром «День месяца, после которого счет считается неоплаченным»; ❼ не покрыт платежами списания аренды за два месяца тоже произошли по 225 р., теперь на балансе -450 р. и по идеи неоплаченный счет, но блокировки так и не наступает, рестартил ядро, не помогает, перечитал доки несколько раз, не могу понять чего не хватает. Мб у меня что не так с ядром LANBilling 2.0 Core Server Build: 18.0 (Mar 10 2016 15:33:10), rev #334e8b10. Перевожу на смешанный тип договора, блокировка наступает, иногда не сразу, но после рестарта ядра точно, значит что-то не так с выставленным счетом, только что не пойму, по срокам он уже должен быть неоплаченным. Ранее использовал только авансовые типы договоров для радиуса и нетфлоу, с ними проблем не было. Поделитесь опытом, кто реализовывал схемы с постоплатой

http://forums.lanbilling.ru/board/viewtopic.php?f=1&t=6489&start=10 тут у человека тоже не поддерживала ios, ему советовали перебраться на другую версию

Из вашего поста Calling-Station-Id nas не шлет на билинг т.к. не добавлена ком*** на это radius-server attribute 31 send nas-port-detail mac-only (команда работает не на всех IOS) В моем случае она есть и она шлет, но там одни нули. На сколько понял это из-за типа сабскрайбера routed, который в себе не несет мак вообще. Пока вижу принимать мак только через dhcp инициаторов, пришлет ли он корректный Calling-Station-Id пока не могу проверить

Конечно же лучше сделать dhcp, повесить авторизацию через opt82 на другую политику. Это хочу делать для новых абонентов. А можно ли это сделать не убирая текущую политику и повесить на радуис два способа авторизации, которые меняются в зависимости от типа инициатора? т.к. текущих абонентов я не могу перевести со статики, и их конечно желательно тоже как-то определить, на каких порта они весят и с какими маками, чтобы видеть статуса линков Или создать новую policy-map с новым листом авторизации и новыми вланами для абонентов, которые будут авторизироваться через dhcp, просто пока не представляю как должен выглядеть конфиг в таком случае

чтобы понять на каком порту коммутатора доступа абонент

не получается, при данной схеме идентификатором (тип static) видимо выступает мак asr1000.stelecom#sh ip subscriber vrf Inet Displaying subscribers in the Inet service vrf: Type Display UID Status Subscriber Identifier --------- ------------ ------ --------------------- static 691 up 0000.0000.0000 routed 73 up 172.31.80.4/32 routed 1079 up 172.31.80.6/32 routed 199 up 172.31.80.8/32 routed 1330 up 172.31.80.11/32 routed 89 up 172.31.80.12/32 routed 1107 up 172.31.80.13/32 а не ip адрес как при routed инициализация такая: policy-map type control ISG-CUSTOMERS-POLICY class type control always event session-start 1 set-timer IP-SESSION-TIMEOUT 1440 10 authorize aaa list ISG-AUTH-1 password test identifier source-ip-address

то есть routed в себе не несет мак-адреса, теперь понятно А если заменить на l2-connected ip subscriber list mylist150 ip source 172.31.81.65 mask 255.255.255.192 interface GigabitEthernet0/0/0.150 encapsulation dot1Q 150 ip vrf forwarding Inet ip address 172.31.81.65 255.255.255.192 ip nat inside ip flow ingress ip flow egress service-policy type control ISG-CUSTOMERS-POLICY ip subscriber l2-connected initiator static ip subscriber list mylist150 сейчас нет возможности проверить, только вечером должно ли так начать отдавать?

Добрый день. Используется схема Cisco ASR1001 <> Cisco 3750 <> Dlink DES серий <> абонент ASR1001 boot system flash bootflash:asr1001-universalk9.03.10.05.S.153-3.S5-ext.bin boot system flash bootflash:asr1001-universalk9.03.08.01.S.153-1.S1.bin interface GigabitEthernet0/0/0.150 encapsulation dot1Q 150 ip vrf forwarding Inet ip address 172.31.81.65 255.255.255.192 ip nat inside ip flow ingress ip flow egress service-policy type control ISG-CUSTOMERS-POLICY ip subscriber routed initiator unclassified ip-address radius-server attribute 44 include-in-access-req default-vrf radius-server attribute 44 extend-with-addr radius-server attribute 8 include-in-access-req radius-server attribute 32 include-in-accounting-req radius-server attribute 55 include-in-acct-req radius-server attribute 31 mac format unformatted radius-server attribute 31 send nas-port-detail mac-only radius-server host 10.23.3.251 auth-port 1812 acct-port 1813 key test radius-server retransmit 10 radius-server vsa send cisco-nas-port Radius при авторизации абонентов выдает аттрибут: Jan 5 19:01:10.797: RADIUS: User-Name [1] 15 "172.31.80.102" Jan 5 19:01:10.797: RADIUS: User-Password [2] 18 * Jan 5 19:01:10.797: RADIUS: Framed-IP-Address [8] 6 172.31.80.102 Jan 5 19:01:10.797: RADIUS: Vendor, Cisco [26] 22 Jan 5 19:01:10.798: RADIUS: ssg-account-info [250] 16 "S172.31.80.102" Jan 5 19:01:10.798: RADIUS: Calling-Station-Id [31] 14 "000000000000" 3750 маки отдает Dev-10#show mac address vlan 150 Mac Address Table ------------------------------------------- Vlan Mac Address Type Ports ---- ----------- -------- ----- ..... 150 0004.614b.7a72 DYNAMIC Gi1/0/20 150 0018.f329.cc76 DYNAMIC Gi1/0/20 150 001b.3866.bf5b DYNAMIC Gi1/0/20 150 0023.5472.9708 DYNAMIC Gi1/0/20 150 0024.54c3.6519 DYNAMIC Gi1/0/20 150 54a0.5071.cc5c DYNAMIC Gi1/0/20 150 acf1.df2f.6568 DYNAMIC Gi1/0/20 150 d867.d9a9.6200 DYNAMIC Gi1/1/1 150 e0ca.941b.cfa7 DYNAMIC Gi1/0/20 .... Total Mac Addresses for this criterion: 29 dlink маки отдает DES-3200-52:admin#sh fdb Command: show fdb Unicast MAC Address Aging Time = 300 VID VLAN Name MAC Address Port Type Status ---- -------------------------------- ----------------- ----- ------- ------- ..... 150 SW-005-DATA 00-04-61-4B-7A-72 13 Dynamic Forward 150 SW-005-DATA 00-18-F3-29-CC-76 6 Dynamic Forward 150 SW-005-DATA 00-1B-38-66-BF-5B 24 Dynamic Forward 150 SW-005-DATA 00-24-54-C3-65-19 1 Dynamic Forward 150 SW-005-DATA 00-E0-4C-D2-C3-EF 3 Dynamic Forward 150 SW-005-DATA 50-57-A8-85-A5-94 49 Dynamic Forward 150 SW-005-DATA AC-F1-DF-2F-65-68 11 Dynamic Forward 150 SW-005-DATA D8-67-D9-A9-62-00 49 Dynamic Forward 150 SW-005-DATA E0-CA-94-1B-CF-A7 14 Dynamic Forward .... Ланбилинг версии 2.0.014, в истории авторизации абонентов мак-адреса с нулями соответственно. Абоненты авторизируются по статическим ip, без dhcp. Как научить брас выдавать корректные маки абонентов, которые запрашивают авторизацию или что ему не хватает?