Support A2Billing :

provided by Star2Billing S.L.

Support A2Billing :
It is currently Wed Aug 21, 2019 9:59 am
VoIP Billing solution


All times are UTC




Post new topic Reply to topic  [ 23 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: A2Billing invoicing - proposed work flow
PostPosted: Tue Jan 19, 2010 6:20 pm 
Offline

Joined: Fri Jun 23, 2006 3:56 pm
Posts: 4065
Dear all

We need your input.


I've been giving some thought to the process of invoicing, and I believe that I have come up with a relatively simple logic of how it should work.

Introduction

The general principle is that invoicing works exactly like a bank statement that you get every month. It shows debits, and credits, with a value carried over from the last statement.

A2Billing invoicing could work in exactly the same way, using the same idea - a post-paid customer has an overdraft limit, while a pre-paid customer does not.

There are two approaches to invoicing in accounting.

1. Send an invoice, and when it is paid, mark it as paid.
2. Send an invoice every month, with the balance carried forward from previous invoices. Thus the latest invoice replaces all previous invoices.

In my opinion, Option 1 is suitable for selling phones, or consultancy, e.g. one off items, but option 2 is more suitable for telecoms billing, as we expect to send every customer an invoice every month, so all we are interested in is their outstanding balance.

The process

Each customer has a balance available to them – this is a net value – excluding taxes, and a credit limit, which is also a net value.

The amount of balance available will either be the value of money given to you by the customer, or it will be the credit limit you have given the customer, plus any money they have given you.

e.g.
• Postpay customer balance 0, credit limit, 100, gives an available balance of 100
• Pre-pay customer balance 50, credit limit 0, gives an available balance of 50
• Customer with balance 25 and credit limit of 75, gives available balance of 100

As charges are made during the month, e.g. DID charges, lines added to the invoice, Subscriptions, Recurring charges, they are added to a “Preview invoice” and at the same time, the available balance is reduced.

On invoice day - which is set in the customer page. The invoice is prepared, and closed down - it is no longer a preview invoice, it is the invoice / statement for that month - and no items can be added on to that that invoice. It is now fixed as a permanent record for that month's usage in terms of payments, charges and calls made, and of course TAX.

The balance from that invoice is recorded, and a new preview invoice prepared, with the first line being the balance carried forward from the previous month.

The Balance carried forward comes from the total net charges, less the total net payments in the previous month.

Then the whole process starts again.

A record of the time and date that the new preview invoice is created is kept, so that only items after this date and time are recorded on the new invoice.

The key to this is that anything that changes the customer's balance must be written to the customer's preview invoice, or the system falls down, and you do not have an audit trail.

Advantages

I believe that this approach will have the following advantages:-

1. A unified approach to all charges of whatever nature that are applied to a customer's account, making it easy to understand.

2. Most people are familiar with a bank statement, so the concept will be familiar to most customers, as our system would work in the same way.

3. Remove complexity of paying money against invoices. Simply an outstanding balance maintained.

4. Flexibility in whether a customer is pre-pay or post-pay, simply by changing the credit limit of the customer - e.g. 0 credit limit of pre-pay, and a value for post-pay.

5. No requirement to set payments against individual invoices, with the complexity and administration that this requires.

6. A complete audit trail for every customer.

7. Simplification of the process of maintaining payments, a payment comes in, and it is inserted against the customer, customer’s available balance is updated and a payment line inserted on the preview invoice.

Finally, because all the core information is in one place - creating invoices, statements, or receipts in any format can be done from the same raw information from what we may call a transactions table, simply by running an appropriate query, and displaying the information as desired.


The Rules


1. Invoice items may not be edited in terms of amounts, as to change the amount would put it out of sync with the Outstanding balance.

2. Corrections can be made by adding a line (credit or debit) onto the invoice during the billing period, which is either negative or positive.

3. No changes can be made to the outstanding balance unless a line is written to the transactions table listing that transaction that changed the balance.

4. Services are disconnected when the customer exceeds his credit limit - e.g. he goes over his overdraft limit.

5. Effectively, each invoice sent out will replace the last invoice in terms of amount to pay, as it includes the balance carried forward.

6. Payments can be made either in excess of the invoice, or less than the invoice and the system will cope.



Nice to have


The preview invoice can be closed off at any time of the month by the admin, and a new preview invoice restarted with the current outstanding balance. This could be done on a customer by customer basis, or run by pressing a button, and invoicing a particular subset by filtering on customers first - a bulk update for instance. This would allow a customer to have their final bill, as the balance would be reset to zero. Alternatively, the customer could close off their own invoice and pay it.


In conclusion


The key to understanding this is to regard the system like bank statement. where the customer’s account is credited or debited, and all services are suspended when the customer has no balance available.

One disadvantage is that different types of service attract different levels of VAT, this will not be easy to include in the current version of A2Billing, as it is an accounts based system, but I am sure there are work arounds which can carry is through to the next version of A2Billing, where we can write this requirement in from the ground up.


Can you help

Please could you inspect the work flow above, and tell us if it is acceptable, and please pick holes in it, or ask any questions where it is not clear.

We do not want to be re-designing this again, and we are keen to get it right.

Initial indications show that there is a lot of work in doing this. We will come up with an estimate of how much work is involved after we get your comments.


Yours

Joe Roper


Top
 Profile  
 
 Post subject: Re: A2Billing invoicing - proposed work flow
PostPosted: Fri Jan 22, 2010 4:59 am 
Offline
User avatar

Joined: Sat Mar 28, 2009 5:50 am
Posts: 96
Joe,

Implementation of invoicing in A2Billing is currently flawed and imperfect.

This time you have presented "the right concept" of telecom invoicing. I totally agree with your 2nd approach as this is the way telecom invoicing is implemented.

Regarding customers closing off their own invoices, I believe this is flawed and can produce unwanted results in the long run.

Moreover adding search facility (by lastname, invoice date, invoice no, account no etc) on invoices page would definitely make invoicing even better.

jroper wrote:
We do not want to be re-designing this again, and we are keen to get it right.


Hopefully you will get it this time as I can tell from your proposed concept that you are heading in the right direction.

Cheers,

A.


Top
 Profile  
 
 Post subject: Re: A2Billing invoicing - proposed work flow
PostPosted: Fri Jan 22, 2010 8:03 am 
Offline

Joined: Fri Jun 23, 2006 3:56 pm
Posts: 4065
Hi

Thank you for your attention and your reply. It is appreciated

I was beginning to think that one or more of the following is true:-

a) no one is particularly interested.
b) Invoicing is fine, and no changes are required.
c) no one had read the post.

