Write-off popup for balanced paymens

Hi folks,

I agree with Samuel, OpenERP should not show this screen if there is no residual amount.

That's not that bad cause everything is alright with the move, but it's confusing people.

My2Cents,

Regards,

Joël

Hello,
I noticed that thing too and vote for you make the field readonly and not
mandatory as long as amount is 0.
Will decrease OpenERP entry barrier for newcomers which is always good.

2009/10/16 Joël Grand-Guillaume @ CampToCamp <
<email address hidden>>

> Hi folks,
>
>
> I agree with Samuel, OpenERP should not show this screen if there is no
> residual amount.
>
> That's not that bad cause everything is alright with the move, but it's
> confusing people.
>
> My2Cents,
>
> Regards,
>
> Joël
>
> --
> Write-off popup for balanced paymens
> https://bugs.launchpad.net/bugs/453030
> You received this bug notification because you are subscribed to
> OpenObject Addons.
>
> Status in OpenObject Addons Modules: New
>
> Bug description:
> There is always a “Write-off Move” popup dialog showing when doing a
> payment from the invoice and if the payment currency does not match the
> company currency.
> It seems the ERP does not check if there is any residual mount. It only
> checks whether the currencies match…
>
> Why should this be necessary for a balanced payment with no residual
> amount?
>

Hello,

would you please apply this patch and let us know?

Thanks.

Hi !

After testing this patch I aggree that he fix part of the problem : Adding rounding things and so on, this is ok. But for the test which decide if we need a write off or not, I'm not sure...

I explain my point of view :

- Company currency : CHF
- Invoice currency: EUR
- Amount of invoice : 900EUR.-
- Pay it with 900 EUR....

In this case, if my currency rate is still the same => I got no write off, this is ok

BUT, if my currency rate has changed since the invoice creation, then I got a problem... In this case, I won't be asked for a write-off, but I got one cause my amount in company's currency is not the same.

Si, I think this test should test the following :

If amount of the invoice in currency (EUR in this example) = amount paid in currency (EUR) AND amount in company's currency (CHF in this example) = amount paid in company's currency (rate of the payment dates), then no write-off !!

Regards,

Joël

Note : We also have a trouble with the amount in currency which is not given to the pay_and_reconcile function, so we do not write the amount in currency for the payment in that case... This is also a trouble reported here : https://bugs.launchpad.net/openobject-addons/+bug/461779

Hello all,

may be this report and the explanation by @sraps is a useful reading:
https://bugs.launchpad.net/openobject-addons/+bug/452854
may be the two bugs should be fixed together, if they are not even the same.

BTW, I said I found it annoying before that paying an invoice would ask for
write off account in case of full payment. I see that this has been improved
recently and seems to be only annoying when you use different currencies as
report here. This is much less annoying than before already.

2009/10/27 Joël Grand-Guillaume @ CampToCamp <
<email address hidden>>

> Hi !
>
> After testing this patch I aggree that he fix part of the problem :
> Adding rounding things and so on, this is ok. But for the test which
> decide if we need a write off or not, I'm not sure...
>
> I explain my point of view :
>
> - Company currency : CHF
> - Invoice currency: EUR
> - Amount of invoice : 900EUR.-
> - Pay it with 900 EUR....
>
> In this case, if my currency rate is still the same => I got no write
> off, this is ok
>
> BUT, if my currency rate has changed since the invoice creation, then I
> got a problem... In this case, I won't be asked for a write-off, but I
> got one cause my amount in company's currency is not the same.
>
> Si, I think this test should test the following :
>
> If amount of the invoice in currency (EUR in this example) = amount paid
> in currency (EUR) AND amount in company's currency (CHF in this example)
> = amount paid in company's currency (rate of the payment dates), then no
> write-off !!
>
>
> Regards,
>
>
> Joël
>
>
> Note : We also have a trouble with the amount in currency which is not
> given to the pay_and_reconcile function, so we do not write the amount in
> currency for the payment in that case... This is also a trouble reported
> here : https://bugs.launchpad.net/openobject-addons/+bug/461779
>
> --
> Write-off popup for balanced paymens
> https://bugs.launchpad.net/bugs/453030
> You received this bug notification because you are subscribed to
> OpenObject Addons.
>
> Status in OpenObject Addons Modules: Confirmed
>
> Bug description:
> There is always a “Write-off Move” popup dialog showing when doing a
> payment from the invoice and if the payment currency does not match the
> company currency.
> It seems the ERP does not check if there is any residual mount. It only
> checks whether the currencies match…
>
> Why should this be necessary for a balanced payment with no residual
> amount?
>

Hi !

So, I decided to report everything in this bug report. I linked my own one (461779) to this one and give you a patch which fix every purpose of both bugs :

- Adding the amount currency to generated payment lines in account move lines
- Avoid the window with write-off popup if not needed (Payment has no difference)

According to my test, we still have trouble with the residual amount discussed here : https://bugs.launchpad.net/bugs/427869

Regards,

Joël

This patch fix two bugs:

- Avoid write-off popup into pay invoice wizard if not needed
- Write the amount currency on payment in account move line object

Hello, not sure Launchpad is forwarding my mail reply here (doesn't seem for some reason, unless that's just lag), so pasting it again, sorry for the possible double post:

Hello Joel,

what a coincidence, we are working on this today too.
We share you opinion about using the payment dat for the write-off in the "pay invoice" wizard.

The only patch we will propose (nearly done, so will come like tomorrow at worst), is adding the optional write-off analytical account to be homogenous with this patch asked by Anevia and agreed by Fabien.

Still, we have a few open questions to present a more homogenous interface for both mentioned reconciliations:
- the comment field is optional in our attached patch and set by default to "Write-off" (as before our patch), while in the "pay invoice" wizard, it's mandatory but has no default value. Wouldn't it be better to have the same thing? What is the best then?
- we could-order the fields in the layout to have a similar layout. Do you agree, then what is the best layout to use?

Finally, I should say I wish to see the "pay invoice" wizard, along with "invoice on picking", "partial picking", and "group orders" wizards at the very least (others?) move to the new osv_memory framework for the 5.2 release. In trunk osv_memory support inheritance, this would finally, allow us to properly extend those significant features in extension modules while in the current situation we can do not really better than copy paste (I don't consider monkey-patching much better).

In the case, we move to osv_memory for 5.2, we could probably use THE SAME osv_memory wizard (provided we make it generic enough) for the both reconciliation situation mentioned. What do you think?

Hello Raphaël,

Great that you join my effort on that :) ! It's perfect, so you're working on the part I don't (add analytic part to other reconciliation process), we're lucky !

My opinion on your questions:

- For the comment field, I think we should have no default value (cause "write-off" is not relevant), and make it required to force people writting something smart...

- For the layout, I think it's a good idea to have the same also. Personally, I prefer the pay invoice design on this point, but at the end, the most important is to have something similar.

For the 5.2 version and the same osv_memory wizard, I dream about what you wrote since years :) ! So I'll be the first to help with that !!

Regards,

Joël

It has been fixed in stable version.
Thank you.