Design ideas for a shares product class

There is an existing PrdOfferingBO from which LoanOfferingBO and SavingsOfferingBO are derived. PrdOfferingBO includes basic information like an ID, name, description, status and start(creation) date. It does include some extra information (like category) than is not currently needed to support the shares product (since there will only be one shares product initially).

PrdOfferingBO seems like a good candidate to use as the base class for the shares product class.

If we did use PrdOfferingBO as the base class then it would allow for an easier introduction of multiple shares products down the line and fit with the existing product definition scheme. If we use the PrdOfferingBO, then some refactoring would be required to move those fields only needed by Savings and Loan products to a new class derived from PrdOfferingBO, leaving only what is needed for the shares product in PrdOfferingBO. The PrdOfferringBO base class uses the hibernate mapping file PrdOfferingBO.hbm.xml and maps to the existing table PRD_OFFERING.

Here is a sketch of what the Shares product class might look like (using the existing classes: Money, AmountFeeBO, GLCodeEntity):

Public class SharesProductBO extends PrdOfferingBO {
   private Money faceValue;
   private Money currentPrice;
   private int minimumShares;  
   private Set<AmountFeeBO>  fees;
   private GLCodeEntity purchaseGLCode;   
   private GLCodeEntity redemptionGLCode;   
   private GLCodeEntity dividendGLCode;
}

The definition above would need a mechanism added for handling dividends. It also does not include the tracking of the price history as suggested by Carlo. Both dividends and price history could be added after an initial iteration implemented the above.

In terms of database mapping, the Money class maps into two fields, an amount and a currency id, GLCodeEntity instances have their own table (GL_CODE, see GLCodeEntity.hbm.xml for details) and fee associations are captured in the PRD_OFFERING_FEES table. So the final shares product table would look something like:

SHARES_PRODUCT

Face_value_amount
Face_value_currency_id
Current_price_amount
Current_price_currency_id
Minimum_shares
Purchase_gl_code_id
Redemption_gl_code_id
Dividend_gl_code_id

Since the SHARES_PRODUCT table would keep track of the different kinds of shares product the MFI has to offer, we also need a table to keep track of the actual certificates issued given a shares product:

SHARE_REGISTRY
Certificate_Number
Product_id
Share_class
Date_issued
Customer_id

The certificate_number is the unique identifier for this table. product_id is a foreign key into the SHARES_PRODUCT table.

To keep track price history of a share, we have

SHARE_PRICE_HISTORY
Product_id
Price
Date

To keep track of the trades of these shares:

TRADE_HISTORY
trade_id
transaction_date
buy_sell_transfer
previous_holder_customer_id
current_holder_customer_id
price_per_share
number_of_shares
nominal_value_per_share
transaction_fee
fee_type
currency

The previous_holder_customer_id and current_holder_customer_id must both be valid customer_id's from the CUSTOMER table.

(Question: Is there a currency field somewhere in some other database?)

Finally, the SHARES_TRADED_HISTORY keeps track of which shares certificates are associated with which trades:

SHARES_TRADED_HISTORY
trade_id
certificate_number
trade_date

There is a one to many relationship between the TRADE_HISTORY and the SHARES_TRADED_HISTORY table since one trade can involve many trade certificates.

I will attach a diagram of these new tables.