SAP Order to Cash (SD Full Cycle) – Realistic Hands‑On Tutorial with Real Company Data & FI Integration | Part 05 | FreeLearning365

 

SAP Order to Cash (SD Full Cycle) – Realistic Hands‑On Tutorial with Real Company Data & FI Integration


SAP Order to Cash (SD Full Cycle) – Realistic Hands‑On Tutorial with Real Company Data & FI Integration

Welcome to the real Order to Cash. This is not a summary of T‑codes or a one‑page cheat sheet. This is the end‑to‑end walkthrough I wish someone had handed me when I was a fresher staring at a blank SAP client, wondering why my invoice didn’t post to FI. We’ll build everything from scratch – master data, sales order, delivery, picking, goods issue, billing, and the exact accounting entries that hit the general ledger. You will see not just what happens, but why it happens, and where the money lives. By the time you finish, you’ll be able to run a complete O2C cycle in any IDES or sandbox system and explain it to a CFO.

We’ll use a fictional company, GlobalTech Innovations (Company Code 1000), a mid‑sized distributor of IT hardware and networking gear. Our sales organisation is 1000 – Domestic Sales, distribution channel 10 – Wholesale, division 00 – General. The customer is TechMart Retail (Customer 100001), and the material we sell is MAT‑IT‑001 – ProSwitch 24‑Port Gigabit Switch. Every number you see is real, every screen is real. You can replicate this in your own SAP system right now.

Let’s stop learning SAP like a video game and start thinking like a consultant.

1. The Order to Cash Mindset

Order to Cash (O2C) is the heartbeat of any business. It’s the process from the moment a customer raises a purchase order to the moment the cash hits your bank account. In SAP, it spans Sales & Distribution (SD), Materials Management (MM), and Financial Accounting (FI). If you master O2C, you can trace a single transaction from a sales order right down to a profit‑and‑loss report. That’s power.

An SAP consultant never just “creates a sales order”. You must always ask:

  • What are the customer’s payment terms and credit limit?
  • Is the material available in stock, or do we need a purchase order to a vendor?
  • Which tax jurisdiction applies? Are we registering the correct tax code?
  • When we bill, which GL account will be credited for revenue? What about the cost of goods sold?
  • If the customer disputes the invoice, how do we reverse or credit memo it?

We’ll answer all of that by doing, not reading.

2. Master Data – The Backbone of Every O2C Transaction

Before you can type VA01, you must have the following master data in place. Skip even one record, and SAP will throw a hard error. I’ll list exactly what you need, and you’ll see how each piece is used later.

2.1 Customer Master (Transaction FD01 / XD01)

Create customer 100001 – TechMart Retail in company code 1000, sales area 1000/10/00.

  • General Data: Name 1 = TechMart Retail, Search term = TECHRETAIL
  • Address: Street = 45 Market Street, City = Bangalore, Country = IN, Region = KA
  • Control Data: Authorization group – blank, VAT registration number = 29AADCT1234P1Z9
  • Company Code Data (FI view): Reconciliation account = 140000 (Domestic Receivables), Payment terms = 0002 (within 14 days 2% discount, net 30 days), Tolerance group – blank, Sort key = 001
  • Sales Area Data (Sales view): Sales office = 1000, Sales group = 100, Customer group = 01, Currency = INR, Pricing procedure = RVA001 (standard), Customer pricing procedure = 1, Delivery priority = 02, Shipping conditions = 01 (as soon as possible), Delivering plant = 1100, Tax classification: Tax category IN = 1 (Taxable), Tax code default = X1 (Output tax 18%)

Consultant Tip: Never leave the tax classification empty, otherwise the system cannot determine the tax code during billing. A missing tax code means the invoice won’t post to FI, and your accountant will chase you with a real‑world stick.

2.2 Material Master (Transaction MM01)

