SAP SD Interview Questions

"It usually starts with pre-sales: an inquiry, then a quotation, both optional. The customer accepts, so I create a sales order with reference to the quotation in VA01. The order determines prices, checks availability and sets schedule lines. When the goods are due, shipping creates an outbound delivery in VL01N, the warehouse picks and packs, and then we post goods issue, which reduces stock and makes the delivery ready to bill. Billing creates the invoice, say with VF01 or the billing due list, and when it's released it creates an accounting document with the customer receivable. The last step, the incoming payment, happens in finance. Every document is linked, so the document flow lets me trace any invoice back to its order."

"A sales area is the combination of a sales organisation, a distribution channel and a division. The sales organisation is the legal selling unit, and it's assigned to exactly one company code, so every sale knows which books it lands in. The distribution channel is how we reach the customer, like wholesale or online, and the division is a product line. Customer sales data and most pricing is kept per sales area. For logistics, I assign the delivering plants to the sales organisation and channel combination, and each plant belongs to one company code too. Shipping points are assigned to plants, and they're where deliveries are processed. Sales offices and sales groups sit underneath for internal reporting and responsibility."

"An incompletion procedure is a list of fields that must be filled on a document, like the customer's purchase order number, the payment terms or the incoterms. There are separate procedures for the header, items, schedule lines and partners, and they're assigned to the sales document type, item category, schedule line category or delivery type. Each field in the list carries a status group, and the status group decides the consequence: the document can be saved but not delivered, or not billed, or both. The document type also controls whether a user can save an incomplete document at all. When an order won't deliver, the incompletion log in the order is one of the first places I look, because it names exactly which field is missing."

"The sold-to party is who places the order and whose sales data drives the order. The ship-to party is where the goods go, so its address and transportation zone drive shipping. The bill-to party receives the invoice, and the payer is who actually pays and whose account carries the receivable, so credit checks normally run on the payer. For a small shop all four are the same customer. A retail chain is the classic case for splitting them: each store is its own ship-to, but the head office is the bill-to and payer, so one central account gets the invoices and the credit limit. Partner determination procedures, assigned to customer account groups and document types, decide which functions are required and how they're proposed."

"In one role the sales team asked for a custom screen and program to hold orders for customers with a missing trade document until someone approved them. The real need was simple: don't ship until the paperwork is in. I set up a meeting and showed them two standard options: adding the document field to the incompletion procedure with a status group that blocks delivery, or a default delivery block on that order type that a named person removes. We tested it with two of their users in the test system. They chose the incompletion approach because it told them exactly what was missing. It took a couple of days of configuration instead of weeks of development, and it has had no upgrade issues since. I also wrote a one-page guide so new sales staff knew why the order wouldn't deliver."

"The sales document type, set up in VOV8, is the header of the whole process. It says what kind of document it is, like an order, a quotation or a return, and which number ranges it uses. It can force the user to create it with reference to a quotation or contract. It proposes the delivery type and two billing types, one for delivery-related and one for order-related billing. It can set a default delivery or billing block, which is common on returns and credit memo requests. It carries the document pricing procedure key used to find the pricing procedure, and the credit group that switches the credit check on or off. When I need a new type, I copy the closest standard one, like OR for a normal order, and then change only what the business needs, so copy control and item categories come across too."

"The item category is found in VOV4 from four things: the sales document type, the item category group from the material master's sales view, the usage, and the item category of the higher-level item, if there is one. For a standard order and a normal material that gives TAN, and a free-of-charge sub-item gives TANN. The item category controls whether the line is priced, whether and how it's billed, and whether schedule lines are allowed. The schedule line category then comes from the item category plus the MRP type of the material in that plant, set in VOV5. For example CP passes requirements to planning and CN doesn't. The schedule line controls whether the line is relevant for delivery, the movement type at goods issue and whether an availability check runs."

"Copy control decides what happens when one document is created from another. There are separate setups for order to order, like quotation to order, order to delivery, delivery to billing and order to billing. At header and item level I set copying requirements, which are routines that stop the copy if a condition fails, and data transfer routines, which decide what gets carried over and can add split criteria. For billing items I also set which quantity is billed and the pricing type. The pricing type matters a lot: B carries out new pricing, so the invoice picks up today's condition records. D copies the order prices unchanged. G copies them unchanged but redetermines taxes, which is common when tax rates might change between order and invoice. When a customer disputes an invoice price, this is one of the first things I check."

