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
• Supplier payable invoices, procurement source documents, and supplier payments
• 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
• Inventory procurement suppliers and return counterparties
• 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.

For procurement, the Supplier role is especially important. Purchase orders, goods receipts, supplier returns, supplier debit notes, supplier invoices, and supplier payment batches should use parties that have an active Supplier role. If the role is missing or pending approval, procurement lookups may block the party even if the organisation record exists.

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

The same organisation may also be both a customer and a supplier. Do not create two organisation records for the same legal entity; assign both roles to the same party where policy allows it.

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.

For suppliers, organisation records should carry the trading name, contacts, tax or registration details where required, addresses, bank accounts, attachments, and active Supplier role assignment.

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.
• Supplier invoices and payment batches should use the supplier party and its approved payment instruments.
• 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 create a duplicate supplier because procurement lookup cannot find it; first check whether the Supplier role is missing, inactive, pending approval, or not applicable to the party shape.
• 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