|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d
_______________________________________________ Mifos-issues mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mifos-issues
Vishwas,
In reverse order:
3) your right, dont worry about it for now. It will come up in time if needed. I would of thought they would of entered the whole cheque no not just the sequence number though.
2) I dont see the need to have both savings and loan 'additional transaction/payment details' entered in the same table. Cant see how that would be useful or of advantage. Would expect savings to have its own table for extra payment details. Right now that might be the identical.
1) So in the scenario of transactions that have an entry in the one-to-one payment table that are reversed, to retain one-to-one modelling you could:
a) just create a new entry in the table with same details as of before OR
b) remove relation from 'reversed' transaction to payment details and replace with new transaction
Of these I think 1a is the preference as it retains all details of reversed transactions.
If you retain the existing one-to-many approach you have the problem of if you need to update/edit the 'additional payment details' for whatever reason the older 'reversed' transactions now also point to these changed details (which insnt the details entered for that transaction) (not end of the world stuff either though)