Invoicing: Best Practice?

[gemma-the-husky]

The thing is the client wants to group a bunch of order lines and invoice it. So if there are 10 Order lines in an order, she may want to invoice it as 3 invoices (6 Orderlines in 1, 4 in the next, 1 in the last etc.)

I'm really confused as to what to do.

I know invoicing the order as a whole would be the easiest.

But, I'm thinking if the user can select (using a tickbox) from the Orders form which of the OrderLines to invoice then and then comeback later on and invoice the rest? Not too sure how to implement this though.

This is the key statement to deciding what you want to do. It isn't what is easiest . It's what you have to do to solve the problem.

If you want, you could store an invoice number in the order lines table - then its easy to construct an invoice for selected order lines. But the problem then comes down to what happens if the whole orderl ine cannot be supplied. eg - someone orders 10 things, you supply 6 now, and 4 later. So, instead of trying to "fudge" a less than perfect solution - the best thing in my opinion is to use a properly normalised table structure, as I explained in an earlier post.

 

[Simon_MT]

You simply wouldn't get anywhere with my Invoicing system, it is too complicated. It involves margin VAT, undisclosed VAT, bi-directional calculations, multiple currencies, self-billing, various tax regimes including Zero Rated for Export and an Approval process. I'm not being precious about the structure but it is for a specialised market with three types of invoicing.

I'm happy to advise. You just need to remember that Invoicing is a staged process and if you manage the stages you have solved the problem. In a warehouse or manfacturing situation an Order is received, entered and awaiting to be fulfilled. It has to be made or picked, packed and delivered. Then invoiced but once invoiced only copies can be sent.

If you stand-back a little a chart what really happens in your business this is a helpful, all your need to do is emulate what really happens. I once made the mistake of not including O2 in a manufacturing process and could work why the calculations were wrong.

In the past I have got really cross with Access because I know what I wanted to achieve but couldn't programatically. I only use the Yes/No scenario when there can be only be two states. With stock there are degrees of saleability, I couldn't simply say this stock item is available for sale and had to go another stage to determine the status of the stock.

Simon