webERP Forum
Statement of Cash Flows - Ignore Tiny Amounts? - Printable Version

+- webERP Forum (http://www.weberp.org/forum)
+-- Forum: webERP Discussion (/forumdisplay.php?fid=1)
+--- Forum: Problems / Bugs? (/forumdisplay.php?fid=8)
+--- Thread: Statement of Cash Flows - Ignore Tiny Amounts? (/showthread.php?tid=8310)



Statement of Cash Flows - Ignore Tiny Amounts? - VortecCPI - 12-15-2018 05:59 AM

GLCashFlowsIndirect.php

This report is showing data for accounts balances that are tiny. Other reports are not doing this so I assume this is something specific to this report. I increased decimal places so I could see the true values:

[attachment=948] [attachment=949]

If I change this:

PHP Code:
if($MyRow['ActualAmount']<>

To this:

PHP Code:
if(abs($MyRow['ActualAmount'])>0.005 

The accounts with $0.00 come off the report.

Is there a more elegant way we can ignore these tiny amounts? Perhaps by using $_SESSION['CompanyRecord']['decimalplaces'] to set accuracy/granularity?


RE: Statement of Cash Flows - Ignore Tiny Amounts? - VortecCPI - 12-15-2018 10:22 PM

Maybe this is a good thing a s it causes us to dig deeper into why zero is not really zero...


RE: Statement of Cash Flows - Ignore Tiny Amounts? - falkoner - 12-15-2018 11:19 PM

(12-15-2018 05:59 AM)VortecCPI Wrote:  Is there a more elegant way we can ignore these tiny amounts? Perhaps by using $_SESSION['CompanyRecord']['decimalplaces'] to set accuracy/granularity?

That is the way we normally use, but the most elegant solution would be to not have those tiny amounts in the first place.


RE: Statement of Cash Flows - Ignore Tiny Amounts? - VortecCPI - 12-15-2018 11:32 PM

Agreed but in our case this is due to tiny rounding differences in tax and per-unit price. With only four decimal places at the stock level there is no getting around it.
I suppose some sort of manual GL Journal entry would fix it but it will always exist as we move on with business transactions.

You can see the differences below:

[attachment=950]

We only have two decimal places for USD but costs and taxes use far more so we will always have a small discrepancy. Our stock per-unit cost/price uses all four decimal places and even that is not enough to produce cost/price matches in all cases. Z_CheckDebtorsControl.php shows small (but matching) differences for every period.

So far tax has caused us the greatest pain as whether we were to round up or round down we we always have a small difference.