You say that customers should not close off their own invoices - I was thinking along the lines of customers being able to settle their account to current date.

The only issue that I can see is that this may cause some unexpected load during the day for busy customers. which may be sufficient to avoid giving that facility to customers. What are your thoughts on why it should not be allowed?

We could do with more input as to whether this is the right or wrong approach, and whether anyone can see any flaws in the system, and finally, whether the system is easily understood.

Yours

Joe


Top
 Profile  
 
 Post subject: Re: A2Billing invoicing - proposed work flow
PostPosted: Fri Jan 22, 2010 1:38 pm 
Offline

Joined: Tue Aug 19, 2008 3:49 pm
Posts: 184
Hi,

I am still digesting the post.

However, I really do not want customers closing invoices. I think it will cause added support tickets requesting re-opening or correcting an invoice. Admin/Billing can mess these up enough by themselves.

More after further digestion.

Les


Top
 Profile  
 
 Post subject: Re: A2Billing invoicing - proposed work flow
PostPosted: Sun Jan 24, 2010 7:36 am 
Offline
User avatar

Joined: Sat Mar 28, 2009 5:50 am
Posts: 96
Joe,

I believe, letting customers do their invoices will result in following

1) Increased business admin work e.g. reversions, corrections etc.
2) Substantial amount of time/effort required for coding/maintaing a functionality which is not worth it.

Regarding the understanding, It's very similar to a bank statement and also I've seen invoices from well established telecom companies using the same format. So people already familiar with it.

