Rietveld Code Review Tool
Help | Bug tracker | Discussion group | Source code | Sign in
(337)

Unified Diff: party_rollup_overview.rst

Issue 2001042: Tryton Blue Print for Structuring Parties
Patch Set: Added corrections from gsp and me Created 13 years, 7 months ago
Use n/p to move between diff chunks; N/P to move between comments. Please Sign in to add in-line comments.
Jump to:
View side-by-side diff with in-line comments
Download patch
« no previous file with comments | « no previous file | no next file » | no next file with comments »
Expand Comments ('e') | Collapse Comments ('c') | Show Comments Hide Comments ('s')
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:
|-----------------|-----------|--------|--------------|--------------------
« no previous file with comments | « no previous file | no next file » | no next file with comments »

Powered by Google App Engine
RSS Feeds Recent Issues | This issue
This is Rietveld f62528b