"The condition technique is how SAP finds values like prices, discounts and taxes. At the bottom is the field catalogue, the fields allowed as keys. From those I build condition tables, each a key combination like sales organisation, customer and material. An access sequence lists the tables in the order to search them, usually most specific first, so a customer-specific price wins over a general list price. The exclusive flag on an access stops the search once a record is found. A condition type, like a base price or a customer discount, points to an access sequence and says how the value is calculated. The pricing procedure lists condition types in the order they're applied, with subtotals. Finally, the business keeps condition records in VK11 against those tables, and that's the data the order actually reads."

"The pricing procedure is chosen in OVKK from five fields: the sales organisation, distribution channel and division, which make the sales area, then the customer pricing procedure, and the document pricing procedure. The customer pricing procedure is a key on the customer master in its sales area data, and the document pricing procedure sits on the sales document type, or the billing type for billing. So in this case the material isn't the reason. The two customers must sit in different sales areas or carry different customer pricing procedure keys, for example one is a normal customer and one is flagged for a special key-account procedure. I'd open both customer masters, compare that field, and check the OVKK entries for each combination. The material only matters later, when the condition records are searched."

"Each line has a step and counter, a condition type, and a from and to step that set the base for percentages. Manual means the condition is only used if a user enters it, it's never found automatically. Required means the item is incomplete if that condition is missing, which is how I make sure no line goes out without a base price. Statistical means the value is calculated and shown but doesn't change the net value, like the cost condition used for margin, or an expected cash discount. There's a requirement column for routines, subtotal fields that store values for reporting, and an alternative calculation or base routine for special logic. The account key, like ERL for revenue or ERS for deductions, tells billing which kind of GL account the value posts to through revenue account determination."

"A header condition is entered once, at order level, not found from records. If it's a percentage, like a two percent header discount, it's simply copied to every item. If it's a fixed amount, like a flat freight charge, it depends on the condition type. The standard header amount types are set as group conditions, so SAP spreads the amount across items, normally by net value, or by weight or volume if a base routine says so. If that flag is missing, the full amount lands on every item, which is a classic mistake. The other trap is that after adding or changing items you have to update the header condition so it's spread again. A group condition is still an item condition, but its scale reads the combined quantity or value of all items in the same group, for example a material pricing group. So two lines of sixty cartons each can together reach a hundred-carton scale that neither line reaches alone."

"In classic SD, a rebate is a retrospective discount. I'd create a rebate agreement in VBO1 with the customer, the rebate conditions and the accrual rates. The sales organisation, the payer and the billing type all have to be rebate relevant. Each invoice then updates the business volume and posts an accrual through the accrual key in the pricing procedure. At the end of the period, or as partial payments, the agreement is settled, which creates a rebate credit memo and reverses the accrual. In S/4HANA, SAP's direction is settlement management using condition contracts. New SD rebate agreements aren't the target solution; existing ones can be run down and settled after conversion. Condition contracts track business volume from the billing data, post accruals and settle on a calendar, and they cover supplier rebates in the same framework."

"At my last company, a customer called to say their invoices were showing the list price, not their contract price. I opened the pricing analysis on one billing item, which shows every access the system tried. The customer-specific access had found no record. The old record ended at year end, but the new year's records had been loaded with a start date a month late, so for that month there was no valid customer price and the search fell through to the list price. I checked other customers and found about twenty with the same gap from the same upload. We corrected the validity dates, then cancelled and rebilled the affected invoices where the customer hadn't paid, and used credit memos where they had. To stop it repeating, I added a check to the upload template for date gaps and asked for a monthly report of customers billed at list price."

"The availability check decides what quantity can be confirmed and for which date. The material master carries a checking group, which controls how requirements are passed on, for example summed per day or kept individually. The sales transaction brings a checking rule, and for sales orders that's usually A. Together they point to the scope of check in OVZ9, and that's where the real logic lives. It says which stocks count, like safety stock or stock in quality inspection, which receipts count, like purchase orders or production orders, and which issues count, like other sales orders and reservations. It also says whether to check within the replenishment lead time. If that's on, SAP assumes it can always get the material once the lead time has passed, so it confirms by then at the latest. The result is a full confirmation, a partial one or a later date."

