Skip to main content

Thirty worked Charity scenarios

These exercises use invented Bright Haven Trust data. Use an approved training tenant and actual permitted IDs. Each expected result assumes its task's capabilities, permissions, unit scope and configuration are satisfied. The role names and account labels below are illustrative, not seeded templates or prescribed accounting codes.

1. Existing customer becomes a donor​

Request: Bright Future Foundation already exists as a customer organisation and makes a gift.

  1. Search Party and confirm the existing organisation.
  2. Open Donors and activate that same Party as DONOR.
  3. Recheck its ID and use it for the identified donation.

Expected: One canonical Party with commercial and donor roles; no new Partner required by activation. Recovery: If two similar identities exist, resolve the identity selection before proceeding. See Donors.

2. Unidentified collection​

Request: Record an unattributed GBP 84.50 North collection.

Choose North, UNIDENTIFIED and GBP 84.50; allocate 84.50 to General Support and save. Confirm no Party and public-anonymity false.

Expected: DRAFT with an unidentified donor, not a fake named donor. Recovery: If identity later becomes known before posting, edit the draft under the appropriate permissions with a reason.

3. Known donor requests public anonymity​

Select the known active donor, keep IDENTIFIED and check Known donor requests public anonymity. Save GBP 100 to General Support.

Expected: Internal Party reference remains; anonymity preference is recorded. Recovery: Do not switch to UNIDENTIFIED to hide a known identity or assume this creates a public publication workflow. See Privacy.

4. Create a restricted education fund​

Create EDUCATION / Education Support / RESTRICTED with the approved restriction description and Active selected. Save, reload and then configure its approved revenue mapping separately.

Expected: Eligible active fund; no journal or bank account created. Recovery: Missing restriction text is a validation issue, not a reason to choose UNRESTRICTED instead.

5. Exact two-fund split​

Record GBP 250: General 150 and Education 100. Verify the exact total, save and inspect detail.

Expected: One draft with two unique fund rows. Recovery: If the second row is 99.99, resolve the missing penny explicitly; the system does not use a tolerance. See Allocations.

6. Duplicate allocation row​

A draft lists Education twice, 40 and 60, against total 100. Replace them with one Education row for 100 and save.

Expected: One row per fund. Recovery: Do not create another Education fund just to keep duplicate rows.

7. Currency draft that cannot post​

Farah enters a valid EUR 100 draft in a GBP-base tenant. Saving the draft can succeed; Nadia's financial preparation refuses a non-base-currency post.

Expected: Valid draft does not imply eligible posting. Recovery: Ask finance for the approved treatment. Relabelling EUR as GBP misstates the receipt; no manual FX control is provided.

8. Four-decimal GBP draft​

A GBP 1.2345 draft passes four-decimal storage rules. Posting rejects GBP precision. Confirm the actual received amount and explicitly edit total and splits to the correct two-decimal value with a reason.

Expected: No silent rounding. Recovery: If the actual evidence cannot be represented in the workflow, obtain the approved finance decision rather than guessing. See Currency and dates.

9. Preserve private notes while editing​

Farah can update donations but lacks sensitive view. The browser refuses to open an editable draft that would overwrite redacted notes. An appropriately authorised user reviews the requested change and preserves the existing notes.

Expected: Redacted notes are not silently erased. Recovery: Review the approved access or assign the task to an authorised editor; an empty-looking note is not proof it is blank.

10. Cancel an accidental draft​

Open the unposted GBP 50 draft, confirm its ID, enter the cancellation reason, tick confirmation and choose Cancel donation draft. Reload.

Expected: CANCELLED with retained lifecycle history; no refund or ledger posting. Recovery: If another user posted it meanwhile, reload and choose the correct supported posted-record procedure.

11. Configure finance for a compatible ledger​

Finance confirms the existing ledger base currency is consistently GBP. Save approved GBP settings with Europe/London, an initial date no later than local today, active state and a reason. Configure routes and fund mappings next.

Expected: Settings saved/versioned; configuration alone does not grant post rights. Recovery: Missing routes/mappings remain separate blockers.

12. Mixed-ledger currency conflict​

Settings activation reports LEDGER_BASE_CURRENCY_CONFLICT because retained ledger/payment base currencies differ or are invalid. Capture the non-secret diagnostic and ask finance/support to investigate.

Expected: No automatic conversion or historical rewrite. Recovery: Do not deactivate inconvenient records or choose an arbitrary currency to force activation. See Configuration.

13. Advance a deliberately held calendar​

Local today is 7 November and the approved business date remains 5 November. After finance approval, Nadia advances it to 6 November with the required reason and authority.

Expected: New saved date/version; not an automatic midnight rollover. Recovery: Regenerate previews prepared against the earlier date/version.

14. Actual receipt predates posting​

Money arrived 5 November; approved business date is 6 November. Post with actual receipt 5 November and review posting date 6 November in preview.

Expected: Internal receipt keeps arrival date; journal uses business date. Recovery: Do not change arrival date to match the journal just for visual consistency.

15. Set up a North cash route​

Create a route for North, holding NORTH-CASH-01, an approved active debit-normal ASSET account, CASH, configured GBP and a reason. Save and inspect its ID.

Expected: Approved immutable route identity. Recovery: To change identity create a replacement; activate/deactivate is the supported maintenance action. See Receipt routes.

