SAP Mass Purchase Order Creation with ME21N

Choosing the grouping

How you group items into orders is a commercial decision disguised as a technical one. One order per vendor per plant is the common default and produces manageable documents. One order per requirement produces a large number of small orders, which suppliers dislike and which multiplies release strategy events. One giant order per vendor is efficient to raise and painful to amend later.

Ask procurement what they want before deciding. The grouping is visible to the supplier and difficult to change once the orders are out.

The fields you have to map

Vendor and purchasing organisation

The vendor must exist, must not be blocked for purchasing, and must be linked to the purchasing organisation on the row. That last condition catches files built against a vendor list from another entity. The vendor master guide covers creating the purchasing segment that makes this work.

Document type

Document type drives the number range, the field selection and, in many configurations, the release strategy. Standard orders, framework orders and transport orders behave differently. Using the wrong type is not usually an error; it produces orders in the wrong number range with the wrong approval path, which is discovered later and cannot be corrected by changing a field.

Net price, and where it comes from

This is the field that most distinguishes purchase order loads from other mass work. A PO price can come from three places: an info record, a contract or scheduling agreement, or the file itself.

Supplying the price in the file is straightforward and overrides determination. It is right when the price is genuinely known and agreed for this order. It is wrong when a contract exists, because the order then carries a price that does not match the agreement and nobody notices until invoice matching fails.

Leaving the price blank lets SAP determine it, which is right when info records or contracts are properly maintained and produces error ME 083 when they are not. On a large file, the pattern of ME 083 errors is a useful map of where your info record coverage has gaps.

Account assignment: four categories, four different sheets

The account assignment category decides where the cost lands and which extra columns your file needs. It is the single largest structural variable in a PO file.

Blank means stock. The material goes into inventory, is valued on the material master, and needs no cost object. This is the simplest file shape and the one most planning-driven orders use.

K means cost centre. The item is consumed on receipt and expensed. The file needs a cost centre column, populated on every K row. This is most consumable and indirect buying.

F means internal order. Cost collects on an order, typically for events, campaigns or maintenance work. The file needs the order number.

P means WBS element. Cost capitalises to a project. The file needs the WBS element, and project structures change, so validation against the live project is worth more here than elsewhere.

A file spanning several categories needs every category's columns present, populated only on the rows that use them. This is fine and normal, and it makes visual review harder, which is an argument for splitting large mixed files by category.

Release strategy: what happens when four hundred orders need approving

Most organisations put purchase orders through a release strategy, and mass creation interacts with it in ways that surprise people the first time.

Orders created through the standard interface are subject to the same release strategy as orders created in ME21N. The strategy is determined per order from its characteristics, usually value, document type, purchasing group and plant. Four hundred orders therefore generate up to four hundred release events, all landing in someone's inbox at once.

Three consequences worth planning for:

• The approver needs warning. A release queue that normally receives ten items a day receiving four hundred at nine in the morning is a process failure even though the load worked perfectly.
• Grouping changes the value bands. Because strategy is usually value-driven, how you group items into orders determines which approval level each order hits. Many small orders may all fall below a threshold that one combined order would have exceeded, which is a governance question, not an optimisation.
• Unreleased orders do nothing. They exist, they consume nothing, and they do not transmit to the supplier. A load that finishes with four hundred unreleased orders has not achieved what the business asked for, so releasing is part of the plan rather than someone else's problem.

The eight stages of a controlled ME21N run

Validation: six checks before a single order is raised

Two of these are worth expanding.

Material extended to plant is the same condition described in the material master guide, seen from the other side. A material with no purchasing view in the plant cannot be ordered there. On a file covering a new site, this failure will hit most rows, and the fix is a material extension run that has to happen first.

Delivery date valid catches more than past dates. Dates outside the factory calendar, dates before the planned delivery time allows, and dates that fall in a plant shutdown all cause problems, some as errors and some as silently rescheduled deliveries.

Errors, and what they are telling you