Cheers,

A.


Top
 Profile  
 
 Post subject: Re: A2Billing invoicing - proposed work flow
PostPosted: Sun Jan 31, 2010 2:53 pm 
Offline

Joined: Thu Dec 03, 2009 11:18 am
Posts: 62
WOW!! fantastic...
The ability for a invoice to be closed by a billing cycle or the customer is simple and should stay.
One can assume that if the customer pay the balance on the invoice they have agreed with the charges on it. I expect no one to pay an invoice that they have questions and a ticket will come if there are any. Since one can not make changes to a line item on it, a correction must be created to fix any discrepancy thus documenting every transaction.
if there are question on a invoice closed by the billing cycle a correction is made on the next invoice. in any case it is a vast improvement from what it is today. (in my case useless) :(

"The only issue that I can see is that this may cause some unexpected load during the day for busy customers. which may be sufficient to avoid giving that facility to customers. What are your thoughts on why it should not be allowed?"
HUH!! what load? the payment is nothing more that another entry in the database and a simple entry in a column with the payment ID for that line items of that invoice. do you expect an invoice with thousands of entries that a simple update will load the system?

I am not sure I understand the diff from option 1 or 2.
if one has the ability to close an invoice and a new one start and we have an option button to pay that closed invoice, this is option 1 right?
One can still pay on that invoice a different amount where it should only mark the invoice is paid. Any difference is just forwarded as a line item in the next invoice.

as far as warnings. that should be set based on the customer available credit right? ie: if the customer is set to get a warning at $10 and it is a postpaid customer with a credit limit of $50 he should get a warning when his balance is -$40. This would eliminate the need to have "postpaid" and "prepaid" customer. :)

This is nice.... :) now when will it be available :) cant wait.....


Top
 Profile  
 
 Post subject: Re: A2Billing invoicing - proposed work flow
PostPosted: Sun Jan 31, 2010 5:10 pm 
Offline

Joined: Tue Aug 19, 2008 3:49 pm
Posts: 184
LFCII wrote:
Hi,

I am still digesting the post.

However, I really do not want customers closing invoices. I think it will cause added support tickets requesting re-opening or correcting an invoice. Admin/Billing can mess these up enough by themselves.

More after further digestion.

Les


I might be confused on what "Alternatively, the customer could close off their own invoice and pay it." means.

Let me define "invoice = record cycle" to help me express my thoughts.

I am using the term record cycle because A2Billing is designed for repeating service with the occasional one time sale. A set up fee or an ATA for example.

Record cycles should be a set time period. Every 30 days for example. The customer should not have the ability to close a record earlier than the cycle. The cycle should run as scheduled and then, in the case of a postpaid account, the customer would review the record and pay it.

In the case of a prepaid account, the customer would review the 30 day record to see that it agrees with what they used and what they used it on.

Actually the latter happens in both cases.

If there needs to be a correction it will have to be adjusted for in the next record cycle.

The information giving for both prepaid and post paid should be the same.

So in both cases the record should be the same.

The prepaid customer is going to see what he used and paid for.

The postpaid customer is going to see what he used and is paying for.

So the flow would be:

1.0 Customer Status

1.1.1 Postpaid customer is giving credit limit.
1.1.2 Prepaid customer makes a monetary deposit.

2. Record cycle is started.

3. Record cycle is stopped.

4. Customer reviews the record.

4.1 Postpaid customer is requested to pay record.
4.2 Prepaid customer is offered to add funds.

If this is what Joe's post suggest, it sounds good to me.

The above is just my thoughts.

If someone needs a more complex system (ie: advanced call records), maybe it should be considered as additional custom coding needed on their part????

Kind Regards,

Les


Top
 Profile  
 
 Post subject: Re: A2Billing invoicing - proposed work flow
PostPosted: Tue Feb 02, 2010 8:29 am 
Offline

Joined: Fri Jun 23, 2006 3:56 pm
Posts: 4065
Hi

There is a major difference between options 1 and 2 of how to create the invoice.