"SAP starts from the requested delivery date and works backwards. It takes off the transit time from the route to get the goods issue date. Before that, it takes off the loading time to get the loading date. From the loading date it subtracts the pick and pack time to get the material availability date, and the transportation lead time to get the transportation planning date. The route gives transit and transport lead time; the shipping point gives loading and pick and pack time. The delivery must be created by the earlier of those two dates. If the material availability date is already in the past, or stock isn't available on it, SAP schedules forward from the date it can have the goods, and that gives a later confirmed delivery date on the schedule line. Factory calendars decide which days count."

"The shipping point comes from three fields. The shipping condition, which comes from the customer master or can be forced by the sales document type, the loading group from the material master, and the delivering plant. That combination is set in OVL2 with a default and some allowed manual choices. For the route, SAP uses the departure zone of the shipping point, the transportation zone of the ship-to customer, the shipping condition again, and the transportation group from the material. The route matters because it carries the transit time and transport lead time that drive scheduling. In the delivery, the route can be redetermined once the weight is known, using a weight group, if the business sets that up. When a route looks wrong, I check the ship-to's transportation zone first, because that's the field most often left blank or outdated."

"I'd open the order and go through the usual suspects in order. First, blocks: is there a delivery block at header or item level, and is the credit status blocked? Then the incompletion log, since a missing field can stop delivery. Next I'd look at the schedule lines. If the confirmed quantity is zero, it's availability, and I'd check stock and the scope of check. If it's confirmed, I'd look at the material availability date, because the delivery run only picks a line up once its selection date falls inside the run's date range. Then I'd check the shipping point and whether the delivery job for that shipping point ran and what its log says. Once I know the cause I tell the lead in plain words and, if it's a data or setup issue, fix it for the other orders too."

"The billing relevance on the item category decides it. Delivery-related billing means the item can only be billed after the delivery and goods issue, which is normal for physical goods. Order-related billing means it's billed straight from the sales order, which fits services, credit and debit memo requests, or billing by a target quantity. Both billing types are proposed by the sales document type, which has one field for each. Collective billing is running the billing due list, VF04, often as a background job, to bill many documents at once. SAP puts several deliveries into one invoice when the header data matches, like the same payer, billing date and terms of payment. If anything differs, it splits them into separate invoices."

"For damaged goods coming back, I create a returns order with reference to the original invoice, so prices and quantities copy across. The returns order usually carries a billing block. Then a returns delivery is created, and when the goods arrive we post the goods receipt, typically into blocked stock so quality can inspect them. Once the inspection is done, the block is removed and the returns credit memo is created. For the overcharged customer who keeps the goods, there's nothing to ship, so I create a credit memo request with reference to the invoice for the difference. It also comes with a billing block so a supervisor approves it. When the block is released, a credit memo is billed straight from the request. The reverse case, an undercharge, uses a debit memo request."

"It's mostly a pricing procedure job. Revenue account determination reads the account key on each pricing line, so freight and promotional discounts need their own condition types, each carrying its own key. Standard gives me ERL for revenue, ERS for sales deductions and ERF for freight. Freight can simply use ERF. Normal discounts already use ERS, so for promotions I'd create a new account key and put it only on the promotion condition types. Statistical lines like cost get no key, because they never post, and rebate conditions also carry an accrual key. Tax isn't part of this: its account comes from the tax setup in finance. Then finance adds the account determination entries for the new key, usually without depending on customer or material. I'd test with one order that has a freight charge and a promotion, bill it, and check that each amount lands on its own account in the accounting document."

"First I'd stop the bleeding: find out why last year's price was picked, most likely a missing or wrongly dated condition record, and fix it so today's invoices are right. Then I'd list every affected invoice. Before correcting anything, I'd talk to the account manager and finance, because the right fix depends on the customer. If the invoices aren't paid and the customer is fine with it, I'd cancel them and rebill, first checking that the rebill really picks up the corrected price, because copy control may just copy the old order price. If they've been paid or sent to the customer's system, a credit memo request or debit memo request for the difference is cleaner. I'd agree the posting dates with finance so it lands in the right period, and I'd write a short note explaining what happened and the check we've added."

"In the classic setup, maintained in NACE, output uses the condition technique again. There's an output type, like an order confirmation or an invoice, an access sequence, and condition records that say for this sales organisation and customer, send this output. The output procedure is assigned to the document type. The condition record also sets the partner function that receives it, the medium, like print, email or EDI, and the dispatch time, for example immediately on save or with a scheduled job. The output type points to a print program and a form. In S/4HANA there's a newer output management framework where determination is done with BRFplus rule tables and forms are usually PDF-based. You can choose for each application, like sales documents or billing, whether it uses the new framework or the older one, which matters a lot in conversions."

