...
1.3 TRANSACTION TYPES
F. PURCHASING SHARES
- Overview _ Shares are always/only purchased by members of the MFI. External individuals, parties, etc, do not purchase shares so we don't need the capability for non-clients to purchase shares. By definition, if you own a share in the MFI, you are the member of the MFI. (This is certainly true in the case of Saccos in Africa. Need to validate for other MFIs). Note that there is a difference between a member and borrower-- a member may or may not have an active loan with the MFI. _ 99% of shares are owned by individuals. For V1, is it OK to limit shares to individuals? Do we need to include support for groups/centers to purchase shares? No need to give configuration controls to limit this in UI in V1. IMO, best to first build for individuals-then add functionality into groups/centers later.
- User navigates to client's account page. (This user flow assumes we wont have a separate shares account)
- User clicks "purchase shares" from client's account page.
- System displays purchase screen:
- System-displayed: Current price per share. This price is defined organization-wide and can not be edited by system user.
- User-entered: Number of shares to be purchased (in V1, even though shares are only sold in multiples, this can simply be the number of shares to be purchased-LO or teller will know MFIs rules for multiples so doesn't need to be system enforced) * Applicable fees as defined in product definition.
- Fees should not be editable
- Fees should not be able to be removed (unlike loan account creation pipeline)
- System-displayed: Total amount to be paid = (`# of shares * price per share`) + fees (Question: do we need to do this on the input screen-or can this simply be displayed on the preview page?)
- Question: Do we need a user-enter field to capture share certificate numbers-since MFIs rarely actually have certificates? Instead, should certificate numbers be system generated. Assuming they should be system generated.
- Purchase date
- Receipt #
- Mode of Payment
- User clicks "Preview" _ System checks to make sure that # matches "minimum # of shares" _ System displays user-entered data _ System displays total price of shares _ System displays total fees * System displays total amount to be collected
- User clicks "Submit" and system records: _ Member number & Name & address. This info must bee kept for at least 10 years in Kenya. _ Group member number (if group member) _ Purchase Date _ Price per share _ Number & value of shares purchased _ Total fee amount collected _ Total amount of $$ collected _ Nominal Value of the Shares (Note, this doesn't change over time, so not sure if we need to capture) _ Share #s. Share numbers should be unique between shares, and sequential. On detail pages, etc, no need to display all the share numbers, just the share # range. Ie 1 - 500; 1501 - 2000, etc. _ System generates appropriate GL transactions against the client account.
- System displays confirmation screen: _ Member name & acct _ Purchase date _ Number & value of shares purchased _ Total fee amount collected * Total amount of $$ collected
- Certificates _ Certificate numbers will be numeric _ Questions
- Can one certificate represent multiple shares?
- Is there a maximum number of shares a certificate can represent?
- Questions * Are there specific audit requirements that should be taken into account? For example, if the name and address of a member at the time of purchase must be preserved, but a members address can be edited, then would we need to record a copy of the address with each transaction so as not to loose that data?
G. REDEEMING SHARES
- Redemption of shares happens with a member leaves the MFI and sells back her shares to the MFI. (Can redemption of shares happen at other times as well?)
- User navigates to client's account page
- User clicks on "Redeem Shares"
- System displays page with following fields: _ System-displayed, non-editable (inherited from product definition) Value of each share _ # of shares to be sold-- User Entered
- There may be limitations with this, including if you are using shares to guarantee a loan or if there are minimum number of shares required to be a member. Still TBD.
- Transaction date (will we allow post-dated transactions?)
- Method of payment (cash, check, etc)
- Voucher number & date
- Any fees associated with redeeming shares
- User clicks on "Preview": _ System displays all the info entered above on the preview page _ total value of shares sold _ Total fees due _ Total amount to be paid (value of shares - fees).
- System record the following: _ GL transactions for share redemptions & fee payment _ Question: Does "balance of MFI's shares available for sale" get increased?
- Client account page displays: _ Transaction for Fee payment _ Transaction for Shares Sale * Updated shares balance
H. TRANSFERING SHARES
- Because shares are transferred between members, there are no GL transactions that occur-apart from the payment of any transfer fees. It doesn't matter to the MFI and it doesn't need to get tracked by the MFI.
- User navigates to client's account page. Clicks on "Transfer Shares"
- System displays page with following fields: _ User-entered field # of shares to transfer _ User-entered field: System ID of member to transfer shares _ User-entered field: Date of transfer (default to today's date): Note-any limitations with this field? Do we need to handle back-dated transfers? Or should we restrict date of transfer to date recorded in system (assuming the later). _ Receipt ID/Date * System-displayed: Transfer fees to be applied
- User clicks "Preview" and system displays following information: _ Name, group/center membership, and LO for recipient of shares _ # of shares transferred & value of shares _ # of shares remaining in account & value of shares _ Fees to be collected * Receipt ID/Date
- User clicks "Submit" and system displays the same info as above
- System records: _ Transfer transaction # (if no GL transactions are created, I'm assuming we don't have a transaction #-- but we do have a client transaction #, right?) _ Date of transfer
- If we build this feature incrementally, this functionality can be built later. However, it is still required for the initial release.
PAYOUT OF DIVIDENDS
Most of this is still TBD.
- Once a dividend is disbursed across the organization, a dividend balance displays in the client's account. Need to determine if this balance is separate from client fee balance (assuming it is). Also need to determine if, in the case where clients have savings accounts, the dividend can be paid out to the savings account. However for the first release, we probably shouldn't try to handle this scenario as there are numerous edge cases (what happens if savings accts aren't present, etc, etc).
- Account should display date of dividend disbursement, amount of disbursement, etc.
- Dividends are paid out to share owner at time of dividend disbursement. If client A owns a share from Jan - Oct and then transfers it to client B and dividends are paid out at December-the full dividend payment is made to client B. _ User navigates to client account and clicks "Dividend Pay-out" (or something like that). System displays: _ System-displayed, non-editable: Balance of amount to be paid (no partial pay-out is supported.) _ User-selected: Mode of payment (Cash, check) _ User-entered: Payment date (defaults to today's date). * Receipt #
- User clicks preview and system displays preview page with date above displayed.
- User clicks on "submit". System records the following: * Appropriate GL transactions.
- Detail page displays * Date of dividend payment, amount of payment, etc. (Note-I'm assuming there has to be a difference between issuing a dividend and the actual payout of the dividend-since these transactions will almost always happen on different days)
- Questions: _ What happens if a client doesn't collect their dividend? How is this handled? Are there "write-offs" required? I don't know, but will find out. _ Do we want to support past-dated dividend payouts? Assuming no for V1.
- OOS: _ Integration of dividend payment into collection sheet and bulk-entry screens. Potentially we can develop, later, a separate bulk-payment screen for dividends. In the Kenyan MFI, client comes to branch office to collect dividend. _ Ability to "waive" or "cancel" a dividend payment that has been issued but not yet paid. * "Reversals/adjustments" for dividend payments (we will need that at a later time, though)
1.4 SYSTEM VALIDATIONS
Still TBD, but might include: _ Value of shares owned is X amount of loans disbursed at time of loan disbursement, share transfer, share redemption _ Each member requires X number/amount of shares
1.5 CONFIGURATION REQUIREMENTS
Still TBD, but will likely include
- Shares module on/off (if "off", all shares features are hidden)
- Supported payment types of share purchases, dividend payment, and share redemption.
1.6 REPORTING REQUIREMENTS
Still TBD
1.7 OPEN ISSUES
- What happens to shares in case of client death?
- Do we need to handle rules based on share ownership? * For example: Many MFIs require that members own a certain # or value of shares in relationship to their loan size-- for example, the maximum loan size a member can receive is 5x value of their shares. They use that as a type of collateral. Continuing with this example, after a borrower has paid off their loan, they can take another loan at a maximum of 5x value of their shares. If they want to receive a larger loan, they must purchase more shares.
- Can a share certificate always correspond to multiple shares? Or is there a one-to-one relationship (ie, for every share granted, a unique share certificate is given). If a share certificate can represent multiple shares, is there a maximum limit of shares a certificate can represent?
1.8 OOS
- Share certificates & printing of certificates. Tracking fact that a share certificate can only be printed one-time, etc.
1.9 USER INTERFACE MOCKUPS
- `Current screen mockups zip file <https://mifos.dev.java.net/source/browse/_checkout_/mifos/documents/ui-workspace/Mifos_08_Jan_2007.zip?rev=11459>`_
To view the mockups, unzip the file, double click on any file in the folder, make sure to accept "blocked content" if your browser prompts you, click on "admin" tab and look for the shares section.
`Click here for MSWord specifications as of Dec 14th, 2006 (The wiki page specs above are now the most recent) <https://mifos.dev.java.net/files/documents/5045/45790/file_45790.dat?filename=Shares%20Product%20Features%20%2d%20%31%34%20Dec%20%30%36%2edoc>`_