16. Missing mapping on one split​

A GBP 250 draft has General 150 and Education 100. General has an active mapping; Education does not. Configure the approved Education mapping and regenerate preview.

Expected: Both splits use their approved accounts. Recovery: Do not move Education's 100 into General to bypass finance setup.

17. Post a two-fund gift​

Nadia reviews the GBP 250 draft, chooses the correct route and receipt date, generates preview, checks four journal lines, ticks review confirmation and confirms post.

Expected: POSTED, one internal payment, one initial journal and revision/history. Recovery: If the response is lost, use original-operation retry. See Posting.

18. Calendar changes after preview​

Nadia previews against calendar version A. An authorised finance user advances the date to version B before confirmation. The stale proposal is refused.

Expected: No unnoticed posting on an unreviewed date. Recovery: Reload settings and donation, regenerate preview and review both dates before confirming.

19. Lost posting response​

The network disconnects after Confirm post. The page shows an unresolved operation. Return to that donation and choose Retry original operation without changing the body/key.

Expected: The same intent resolves; not a second receipt. Recovery: Preserve the pending state and contact support if still unresolved. Do not clear storage or create another gift. See Retries.

20. Correct General/Education classification​

Correct posted GBP 250 from General 150 / Education 100 to 175 / 75. Supply both replacement rows, an approved same-holding route, reason and reference; preview and confirm.

Expected: Same payment; POSTED; new effective revision. Net recognised amount stays 250.

Recovery: Supply full replacement amounts, not +25/−25. See Corrections.

21. Correct an asset classification in the same holding​

Finance approves a replacement route using the same North cash holding, method, currency and unit but another eligible asset account. Nadia also needs charity.donation.correct.cash-account for that change.

Expected: Debit-account classification changes; physical money does not move. Recovery: A different bank/cash holding cannot be selected as a classification fix even with this permission.

22. Reverse one proven duplicate​

Two POSTED GBP 100 records refer to one actual receipt. Inspect matching identity/date/method/holding/evidence. On the duplicate, enter the canonical posted ID, reason/reference, attest evidence, preview and confirm reverse.

Expected: Canonical POSTED, duplicate REVERSED, net ledger recognises 100. Recovery: Two genuine gifts are not duplicates merely because fields match. See Duplicate reversals.

23. Retired branch historical correction​

North is inactive. Nadia retains an explicit North grant and the extra inactive-unit view/correct authorities. She reviews a historical posted gift and performs an eligible classification correction.

Expected: History can be maintained without reactivating the branch. Recovery: New posts remain blocked; these rights do not reopen the branch for ordinary draft work.

24. Retire a financially used fund​

Education has been used and later fully reclassified. A manager tries to change its restriction. The immutable-use rule still refuses it. Deactivate it if retiring and create a separately approved new fund for the new purpose.

Expected: Original code/type/restriction remain evidence even at zero net balance. Recovery: Review old drafts explicitly; do not assume they migrate to the new fund automatically.

25. Start alias-only support​

Activate the sponsor's DONOR role, verify the restricted fund and select eligible Willow-27. Enter GBP 30 MONTHLY and approved dates; start and inspect the sponsorship.

Expected: ACTIVE commitment with an alias target, no confidential identity or automatic donation. Recovery: A missing alias target needs Care eligibility review through the authorised team, not disclosure of a real name. See Sponsorships.

26. Pause and review a duplicate commitment request​

Omar pauses a sponsor's Willow-27 relationship. A colleague tries to start another for the same sponsor/target. The existing PAUSED relationship still counts as live and blocks duplication.

Expected: Review the existing relationship rather than create a duplicate. Recovery: Resume only if eligible and approved; an ended relationship is terminal. See Lifecycle.

Willow-27's profile-sharing consent expires. Refresh shows Needs transfer. Omar agrees a facility destination, enters the reason and transfers.

Expected: Old record ENDED; linked new facility record ACTIVE with preserved commitment and current start. No automatic end occurred on consent expiry. Recovery: Review any existing destination sponsorship and outstanding messages separately. See Transfers.

28. Separate approval with photo refusal and revision​

Omar drafts an update with a photo reference and submits it. He cannot decide his own submission. Leena sees missing public-photo consent and rejects with a useful reason. Omar removes the photo reference, saves/resubmits; Leena reviews again and approves. Omar marks it published.

Expected: Distinct-user review, frozen approved content and recorded publication; nothing sent. Recovery: If current eligibility changes before approval, resolve that blocker. Before later external use, review current consent under the approved process. See Approvals.

29. Read coverage without inferring collections​

Run Sponsorship coverage within approved unit scope. Read ACTIVE/PAUSED relationship coverage, protected small values and the note that programme/needs-transfer totals are tenant-wide.

Expected: Aggregates with <5 protection, not named people or paid instalments. Recovery: A large fund total cannot prove a particular sponsor paid; donations are not linked to commitments. See Reports.

30. Export safe finance evidence​

An authorised support integration requests financial CSV page 0, size 100 with the required export/view rights. It collects the documented fixed columns for posted/reversed records in readable units and handles subsequent pages explicitly where needed.

Expected: IDs, posting date, currency, amount and state; no donor or private reasons even for a sensitive viewer. Recovery: Do not assume a browser export button or a one-response full-tenant export. Report the exact authorised API boundary and pagination. See Privacy and exports.