deleting an invoice from accounting-invoices, does not reset the check mark in the Sales order, for that line

[Mihai Satmarean]

Create a sales order with one or many lines
Confirm the sale,

go to one of the lines of the sale, double click and press "Make Invoice"

Go to Accounting->Clients-Invoices,
Delete the invoice

The state of the line is still invoiced!!

I expected that the check mark from the lines of the sale in front of the "Make Invoice"button, would be gone, but is not

Also in the Sales-> Lines to invoice the related line has the Invoiced check mark.

Thanks,

[Ujjvala Collins (uco-openerp)]

Hello Mihai Boiciuc,

The fix has been committed on lp:~openerp-dev/openobject-addons/trunk-bug-797083-uco with revision 4785 <email address hidden>.

It will be merged into trunk-addons soon.

Thanks for reporting.

Regards,
Ujjvala

[Ujjvala Collins (uco-openerp)]

Hello,

There are two possibilities, as per the bug, when we delete the customer invoice:
1. Invoice created for the whole sale order
2. Invoice created using the Make Invoice button sale order line.

Now we can achieve the solution by overriding the unlink method of invoice object,
-> For the first possibility what we have thought is, we can put the sale order in Invoice Exception state, where we manually cancel the Invoice first and then delete it.
-> For the second possibility we just simply change the state of sale order line and make the boolean field again False.

Overriding the unlink method can cause many other problems, so before applying this change we would like to ask the experts to share their views on this.

Thanks,
Ujjvala

[Ferdinand (office-chricar)]

"Deleting" invoices is problematic, because it violates good accounting principles (in Austria) which forbid deletion of posted moves (as it creates gaps in all sort of numberings which are supposed to be gap less)
I acknowledge that it is tempting to delete a wrong invoice and replace it with a correct one, nevertheless all information (especially reports) which is generated between posting of the invoice and deletion can not be explained. For partners this is an absolute horror to trace and explain this to customers.

IMHO deletion must be only be possible if at least tracing is turned on for account_invoice, invoice_line, account_move, account_move line.
please check bug
https://bugs.launchpad.net/openobject-addons/+bug/606172
if this works.

in any case I would prefer to have a "cancel" option instead of "delete", whereas cancel creates a reversed invoice (refund) with a new number and associated moves automatically.

this would also show up in the SO/PO history. and make things clear and transparent.

[Mihai Satmarean (mihai-satmarean)]

Hi,

I agree with deleting of the invoices is bad practice.

Nevertheless, in some cases, a user with enough privileges should be able to delete if some big mistakes are made.

But here in our case,
The reason why we delete invoices is simple, invoice module does not cover all the invoicing scenarios that we use. We, being a small production unit, we take even the smallest orders, we need to invoice with one missing feature "Invoice merging and splitting".

Then what we do?
Our sales orders are set to invoice on delivery because almost all the time we deliver more then ordered with a 5% amount.
We create the invoices belonging to many sales order, for the same client. we modify one of them to fit the whole delivery, and then delete the rest. (Here we would really need the merge invoicing feature) we did find in a "pastebin" some code, but did not get it functional till now. Here is the link: http://pastebin.com/crD6GTWe

Also next issue is when we partial deliver one sales order, we need to invoice only partial, but this is not possible when "Invoicing on delivery". Perhaps somebody could shed some lights on the best practices.

Here we run into troubles and did not find a best practice to this point.

My problem is that invoicing is not as flexible as we need, and we wait forward for the improvements ahead.

Till then we workaround how we can.

We are happy to report all our problems and scenarios and see that somebody is always there to fix.

Thanks.

[David Rinnan, Aspirix AB (david-aspirix)]

I am not sure about the many sales order to one invoice feature.

I do however know that it is possible to do invoice on delivery and partial delivery. The invoice will be managed via the shipping rather than via the sales order.
the sales order will however be updated with the amount invoiced.

I don't have the exact solution in my head at the moment but I have assisted one of my clients achieve this via configuration.

Regards
david

--
David Rinnan
Business Consultant

ASPIRIX AB
email: <email address hidden>
phone: [phone]
skype: david.rinnan
twitter: davidrinnan

Open Source Business Solutions

21 jun 2011 kl. 09.32 skrev Mihai Boiciuc:

> Hi,
>
> I agree with deleting of the invoices is bad practice.
>
> Nevertheless, in some cases, a user with enough privileges should be
> able to delete if some big mistakes are made.
>
> But here in our case,
> The reason why we delete invoices is simple, invoice module does not cover all the invoicing scenarios that we use. We, being a small production unit, we take even the smallest orders, we need to invoice with one missing feature "Invoice merging and splitting".
>
> Then what we do?
> Our sales orders are set to invoice on delivery because almost all the time we deliver more then ordered with a 5% amount.
> We create the invoices belonging to many sales order, for the same client. we modify one of them to fit the whole delivery, and then delete the rest. (Here we would really need the merge invoicing feature) we did find in a "pastebin" some code, but did not get it functional till now. Here is the link: http://pastebin.com/crD6GTWe
>
> Also next issue is when we partial deliver one sales order, we need to
> invoice only partial, but this is not possible when "Invoicing on
> delivery". Perhaps somebody could shed some lights on the best
> practices.
>
>
> Here we run into troubles and did not find a best practice to this point.
>
> My problem is that invoicing is not as flexible as we need, and we wait
> forward for the improvements ahead.
>
> Till then we workaround how we can.
>
> We are happy to report all our problems and scenarios and see that
> somebody is always there to fix.
>
>
> Thanks.
>
> --
> You received this bug notification because you are a member of OpenERP
> Accounting Experts, which is subscribed to the bug report.
> https://bugs.launchpad.net/bugs/797083
>
> Title:
> deleting an invoice from accounting-invoices, does not reset the check
> mark in the Sales order, for that line
>
> Status in OpenERP Modules (addons):
> Confirmed
>
> Bug description:
> Create a sales order with one or many lines
> Confirm the sale,
>
> go to one of the lines of the sale, double click and press "Make
> Invoice"
>
> Go to Accounting->Clients-Invoices,
> Delete the invoice
>
> The state of the line is still invoiced!!
>
> I expected that the check mark from the lines of the sale in front of
> the "Make Invoice"button, would be gone, but is not
>
> Also in the Sales-> Lines to invoice the related line has the Invoiced
> check mark.
>
>
> Thanks,
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/openobject-...

[Ferdinand (office-chricar)]

yes - invoice from delivery - using quantities given there - works

[Mihai Satmarean (mihai-satmarean)]

Hi again,

I do a partial delivery, but I do not know how to correctly deliver and invoice only half of every quantity there, and then later invoice the rest.

After that the scenario is to invoice only half of the lines with full quantity at a time, and then later on, the rest.

[Ferdinand (office-chricar)]

well you have do a partial delivery (1) and invoice the delivered (partial) quantity,
 (1) this creates a new picking with the remaining quantity
the workflow is a bit confusing , because the user does not see both pickings

[Meera Trambadia (OpenERP) (mtr-openerp)]

Hello,

Its fixed in https://code.launchpad.net/~openerp-dev/openobject-addons/trunk-bug-797083-uco.
Revision ID: mtr@mtr-20110818070939-rmaoyi438yu88ai9
Revision no: 4786

Thanks,
mtr