"In classic SD credit management, the check is switched on by the credit control area, the customer's risk category and the credit group of the document type. A static check adds open orders, open deliveries, open billing documents and open receivables, and compares them with the limit. A dynamic check does the same, except open order value only counts if it falls inside a time horizon, say the next two months, so orders far in the future don't block today's business. If the check fails, it can warn, stop the document or set a credit block, which credit staff release. In S/4HANA, the old SD credit management is replaced by the separate credit management component. Credit data sits on the business partner in credit segments, limits can come from scoring rules, and blocked orders can be handled as documented credit decisions that credit staff work through in an app."

"I wouldn't release it or change the limit myself, even if my user had the access, because that's a credit decision and it belongs to the credit team. But I'd help make it quick. I'd look at the order's credit status and tell the director exactly why it blocked: over the limit, an overdue item or a limit review date that has passed. Then I'd call the credit manager or whoever is on duty, give them that detail, and they can release it in minutes if they agree. If the block was caused by something wrong, like an old invoice that was paid but not cleared, I'd get finance to fix the root cause. Afterwards I'd suggest a review if this customer blocks often, so it's handled by a proper rule, not a late-night call."

"The first thing is master data: customers are created and changed as business partners, and customer-vendor integration keeps the customer records in sync, so a conversion needs every customer cleaned up and mapped first. In the data model, the separate header and item status tables were removed and the status fields moved into the document tables themselves, and the pricing results moved to a new table too, which affects custom reports that read the old tables. Functionally, credit management moves to the separate credit management component, SD rebate agreements give way to settlement management, there's a newer output management framework, and the advanced availability check adds things like product allocation and a new backorder process. Users also get Fiori apps for many sales tasks. In a conversion I'd check the simplification list for each of these and test custom code against it."

"On my last project I owned sales and billing for a conversion covering three sales organisations. The hardest part was customer data. Business partner conversion failed for a few hundred customers because of bad tax numbers and duplicate addresses, and we only found out in the second mock run. I set up a daily error list with the data owners and we cleared it before cutover. The thing that did bite us was open sales orders. We migrated them, but some carried old pricing, and the first week of invoices needed manual price checks. If I did it again, I'd run a full order-to-invoice test on real migrated orders in each mock, not just check that the orders loaded, and I'd agree a cut-off for price changes before go-live."

"Say company A sells and company B's plant ships. First I allow B's plant as a delivering plant for A's sales organisation and channel. B's plant is given the sales area that B uses for intercompany billing, and A is created as a customer in that sales area, with the internal customer number assigned to A's sales organisation. I assign the intercompany billing type, IV, to the order types allowed for intercompany. For price, I maintain the internal price condition, PI01, which shows as a statistical cost in A's order and is picked up as IV01 in the intercompany invoice. The flow is: A's order, a delivery from B's shipping point, goods issue from B's stock, then two invoices off the same delivery. A bills the end customer with a normal invoice, and B bills A with the intercompany invoice. The payable side in A is handled by finance."

"In a third-party order the line gets the third-party item category, TAS, either from the material's item category group or manually. Its schedule line category, CS, automatically creates a purchase requisition when the order is saved, with the customer's ship-to as the delivery address. Purchasing turns that into a purchase order to the vendor, and the vendor delivers straight to our customer. We don't create an outbound delivery in SD and there's no stock movement through our warehouse. A goods receipt can be posted as a statistical record if the business wants it. For billing, the standard item category is billed once the vendor's invoice is posted, based on that invoice quantity, so we don't invoice the customer for goods the vendor hasn't billed us for. That billing relevance can be changed if the business wants to bill earlier."

"Consignment is when we keep stock at the customer's site but it stays ours until they use it. Fill-up, with order type KB, sends goods to the customer. It creates a delivery and moves the stock into special consignment stock for that customer, but there's no invoice because ownership hasn't passed. Issue, KE, is when the customer reports what they've used: it creates a delivery from consignment stock and that one is billed. Pick-up, KA, brings unused consignment stock back to our plant, again without billing. Returns, KR, is for goods the customer had already been billed for and wants to return, so the stock goes back into consignment and they get a credit memo. So only issue creates an invoice, and returns creates a credit."