SAP SD / O2C Interview Questions

Sales area data is maintained in BP transaction (or the Fiori Manage Customer Master app) under the BP role FLCU01 (Customer — sales), per sales area; FLCU00 is the FI customer role for company-code data. The data is stored in KNVV via CVI (customer-vendor integration). The BP grouping controls number range and is mapped to a customer account group, which drives field status of the customer data. Only sales areas defined in OVXG (or the reference sales area for common channel/division) can be entered. Which users may maintain which sales areas is controlled by authorization objects (e.g. B_BUPA_RLT for roles, F_KNA1_* / V_KNA1_VKO for sales area data). Sales office and group values must be assigned to the sales area to be valid.

FLCU00 creates the FI customer view: general data and company code data (KNB1) through CVI. Sales requires the sales role FLCU01 with sales area data (KNVV) — pricing procedure, shipping condition, delivering plant, Incoterms, payment terms, account assignment group, tax classification — and partner functions (KNVP) for each sales area. Without FLCU01 and the sales area, the customer is not defined for the sales area. Fix: extend the BP with FLCU01 for the required sales areas, check the partner functions and tax classification, and adapt the creation process/app configuration so sales customers are always created with FLCU01.

Sales office is a geographical or branch unit (e.g. Region North), sales group a team of sales employees within an office. Both are defined under Enterprise Structure > Definition > Sales and Distribution (OVX1, OVX4); the sales office is assigned to sales areas (OVXM) and the sales group to sales offices (OVXJ). They are optional in sales documents. They are proposed from the customer's sales area data (KNVV) and stored in the order header (VBAK-VKBUR, VKGRP). Practical uses: reporting and analytics by region/team, output determination (e.g. office address on documents), pricing condition keys, partner and responsibility assignment, and authorization restrictions. They have no direct MM or FI posting impact.

Classify all traded products with commodity codes and country of origin, maintain weights; set default business transaction types and export procedures; make export data mandatory via incompletion for export documents; use pro forma invoices for customs where needed; ensure billing documents carry complete trade data for declarations; add sanctioned party and export control screening before delivery (built-in or SAP GTS); assign trade compliance ownership and monitor declaration errors.

SLG1 logs surface errors from billing document release to accounting, output determination, and interface failures that would otherwise be silent. Under clean core, consultants cannot debug or modify standard code, so root-cause analysis relies on log messages, BAdI implementations, and SAP-delivered extensibility points. Errors requiring core changes must be raised via incident to SAP rather than patched directly, making log accuracy critical for triage speed during hypercare.

I would first isolate whether the failure originates in advanced ATP (checking product allocation or supply protection rules in the aATP app) or in the billing document itself via VF03, since ATP errors surfacing at billing usually indicate a delivery-quantity or characteristic mismatch. Cross-check MDG-sourced material master fields against the SD material master view for governance gaps, then validate revenue account determination hasn't shifted due to a converted material group or item category. Fix root cause in MDG governance rules, correct affected billing documents, and rerun a controlled batch to confirm resolution before releasing to finance.

I would check validity periods on the condition record via VK13 - mass updates often use a validity end date that may have expired or overlapped incorrectly with the manual entry, causing it to be superseded. I'd also check if the mass update created a new record with higher priority in the access sequence or overlapping validity that pushed out the manual record, and review change documents (condition record change log) to confirm what was altered and when, then correct validity dates or recreate the manual condition record if genuinely deleted.

Set up proactive IDoc monitoring using WE02/WE05 with status filters for error statuses (like 51, 56) rather than relying on users noticing missing orders, and configure background jobs or alerts (via workflow or BD87 reprocessing checks) that flag IDocs stuck in error or intermediate status. Correlate order volume expected from the EDI partner against actual sales orders created, using a reconciliation report, to catch 'silent' failures where the IDoc posted with warnings but didn't create a valid order. Ensure PP is only planning against confirmed valid orders, not provisional or erroneous ones.

The design centers on requirements class settings (linked via requirement type from the strategy group, typically strategy 20) that enable individual customer stock through special stock indicator 'E', account assignment category, and valuation via order-related settlement or results analysis. Schedule line category must have both 'transfer of requirements' and 'availability check against individual stock' active, with the item category configured for individual purchase order/individual stock relevant processing. Any mismatch between requirement class account assignment and item category valuation settings causes stock to post to standard valuation rather than segregated order stock.

Pro forma billing types (F5/F8) should be configured with no accounting document transfer (billing relevance blank or transaction flow indicator suppressing FI posting) and excluded from credit exposure calculation by ensuring the item category/billing type combination does not update open credit value via S066. Copy control from order/delivery to pro forma must block relevance for delivery-related billing quantity updates and revenue recognition (RR) processing to prevent duplicate revenue triggers when the real invoice is later created.

Move credit exposure checks earlier in the sequence so credit release happens before TM freight order/tendering triggers, or introduce a soft pre-check at order creation using dynamic credit checks tied to a lower-risk category before the document reaches transportation-relevant status. Configure the credit check to block at delivery-relevant status change rather than allowing downstream TM integration to fire on documents still pending credit release, and add a status/BAdI-driven gate so TM planning is only triggered after credit release confirmation.

A plant must be assigned to a company code, and that company code drives the valuation and FI posting for goods movements originating from that plant regardless of which sales organization sells from it. Shipping points are assigned to plants, and multiple shipping points can serve one plant based on shipping conditions. Cross-company sales scenarios arise when the plant's company code differs from the sales organization's company code, requiring intercompany billing configuration and careful account determination to avoid incorrect revenue recognition.