@etobella Thanks for the PR!
Well, it fix the example I gave in the issue yes, thanks, but it does not fix all cases, like the one in the second issue.
Let me show you what I have with the same setup from #693

Default screen when going to reconcile UI, we have a rounding issue

After entering the 121000 account in manual tab :

@florian-dacosta Round 2

I added a rounding factor in order to remove this possible error (the rounding should only be used on comparison)

@etobella I still don't get why there is a rounding to find an amount that is written in the amount field of the account.bank.statement.line. Why the 259 200 needs to be computed and not read for the line ?

Anyway, I've tested the later version
I still get this rounding issue before chosing the invoice.
And once validated, the state /payment on the invoice is not ok.

Go to reconcile UI - Not OK

Choose the invoice - OK

Reconciled invoice after validation - Not OK

The bank accounting entry is missing the currency on the 121000 line

We have a rounding issue because the reconcile is done on the currency of the company. Also we cannot use that amount, because we might have previous lines.

The only option I can see is to do the reconcile in the amount of the statement line.

This is more work to do and I just wanted to add a patch, but seems we need to do a real refactoring (it is good to have so many tests)

Thank you for your help with these issues, @etobella.
As previously mentioned by @florian-dacosta, we're in a rush on this topic due to our customer's situation—they've been expecting to use it properly for 6 months now. I hope you can tackle these topics and help us resolve the issues.

@PaulGoubert @florian-dacosta Round 3

I have changed the flow in order to compare using the currency of the line. It has no sense to move from EUR to USD to EUR, so it should remove some of this errors.

The only issue I found is that it is not showing properly when reconciling with the Foraign Exchange Loss

Before Reconciling

After reconciling

The foreign loss has been lost, but it is correctly reconciled

I applied a fix for this. I am not sure if it gets all the possible cases, but at least it is an approach

@etobella Thanks for your work, it is really helpull !
About the rounding case, with last version of the code, here is what I have :

1. First click on the reconcile button on journal
   

2. It give me the reconciliation screen with the rounding error in the suspense account :
   

If I choose the counter part, all is fine, then when I reconcile, as you saif, all is fine, the invoice is reconciled correctly, the accounting entries are correct.

3. Right after, the view of the statement line in the reconciliation UI was correct. I am not sure how it work, but with a new tab/after restarting the server and going back on the statement line, I have really strange data :
   

For now the most annoying for me is the display in 1. Even if all goes fine after, it is very confusing for the user.

I applied a fix for this. I am not sure if it gets all the possible cases, but at least it is an approach

I am not sure what you refer to ?
If it is about the last created issue (695), I have just updated it because I had made a mistake in the screen shot of the use case.
I have tested again right now, and it is still actual.

1st point should be solved now.

1st point should be solved now.

It is, thanks
I have made a PR on yours to fix different other issues, Take a look when you can

@etobella Could you rebase please ?