generate a sales invoice report without updating the ledger accounts


i am trying to find a way to print a sales invoice (an actual one, not a proforma invoice) without actually posting it.

the reason is the client wishes to send the invoice before updating his customer’s ledger account, and he wants to send the complete invoice details including the invoice number; which is why i couldn’t use the proforma posting feature.

how can this be done or is there a way around this?

That is what a proforma is really, if you do not like the word proforma then remove it, but there are potential legal issues here with the supply of goods and services along with the tax and movement of goods reporting when you remove the fact it is a proforma - by not identifying it there is no difference between it and an invoice, and therefore you would need to control how you identify these!

Yes, you should use proforma. For one of the customers I have created a functionality that is assigning real invoice numbers to proforma invoices. But as soon as you later post the order(-s) for real, it uses the same invoice number which you had on proforma that you printed earlier. But this does include some applicaiton modification and is not included in standard AX.

On a funny note, as a one-off solution - do the DB backup, post the invoice and restore the backup… [:D] But you better don’t try this at home…!

hi Adam; i understand what a proforma is however my only problem with it is that it is not assigned the invoice number. the customer wants to see an identification of the document to be sent to their customer as if it was an actual invoice.

janis i’d REALLY like to know how u managed to do so; maybe how you went through your solution logically. and if its not alot, what modifications were done.

Thanks for the replies =]

First of all, I know that this soultion is not 100% perfect as AX allows you so many ways of posting different sales lines on one invoice, which may even come from different orders… In ideal world you would have to save the posted sales lines of that posting query while printing proforma invoice and save those records somewhere along with the number assigned to the proforma invoice. Then, when you post the real invoice with the same selected sales lines (checking all values, like quantities, amounts etc), in other words - by verifying that this is totally the same posting as one used on the proforma, AX should look for the saved invoice number and assign it to the real invoice.

HOWEVER, in real world, where everyone is pushed by times and dead-lines, quick but not that accurate solution can be done as well - knowing that all lines from sales orders are always posted, you can just save that proforma number in a new field in a sales orders header and retrieve it later when posting real invoice. But this won’t be a good solution in case if partial order postings are done or you change any price/quantities/totals information in time between proforma and real invoice printing.

Janis hits the issue of the modification on the head really - you cannot at the proforma issue an invoice number that you can be 100% certain will be the invoice number - you can modify it to do this but the moment you part ship you are in trouble - you would need to modify it to only ever allow full shipments as well which is a restrictive process. Also what happens if the tax rate changes between issues - the customer has what they feel is a legally binding invoice that when the real one is produced is different. Then there is combined shipments, you cannot use this functionality. There are probably a few other reasons as well as legal considerations.

Janis, your solution would work for customers with a solid sales process. but like adam said it will totally throw away the “partial posting” functionality of AX.

the only problem is that the customer wants to control the invoice date of the sales invoice so that they adjust it according to the date the invoice was actually delivered which is never certain. and once posted, AX does not allow you to edit the invoice date.

It does not allow you to edit the invoice date for legal and tax reasons.

I would go back to the customer and sit down with them and find out the requirements and reasons why, telling them the local legal limitations and the systme limitations. There is a process to be mapped out and it feels you are trying to bend the system to a customer requirement that has not been challenged.

“Janis, your solution would work for customers with a solid sales process. but like adam said it will totally throw away the “partial posting” functionality of AX.”

That’s what I mentioned in the next sentence after offering you that solution. Secondly, even theoretically I cannot imagine any other solution that would be perfect (because it is just impossible).