Re: [Rails-devel] Shares and certificates (was: Further 1835 testing)

[Erik V. <eri...@xs...>]

The below observation by Martin is also pertinent to our discussion:

> From: Dr....@t-... [mailto:Dr....@t-...] 
> keep in mind that there are games lurking in the wood that have higher denominations and not even a fixed one for the portfolio at start.
> And yes of course prime example: 1880 -> The president share might be a 20, 30 or 40 percent share and thus subsequently the number of shares per company might not be known until the corporation has started.

In 1880 there is no dispute what a share is: 10%.

However, for me the interesting aspect of this observation is, that in 1880 we do not know beforehand how many certificates we have, and what number of shares at least one certificate represents.   The 1856 situation is very similar, but in this case the undefinedness applies to all CGR certificates.

In 1856 this is solved by initializing the CGR with 19 certs: 1 of 10% and 18 of 5%.  Should the CGR need only 10 shares, then Rails throws away ten 5% certificates, and doubles the share unit value of the company, which automatically converts the remaining nine certificates from 10% to 20% and from 5% to 10%, without need to affect the number of share units each cert represents.

In 1880 I would solve this by initializing with one 20% and eight 10% certificates.  Should the company start with a 30% or 40% president certificate, then the number of share units of that cert will be raised from 2 to 3 or 4, and one or two 10% certs will be discarded.

> From: Stefan Frey [mailto:ste...@we...]
> * I disagree the concept of "share" should be objects in Rails. I prefer the
> nominal (percentage) being an attribute of the certificates.

I'm with Stefan in this matter.

> So my suggestion (derived from all input from the current discussion) is:
> 
> A) Use one class that represents share certificates types. Use another class
> that represent concrete share certificates (similar to trains and train types,
> and this would be required for your proposal as well).
> 
> B) Share certificate types have an attribute called nominal_percentage (or
> nominal percentage) which defines what their contribution to the total
> capital stock is and another boolean attribute which defines president or not.
> 
> C) Each company defines an attribute called quotation_percentage which
> defines the percentage of stock ownership the stock market price
> corresponds to. The selling and purchase price for each certificate then
> equals (nominal_percentage / quotation_percentage) * stock_price.

What we currently have is:

CC) Companies have two attributes relevant to this discussion:
- The "share unit", which is the size of its smallest share (which can vary from 5% to 100%),
- the "share price unit", which is the number of share units that the share price applies to.  Always 1, except for the PR.

DD) Each cert has an attribute named "shares" that represents the number of share units represented by that certificate. In the light of the previous discussion it has become clear, that we should rename this attribute to "number of share units". (Of course there is also a "president" boolean).

A main difference with Stefan's proposal is the current existence of an additional "share unit" company attribute, which is the base percentage in which all share amounts are expressed.  I think I introduced this attribute with 1856 to facilitate the share conversion that may occur during the CGR formation (see above).  My strong preference is to retain this structure.

Do we really need certificate types as in B)?  I don't see a big need for such an additional type (whereby I realize that as yet we are not prepared for the "lunatic designer" syndrome that Stefan envisions).  But I'm not firmly against either. In any case, if we introduce such a concept, we must have a strategy for handling the 1880 and 1856 cases.  In these games we must be prepared to either:
- define all possible cert types beforehand, and change the cert type of some or all certificates of a company, as needed, or
- change the parameters of some cert types, as needed. 
In particular for 1880 the question then arises if cert types will be defined per company, or just once for all companies.

Also keep in mind that in Rails every persistent attribute that can change value must be a state variable.  Currently, shareUnit is an IntegerState, on behalf of 1856.  In hindsight, I could have chosen to leave it an integer, but to replace that in PublicCompany_CGR by an IntegerState, forcing all access to either to use a method.  I would suggest to use the latter approach in 1880, by overriding the integer "shares" (or rather "numberOfShareUnits") by an IntegerState in a specific class PublicCertificate_1880.  

Erik.