SAP SD

SD handles the full sales cycle: capturing sales orders, checking availability and pricing, creating deliveries and shipping goods, and billing customers. It manages customer master data, pricing, credit and output, ensuring orders are fulfilled and invoiced correctly.

• Sales Order: the central sales document.
• Pricing: determining prices, discounts and taxes.
• Delivery & Shipping: picking, packing, goods issue.
• Billing: creating invoices (posts to FI-AR).
• Credit Management & Output.

Everything in SD hangs off the sales area: a sales organisation, a distribution channel and a division. If you cannot name the sales area of a document you cannot explain its pricing, its partner determination or its output, because all three are configured per sales area.

The transactions run in threes, like the rest of SAP. A sales order is VA01, VA02 and VA03. A delivery is VL01N and VL02N, where picking and goods issue happen. Billing is VF01. Pricing condition records are maintained in VK11, and VA05 lists orders when you need to find one.

The tables repeat the header and item pattern: VBAK and VBAP for the order, LIKP and LIPS for the delivery, VBRK and VBRP for the invoice. The document flow that ties them together is VBFA, which is the table to read when someone asks what happened to an order.

This is the single most useful exercise in SD, and it takes about twenty minutes.

1. Create a standard order with VA01, order type OR, for a customer and a material that has stock. Watch the pricing tab populate itself: those values came from condition records, not from you.
2. Create the delivery with VL01N against the order. Pick the quantity, then post goods issue. Inventory falls and an accounting document appears, because stock leaving the building has a value.
3. Bill it with VF01. Revenue and receivables post to FI.
4. Go back to the order and open the document flow. Order, delivery, goods issue, invoice, accounting document, in one screen.

If the order will not deliver, the reason is nearly always availability, a delivery block or a credit block, and the document flow tells you which.

SD is the heart of order-to-cash: goods issue reduces inventory (MM) and posts to FI, and billing posts revenue to FI accounts receivable. It integrates with MM (stock/availability), PP (make-to-order), and CO (profitability), and is a common specialisation.

The integration people underestimate is the material master. A material that is not extended to the sales organisation cannot be sold, no matter how much stock sits in the plant, and the error message does not say so plainly. See SAP MM for how the views are maintained and SAP QM for what an inspection lot does to a delivery.

• How the pricing procedure is built. Condition types, access sequences and the order they are evaluated in decide every price on every order. This is the part of SD worth learning properly, because almost every change request touches it.
• Which availability check. The classic ATP check answers whether stock exists. Advanced ATP adds rules for who gets it when there is not enough, which matters the moment supply is short.
• Where credit management sits. Blocking an order for credit protects the business and stops a shipment, so someone must own releasing the block.
• Copy control. What flows from order to delivery to invoice is configuration. When a field mysteriously does not reach the invoice, copy control is where it stopped.

More SD questions are about pricing than about everything else combined, so it is worth understanding the machinery rather than the screen.

A condition type is one element of a price: a base price, a discount, a freight charge, a tax. The pricing procedure lists the condition types in the order they are applied and says which are added, which are subtotals and which are statistical. Each condition type has an access sequence, an ordered list of places to look for a record, from the most specific to the most general: this customer and this material, then this customer group, then the material alone.

Condition records are the actual numbers, maintained with VK11. The system walks the access sequence for each condition type, takes the first record it finds, and stops.

That is why the analysis function on the order's pricing tab is the tool to reach for. It lists every condition type, every access it tried, and the reason each one failed. Nine times out of ten the answer is that the record exists at a level the access sequence never looks at.

Returns and credit memos run the same machinery in reverse, with their own document types and their own copy control, which is why a return that prices differently from the original order is usually a copy control question rather than a pricing one.

Learn SD by following its end-to-end process, its master data, its configuration (in SPRO), and its integration points with finance and neighbouring modules. Hands-on practice in a training system is essential.

This is the most common support call in SD, and there are only a few real causes. Work through them in this order and you will find it every time.

Availability. Open the order and run the availability check. If the confirmed quantity is zero, the stock is not there, or it is there but committed to an earlier order. The check is a promise, not a reservation, until the delivery exists.

A delivery block. Blocks sit at header or item level and can come from the order type, the customer, or a manual entry. The header status screen shows them.

A credit block. The order exists, the stock exists, and credit management has stopped it. Releasing that is a finance decision rather than a sales one, which is why it needs an owner in the business.

Incomplete data. The incompletion log lists what the document is missing, and a document that is incomplete will not move to the next step no matter what else is right.

The shipping point could not be determined. That is configuration, derived from the shipping conditions, the loading group and the plant, and it fails quietly on new material or plant combinations.

• Learning screens, not the end-to-end process.
• Ignoring the finance integration that every logistics module has.
• Skipping master-data setup that the process depends on.

• Blaming pricing when the access sequence never found a record. Use the analysis on the pricing tab: it shows every condition type it tried and why each one missed.
• Incomplete partner functions on the customer. A missing ship-to stops a delivery, and the message points at the document rather than the master data.
• Learning VA01 without the sales area behind it. The screen is easy and the configuration underneath it is the job.

SD kept its transactions and lost some of its tables. Pricing conditions moved from KONV to PRCD_ELEMENTS, so older reports and queries that read KONV directly have to be rewritten. Customers are Business Partners, maintained with BP rather than XD01. Advanced ATP replaced the older availability check in new builds, and the classic SD credit management was superseded by FSCM credit management.

Running the cycle is the easy half, and building the pricing procedure that made those numbers appear is the part you do in the course.