|
||||||||
|
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
Keith,
1) The relationship is currently a One to Many. When a new loan transaction is created from older reversed transactions (happens when a payment/adjustment is made before existing transactions), the new transaction would still point to the same payment detail as the original transaction did.
2) The table is meant to store payment specific details, the same would also be used for saving payment details for savings transactions
3) I had originally not though about the 3rd point, but when I read the comment and wanted to add the constraints, I am not entirely sure which of these fields need to be unique
Ex: I know check "number" would not be:
Ex: In almost all National banks in India, the issued check books which would have the series number on top of the checkbox and a sequence number for all the checks. The check sequence number would be unique only within the particular series.
Most data entry while receiving the check etc would only record the sequence number on a particular check which will duplicate across different series etc