Managing Purchasing, Reporting, and Group Work

This page shows users how to raise spend requests, handle visible purchasing steps, produce reports, and work with multi-entity outputs without hiding bad source data.

Product: Beam Machine
Module: Procurement, Reporting, and Multi-Entity
Role: Procurement User, Accountant, Finance Lead, Group Reviewer
Difficulty: Intermediate
Time: 12 minutes first read
Last Updated: 2026-03-10
Version: Current Beam Machine app build in this repo

Before You Start

• You need the correct entity, requester, supplier, or group context.
• You should know whether you are raising demand, recording receipt, preparing reporting, or reviewing group outputs.
• Keep 99-functionality-gap-map.md open if you need to confirm which purchasing steps are partial.

What is procurement, reporting, and group work?

This part of Beam Machine links operational demand, purchasing control, management reporting, and group-level outputs. On paper, this would be your requisition forms, purchase orders, goods-received notes, board pack reports, and consolidation workbooks.

In Beam Machine, that work is split across Procurement, Reporting, and Multi-Entity.

When do you use this?

Use this page when the business needs to request spend, record a receipt event, produce management reporting, or consolidate more than one entity.

If you use reporting to hide bad inputs, the output may look polished but it is still wrong.

Where do you find this work?

Primary path: Use Procurement, Reporting, and Multi-Entity from the left sidebar.
Reference: Use 98-screen-map.md if you need the route list.

How to run the workflow safely

Main screens

Screen	Route	What it does
Purchase Requisitions	/dashboard/procurement/requisitions	Raise and review requisitions
New Requisition	/dashboard/procurement/requisitions/new	Create a requisition
Purchase Orders	/dashboard/procurement/orders	Review or manage POs
New Purchase Order	/dashboard/procurement/orders/new	Create a new PO
Goods Received	/dashboard/procurement/received	Record receipts
Reporting	/dashboard/reporting	Reporting family entry point
Multi-Entity	/dashboard/multi-entity	Consolidation and eliminations

Raise a requisition

1. Open Procurement > Purchase Requisitions.
2. Create the requisition before money goes out.
3. Add a clear description.
4. Confirm department, amount, and requester.
5. Submit into approval flow if your process requires it.

✅ Checkpoint: The purchase need should exist as a controlled request before it becomes a bill or payment.

Use the visible purchase-order flow honestly

1. Open Procurement > Purchase Orders > New.
2. Enter the supplier, expected delivery date, reference, and line items if the environment allows it.
3. Confirm whether your environment actually saves the PO successfully.
4. If it does not, log the gap instead of pretending the full PO lifecycle is production-complete.

✅ Checkpoint: The form may be visible, but the end-to-end PO creation flow is still not fully implemented in the current codebase.

Record goods received

1. Open Goods Received.
2. Confirm the receiving event happened in real life.
3. Link the receipt to the purchase context where possible.
4. Review the record before downstream payable processing.

✅ Checkpoint: A goods receipt should explain why a supplier bill exists, not be captured as an afterthought.

Use reporting without lying to management

1. Open Reporting.
2. Choose the report family you need.
3. Confirm the entity or group.
4. Confirm the period.
5. Check the underlying books before export or circulation.

Current visible report families include:

• Financial Reports
• Aged Reports
• Budget and Variance
• Executive Summary
• Ratio Analysis
• KPI Dashboard
• Narratives
• Benchmarks

Use reports/00-report-index.md if you need one page per reporting route.

✅ Checkpoint: If the source books are not credible, the report is not credible either.

Use multi-entity pages properly

1. Open Multi-Entity only when the work is genuinely group-level.
2. Confirm each source entity is clean enough first.
3. Use Consolidation for group roll-up.
4. Use Eliminations for intercompany adjustments.
5. Review the group output before anyone uses it in reporting.

✅ Checkpoint: Group work should not be a place where source-entity mistakes go to hide.

Common Questions & Issues

"We skipped requisitions and just captured the bill"

Why this happens: Teams take the shortest path when the control path feels slower.

Fix: Start the spend trail earlier with a requisition so demand, approval, receipt, and payable logic can connect.

---

"The PO page exists, so full purchase-order processing must be ready"

Why this happens: Visible forms look more complete than the current implementation really is.

Fix: Treat the PO create flow as partial until your environment proves the save and lifecycle steps work end to end.

---

"We’ll fix the bad source data during consolidation"

Why this happens: Multi-entity work is often used as a cleanup layer.

Fix: Clean the source entity first. Consolidation should combine good data, not disguise bad data.

What's Next

• Read 11-accounting-ledger-reports-and-close.md for the ledger and close work that supports reporting.
• Read 12-invoicing-banking-and-tax.md if the workflow moves into billing, banking, or tax.
• Read reports/00-report-index.md if you need report-by-report guidance.

Related Pages

• 06-finance-core.md
• 11-accounting-ledger-reports-and-close.md
• 12-invoicing-banking-and-tax.md
• reports/00-report-index.md
• 99-functionality-gap-map.md

SA Compliance Reference

• Procurement records, supporting documents, and goods-received evidence may affect VAT support, audit readiness, and management accountability.
• Group reporting depends on clean source records and defensible eliminations.
• Use the current visible workflow and treat partial PO functionality honestly in operating procedures.

Still Stuck?

• Check 98-screen-map.md to confirm the route.
• Check 99-functionality-gap-map.md to confirm maturity and known gaps.
• Contact support: support@veva.co.za

Was this page helpful?

[Yes] [No]