Option one expects an invoice to be created, and then paid in full. If a number of invoices are created, then the amount owed will be the total of all the invoices ever issued and not marked as paid.

Option two creates an invoice, and the balance carried forward from all previous invoices, so to get an amount owed, one only has to look at the final invoice, as it will include the values from all other invoices.

In terms of maintenance - option one would require two processes - 1. Mark the invoice as paid, and 2, Show the amount credited. The system gets difficult to understand if a customer over pays, or under pays.

Option two only requires that payments received are entered into A2Billing, thus the system easily copes with under payments and over payments, as well as requiring less mouse clicks to maintain, and thus for a telecom billing system where the amounts owed by the customer, and the transactions made are happening almost on a minute by minute basis as calls are made, this is more suitable.

In respect of the customer being able to close their own invoice, and given the number of objections to that feature in this thread, I do not think that is necessary now, and and may cause support issues, particularly if they keep pressing the button, they will end up with dozens of invoices. However, for admin to have this ability to present an upto date final bill for someone who is say closing their account would be desirable.

Les - your assessment is clear and correct, which to my mind validates the methodology, as you have clearly understood the process.


Our main concerns about rewriting this is the time it will take to implement this, and the level of instability that may be induced by what would appear to be minor changes on the surface, but in fact cause ripple effects elsewhere.

It is quite a big coding job, as every single item that changes the balance (recurring service, DID, Subscription, charge, refill, payment, CDR, plus a few I may have forgotten) has to write a record to a transaction table, and from that, the invoices can be generated, which is another big coding job.

Before spending the time to do an assessment of hours and cost on this, we really need more affirmation that this is the right way forward.

Joe


Top
 Profile  
 
 Post subject: Re: A2Billing invoicing - proposed work flow
PostPosted: Tue Feb 02, 2010 10:44 pm 
Offline

Joined: Tue Aug 19, 2008 3:49 pm
Posts: 184
jroper wrote:
Hi



It is quite a big coding job, as every single item that changes the balance (recurring service, DID, Subscription, charge, refill, payment, CDR, plus a few I may have forgotten) has to write a record to a transaction table, and from that, the invoices can be generated, which is another big coding job.


Can some of those items be consolidated under on menu or maybe removed?

Les


Top
 Profile  
 
 Post subject: Re: A2Billing invoicing - proposed work flow
PostPosted: Wed Feb 03, 2010 5:03 am 
Offline

Joined: Fri Jun 23, 2006 3:56 pm
Posts: 4065
Hi

Not easily. I cannot think of any that are surplus to requirements.

Joe


Top
 Profile  
 
 Post subject: Re: A2Billing invoicing - proposed work flow
PostPosted: Thu Feb 04, 2010 9:29 am 
Offline

Joined: Wed Sep 30, 2009 8:58 am
Posts: 49
jroper wrote:

Alternatively, the customer could close off their own invoice and pay it.


Joe Roper



Hi,

Joe, many thanks for the time&patience taken for preparing this, and as I was reading, I noticed above quote, which is also concerned by some other fellows here. I'm not clear on that.

- Does this mean that the customer can close off their invoice anytime they want, no matter any other factor?


