Party Operations

Party operations maintain the individual, group, and organisation records used across Pinkapple ERP.

Open Parties -> Operations.

Workspace Reference

Workspace	Main Action	Main Record
Individual Clients	Create or edit individual	Natural person with identity, contact, KYC, roles, relationships, and accounts.
Groups	Create or edit group	Collective party with members, officers, roles, contacts, and downstream activity.
Organisations	Create or edit organisation	Legal or operating entity such as school, supplier, buyer, cooperative, company, or institution.
Party Roles	Assign or end role	Business role that allows the party to participate in module workflows.

What Users Maintain

Party operations can include:

• individual records
• group records
• organisation records
• role assignments
• contacts and phone numbers
• email addresses
• physical or postal addresses
• identity and KYC information
• relationships
• group membership
• bank accounts
• attachments and notes
• lifecycle status
• financial exposure summaries where permitted

The exact fields and actions depend on permissions and the active service context.

Individual Parties

Use individual records for natural persons.

Typical information includes:

Information Area	Examples
Identity	Full name, gender, date of birth, identification details.
Contacts	Primary phone, alternate phone, email, contact preferences.
Address	Residential, postal, workplace, or other addresses.
KYC	Identity documents, photos, signatures, attachments, risk details.
Roles	Borrower, customer, employee, farmer, member, guarantor, supplier, or other roles.
Relationships	Group membership, employer, guarantor relationship, next of kin, linked organisation.
Accounts	Loan, deposit, share, billing, wallet, payment, or other linked activity where permitted.

Individual records may be approved, locked, blacklisted, anonymised, or otherwise controlled depending on policy.

Important individual fields:

Field	Meaning
Main party role	Primary reason the individual is being created, such as customer, farmer, student, employee, agent, borrower, or member.
Full name	User-facing identity used across modules.
Phone and email	Contact data used for communication, follow-ups, and payment instruments.
Identification details	KYC or official identification where policy requires it.
Addresses	Residential, postal, workplace, or other contact locations.
Bank accounts	Party-owned bank records used later by payment instruments.
Attachments	Supporting files such as ID, photo, contract, consent, or onboarding evidence.

Groups

Use group records for collective parties.

Examples:

• savings groups
• farmer groups
• clubs
• committees
• cooperative units
• customer groups
• borrowing groups

Common group tasks include:

• create group
• maintain group type or role
• add or remove members
• assign group officers or signatories
• manage group status
• use the group in loans, deposits, shares, billing, agriculture, or payments

Group membership should be kept current because downstream eligibility and reporting can depend on it.

Important group fields:

Field	Meaning
Main party role	Why the group exists in the system, such as farmer group, borrowing group, customer group, or committee.
Group name	User-facing group identity.
Group type or role type	Controls applicable fields and eligibility.
Members	Individuals connected to the group.
Officers or signatories	People allowed to act for the group where policy requires it.
Contacts and address	Communication and statement details.
Attachments	Registration, minutes, agreement, or supporting documents.

Organisations

Use organisation records for legal or operating entities.

Examples:

• supplier
• buyer
• cooperative
• school
• company
• transport provider
• employer
• partner institution

Organisation records should hold:

• legal or trading name
• registration details
• tax information where applicable
• primary contacts
• addresses
• bank accounts
• roles
• attachments or supporting documents
• approval and lifecycle status

Important organisation fields:

Field	Meaning
Main party role	Why the organisation is being created, such as school customer, supplier, buyer, cooperative, employer, or partner.
Organisation name	Legal or trading name used across modules.
Registration or tax details	Official identifiers where required.
Primary contacts	People or channels used for communication and follow-up.
Addresses	Billing, delivery, head office, or operating locations.
Bank accounts	Party-owned bank records used later by payment instruments.
Attachments	Contracts, certificates, tax documents, or other supporting evidence.

Assigning Roles

Assign a role when a party needs to participate in a business process.

Examples:

Need	Role Example
Loan application	Borrower or guarantor.
Supplier payment setup	Supplier.
Agriculture settlement	Farmer, producer, buyer, or transporter.
Billing invoice	Customer or billed party.
Share activity	Member or shareholder.
Staff activity	Employee.

End a role when it no longer applies. Ending a role keeps historical activity intact.

Contact Hygiene

Contacts drive communication, payment instruments, customer statements, and operational follow-up.

Review contact data before:

• creating mobile money payment instruments
• sending statements or reminders
• sending SMS or email messages
• assigning CRM follow-up
• approving loan or onboarding records
• setting up supplier or farmer payouts

Avoid storing the same phone number in multiple unrelated places. Use the party contact record as the master.

Bank Account Hygiene

Bank accounts should be maintained on the party record where bank payouts, supplier payments, refunds, or account verification depend on them.

Before using a bank account:

• confirm account number
• confirm account name
• confirm bank and branch where required
• confirm currency
• confirm approval or verification status where available
• confirm it belongs to the selected party

Payment instruments should reference approved party bank-account records rather than free-typing bank details during batch payout.

Duplicate Prevention

Before creating a new party, search by:

• name
• phone number
• email
• identification number
• registration number
• group name
• organisation name

If a party already exists, add the missing role instead of creating a duplicate record.

Duplicate parties cause:

• split balances
• wrong payment instruments
• duplicate statements
• duplicate CRM records
• incorrect exposure reports
• failed lookup eligibility

Financial Summary

Where permissions allow, users can review service-scoped financial exposure for a party.

Examples:

• invoices and balances
• payment instruments
• loan accounts
• deposit accounts
• share accounts
• wallet activity
• settlement obligations
• relationships and guarantees

Use financial summary for review and navigation. Do not treat it as a replacement for detailed module ledgers.

Party Lifecycle

Common lifecycle controls include:

State Or Action	Meaning
Active	Party can be used in normal workflows.
Pending Approval	Party or change is waiting for review.
Locked	Access or activity is restricted.
Blacklisted	Party is restricted by policy or risk controls.
Inactive	Party is retained for history but not used for new workflows.
Anonymised	Personal details are hidden or removed according to policy.

Lifecycle actions should be used carefully because many modules depend on party availability.

Troubleshooting

Issue	What To Check
Party does not appear in a module lookup.	Required role, active status, approval status, service context, and permissions.
Payment instrument cannot be created.	Party phone/contact or bank account exists and is eligible.
Communication cannot be sent.	Phone, email, contact preference, and consent where required.
Statement details are wrong.	Party identity, address, invoice allocations, and duplicate records.
Supplier payout destination is wrong.	Party bank account or mobile contact and payment instrument verification.
Party appears duplicated.	Search individual, group, and organisation records before creating another.

Common Mistakes

Mistake	Better Practice
Creating a new party when only a new role is needed.	Add the role to the existing party.
Deleting or disabling a party to stop one relationship.	End the role instead.
Typing payout contacts in payment batches.	Maintain party contacts and instruments first.
Ignoring duplicate records.	Merge or clean records according to policy before more activity is created.
Treating financial summary as the final ledger.	Open the detailed module ledger for confirmation.

Related Guides

• Party Setup
• Payment Instruments
• Billing Overview
• Communication Overview