Create material MAT‑IT‑001. Use Industry sector “M – Mechanical engineering” (we’ll keep it simple).

  • Basic Data 1: Description = ProSwitch 24‑Port Gigabit Switch, Base Unit of Measure = PC (pieces), Material Group = 001, Division = 00
  • Sales: Sales Org 1 view: Sales unit = PC, Delivering plant = 1100, Tax classification: Tax category IN = 1 (full rate), Account assignment group (Material Account Assignment Group) = 01 (Trading goods)
  • Sales: Sales Org 2 view: Item category group = NORM (Standard item), Material pricing group = 01
  • Accounting 1 view: Valuation class = 7920 (Finished goods – trading), Price control = S (Standard price), Standard price = 8,500.00 INR, Moving average price = 8,500.00
  • Plant Data / Stor. 1 (Plant 1100): Storage location = 0001 (Raw Material 1? We’ll use finished goods loc), we’ll later create a storage location FG01. Make sure the material is extended to plant 1100 and storage location 0001 initially. We will transfer to FG01.

We’ll define the condition records later, but the material must exist.

2.3 Condition Master – Pricing (Transaction VK11)

The system needs to know how much we are selling the switch for. Create condition record for condition type PR00 (Price).

  • Key combination: Customer/Material – we’ll use a customer‑specific price. Access sequence PR00 – standard. In VK11, select PR00, then choose key combination “Customer/Material”. Enter Customer 100001, Material MAT‑IT‑001, Sales Org 1000, Distribution Channel 10. Enter validity, e.g., from today to 31.12.9999. Amount = 10,000.00 INR per PC. Currency INR, per 1 unit.
  • Also create a freight condition HD00 (Freight) or use standard condition type KF00. For simplicity, we’ll use condition type FRA1 (Freight – percentage). In VK11, choose FRA1, key combination “Customer/Material/Destination Country/Region”. Enter Customer 100001, Material MAT‑IT‑001, Country IN, Region KA. Amount = 2% (percentage of net price). This will add 2% freight surcharge.

Next, tax condition records. For Indian taxation, standard condition type MWST (Output Tax) uses condition table with tax code. In VK11, choose MWST, key combination “Country/State/Customer Tax class/Material Tax class”. Country IN, Region KA, Tax class customer = 1, Tax class material = 1. Validity, amount rate = 18% (for output tax). Ensure condition record exists. If you use a different tax procedure, the condition type might be JIN1 or JIN2, but standard IDES often uses MWST with tax code. Adjust accordingly. The concept is what matters.

2.4 Customer‑Material Info Record (Transaction VD51)

This is one of the most overlooked yet powerful records. It tells SAP what the customer’s part number is, what unit they order in, and even default delivery plant. Create for Customer 100001, Material MAT‑IT‑001, Sales Org 1000, Dist Channel 10.

  • Customer Material = “CUST-PART-888” (their part number)
  • Unit of measure for the customer = PC (pieces)
  • Delivery plant = 1100
  • Default order quantity = 10 (optional)

Now when you enter sales order, you can use both our material number and the customer’s part number. Super handy for EDI.

3. Sales Order Creation – The Moment the Business Commits

You’ve got master data. Time to create a real sales order. In a typical distribution scenario, a buyer from TechMart sends a purchase order to GlobalTech. Let’s simulate that.

3.1 The Customer’s Purchase Order (PO)

TechMart Retail Purchase Order No: TM-PO-2401, dated 15th May 2026. They order 20 units of ProSwitch at agreed price 10,000 INR each, plus freight 2%, with delivery to their warehouse at 45 Market Street, Bangalore. Payment terms net 30 days.

3.2 Create Sales Order: VA01

Go to transaction VA01. Enter Order Type = OR (Standard Order), Sales Organization = 1000, Distribution Channel = 10, Division = 00. Press Enter.

In the overview screen, fill:

  • Sold‑to party: 100001
  • Ship‑to party: same (100001)
  • PO Number: TM-PO-2401, PO date: 15.05.2026
  • Requested delivery date: 20.05.2026
  • Header pricing date: 15.05.2026
  • Currency: INR

Press Enter. The system will perform an automatic partner determination, picking up the ship‑to and bill‑to from the customer master. Next, in the item overview:

  • Material: MAT‑IT‑001
  • Order Quantity: 20 PC
  • Plant: 1100
  • Storage Location: FG01 (we’ll set up FG01 later, for now use 0001; we’ll correct after goods receipt from production if needed. For trading goods it’s fine.)

Press Enter again. Now watch the magic.

SAP will call the pricing procedure. It looks up condition records we created:

  • PR00 pulls 10,000 INR/PC → total 200,000 INR
  • FRA1 applies 2% on 200,000 = 4,000 INR
  • Net value = 204,000 INR
  • Then tax MWST calculates 18% on 204,000 = 36,720 INR (assuming tax base includes freight; check your tax procedure). In standard RVA001 with tax code X1, the base is net value, so output tax = 36,720 INR.
  • Total invoice value = 240,720 INR.

