Table of Contents

Parties

Explanation of Key Concepts

There are different types of parties in DOKA.

Normal parties/ Basis parties These have a PTSPTA instance with a role code as their instance name in the contract group (e.g. APL, ISS)
Dynamic contract parties These have a PTSPTA instance with a role code as their instance name in the contract group, and there is also a role field that contains the role code for the basis party (e.g. PRB with DOCPRBROL).
If filled, these are either in-house independent parties, or fields have been filled from another contract/basis party.
Transient/temporary parties These have a PTSPTA instance with a role code as their instance name, typically in a panel module or in another position outside the contract group (e.g. as recipient of a message in xxxFRE transactions).
These are only used in one single transaction.
The only difference between these and dynamic parties is that transient parties are not stored in a contract group.


Handling Parties

When is the data changing a basis party to a dynamic party transferred? When a contract is loaded, dynamic parties linked through role fields are reset each time, or when the content of role fields are changed.
When and how are address details amended for a dynamic party transferred to the basis party? Whenever data changes are confirmed for a dynamic party (clicking Save in the amendment panel) details for the respective basis party are also changed.
What happens to reference numbers for dynamic and transient parties? Party reference numbers are normal party data and do not need to be handled in any special way.
How are the role codes for the various parties assigned/applied? Role codes have to be unique for all parties (thus also for transient parties). Therefore, a transient party cannot have the same role code as an existing role code in the contract group.
What happens when basis party and dynamic party role codes are changed? They need to be initialized, updated and reloaded each time.


Dynamic Parties

This section describes the handling of dynamic roles (PRB/ PYR/ PRP) that can be filled dynamically from a basis party using the role fields (DocPrbRol/ PayRol/ DocPrbRolBe1).

There are various positions in DOKA where parties need to be copied dynamically from another role, or where an address needs to be capture that is not yet used in a contract. Such an example is the presenter of documents (PRB). The standards for these parties are described below:

These parties are made up of an PTSPTA, which is normally stored in the contract, and a separate role field (e.g. DOCPRBROL) that is also stored in the contract.

These parties are not stored in the contract if they are only used one single time, i.e. as the recipient of a message in FREMSG and on the DOCEOT panel; such parties are refered to as transient parties (see above).

Unique instance name:
If an instance name already exists in a contract group (such as in BEDGRP, for instance), a new party in a panel module (such as in BETP, FREMSG, for instance) can NEVER have the same instance name, and vice versa.

Role codes in the role field:
'FRE' (Free Entry/Freie Eingabe) should be used as the role code from the ROLALL table for the relevant 'Other parties' in the role field.

Role field:

Initializing the dynamic party:
Whenever the system loads a contract, initially the dynamic party always has to be loaded from the basis party, if the former corresponds to the latter. This ensures that both parties are synchronized . This also applies for reference numbers.

Amendments involving a dynamic party

Amending a field relating to a dynamic party:
If a field (e.g. REF, EXTACT) for a dynamic party is changed in the transaction, and if the role field refers to a basis party, the change has to be immediately transferred to this basis party and also saved there when the transaction is saved in order to ensure that the content of these two roles remain identical once the transaction has been saved.

Amending the dynamic party (via the role field):
If a new basis party is selected in the role field,

Reference (PTS\REF) - special features:
Because the field for the reference is also available as a field for itelf on the main panel (Overview) and not just on the Details panel for the party, data has to be transferred to the basis party whenever the user leaves the reference number field and not only when the user clicks [Apply] on the Details panel.