Section §7
Process flows
Order-to-cash, procure-to-pay, plan-to-make, record-to-report.
This section describes the four canonical end-to-end business processes that execute through MES-Plus, using the standard manufacturing terminology: order-to-cash, procure-to-pay, plan-to-make, record-to-report. Each is presented as a stepped flow with the system actions, the actors, and the integration touchpoints.
The four flows together account for ~95 % of MES-Plus database write traffic.
7.1 Order-to-cash (O2C)
Customer ──order──▶ Sales ──CustOrd──▶ Planning ──ProdOrd──▶ Shop floor
│
│ (production)
▼
Goods issue
│
▼
┌───────────────┐
│ Customer │
│ invoice │
└───────┬───────┘
│
▼
GL post + EDI to customer
│
▼
Bank statement → cash apply
Step detail:
- Order entry. Sales takes order by phone, email, or EDI (3 large customers). EDI orders are picked up by SSIS package
edi_in_orders, validated against item master and customer master, and written tocustomer_order_headerand_lines. Manual orders are entered through the customer-order screen. - Order acknowledgement. A Crystal Report acknowledges back to customer via email (SMTP via broker). For EDI customers, an EDIFACT ORDRSP is generated by SSIS package
edi_out_acks. - MRP / planning. Overnight MRP run (see 7.3) generates suggested production orders to cover the customer orders. Planner releases them next morning (journey B).
- Production execution. Operators report against production orders (journey A). Production events generate inventory transactions: material consumed (negative) and finished goods received into stock (positive).
- Goods issue. When finished goods are available, sales-order picker performs goods-issue against the customer order. Inventory transaction decrements stock; customer-order line status moves to
shipped. - Invoice generation. Customer invoice is created from the goods-issue record. Invoice may be batch-generated nightly (default for non-EDI customers) or generated on-demand for urgent cases. EDI customers receive INVOIC EDIFACT, generated by SSIS
edi_out_invoices. - GL posting. Invoice posts to GL: debit AR, credit sales revenue, credit VAT payable.
- Cash application. Bank statement (MT940) is imported by broker. Statement lines are matched to open AR invoices by amount + variable-symbol reference. Auto-match resolves ~78 % [DB sample, 90 days]; remainder is manually applied by accounting.
Cycle time for a typical order: 4 hours (stock available) to 11 days (manufacture-to-order). Cash-apply lag: 14 days typical, 45 days 90th percentile [DB, 90-day sample].
Integration touchpoints: EDI in (orders) × 3 partners; EDI out (acks, invoices) × 3 partners; SMTP for non-EDI; bank-statement import; bank export (for refunds, rare).
7.2 Procure-to-pay (P2P)
Demand ──MRP──▶ Procurement ──PO──▶ Supplier
│
│ (supplier delivers)
▼
Goods receipt
│
▼
┌──────────────────┐
│ Supplier invoice│
│ 3-way match │
└────────┬─────────┘
│
▼
GL post + AP open
│
▼
Weekly pay run → bank file
Step detail:
- Demand origination. Two paths: MRP (overnight, see 7.3) generates purchase requisitions to cover net material shortages; manual entry by procurement for non-MRP demand (consumables, services, fixed-asset purchases).
- PO creation and approval. Journey C (§5.3) describes the PO lifecycle. Released POs are emailed PDF to supplier.
- Supplier confirmation. Supplier confirms by email or phone. Confirmation is captured in a free-text PO-line note; there is no structured “confirmed by supplier” status. [INT, R-09 in §11]
- Goods receipt. Journey D (§5.4) describes the receipt event. Inventory increments. PO-line status moves to
receivedwhen quantity is complete. - Supplier invoice processing. Journey E (§5.5) describes the three-way match. Cleanly matched invoices post to GL automatically; variance invoices route to period-close lead.
- GL posting. Invoice posts: debit expense (per item account on the PO line) or inventory (for stocked items), credit AP, debit VAT receivable.
- Payment. Weekly payment run, Fridays 14:00. Accountant selects invoices to pay (filter: due within next 10 days, not held). System generates bank-payment file (ABO format for primary bank, MultiCash for backups). Broker delivers via SFTP. Bank processes overnight.
- Bank confirmation. Following Monday morning, bank statement import reconciles the payments out; AP invoices move to
paid.
Cycle time for typical purchase: 5–14 days (delivery-dependent). Invoice-to-pay: 14–45 days (per supplier payment terms, plus weekly batch alignment).
Integration touchpoints: SMTP (PO out); SFTP (bank file out, statement in); ČNB customs portal (for non-EU import declarations, rare); EDI (none for purchasing in this customer).
7.3 Plan-to-make (P2M) — the overnight MRP
This is the system’s single most consequential batch process. It runs nightly at 22:45 and typically completes by 01:30.
┌──────────────────────────┐
│ 22:30 cut-off snapshot │ (all transactions of the day are frozen)
└────────────┬─────────────┘
│
▼
┌──────────────────────────┐
│ 22:45 Phase 1: │ Net requirements: customer orders + safety
│ net-requirements │ stock + forecast (where loaded) minus
│ │ available on-hand and on-order
└────────────┬─────────────┘
│
▼
┌──────────────────────────┐
│ 23:30 Phase 2: │ BOM explosion: for each manufactured-item
│ BOM explosion │ shortfall, generate component demand
│ │ recursively. ~5 explosion levels typical.
└────────────┬─────────────┘
│
▼
┌──────────────────────────┐
│ 00:45 Phase 3: │ Translate net requirements into suggested
│ suggestion generation │ planned-order rows: production for makes,
│ │ purchase requisition for buys.
└────────────┬─────────────┘
│
▼
┌──────────────────────────┐
│ 01:15 Phase 4: │ Capacity check: do planned production
│ capacity flagging │ orders fit available work-centre capacity?
│ │ Flag exceptions.
└────────────┬─────────────┘
│
▼
┌──────────────────────────┐
│ 01:30 Phase 5: │ Write planned_orders rows. Old planned-
│ commit │ order rows that were not released are
│ │ replaced (planning is "regenerative").
└──────────────────────────┘
Friction. The MRP is “regenerative” — each run discards last night’s unreleased planned orders and recomputes from scratch. This is the vendor default. The customer’s planner has occasionally lost track of overrides that were entered yesterday and discarded overnight. [INT]
Operating envelope. The 22:30–02:00 batch window is the operating envelope. If MRP runs past 02:00, downstream nightly exports (BI export, integration broker) start late and may not complete by their consumer’s expected time (BI dashboard 06:00 refresh, EDI partner #2 expects nightly file by 04:00). [DOC]
Failure mode. If MRP fails mid-phase, the database is left in an inconsistent state (planned-order rows partially written, capacity flags missing). Recovery is manual: a stored procedure sp_mrp_rollback exists but is brittle and last tested in 2020. [Sev-1, R-01 + R-11]
Workaround pattern. Twice in 2024 the MRP failed for non-recoverable reasons. The customer’s workaround was to revert the database to the pre-22:30 snapshot (a tail-of-log restore, ~90 minutes), then run the day forward without an MRP recompute. Planning operated on the previous day’s MRP for one working day. No production was lost, but the planner reports having to “trust gut” more than usual.
7.4 Record-to-report (R2R)
Period close. Journey F (§5.6) narrated the human cycle; this section describes the system’s batch and reporting actions.
The five-day close cycle’s batch components:
| Cycle day | Batch | Duration | What it does |
|---|---|---|---|
| D+1 | Inventory revaluation | ~45 min normal, ~2 h month-end | Re-applies standard cost to all open inventory; writes variance entries to GL. |
| D+1 | Cost rollup | ~30 min | Recalculates standard cost from current BOMs and routings. Writes new standards for next period. |
| D+1 | Sub-ledger reconciliation reports | ~20 min | Compares sub-ledger balances (inventory, AR, AP) to GL control accounts. Generates exception report. |
| D+3 | Statutory report generation | ~10 min | VAT report, intrastat report (if applicable), local statistical report. Crystal Reports output. |
| D+4 | Period archive + lock | ~5 min | Sets periods.status = 'closed'. Trigger on GL journal table henceforth rejects writes to this period. |
The standard-cost rollup is the single largest source of inter-period variance. Items whose BOM or routing has been edited during the period get new standards on D+1; the variance between old and new standard appears in the next period’s “purchase price variance” and “production variance” accounts. The cost accountant reviews these in D+3. [OBS, INT]
Statutory reports. VAT and intrastat are produced by Crystal Reports as PDF and XML respectively. The XML is uploaded manually to the relevant tax-authority portal by the accountant. There is no automated submission. [OBS]
7.5 What is not in MES-Plus’s process scope
For completeness, three business processes that cross MES-Plus but are not contained in it:
- Payroll cycle. Monthly. MES-Plus exports labour hours from production_events; payroll system imports CSV; payroll system pays bank.
- Customer onboarding (sales side). Lives in the sales director’s workbook until an order is taken; only then is the customer master record created in MES-Plus.
- Engineering change order. New product introduction, design changes. Performed in the engineering file share + a separate ECN tracker; results in a new or updated BOM/routing being entered into MES-Plus by an engineer at the end of the change cycle. The handoff is manual.
§12 modernisation considerations treats each of these as potential scope expansion or potential boundary clarification.