You can see the pricing condition lines by selecting the item and going to Extras → Pricing. It will show the condition types, amounts, and a subtotal for net and tax. This is where real‑world customisation matters: you might need a separate condition type for freight that is taxable. We’ll revisit pricing later.

3.3 Availability Check and Credit Block

Once you press Save, the system performs a few background checks:

  • Availability check (ATP): If you have defined checking group 02 (individual requirements) for the material, SAP will look at the available stock in plant 1100. Suppose we have 15 pieces in unrestricted stock. The system can confirm 15 pieces and place the remaining 5 as a planned requirement. In VA01, you’ll see the confirmed quantity column. If you haven’t set up ATP, the order will confirm the full quantity with zero stock – dangerous! We’ll later do a goods receipt to build stock.
  • Credit check: If credit management is active (transaction OVA8), the system compares the open order value + existing receivables against the customer’s credit limit. For customer 100001, let’s set credit limit 500,000 INR. The sales order value 240,720 INR is within limit, so no block. If it exceeded, the order would be blocked for credit and you’d need VKM1/VKM3 to release.

Let’s assume all checks pass. Save the order. System generates internal document number, e.g., 10000001. Write it down – it’s the thread that ties the whole flow together.

3.4 Document Flow and Output

Immediately, the system can trigger an order confirmation output (like an email). Output determination is configured in NACE (transaction VV31 for output conditions). For output type BA00 (Order Confirmation), we may have a condition record. Let’s assume it’s set to send a PDF via email. The sales order document flow (transaction VA03) shows “Sales Order 10000001”. No other documents yet.

Hands‑on Exercise: In your sandbox, create sales order 10000001 with the data above. Practice changing the pricing manually by selecting the item, going to Conditions, and inserting a discount condition type (e.g., K004) of 5%. Watch the net value drop. This is how you simulate real‑life negotiations.

4. Delivery Processing – From Warehouse Promise to Packed Goods

Now the warehouse needs to fulfil the order. The delivery document is the bridge between sales and inventory management. We’ll create the delivery with reference to the sales order.

4.1 Create Outbound Delivery: VL01N

Use transaction VL01N. Enter Shipping point: we need to configure a shipping point, say 1000 (Plant 1100’s shipping point). For standard, use the same as plant. Enter selection date (today), and order number 10000001. Press Enter.

If the material is not fully confirmed due to stock shortage, you may see partial delivery. Assuming stock is available (we will manually add stock via MIGO later), we can deliver 20 pieces. The delivery copy controls bring in the order quantity and schedule lines. Check the item: delivery quantity 20 PC, storage location FG01. You can perform picking here.

Before saving, go to Subsequent Functions → Picking. If you use WM, you’d create a transfer order. For simple IM, you can set the picked quantity equal to delivery quantity, and the system automatically determines the storage bin (we’ll set up storage location FG01 with bin “DYNAMIC”). Use transaction LT01 or VL02N to pick after delivery creation. We’ll do picking after delivery creation to simulate warehouse steps.

Save the delivery. System generates document number, e.g., 80000001.

4.2 Picking and Goods Issue (VL02N)

Now warehouse picks the goods. In VL02N, open delivery 80000001. Go to Subsequent Functions → Picking. In the picking screen, you can confirm the picked quantity 20 PC. The system will propose a storage location and bin. You can manually enter storage location FG01, and bin “A-01-01” (a shelf). Confirm picking. Save. The material document for picking reduces the unrestricted-use stock of the storage location and moves it to “picked” status in IM. However, the goods are not yet issued from the company’s book.

After picking, we post Goods Issue (GI). In the same VL02N, click on Post Goods Issue (traffic light icon). The system will now perform the material movement 601 (GI for delivery). This reduces inventory and updates the General Ledger: debit Cost of Goods Sold (COGS) and credit Inventory. The accounting entry will be recorded automatically through account determination. Let’s see the exact FI postings when we do billing. But before that, save the goods issue. Delivery status becomes “C” (completed).

