Creating and managing company accounts
The interactive management of Companies/Clients is based by default on a combined view (listDetailsWindow), which can be opened via the Companies/Clients menu item in the Main menu.
The following screenshot shows the default ribbon (for a role with all relevant permissions), including the default input form with the details of the company selected in the list area (at the bottom).
Special features in the ribbon
In addition to the generic ribbon buttons (New, Delete, etc.), the main category ('Common') visible in the screenshot also contains two specific ribbon buttons for Companies/Clients:
|
Sub category |
Ribbon button |
Description |
Example |
|
Details |
|
The Integration Settings ribbon button opens a modal dialogue with specific settings for ‘Clients’ (Lobster Data Platform / Integration). |
|
|
Overview |
|
The Integration Settings ribbon button opens a modal view that visualises the company hierarchy based on a selected company. The example on the right shows a very simple company hierarchy in which the company ‘F_UTILITY B.V.’ is subordinate to the company "ZWORX Ltd. |
|
Contents of the default input form
The default data input form for Companies/Clients only shows a selection of the total available content of the data structure for Companies/Clients via Form elements.
These appear in three tabs:
'Company Account' tab
|
Object |
Field |
Data field path |
Example value |
Contents |
|
‘Company Account’ |
Meta type |
metaType |
‘Company’ (COMPANY) |
Single selection for the Company meta type of the company, e.g. ‘Company’ (COMPANY) or ‘Group’ (GROUP). |
|
Language |
locale |
‘German’ (de) |
Simple selection that links a specific Locale to the company. |
|
|
Style name |
styleName |
"XFLOW" |
Simple selection that links one of several available Styles to the company. |
|
|
Parent companies |
parentCompanies |
"ZWORX Ltd." |
Multiple selection of Companies/Clients that are to be directly superior to the company in the hierarchy. |
|
|
Company types |
types |
'Bill-to party' (INV) |
Multiple selection for Company type values, which characterises the ‘profile’ of a company and helps to control its participation in modelled processes. |
|
|
Address' |
Salutation |
address.salutation |
'Company' (COMPANY) |
Single selection for the Salutation in the company address. |
|
Name |
address.name1 |
'F_UTILITY B. V.' |
Free text that should identify the company as clearly as possible, as it is preferably used for labelling (see ‘Graph’ above). |
|
|
Name 2 |
address.name2 |
'ZWORX Group' |
Free text that defines subordinate text for naming the company. |
|
|
Street |
address.street1 |
'Dingshoflaan' |
Free text for the street in the postal address. |
|
|
Street no. |
address.streetNo |
'57' |
Free text for house number(s) in the postal address. |
|
|
Account-No. |
address.accNumber |
'002-101' |
Free text that can be used, for example, to specify an identifier for the company in other systems. |
|
|
Country code* |
address.countryCode |
'Netherlands' (NL) |
Single selection for the Country in the postal address. |
|
|
Zip code* |
address.zipcode |
'8043' |
Free text for the zip code in the postal address. |
|
|
City* |
address.city |
'Zwolle' |
Free text for the name of the city in the postal address. |
*) Interactive changes to the Country, Zip code and City fields may trigger a lookup of data for Cities. When accepting a match in the automatically displayed dropdown, address fields may also be filled or overwritten with data stored for Cities that is not displayed in the standard entry screen for Companies/Clients.
'Communication Infos' tab
The screenshot shows the format used in the default input form for Companies/Clients for entering Communication infos.
Communication infos is saved as Plural attributes of the ‘Communication information’ (AddressCommunicationInfo) type for the company address.
A Communication type can be selected in the Type field. Several entries for the same type can be assigned to an address.
In the Context field, a text key can be specified that characterises the intended use for the relevant communication information.
In the Value field, the key information for the communication information (e.g. an e-mail address or a telephone number) should be entered.
CAUTION
For Plural attributes, the restriction stipulates that there must be no complete redundancy between two instances of the attribute when saving. If the list of Communication infos contains at least two entries that are completely identical in Type, Context and Value, an error occurs when saving.
►NOTE◄ Communication information with the Type e-mail is used particularly frequently to store data for addressing in an automatic E-Mail. For Companies/Clients, for example, the Mail address company resolver can be used to look up stored e-mail addresses for a specific Context directly without having to configure this read access to the attribute structure of the address in detail. However, simplified access via E-mail requires a Context to be stored in the attribute.
►NOTE◄ Even if Communication infos refer to a Communication type, they are not formally typed attributes but Plural attributes (see also Business objects and attributes). This must be taken into account when configuring accesses (see Attribute (Resolvers) or Projections).
'Contacts' tab
The screenshot shows the format used in the default input form for Companies/Clients for entering Contacts.
Contacts are saved as typed attributes of the ‘address contact’ (AddressContact) type for the company address.
Each 'address contact' (AddressContact) attribute references a fully-fledged 'address' (Address) entity via its contactAddress field.
In addition to the Combobox element for the Contact type (see Contact type), the default input form only contains a very straightforward selection of address fields (Salutation, Name, Name 2). It can be extended as required.
CAUTION
The definition for the Contact type enumeration uses the 'Plural attribute' (pluralAttribute) indicator to identify types that can be assigned multiple times to the same attribute owner (here: address). However, the input form does not check whether more than one entry has been created for a non-plural Contact type. If this is the case, an error message is not displayed when the company account is saved, but only the 'last' entry for the relevant subtype is actually saved. If the Contact type ‘Location’ in the example did not qualify as a ‘Plural attribute’, the penultimate contact entry (‘Terminal 1’) would simply be ‘lost’ when it is saved without a message.
However, this effect is only relevant if the data input form manages Contacts of all types via a common Repeatable element ('Contacts'), as is the case in the default setting. If individual Form elements s are set up for each type instead, each Contact type (whether plural or singular) is represented 'appropriately'.