Is there a limit in order to make sure text boxes are large enough?
Several countries with exchange rates over 1000X per US dollar have deployments in development. For example, Tanzania has an exchange rate of ~ 1200 Tanzanian Shillings/US dollar and Uganda has an exchange rate of ~ 1700 new shillings/US Dollar, and there are some MFIs looking at deploying Mifos in those countries. Lebanon and Colombia are other countries that have exchange rates over 1500/1. Countries such as Mozambique and Zimbabwe have exchange rates over 20,000/1 as Sam mentioned. I definitely think group loan amounts could easily be more than 7 digits in some of those countries. You can see exchange rates for countries in Africa at http://www.mbendi.co.za/cyexch.htm#top and exchange rates across the world at http://www.exchangerate.com/world_rates.html. With that in mind, I think 10 digits before the decimal would be an appropriate limit for data entry. Reporting will need even larger limits since reports often include total loan amounts over a period of time, but that will be configured separately. If anyone has any other data we should take into account, please let us know. Thanks, Beth From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sam Birney Sent: Thursday, February 28, 2008 12:41 PM To: Developer Subject: Re: [Mifos-developer] Configuration - AccountingRules questions This is an interesting question. I also don't see why someone would want to reduce the possible number of digits before the decimal, will have to see if someone can provide that input on from a functional spec perspective. As far as the ceiling goes, we'll have to keep in mind exchange rates in various countries. For example, according to a recent web search just now, 1 US Dollar = 30,538.9 Zimbabwe Dollars. So, you can imagine that we might need a lot more digits to the left of the decimal to deal with reasonable amounts in that currency. Fortunately for our set of initial deployments, it looks like the exchange rates are all within 100X per US dollar (the currency that many developers happen to be most familiar with). The Mifos program managers are currently looking at the requirements for this to make sure that we have the precision needed to support all our deployments. On Thu, Feb 28, 2008 at 10:24 AM, Van Mittal-Henkle <[EMAIL PROTECTED]> wrote: > I see two options that allow the user to configure the number of > digits before the decimal: > > AccountingRules.DigitsBeforeDecimal=7 > AccountingRules.DigitsBeforeDecimalForInterest=10 > > My understanding was that there is a ceiling on how many digits Mifos > will handle before the decimal. Are the above values the ceiling? Yes. > Would we ever expect a user to reduce the number of digits before the > decimal in a custom configuration setting? If they did, what would > this achieve? These are limits that are set on user input. In the Mifos UI a user will be prevented from entering more digits than this to the left of the decimal separator. Prior to the configuration project these limits were hard coded with the values currently in the default config file. Now they have been pulled out into configuration settings. I haven't seen any documented use cases, but I was imagining that this would be used to enforce an upper limit on values that an end user could enter into the system. Kim can correct me if I'm wrong on any of this or add to it if there is more relevant detail. > I'm trying to understand this configuration setting both from the > perspective of a tester who needs to write test cases that exercise > this functionality, but also from the perspective of an MFI or Mifos > Specialist configuring Mifos. To me, it seems like this is > unnecessary configuration for a user to specify (and if that's the > case, it should not be in the file). If there are no use cases for it, then it could certainly be removed. Note that to remove it cleanly would entail code changes other than just removing from the config file. It would be good to understand what use cases there are (if any) from the functional perspective. --Van ------------------------------------------------------------------------ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
