SAP Library / SD / O2C / Cheat sheet
SAP SD / O2C cheat sheet
28 objects in 3 groups. Each links to its full reviewed page.
T-Codes14
- VA01VA01 is the SAP transaction used to create a sales document — most often a standard sales order. You supply the order type and the sales area (sales organisation, distribution channel, division), then the sold-to party, materials and quantities. Saving writes the header, items and schedule lines and returns the sales document number.
- VA02VA02 is the change transaction for an existing sales document. You open the order by number and adjust quantities, dates, partners, rejection reasons or conditions within what configuration and authorisation allow. The document is updated in place, so planning, the delivery due list, credit exposure and the document flow all react to what you save.
- VA03VA03 opens a sales document in display mode. Nothing can be changed, which makes it the safe transaction for support, audit and analysis work: you read header and item data, conditions, schedule lines, partners, status information and the document flow that shows which deliveries and invoices already exist for the order.
- VL01NVL01N creates an outbound delivery for a sales document. It is the shipping step of order-to-cash: the delivery collects the items that are due, carries picking and packing quantities, and becomes the document that posts goods issue. Which items can be delivered depends on dates, availability, blocks and delivery-relevant configuration.
- VL02NVL02N is used to change outbound deliveries, perform picking-related updates, packing information and post goods issue where permitted. It is most useful when a delivery needs operational completion or correction before billing. Work from the exact document, organizational level and business date, then verify downstream status or accounting evidence before changing master data or configuration.
- VL03NVL03N is the display-only transaction for an outbound delivery document. It shows header and item data, shipping point, picking and packing status, goods movement status, and document flow, but it cannot change anything. Consultants use it to read the current state of a delivery when diagnosing stuck goods issue, blocked billing, or quantity discrepancies against the sales order.
- VF01VF01 creates a billing document from a reference such as an outbound delivery or a sales order. It is the invoicing step of order-to-cash: quantities and conditions are copied by copy control, the document is priced, and posting it releases the values to accounting where receivables and revenue are recognised.
- VF02VF02 is used to change permitted billing-document header or output-related fields and handle certain release/correction actions after billing creation. It is most useful when a billing document exists but permitted attributes or accounting-release issues require follow-up without recreating the invoice. Work from the exact document, organizational level and business date, then verify downstream status or accounting evidence before changing master data or configuration.
- VF03VF03 displays a posted billing document (invoice, credit memo, debit memo, or cancellation) in read-only mode, showing header and item data, pricing conditions as they were determined at billing time, the accounting document status, and the document flow back to delivery and order. It cannot change anything; VF02 is the transaction for permitted changes.
- VK11VK11 creates a new pricing condition record (a price, discount, surcharge, or freight rate) for a condition type such as PR00 or K004. It writes the value into the condition table generated for the chosen key combination, plus the header and item condition tables. Existing sales documents are unaffected until pricing is re-run manually.
- VK12VK12 is the SD transaction used to change existing pricing condition records - prices, discounts, surcharges, freight - for a condition type and key combination that was already created via VK11. It cannot create a new key combination; if the exact combination does not already exist as a record, VK12 returns an empty list rather than letting the user add one.
- VK13VK13 displays existing pricing condition records (prices, discounts, surcharges, freight) for a chosen condition type and key combination, such as customer/material or price list. It is read-only; VK11 creates and VK12 changes. The main source of confusion is that a condition type can have records stored under several different key combinations at once, so checking the wrong one gives a false 'no record found' result even though a price exists.
- VKOAVKOA configures revenue account determination for SD billing. SAP derives the G/L account from configured key combinations such as chart of accounts, sales organization, customer and material account-assignment groups, and account key. When postings hit the wrong account, first prove which determination key was used before changing the configuration.
- V/08V/08 is used to configure the sequence of pricing condition types, subtotals, requirements, formulas and account keys in an SD pricing procedure. It is most useful when designing pricing or diagnosing why a condition is mandatory, statistical, excluded or posted differently. Start from the exact business object, organizational scope and status, then prove the result through document flow, logs or master data before applying a corrective action.
Key Tables8
- VBAKVBAK stores one row per sales document header (order, quotation, contract, scheduling agreement) keyed by VBELN. It holds organizational data (sales org, channel, division), document type, currency, net value, and the pricing document number. It does not store the customer directly; sold-to and ship-to come from VBPA. Item detail lives in VBAP, status in VBUK.
- VBAPVBAP stores one row per sales document item, meaning one material or service line inside an inquiry, quotation, order, contract, or scheduling agreement. It holds the item category, plant, quantity, net value, currency, and rejection status for that line, and links back to the header in VBAK and forward to schedule lines, status, and business data tables via the same VBELN and POSNR keys.
- VBEPVBEP stores the schedule line data for a sales document item: one row per schedule line, holding the confirmed and requested quantities, the delivery date, and delivery block status for that quantity slice. A single sales order item can have several schedule lines when quantity is split across delivery dates or partially confirmed against different availability results.
- VBFAVBFA stores the link between one sales document (or item) and the document it produced in the order-to-cash chain, such as order to delivery, delivery to invoice, or order to credit memo. Each row is one preceding-to-subsequent relationship, not a document itself. It is the table to query when tracing what happened downstream or upstream of a given order, delivery, or billing document.
- LIKPLIKP is the outbound (or inbound) delivery header table in SD. One row represents one delivery document: its type, shipping point, ship-to party, planned and actual dates for picking, loading and goods issue, and route. Delivery items live in LIPS, not LIKP, so quantities and materials are never read from this table directly.
- LIPSLIPS stores the item-level data of outbound and inbound deliveries: one record per delivery item, holding the material, quantities (ordered, delivered, picked), plant, storage location, batch, and the links back to the originating sales order item and forward to the shipment and goods movement. It is the item counterpart to the header table LIKP.
- VBRKVBRK stores one row per billing document header - invoice, credit memo, debit memo, or pro forma - created in the SD billing process. It carries the billing type, billing date, net value, currency, payer and sold-to, and the accounting transfer status. Line-level revenue and tax sit in VBRP; VBRK alone never gives a complete invoice.
- VBRPVBRP stores one row per billing document item: the material, quantity, and net value billed, plus pointers back to the sales order item (AUBEL/AUPOS) and the delivery or order item that generated the billing line (VGBEL/VGPOS). It is the item-level counterpart to the billing header table VBRK and is the table to query when a customer disputes an invoiced amount or quantity.
Common Issues6
- Pricing procedure not determined in the sales orderThe order has no pricing procedure because the combination of sales organization, distribution channel, division, customer pricing procedure, and document pricing procedure has no matching entry in the pricing procedure determination table, or one of those four inputs is missing on the customer master, sales document type, or item category. Without a procedure, the conditions tab is empty and no condition types can be applied at all.
- Condition record exists but is not being set in pricingThe condition record is visible in VK13 but pricing analysis on the order item shows the access was either never attempted, found no record, or found the record and rejected it. Common reasons: validity dates do not cover the pricing date, a higher-priority access in an exclusive access sequence already returned a value, a requirement routine suppressed the step, or the record sits in a key combination the order data does not actually match.
- Shipping point not determined for the sales order itemShipping point determination fails when the combination of shipping condition (customer or order header), loading group (material master, per plant), and delivering plant has no matching entry in the shipping point determination table, or when one of those three inputs is blank. The item sits in the incompletion log and no delivery can be created until the missing input or the missing configuration entry is fixed.
- Delivery cannot be created because the schedule line is unconfirmedThe delivery due list or VL01N finds no deliverable quantity because the schedule line's confirmed quantity is zero or its confirmed date falls outside the selection window. This is driven by the availability check result, not by a delivery-side setting, so the fix almost always starts in the sales order, not in shipping.
- Billing document not released to accountingA billing document is not released to accounting when SAP cannot generate the FI accounting document behind it, usually because account determination cannot find a G/L account, the posting period is closed, a required CO account assignment is missing, or the tax code has no account assigned. The billing document itself exists and can be printed, but no financial posting occurs until the underlying determination gap is fixed.
- Account determination error in the billing documentThe billing document saves but cannot post to accounting because the system cannot find a valid G/L account for the combination of chart of accounts, sales organization, account assignment group of customer and material, and account key. The fix is either a missing entry in the account determination table (VKOA) or missing account assignment group in customer or material master data.