SAP Modules overview

A module is not a separate product you install. It is a functional area inside one SAP system, with its own configuration, its own master data and its own transactions, sharing a single database and a single set of organisational units with every other area. When people say a company "runs MM and FI", they mean the same system is configured for procurement and for accounting, and that the two are wired together.

This matters for how you learn. A module boundary tells you which tables and transactions belong together, but it does not stop a business process. Buying something touches procurement, inventory and accounting in one document flow, and nobody in the business thinks of that as three systems.

These are the areas most projects start with, and the ones most jobs are advertised against.

• FI (Financial Accounting) and CO (Controlling), the finance backbone. FI is the external, statutory view: the general ledger, payables, receivables and assets. CO is the internal view: cost centres, internal orders and profitability. Every other module eventually posts here. See SAP FI.
• MM (Materials Management), procurement and inventory: purchase requisitions, purchase orders, goods receipts and invoice verification. See SAP MM.
• SD (Sales and Distribution), selling and delivering: enquiries, quotations, sales orders, deliveries and billing.
• PP (Production Planning), what gets made and when: bills of material, routings, planned orders and production orders. See SAP PP.
• QM (Quality Management), inspection lots and quality notifications, usually triggered by a goods receipt or a production confirmation.
• PM (Plant Maintenance), keeping equipment running: functional locations, equipment records and maintenance orders. See SAP PM.
• WM and EWM, warehouse management at two levels of sophistication, from simple storage bins up to a full warehouse execution system.

• HCM / SuccessFactors, human resources. HCM is the classic on-premise personnel administration and payroll. SuccessFactors is the cloud suite SAP now leads with, and many landscapes run SuccessFactors for talent while payroll stays where it is.
• CRM / SRM / Ariba, customer and supplier relationships and procurement. The classic on-premise CRM and SRM have largely given way to cloud products, with Ariba carrying sourcing and supplier collaboration.
• IBP, supply-chain planning, the cloud successor to the planning half of APO.

• BW / BPC, data warehousing and planning/consolidation.
• GRC / MDG, governance-risk-compliance and master-data governance. MDG is worth knowing early even if you never specialise in it, because it is the answer to "who is allowed to create this master record", and see SAP MDG.
• PS, CS, RE-FX, projects, customer service, real estate.

Three places, and knowing them is most of what separates someone who has read about SAP from someone who has used it.

Configuration lives in the IMG, reached with transaction SPRO, then SAP Reference IMG. The tree there is organised by module, so the MM settings sit under Materials Management and the FI settings under Financial Accounting. Configuration is made in the development client and transported, never typed straight into production.

Transactions follow a naming habit that is worth learning. The MM material master is MM01 to create, MM02 to change and MM03 to display. A purchase order is ME21N, ME22N and ME23N. A sales order is VA01, VA02 and VA03. Once you notice the pattern you can guess half the transactions you need.

Data lives in tables you can read with SE16N, and the names repeat the same header and item idea. Material master general data is in MARA and its plant level data in MARC. A purchase order is EKKO for the header and EKPO for the items. A sales order is VBAK and VBAP. An accounting document is BKPF and BSEG.

This is the exercise that makes integration concrete, and you can run all of it on a practice system in about twenty minutes. Nothing here is theoretical: it is the same document flow a real procurement process produces.

1. Create a material with MM01. Choose a trading goods type, give it a plant and a storage location, and fill the Basic Data, Purchasing and Accounting views. You have just written rows into MARA and MARC.
2. Raise a purchase order for it with ME21N, against any vendor, one line, quantity ten. That is EKKO and EKPO. No accounting document exists yet, and that surprises people: ordering something is a commitment, not a posting.
3. Receive the goods with MIGO, movement type 101, referencing the purchase order. Now inventory rises and an accounting document appears, because stock has value.
4. Post the vendor invoice with MIRO. The three-way match happens here: order, receipt, invoice. If they agree the document posts, and if they do not it blocks for payment.
5. Open the accounting document with FB03 and read the lines. You configured nothing in FI, and yet FI has a complete record of the transaction.

Step five is the point of the exercise. The MM consultant did the work and the FI consultant owns the result, which is why the two argue about account determination.

The decision that matters early is not which module is most interesting, it is which one your next employer is hiring for. A few things to weigh honestly.

• Do you want to talk to the business or to the system? FI, CO, MM and SD are conversations with accountants, buyers and sales operations. Basis and ABAP are conversations with the system. Both pay, and they suit different people.
• Is your background already an advantage? An accountant moving into FI, or a production planner moving into PP, starts several months ahead and should not throw that away.
• How wide is the market? FI and MM appear on nearly every project, so there is always work, and there is also more competition. PM, QM and RE-FX are narrower, and a scarce skill is often better paid than a common one.
• What will you meet anyway? Whatever you choose, you will meet finance, because every module posts there in the end.

Every module here has its own page. Everything integrates through finance and shared master data, which is SAP’s core strength. Pick one module to specialise in, but understand its neighbours, because real processes cross module boundaries.

• Trying to learn all modules instead of specialising. Breadth is worth having and it is not what gets you hired.
• Ignoring cross-module integration. Most production incidents live at a boundary, not inside one module, and the person who can read a document flow across two areas is the person who resolves them.
• Overlooking the FI/CO backbone every module posts to.
• Learning transactions without organisational structure. If you cannot say which company code, plant and purchasing organisation a document belongs to, you cannot explain why a posting went where it did, and account determination will stay guesswork.
• Assuming an ECC screenshot is current. Several transactions people still teach were replaced in S/4HANA, and turning up to an interview describing the old one is a bad first impression.

Module names largely survived the move to S/4HANA. The tables underneath them did not, and three changes come up constantly.

• Finance was consolidated into the Universal Journal, table ACDOCA, which merged what had been separate FI and CO line-item tables. Reconciliation between the two stopped being a monthly exercise because there is now one set of lines.
• Customers and vendors became Business Partners. The old XD01 and XK01 masters were replaced by transaction BP, with a single partner carrying customer and supplier roles.
• Inventory documents moved to MATDOC, replacing the older header and item pair for material documents.

If a tutorial shows you XD01 on a system described as S/4HANA, it was written for ECC and not checked.

Picking the module is the easy half, and configuring one end to end in a live system is the part you do in the course.