[Mifos-developer] progress on currency denominated loan products work (story 2176)
Adam Monsen
currencies" - http://mingle.mifos.org/projects/mifos/cards/2176 ). I
started by learning just how currency configuration works. I was then
able to clean up AccountingRules a bit, and this eased cleanup of
MifosCurrency as well. For instance, the "default currency" flag in the
database was never used, and the application-wide configuration file
will be used to set which currency is the default. I've also added a few
empty test methods to AccountingRulesTest:
canConfigureAlternateCurrency,
canConfigureAlternateCurrencyWithNonDefaultDigitsAfterDecimal, and
canConfigureNegativeDigitsAfterDecimal. I'm not sure about the third
one; it might be another configuration value (or several) that need to
be able to go negative for working with currencies that need to be
rounded to, for instance, the 10s or 100s place. Again, AccountingRules
doesn't have any of the code implementing the logic indicated by the
test stubs, but is mostly cleaned up and ready to be augmented for
adding multiple currencies.
Related changesets: r16400, r16406, r16416
Still on branches/currencyCleanup: r16465, r16466
I was blocked for quite a while trying to get the acceptance tests to
run. The problem turned out to be the presence of several different
database revisions in test data sets.
Details:
Upgrading all 59 datasets took a long time on my laptop, and several
dataset upgrades broke because not all of the datasets started at the
same database_version. Given datasets with different values for
database_version and certain schema changes, the same
latest-schema_last.sql is not usable by DataSetUpgradeUtil for upgrading
all datasets in a given directory using the --dataDirectory command line
option. After I figured out the database_version mismatches, I was able
to run DataSetUpgradeUtil a few times using different versions of
latest-schema_last.sql. I attached some output from DataSetUpgradeUtil
showing the errors I was seeing in case it might help someone else in
the future. "error in upgrading to 226" showed up for a bunch of the
datasets, and "Field 'DEFAULT_DIGITS_AFTER_DECIMAL' doesn't have a
default value" showed up for one dataset.
Udai Gupta
@Dataset upgrades
I have been into the similar situation few days ago, so I can understand how painful it can be. I am not sure how some datasets were left in inconsistent state as I ran DatasetUpgradeUtil for both 226 and 227 successfully. I think merging can also leave the datasets in inconsistent state by replacing the latest one to an old version and tests doesn't fail at these inconsistency. Doing a simple validation while reading the dataSet for acceptance tests could take care of this issue.
The dataset are read by DBUnitUtil from common module, while reading dataset get the DATABASE_VERSION using dbunit getTable.getRow from dataset and match it with DatabaseVersionPersistance.DATABASE_VERSION, fail if doesn't match.
I am still not sure about the way to do that, because I don't want to have a new DATABASE_VERSION in common module as it will increase upgrade overhead. May be we could move DatabaseVersionPersistence to common module.
Udai
Keith Woodlock
As I will be looking into refactoring loan creation and loan products
are directly related to this area I was wondering could you explain a
bit more about story 2176?
"Add configuration of multiple currencies"
So what exactly does this mean?
What does it enable in terms of the application?
KeithW
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
Jeff Brewster
tests could take care of this issue.
I've created a new acceptance test - DatasetVersionTest which will
compare the DB version for each acceptance test to the DB version in the
running Mifos application. This should at least flag when data sets are
not on the latest revision - and remind anyone doing a DB change to
update the data sets prior to check in. However, I have disabled the
test for now as I'm encountering a difference in behavior between
Eclipse and mvn command line. In the test, I look for the data sets as
follows:
File f = new
File("acceptanceTests/src/test/resources/dataSets");
FileExtensionFilter filter = new
FileExtensionFilter("acceptance_", "dbunit.xml.zip");
File[] acceptList = f.listFiles(filter);
This presumes the working directory is the top mifos directory. This
works in Eclipse. However, when I run this same test from mvn command
line, the test fails because it can't locate any of the datasets. I
haven't yet determined where the working dir is from mvn command line.
Jeff
Udai Gupta
its great to have a test for dataset version. I enabled your test at trunk.
I have changed the path to "target/test-classes/dataSets" and it was
working for maven, but its not working for eclipse.
Udai
Adam Feuer
> I have changed the path to "target/test-classes/dataSets" and it was
> working for maven, but its not working for eclipse.
Jeff, Udai,
I think this can be fixed by changing the Eclipse compile system,
under Project Properties > Build Path - Eclipse may not be placing the
datasets into the right directory. I can help with it when I get back
if that is the case.
-adam
--
Adam Feuer <adamf at pobox dot com>
Jeff Brewster
>under Project Properties > Build Path - Eclipse may not be placing the
>datasets into the right directory. I can help with it when I get back
>if that is the case.
>
Udai & Adam,
Thanks Udai for updating that path to make it work in maven. Sorry I
forgot to submit my change to DbUnitUtilities.java to include the
ignored columns map.
I've found this path works in Eclipse -
"acceptanceTests/target/test-classes/dataSets", where in maven it's
"target/test-classes/datasets" So the data sets are placed in the right
location, but it appears to me that in Eclipse the acceptance test has a
different working directory than maven. I've added this comment to the
test.
Jeff
Van Mittal-Henkle
AdamM is out on vacation this week, so I'll provide a little background
on this.
At the Al Majmoua deployment which is underway, they issues some loans
in US Dollars and some in Lebanese Pounds. In order to support this we
are adding a feature called "currency denominated loan products". The
basic idea is that when you create a loan product you will be able to
specify the currency to be used for any loans created using that loan
product. So for a given loan (and any operations it does) the currency
used will come from the loan product associated with the loan. The list
of currencies to choose from will specified in the configuration file
(which is what AdamM has been working on).
You can find more details about this feature here:
http://www.mifos.org/knowledge/functional-specifications/account-creatio
n/currency-denominated-loan-products
--Van
----
Van Mittal-Henkle
Mifos Software Developer
Grameen Foundation
va...@grameenfoundation.org
> -----Original Message-----
> From: Keith Woodlock [mailto:keithw...@gmail.com]
> Sent: Thursday, December 24, 2009 6:02 AM
> To: Mifos software development
> Subject: Re: [Mifos-developer] progress on currency denominated
> loanproducts work (story 2176)
>
> Adam,
>
> As I will be looking into refactoring loan creation and loan products
> are directly related to this area I was wondering could you explain a
> bit more about story 2176?
>
> "Add configuration of multiple currencies"
>
> So what exactly does this mean?
> What does it enable in terms of the application?
>
> KeithW
>
Keith Woodlock
Thanks for that. From reading through functional specs I can see that
it is not really about 'multiple currencies'. So the system still only
supports a 'single currency' but when creating loan products and thus
loans/fees, they will be presented with option for choosing the
'single currency' they want associated instead of always defaulting to
the 'default currency'.
So the system could now possibly have loans in 'multiple currencies'
but it is still 'single currency support per loan account'. I think
its worth clearing that up.
I was going to ask about collection sheets regarding this but i can
see its a non-goal, although its easy to see how confusing this would
be for people using the collection sheet that loans displayed on
collection sheet can have 'different currencies' but that this is not
indicated through the UI.
KeithW
Van Mittal-Henkle
> So the system could now possibly have loans in 'multiple currencies'
> but it is still 'single currency support per loan account'. I think
> its worth clearing that up.
Yes, you've summarized the initial goal nicely.
One thing that is worth noting (and relates to some previous discussion
on the list about multi-currency support) is that the way these loans
are used in practice includes payments being made in multiple
currencies. So, for example, a loan in US dollars might have some
repayments made in USD and some in Lebanese Pounds. This won't be
tracked initially (all payments will be entered as USD), but eventually
we may want to support recording of payments in multiple currencies on a
given loan.
> I was going to ask about collection sheets regarding this but i can
> see its a non-goal, although its easy to see how confusing this would
> be for people using the collection sheet that loans displayed on
> collection sheet can have 'different currencies' but that this is not
> indicated through the UI.
Yes, more thought and work would be required for reconciling collection
sheets and multiple currencies. Since collection sheets are not used by
the initial customer using currency denominated loan products, we've
sidestepped this issue for now.
Cheers,
--Van