Hi developers,
I’ve always heard and read that posted entries should never be changed, I do understand but in my company’s case this is just IMPOSSIBLE.
I have two reasons to change them:
1- financial department posted outstanding last year invoices and phone one day to tell many of them are wrong on amount, date or customer instead. You will ask how is it possible? (I ask myself too), but that’s it
2- posted invoices: think you create invoice ‘FV001’ with posting date ‘01/02/07’ and send it to the customer. He reply telling that the invoice must have date ‘31/01/07’ so I understand you should create a Credit memo for it and redo the invoice. But this will be nearly always after we have created another invoices and, at least in our country, you must have correlative No. and dates. For this I have to “move” invoices
Taking care of all tables affected: Cust. Ledger entries, Detailed Cust. Ledger entries, G/L entries, etc… what’s the problem on changing No.'s, dates, amounts and also deleting?. I have been doing it for the last months and there’s no inconsistent problems, accounting problems, or everything else.
Please spread your opinions !!.
Is there any local country legal requirement to produce the original invoice issued?
Your customer is dictating the invoice to you, so why are you producing the invoice prior to the customer dictating the details? I do not agree with this approach but understand it in some industries, the cost of doing business with the customer.
How are your auditors tracing transactions when the documentation produced bears no relevance to the details in the system when you adjust them?
Are you audit trailing your changes?
Does your government mind if you alter posted legal documentation which may include the tax implication to the government? You will presumably have to detail that you have not altered this?
Good points I also marked with a ‘?’ when I saw them[;)]
Our invoices are created and sent according (more or less) with the due date but for example, think an invoice sent with date ‘02/07/07’ and the customer tells us to change it to ‘31/06/07’ just to include expenses on the second trimestral taxes. We should say no but ‘what the boss says goes’ (jajjaa) and he always please the customer, and I do understand.
So the next step is to call me to change everything neccesary to do it, if the invoice to change is the last I’m lucky, but almost always I have to use “tricks & traps” [8o|]
I don’t really understand this question but if you’re talking about accountant incongruencies… we have had none
I did it at the beginning but watching there were no problems after a pair of months I left. Mean that previous invoice have never existed [:S]
Government knows absolutely NOTHING, of course. This are just internal adjustments’ [:D]
Thanks for the reply Adam
By the auditors there are several aspects here, you could be audited by teh government, they would check transactions, you could be audited for your accounts, so they pick an invoice and check where the postings went on what dates and what the tax implications were.
I think if you were doing this in the UK and they discovered what you were doing there would be serious repercussions, for example how do they know you are not avoiding tax with your “changes”. For example your initial invoice is outside a tax period, you report the tax period, then you move it into the closed tax period, you could be ducking the tax, even though NAV should pick it up if you run it correctly.
I just do not think any body regulating your industry or with any power would look kindly on what you are doing.
I was once involved in an implementation where the wrong commodity code was used in reporting for Tax, they declared the goods as fertiliser not pharmaceuticals (an honest mistake I believe) but customs and excise cam in and took the entire infrastructure away for 6 months to assess the transactions, the bill was over €300,000 I believe in the end.
My reference to auditing your changes is to prove to any investigating body that you made the changes and the reasons for changing them, if you are no longer doing this they would assume every entry had been altered.
And let me ask the governement question another way, they currently know nothing, if they found out how would they view these internal adjustments?[:D]
Ask your boss to raise the credit memo and the invoice. I am presuming it is the invoice date and not the “due” date which you can manually enter on the customer ledger
In spain when you make a correction to an invoice you have to issue a corrective invoice, which is called a ‘factura rectificativa’. The process is quite simple. You issue an invoice, the client calls you and says detail such-and-such is incorrect. The only legal way of correcthing this to generate a corrective invoice from the incorrect invoice - which must indicate the invoice number it corrects. Within navision this will imply cancelling/reversing the G/L entries, and tax entries and then creating a new non-posted invoice which you then register using a new reference number. It should be said that very few companies either know the spanish legislation nor respect it. Many (most?) of the ERP packages do not provide any means to generate this type of invoice. Laughably accounting postings have to be numerically correlative by date - something which is impossible to all intents and purposes, so all packages provide a renumbering function which updates the numeric sequence before presentation. Ian
Thanks for the local insight Ian, so there is no issue in Spain with this approach, in theory, or at least the theory if no one finds out!
Adam → even if it doesn’t appear, no tax is defrauded but accounted on a different period, I promise [;)]
imurphy → corrective invoice… interesting concept I didn’t know, but I will comment it tomorrow at the office, thanks [:D]
everybody → I know we should find another way to invoice properly but the thread wasn’t really created for my particular case. I read many times posted entries mustn’t be changed in NAV but I wanted to know if this is just for legal affairs ¿?, because as I understand it’s just about knowing tables affected. More expert’s opinions please?
Without a full audit trail how do you prove no Tax has been defrauded [:D]
I think the biggest thing is two fold. You look at the system, and what it has generated has changed, and you can never track this change because the change has happened outside of normal processing, there is no invoice and credit memo relationshop, there is just the possibility of a figure in one table, and one in another that are different an no way of finding out how, and any partner or Microsoft will ALWAYS blame you for changing it - how can they ever investigate any error or possible bug when you are changing the figures in the tables - there is no solid base to test from or replication procedure etc.
Using the system to correct errors just lets everyone see what was done and why - even if it takes longer it maybe shorter and cheaper in the long run.