Party Setup

Party setup controls how people, groups, and organisations are classified, governed, and reused across Pinkapple ERP.

Open Parties -> Setup.

Setup Goal

Party setup should make sure users can:

• classify parties consistently
• assign the right roles
• capture role-specific information only where needed
• prevent duplicate customer, supplier, farmer, borrower, member, or agent records
• control which modules can use which party records
• support contacts, bank accounts, payment instruments, statements, communication, and reporting

Workspace Reference

Workspace	Open From	Main Action	Main Record
Party Role Types	Parties -> Setup -> Party Types	Create or maintain role type	Defines party role names, applicability, onboarding fields, and module behavior.
Runtime Party Roles	Parties -> Operations -> Party Roles	Assign or end role	Applies a configured role type to an actual party.
Individual Clients	Parties -> Operations -> Individual Clients	Create or edit individual	Natural-person party records.
Organisations	Parties -> Operations -> Organisations	Create or edit organisation	Organisation party records.
Groups	Parties -> Operations -> Groups	Create or edit group	Collective party records and membership.

Party Types

Pinkapple works with three broad party shapes:

Party Shape	Use It For
Individual	Natural persons such as customers, borrowers, farmers, employees, agents, members, or guarantors.
Group	Collective parties such as savings groups, farmer groups, clubs, committees, or customer groups.
Organisation	Companies, suppliers, cooperatives, schools, buyers, employers, institutions, or partner entities.

The party shape describes the legal or operating identity. Roles describe what the party does in a business context.

Party Role Types

Role types define the meaning of a party relationship.

When creating a role type, choose a clear business name and limit it to the party shapes that should actually use it.

Examples:

• borrower
• depositor
• shareholder
• supplier
• customer
• farmer
• buyer
• transporter
• employee
• agent
• guarantor
• cooperative

Role types are important because other modules use them for lookup filtering, eligibility, approvals, forms, reports, and workflow routing.

Important role-type fields:

Field	Meaning
Role name or code	User-facing role such as Supplier, Farmer, Buyer, Student, Customer, Agent, Borrower, or Member.
Applicable party shapes	Whether individuals, groups, organisations, or a combination may use the role.
Description	When users should assign this role.
Profile sections	Role-specific field groups shown during onboarding.
Required fields	Data the user must capture before the role is complete.
Active status	Whether the role type can be assigned to new parties.

Role Applicability

Each role type should clearly state which party shapes can use it.

Examples:

Role Type	Typical Applicability
Borrower	Individual, group, or organisation depending on lending policy.
Supplier	Individual or organisation.
Farmer	Individual, group, or cooperative.
Employee	Individual.
Buyer	Individual or organisation.
Guarantor	Usually individual or organisation depending on policy.

Avoid assigning roles too broadly. If every party can be every role, module lookups become noisy and users make more mistakes.

Profile Sections

Role types can include profile sections that capture role-specific information.

Examples:

• farmer production details
• supplier payment preferences
• borrower employment details
• agent commission details
• cooperative registration information
• transporter vehicle or route details

Keep common identity information on the party record:

• name
• phone numbers
• email
• addresses
• identification
• bank accounts
• general KYC

Use role profile sections only for information that belongs to that role.

Contact And Bank Data Ownership

Party setup should reinforce this rule: party records own contact and bank data.

Downstream modules should reference party-owned data instead of creating separate copies.

Examples:

• Payment instruments should select party phone/contact or party bank-account records.
• Billing statements should use party identity and address/contact details.
• Communication should use party phone, email, or contact preferences.
• CRM should link to an existing party where one already exists.

This prevents duplicate phone numbers, bank accounts, and customer identities.

Legacy Type Mappings

Some tenants may still have legacy client or group types. Legacy mappings help older records work with the newer party role model.

Use legacy mappings for:

• migration compatibility
• old client/group records
• phased rollout of party roles

Do not treat legacy mappings as the preferred long-term configuration when party role types are available.

Approval And Permissions

Administrators should decide:

• who can create parties
• who can edit identity details
• who can assign or end roles
• who can approve parties or role assignments
• who can maintain sensitive KYC, contacts, and bank details
• who can blacklist, lock, anonymise, or reactivate parties

Sensitive fields such as identity documents, bank accounts, phone numbers, and payout contacts should have clear governance.

Setup Checklist

• Role type names are clear and business-facing.
• Role applicability is defined for individuals, groups, and organisations.
• Required profile sections are useful but not excessive.
• Contacts and bank accounts are maintained on the party record.
• Legacy mappings are reviewed before migration or go-live.
• Permissions align with who can create, update, assign, approve, or end roles.
• Module lookups show only relevant roles.
• Reporting teams understand which roles drive exposure and activity reports.

Common Mistakes

Mistake	Better Practice
Creating separate customer, supplier, and borrower records for the same person.	Create one party and assign multiple roles.
Putting common phone or bank details in role-specific sections.	Keep contacts and bank accounts on the party record.
Making role types too broad.	Limit applicability so lookups stay useful.
Using legacy types as the long-term model.	Move toward role types where available.
Ending a party to stop one relationship.	End the relevant role, not the whole party.

Related Guides

• Party Operations
• Payment Instruments
• Billing Overview
• CRM Overview