Hello Udai,
i apologise but i haven't looked at the corresponding code and
implementation. However, i have something to offer in terms of
functionality (and therefore, i am forwarding this to the user mailing list
as well).
Accounting itself does not entertain entries with a precision that exceeds
the precision of money amounts as they are in the real world.
To try and illustrate: the loan management system may compute and use
intermediate amounts (such as interest for a particular time period) that
temporarily are a different precision than the required (say, two digits
after decimal). The necessary rounding rules must kick into action when the
results of such calculations produce "final" computed amounts
However, in accounting, for example, it is not acceptable for an accountant
to record journal entries (such as Dr. Cash by INR23.56*75*/-, and Cr.
Loans Made by the same) that are to an unrealistic precision. She cannot
even make a series of entries that have the cumulative effect (with other
journal entries such as Dr.Cash by INR23.56*25*/-, etc.) that all result in
a "realistic" precision. Each entry must follow the rules for the integrity
of double-entry accounting, as must all entries taken together.
Of course, the accountant does make other "rounding" adjustments, but these
are in a different sense and context, and their material impact, if any,
must also be documented and disclosed.
So, the question of "MORE" precision in accounting than in the loan
management system does not arise. If "lower" precision is chosen, it will
necessarily produce (in an unpredictable way) differences in amounts
reported between accounting and loan management
There's my .02
i might be able to look at the implementation later and provide more
insight as to whether this is a misnomer, or a result of the current
implementation with a perfectly "valid" explanation in the local sense.
thank you,
krishnan
On Thu, Nov 24, 2011 at 12:59 PM, Udai Gupta <[email protected]> wrote:
> Hi,
>
> I was just wondering why this new configuration is required
> AccountingRules.DigitsAfterDecimalForCashFlowValidations. Shouldn't
> this be depended on or derived from AccountingRules.DigitsAfterDecimal
> if more precision is required.
>
> I am guessing AccountingRules.DigitsAfterDecimalForCashFlowValidations
> = AccountingRules.DigitsAfterDecimal + 1; (more precision is required
> for calculation) which can be an internal property.
>
> I haven't looked at this in detail so if there is an obvious reason
> why this should be left for user to decide what precision should be
> used for CashFlowValidation then I would vote for removing this.
>
> Udai
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> Mifos-developer mailing list
> [email protected]
> Unsubscribe or change settings at:
> https://lists.sourceforge.net/lists/listinfo/mifos-developer
>
--
Regards,
Krishnan Mani,
for MOSTFIT
(email) [email protected]
(cell) +91 93 26 36 46 39
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Mifos-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mifos-users
