provided by Star2Billing S.L.

Hello

I've been testing the invoicing module for a few days now, in postpaid mode. I have a number of design issues with it, and proposal for these. I am willing to implement a fair share of this, probably once 1.5 is under way (1.4 final should come soon, so it does not make sense to include in this release).

Please feel free to comment this ideas - all feedback is needed.

jean

1) log all credit affecting transactions as a charge
currently, the recurring service does not post any charge, just updates the cc_card.credit - this makes hard to justify to the customer. A charge should be posted.

2) create separate cc_invoice_item for different charges
currently, everything is summed up into one line of cc_invoice. separating subscription, recurr charges, calls, etc... onto different lines would allow a clearer invoice, and a better analysis of the revenue.
also, different vat rates could apply to different type of services - many of you guys are in europe, I am sure you understand what I mean !

3) total amount
the db design show that one cc_invoice can have mutiple cc_invoice_item - which makes sense. yet, the cc_invoice does not have a total of all sum(cc_invoice_item.price).
-> this does not allow to produce any details for an invoice.
-> reporting is complicated, as an expensive joint is needed

4) open amount
once a total field is implemented at invoice level, the next goodie is the open amount - ie the amount remaining to be paid for this invoice. currently, this can only be retrived via a complex query through log payment.

5) vat
vat is recalculated dynamically. each time an invoice is displayed, the vat is recalculated, and the rounding is redone. given that the sum of rounded value is different from the rounding of the sum of the values, it is possible to have strange results. the vat amount should be stored at invoice level.

6) rounding
rounding is done at display time. some screens were rounding via different methods (see ticket #530). ideally, the # of decimals is defined at system level, and rounding is done at invoicing time, and only rounded value are stored.

7) auto-refill at invoicing time.
when two invoice cycle are run and no customer payment is done, the second invoice invoices again the current balance (cc_card.credit). therefore, you actually need to refill the account while the invoice is produced.
The risk is managed in two different ways... credit limit only controls unbilled amount, while the invoice amounts are managed through the collection process (with a couple of good custom reports and the help of total / open amount fields previously mentionned). With also the help of these two fields, the notification batch can evolve to include the verification o the unbilled amount, AND include the billed, open, amounts.

8 ) payment assignation to invoice.
currently, when a payment is made - to my understanding - one goes into the payment screen, enters the payment, and then goes to the invoice screen, and assign the payment to the invoice. having an option to assign the payment directly to the invoice in the payment screen would make life easier

We are currently at 1.7 and there are still alot of these issues that you mention open and that could be alot better. I have a very specific question for you. Areski has announced that he is too busy to attend a problem that is in the billing cron and I am trying to find someone with knowledge to help here. The problem is that the invoice amount in the invoice that is generated by the billing cron is incorrect. The Receipts generated for usage and DID´s is correct. When you compare the reciepts amount to the usage on the account it adds up perfectly and also the amount for the DID´s monthly usage is correct. BUT the invoice that is generated does not reflect the sum of the reciepts and I cannot find the relation where it is going wrong. Can you help?

Hi,

I am currently still running on 1.4, and I have not used DIDs.... It s not that I dont want to help, but I am not in a good position...

If I have a few minutes during the week, I'll try to have a look - could you also give more details ? post test versions of invoice & receipt ? (maybe start a new thread)

J.

Seeing that this is live data of a customer of mine I would like to PM that as i did with Areski. Please let me know if there is something that you can do. I really appreciate it.

Hi

I havent downloaded 1.7 yet.... but I guess it is very close from 1.4 on that part.

Receipts are calculated by looking into the cc_call tables, and summing all calls from last billing till the current moment.
Invoices only take the credit, and use that as the amount owed.
So, you should see that the customer credit is different from the sum of calls for the period.

In your case, there is a delta of 51 MXN. This can be caused by different reasons...

few ways forward -
A/ try to reconcile the 51 pesos, and if you find out what causes it, delete the charges (it is small money - but bear this mind for inter-operator reconcilliation) - look carefully around the beginning and end of the billing period - I vaguely remember this could be related

B/ try to implement a code change
B1/ modify the php so the invoice amount comes from the same variables as the receipt - should be quick - and that the credit is increased by this value. you will see that the credit goes back to 51 pesos and not 0 - and this will re-happen forever...

B2/ try to implement my code change from 1.4
What I have done in 1.4 is modify the script so the invoice takes the same amount as the receipt, along with quite a few other changes. The code is at the end of the thread: viewtopic.php?f=21&t=5881
Obviously, you need to have a test box before running this on your prod ! you first want to do a diff between 1.4 & 1.7, and then see how to merge my changes with 1.7 - not immediate.... i agree