[6.0] [account] Cancel invoice is lost invoice number

[Moisés López - http://www.vauxoo.com]

1) Confirm a invoice
   Check the invoice number assing
   Now, Cancel the invoice
   Check the invoice number is lost
2) number is lost
3) same number before cancel
4) OpenERP-6.0
5) revno 4886

[Numérigraphe (numerigraphe)]

I think that's on purpose.
If you later re-confirm the invoice, it keeps its initial number. That lets you correct invoices : cancel, correct a mistake and confirm again.
Lionel Sausin.

[Amit Parik (amit-parik)]

Hello,

I have checked your issue and I am also agree with the comment#1.

When you confirm a invoice again after cancel it. It will again generated a invoice number so this is not a bug but it's behaviour.
Because when the invoice in cancelled state there is no journal entires for this invoice so it doesn't require any invoice number.

Generally the invoice number comes from the name field of journal entires (account.move) when you have validate the invoice the sequence will generated for account.move and this will sequence passed as a invoice number in account invoice.
When you have cancel the invoice the journal entries will removed. You can see at line no 1025 in def action_cancel method the move_id write as a "False" so the journal entires has totally removed that's why you can not seen the invoice number in account.invoice.

As per the functional behaviour, If the the invoice is cancelled that doesn't need any invoice number. And If you again confirm the same invoice the invoice number will be generated so this is not a bug it's behaviour.

So currently I am closing this issue.

Hope this will help for you.

Correct me If I am wrong.

Thanks.

[Moisés López - http://www.vauxoo.com (moylop260)]

Hi Amit Parik I agree with you on everything.

So I think that there should be the Invoice Cancel feature, where you just cancel the account_move

[Ariel E. Figueroa - http://www.humanytek.com (arielfigue)]

Mr. Amit Parik:

I read with interest your comments about report bug MoyLop and I think your explanation is valid only in certain circumstances or regions, I want you see this "out of the box" and see the problem as a problem of consistency of information and a receipted invoice, legally speaking should keep your number but with a state canceled, at least in countries like Mexico where I live and work and Argentina where I come from and I have knowledge of these issues too.
I do not read python code as well as it does moylop however as a OpenERP consultant in Mexico I think that implements OpenERP canceled if a invoice does not require a movement definitely book yet I believe the invoice may be tied to an accounting movement also canceled with the same invoice number canceled.
I do not think this should be seen as a behavioral issue, I believe very strongly that this should be seen as a problem that can have legal implications with customers sensitive countries whose accounting standards require.
I Hope you see the problem, if exist a module as account_anglo_saxon for inventory control according to the legal form of certain regions of the world, should be exist too a consistent behavior of OpenERP according to the law, this is a very very delicated problem.

Greetings from Mexico.
AEF

[Ferdinand (office-chricar)]

basic rules to be revision proof and avoid fraud and help users to organizer their work.
in many countries this is required by fiscal law, tax consultants, auditors etc.
* all changes to invoices (documents) after validation must be forbidden
* invoice (and others) numbers series must be gap less (and some of them must restart every fiscal year at 1)

so in day 2 day business we need ways to correct errors
* cancel an invoice /document
++ the printed invoice/document needs clearly printed "CANCELED" next to the invoice number
++ the attachment of the original invoice/document must be kept and marked as canceled and a new attachment must be stored to be revision proof
++ the associated account move lines must not be deleted but posted with debit/credit inverted amounts
++ if the cancelation happens as long as the period of the original moves is not closed the cancelation moves must be in this period, else in the current (of former year), else in the current period of the current year.
++ all cancel action must be audited - especially to allow support. information which was once stored and just "disapears"(accidently or deliberately) is a nightmare for any support team.

* amend validated invoices
this is very delicate, because it often happens that some minor changes are necessary which are not relevant for accounting and there is a need to allow such changes.
++ many amend action of validated/confirmed resources must be audited

the problem seems to be that the system does not remember (yet) which resources have been already validated

typically all amendments of SO,PO,PICK,INV,MO, partner, products, price list, timesheets, ..... should be audited appart from (most) actions which are controlled by the workflow (which should conform to the rules above) and hence are considered as "normal/accepted" .

[Ariel E. Figueroa - http://www.humanytek.com (arielfigue)]

Completely agree with you, Ferdinand, for OpenERP no exist a difference between a "manufacturing order" behavior and a invoice behavior, and I think very necessary that if there should be because, the tax rules most of the countries of the world are based on the invoice as element of verification against the law.
I know it's a very ambiguous that may be this improvement can be useful for certain countries and for others not so but I insist in my comment about account_anglo_saxon module, this "litle" diference of functionality makes the diference in many countries for do OpenERP a very valuable tool.
I hope the people in charge of decide these issues can make the smartest decision about this.