Posting Error: Source Not Balanced for Invoice with Landed Cost Distribution


Posting Error: Source Not Balanced for Invoice with Landed Cost Distribution

The posting error above occurs occasionally in cases where the invoice line amount does not equal the sum of landed cost distribution amounts in the Invoice=>Invoice Line=>Landed Cost Allocation sub-tab
due to minor rounding differences. I experience this error when using cost distribution=costs but I expect the same issue to occur for all other distribution methods (e.g. weight)

Costing Method=Average PO

Example scenario:

1. Create Invoice for Landed Costs
2. Invoice=>Invoice Line=> Price = 2,900.01
3. Invoice=>Invoice Line=>Landed Costs, Enter MR document in field "Receipt". My MR document contains 3 receipt lines.
4. Push "Distribute costs"
5. Invoice=>Invoice Line=>Landed Cost Allocation. 3 distribution lines have been created with the following amounts (see screenshot):
At this point, all cost distribution amounts add up to the invoice line amount, that is, 2,900.01.
When posting these cost lines, the system rounds these amounts to 2 decimals:
The total posting amount from the cost distribution lines adds up to 2,900.02.
There is now a difference of .01 between the cost distribution lines (2,900.02) and the invoice amount (2,900.01)
6. Posting the invoice results in posting error: Source Not Balanced.

Ideally, the distribution logic would compare total cost distribution amounts with invoice line amount and add the minor difference (in my example 0.01) to the last distribution line.




Michael Powacht
July 16, 2018, 7:31 AM

Hello Soo Fang, I looked at your changes and I see that you use Standard Precision based on the currency.
It looks like our sample above distributes the values without creating balancing issues but I'm still concerned about rounding/precision. In our example above, the value of type double is=1270.5253733484. With your patch this amount is rounded to 1270.52 using BigDecimal.ROUND_HALF_UP but correct rounding would be 1270.53 (based on 1270.525).
Then again, if it's rounded correctly to .53 the balancing problem is still there.

Please let me know what you think,

Hiep Lq
July 16, 2018, 1:45 PM

before i also got issue "Source Not Balanced", i believe it relate rounding, but i can't figure out test data like Michael, so can't report issue here.

when i learn code, i saw somewhere use fix value "2" for scale. i guess it's other root course.

Soo Fang Lee
July 16, 2018, 3:05 PM

The amount 1270.52 is not because of BigDecimal.ROUND_HALF_UP, it is because the adjustment process will added total of allocation amount and adjust the largest amount.

Michael Powacht
July 17, 2018, 2:05 AM

You are absolutely right Soo Fang. I tested with different numbers yesterday and mistakenly interpreted it as a rounding issue. I retested it now using the exact same scenario:

//BEFORE Rounding
System.out.println(result) =>1270.5253733489405
lca.setAmt(result, getParent().getC_Currency().getStdPrecision());
//AFTER Rounding:
System.out.println(lca.getAmt()) =>1270.53

AFTER Adjustment: Invoice>Invoice Line>Landed Cost Allocation=> 1,270.52

Testing is successful. Could you please initiate a peer review to have it deployed in the public repository.

Michael Powacht
August 8, 2018, 6:46 AM

Many thanks!


Heng Sin Low


Michael Powacht



Tested By



Fix versions

Affects versions