Reverse Shipments don't post because of Not Balanced in special case

Yes, please go ahead and add that.

Reopening to check performance

Hi @Heng Sin Low, when applying this in the stage environment noticed that posting is taking long time, for example, posting a 7 lines reverse shipment is taking more than 20 seconds.

So, analyzed and the problems are mostly in the queries that look for the fact_acct to reverse.

I added the following index and it works a lot better:

Posting went from 20 seconds to 2 seconds.

Do you think is OK to add it to core? Or keep it as customization here?

BTW - the opening of the Posting window is also impacted in a good way, something like clicking the "Posted" button takes 4 seconds without the index and less than 1 second with the index.

WDYT?

For safety and consistency, make sense to add it to those other place you mention as well.

Thanks @Heng Sin Low - ready.

Hi Carlos,

For safety and consistency, make sense to add it to those other place you mention as well.

Hi @Heng Sin Low

I added a commit with an explanatory comment in the javadoc.

Also, I found the same problem in a normal use case using Inventory Move for re-serialization (change of attribute set instance).

You can see the posting of this inventory move reversal in test server:

The posting is not balanced resulting in a Suspense Balancing account.

In theory this problem can happen in all the other documents using FactLine.updateReverseLine, for example:

• Doc_Inventory if somebody uses the Asset and Inventory Difference (or Charge or Cost Adjustment) with the same account

• Doc_MatchPO if somebody defines PPV and PPVOffset with the same account

• Doc_MatchInv same case with Inventory Clearing and Not Invoiced Receipts

Wondering if we must add the true/false also to these classes just to be safe?

Inventory Move Reversal:

Wrong posting with Suspense Balance