: Public Note
Created: |
08/01/2011 18:07:38 |
Modified: |
08/01/2011 18:12:01 |
|
Project: |
|
Author: |
T. Kostic |
Version: |
1.0 |
Phase: |
1.0 |
Status: |
Proposed |
Complexity: |
Easy |
Difficulty: |
|
Priority: |
|
Multiplicity: |
|
Advanced: |
|
UUID: |
{399CDABC-367C-47fd-842B-6829C92DC122} |
Appears In: |
14-ElectronicAddress, ErpPerson |
[tk, 2011-01-09]<br/><ul>
<li><font color="#ff0000">[c-031] IEC61968::Common::ElectronicAddress is now a #lt;#lt;Compound#gt;#gt; and associations have all been replaced with attributes. Document, Organisation, Asset, Location, Cashier (all NORM) and ErpPerson (still INF class) have all an attribute electronicAddress. One <b><i>cannot</i></b> inherit from a compound, so: Add to ErpPerson another electronicAddress attribute (to have the ability for primary and alternate). We did similar e.g. for Organisation with phone1 and phone2 attributes. Then you can remove Mkt_ElectronicAddress and the enum EmailAddressType. - </font><font color="#008040"><b>COMPLETED</b></font></li><li><font color="#ff0000">ErpPerson: WG14 planned to rename the class to Person and make it NORM in IEC61968::Common package (we'll need it heavilly for Work and also for PaymentMetering). - </font><font color="#008040"><b>Created MktPerson</b></font></li><li><font color="#ff0000">Add the attribute 'userID' to ErpPerson as it is a useful thing in general. You can then remove the shadow class Mkt_ErpPerson, as it has no own associations. WG16 and WG14 together have to see WG16 requirements for ErpPerson's associations and attributes - we want to keep as normative only what is really used by profiles (that's the rule). - </font><font color="#008040"><b>Created MktPerson (for now)</b></font></li><li>TODO: Association classes.</li></ul>
<br/><br/>