Each task gives you the explanation (what you're doing), the exact action (the field and the value), an enrichment (the why behind it), and the expected result to check against. Work them in order in the practice system, and tick each result as it lands.
Open the app where every sales order begins.
ActionThis is the SAP Fiori app for creating sales orders — the modern successor to the classic VA01 transaction. Same job, current interface.
Expected resultTell SAP what kind of order this is, and which part of the business is selling.
ActionOR, sales organisation 1010, distribution channel 10 and division 00, then choose Continue.A sales area is the combination of sales organisation, distribution channel and division. It defines which customers, materials and pricing this part of the business is responsible for — so it sets the rules for everything that follows.
Expected resultTell SAP who this order is for.
Action10100001 and press Enter on the keyboard.The Sold-To party is the customer we receive the PO from. On pressing Enter, the Ship-To party is auto-populated, along with the customer's relevant details — name, address, customer group, shipping condition and Incoterms — all drawn from the customer master data in the system.
Expected resultCapture the customer's own order number so both sides can trace it.
ActionPO1111 (the customer's purchase-order number).This stores the customer's own PO number against your sales order, so that months later either side can find this exact order in a single search.
Expected resultAdd what the customer actually wants.
ActionTG11 and in the Order Quantity field enter 5 PC.The material number pulls the item's description from the material master. The net price is not taken from the material master — SAP determines it through the condition technique: it picks the pricing procedure (from the sales area, sales document type and the customer), then the access sequence searches the condition tables for the valid condition record and copies that price into the order.
Expected resultSee the free-goods deal apply automatically — then handle it with the customer.
ActionFree goods are determined automatically. When the order quantity meets the free-goods condition record, SAP adds a dependent, free-of-charge item in real time — no one keys it in, the system applies the deal.
In practice · the real-world bitSAP does the maths; you manage the customer. Verify the free line is there and matches the promotion you're aware of, and let the customer know they're receiving it — confirm they'll accept it. If a free line is missing where you'd expect one, or the quantity looks wrong, escalate rather than save.
Expected resultCommit the order to the system.
ActionSaving writes the order to the database — the promise becomes real and traceable, and the warehouse can now see it. The confirmation dialog is a final "are you sure?", not an error.
Expected resultSee what your order set in motion.
ActionYour order is step one of a chain — delivery, picking, goods issue, billing. Reading the flow shows the whole downstream journey a single sales order sets in motion.
Expected resultThe clean run above is the happy path. Real orders bend at three points, where SAP makes a check and you handle what it finds. This is where the job actually lives.
Before you promise a date, SAP checks whether stock can meet it.
Enrichment · the SAP mechanicThe system runs an availability check (ATP) in the plant, using advanced functions like product allocation and supply protection. It returns one of three answers.
If SAP can only meet a later date, communicate that proposed date to the customer before you commit — don't let them discover it from a late delivery. The date is SAP's; managing the expectation is yours.
Zero stock doesn't always mean "no" — it depends whether the customer can be backordered.
Enrichment · the SAP mechanicIf the customer is eligible for backorders, a pop-up (custom backorder check) prompts for input and the line can be processed as a backorder. If the customer is not eligible, the line is automatically rejected with a suitable reason (custom rejection handler).
Ask the customer whether they'll accept a backorder before committing them to one. If they're not eligible and the line is rejected, explain why and offer an alternative — a substitute, a partial, a different date — not a flat "no".
Before the order completes, SAP checks the customer's credit.
Enrichment · the SAP mechanicThe system runs a credit check in the background, based on the customer's credit history and risk group. The order is either clear or blocked for credit.
A credit block isn't yours to override. Inform the customer their order is on credit hold, and contact Credit Control to run the analysis and decide whether the limit can be raised. You're the bridge between the customer and Credit Control — keep both moving.
When you save, SAP checks the order has everything the downstream process needs.
Enrichment · the SAP mechanicOn save, SAP runs an incompletion check on the key fields delivery and billing depend on — pricing, payment terms, mandatory master data. If anything essential is missing, the order is flagged incomplete — and an incomplete order can stall the downstream chain: no confirmation, no delivery, no billing, until someone resolves it.
Don't leave it stuck. If the missing field is yours, complete it now; if it isn't (a pricing condition, a credit term), escalate to the owning team — an incomplete order helps nobody, least of all the customer waiting on it.
You took one customer request all the way to a saved sales order — eight tasks on the happy path, four decision points where SAP checks and you handle what it finds. When you can run this without the enrichment notes, you've got it.