Also, could you clarify how automated things will be in this flow? I mean what are the steps that admins need to do and take, and what are the customer related works apart from the paying. What I mean by that, do I as an admin need to manually create invoices and stuff, or what (sorry I'm somehow not very familiar with the way billing aspect of a2b works)

Thanks for your time once again!

Ali.


Top
 Profile  
 
 Post subject: Re: A2Billing invoicing - proposed work flow
PostPosted: Thu Feb 04, 2010 9:46 am 
Offline

Joined: Fri Jun 23, 2006 3:56 pm
Posts: 4065
Hi

The thought was that a customer could pay right up to the minute, all costs included.

e.g. You send out an invoice on the 1st of the month for a post paid customer. So that includes all charges upto and including the 1st. He gets round to paying his invoice on the 10th of the month. He sees his current invoice, and also the "Preview" invoice, that includes all the traffic and other costs incurred between the 1st and the 10th. He could opt to close that invoice turning it from a preview invoice to an actual invoice.

This would carry the balance forward from the previous invoice, and add in any traffic and charges reported on the preview invoice which would be anything from the 1st to the 10th . He would then pay the sum of money indicated by the invoice.

Once closed, another preview invoice would be created, and charges after the last invoice would be included, i.e from the 10th onwards, and this invoice would be turned from the preview invoice to the real invoice on the date of the next invoice run.

However, it has been thought that this may cause support issues, and make it difficult for A2B Admin to audit a particular account. So giving this facility to the customer may not be a good idea, but I think it is something admin may require. Especially if he is to close someone's account, and have it settled in full.


In respect of work by A2Billing admin, there should be no requirement for him to do anything other than log all payments from customers as they come in. If they come in via a payment processor (Paypal), then this will be
automatic as well.

I trust that this clarifies.

To understand it - think bank statement. With this approach, the customer can pay as much or as little as he wishes, and as long as he does not exceed his credit limit at any point, the calls will keep flowing.

Joe


Top
 Profile  
 
 Post subject: Re: A2Billing invoicing - proposed work flow
PostPosted: Sat Feb 06, 2010 1:18 pm 
Offline

Joined: Thu Dec 03, 2009 11:18 am
Posts: 62
In the "close invoice" issue: I think that as long as the system is setup to close AND pay the exact amount on the invoice PLUS any balance, should not have any coding nightmare no? The invoice will only close if the customer pay the full balance owed. a partial payment will not close the invoice.
A partial payment is just added to the current invoice as a crediit

Here is a suggestion on how an invoice should have as items.

ITEM QTY Desc Rate Price VAT TOTAL
BAL Previous Unpaid Balance (2010-01-01) 357.00
PMT Payment (2010-01-05) -357.00
DID 3 DID 2.00 6.00 8.25 6.5
123-5555, 123-5556, 123-5557
TRUNK4 2 Trunk 4 Channels 20.00 40.00 0 40.00
INBOUND 4361 Inbound Minutes Used 0.00 0.00 0 0
OUTBOUND 6427 Outbound minutes used (Local) 0.005 32.14 5 33.75
OUTLD 300 Outbound Long Distance 0.05 15.00 0 15.00
INTLD 50 Outbound International ----- 89.00 0 89.00
REP 1 Detailed Report request 20.00 20.00 5 21.00
FAX 2 Fax to email DID 5.00 10.00 0 10.99
123-5558, 123-5559
PPMT Partial Payment (2010-02-05) -50.00
DUE Total Amount Due 165.25

It should have every item the client subscribe to.

The REP item would be something one can add as a billable charge for a call detail report if a customer request one and added manually or automatically if it is a subscribed item.
:mrgreen2:


Top
 Profile  
 
 Post subject: Re: A2Billing invoicing - proposed work flow
PostPosted: Sat Feb 06, 2010 2:10 pm 
Offline

Joined: Fri Jun 23, 2006 3:56 pm
Posts: 4065
Quote:
The invoice will only close if the customer pay the full balance owed. a partial payment will not close the invoice.


No you clearly do not understand the workflow described.

Reread the process, and while you are doing so, try to imagine how a bank statement works.

Joe


.


Top
 Profile  
 
 Post subject: Re: A2Billing invoicing - proposed work flow
PostPosted: Mon Feb 15, 2010 9:31 pm 
Offline

Joined: Mon Feb 15, 2010 8:56 pm
Posts: 2
Joe

Thank you for a very concise workflow.

This really works for me. I like the idea of an 'open' preview invoice that consolidates purchases throughout the month and the bank statement approach. I would not trust a customer to close the invoice, however it is a must for the admin to be able to do so. I also like the rules, these need to be nailed to the floor with an audit trail.

Quote:
2. Send an invoice every month, with the balance carried forward from previous invoices. Thus the latest invoice replaces all previous invoices.


How are you thinking of sending the invoices?

Andy


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 23 posts ]  Go to page 1, 2  Next
Predictive Dialer


All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group