SAP Plant

A plant might be a factory, a warehouse, a distribution center or a regional operation. It is the level at which materials are planned, procured, produced and stored, and it is assigned to a company code so its activities post to the right legal entity.

• Material requirements planning (MRP) runs per plant.
• Inventory is managed within a plant (and its storage locations).
• Production and procurement are organised around plants.
• Many material-master views are maintained per plant.

The plant is the most widely used organisational unit in logistics, and tracing where it shows up explains why getting it wrong is expensive.

On the material master, as the level at which MRP type, procurement type, purchasing group and valuation are held. The same material can be made at one plant and bought at another.

On a purchase order line, deciding where goods are received and which company code the posting belongs to. Nobody types the company code; the plant supplies it.

On a sales order line, as the delivering plant, which decides where availability is checked and where stock leaves from.

On a production order, since the bill of material, routing and work centres are all per plant.

On every stock figure, because inventory is held at plant and storage location level.

The assignment that carries the most weight is plant to company code. It is what makes a goods movement post to the right set of books, and it is why a plant assigned wrongly produces perfectly valid documents in the wrong entity's accounts. Changing it after go-live is a data migration rather than a configuration change.

Two other assignments matter almost as much: plant to purchasing organisation, which decides who may buy for it, and plant to sales organisation and distribution channel, which decides whether it can deliver.

Twenty minutes, and it makes an abstract unit concrete.

1. Open a material with MM03 and note that it asks for a plant before showing purchasing or MRP data.
2. Look up which company code that plant is assigned to, in the enterprise structure configuration.
3. Post a goods receipt for that material and open the accounting document. It posted to that company code, and you never entered one.
4. Try to create a purchase order for a plant not assigned to your purchasing organisation. It is refused, naming the combination.
5. Check MMBE. Stock is shown per plant and storage location, not as one company-wide figure.

Step three is the point worth internalising: the plant is how logistics tells finance whose books to use. See SAP master data for the level structure this mirrors.

Almost every logistics report is filtered or grouped by plant, and that is not a reporting convention, it is a consequence of the master data. Stock quantities, requirement dates, purchasing values and production quantities are all stored against a plant, so the plant is the natural grain of the data.

The practical effect is that a plant which was created badly produces reports nobody can use. Two examples worth recognising.

One plant standing for several physical sites. Stock reports show a single availability figure across locations that are two hundred kilometres apart, so the number is true and useless. The business then rebuilds the split in a spreadsheet, using storage location as a proxy for site, which works until somebody moves stock between them.

Several plants standing for one site. Now every internal movement is a stock transfer between plants, which generates documents, needs a delivery in some configurations, and makes the site look busier than it is. Each transfer is real work for somebody.

Both are recoverable in the sense that the system keeps working, and neither is recoverable in the sense that you can quietly change it later. Merging or splitting plants on a live system means moving stock, reassigning materials, reworking purchasing documents and re-pointing every report that names them. This is why plant design gets a workshop and not a decision in passing.

When you are asked to review an existing design, the useful question is not whether it follows a rule. It is whether anybody has to correct the system's answers by hand before using them. That is where a bad plant structure shows.

The plant links logistics to finance: goods movements in a plant post to the assigned company code. It also links to sales (as a delivering plant) and production. This cross-module role makes the plant one of the most-referenced organizational units.

It also sits underneath valuation. The valuation area is normally the plant, which means the same material can carry a different price at two sites, and account determination reads the material's valuation class in that plant to choose the general ledger account. So a plant is not only where goods are, it is where they are worth something. See ERP fundamentals for where this sits among the other units.

Version note: this has not changed in shape between ECC and S/4HANA. What changed is where the data sits. In S/4HANA the material valuation and stock tables were consolidated, so several of the old totals tables no longer hold data, and reports written against them return nothing. The plant field, the assignments and the meaning are the same. See S/4HANA versus ECC.

A plant is subdivided into storage locations, distinct areas holding stock. Together, plant and storage location pinpoint where inventory physically sits.

The distinction worth holding: storage locations track where stock is and carry no valuation of their own. Value lives at plant level. That is why moving stock between storage locations in one plant creates a material document and no accounting document, and moving it between plants creates both.

Worth stating the boundary clearly, because it decides a lot of design arguments. Availability is checked at plant level in the standard case, so moving stock between storage locations inside a plant does not change what the system says you can promise. If two areas genuinely need separate availability, they need separate plants, and the cost of that is everything in the previous section. If they only need to be distinguished for putaway and counting, storage locations are correct and cheap.

• How many plants per site. One is normal. Several at one location means somebody wanted separate valuation or separate MRP, and each one multiplies the material master extensions required.
• Whether a distribution centre is a plant. If it holds stock and that stock has value there, it is.
• Valuation at plant or company code level. Plant level is the common choice and allows site-specific prices.
• How many storage locations. Enough to find things, few enough that people are not transferring all day. See number ranges for the naming that goes with this.

• Confusing plant (logistics) with company code (legal).
• Forgetting plant-specific material views, needed to use a material there.
• Poor plant design that does not match physical operations.

• Creating plants for reporting. Reporting dimensions belong in profit centres, not in the enterprise structure, and a plant carries master data extensions forever.
• Forgetting to extend materials to a new plant. The plant exists and nothing can be transacted in it.
• Assuming stock is company-wide. See the fiscal year for another structural setting decided once.

Recognising the unit is straightforward, and designing a plant structure that survives a decade of change is the part you do in the course.