ME 021, the blocked vendor, deserves a specific note. A purchasing block is set deliberately, usually because of a quality issue, a commercial dispute or a compliance concern. It is the one error in this guide where the right response is almost never to remove the obstacle. Take the row out of the run and ask why the block is there.

Running the whole sequence inside Excel

Orders, requisitions, and agreements

The choice between these three is really a question about how settled the sourcing decision is.

Raise orders when the vendor and price are agreed. This is the case for call-offs against contracts, seasonal buys at negotiated prices, and planning output that has already been sourced.

Raise requisitions when demand is known and sourcing is not. Requisitions commit nothing externally, go through their own release process, and are converted to orders once a vendor is chosen. Mass requisition creation is lower risk than mass order creation for exactly this reason.

Create agreements when the relationship is ongoing and the quantities are not yet known. The agreement fixes terms; releases against it become the volume work.

What the orders trigger downstream

A purchase order is the start of a chain, and mass creation puts volume into every link of it.

• Release strategy. Immediate, and covered above.
• Output determination. Released orders transmit to suppliers by print, email or EDI. Four hundred transmissions at once is a moment worth telling suppliers about, particularly where one vendor receives many.
• MRP. Orders appear as firm receipts and change what the next planning run proposes. Raising orders that duplicate existing coverage produces excess supply that nobody notices until stock arrives.
• Goods receipt. Deliveries against these orders arrive later, and where volume is high, receipting becomes its own mass task. The MIGO guide covers that side.
• Invoice verification. Supplier invoices will match against these orders. Prices that were overridden in the file are where three-way match failures come from. See the MIRO guide.
• Commitment accounting. Where active, the orders consume budget on creation, so a large run can exhaust a budget before anything is received.

None of this argues against mass creation. It argues for telling the people downstream that it is happening.

Amending and cancelling at volume

Purchase orders are amendable, which makes them more forgiving than financial documents and less forgiving than master data.

An order that has not been released can be changed freely. Once released, changes may reset the release depending on configuration, which sends it back through approval. Once a goods receipt or invoice exists against a line, the options narrow considerably.

For a mass run this produces a clear practical rule: find mistakes before release, not after. The window between creation and release is when correction is cheap. That is another reason to check a sample in ME23N rather than trusting the log, and to keep runs small enough that a full review before release is realistic.

Deletion is a flag on the item rather than a removal, so a wrongly created order leaves a visible trace whatever you do. Cancelling four hundred orders is a tidier outcome than amending them, but neither is invisible, which is the strongest argument for testing properly first.

Item categories: when the order is not a simple buy

Account assignment decides where the cost lands. Item category decides what kind of transaction the line actually is, and it changes the columns your file needs just as much.

• Standard (blank). Buy a material from a vendor, receive it, pay for it. Most rows in most files.
• Subcontracting (L). You send components to the vendor, they return a finished item. The order needs a component list, and the components have to be provided or the receipt fails. A subcontracting row in a file of standard rows is a common cause of a run that mostly works.
• Consignment (K). Stock sits at your site owned by the vendor until consumed. No invoice on receipt, and valuation works differently. Files mixing consignment and standard lines need the distinction explicit.
• Third-party (S). The vendor ships directly to your customer. The order links to a sales order and the goods never reach your plant.
• Text item (blank material). No material number, so the file must carry a description, a material group and an account assignment. These are the rows that fail validation when a template assumes a material is always present.

The practical guidance is to split by item category rather than mixing. Each category needs different columns populated, and a single file trying to serve all of them becomes wide, sparse and hard for anyone to review. Splitting also means a failure in the subcontracting rows does not stop the standard buy.

Source determination, info records, and where the vendor comes from

Every purchase order needs a vendor, but not every requirements file carries one. Where the vendor is absent, SAP can determine it from source lists, quota arrangements and outline agreements, which is a genuine convenience and a source of surprises at volume.

Supplying the vendor explicitly is the predictable option. The order goes to the vendor named in the file, and if that vendor is wrong it is wrong visibly. This is the right choice for most mass runs, because a reviewer can check the file before anything is raised.

