Party Data Model

Main Entity

• Party Entity - a complex entity

Basic Table

• gParty table

Every Party Entity has one and only one gParty record associated with it.

A general and simplified graph of the Party Data Model

What type of information does the gParty table store?

The gParty table has general information about a Party Entity, like the Name, the Industry, the VATID etc.

Some of this information can be found in string or number fields in the table and other information can be found in dimension tables, directly related to the gParty table.

There is also other information about the Party Entity, stored in other tables, that is not directly related to the gParty table - more on this in the Sales and Purchases functional areas.

Dimension tables directly related to the gParty table

There are 2 types of dimension tables directly related (or connected) to the gParty table:

1. The [1,1] -> [0,n] related dimension tables

A paradigm for this type of relation is the gParty -> gIndustry relation (see the image above)

• Every gParty has one (and only one) relation to a gIndustry record.
• This relation is constructed by a link (or constraint) that is of type [1,1] -> [0,n] and uses the gParty.sIndustryFK and gIndustry.sIndustryPK fields as linking fields.
• In Relational theory terms, we could say that the gParty.sIndustryFK is a FK and the gIndustry.sIndustryPK is a PK in the above relation.

Just note here that in most Relational Model "notations" the PKs and the FKs have the same name - here it would be  gParty.sIndustryPK  instead of gParty.sIndustryFK. This type of naming is also used, by default, in the WX IDE.

To distinguish between PKs and FKs, we use different names for the PK and FK fields. 

2. The [0,n]-> [1,1] related dimension tables

A paradigm for this type of relation is the gParty -> gPartyAddress relation (see the image above)

• Every gParty can have many (or no) relations to a gPartyAddress record - in the end, this just means that a Party Entity can have many addresses (or no addresses).
• This relation is constructed by a link (or constraint) that is of type [0,n]->[1,1] and uses the gParty.sPartyPK and gPartyAddress.sPartyFK fields as linking fields.
• In Relational theory terms, we could say that the gPartyAddress.sPartyFK is a FK and the gParty.sPartyPK is a PK in the above relation.

List of tables related to the gParty table

• gIndustry - link [1,1] -> [0,n]
• gCountry- link [1,1] -> [0,n]
• gPartyBranch - link [0,n] -> [1,1]
• gPartyAddress - link [0,n] -> [1,1]

In addition to the above tables there are also the sCustomer, pSupplier, gPerson and hEmployee tables, discussed in the Customer, Supplier, Person and Employee entities sections.

The Customer Entity

The Party Entity by itself cannot be used in the Sales functional area - it is not a Customer Entity.

To use a Party Entity in Sales, the entity must have the Customer Role

This is done with a one to one relation between the gParty record and a sCustomer record - here the PK is the gPartyPK.sPartyPK field and the FK is the sCustomer.sPartyFK field.

To implement this type of relation in the Analysis:

• we use a [0,n]->[1,1] link between the gParty table and the sCustomer table, and
• we assign the sCustomer.sPartyFK as a PK of the sCustomer table - making it unique (see the image above).

All information needed for the Customer role is stored in the sCustomer table or tables related to the sCustomer table.

Note here that although the sCustomer.sPartyFK field, as implied by its name, is a FK (moved over from the gParty table), it is also the PK of the sCustomer table.

Beyond the Relational Model

The above relation is all that is needed for a Party Entity to become a Customer Entity - in a purely Relational world.

But in the Party Data Model, there are a couple of things that are not 100% relational ...

We have added a boolean field named bCustomer in the gParty table - the bCustomer is set to true if a Party is a Customer and this is controlled by BPs.

Although there is a lot of Business Processing needed to implement this boolean field, we think it is worth it since it speeds things up, especially queries.

List of tables related the the Customer Entity (or sCustomer table)

• sCustomerGroup - link [1,1] -> [0,n]
• sCustomerArea - link [1,1] -> [0,n]
• gPartyPosting - link [1,1] -> [0,n]
• gSalesTerm - link [1,1] -> [0,n]
• sCustomerPriceList- link [1,1] -> [0,n]

The most important relation is with the gPartyPosting table - this relation controls taxes and posting to GL

The Supplier Entity

The Party Entity by itself cannot be used in the Purchase functional area - it is not a Supplier Entity.

To use a Party Entity in Purchases, the entity must have the Supplier Role

This is done with a one to one relation between the gParty record and a pSupplier record - here the PK is the gPartyPK.sPartyPK field and the FK is the pSupplier.sPartyFK field.

To implement this type of relation in the Analysis:

• we use a [0,n]->[1,1] link between the gParty table and the pSupplier table, and
• we assign the pSupplier.sPartyFK as a PK of the pSupplier table - making it unique (see the image above).

All information needed for the Supplier role is stored in the pSupplier table or tables related to the pSupplier table.

Note here that although the pSupplier.sPartyFK field, as implied by its name, is a FK (moved over from the gParty table), it is also the PK of the pSupplier table.

Beyond the Relational Model

The above relation is all that is needed for a Party Entity to become a Supplier Entity - in a purely Relational world.

But in the Party Data Model, there are a couple of things that are not 100% pure relational ...

We have added a boolean field named bSupplier in the gParty table- the bSupplier is set to true if a Party is a Supplier and this is controlled by BPs.

Although there is a lot of Business Processing needed to implement this boolean field, we think it is worth it since it speeds things up, especially queries.

List of tables related the the Supplier Entity (or pSupplier table)

• pSupplierGroup - link [1,1] -> [0,n]
• gPartyPosting - link [1,1] -> [0,n]
• gSalesTerm - link [1,1] -> [0,n]

The most important relation is with the gPartyPosting table - this controls taxes and posting to GL

The Person Entity

The Party Entity is a Legal Entity by default.

To transform a Party Entity to a Person Entity you must assign it the Person Role

This is done with a one to one relation between the gParty record and a gPerson record - here the PK is the gPartyPK.sPartyPK field and the FK is the gPerson.sPartyFK field.

To implement this type of relation in the Analysis:

• we use a [0,n]->[1,1] link between the gParty table and the gPerson table, and
• we assign the gPerson.sPartyFK as a PK of the gPerson table - making it unique

All information needed for the Person role is stored in the gPerson table or tables related to the gPerson table.

Note here that although the gParty.sPartyFK field, as implied by its name, is a FK (moved over from the gParty table), it is also the PK of the gParty table.

The Employee Entity

This is used here for developers who want to extend the Data Models and implement HRM functionality.

Please note that it is NOT supported in the current version.