Shares ModuleContents ::
Some reading on MFIs that use Shares:
Shares Module Work In Progress is a page for developers working on this project to track project related information, design ideas and the ongoing work to implement this feature.
Last updated by: – vanmh - 25 Jan 2007 (Note: the specs below are based upon the Dec. 14th MSWord document.)
1.1 CREATING SHARES PRODUCT
A. CREATING SHARES PRODUCT
- User navigates to Admin page and clicks on "Define new shares product".
- System displays page with following fields: _ Face value: `[ ]` (per share) share _ Current price: `[ ]` (per share). Price is determined by organization and changes, at most once a year. * Minimum # of shares
- Question, is this minimum # of shares per purchase or minimum # of shares a member must own?
- FYI that shares are typically sold in fixed denominations (ie multiples of 500 shares.) (Questions: Is there only 1 denomination defined? Or can a single loan product have multiple denominations. But for V1, we probably don't need to control this through the system-can system user to enter correctly)
- Required fees (ie, passbook fee; processing fees): (Note that fee module should add a "Shares" parameter for the "Fee applicable to:" field. Share-specific fees can be charged at time of account opening, purchase of first shares, every purchase, selling fees, transfer fees? Need to define fee types.) (Note-this section should probably be broken apart to another user flow "defining share fees") _ Upfront fees: at time shares are first purchased _ Transfer fees _ Fees at each purchase _ Still TBD
- GL codes: _ share purchases, _ share redemption _ dividend payments. _ (Fees related to purchasing/transfer of shares will have their own GL codes, specified in the define-a-fee section)
- Dividends are actually paid out. If there are checks, send out checks. Pay out cash. Could
- Area general meeting. Reads accounts and pays dividends. People go to branch to get the dividend. Most individual members.
- User clicks "Preview" and system displays "Preview Page" that lists all user-entered data.
- User clicks "submit" and Share Product becomes active.
- OOS: _ Different share classes. MFIs typically keep it very simple and only have 1 class of shares. For now, multiple classes is OOS-but would be interesting to think through how this feature might be added later; _ Maximum limit of the # of shares that can be sold at one time (No known use case for this). _ Options to turn shares product on/off for clients, groups, individuals. For V1, can have same rules for any shares product (just need to define what those are) _ Marking a shares product as inactive.
- Questions * Do MFIs issue a certain number of shares for members to buy-ie, 1 million shares-and as shares are purchased, this number decrements? This is how it's supposed to work-but not sure how it does work at MFIs. If so, we'll need a mechanism in product definition to issue additional shares.
- Answer: For regulated Indian MFIs, they have a certain amount of authorized capital/share capital. Based on what they decide will be the face value of the shares, the authorized capital limit automatically imposes a limit on the number of shares. E.g. if authorized capital is $1 million and each share has face value of $10, then max number of shares that can be issued is $1million/$10 = 100,000. However, institutions can request the central bank to extend their limits for authorized capital so in some sense, in the long term, their ability to issue shares is somewhat unlimited. Given this, I don't think we need to have an ability, in the first release of the shares module, to stop selling shares at any particular point. The MFI can simply track this themselves by generating reports to ensure they're not crossing a particular threshold.
- Should system allow user to define multiple share products? * Answer: no-single product across the organization. (The answer to this question will impact how we handle/implement shares-ie, creating shares accounts or not)
- Question: If shares can only be purchased in multiples of 500 shares, can they only be sold in the same multiples? Are there restrictions for selling shares if you have open loan accounts? Can all of these validations and restrictions be punted until a later time.
- Do we know what the expected range of number of certificates per MFI would be? * Answer: It really depends on the size of the MFI. MFIs can certainly have 1 million customers and assuming they own 10 shares each (a reasonable number)-- you get 10 million. From what we can tell, the largest of our target MFI customers will just begin to be reaching 1 million clients in 5 years...
- Do MFIs use pre-printed share certificates that include share numbers already on them-- or should mifos generate the share numbers itself? If Mifos generates the numbers-- do we need to specify a "Starting number" for the shares (ie, to account for shares already distributed before Mifos was implemented at the MFI). Possible answer: share certificate numbers should be user-entered (note: this conflicts with system generated preference given in section F-- need to resolve). We can always add the ability to automatically generate share numbers later.
B. ALTERNATE FLOW: EDIT PRODUCT DEFINITION
- System user can edit the following fields: _ Price per share _ Minimum shares required * Fees
- Preview & confirmation page should be displayed
- System should capture all changes made to product definition in the change log, viewable off the product details page.
- All changes made to share product should affect future accounts/transactions. If we allow past-dated share transactions, then that transaction should take prod definition values as per the time of transaction. (Still tbd if we allow past-dated transactions)
- OOS * Ability to schedule a change in share price for a date in future.
C. ALTERNATE FLOW: CLOSING SHARES PRODUCT
- OOS: Ability to close a shares product offering. This is an extremely rare scenario, so don't need to handle in the first version of this feature.
DISTRIBUTING DIVIDENDS
- User has ability, through Admin page (or Share Product Page), to "define and distribute dividends". User flow is: _ User enters in amount of dividend per share, clicks "preview" _ System displays preview page that displays dividend amount per share and total amount of dividends to be distributed based on total outstanding shares. User clicks submit. (Note, an alternative approach is for user to enter the amount of dividends to be disbursed, and the system calculates the amount per share, rounding down. But this can easily happen offline) _ Confirmation is displayed. _ Immediately upon submission, liabilities are credited. Debits to liabilities are made when payment to individual is actually disbursed. _ Dividends are disbursed only to those shares that one owns at the moment. There are no partial dividends distributed for shares redeemed midway through the year-or dividends disbursed partially to the previous owner and partially to the new owner. _ Dividend page should display date of dividend disbursal, dividend per share and total dividend disbursed.
- On Share Product Page (or somewhere else?) a history of dividend distributions are recorded: _ Date disbursed. _ Username of who disbursed dividends _ Amount per share disbursed _ Total amount disbursed. * Do we also need GL transactions for this disbursal?
- QUESTION: _ Do we need the ability to "undo" dividend distribution in case there was an error? What if some dividends have already been paid off? Can this be OOS for V1? _ When a dividend is distributed, where should we record and display that an account has an unpaid dividend balance? Should a dividend balance be tracked separately from other account balances?
E. ALTERNATE FLOW: VIEWING SHARE PRODUCT DETAILS
- System displays all share product info
- Link to "Edit Shares Product"
- Link to "View change log"
- History of Dividends Disbursed (with link to disburse dividends)
- Question: * I'm assuming it's OK to capture the history of the share price change in the "View Change Log".
1.2 SHARES ACCOUNTS
There is an open issue whether/not shares would simply be bought/sold through the client's account-or if we should create a separate "Shares" account created to manage the shares. In some ways, this is a technical decision (ie, what will be easier/harder to implement). But from a user perspective-since there are really no account states required (ie, if shares exist, account is active)-it seems best simply to allow any active user to be able to purchase/redeem shares-without creating the unnecessary step of creating a shares account. Instead, would be great if we could just facilitate the purchase/redemption/transfer of shares through the member's acct.
If we do decide to use share accounts, here are some initial specifications...
Creating Shares Account
- Share accounts can exist without any shares balance (similar to savings account).
- User creates shares account for a client (although system could automatically create a shares account if necessary). No additional No additional information is required for shares purchase beyond what is already captured in client record. (Is there a "beneficiary" defined in case of death? I'm assuming not)
- Account is immediately "Active" (like a center account)
- User records shares purchase for client (no need to have shares acct automatically open with a balance).? Or does a shares purchase immediately open a shares account, and there's no state flow beyond that?
- Account states: Open/closed. In general, MFIs that use shares typically require all members to own shares. So account would only close when client leaves MFI. Either is fine although in practice a shares account is simply the member account, and purchase of shares means your name appears in the shares register and you get a receipt _ By definition, only members of the MFI own shares in the MFI. Non-members can't own shares. _ OOS:
- Automatic creation of share account upon creation of client
- Automatic purchase of shares upon creation of client
Movement of Account through state flow diagram
- Share account can be either active/closed. No partial application, pending approval, cancelled state is necessary. Is abandoned state necessary? Probably not. We might have "dormant" status which is reactivated when user buys shares.
Closing Shares Account
- Similar to the "close savings account" pipeline, we could have a "Close Shares Account" feature-- that prompts a user to sell any shares that are still open. However, this raises issues-if members must have shares to be active-then you shouldn't be able to close a share account for an active client. Selling of shares should be integrated into the closing-client pipeline, which greatly increases complexity.
Shares Account Detail Page
Need to define what a shares account page looks like and what info should be displayed.
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
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>`_