Letting SAP determine the source works well where source lists are properly maintained and produces unpredictable results where they are not. On a large run, source determination can spread orders across vendors in a pattern nobody intended, particularly where quota arrangements are active and the quota is consumed unevenly by the run itself.

The related question is the info record. An info record holds the price and conditions for a material and vendor combination, and it is what makes price determination work. Two things about them matter for mass creation:

• Missing info records surface as ME 083. The pattern of those errors across a file tells you exactly which material and vendor combinations are undocumented, which is useful information in its own right.
• Info records can be created from the order. Where configuration permits, raising an order with a price updates or creates the info record. On a mass run this quietly writes hundreds of info records, which may or may not be what procurement wants. Check the setting before a large first run.

Governance, approval, and commitment

• Approve the file, not the orders. The reviewable artefact is the requirements list: vendors, quantities, prices, total value. Approving that before the run is more meaningful than approving four hundred documents afterwards.
• Show the total. Whoever signs off should see what the run commits in aggregate. This is the number that matters and it is invisible when orders are raised one at a time.
• Run as a named user. The orders carry the identity and purchasing authorisations of the person who ran them.
• Never engineer the grouping around thresholds. Worth repeating because the temptation is real under deadline pressure.
• Tell the approver before, not after. A release queue that receives a warning is a process; one that does not is an incident.
• Keep the completed file. Requirements, PO numbers and values in one artefact is the record of what was committed and why.

Volume, batching, and timing

• Runtime tracks orders, not rows. Two thousand items forming four hundred orders makes four hundred calls. Consolidating items into fewer orders is faster and produces larger documents.
• Batch by vendor or plant. A failed batch should be describable in one sentence, and both boundaries keep failure modes homogeneous.
• Avoid running during MRP. Orders created mid-planning-run produce a supply picture that is briefly inconsistent, and diagnosing that wastes an afternoon.
• Mind the period. Where commitment accounting is active, the posting period affects which budget is consumed.
• Stagger transmission. Where output goes by EDI to one vendor, four hundred simultaneous messages may be unwelcome at their end.

From a one-off run to a repeatable buy

• Save the mapping with the grouping rule. How items become orders is the decision that took the thinking.
• Ship a template to the requesters. If planning or the project team submits requirements with material, plant, quantity, date and account assignment already correct, the run is a formality.
• Encode the account assignment logic. Which buying type uses which category, and which cost object column it needs.
• Record the document types proven against. Along with their release strategies, so nobody assumes a template covers a case it has never met.
• Name an owner. Document types, release strategies and purchasing organisations all change.

Common mistakes and how to avoid them

• Header fields disagreeing within a group. Two vendors under one PO reference produces an ambiguous order and a confusing failure.
• Overriding a price where a contract exists. The order no longer matches the agreement, and invoice matching fails later.
• Forgetting that release strategy will fire. Four hundred approvals landing unannounced is a process failure even when the load succeeded.
• Missing cost objects on assigned rows. Every K, F and P row needs its object. Blank rows for stock are correct; blank rows for K are not.
• Ordering materials not extended to the plant. An MM02 extension run has to happen first.
• Working around a blocked vendor. The block exists for a reason. Take the row out and ask.
• Raising orders when sourcing is not settled. Requisitions exist precisely for that case and commit nothing.
• Treating the run as finished at creation. Unreleased orders do nothing at all.

After the orders are raised

The run is not finished at creation. Four things close the gap between orders existing and procurement working.

Review before release. This is the last cheap moment. Open a sample in ME23N and check the price, the account assignment, the delivery date and which release strategy was determined. A file that passed validation can still have produced orders nobody wants.

Release, and watch the queue. Someone has to approve them. Whether that is one person clicking through four hundred items or a collective release depends on your configuration, and finding out during the run is too late.

Confirm transmission. Released orders go out by print, email or EDI. Check that they did, particularly where one vendor receives many and their systems may throttle.

Hand the numbers back. Whoever supplied the requirements needs the PO numbers written against their rows, so the planning system, project or requesting team can track receipts.

The complete ME21N mass creation reference

The reference sheet below collects everything above into one image you can share before a buying run.

Go deeper

Frequently asked questions