Real‑life scenario: Suppose the picker finds one unit damaged. They can enter picked quantity 19, and the delivery becomes partial. The remaining 1 unit will stay open, and later you can create a subsequent delivery for the backorder. You can handle partial deliveries directly in VL02N by adjusting the picked quantity before GI. This is a common day‑to‑day activity in any warehouse.

5. Billing – The Invoice That Triggers Revenue

With goods issued, it’s time to send the invoice. Billing is the SD document that connects to Financial Accounting. We’ll create the invoice with reference to the delivery.

5.1 Create Billing Document: VF01

Transaction VF01. Enter the delivery document 80000001. The system proposes billing type F2 (Invoice). Check the billing date, document date, and pricing date. The pricing is copied from the sales order, but you can also trigger a re‑determination. In standard, the copy control from delivery to billing takes the pricing from the order. The net value should be 204,000 INR, tax 36,720 INR, total 240,720 INR.

Review the billing item. If you want to correct pricing, you can go to item conditions and adjust. For our scenario, it’s correct. Save the billing document. System generates number, e.g., 90000001.

Now the magic: SAP posts an FI document automatically. Let’s view it.

5.2 Accounting Document from Billing

Go to VF02, open billing document 90000001, and follow menu Environment → Acc. Document. It will show FI document number, say 100000000. Alternatively, use transaction FB03 with that number. The journal entry looks like this (simplified, based on account determination):

  • Debit: Customer (Reconciliation account) 140000 = 240,720 INR (the total invoice amount)
  • Credit: Domestic Sales Revenue (GL 800000) = 200,000 INR (net sales value excluding freight, or including freight depending on config)
  • Credit: Freight Revenue (GL 810000) = 4,000 INR (if freight mapped to separate revenue account)
  • Credit: Output Tax Payable (GL 220000) = 36,720 INR

Additionally, the goods issue already posted a COGS entry when we did GI: Debit COGS (GL 620000) 20 units x standard cost 8,500 = 170,000 INR, Credit Inventory (GL 140000? no, Inventory account). Let’s check the material document from GI. Use MB51 for material MAT‑IT‑001, movement type 601, and see the FI document: Dr COGS 170,000, Cr Inventory 140000 (say GL 140000 is Finished Goods Inventory). So the full profit impact is already reflected.

Wait – why does the sales order value not directly hit COGS? Because COGS is based on inventory valuation, not sales price. That’s why you see two separate P&L impacts: revenue from billing, COGS from goods issue. The gross profit is 200,000 (revenue) – 170,000 (COGS) = 30,000 INR (plus freight revenue). This is the essence of how SAP separates value flows.

6. Payment Posting and Clearing the Customer

TechMart Retail makes a bank transfer of the full amount 240,720 INR on 30th May 2026. We’ll post the incoming payment and clear the open item.

6.1 Post Incoming Payment: F-28

Transaction F-28. Enter document date 30.05.2026, company code 1000, posting key 40 (debit bank), bank account GL 113100, amount 240,720. Open item selection: select the open item from invoice 90000001. If you have payment term discount, and they pay within 14 days, you could use F-28 with discount. Let’s assume they pay after discount period, no discount. Save. The system clears the customer open item and debits bank.

Now run FBL5N for customer 100001. You’ll see the invoice item cleared, balance zero. The O2C cycle is complete.

7. Deep Dive: Pricing Procedure Demystified

You just saw pricing in action. Now let’s understand how SAP pulls that 2% freight and 18% tax without you doing anything. This is the condition technique, the brain of pricing, output, and account determination.

7.1 The Building Blocks

  • Condition Table: Defines the fields used for accessing a record, e.g., “Customer / Material”.
  • Access Sequence: A search strategy that tries one condition table after another until a valid record is found. For PR00, it might first try “Customer/Material”, then “Customer discount group”, then “Material price group”.
  • Condition Type: Represents a pricing element, e.g., PR00, K004, MWST. It links to an access sequence.
  • Condition Record: The actual data that says “Customer 100001 gets 10,000 INR for material MAT‑IT‑001”.
  • Pricing Procedure: A step‑by‑step list of condition types, subtotals, and requirements that dictate the order and calculation. Standard procedure RVA001 is used for domestic sales.

7.2 Tracing the Calculation

In our sales order, pricing procedure RVA001 contains:

  • Step 10: PR00 – Price (condition type) – statistical? No, carries value.
  • Step 20: FRA1 – Freight percentage (we added).
  • Step 130: MWST – Output tax (condition type, subtotal ‘Net value’).

