Issue and reprint receipts

Issue, approve, deliver, duplicate, print and cancel receipts without breaking payment evidence.

Product-truth rule

Makronexus keeps several records deliberately separate. A payer's intention, a provider session, a Payment record, an invoice allocation, a receipt, a cashier count, a bank deposit and a reconciliation match answer different questions. Never collapse them into one green badge. A safe operator follows the evidence chain and names the exact record that proves each claim.

At Mupfure Learning Academy, use the authenticated tenant and selected school on every collection action. Confirm the student, invoice, currency, amount, channel and business date before mutation. Use generated identifiers and audit fields after mutation; do not rely on a toast, copied reference or printed page as the sole proof. Where a provider is missing, inactive or lacks credentials, provider workspaces may show warnings or placeholder data. Placeholder rows are not transactions and must never enter a handover, receipt or reconciliation total.

Learning outcomes

By the end of this chapter, you can:

• explain the records and lifecycle dimensions used by this workflow;
• choose the correct workspace and exact permission for each action;
• perform the workflow without treating a UI success message as financial proof;
• identify exceptions before they alter invoices, cash, receipts or external evidence;
• assemble an audit trail another reviewer can reproduce.

Prerequisites

• A saved Payment
• Verified allocation context
• Approved receipt numbering, template and delivery settings

Key definitions and boundaries

Receipt types include official, provisional, duplicate, adjustment, refund and other. Approval states are pending, approved, rejected and cancelled. Delivery methods include email, SMS, WhatsApp, printed, portal and none. A duplicate points to the original receipt; a cancellation preserves the original number and reason. Delivery fields record send action and recipient, not universal proof that the recipient read or accepted the document.

Roles and exact permissions

Use only abilities assigned for the active tenant and school. Backend enforcement remains authoritative, and route aliases do not replace endpoint-specific permissions.

• financial_receipt:create
• financial_receipt:list
• financial_receipt:read
• financial_receipt:statistics
• financial_receipt:update
• financial_receipt:resend
• financial_receipt:cancel
• financial_receipt:delete
• financial_payment:read

A role that can view a record does not automatically have authority to create, confirm, verify, allocate, refund, approve or delete it. Apply segregation of duties for independent monetary decisions.

Workflow map

Guided procedure

1. Issue only from saved evidence

Open the Payment and confirm payment ID, payment number, student, school, amount, currency, method and allocations. The Receipt issue request requires payment ID, line items and invoice allocations; these should reconcile to the Payment. Do not issue an official receipt from a pending attempt, a screenshot or an unsaved front-desk form.

2. Check numbering and content

Use the generated receipt number and active school settings. Confirm receipt date, type, payer/received-from details, issuer identity/location, line descriptions, invoice links, amount and currency. Statutory fields such as a ZIMRA number are configuration- and country-dependent; do not fabricate one when the integration has not returned it.

3. Approve and deliver independently

Where approval is required, a maker issues and an authorised reviewer approves or rejects. Printing or PDF generation is presentation evidence, not approval. Sending records delivery method and recipient. A “sent” flag does not universally prove provider delivery, portal view or guardian receipt; use channel-specific evidence where available.

4. Reprint through duplicates

A lost or damaged copy should normally produce a duplicate receipt linked by originalReceiptId, with a reason. Never regenerate a second “original” number. Mark duplicate status visibly. Preserve who requested it, who issued it and whether it was sent immediately.

5. Cancel without erasing

Cancellation requires a reason and keeps the receipt in the audit trail. Cancelling a receipt does not automatically reverse or refund the Payment. Review the Payment separately and initiate the correct correction only when the underlying funds or allocation is wrong.

Worked Mupfure scenario

Mupfure receives a USD 300 cash Payment allocated to one invoice. The cashier issues an official receipt pending approval. The bursar checks payment and allocation links, approves it, and the cashier prints a copy. Two weeks later the guardian requests another copy. The operator creates a duplicate linked to the original, records “guardian lost printed copy”, and sends it by email. The Payment remains one record and the original receipt number remains historically intact.

Control standard

Apply the following control standard to every collection channel:

1. Identify the payer, student, school, currency and obligation independently.
2. Authorise the operator through the exact route permission, not only menu visibility.
3. Capture the channel evidence required for that method, such as a bank reference, mobile number, card last four digits or cash-session identity.
4. Verify the resulting lifecycle state and immutable identifiers after the request completes.
5. Allocate only against valid invoices and prove that allocated plus unallocated value equals the payment amount.
6. Issue evidence only from the saved Payment and its allocation context.
7. Handover cash, provider and exception evidence to the correct downstream workspace without pretending that P5 posting or P6 reconciliation is complete.

Maker and reviewer should be different people for verification, refunds, cash-up approval, custody acceptance, deposit dispatch and any manual provider confirmation. When staffing makes this impossible, record the approved exception and obtain retrospective review under school policy. Never share credentials, edit gateway payloads, reuse another operator's session, or delete evidence merely to remove a discrepancy.

Failure modes

Failure or warning	Required response
Receipt amount differs from Payment	Do not approve. Reopen the source Payment/allocation and correct through the authorised process.
Receipt issued from pending attempt	Cancel/hold the receipt and wait for a saved Payment.
Second original number created	Preserve both records, stop delivery and correct using duplicate/cancellation controls.
Sent flag treated as read confirmation	Use only as send evidence unless the provider exposes stronger delivery/read proof.
Receipt cancellation assumed to refund money	Review and process the Payment separately; these are independent records.

Verification checklist

Before declaring this workflow complete, verify:

• the tenant, school, student and operator identities are correct;
• amount, currency, business/payment date and channel agree with source evidence;
• every attempt, Payment, allocation, receipt or control record has its own saved identifier;
• lifecycle states are read from the saved records after mutation;
• allocated and unallocated values conserve the Payment amount;
• duplicate and idempotency searches were completed where uncertainty existed;
• approval, verification and exception notes identify actors and timestamps;
• cash/provider/bank evidence was handed to the correct downstream workspace;
• no P5 posting or P6 reconciliation completion is claimed without those records.

Practice and knowledge check

1. Trace a receipt to its Payment and every invoice allocation.
2. Explain the difference between print, send, approval and payer receipt.
3. Demonstrate a duplicate issue without changing the original receipt.

Record your answers with the Payment/attempt/receipt/control IDs used. A reviewer must be able to reproduce the result from Makronexus without relying on screenshots alone.