SAP SD / O2C Interview Questions

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.

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.

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.

Check the job's selection variant to confirm it is picking up all relevant deliveries and review whether the copy control determination (delivery to intercompany billing) has requirement routines silently excluding certain document types or partner combinations. Cross-check with MM goods movement status, since intercompany billing typically requires the internal goods issue/receipt to be posted first, so deliveries stuck due to MM posting delays would not appear as errors but simply remain unprocessed until the next run.