The system calculates step 10, gets 200,000. Step 20, based on net value from step 10, adds 2% (4,000). Net value = 204,000. Step 130 takes the net value (including freight if base is set to net) and multiplies by tax rate 18%. That’s why you saw tax on freight. To change tax base, you modify the “From” and “To” reference steps in the procedure’s control data for the tax condition type. This is where real customizing happens. You can even add a pricing condition for packaging, discount, surcharge, or rebate.

7.3 Hands‑on Customising (if you have SPRO access)

Go to SPRO → Sales and Distribution → Basic Functions → Pricing → Pricing Control → Define Condition Tables. You can create a table with fields like “Customer Group” and “Material Pricing Group” to give volume discounts. Then build an access sequence, assign the table, and create condition records in VK11. This is what separates a power user from a consultant.

8. Tax Determination – Getting the Right Tax Code Every Time

In our example, we used tax code X1 with 18%. But how does SAP know to use X1? Through the customer and material tax classifications and the tax procedure assigned to the country.

In SPRO, under “Taxes on Sales/Purchases”, you define tax codes and link them to condition types. The standard tax procedure TAXINN (for India) or TAXINJ might be in place. The system checks the customer’s tax classification (1 = taxable) and material’s tax classification (1 = full rate) against condition records for tax code X1. If you had an export customer, you’d set them as tax class 0 (exempt) and create condition record with tax code X0 (0% tax). This drives the correct output tax.

Common pitfall: Forgetting to extend the tax condition record for a new plant or sales org. Then billing fails to determine tax, and the FI document is incomplete. Always test billing for every combination.

9. Account Determination – The Invisible Hand That Posts to the Right GL

How does SAP know that for material MAT‑IT‑001, revenue should go to GL 800000 and COGS to GL 620000? This is Account Determination, configurable via transaction VKOA (or SPRO path). The key master data fields involved:

  • Chart of accounts (INT1)
  • Sales organization (1000)
  • Account assignment group for customer (from customer master sales view, e.g., 01 – Domestic)
  • Account assignment group for material (from material master sales view, e.g., 01 – Trading goods)
  • Account key (e.g., ERL – Revenue, ERF – Freight revenue, MWS – Tax)

In OB40 (or VKOA), you maintain condition records that map these combinations to GL accounts. For GlobalTech, we configured:

  • Chart INT1, Sales Org 1000, Cust. Acct. Ass. Grp 01, Material Acct. Ass. Grp 01, Acct Key ERL → GL 800000
  • Same combination, Acct Key ERF → GL 810000
  • Tax codes mapping via OB40: tax code X1 with account key MWS → GL 220000

When billing runs, the system reads the billing item, determines these keys from the sales doc type, item category, and master data, then posts to the accounts. Similarly, for GI (movement type 601), the automatic account determination in MM (OBYC) uses valuation class (7920) and account grouping for movement type to post to COGS and Inventory. In our case, BSX (inventory posting) for valuation class 7920 points to FG inventory GL 140000, and GBB (COGS offset) with account grouping AUF (for trading goods) points to COGS GL 620000. This interconnectedness is why an SD consultant must understand MM and FI integration.

10. Full Scenario 1: Standard Domestic Sale with Stock

Let’s re‑run the entire O2C with all steps logged, like a console output, for clarity. (Scenario name: Scen‑01 – Standard Domestic Sale)

Step 0 – Precondition: Initial stock of MAT‑IT‑001 in plant 1100, storage location FG01: 30 PC (you can post via MIGO 501). Customer credit limit 500,000 INR.

Step 1 – Sales Order VA01: OR, customer 100001, material MAT‑IT‑001, quantity 20 PC, plant 1100. Pricing: PR00=10,000, FRA1=2%, tax 18%. Total 240,720 INR. ATP confirms 20 PC. Save → SO #10000011.

Step 2 – Delivery VL01N: With reference to SO #10000011, shipping point 1000. Delivery quantity 20 PC. Save → delivery #80000011.

Step 3 – Pick & Goods Issue VL02N: Picking confirm 20 PC from FG01. Post GI → movement 601. MM document 4900000011, FI document 120000001 (Dr COGS 170,000, Cr Inventory 170,000). Delivery status C.

