Parties

Parties is the shared people and organisation foundation for Pinkapple ERP.

A party can be an individual, group, or organisation. Other modules consume party records instead of creating their own customer, supplier, borrower, farmer, employee, member, agent, or vendor master lists.

Why Parties Matter

Parties feed:

• Billing invoices and statements
• Payments and payout instruments
• Loans and deposits
• Shares and member records
• CRM leads and opportunities
• POS customers
• Agriculture producers and buyers
• Production customers and suppliers
• Communication recipients
• Reporting and exposure summaries

Workspaces

Open Parties to manage:

• party types and role types
• party roles
• individual clients
• groups
• organisations

Workspace Reference

Workspace	Open From	Main Action	Main Record
Party Types / Role Types	Parties -> Setup -> Party Types	Create or maintain party role type	Defines which roles a party can hold and which fields are needed.
Party Roles	Parties -> Operations -> Party Roles	Assign, update, or end role	Runtime role assignment on an existing party.
Individual Clients	Parties -> Operations -> Individual Clients	Create individual	Natural person used by customers, students, farmers, borrowers, employees, agents, members, or guarantors.
Groups	Parties -> Operations -> Groups	Create group	Collective party such as savings group, farmer group, club, committee, or customer group.
Organisations	Parties -> Operations -> Organisations	Create organisation	Company, supplier, cooperative, school, buyer, employer, institution, or partner.

Some legacy client and group type setup may still appear while party-role migration is active. New configuration should use party role types where possible.

Party Types And Role Types

Party role types describe what a party is allowed to be in a business context.

Examples:

• borrower
• supplier
• customer
• farmer
• agent
• employee
• cooperative
• guarantor
• member

A role type may control profile sections, required information, applicability, and display behavior.

Party Roles

A party role is a runtime assignment of a role to a party.

For example, the same individual may be:

• a borrower in Loans
• a member in Shares
• a customer in Billing
• a mobile-money payout recipient in Payments

Ending a role should not delete the party. It only ends that role assignment.

Individuals, Groups, And Organisations

Individuals

Individuals represent natural persons. They can hold phone numbers, contact details, KYC data, role assignments, accounts, and relationships.

Groups

Groups represent collective parties such as savings groups, farmer groups, clubs, committees, or customer groups.

Organisations

Organisations represent companies, suppliers, cooperatives, schools, buyers, employers, institutions, or other legal entities.

Party Data As Source Of Truth

Party contact and bank information should be maintained on the party record. Downstream modules should reference that party-owned data.

For example:

• Payment instruments should use party contacts or bank accounts as their source.
• Billing statements should use the party identity.
• Communication should use party contact channels.
• CRM should avoid duplicating customer identity where the party already exists.

Common Mistakes To Avoid

• Do not create separate supplier/customer records in each module when a party record should be reused.
• Do not delete a party to stop one relationship; end the relevant role instead.
• Do not type payout phone numbers directly into a payment batch when the number belongs on the party record.
• Do not create duplicate individual and organisation records for the same legal party without a clear reason.
• Do not use legacy client/group types as the long-term model when party role types are available.

Related Guides

• Party Setup
• Party Operations
• Billing Overview
• Payments & Settlement