Party Data Type

A party can refer to any number of types of data; for example, a contact, customer, user, company, organisation, person, etc.

A party can refer to an individual, which is defined as a person with a name; or it can refer to a non-individual, which is usually a company or similar type of entity.

Each party can contain both a person’s name and company name. It’s also possible for a party to ‘work for’ another party, which can be used to represent a hierarchy.

However, as most accounting systems do not have a concept of customers and accounts, either party type can be used.

Many systems have different concepts for managing a party and how they relate to each other. Slyncy has a flexible data model and can represent all of the possible ways a party can be presented in an end system. However, translating from one representation to another sometimes can be very difficult.

Currently we do not support deletions. So if you delete a party in any system, the connection to that system will be lost. If you try to send a transaction to that system and it depends on the deleted party, then the transaction will fail. You need to check that the party is not being used and make sure you delete the same party in all systems. It is best to deactivate or archive the party whenever possible.

Duplicates can be difficult to manage in Slyncy. Deduplication of parties must be done very carefully. With most deduplication processes, the duplicate item is effectively deleted (and the deletion problems above apply). Ensure that you deduplicate in the exact same way on all systems – ensuring that the same duplicate is deleted on all systems. To ensure that the duplicate is the same on all systems, you should check the Slyncy hub’s version of the party and follow through the links.

CRM Party Structure

CRM’s have a fairly strict concept of company/contact hierarchy.

• a company or organisation is represented as an non-individual party
• a contact is represented as an individual party.

This is fine when you are transferring from a CRM to another system. Some problems arise when transferring non-CRM parties to a CRM:

If we require an Opportunity to be linked to an account, but the Invoice in the accounting system is linked to a non-individual party (i.e. a named person).In this case we need to transfer the non-individual party as an account. Most CRM’s allow you to turn on Customer/Supplier sync, which means any party that is a customer/supplier (i.e. they’ve been invoiced or have sent a bill) will also be transferred as an account.If we have a party with both the person’s name and company on the same party (i.e. non hierarchical data), then we don’t have enough data to transfer the party as both a company name and client name.Slyncy does not have a standard way of supporting this as there is no single way to solve this. However, the system may be customised to achieve this, talk to your Slyncy consultant to ensure that your configuration is customised to handle this correctly.

Non-hierarchical data

Non hierarchical data refer to parties with both the company and person’s name on it.

• On creation, Parties are defaulted to individual if there is a firstname or lastname, otherwise non-individual.

Integrating non-hierarchical data with a CRM for example can cause problems (see the CRM Party Structure section).

Party Fields