Platform · Modules

The modules behind
the processes.

A module is a participant, not a destination. MM, SD, PP, QM, FI, FA, PS, HRMS, the Vendor Portal and Plant Maintenance are the ten building blocks of Compreo — but no one runs a business by opening a module and staring at it. They earn their keep inside the processes that cross them: a requisition that becomes a PO, a GRN that posts to the ledger, a project that bills on progress. Business buyers navigate by process; IT and architects navigate by module. This page is the map for both.

Two readings, one platform

Two ways to read
the same platform.

Walk into most ERP evaluations and the conversation splits in two. The plant head and the finance controller want to know whether Procure-to-Pay or Record-to-Report will actually run end to end. The IT architect and the systems integrator want to know which modules exist, what objects they own, and where the integration seams are. Both questions are fair, and they describe the same system from opposite ends.

One design, two entry points

Compreo answers both with one design. The processes are the spine — eight cross-functional flows that carry work from the team that starts it to the team that closes it. The modules below are the participants in those flows: each one owns its master data and its transactions, and each one shows up in several processes rather than living in a silo of its own.

Read this index as a module catalogue if that is your job; follow the “Powers these processes” column if it is not.

The catalogue

The ten modules.

Each module owns its master data and its transactions — and shows up in several processes rather than living in a silo. Follow the last column to see where each one participates.

Module Code What it does Powers these processes
Materials Management MM Owns the material master, vendors, PR, RFQ, PO, GRN and stock. The intake side of the business — what you need, who supplies it, what arrived, what's on hand. Procure-to-Pay · Plan-to-Produce · Plan-to-Maintain
Sales & Distribution SD Owns the customer master, enquiries, quotations, sales orders, dispatch and billing. The outbound side — demand in, goods and invoices out. Order-to-Cash · Project-to-Cash
Production Planning PP Owns the BOM, routing, work orders and shop-floor execution across process, discrete and repetitive manufacturing. Turns a plan into output. Plan-to-Produce
Quality Management QM Owns inspection plans, quality gates and certificates of analysis at GRN, in-process and pre-dispatch. Decides what is accepted before it becomes stock. Procure-to-Pay · Plan-to-Produce · Order-to-Cash
Financial Accounting FI Owns the GL, accounts payable, accounts receivable, taxes and the close. The book of record every other module posts into. Record-to-Report · Procure-to-Pay · Order-to-Cash
Fixed Assets FA Owns the asset register, capitalisation, depreciation, transfers and retirement. Tracks what the capital became after it was bought. Acquire-to-Retire · Record-to-Report
Project System PS Owns the WBS, BOQ, project budgets, project procurement and progress billing. The structure that ties spend and revenue to a plan. Project-to-Cash · Procure-to-Pay
Human Resources HRMS Owns the employee master, attendance, leave, payroll and approval delegation. Keeps the people side — and the approvers — current. Hire-to-Retire · delegation across all processes
Vendor Portal VP Gives suppliers a self-service window: respond to RFQ, see PO and GRN status, submit invoices and track payment. Moves the conversation out of email. Procure-to-Pay
Plant Maintenance PM Owns equipment, maintenance plans, breakdown and preventive work orders, and the spares those orders consume. Keeps assets running and links wear to cost. Plan-to-Maintain · Acquire-to-Retire
No module works alone

How the modules
cooperate.

The point of one platform is that a module never works alone. A 3-way match is the cleanest example: MM holds the PO and the GRN, QM decides whether the receipt is accepted, and FI posts the invoice — and the match either reconciles on UOM and quantity or it doesn't, with no spreadsheet in between. When PS runs a project, it draws MM for site procurement, FA when capital is capitalised, and SD when the project bills.

Because every module shares the same master data and the same approval engine, HRMS quietly governs all of them: when an approver is on leave, delegation flows to the right person in every process at once, so a PR or an invoice does not stall waiting on someone who isn't there. That cooperation is the difference between modules that integrate and modules that were never separate.

01

MM

PO and GRN raised against stock or a project.

02

QM

Receipt inspected and accepted before it becomes stock.

03

FI

Invoice matched and posted to the same ledger.

POGRNQCMATCHPOST
By design

What this design avoids.

When the modules were never separate, three familiar failure modes simply have nowhere to live.

No reconciliation between systems

When MM, QM and FI are one platform, the GRN and the invoice meet on the same record. There is nothing to export, match and argue about between a procurement tool and a finance tool.

No module left guessing

PP plans against the same stock MM owns; PS bills against the same costs FI booked. One source of truth means no module is working off a stale copy of another module's data.

No silo for the people side

HRMS isn't a separate HR product bolted on — it supplies the approvers, the delegation and the org structure that every other process relies on to move.

FAQ

Common questions.

You can start where the pain is and switch on modules as you grow, but they are not separate products stitched together. Every module shares one data model and one approval engine from day one, so adding FA or Plant Maintenance later doesn't mean a new integration project.

Because the 3-way match, the project close and the asset register all post into the same GL here. Keeping FI inside the platform is what removes the reconciliation step between procurement, projects and the book of record.

Yes — suppliers get their own self-service window onto the same RFQ, PO and GRN records your team works on, so status and invoices live in one place instead of email threads.

It owns the approvers and the delegation. When someone is on leave, every process — a PR in MM, an invoice in FI — routes to their delegate automatically, so approvals don't break when people do.

Platform · Modules

See the modules running as one process.

Tell us the flow that hurts most and we'll show you which modules participate — on your data, not a demo dataset.