Step 4 – Billing VF01: With ref. to delivery #80000011. Invoice F2 #90000011. FI document 130000001. Entry: Dr Customer 240,720, Cr Sales 200,000, Cr Freight revenue 4,000, Cr Output tax 36,720.

Step 5 – Payment F-28: Post incoming payment 240,720 against invoice. Customer cleared.

11. Full Scenario 2: Third‑Party Order (Drop‑Ship) – Where SD meets MM

Now let’s spice it up. GlobalTech doesn’t stock all materials. For a high‑end router MAT‑IT‑002, we use a third‑party vendor. The customer orders the router, we place a purchase order to the vendor who ships directly to the customer. Our profit is the margin. This is the third‑party order process.

Master Data: Create material MAT‑IT‑002, item category group BANS (third‑party item) in sales views. In purchasing view, define a valid vendor 200001 (TechSupply Inc.) and info record. Pricing condition for PR00 at 25,000 INR. No stock needed.

Sales order type OR will automatically determine item category TAS (third‑party) for this material. Let’s walk through.

Step 1 – Sales Order VA01: Customer 100001, material MAT‑IT‑002, qty 5 PC. The system sets item category TAS. Pricing: PR00 = 25,000 each, total net 125,000, plus freight (if applicable), tax 18% = 22,500, total 147,500. The procurement indicator is set. Upon saving, a purchase requisition (PR) is automatically created with account assignment ‘Sales order item’. You can see it in document flow or via ME51N with reference.

Step 2 – Convert PR to PO (ME21N): Using the PR, create PO to vendor 200001, net price 18,000 INR (our cost). Item category standard, account assignment category ‘S’ (third‑party). Indicate delivery address as customer’s ship‑to. Save PO #4500000011.

Step 3 – Goods Receipt and Vendor Invoice (MIGO, MIRO): When vendor ships to customer, they send an invoice to us. We post GR in MIGO for PO without moving stock (movement type 101 with account assignment). This does not affect our inventory; it posts COGS directly (Dr COGS 90,000, Cr Vendor 90,000). Then MIRO to enter vendor invoice for the same amount.

Step 4 – Billing to Customer: Now we create the invoice to customer based on the sales order. Since no delivery is involved, we create billing via VF01 directly referencing the sales order. The billing quantity is 5 PC, revenue 125,000, tax 22,500. The revenue and COGS are matched in the same period, giving us a clean gross margin of 35,000 INR.

That’s the power of third‑party processing – no touch of physical inventory, just pure financial orchestration.

12. Full Scenario 3: Intercompany Sale – Selling Between Two Company Codes

GlobalTech also sells from company code 1000 (India) to an overseas subsidiary, company code 2000 (Germany). We have a customer 200001 (GlobalTech GmbH) in sales area 1000/10/00. When we ship goods from India plant to Germany, it’s an intercompany sale that involves two sets of books. SD handles the external sales invoice, while an internal billing document (IV) transfers revenue and cost between company codes.

Simplified walkthrough:

  • Create a sales order of type OR for customer 200001 with material MAT‑IT‑001, plant 1100. The item category is standard NORM, but in the billing plan we might need intercompany billing.
  • Goods issue in India: movement 601. COGS hits company 1000 books.
  • Create external billing to customer 200001 in INR or EUR (depending on pricing). Let’s assume invoice value 250,000 INR.
  • The system also generates an intercompany billing document (type IV) between company codes, costing to 2000 and revenue to 1000, using separate account determination. This posts Dr Intercompany Receivables 250,000 Cr Intercompany Revenue 250,000 in company 1000, and opposite entries in company 2000.
  • Finally, payment from 200001 clears the external receivable.

While detailed IMG for intercompany setup is a session on its own, it’s crucial to know the flow exists and is driven by the sales organization’s company code and the delivering plant’s company code. If they differ, intercompany billing is triggered. This protects each legal entity’s P&L.

13. Integration Checkpoints – Where SD Shakes Hands with MM and FI

