Community mailing list archives
Re: Invoice can be deleted but not recreatedby
Camptocamp SA, Joël Grand-Guillaume
That said, I'm 100% in-line with you here. The current implementation is really, well let's say not perfect ;) Solving this in a OCA module makes sense for everyone. The main issue for me is that in some cases, we can't revert what has been done (e.g. the workflow of the PO when invoiced, even if you delete the invoice). I also have the feeling that all this is very linked to the invoice policy you choose on the PO, so you might want to summarize the differences based on various invoice policy...
HiThanks Jordi to push this blue print. However, I can't make any suggestion, you may want to change the permission on this file so everyone can contribute.
On Thu, Apr 23, 2015 at 10:08 AM, Jordi Ballester Alomar <firstname.lastname@example.org> wrote:
Oh, Eva, and by the way, regarding this comment "I speak as probably the only non programmer of the group. So, my suggestions come purely from a functional point.", since you have now Daniel Reis "Odoo Development Essentials" you are now part of this elite group of programmers ;)On Thu, Apr 23, 2015 at 10:00 AM, Jordi Ballester Alomar <email@example.com> wrote:On Wed, Apr 22, 2015 at 6:24 PM, Eva Pinter <firstname.lastname@example.org> wrote:
Hello Jordi,I believe the easiest would first be to have a warning when deleting an invoice that is linked to a PO. So the user knows that there will be consequences.To go further, I would really prefer to have only 2 ways of creating invoices for PO. The first would be that I create the invoice manually and that I can select the PO lines that would be copied into the invoice. This would ease the creation of invoices as well as the automatic creation of invoice from OCR, that is not possible at the moment, due to the invoice control as it is.Then, I believe that when an invoice is deleted, the system should check if the position is linked to a PO line and if it is the case, the PO line should be marked as not invoiced. This should work the same way, if you cancel the invoice, the system should know that it is not invoiced anymore as the invoice has been cancelled.I have started to document the approach that you are describing. This is the blueprint document https://docs.google.com/document/d/1wh4Kbxa_UgaPi6eVIgILG37j2a-RdUX26TFdOOybnU8/edit?usp=sharing But it's a very early draft.The second would be as it is now, based on received goods that works (so far) perfectly and logically.Well, there are some scenarios that are currently not supported by the Core:
- Create Invoices for part of a PO line => This is supported by an existing OCA module purchase_partial_invoicing- Create Invoices for part of an Incoming Shipment that has been received => Currently not supported. I'm working on this one.IMHO the right approach is to create the invoice first, and then match it, as you described above. But I have not yet quantified how hard is it to implement.I speak as probably the only non programmer of the group. So, my suggestions come purely from a functional point.ThanksOn Wed, Apr 22, 2015 at 5:48 PM, Dominique Chabord <email@example.com> wrote:2015-04-22 17:18 GMT+02:00 Jordi Ballester Alomar <firstname.lastname@example.org>: > Well, but that's a very bad think, because the system is letting you do > something for which there's no reversal possible. yes, either I miss something in Odoo since ten years or we are in this bad case. Not sure anyway I fully understodd Eva's point. > > What I mean is, if I create an standalone invoice and then I delete it. > There's a possible reversal or restoration to the previous state, which is > to create the invoice again. This is the essence of a draft. Good so far. > > But if I create an invoice from an approved purchase order, and I delete the > invoice, that order is left in a status "Purchase Order" for which I can't > do anything. I cannot restore the previous state in any possible way. Because the "draft" is not a draft. It is a suggestion by the workflow managed like draft by Odoo. Not only for invoices. > > These situations should be prevented. Possibly by making sure that an > invoice cannot be deleted once it has been referenced. This would be a deep change in Odoo. What if you just modify the invoice ? The basic workflow is at stake, I think.Not sure why it would be a big change. When the user attempts to delete, the system checks if there's a PO that references this invoice. If there is, you stop the user from doing so.And then you can apply this same behavior for stock moves. That is, if a stock move references an invoice.Probably there are other processes where this can occur. But it seems to me that this one can be fixed with a single module... or I'm missing something here.> > I'm not sure if that's a bug. If I make no mistake, it is a historical feature or a limitation of the framework. I remember this was globally fixed in a "well known fork" and it was a big change. There, all suggestions issued by the workflow which haven't been committed, can be reissued from fresh situation (and they actually are iif the situation has evolved). This makes a big difference in all applications.A different thing would be when you have created the invoice, and you realize that you didn't want to, maybe because you'd like to split the invoice. In that case I'd agree with you that the workflow would be affected and the thing to do would then be to have a reversal mechanism, instead of a preventive check that doesn't let you delete invoices.>And if it's not, I'd suggest that we create a > module to prevent this from happening and publish it to the OCA. Not sure you can fix it across all the erp with a module, but may be it might fix the specific point of the draft invoice. > > Regards, > Jordi. > > > On Wed, Apr 22, 2015 at 5:09 PM, Dominique Chabord > <email@example.com> wrote: >> >> hello, >> if I understand correctly, the problem is a known native problem. Odoo >> doesn't make any difference between a handmade draft and a suggestion >> made by the system which should be recalculated automatically in case >> you delete it. This is true in all the applications since Tinyerp 2.0. >> Never delete any draft created by the system. >> regards >>----