SAP Sales orders

A sales order records what the customer wants: items, quantities, prices, delivery dates and terms. On creation it triggers availability checking (can we deliver?), pricing (what does it cost?), and credit checking, then becomes the reference for the subsequent delivery and billing documents.

• Order type (standard, rush, returns, etc.) controls behaviour.
• Item categories control how each line behaves.
• Schedule lines: quantities and delivery dates.
• Pricing, availability (ATP) and credit checks.

The header and item distinction matters here as elsewhere. Payment terms, the sold-to party and the order reason live on the header. Material, quantity, plant, item category and the confirmed schedule live on the item. A change made at header level generally propagates to items that have not been changed individually, and that asymmetry explains why an update sometimes reaches only some lines.

Most of a sales order is determined rather than entered, and knowing what determines what turns the document from a form into something diagnosable.

The order type is chosen, and everything follows from it plus the sales area. It decides the number range, which item categories are allowed, whether pricing is carried out, and which delivery and billing types come next.

The item category is determined from the order type, the material's item category group, and the usage. It decides whether the item is relevant for delivery, for pricing, and for billing. A free-of-charge item and a standard item differ almost entirely in their item category.

Schedule line category follows from the item category and the material's MRP type, and it decides whether an availability check and a requirement transfer happen at all.

Partners are determined from the customer master through a partner determination procedure: sold-to, ship-to, bill-to, payer. A missing partner function is a common reason an order cannot proceed.

Pricing, output and text are all determined by the same condition technique, each with its own procedure.

The practical consequence: when an order behaves unexpectedly, the question is which determination produced that value, and the analysis functions on the document will tell you.

Twenty minutes, and it turns the list above into something you can see.

1. Create a standard order with VA01 for a customer and a material with stock.
2. On the item, check the item category. You did not type it; it was determined.
3. Open the schedule line. There is a confirmed quantity and date from the availability check, and a schedule line category deciding whether that check ran.
4. Look at the partners tab. Ship-to and bill-to were pulled from the customer master.
5. Open the pricing analysis on the conditions tab and read which condition records were found.
6. Now create an order for a material with no stock. The confirmed date moves out, and the schedule line shows why.

Six checks, and between them they explain almost any order that behaves oddly.

The sales order kicks off order-to-cash: it leads to a delivery (goods issue reducing MM stock and posting COGS to FI) and a billing document (posting revenue and AR in FI). For make-to-order it can trigger production (PP). It is the connective tissue between the customer and fulfilment.

The order also creates a requirement, which is what makes it visible to planning. That requirement is why an order for an unstocked material can trigger production or purchasing, and it is transferred according to the schedule line category. Turn the transfer off and planning never learns about the demand. See production orders for what happens when the material is made rather than bought.

• How many order types. Standard, rush, returns, credit memo request, free of charge. Each is a real difference in process; creating one per department is not.
• Whether availability is checked. Checking gives realistic promises and refuses to confirm what does not exist. Not checking accepts everything and disappoints later.
• Where blocks apply. Delivery and billing blocks on the order type give an approval step before fulfilment or invoicing.
• Contract and scheduling agreement use. Repeated business against an agreement rather than standalone orders, which changes pricing and release behaviour.

Standard orders are the majority and the variants are where the process differences live.

A rush order creates the delivery immediately on saving, for a customer collecting now. A cash sale goes further, billing at the same time, which suits a counter sale.

A free of charge delivery ships goods with no invoice, for a sample or a replacement, and its item category makes it irrelevant for pricing and billing.

A returns order starts the reverse flow, creating a return delivery that puts stock back and then a credit.

A credit memo request and a debit memo request adjust value with no goods movement at all. Both are typically created with a billing block so somebody approves before the customer's account changes.

A consignment fill-up moves stock to the customer's site while it remains yours, and a consignment issue bills it when they use it.

A quotation and a contract sit before the order: a quotation is an offer with a validity, a contract is an agreement that orders are released against.

Each is the same document structure with different configuration, which is why learning one order type properly makes the rest quick.

An order for stock that exists is uninteresting. The behaviour when it does not is where the configuration shows.

The availability check runs at order entry and produces a confirmed quantity and date. What it considers is a checking rule: current stock, plus purchase orders and production orders arriving, minus what is already committed. Which of those are included is configurable, and a business that includes planned orders is promising against something not yet ordered.

Partial confirmation splits the schedule line: some now, the rest when supply arrives. Full delivery customers refuse that, so nothing confirms until everything can.

Backorder processing and rescheduling revisit confirmations periodically as supply changes, and they can move stock from one order to another. That is intended behaviour and it surprises salespeople who believed a confirmation was a reservation.

Advanced ATP adds explicit rules for scarcity: priorities, allocation quantities per customer group, and substitution. Where supply is regularly short, the difference between advanced ATP and the classic check is the difference between a policy and an accident of processing order.

• Wrong order/item category, wrong process behaviour.
• Ignoring availability/credit checks.
• Pricing errors flowing to billing.

• Reading the confirmed quantity as reserved stock. It is a promise, and another order can consume the stock first.
• Changing an order after delivery has started. The delivery holds its own quantities, and the two can diverge.
• Blaming pricing before opening the analysis. See returns and credit management for the two processes that most often interrupt an order.

• Creating an order type per department. Order types should reflect genuine process differences; everything else is a reason to use a different customer or a different item category.
• Availability checking switched off to stop orders being refused. The orders are then all confirmable and none of the dates mean anything.

Creating an order is the easy half, and configuring order types, item categories and determination so the document behaves correctly is the part you do in the course.

The habit worth building is reading the item category and the schedule line category on any order that behaves unexpectedly. Between them they decide whether the item delivers, prices, bills and creates a requirement, and they were determined rather than typed.