As you’ve seen, O2C is not a solo act. Here are the exact integration points you must memorize:

  • SD → MM: Delivery (goods issue) triggers material movement 601, which updates stock and creates an MM document. The movement type determines the COGS account through OBYC.
  • SD → MM (Purchasing): Third‑party order creates purchase requisition and subsequent PO.
  • SD → FI: Billing posts customer invoice, revenue, and tax. Account determination (VKOA) maps the revenue and tax accounts.
  • SD → CO‑PA: Billing document passes characteristic values (customer, material, etc.) to Profitability Analysis (if active), enabling margin reporting.
  • MM → FI: Goods receipt (for third‑party) or goods issue posts to FI via OBYC.
  • FI ↔ SD: Credit management (FD32, OVA8) reads open AR and open orders from SD and FI, blocking sales orders if limit exceeded.

14. Troubleshooting Common O2C Issues

Real life isn’t as smooth as the demo. Here are the top five head‑scratchers and their fixes:

  1. No pricing determined in VA01: Check condition records in VK11 for PR00 – maybe the validity date is expired or material pricing group missing. Also check the pricing procedure assignment to sales area. Verify customer pricing procedure and document pricing procedure match.
  2. Delivery not created, error “No schedule lines due for delivery”: The sales order item has a schedule line with a confirmed date in the past and delivery block. Run V_V2 (backorder processing) or check the item category’s delivery relevance. Also ensure the shipping point is correctly determined.
  3. Billing document saves but no FI document: This usually means the account determination failed. In VF02, check the log. It will say “Account key XXX not defined”. Go to VKOA and maintain the missing record for that combination. Or tax code determination missing.
  4. Credit check blocks the order, but you can’t release: Use VKM1 to view blocked documents, then release with VKM3 (if authorization). Adjust credit limit in FD32.
  5. Goods issue fails with “Deficit of stock”: Check stock overview in MMBE. If stock insufficient, post a goods receipt via MIGO 501, or change the delivery quantity to match available stock.

15. Consultant Wisdom – Best Practices and Pitfalls

Having implemented O2C in multiple industries, here’s what I’ve learned:

  • Always walk through the full cycle with the finance team before go‑live. Their GL account expectations might differ. A wrongly assigned revenue account can cause a month‑end nightmare.
  • Document your condition technique changes. A seemingly innocent new condition type can break the entire pricing procedure if the step number collision isn’t managed. Use condition type ranges and maintain an Excel mapping.
  • Master data governance is non‑negotiable. A missing customer‑material info record won’t stop VA01, but it can cause EDI failures. Create checklists for data migration.
  • Tax configuration is country‑specific. Don’t copy‑paste from one project to another. Always engage a local tax expert and test with a sample of real customer and material tax classes.
  • Use output determination to automate communication. Sending order confirmations and invoices automatically saves dozens of hours a week.
  • Watch out for pricing copy control. If you reprice at billing, the invoice might differ from the order, which causes customer disputes. Decide once.

16. Interactive “Try It Now” Checklist

Open your SAP GUI and follow this checklist to internalise the O2C flow:

  1. Create your customer (XD01) with payment terms 0002, reconciliation account 140000, tax classification 1.
  2. Create material (MM01) with sales views, accounting, and tax classification 1. Post initial stock using MIGO (movement 561).
  3. Create condition records: PR00 with amount 10,000 INR, FRA1 2%, MWST 18% with tax code X1 for country IN.
  4. VA01 – create OR, see pricing. Save.
  5. VL01N – create delivery, pick, GI. Observe material document.
  6. VF01 – create billing. Check FI document in VF02.
  7. F-28 – post payment, clear customer.
  8. Optionally, try a third‑party order: change material item category group to BANS, create customer‑material info record for third‑party material. Follow the PR/PO flow.
  9. Celebrate – you just touched SD, MM, and FI in one sitting.

17. Closing Thoughts – From Process to Profit

Order to Cash is where business value meets system configuration. If you can sit with a business owner and map their order‑to‑cash process onto SAP, and then build it in the sandbox, you’re not just a module consultant – you’re a solutions architect. This article has given you the real data, the real transactions, and the real troubleshooting. Your next step is to take this scenario, change the company, add consignment processing, or integrate with a CRM, and make it your own. The knowledge compounds.

Stay tuned for the next part in the series: Procure to Pay (MM full cycle) – where we’ll buy those switches from our vendor and watch the other side of the money.

Happy learning, and remember: a consultant who understands the business process will always be more valuable than one who only knows T‑codes.

– FreeLearning365, in tech partnership with @techbook24

Post a Comment

0 Comments