Index: party_rollup_overview.rst |
=================================================================== |
--- a/party_rollup_overview.rst |
+++ b/party_rollup_overview.rst |
@@ -1,182 +1,184 @@ |
-Author Udo Spallek (virtual things) |
+Author Udo Spallek (virtual things), gsp |
Structuring Parties |
################### |
This document tries to show a bigger picture of structuring parties. |
-Tryton uses a singular container for all party entities of the |
+The party model is a single 'container' for all party entities of the |
whole enterprise environment. So it could be useful to begin to |
differentiate parties in many ways. |
Party Types |
-+++++++++++ |
+=========== |
Module name: party_type |
-This conception introduces a general party type attribute to |
+This concept introduces a general party type attribute to |
Tryton parties. The two main party types are: |
* Person |
* Organization |
A party must be determined as one of these exclusive types. |
-Each party type can restrict some individual attributes to persons or |
-organizations. Parties with type person are endued with some |
+New attributes may be added, but restricted to certain party types, in |
+order to differentiate between and adequately represent Persons and |
+Organizations. Parties with type Person for instance are endued with some |
detailing attributes for refined searches or greetings in documents. |
Additional fields for parties with type 'Person' are: |
* First-Name |
* Gender |
The provided model should be easily extensible to other general types |
e.g. sub-typing organizations into 'Legal Organization' (e.g. company, |
agency, financial institution aka bank...) or 'Informal Organization' |
-(e.g. household, family, user group...) |
+(e.g. household, family, user group...). |
-In the later use in this document the term 'organization' stands as an |
-abbreviation for 'a party typed as organization'. The term 'person' stands |
-as an abbreviation for 'a party typed as person' |
+For the remainder of this document the term 'Organization' stands as an |
+abbreviation for 'a party with party type organization'. The term 'Person' stands |
+as an abbreviation for 'a party with party type person'. |
Caveat |
====== |
-The party type conception should not be confused with a conception |
+The party type concept should not be confused with a concept |
of party roles. Party roles are for example Customer, Partner, Supplier, |
Salesmen, Employee, Internal Company, Father, Mother, Competitor... |
Differences between party role and a party type: |
- * Party types are not depending on time |
+ * Party types do not depend on time |
* Party roles may change over time |
* A party must have one and only one type |
- * A party can have many party roles, or not. |
+ * A party can have many party roles, or none at all. |
-Party roles will not discussed further in this conception, but later in another |
-document. |
+Party roles will not be discussed any further in this blueprint, but later |
+in another document. |
Roll-up Parties |
gsps
2010/08/19 20:19:57
Proposal:
Rename 'roll-up parties' to 'complex' or
udono
2010/08/19 20:36:47
Done.
yangoon1
2010/08/19 20:39:12
Roll-up in this context means the tree structure o
gsps
2010/08/19 21:19:39
Fair enough; are there any dictionaries or glossar
|
-+++++++++++++++ |
+=============== |
-Structural relationships between parties can be build-up in many ways. |
+Structural relationships between parties can be built up in many ways. |
-This conception has the goal to create the functionalities and views for |
-generic structural relationships between parties. |
-The target question is: How to build parties which are composed of other |
-parties. This 'composition' of parties is named 'roll-up' in the |
+The motivation behind this concept is to create generic structures |
+among or within parties. Such is functionality depending on the relationship |
+between two parties to represent their structuring. |
+The target question therefore is: How do we build parties which are composed |
+of other parties? This 'composition' of parties is named 'roll-up' in the |
further document. |
-Claim is to provide functionality which is directly useful for |
-the existing business related modules and not to break the functionality |
-of these modules. |
+The idea is providing functionality which is directly useful for the existing |
+Tryton modules and not breaking those modules thereby. |
-Restriction by design for the later explained models are at first, that a |
-person is a prime entity atom like. A person can not be rolled-up by another |
-entity. (Be patient, in the next coming Frankenstein-mode of Tryton, you can |
-do this and other wired stuff). On the other Hand, persons could be involved |
-in one or more organization. |
+One of the restrictions that are imposed by design consists in Persons being |
+atomic entities, that cannot be rolled-up by another entity of the same type. |
-A generic roll-up of parties should use a neutral semantic. Which means the |
-roll-up of parties should usable for 'headquarters', 'departments', |
-'subsidiaries', 'families', 'use groups', 'chat members' or |
-other named organizational units. |
+A generic roll-up of parties should use a neutral semantic. That means the |
+roll-up of parties should be usable for 'headquarters', 'departments', |
+'subsidiaries', 'families', 'user groups', 'chat channels' or other named |
+organizational units. |
Caveat |
====== |
-The roll-up of parties should not be confused with a generic relationship |
-conception, which should be able to relate any party of any party type in a |
+The roll-up of parties should not be confused with the concept of generic |
+relationships, which would be able to relate any party of any party type in a |
network like structure. |
-Generic party relationships will not discussed further in this conception, but |
-later in another document. |
+Generic party relationships will not be discussed any further in this |
+conception, but later in another document. |
Roll-up Organizations |
===================== |
Module name: party_rollup_organization |
-In this conception only organizations and their roll-up of other |
-organizations are concerned, but not Persons. Organizations can be build-up |
-by other Organizations. The process building up a organization structure is |
-called 'organization roll-up'. |
+The concept of 'roll-up Organizations' suggests that Organizations |
+can be composed of other Organizations. This kind of grouping therefore |
+excludes Persons. The process building up an Organization structure like that |
+is called 'Organization roll-up'. |
The roll-up pattern introduced here is the strict hierarchical structuring |
-of organizations. |
+of Organizations. |
-This is a design decision, since organizations also can be structured |
-in a network or rolled-up otherwise. Anyway, the network pattern is not |
-helpful for direct business use. Because the path from a subsident |
-organization to its headquarter organization is not unique, since each |
-organization can have many parents in a network structure. |
+Again, this is a design decision, since Organizations also could theoretically |
+be structured in a network or rolled-up otherwise. However, the network pattern |
+is not helpful for direct business use, as the path from a subsident |
+organization to its headquarter organization might not be unique. The reason |
+being, that each organization can have many parents when using a network |
+structure. The business case used here is to always provide a unique path |
+from a subsident organization to its headquarter organization. |
-Organizations are ordered in a hierarchical tree structure, more exact, |
-they are ordered in a directed graph. Each organization can have one and |
-only one parent organization. Each organization can have one or more children |
-organizations. |
+Organizations are ordered in a hierarchical tree structure, or to be more |
+exacting, they are laid out in an acyclic, directed graph with a single root |
+node (that is, the heardquarter organization). Each Organization can have one |
+and only one parent Organization. Each Organization can have one or more |
+child Organizations. |
-In this structure, the diving through the branches and leafs of a organization |
-tree generates always a unique path to a certain organization. |
-The big benefit is, that a certain organization is every time unequivocal |
-Its path to the root organization or to the children organizations can easily |
-be evaluated in later modules (Read at the caveat section about the |
-'price to pay' for this benefit). This can be used later e.g. for restricting |
+In this structure, one can always find an unique path from any of the nodes |
+(Organizations) to any of the other node, satisfying our requirement of a |
+'network pattern helpful for direct business use'. |
+The big benefit of this is, that dependencies and routes between various |
+Organizations can unequivocally be determined by modules that might process |
+this information for further applications (Read the caveat section about the |
+drawback that comes with it). For instance it could be used to restrict |
the selection of parties to parties which are in the same or in a different |
-path (organization roll-up) of a given party. |
+path (Organization roll-up) of a given party. |
-This conception is directly usable in enterprise relevant aspects of a B2B |
+This concept is directly applicable to enterprise relevant aspects of a B2B |
market. And it does not interfere with a B2C market of the same enterprise, |
-since persons are not related to this model. |
+since Persons are not related to this model. |
Caveat |
------ |
-Organizations which take part to more than one organization roll-up, |
-needed to be created as a unrelated duplicate. This lag must be solved in |
+Organizations which take part in more than one Organization roll-up, |
+need to be created as an unrelated duplicate. This lag must be solved in |
another module, maybe party_relationship explained in short above. |
gsps
2010/08/19 20:19:57
I disagree. We could easily avoid this by not crea
udono
2010/08/19 20:36:47
As I said, it is a design decision and not a limit
yangoon1
2010/08/19 20:39:12
Good point, agreed.
udono
2010/08/19 21:11:31
Here we need an abstract vector with the organizat
gsps
2010/08/19 21:19:39
I was in fact talking about a tree structure as we
|
Roll-up Persons |
=============== |
Module: party_rollup_person |
-An organization is usually a grouping structure, which is finally made |
-up of persons. One organization can involve none ore more persons. A |
-singular person is involved in none or more organizations. This is the |
-reason why the roll-up of organizations and persons is divided in two |
-parts. Think of a salesmen or agent who works for different companies. |
+An organization usually is a grouping structure, which is ultimately made |
+up of persons. One Organization can involve none or more Persons. A single |
+Person can be involved in an arbitrary number of Organizations. This is the |
+reason why the roll-up of Organizations and Persons is divided in two |
+parts. Think of a salesman or an agent who works for multiple companies. |
-A person can be addressed indirect as a member of one or another |
-organization (B2B market). And a person can be addressed directly, without an |
-organization included (B2C market). |
+A Person can be addressed indirectly as a member of one or another |
+Organization. And a Person can be addressed directly, without an |
+Organization included. |
Caveat |
------ |
-The path to a person is not unique, since a person can be member of many |
-organizations and additionally accessed directly. To unique reference |
-a person in an organization roll-up a vector is needed, with the |
-dimensions: person(.id), organization(.id). |
-Referencing a person directly always mean referencing the person party |
-not embedded in an organizational structure. |
+The path to a Person is not unique, since a Person can be member of many |
+Organizations and even accessed directly. To uniquely refer to a Person in |
+an Organization roll-up a vector with the dimensions 'person(.id)' and |
+'organization(.id)' is needed. |
+Referencing a Person directly always means refering to the Person party |
+in the context of none or more organizations. |
Examples |
-++++++++ |
+======== |
The following examples make use of ASCII arts, so be sure to have a mono spaced |
-font enabled. Included Modules: |
+font enabled. Included modules: |
* party_type |
* party_rollup_organization |
* party_rollup_person |
Standard Party List: |
|-----------------|-----------|--------|--------------|-------------------- |