[Spce-user] billing issues in a development environment

[Joan Cifre (ibred)]

Hello Andreas,
I've tried with your pattern ^6[0-9]+$ for example and... IT SEEMS TO 
WORK! I'm very grateful you help me with this. Now I'v fount an utility 
to test patterns before use it
http://www.regexplanet.com/advanced/java/index.html
I will use it with my patterns since now to verify if they are correct

Now I have two questions about billing maybe you can help me again
- The billing matching pattern is verified before or after the "Rewrite 
matching rule" of the Calle?
- If I fill the column of "Onpeak follow rate" (for example), in cents, 
I got the charges in cents? Or the system multiplies it by 100 to got 
Euro (or dollar or whatever)?

Sorry for abuse of your knowledge
Thanks for your help,
Joan

El 28/03/2012 0:42, Andreas Granig escribió:
> Hi Joan,
>
> Your destination patterns are wrong. You must be aware that they are
> used as regular expressions, and the first two rows actually look good
> (e.g. the first one means "match anything starting with 34871 or 34971,
> followed by any six digits").
>
> However, the third one is most likely wrong, because "^101028$" means
> "match exactly the number 101028", which I guess is not what you want.
> Row number four, which is "^11$", means match exactly the number "11".
> What you most likely want in this cases is for example "^11[0-9]+$",
> which means it starts with "11" and continues with one or more digits.
>
> To sum it up, the "^" sign in regular expressions means "match beginning
> of the string", and the "$" means "match end of the string", which
> explains why "^11$" only matches exactly the string "11".
>
> I couldn't find a single entry in your document which would match your
> number "636421271". The closest would be row 16811, but only if you
> remove the "$" to make it "^63", which means any string starting with "63".
>
> Hope this helps fixing your billing profile. One more important thing to
> notice is that the full international number is matched against your
> rules, so for example an exact match for a call to Austria (country code
> 43), Vienna (area code 1) would need a destination like "^431[0-9]+$".
>
> Andreas
>
> On 03/28/2012 12:10 AM, Joan Cifre (ibred) wrote:
>> Hello,
>> hera I send attached the result of the database query. The billing
>> profile is number 3. The last destination is ^.*$, but for example, a
>> call to 636421271 matches only with this destination, not with 16716 row
>> as expected (or maybe with 3676 row if it matches international prefix).
>> If I remove ^.*$, rate-o-mat stops with an error.
>> Hope the file can be useful
>> Joan
>>
>>
>> El 27/03/2012 16:30, Andreas Granig escribió:
>>> Hi,
>>>
>>> On 03/27/2012 03:23 PM, Joan Cifre (ibred) wrote:
>>>> - The billing system stops (rate-o-mat stopped) not only when there is
>>>> no match, but also when there is a match. The problem could be that we
>>>> have many fees (more than 10 thousand). When I have a "all-matches" rule
>>>> (^.\*$) at the begginning there is no problem, but when the rule to
>>>> match is not at the start of the list, the system does not found it and
>>>> rate-o-mat is stopped
>>> The correct rule is actually without quoting the star, like "^.*$".
>>>
>>> In any case, it really doesn't matter at which place you put the
>>> catch-all rule, because rate-o-mat re-orders it internally when trying
>>> to find a matching rule anyways.
>>>
>>> Can you show one db entry of such a billing fee (from mysql db
>>> "billing.billing_fees") where you expect a match (you can of course set
>>> the rate values to 0 for privacy reasons)? Maybe your destination colum
>>> is not as expected
>>>
>>> One other typical error we encounter with people new to the platform is
>>> when you see such a message in /var/log/ngcp/cdr.log:
>>>
>>> Error rating CDR batch: No contract id found for uuid
>>> 'f13c07a9-639b-45f3-be4b-915646bebac5'
>>>
>>> This usually comes from the fact that an account is deleted before all
>>> CDRs have been rated for all subscribers of this account (either via
>>> SOAP or in the Admin Panel). The correct approach for disabling a
>>> subscriber immediately is "terminating" a subscriber (that is, clicking
>>> the x-Button in the subscriber's master data), and only later on (once
>>> you're sure all CDRs are rated) really delete the account.
>>> The reason for that is that when you completely delete an account,
>>> you're not able to bill this customer anymore, whereas when you
>>> terminate the subscribers of this account, they can't use it anymore,
>>> but you're still able to rate/bill calls.
>>>
>>> Andreas
>>>
>>> Andreas
>>>
>>>
>>>
>>> _______________________________________________
>>> Spce-user mailing list
>>> Spce-user at lists.sipwise.com
>>> http://lists.sipwise.com/listinfo/spce-user