Atlas Full-Text Manifest ================================================== Generated: 2026-07-10T00:00:00Z Canonical: https://dkharlanau.github.io/llms-full.txt Source: https://dkharlanau.github.io/atlas/manifest.json This file contains the full text of reviewed and verified Atlas pages only. Pages with status=needs_verification or verified=false are excluded. Source file paths are excluded to protect private draft locations. ================================================== PAGE: AI Agent for SAP Support URL: https://dkharlanau.github.io/atlas/ai-operations/ai-agent-for-sap-support/ SECTION: ai-operations DOMAIN: AI-assisted operations TYPE: operating pattern SAP AREA: SAP support / BTP-adjacent architecture BUSINESS PROCESS: Support operations TAGS: ai-operations, sap-ams, operational-memory REVIEWED: 2026-05-06 ---------------------------------------- Home Knowledge Atlas AI Operations AI Agent for SAP Support Atlas AI Operations AI agent for SAP support A support assistant should retrieve context, structure the diagnosis, and escalate cleanly. It should not guess its way through ERP risk. ProcessSupport operations PatternRetrieval, diagnosis, escalation, human review Reviewed06 May 2026 Core idea An AI agent for SAP support is most useful when it acts as a disciplined support layer: it retrieves relevant context, summarizes the issue, suggests diagnostic paths, prepares tickets, and routes uncertainty to humans. The goal is not autonomous configuration change. The goal is faster, more consistent first-pass support while preserving authorization boundaries, auditability, and human accountability. Minimum safe architecture Knowledge retrieval: approved runbooks, process notes, KEDB entries, public documentation, and system-specific support material where access is allowed. Authorization awareness: the agent should not expose data or suggest actions outside the user context. Structured diagnosis: the answer should separate evidence, likely cause, recommended next check, and escalation path. Human approval: any material process change, master-data change, financial impact, or configuration change needs controlled review. Traceability: responses should point to the sources used and leave an audit trail where the organization requires it. Good use cases Useful first use cases are ticket enrichment, incident summarization, runbook retrieval, duplicate issue detection, first-pass classification, and suggested diagnostic checklists. These are valuable because they reduce support friction without pretending the model owns the ERP decision. Support takeaway A credible SAP support agent should be conservative by design. It should say when it does not know, ask for missing evidence, and escalate early when the issue touches authorization, finance, compliance, master data, or configuration. Related Pages AI-Ready Process Documentation Authorization-Aware AI for SAP Operational Memory for SAP AMS ================================================== PAGE: AI-Ready Process Documentation URL: https://dkharlanau.github.io/atlas/ai-operations/ai-ready-process-documentation/ SECTION: ai-operations DOMAIN: AI-assisted operations TYPE: AI operations SAP AREA: Support knowledge management BUSINESS PROCESS: Support operations TAGS: ai-operations, sap-ams, operational-memory REVIEWED: 2026-06-13 ---------------------------------------- HomeKnowledge AtlasAi OperationsAI-Ready Process Documentation Knowledge Atlas AI-ready process documentation AI-assisted support improves when process knowledge is structured, current, scoped, and tied to evidence instead of scattered across chats and old handovers. DomainAI-assisted operationsTypeAI operationsReviewed2026-06-13 Where this fits This page connects operational memory, runbooks, knowledge-base design, and AI retrieval. It is useful before building a support copilot or ticket assistant. Common issues Documentation describes ideal process flow but not exceptions, ownership, diagnostic evidence, or escalation boundaries. Runbooks are stale, unversioned, and not linked to system context or common symptoms. AI retrieval finds the wrong content because documents lack clear scope and metadata. Diagnostic questions Does each process note say where it applies, who owns it, and when it was last reviewed? Are exceptions and support symptoms documented with evidence requirements? Can a reader or retrieval system distinguish official process from draft notes? Good process documentation is rarely complete on the first pass. The useful version is the one that is reviewed, scoped, and honest about what is still draft. Related pages AI Agent for SAP Support Operational Memory for SAP AMS Authorization-Aware AI for SAP ================================================== PAGE: Authorization-Aware AI for SAP URL: https://dkharlanau.github.io/atlas/ai-operations/authorization-aware-ai-for-sap/ SECTION: ai-operations DOMAIN: AI-assisted operations TYPE: AI operations SAP AREA: Security / authorization-aware retrieval BUSINESS PROCESS: Support operations TAGS: ai-operations, sap-ams, data-quality REVIEWED: 2026-06-13 ---------------------------------------- HomeKnowledge AtlasAi OperationsAuthorization-Aware AI Knowledge Atlas Authorization-aware AI for SAP An AI support layer must respect the same access boundaries that protect SAP data from human misuse. DomainAI-assisted operationsTypeAI operationsReviewed2026-06-13 Where this fits Authorization-aware AI belongs in any SAP support assistant, retrieval workflow, ticket summarizer, or agent that reads operational data. Common issues The AI has broader data access than the user asking the question. Retrieved context leaks company-code, plant, customer, supplier, finance, or personnel information across boundaries. The model suggests an action the user could not perform in the source system. Diagnostic questions Whose authorization context is used for retrieval? Can the answer reveal data indirectly through summaries or aggregates? Is every action recommendation routed through human approval and system authorization? Authorization-aware AI is not a one-time setup. Access rules, user roles, and data boundaries change, so the retrieval layer needs to be retested whenever the underlying authorization model changes. Related pages AI Agent for SAP Support SAP Master Data Quality AI-Ready Process Documentation ================================================== PAGE: Agent-Assisted Development Workflows URL: https://dkharlanau.github.io/atlas/automation/agent-assisted-development-workflows/ SECTION: automation DOMAIN: Automation TYPE: agentic workflow SAP AREA: Developer automation / support tooling BUSINESS PROCESS: Knowledge work TAGS: automation, ai-operations, sap-ams REVIEWED: 2026-06-13 ---------------------------------------- HomeKnowledge AtlasAutomationAgent-Assisted Development Workflows Knowledge Atlas Agent-assisted development workflows Agentic workflows are useful when they turn goals into inspected, traceable work. They are risky when they hide assumptions or change systems without review. DomainAutomationTypeagentic workflowReviewed2026-06-13 Where this fits This page connects AI-assisted development, documentation, support tooling, and operational analysis. The useful pattern is supervised execution with explicit scope, tests, and review. Common issues An agent is asked to implement without first inspecting the repository, data, or operational context. The workflow produces output but no traceable reasoning, source mapping, or verification result. Humans review only the final artifact instead of reviewing assumptions, scope, and tests. Diagnostic questions What is the agent allowed to read, change, and publish? What evidence proves the result is correct? Where is human approval required before changes reach production or public pages? The useful agentic workflow is one where the human reviewer can inspect assumptions, scope, and evidence without replaying the entire session. Related pages Rule-Based Automation vs AI AI Agent for SAP Support AI-Ready Process Documentation ================================================== PAGE: Operational Memory for SAP AMS URL: https://dkharlanau.github.io/atlas/automation/operational-memory-for-sap-ams/ SECTION: automation DOMAIN: Automation TYPE: automation pattern SAP AREA: AMS support knowledge BUSINESS PROCESS: Support operations TAGS: automation, sap-ams, operational-memory REVIEWED: 2026-06-13 ---------------------------------------- HomeKnowledge AtlasAutomationOperational Memory for SAP AMS Knowledge Atlas Operational memory for SAP AMS AMS improves when support knowledge is structured as reusable memory, not trapped in tickets, chats, and individual consultants. DomainAutomationTypeautomation patternReviewed2026-06-13 Where this fits Operational memory is the layer between incident closure and real prevention. It captures what was learned so the next support case starts from evidence, not rediscovery. Common issues Tickets are closed with minimal resolution text and no reusable diagnostic pattern. Critical knowledge lives in personal notes, vendor chats, or one consultant’s memory. Runbooks exist but are not connected to symptoms, ownership, evidence, or review cadence. Diagnostic questions Which incidents repeat, and what knowledge would prevent rediscovery? Does the KEDB describe symptoms, evidence, cause, fix, owner, and prevention? Can a new support person safely follow the runbook without hidden context? Operational memory decays quickly when tickets are closed without a decision log. The most valuable entries are the ones that explain why a fix was chosen, not just what was changed. Related pages AI-Ready Process Documentation AI Agent for SAP Support SAP Master Data Quality ================================================== PAGE: Rule-Based Automation vs AI URL: https://dkharlanau.github.io/atlas/automation/rule-based-automation-vs-ai/ SECTION: automation DOMAIN: Automation TYPE: automation pattern SAP AREA: Support automation BUSINESS PROCESS: Support operations TAGS: automation, sap-ams, ai-operations REVIEWED: 2026-06-13 ---------------------------------------- HomeKnowledge AtlasAutomationRule-Based Automation vs AI Knowledge Atlas Rule-based automation vs AI Not every support workflow needs a model. Some need better deterministic rules, ownership, and audit trail. DomainAutomationTypeautomation patternReviewed2026-06-13 Where this fits This page helps decide whether a SAP support task should be handled by a deterministic rule, workflow automation, AI assistance, or human review. Common issues Teams use AI for problems that are better solved with validation rules, workflow, monitoring, or clear ownership. Rule-based automation becomes brittle when the process has ambiguous inputs and exceptions. AI suggestions become risky when they trigger actions without approval or traceability. Diagnostic questions Is the decision rule stable, explicit, and auditable? Does the task require interpretation, summarization, similarity matching, or uncertainty handling? What is the consequence of a wrong action, and where should human approval sit? A good rule is not a defeat. Rules are often the right choice when the cost of a wrong action is high and the input can be validated before execution. Related pages AI Agent for SAP Support Authorization-Aware AI for SAP Agent-Assisted Development Workflows ================================================== PAGE: Order to Cash URL: https://dkharlanau.github.io/atlas/concepts/order-to-cash/ SECTION: concepts DOMAIN: Business operations TYPE: business process SAP AREA: SD / FI integration BUSINESS PROCESS: Order to cash TAGS: order-to-cash, sap-sd REVIEWED: 2026-05-06 ---------------------------------------- Home Knowledge Atlas Concepts Order to Cash Atlas Concept Order to cash The operating chain that turns customer demand into delivery, billing, accounting, and cash collection. ProcessOrder to cash SAP areaSD with finance and logistics touchpoints Reviewed06 May 2026 Core idea Order to cash is the end-to-end flow from customer demand to financial settlement. In a SAP-heavy environment it usually spans sales order capture, availability, delivery, goods issue, billing, accounting, receivables, and dispute handling. Why it matters O2C is where customer promise, inventory reality, logistics execution, pricing, tax, credit, and revenue recognition meet. Weakness in one area often appears as a support ticket somewhere else: an order block, a failed delivery, a billing split, a pricing dispute, or a delayed cash collection. Useful operating view Demand: customer, product, quantity, requested date, and commercial terms. Commitment: availability, credit/risk controls, pricing, and order validation. Execution: delivery creation, picking, packing, goods issue, and shipment handoff. Billing: invoice creation, account determination, tax, and customer communication. Cash: receivables, payment, clearing, disputes, and credit feedback. Support takeaway O2C diagnostics should follow the document flow and the business event sequence. Ask where the process stopped, which document exists, which document is missing, and which team owns the failed control. This prevents “SAP issue” from becoming a vague label for a cross-functional operating problem. Related Atlas Pages SAP ATP Is Not Inventory Order to Cash Map SAP Stock Exists but Is Not Promisable ================================================== PAGE: SAP ATP Is Not Inventory URL: https://dkharlanau.github.io/atlas/concepts/sap-atp-is-not-inventory/ SECTION: concepts DOMAIN: SAP operations TYPE: business concept SAP AREA: SD availability check / ATP BUSINESS PROCESS: Order to cash TAGS: order-to-cash, sap-sd, diagnostics REVIEWED: 2026-05-06 ---------------------------------------- Home Knowledge Atlas Concepts SAP ATP Is Not Inventory Atlas Concept SAP ATP is not inventory ATP is promise logic. Inventory is stock visibility. Confusing the two creates bad support tickets and bad customer commitments. ProcessOrder to cash SAP areaAvailability check / ATP Reviewed06 May 2026 Core idea Available-to-promise answers a commitment question: what quantity can the business responsibly promise to a customer, and when? It is not the same as asking what quantity exists physically in a plant or warehouse. Inventory can exist and still be unavailable for a new promise. It may already be committed to another order, blocked for quality, reserved for production, held in the wrong location, or not considered by the relevant availability check configuration. Why the distinction matters Many support issues start with a simple mismatch: a user sees stock in one report, but the sales order confirms less than expected. The first reaction is often “ATP is wrong.” A better first question is: which supply and demand elements is the check allowed to consider for this material, plant, date, and document context? The answer depends on master data, configuration, document type, timing, existing commitments, and sometimes product allocation or supply protection rules. The exact behavior is landscape-specific. Practical diagnostic questions Is the stock physically available, unrestricted, and relevant for the plant or storage location being checked? Are existing sales orders, reservations, or dependent requirements already consuming the supply? Are purchase orders, production orders, or planned receipts included in the check scope? Is the requested delivery date before the next reliable receipt? Is a product allocation, supply protection, or special stock rule changing the result? Support takeaway Do not diagnose ATP from stock quantity alone. Diagnose it as a time-based promise calculation shaped by business commitments, supply reliability, and configuration. A useful ATP support note should include the material, plant, requested date, confirmed date, confirmed quantity, visible stock, open requirements, open receipts, and the document context that triggered the check. Related Atlas Pages Order to Cash SAP Stock Exists but Is Not Promisable Order to Cash Map ================================================== PAGE: SAP Stock Exists but Is Not Promisable URL: https://dkharlanau.github.io/atlas/concepts/sap-stock-exists-not-promisable/ SECTION: concepts DOMAIN: SAP operations TYPE: business concept SAP AREA: ATP / availability / stock status BUSINESS PROCESS: Order to cash TAGS: order-to-cash, sap-sd, diagnostics, retail REVIEWED: 2026-06-13 ---------------------------------------- HomeKnowledge AtlasConceptsStock Exists but Is Not Promisable Knowledge Atlas SAP Stock Exists but Is Not Promisable A practical explanation of why visible stock can still fail availability, ATP, allocation, or channel commitment checks. DomainSAP operationsTypebusiness conceptReviewed2026-06-13 Where this fits This page sits between inventory reporting and customer commitment. It is useful when business users say stock is visible in one place, but an order, store channel, or online promise still cannot use it. Common issues Stock is in the wrong plant, storage location, channel, or stock type for the process being checked. Stock is physically present but already committed, reserved, blocked, or not included in the relevant availability logic. Retail, e-commerce, and distribution channels may apply allocation or promise rules that differ from simple unrestricted stock visibility. Diagnostic questions Which stock figure is the user looking at, and which process is trying to consume or promise it? Is the stock unrestricted, relevant to the checked location, and available on the requested date? Is another document, allocation rule, or protection rule already consuming the quantity? Stock visibility and promisable stock are two different figures. The gap between them is usually a business rule, not a system error. Related pages SAP ATP Is Not Inventory Order to Cash Store Receiving in SAP Retail ================================================== PAGE: Store Receiving in SAP Retail URL: https://dkharlanau.github.io/atlas/concepts/store-receiving-sap-retail/ SECTION: concepts DOMAIN: Retail operations TYPE: business concept SAP AREA: Retail / inventory management BUSINESS PROCESS: Retail replenishment TAGS: retail, sap-sd, order-to-cash REVIEWED: 2026-05-06 ---------------------------------------- HomeKnowledge AtlasConceptsStore Receiving in SAP Retail Knowledge Atlas Store receiving in SAP Retail Store receiving is not only a goods receipt posting. It is the handoff from supply chain execution to sales-floor availability. DomainRetail operationsTypebusiness conceptReviewed2026-05-06 Where this fits Store receiving is the point where distribution-center or supplier delivery becomes store stock that can be counted, replenished, sold, and audited. Common issues Goods arrive physically but are not posted in time, creating visibility gaps for replenishment and availability. Discrepancies are handled informally instead of being recorded as structured evidence. Store staff may receive during peak operational pressure, which increases errors and delays. Diagnostic questions Has the delivery physically arrived, and is there proof of delivery? Has system receipt been posted against the expected reference? Were shortages, damages, overages, or wrong-store deliveries recorded in a way finance and supply chain can use? Related pages SAP Stock Exists but Is Not Promisable Order to Cash Map SAP Master Data Quality ================================================== PAGE: Master Data Governance Failure Modes URL: https://dkharlanau.github.io/atlas/data-quality/master-data-governance-failure-modes/ SECTION: data-quality DOMAIN: Data operations TYPE: data quality SAP AREA: MDG / master data governance BUSINESS PROCESS: Cross-process operations TAGS: master-data, data-quality, sap-ams REVIEWED: 2026-06-13 ---------------------------------------- HomeKnowledge AtlasData QualityGovernance Failure Modes Knowledge Atlas Master data governance failure modes Weak governance shows up as operational friction: blocked orders, payment failures, reporting distrust, migration cleanup, and repeated support handling. DomainData operationsTypedata qualityReviewed2026-06-13 Where this fits Governance failure modes explain why the same data defect keeps returning after individual records are repaired. Common issues No clear owner for creation, extension, blocking, change approval, or retirement of master data. Rules exist in documentation but not in workflow, validation, monitoring, or accountability. Migration cleanup is treated as a one-time project instead of a continuous quality obligation. Diagnostic questions Who owns the object and who approves change? Which quality rule failed, and was it preventable at entry time? Is this a single bad record or a pattern across objects, plants, company codes, or suppliers? Governance failures become visible when the same ticket type keeps reopening. The signal is not the bad record; it is the absence of an owner, rule, or review loop that should have caught it. Related pages SAP Master Data Quality Authorization-Aware AI for SAP Operational Memory for SAP AMS ================================================== PAGE: SAP Master Data Quality URL: https://dkharlanau.github.io/atlas/data-quality/sap-master-data-quality/ SECTION: data-quality DOMAIN: Data operations TYPE: data quality SAP AREA: Master data / MDG-adjacent BUSINESS PROCESS: Cross-process operations TAGS: master-data, data-quality, sap-ams REVIEWED: 2026-06-13 ---------------------------------------- HomeKnowledge AtlasData QualitySAP Master Data Quality Knowledge Atlas SAP master data quality Master data quality is not an abstract data-management concern. In SAP support, it is often the hidden cause behind blocked processes and repeated tickets. DomainData operationsTypedata qualityReviewed2026-06-13 Where this fits Master data quality sits behind sales, procurement, inventory, finance, logistics, planning, and reporting. When support only fixes transaction symptoms, the same data problem returns. Common issues Required views or organizational extensions are missing. Names, addresses, units of measure, payment terms, partner roles, or classifications are inconsistent. Ownership is unclear, so support corrects records one by one without changing governance. Diagnostic questions Which master data object controls the failed process step? Is the problem missing data, inconsistent data, duplicate data, wrong ownership, or stale migration residue? Can the issue be prevented with validation, workflow, stewardship, or monitoring? Master data quality work is unglamorous until a blocked order or failed payment reveals the real cost. The best fixes combine a repaired record with a governance change that stops the same defect from recurring. Related pages Master Data Governance Failure Modes AI-Ready Process Documentation Authorization-Aware AI for SAP ================================================== PAGE: SAP ALE Distribution Model Diagnostics URL: https://dkharlanau.github.io/atlas/diagnostics/sap-ale-distribution-model-diagnostics/ SECTION: diagnostics DOMAIN: SAP AMS TYPE: diagnostic guide SAP AREA: ALE / master data distribution BUSINESS PROCESS: Integration TAGS: integration, sap-ale, diagnostics, master-data REVIEWED: 2026-06-13 ---------------------------------------- Home Knowledge Atlas Diagnostics SAP ALE Distribution Model Diagnostics Atlas Diagnostic SAP ALE distribution model diagnostics A first-pass structure for finding why master data is not distributed, arrives at the wrong target, or creates duplicate objects. ProcessIntegration SAP areaALE / master data distribution IndexingIndex, reviewed Core idea ALE distribution models decide which master data changes go to which target systems. A missing object usually means the model did not select it, the change pointer was not processed, or the target did not accept it. Duplicates usually mean key mapping is missing or wrong. The diagnostic job is to follow the selection chain: model → change pointer → IDoc → target. Common symptoms Master data change in source system is not reflected in target system. Change pointer exists but no IDoc was generated. IDoc was sent to wrong target system or multiple systems unexpectedly. Target system creates duplicate master data objects instead of updating existing ones. Distribution model shows active but no messages for the object type. Likely causes Missing distribution model entry: the object type or message type is not included in the active distribution model. Change pointer not created: change documents were not written or the change pointer job (BD21) did not process them. Filter object mismatch: the filter object excludes the specific plant, company code, or sales organization from distribution. Partner profile issue: the receiver partner profile does not support the message type or the outbound parameter is missing. Target system key mapping: the target system does not recognize the source key and creates a new object instead of updating. Where to check in SAP BD64 — distribution model display. BD22 — change pointer overview. BD21 — change pointer processing log. WE20 — partner profile outbound parameters. WE02 — generated IDocs for the message type. Key tables / transactions / objects BDCP / BDCPS — change pointers. EDIDC / EDIDS — IDoc control and status. TBD22 / TBD23 — distribution model tables. TBDBE — filter objects. Diagnostic workflow Identify the master data object, message type, source system, and expected target system. Check BD64 for the distribution model: is the object/message type included and active? Check BD22 for change pointers: was a change pointer created for the object change? Run or check BD21 to see if change pointers were processed into IDocs. Check WE20 for the receiver partner profile: does it have the outbound parameter for this message type? Check WE02 for generated IDocs and their status. On the target system, check if the IDoc was received and whether it created or updated the object. Typical fixes or next actions Add the missing object type or message type to the distribution model. Process change pointers with BD21 if they were not automatically processed. Adjust filter objects if the distribution scope is too narrow. Update the partner profile to include the missing outbound parameter. Fix key mapping on the target system if duplicates are being created. What to capture first Before routing the issue, capture: object type, message type, source and target systems, change document number, distribution model name, and whether the issue is new or recurring. This distinguishes a one-time filter miss from a model gap that will keep producing failures. Boundaries and non-goals This page is a diagnostic frame, not an ALE configuration guide. It does not cover distribution model design, filter object setup, or target system key mapping configuration. It does not replace SAP's ALE documentation. This is not official SAP documentation and not a replacement for system-specific analysis. Related Atlas Pages Idoc Aif Integration Diagnostics SAP Idoc Status Diagnostics SAP Key Mapping Diagnostics ================================================== PAGE: SAP Application Log Diagnostics URL: https://dkharlanau.github.io/atlas/diagnostics/sap-application-log-diagnostics/ SECTION: diagnostics DOMAIN: SAP AMS TYPE: diagnostic guide SAP AREA: Application logs / SLG1 / SM21 BUSINESS PROCESS: SAP AMS support TAGS: sap-ams, application-logs, slg1, sm21, diagnostics REVIEWED: 2026-06-13 ---------------------------------------- Home Knowledge Atlas Diagnostics SAP Application Log Diagnostics Atlas Diagnostic SAP application log diagnostics A first-pass structure for finding incident evidence in SAP application logs, system logs, and developer traces. ProcessSAP AMS support SAP areaApplication logs / SLG1 / SM21 IndexingIndex, reviewed Core idea Application logs are often the fastest way to narrow an incident to a component, user, or transaction. When the symptom is vague, the goal is to move from the business report to the concrete log object, time window, and error text. Common symptoms A process failed but no application error message is visible to the user. The support team needs to prove whether an error originated in SAP or in a connected system. An interface or batch job failed and the job log is too short to explain why. A user reports intermittent failures that are hard to reproduce. A custom program or enhancement behaves unexpectedly after a transport. Likely causes Log object not activated: the application writes to a log object that is not active in SLG0/SLG2. Wrong log level: the log is configured for errors only and omits the warning that explains the root cause. Time-window mismatch: the log is searched outside the actual failure window. Object overwritten: old log entries were deleted by housekeeping before the incident was reported. Trace not collected: a short dump or SQL trace was not captured at the moment of failure. Where to check in SAP SLG1 — application log: filter by log object, sub-object, external ID, or time. SM21 — system log: check for operating-system level or kernel errors around the failure time. ST22 — short dump analysis for ABAP runtime errors. ST05 / SQL trace — capture database activity if the issue is reproducible. SM50 / SM66 — work process overview for stuck or failed dialogs. Key tables / transactions / objects SLG1 / SLG2 — application log entries and display. SNAP — short dump header data. TBPROF / TSP02 — spool and print request tables. Diagnostic workflow Confirm the exact time, user, transaction, and business object involved in the incident. Open SLG1 and filter by the relevant log object/sub-object or external ID. If SLG1 is empty, check SM21 for system-level errors in the same time window. For ABAP dumps, open ST22 and search by date/user/transaction. If the failure is reproducible, run ST05 or SAT to capture SQL or runtime trace. Document the log object, message ID, and timestamp; correlate with business process step. Typical fixes or next actions Activate or extend the relevant log object in SLG0 if logging is missing. Adjust log retention or archive strategy so recent incidents are still available. Add explicit error handling and logging in custom code. Route critical log objects to alerting or incident workflow. Escalate to development or basis if the trace points to a program or kernel issue. Support takeaway A useful log investigation ticket includes: time window, user/background user, transaction or program name, business object ID, and the exact symptom. Without this context, log searches become slow and inconclusive. Boundaries and non-goals This page is a diagnostic frame, not a configuration guide for SAP Log Management or SAP Cloud ALM. It does not cover detailed trace interpretation or code debugging. This is not official SAP documentation and not a replacement for system-specific analysis. ================================================== PAGE: SAP Authorization and Role Diagnostics URL: https://dkharlanau.github.io/atlas/diagnostics/sap-authorization-diagnostics/ SECTION: diagnostics DOMAIN: SAP AMS TYPE: diagnostic guide SAP AREA: Authorization / roles / security BUSINESS PROCESS: SAP AMS support TAGS: sap-ams, authorization, roles, security, su53 REVIEWED: 2026-06-13 ---------------------------------------- Home Knowledge Atlas Diagnostics SAP Authorization and Role Diagnostics Atlas Diagnostic SAP authorization and role diagnostics A first-pass structure for authorization failures, missing roles, and profile gaps in SAP support. ProcessSAP AMS support SAP areaAuthorization / roles / security IndexingIndex, reviewed Core idea Authorization failures stop users before they can reproduce a functional issue. The diagnostic goal is to capture the missing authorization object, compare it with the user's roles and profiles, and decide whether the fix is a role change, a user exit, or a process change. Common symptoms User receives 'No authorization' or 'You are not authorized' messages. A transaction starts but specific functions or fields are grayed out. Background job fails with authorization errors under its service user. An interface or RFC call fails with authorization_check errors. Authorization works in one client but not another after a transport. Likely causes Missing authorization object: the role does not contain the required object/activity/value. Organizational level mismatch: the user is authorized for a different company code, plant, or sales organization. Profile not generated: the role was changed but the profile was not regenerated or not assigned. Buffer refresh: user context still holds the old authorization after a role change. User comparison incomplete: the user master record was not compared after role changes. Where to check in SAP SU53 — display authorization check values from the last failed check. PFCG — role maintenance: check objects, organizational levels, and profile generation status. SU01 — user master: compare roles and profiles assigned to the user. ST01 — authorization trace for harder cases. SU56 — authorization buffer for the current user session. Key tables / transactions / objects UST04 / UST12 — user master authorization profiles. AGR_1251 — authorization values in roles. USR02 — user master logon data. Diagnostic workflow Reproduce the error or capture SU53 immediately after it occurs. Identify the missing authorization object, field, and required value. Check whether the user has a role that should contain that object. If the role exists, verify profile generation, user comparison, and buffer refresh. If the role does not contain the object, decide whether to extend the role or change the process. Document the authorization object and value before requesting a security change. Typical fixes or next actions Add the missing authorization object/activity to the correct role and regenerate the profile. Adjust organizational levels if the user works across company codes or plants. Run user comparison for affected users after role changes. Refresh the user context or have the user log off and on again. Escalate to security team if the request conflicts with segregation of duties. Support takeaway Authorization tickets are most useful when they include the SU53 screenshot or authorization object, the user's roles, the transaction and activity, and the business reason for access. Boundaries and non-goals This page is a support diagnostic, not a security role design or SoD review guide. It does not replace the security team's authorization concept. This is not official SAP documentation and not a replacement for system-specific analysis. ================================================== PAGE: SAP Business Partner Replication Diagnostics URL: https://dkharlanau.github.io/atlas/diagnostics/sap-business-partner-replication-diagnostics/ SECTION: diagnostics DOMAIN: SAP AMS TYPE: diagnostic guide SAP AREA: BP / MDG / replication BUSINESS PROCESS: Master data governance TAGS: master-data, sap-mdg, diagnostics, replication REVIEWED: 2026-06-13 ---------------------------------------- Home Knowledge Atlas Diagnostics SAP Business Partner Replication Diagnostics Atlas Diagnostic SAP business partner replication diagnostics A first-pass structure for finding why a business partner was not replicated, arrived incomplete, or created duplicates in a target system. ProcessMaster data governance SAP areaBP / MDG / replication IndexingIndex, reviewed Core idea Business partner replication moves BP master data from a source system to target systems. Most tickets resolve to one of three handoffs: the source did not select the BP, the target did not accept it, or the accepted BP was mapped to the wrong key. The diagnostic job is to find which handoff failed and why. The fastest way to narrow the issue is to prove the message left the source, then prove the target received it. Everything in between is noise until those two facts are established. Common symptoms BP created in source system but does not appear in target system after expected replication time. BP appears in target but with missing roles, addresses, or bank details. Target system creates a duplicate BP instead of updating the existing one. Replication shows success in the source but the target BP has different data. Specific BP role (customer, vendor, contact) is missing after replication. Likely causes Replication model filter: the BP type, role, or organizational unit is excluded from the replication model. Key mapping missing: the source BP GUID or number is not mapped to the target system key, causing a new BP to be created. Data quality block: the BP data fails validation in the target system (missing required field, invalid format, duplicate tax number). Role-specific filter: the replication model sends the BP header but filters out specific roles or relationships. Target system configuration: the target system has different BP grouping, number ranges, or role assignment rules that conflict with the replicated data. Where to check in SAP MDG Data Replication log (if MDG is the source) — check replication status and error messages. BDCP / BDCPS — change pointers for the BP object. WE02 — IDoc status if ALE is used for replication. Key mapping tables (if custom mapping is used) — check source-to-target key mapping. Target system BP display (FLBP1 / FLBP2) — verify roles, addresses, and assignments. Key tables / transactions / objects BUT000 / BUT001 — BP header and general data. BUT100 / BUT100 — BP roles. BUT020 / ADRC — BP addresses. BKDF / BNKA — BP bank details. BDCP / BDCPS — change pointers. Diagnostic workflow Identify the BP number, source system, target system, and the expected versus actual result. Check the replication log or change pointer status to confirm the BP was selected for replication. Check WE02 or the replication middleware for IDoc or message status. Verify key mapping: does the target system recognize the source BP key or create a new one? Check the target BP in FLBP1/FLBP2 for missing roles, addresses, or data. Compare the source BP data with the target BP data to identify which fields were filtered or failed validation. Typical fixes or next actions Update the replication model to include the missing BP type, role, or organizational unit. Create or correct key mapping between source and target systems. Fix data quality issues in the source BP before replicating. Adjust target system BP grouping or role assignment rules if they conflict with replicated data. If duplicates exist, evaluate merge or deactivation options with master data governance. What to capture first Before routing the issue, capture: BP number, source and target systems, expected versus actual result, replication model name, and any error from the replication log or IDoc status. A vague "BP missing" report wastes a round of basic questions; these six items let a support engineer start the real diagnosis. Escalation signals Replication failures affect many business partners or all target systems. A duplicate BP was created in a target system and needs data steward or business approval to merge. The issue involves key mapping, number ranges, or BP grouping changes that require MDG/ BASIS involvement. Missing bank, tax, or address data has compliance, payment, or reporting impact. Boundaries and non-goals This page is a diagnostic frame, not a BP replication configuration guide. It does not cover MDG replication model design, key mapping setup, or BP grouping configuration. It does not replace SAP's master data governance documentation. This is not official SAP documentation and not a replacement for system-specific analysis. Related Atlas Pages SAP Vendor Master Replication Diagnostics SAP Customer Master Replication Diagnostics SAP Key Mapping Diagnostics SAP Master Data Quality ================================================== PAGE: SAP Customer Master Replication Diagnostics URL: https://dkharlanau.github.io/atlas/diagnostics/sap-customer-master-replication-diagnostics/ SECTION: diagnostics DOMAIN: SAP AMS TYPE: diagnostic guide SAP AREA: Customer master / CVI / replication BUSINESS PROCESS: Master data governance TAGS: master-data, sap-mdg, diagnostics, replication REVIEWED: 2026-06-13 ---------------------------------------- Home Knowledge Atlas Diagnostics SAP Customer Master Replication Diagnostics Atlas Diagnostic SAP customer master replication diagnostics A first-pass structure for finding why a customer was not replicated, arrived with wrong data, or created a duplicate in the target system. ProcessMaster data governance SAP areaCustomer master / CVI / replication IndexingIndex, reviewed Core idea Customer master replication moves customer data through ALE, CVI, or MDG. The failures that matter most are missing sales area or company code data, duplicate customers in the target, and CVI links that look connected but carry different data. The diagnostic job is to separate replication model gaps from CVI synchronization gaps from key mapping gaps. Common symptoms Customer created in source system but missing in target system. Customer exists in target but sales area or company code data is missing. Target system creates duplicate customer instead of updating existing one. CVI synchronization creates a business partner but the customer link is broken. Customer partner functions or tax classification differ between source and target. Likely causes Replication model filter: the customer account group or sales area is excluded from replication. CVI synchronization failure: the customer-vendor integration did not create or link the BP correctly. Key mapping missing: the source customer number is not mapped to the target system, causing a new customer to be created. Sales area filter: the replication sends general data but filters out specific sales organizations or distribution channels. Target number range issue: the target system number range is exhausted or configured for external numbering while the source uses internal. Where to check in SAP XD01 / XD02 / XD03 — customer master display in target system. WE02 — IDoc status if ALE replication is used. FLBP1 / FLBP2 — business partner display if CVI is involved. MDG replication log — if MDG is the source. Key mapping tables — source-to-target customer number mapping. Key tables / transactions / objects KNA1 — customer general data. KNB1 — customer company code data. KNVV — customer sales area data. BUT000 / BUT001 — BP header (if CVI is used). CVI_LINK — CVI link table between BP and customer. Diagnostic workflow Identify the customer number, source system, target system, and the expected versus actual result. Check the replication log or IDoc status to confirm the customer was selected and sent. Verify the customer exists in the target system (XD03) and check which views are present. If CVI is used, check FLBP1 for the linked BP and verify the CVI_LINK table. Check key mapping to confirm the source customer maps to the correct target customer. Compare sales area and company code data between source and target. Typical fixes or next actions Update the replication model to include the missing account group or sales area. Create or correct key mapping between source and target customer numbers. Fix CVI synchronization issues by re-running CVI synchronization or correcting the BP link. Extend the customer to the missing sales area or company code in the target system. Adjust target number ranges if they conflict with the source numbering. What to capture first Before routing the issue, capture: customer number, source and target systems, expected versus actual views, replication model, and any IDoc or CVI error. If CVI is involved, include the BP number and the CVI_LINK status. These facts separate a replication problem from a BP-link problem. Escalation signals Customer data is missing or wrong in downstream sales, billing, or service systems. Replication failures affect a key account, distribution channel, or sales organization. A duplicate customer was created and needs merging with approval from sales and finance. The issue involves tax classification, credit segment, or partner function changes beyond standard support scope. Boundaries and non-goals This page is a diagnostic frame, not a customer replication configuration guide. It does not cover CVI setup, replication model design, or customer account group configuration. It does not replace SAP's customer master documentation. This is not official SAP documentation and not a replacement for system-specific analysis. Related Atlas Pages SAP Business Partner Replication Diagnostics SAP Cvi Synchronization Diagnostics SAP Key Mapping Diagnostics SAP Master Data Quality ================================================== PAGE: SAP CVI Synchronization Diagnostics URL: https://dkharlanau.github.io/atlas/diagnostics/sap-cvi-synchronization-diagnostics/ SECTION: diagnostics DOMAIN: SAP AMS TYPE: diagnostic guide SAP AREA: CVI / BP / customer / vendor BUSINESS PROCESS: Master data governance TAGS: master-data, sap-mdg, diagnostics, cvi REVIEWED: 2026-06-13 ---------------------------------------- Home Knowledge Atlas Diagnostics SAP CVI Synchronization Diagnostics Atlas Diagnostic SAP CVI synchronization diagnostics A first-pass structure for finding why a business partner, customer, or vendor is not synchronized correctly through CVI. ProcessMaster data governance SAP areaCVI / BP / customer / vendor IndexingIndex, reviewed Core idea Customer-Vendor Integration (CVI) in S/4HANA keeps business partners aligned with customer and vendor master data. Most CVI incidents are not data corruption; they are configuration or timing mismatches. Before treating a missing customer or vendor as a master-data defect, confirm whether CVI is expected to create the object, which direction is configured, and whether the required BP role exists. Common symptoms Business partner created but no corresponding customer or vendor was generated. Customer or vendor exists but the linked BP has different data or is missing. CVI creates duplicate business partners for the same customer or vendor. BP role assignment is missing or wrong after CVI synchronization. CVI synchronization log shows errors that are not immediately actionable. Likely causes CVI not active for the BP grouping: the BP grouping used for the new BP is not configured for CVI synchronization. Direction mismatch: the synchronization direction is set to BP-to-customer but the customer was created first, or vice versa. Number range conflict: the BP number range overlaps with customer or vendor number ranges, causing collisions. Missing BP role: the BP was created without the FLCU00 (customer) or FLVN00 (vendor) role required for CVI. CVI mapping error: the field mapping between BP and customer/vendor is misconfigured or missing for a specific field. Where to check in SAP FLBP1 / FLBP2 — business partner display to check roles and CVI link. XD03 / XK03 — customer/vendor display to check BP assignment. CVI_LINK — link table between BP and customer/vendor. CVI synchronization log — check for errors during synchronization. BP grouping configuration — check if CVI is active for the grouping. Key tables / transactions / objects BUT000 / BUT001 — BP header and general data. CVI_LINK — CVI link table. KNA1 / KNB1 — customer master data. LFA1 / LFB1 — vendor master data. TBZ9A — BP role definitions. Diagnostic workflow Identify the BP number, customer number, or vendor number and the expected synchronization result. Check FLBP1 for the BP roles (FLCU00 for customer, FLVN00 for vendor). Check CVI_LINK for the relationship between BP and customer/vendor. Check XD03/XK03 for the customer/vendor and verify the BP assignment. Check the CVI synchronization log for errors during the last synchronization run. Verify the BP grouping is configured for CVI and the synchronization direction is correct. Typical fixes or next actions Activate CVI for the BP grouping if it was not configured. Add the missing BP role (FLCU00 or FLVN00) to enable synchronization. Correct the synchronization direction if BP and customer/vendor were created in the wrong order. Fix number range conflicts to prevent duplicate creation. Re-run CVI synchronization after correcting configuration or data issues. What to capture first Before routing the issue, capture: BP number, customer or vendor number, BP grouping, expected roles, actual result, CVI_LINK status, and any synchronization log error. If the BP was created manually, note the creation order; direction mismatches are common when a customer or vendor already exists before the BP. Boundaries and non-goals This page is a diagnostic frame, not a CVI configuration guide. It does not cover CVI setup, BP grouping design, or field mapping configuration. It does not replace SAP's CVI documentation. This is not official SAP documentation and not a replacement for system-specific analysis. Next diagnostic steps SAP Master Data Quality — use this for broader data quality signals and governance context. SAP Business Partner Replication Diagnostics — go here when BP data is replicated between systems. SAP Customer Master Replication Diagnostics — check this when the customer side is missing or wrong. SAP Vendor Master Replication Diagnostics — use this when the vendor side is missing or wrong. SAP BP Relationship Diagnostics — go here if the issue involves related BP roles or relationships. Customer-vendor integration boundary CVI is a bridge, not a cleanup tool. It will not repair a customer that was created before the BP, nor will it guess the right grouping if the BP was created without the FLCU00 or FLVN00 role. Fix the configuration and timing first; manual object creation usually creates more link breaks than it solves. Practical checklist - [ ] Collect BP number, customer/vendor number, BP grouping, and expected roles. **Synthetic example:** BP 1234567890, customer 1000000001, grouping TEST_CUST_GRP. - [ ] Check FLBP1/FLBP2 for BP roles FLCU00/FLVN00 and the CVI link. - [ ] Verify CVI_LINK relationship between BP and customer/vendor. - [ ] Check XD03/XK03 for customer/vendor and confirm BP assignment. - [ ] Review CVI synchronization log for field-level or direction errors. - [ ] Confirm the BP grouping is configured for CVI and the synchronization direction matches the creation order. - [ ] Safety limit: do not manually create a customer/vendor for a BP that should be synchronized; fix CVI config first. Related Atlas Pages SAP Business Partner Replication Diagnostics SAP Vendor Master Replication Diagnostics SAP Customer Master Replication Diagnostics SAP BP Relationship Diagnostics SAP Company Code Data Diagnostics SAP Supplier Master Diagnostics ================================================== PAGE: SAP Goods Receipt Diagnostics URL: https://dkharlanau.github.io/atlas/diagnostics/sap-goods-receipt-diagnostics/ SECTION: diagnostics DOMAIN: SAP AMS TYPE: diagnostic guide SAP AREA: MM inventory management BUSINESS PROCESS: Procure to pay TAGS: procure-to-pay, sap-mm, diagnostics, procurement, goods-receipt REVIEWED: 2026-06-13 ---------------------------------------- HomeKnowledge AtlasDiagnosticsGoods Receipt Diagnostics Knowledge Atlas SAP goods receipt diagnostics Goods receipt is where physical delivery becomes system evidence. Mistakes ripple into stock, invoice matching, and finance. DomainSAP AMSTypediagnostic guideReviewed2026-06-13 Where this fits Goods receipt sits at the boundary of inbound logistics, inventory management, invoice verification, and accounting. A posting failure here usually means the physical delivery, the purchase order, the material master, or the user input are not aligned. Common symptoms The purchase order is closed, blocked, wrong, or no longer matches the physical delivery. The material, batch, serial number, storage location, or quality status prevents normal posting. A receipt was posted too early, too late, with the wrong quantity, or against the wrong reference. The receipt quantity does not match the invoice quantity, causing a three-way match block. Stock is visible physically but not in the system, or posted to the wrong plant or storage location. Likely causes PO mismatch: the delivered material, quantity, or unit of measure differs from the purchase order item. Status block: the PO item is marked delivery completed, blocked, or deleted. Master data gap: the material is not extended to the plant or storage location, or the batch/serial profile is inconsistent. Quality inspection: the material requires inspection and cannot be posted directly to unrestricted stock. Movement type issue: the wrong movement type is used, or the movement type is not configured for the transaction. Timing issue: the invoice arrived before the goods receipt, or the receipt was posted against the wrong period. Where to check in SAP MIGO / MB01 — goods receipt entry and error messages. ME23N — purchase order history showing ordered, delivered, and still-to-deliver quantities. MB52 / MMBE — stock overview to confirm where stock was posted. MKPF / MSEG — material document header and item details. QA33 / QE51N — inspection lot status if quality management is involved. Key tables / transactions / objects MKPF — material document header. MSEG — material document items. EKBE — purchase order history. MARD — storage location stock. QALS — inspection lot data. Diagnostic workflow Confirm the physical delivery: material, quantity, batch/serial, supplier, and delivery note. Check the purchase order in ME23N for expected quantity, open quantity, delivery status, and blocks. Attempt or review the goods receipt posting in MIGO and capture the exact error message. Verify material master plant/storage location/batch settings and quality inspection requirements. Check whether stock was already posted elsewhere or the PO was already delivery-completed. Post the receipt correctly, or document the variance and route to procurement/quality/logistics. Typical fixes or next actions Reverse the incorrect receipt and repost against the correct PO item or quantity. Update the PO quantity or remove the delivery-completed indicator if the delivery is legitimate. Extend the material master to the required plant/storage location or resolve batch/serial issues. Process the inspection lot usage decision if stock is held in quality inspection. Coordinate with procurement if supplier deliveries repeatedly mismatch PO terms. Support takeaway Goods receipt diagnostics should always reconcile physical evidence, purchase order history, and material document data. A useful ticket should include: material number, PO number, delivery note, quantity expected versus received, exact error message, plant/storage location, and whether the issue is recurring. Boundaries and non-goals This page is a diagnostic frame, not a warehouse management or quality management configuration guide. It does not cover advanced EWM putaway, QM inspection plans, or customs/inbound logistics scenarios. Escalation signals Receipt failures affect multiple users, plants, or materials at the same time. The issue involves a closed accounting period, inventory valuation, or intercompany transfer. Quality inspection stock is blocked and operations cannot use the material. Supplier deliveries repeatedly mismatch PO terms and procurement must review the relationship. Related pages Procure to Pay Map GR/IR Clearing Explained SAP Invoice Verification Diagnostics SAP Three-Way Match Diagnostics SAP Purchase Order Creation Diagnostics SAP Material Document Diagnostics SAP Movement Types Diagnostics ================================================== PAGE: SAP IDoc Diagnostics URL: https://dkharlanau.github.io/atlas/diagnostics/sap-idoc-diagnostics/ SECTION: diagnostics DOMAIN: SAP AMS TYPE: diagnostic guide SAP AREA: IDoc / ALE BUSINESS PROCESS: Cross-system integration TAGS: sap-ams, idoc, ale, integration, diagnostics REVIEWED: 2026-06-13 ---------------------------------------- Home Knowledge Atlas Diagnostics SAP IDoc Diagnostics Atlas Diagnostic SAP IDoc diagnostics Trace IDoc failures from creation through partner profile to final posting status. ProcessCross-system integration SAP areaIDoc / ALE Reviewed13 Jun 2026 IndexingIndex, reviewed Core idea IDocs fail at four points: creation, dispatch, receipt, and application posting. The status monitor shows the last failure, but the first error status in the history usually points to the real cause. The diagnostic job is to read the history from oldest to newest and trace the first error to partner profile, port, segment, or application validation. Common symptoms Expected business document was not created from an inbound IDoc. Outbound IDoc was not sent to the partner system. IDoc shows status 51, 56, or 62 in the status monitor. IDoc was sent but the receiving system reports a format error. Duplicate IDocs create duplicate business documents. Likely causes Partner profile missing: the logical system or partner is not configured for the message type. Port issue: RFC or file port used by the IDoc is unavailable. Segment error: mandatory segment is missing or a value violates the IDoc type definition. Application posting error: the IDoc arrived correctly but the business document failed validation. Queue issue: qRFC queue is stuck and prevents sequential processing. Duplicate IDoc: same message was resent and processed twice. Where to check in SAP WE02 / WE05 — IDoc status monitor. WE20 — partner profiles. WE21 — port definitions. BD87 — IDoc reprocessing. SM58 — asynchronous RFC errors. SMQ1 / SMQ2 — qRFC outbound and inbound queues. Key tables / transactions / objects EDIDC — IDoc control record. EDIDD — IDoc data segments. EDIDS — IDoc status records. EDPP1 / EDP13 — partner profile message control. TBDLS — logical systems. Diagnostic workflow Find the IDoc number from the business document reference or message trace. Open WE02/WE05 and review the status history from creation to final status. Identify the first error status and its text. For outbound errors, check partner profile, port, and RFC destination. For inbound errors, check segment data, business document validation, and queue status. Fix the root cause before reprocessing. Typical fixes or next actions Maintain the missing partner profile or message type assignment. Restore the RFC or file port used for transmission. Correct segment values or mapping in the sending system. Fix the underlying business document validation error and reprocess. Clear the qRFC queue and reprocess in correct sequence. What to capture first Before routing the issue, capture: IDoc number, direction, message type, partner, first error status, and error text. Reprocessing without fixing the cause produces more failed IDocs and makes the original failure harder to read. Boundaries and non-goals This page is a diagnostic frame, not an IDoc configuration guide. It does not cover partner profile setup, port or RFC destination configuration, IDoc segment design, or AIF mapping. It does not replace SAP's IDoc and ALE documentation. This is not official SAP documentation and not a replacement for system-specific analysis. Related diagnostics SAP IDoc Status Diagnostics SAP ALE Distribution Model Diagnostics SAP qRFC / tRFC Diagnostics ================================================== PAGE: SAP IDoc Status Diagnostics URL: https://dkharlanau.github.io/atlas/diagnostics/sap-idoc-status-diagnostics/ SECTION: diagnostics DOMAIN: SAP AMS TYPE: diagnostic guide SAP AREA: IDoc / ALE / EDI BUSINESS PROCESS: Integration TAGS: integration, sap-ale, diagnostics, idoc REVIEWED: 2026-06-13 ---------------------------------------- Home Knowledge Atlas Diagnostics SAP IDoc Status Diagnostics Atlas Diagnostic SAP IDoc status diagnostics A first-pass structure for interpreting IDoc status codes and deciding the next action based on status. ProcessIntegration SAP areaIDoc / ALE / EDI IndexingIndex, reviewed Core idea IDoc status codes map a failure to a layer: application (51), processing function (56), ready for dispatch (64), control record (75), or port transmission (02). The diagnostic job is to use the status to choose the right layer, collect the evidence, and avoid reprocessing until the cause is fixed. Common symptoms IDoc stuck in status 64 and not processed. IDoc in status 51 with application error text that is not immediately clear. IDoc in status 56 with 'IDoc added' but no further processing. Inbound IDoc in status 53 but the business document was not created. Outbound IDoc in status 03 but the partner reports it never arrived. Likely causes Status 51 — application error: the IDoc passed syntax and partner checks but failed during application posting. Often master data or business rule issue. Status 56 — IDoc missing: the IDoc was added to the system but the processing function could not be found or is not assigned. Status 64 — not processed: the IDoc is waiting for a background job or manual trigger to process. Status 75 — control record error: the control record contains invalid partner, message type, or port information. Status 02 — error passing data to port: the port or RFC destination is misconfigured or unreachable. Where to check in SAP WE02 / WE05 — IDoc list and detailed display with status history. BD87 — IDoc reprocessing and status change. SM58 — tRFC error log if the IDoc uses RFC. SMQ1 / SMQ2 — qRFC queues if queued RFC is involved. SLG1 — application log for detailed error messages. Key tables / transactions / objects EDIDC — IDoc control record. EDIDS — IDoc status records. EDID4 / EDID3 — IDoc data records (version-dependent). TBD41 / TBD42 — status code definitions. Diagnostic workflow Identify the IDoc number and the current status from WE02 or WE05. Read the status text and any error messages in the status history. Map the status to the layer: syntax (status 60+), partner/profile (status 56, 75), application (status 51), or transmission (status 02, 03). For status 51, check the application log (SLG1) and the specific error text for master data or business rule issues. For status 64, check if the background job (RBDAPP01) is scheduled and running. For status 02 or 03, check the port, RFC destination, and partner profile. Typical fixes or next actions Reprocess the IDoc with BD87 after correcting the underlying master data or configuration issue. Trigger the background job (RBDAPP01) if IDocs are stuck in status 64. Correct the partner profile or port configuration if the IDoc fails at the profile layer. Fix the control record data if status 75 indicates invalid partner or message type. If the IDoc is corrupted and cannot be reprocessed, request a resend from the partner system. What to capture first Before routing the issue, capture: IDoc number, direction, message type, partner, current status, status history, and error text. Note whether the failure is isolated or affects multiple IDocs. Status is the primary signal, but the error text and history turn the status into an actionable next step. Boundaries and non-goals This page is a diagnostic frame, not an IDoc configuration guide. It does not cover partner profile setup, port configuration, or AIF mapping. It does not replace SAP's IDoc documentation. This is not official SAP documentation and not a replacement for system-specific analysis. Related Atlas Pages Idoc Aif Integration Diagnostics SAP Inbound Processing Diagnostics SAP Outbound Processing Diagnostics ================================================== PAGE: SAP Inbound Processing Diagnostics URL: https://dkharlanau.github.io/atlas/diagnostics/sap-inbound-processing-diagnostics/ SECTION: diagnostics DOMAIN: SAP AMS TYPE: diagnostic guide SAP AREA: IDoc / ALE / inbound BUSINESS PROCESS: Integration TAGS: integration, sap-ale, diagnostics, inbound REVIEWED: 2026-06-13 ---------------------------------------- Home Knowledge Atlas Diagnostics SAP Inbound Processing Diagnostics Atlas Diagnostic SAP inbound processing diagnostics A first-pass structure for finding why an inbound message was not received, not posted, or created wrong data. ProcessIntegration SAP areaIDoc / ALE / inbound IndexingIndex, reviewed Core idea Inbound processing is the path from an external system into SAP. When an inbound IDoc or message is missing, stuck in status, or posts wrong data, the support goal is to trace the path from receipt through syntax check, partner profile validation, and application posting to identify where it failed and why. Common symptoms Partner reports a message was sent but no IDoc exists in SAP. Inbound IDoc exists but is stuck in status 64 or 51. IDoc posted successfully but the business document has wrong data. Inbound IDoc creates duplicate business documents. Inbound processing is slow and messages accumulate in the queue. Likely causes Receipt failure: the IDoc never arrived due to network, RFC, or gateway issues. Syntax error: the IDoc structure does not match the expected segment definition. Partner profile mismatch: the sender partner or message type is not configured in the inbound partner profile. Application error: the IDoc passed syntax and profile checks but failed during posting due to master data or business rules. Queue bottleneck: inbound qRFC queues are not processing fast enough. Where to check in SAP WE02 / WE05 — IDoc list filtered by direction 1 (inbound) and partner. SM58 — tRFC error log for inbound RFC failures. SMQ2 — inbound qRFC queue status. SM21 — system log for gateway or connection errors. SLG1 — application log for posting errors. Key tables / transactions / objects EDIDC / EDIDS — IDoc control and status. TRFCQIN — inbound qRFC queue. ARFCSSTATE — tRFC status. Diagnostic workflow Confirm the partner sent the message and capture the message ID or timestamp. Check WE02 for the IDoc with direction 1 (inbound) and the sender partner. If the IDoc does not exist, check SM21 for gateway errors and SM58 for RFC failures. If the IDoc exists, check its status and status history for the failure layer. For status 51, check SLG1 for the application error details. For queue delays, check SMQ2 for queue depth and processing status. Typical fixes or next actions Request a resend from the partner if the IDoc never arrived. Fix syntax errors by correcting the segment data or updating the partner's mapping. Update the inbound partner profile to accept the message type and sender. Fix master data or business rule issues before reprocessing status 51 IDocs. Increase queue processing capacity or tune the queue scheduler if messages accumulate. Support takeaway Inbound issues are usually receipt, syntax, or application posting problems. A useful ticket should include: sender partner, message type, IDoc number if it exists, expected business document, actual result, and any error text from WE02, SM58, or SLG1. Boundaries and non-goals This page is a diagnostic frame, not an inbound processing configuration guide. It does not cover IDoc segment design, partner profile setup, or gateway configuration. It does not replace SAP's IDoc documentation. This is not official SAP documentation and not a replacement for system-specific analysis. Related Atlas Pages Idoc Aif Integration Diagnostics SAP Idoc Status Diagnostics SAP Integration Error Handling Diagnostics ================================================== PAGE: SAP Incident Triage Diagnostics URL: https://dkharlanau.github.io/atlas/diagnostics/sap-incident-triage-diagnostics/ SECTION: diagnostics DOMAIN: SAP AMS TYPE: diagnostic guide SAP AREA: Incident management / triage BUSINESS PROCESS: SAP AMS support TAGS: sap-ams, incident-management, triage, support, diagnostics REVIEWED: 2026-06-13 ---------------------------------------- Home Knowledge Atlas Diagnostics SAP Incident Triage Diagnostics Atlas Diagnostic SAP incident triage diagnostics A first-pass structure for classifying and routing SAP support incidents. ProcessSAP AMS support SAP areaIncident management / triage IndexingIndex, reviewed Core idea Good triage prevents wrong teams, missing evidence, and wasted time. The diagnostic goal in the first minutes is to classify the incident by symptom area, urgency, and the minimum evidence needed before assignment. Common symptoms Incident description is vague or only says 'system is slow'. Ticket is routed to a team that does not own the failing area. Multiple users report different symptoms for the same underlying issue. Incident is treated as urgent but has no business impact yet. Previous incidents for the same symptom were closed without root cause. Likely causes Missing classification: the ticket lacks module, process, or object information. Incorrect routing: routing rules rely on keywords that do not match the actual failure area. Insufficient evidence: logs, error messages, or timestamps were not collected. Urgency mismatch: priority is set by who reported it, not by business impact. No known-pattern link: the symptom matches a known diagnostic page but was not checked. Where to check in SAP Ticket fields — module, process, object, error text, time, user. Atlas/Skill Hub diagnostic index — find a matching pattern. System status monitors — SM50, SM66, SM37 for workload or job issues. Application log (SLG1) or short dumps (ST22) for the time window. Recent changes — transports, jobs, master data updates. Key tables / transactions / objects Incident/ticket system — classification and routing metadata. SM50 / SM66 — work process overview. TBTCO — background job status. Diagnostic workflow Read the ticket and extract: symptom, process area, object key, time, user, and business impact. Classify as master data, configuration, integration, authorization, batch, or performance. Check for matching diagnostic pages or known patterns in the Atlas. Collect minimum evidence: error text, status, log object, or job name. Set priority based on business impact, not reporter seniority. Route to the team that owns the component and attach the evidence. Typical fixes or next actions Add mandatory classification fields to the incident form. Maintain routing rules based on object type and module keywords. Link frequently seen symptoms to diagnostic pages in the knowledge base. Create an evidence checklist for each major symptom category. Review closed incidents for recurring patterns and update triage guidance. Support takeaway Triage tickets are most useful when they include a clear symptom, process area, affected object, time, user, and the business impact that justifies the priority. Boundaries and non-goals This page is a triage diagnostic, not an ITIL incident-management process guide. It does not cover SLA definitions or escalation policies. This is not official SAP documentation and not a replacement for system-specific analysis. ================================================== PAGE: SAP Interface Monitoring Diagnostics URL: https://dkharlanau.github.io/atlas/diagnostics/sap-interface-monitoring-diagnostics/ SECTION: diagnostics DOMAIN: SAP AMS TYPE: diagnostic guide SAP AREA: IDoc / ALE / monitoring BUSINESS PROCESS: Integration TAGS: integration, sap-ale, diagnostics, monitoring REVIEWED: 2026-06-13 ---------------------------------------- Home Knowledge Atlas Diagnostics SAP Interface Monitoring Diagnostics Atlas Diagnostic SAP interface monitoring diagnostics A first-pass structure for finding why interface monitoring misses failures, generates false alerts, or does not cover critical paths. ProcessIntegration SAP areaIDoc / ALE / monitoring IndexingIndex, reviewed Core idea Interface monitoring is only useful if it alerts the right person before the business reports the failure. Most monitoring gaps are not tool failures; they are scope gaps, thresholds set too high, jobs that stopped running, or new interfaces that were never onboarded. The diagnostic job is to compare what the tool checks against what actually failed. Common symptoms Business users report missing data before the monitoring team is aware. Monitoring dashboard shows green status but IDocs are stuck in error. Alert fatigue from false positives causes real failures to be ignored. New interface went live but was not added to monitoring scope. Monitoring job fails or runs too slowly to catch issues in time. Likely causes Monitoring scope gap: the monitoring job or tool only checks specific message types, partners, or status codes, missing others. Threshold too high: the alert threshold is set to a count or age that does not trigger for small but critical failures. Job failure or delay: the monitoring background job failed, was not scheduled, or runs infrequently. Wrong monitoring object: the tool monitors queue depth but not IDoc status, or monitors RFC but not application errors. New interface not onboarded: the interface was deployed without updating the monitoring configuration. Where to check in SAP SM37 — background job log for monitoring jobs. WE02 / WE05 — IDoc status overview to compare with monitoring results. SMQ1 / SMQ2 — qRFC queue status if queue monitoring is used. SM58 — tRFC error log. SLG1 — application log for monitoring tool errors. Key tables / transactions / objects EDIDC / EDIDS — IDoc control and status. TRFCQOUT / TRFCQIN — tRFC queue tables. TBTCO — background job status. Diagnostic workflow Identify the interface path, message type, and partner that was not monitored. Check the monitoring job log (SM37) for failures, delays, or scope limitations. Compare the monitoring configuration with the actual IDoc or queue status in WE02 / SMQ1. Verify the alert thresholds: count, age, or status codes that trigger alerts. Check if the new interface was added to the monitoring scope during deployment. Review the escalation path: who receives alerts and whether they are actionable. Typical fixes or next actions Expand the monitoring scope to cover all critical message types and partners. Lower the alert threshold or add secondary alerts for high-priority interfaces. Fix or reschedule the monitoring background job. Add new interfaces to monitoring as part of the deployment checklist. Tune the monitoring tool to reduce false positives while maintaining sensitivity for real failures. What to capture first Before routing the issue, capture: interface path, message type, partner, expected versus actual monitoring behavior, monitoring job name, and any recent change to the interface or monitoring setup. If the tool reports green while IDocs are stuck in error, the scope or threshold is usually wrong. Boundaries and non-goals This page is a diagnostic frame, not an interface monitoring configuration guide. It does not cover specific monitoring tools (SolMan, SAP Cloud ALM, third-party) or alert routing design. It does not replace SAP's operations documentation. This is not official SAP documentation and not a replacement for system-specific analysis. Related Atlas Pages Idoc Aif Integration Diagnostics SAP Idoc Status Diagnostics SAP Qrfc Trfc Diagnostics ================================================== PAGE: SAP Invoice Verification Diagnostics URL: https://dkharlanau.github.io/atlas/diagnostics/sap-invoice-verification-diagnostics/ SECTION: diagnostics DOMAIN: SAP AMS TYPE: diagnostic guide SAP AREA: MM invoice verification BUSINESS PROCESS: Procure to pay TAGS: procure-to-pay, sap-mm, diagnostics, invoice-verification REVIEWED: 2026-06-13 ---------------------------------------- Home Knowledge Atlas Diagnostics SAP Invoice Verification Diagnostics Atlas Diagnostic SAP invoice verification diagnostics A first-pass structure for separating invoice blocks caused by price, quantity, tax, or reference mismatches. ProcessProcure to pay SAP areaMM invoice verification IndexingIndex, reviewed Core idea Invoice verification is the control point where the supplier's bill is matched against purchase order and goods receipt evidence. A blocked invoice is usually process evidence, not a system error. The support goal is to identify which mismatch element triggered the block and whether it reflects a real discrepancy or a data timing issue. In practice, most invoice blocks resolve to one of four variance types—price, quantity, tax, or reference—and the fastest path to resolution is comparing the invoice line against PO history before adjusting tolerance or master data. Common symptoms Invoice posts with a blocking reason that prevents automatic payment. MIRO shows price, quantity, or tax differences beyond tolerance. Invoice references a purchase order item that has no goods receipt or partial receipt. Multiple invoices for the same PO item create duplicate payment risk. Tax code or tax jurisdiction mismatch prevents posting. Likely causes Price variance: invoice price differs from PO price beyond the configured tolerance. May be a valid supplier price change or a wrong PO price. Quantity variance: invoice quantity exceeds GR quantity. May indicate partial delivery, returns not processed, or duplicate invoicing. Reference mismatch: invoice references wrong PO number, item, or delivery note. Common with consolidated invoices or supplier numbering changes. Tax mismatch: tax code on invoice differs from PO or supplier master. Often caused by jurisdiction changes or supplier tax registration updates. Timing issue: GR was posted after invoice was entered, or invoice arrived before PO was released. Master data issue: supplier not extended to company code, payment terms mismatch, or tax number invalid. Where to check in SAP MIRO / MIR7 — invoice entry and blocking reason display. ME23N — purchase order history showing GR and IR quantities. MIR4 — invoice document display with variance details. MRBR — blocked invoices report and release. FBL1N — supplier line items to see if invoice was posted but blocked. PO history tab — compare ordered, delivered, and invoiced quantities. Key tables / transactions / objects RBKP — invoice document header. RSEG — invoice document items. EKBE — PO history (GR and IR records). LFA1 / LFB1 — supplier master (general and company code). T169 — tolerance groups for invoice verification. Diagnostic workflow Confirm the PO number, item, and supplier on the invoice match the system record. Check PO history (EKBE) for GR quantity and IR quantity. Identify the gap. Review the blocking reason in RBKP, MIR4, or MRBR. Determine if it is price, quantity, tax, or reference. Check tolerance settings to see if the variance is within acceptable limits. If the variance is valid, document the business reason and release. If not, return to supplier or correct master data. Verify that releasing the invoice will not create a duplicate payment. Typical fixes or next actions Release the invoice with documented approval if the variance is within business tolerance. Correct the PO price or quantity if the original document was wrong. Post a subsequent debit or credit memo if the supplier issued a corrected invoice. Update supplier master data (tax code, payment terms) if the mismatch stems from master data. Escalate to procurement if the supplier repeatedly invoices outside agreed terms. What to capture first Before routing the ticket, capture: PO number, invoice number, supplier, variance type (price/quantity/tax/reference), expected versus actual values, and whether the issue is recurring. A blocked invoice should not be released without a documented variance reason and business approval. Escalation signals The variance exceeds the buyer's or finance team's delegated authority and needs procurement/finance approval. The same supplier repeatedly invoices outside PO terms, suggesting a contractual or master-data problem. Releasing the invoice would create a duplicate payment or bypass a required tax review. The block involves complex tax jurisdiction, intercompany, or EDI invoicing scenarios outside standard MM support scope. Boundaries and non-goals This page is a diagnostic frame, not an invoice verification configuration guide. It does not cover automatic invoice verification setup, EDI invoicing, or complex tax scenarios. It does not replace the judgment of a finance controller or procurement manager. This is not official SAP documentation and not a replacement for system-specific analysis. Next diagnostic steps Procure to Pay Map — use this map to connect invoice blocks to the full procure-to-pay workflow. SAP Goods Receipt Diagnostics — go here when the invoice block is caused by GR timing or quantity differences. SAP Three-Way Match Diagnostics — check this to reconcile PO, GR, and invoice data. SAP Purchase Order Creation Diagnostics — use this when the invoice references a wrong or blocked PO. Practical checklist - [ ] Collect invoice number, PO number, item, supplier, and blocking reason. **Synthetic example:** invoice 1234567890, PO 9876543210, block "Quantity variance". - [ ] Check MIRO/MIR4 and PO history (EKBE) for ordered, delivered, and invoiced quantities. - [ ] Compare invoice price, quantity, and tax code against PO and GR within tolerance (T169). - [ ] Confirm no duplicate invoice exists for the same PO item before releasing. - [ ] Document the variance reason and the approver who authorized release. - [ ] Safety limit: do not release blocked invoices that would cause duplicate payment or exceed tolerance without documented approval. Related Atlas Pages SAP Mm Procurement Overview Gr Ir Clearing Explained SAP Goods Receipt Diagnostics SAP Three Way Match Diagnostics ================================================== PAGE: SAP Key Mapping Diagnostics URL: https://dkharlanau.github.io/atlas/diagnostics/sap-key-mapping-diagnostics/ SECTION: diagnostics DOMAIN: SAP AMS TYPE: diagnostic guide SAP AREA: Key mapping / multi-system BUSINESS PROCESS: Master data governance TAGS: master-data, sap-mdg, diagnostics, integration REVIEWED: 2026-06-13 ---------------------------------------- Home Knowledge Atlas Diagnostics SAP Key Mapping Diagnostics Atlas Diagnostic SAP key mapping diagnostics A first-pass structure for finding why objects have different keys across systems, causing duplicates, broken links, or failed replications. ProcessMaster data governance SAP areaKey mapping / multi-system IndexingIndex, reviewed Core idea In multi-system SAP landscapes, the same business object may have different keys in different systems. Key mapping maintains the relationship between these keys. When mapping is missing, wrong, or inconsistent, replication creates duplicates, interfaces fail, and reporting produces fragmented results. The support goal is to identify which object type is affected, which systems are involved, and whether the gap is in the mapping table, the replication model, or the interface logic. The first question to answer is whether the object was created directly in the target system. Manual creation is the most common reason a mapping entry is missing. Common symptoms Replication creates a new object in the target system instead of updating the existing one. Interface reports 'object not found' even though the object exists under a different key. Reporting or analytics shows duplicate records for the same business entity. MDG or ALE replication log shows key mapping errors. Customer or vendor number in S/4 does not match the corresponding BP number or external system key. Likely causes Missing mapping entry: the object was created directly in the target system without going through the mapping process. Wrong mapping entry: the source key is mapped to a different target key than intended. Number range conflict: source and target systems use overlapping number ranges, causing collisions. Mapping table not maintained for new object type: the interface or replication expects mapping but the object type was recently added and mapping is not set up. Manual creation bypass: the object was created manually in the target system, bypassing the mapping logic. Where to check in SAP Key mapping tables — landscape-specific tables that map source keys to target keys. MDG key mapping UI — if MDG manages the mapping. WE02 — IDoc status for ALE replication to see if key mapping errors are reported. Object display in both source and target systems — compare keys and attributes. Number range status (SNRO) — check if ranges overlap between systems. Key tables / transactions / objects Key mapping tables — landscape-specific (e.g., USMD1700 for MDG). CVI_LINK — CVI link between BP and customer/vendor. NRIV — number range intervals. Diagnostic workflow Identify the object type, source system key, target system, and expected target key. Check the key mapping table or MDG key mapping UI for an existing entry. If no entry exists, determine if the object was created manually in the target system or if the mapping was never maintained. If the entry exists but is wrong, trace how the wrong mapping was created. Check number ranges in both systems for overlaps or conflicts. Verify the interface or replication model uses the correct mapping logic. Typical fixes or next actions Create the missing key mapping entry between source and target systems. Correct the wrong mapping entry and evaluate the impact on existing transactions. Adjust number ranges to prevent future collisions. If duplicates were created, evaluate merge, deactivation, or re-keying options with master data governance. Update the interface or replication model to enforce mapping for new object types. What to capture first Key mapping issues are usually maintenance gaps or number range conflicts. Capture: object type, source system, source key, target system, expected target key, actual target key, and whether the object was created manually or via replication. Boundaries and non-goals This page is a diagnostic frame, not a key mapping configuration guide. It does not cover number range design, MDG key mapping setup, or interface mapping logic. It does not replace SAP's multi-system integration documentation. This is not official SAP documentation and not a replacement for system-specific analysis. Related Atlas Pages SAP Business Partner Replication Diagnostics SAP Mdg To S4 Replication Diagnostics SAP Vendor Master Replication Diagnostics SAP Customer Master Replication Diagnostics ================================================== PAGE: SAP Material Document Diagnostics URL: https://dkharlanau.github.io/atlas/diagnostics/sap-material-document-diagnostics/ SECTION: diagnostics DOMAIN: SAP AMS TYPE: diagnostic guide SAP AREA: MM inventory management BUSINESS PROCESS: Inventory / Logistics TAGS: procure-to-pay, sap-mm, diagnostics, inventory-management REVIEWED: 2026-06-13 ---------------------------------------- Home Knowledge Atlas Diagnostics SAP Material Document Diagnostics Atlas Diagnostic SAP material document diagnostics A first-pass structure for finding why a goods movement document is missing, incorrect, or cannot be reversed. ProcessInventory / Logistics SAP areaMM inventory management IndexingIndex, reviewed Core idea Every goods movement in SAP creates a material document that records what moved, where, when, and with what accounting impact. When a document is missing, shows wrong quantities, posts to wrong accounts, or cannot be reversed, the support goal is to trace the document chain, identify the mismatch, and determine if a correction movement or reversal is needed. Common symptoms User reports a goods movement was posted but no material document exists. Material document shows wrong quantity, movement type, or storage location. Reversal fails because the original document is already reversed or cleared. Accounting document linked to the material document shows unexpected GL accounts. Goods movement posted in wrong period and period is now closed. Likely causes User error: wrong quantity, movement type, or storage location entered during posting. Document not saved: the user thought the document was posted but it was only simulated or an error prevented commit. Already reversed: the original document was reversed earlier and a second reversal is not allowed. Period closed: the posting period for MM or FI is closed, preventing new documents or reversals. Valuation mismatch: the material document triggers a valuation that does not match the material's current valuation class or price. Where to check in SAP MIGO — display material document by document number. MB51 — material documents list, filter by material, plant, or movement type. MBST — reversal transaction and error messages. MMRV — allow posting to previous period. FB03 — display accounting document linked to the material document. Key tables / transactions / objects MKPF — material document header. MSEG — material document items. BKPF / BSEG — accounting documents. MBEW — material valuation. Diagnostic workflow Identify the material document number or the expected document that is missing. Check MIGO or MB51 for the document details: material, plant, storage location, movement type, quantity. Verify the accounting document in FB03 to confirm GL accounts and amounts. If reversal is needed, check MBST for the reversal status and any error messages. Check posting period status if the reversal or new posting fails. Determine if the correction should be a reversal, a return movement, or a manual adjustment. Typical fixes or next actions Reverse the incorrect document with MBST if the period is open and the document is not already reversed. Re-post the movement with correct data if the original was wrong. Open the posting period temporarily if the correction is urgent and authorized. If reversal is not possible, use a compensating movement to correct stock or accounting. Document the correction with business justification and approval. Support takeaway Material document issues are usually user entry or timing problems. A useful ticket should include: material, plant, movement type, expected versus actual quantity, document number if it exists, and the business reason for correction. Escalation signals A material document was posted to the wrong material, plant, or storage location and must be reversed. The reversal affects inventory valuation, cost accounting, or a closed accounting period. Multiple documents show the same unexpected movement type or account assignment. The document ties to a production order, sales delivery, or physical inventory adjustment that needs cross-team validation. Boundaries and non-goals This page is a diagnostic frame, not a material document configuration guide. It does not cover WM transfer orders, EWM goods movements, or period-end closing procedures. It does not replace SAP's inventory management documentation. This is not official SAP documentation and not a replacement for system-specific analysis. Related Atlas Pages SAP Movement Types Diagnostics SAP Goods Receipt Diagnostics SAP Stock Transfer Diagnostics ================================================== PAGE: SAP Movement Types Diagnostics URL: https://dkharlanau.github.io/atlas/diagnostics/sap-movement-types-diagnostics/ SECTION: diagnostics DOMAIN: SAP AMS TYPE: diagnostic guide SAP AREA: MM inventory management BUSINESS PROCESS: Procure to pay / Inventory TAGS: procure-to-pay, sap-mm, diagnostics, inventory-management REVIEWED: 2026-06-13 ---------------------------------------- Home Knowledge Atlas Diagnostics SAP Movement Types Diagnostics Atlas Diagnostic SAP movement types diagnostics A first-pass structure for finding why a goods movement posts to the wrong stock type, account, or status. ProcessProcure to pay / Inventory SAP areaMM inventory management IndexingIndex, reviewed Core idea Movement types in SAP define the direction, stock type, and accounting impact of every goods movement. A wrong movement type does not just misclassify stock — it can post to the wrong account, trigger wrong valuation, create incorrect GR/IR records, or leave inventory in an unusable status. The support goal is to identify which movement type was used, whether it matches the business intent, and what correction is needed. Common symptoms Goods receipt posted stock to quality inspection instead of unrestricted. Transfer posting created an unexpected accounting entry. Return to vendor did not reduce GR/IR or created a wrong reversal. Movement type is not allowed for the material type or plant. Inventory count adjustment posted to a consumption account instead of inventory. Likely causes Wrong movement type selected: user chose 101 instead of 103, or 311 instead of 301, changing stock type or valuation. Movement type not configured for material type: the material type restricts which movements are allowed. Account modification mismatch: the movement type posts to a G/L account that does not match the material's valuation class. Stock type confusion: unrestricted, quality inspection, blocked, or in transit were not distinguished correctly. Custom movement type: a landscape-specific movement type behaves differently from standard and is not documented. Where to check in SAP MIGO — display the material document and check the movement type on each item. MB51 — material documents list, filter by movement type and material. OMJJ — movement type configuration (transaction-dependent, view-only in production). MB52 — stock overview showing stock types per storage location. Material master — check material type and valuation class. Key tables / transactions / objects T156 — movement types. T156T — movement type texts. MKPF — material document header. MSEG — material document items. MBEW — material valuation. Diagnostic workflow Identify the material document number and item from the user report or error. Check MIGO or MB51 for the movement type used and compare with the business intent. Verify the stock type before and after the movement in MB52. Check if the movement type is allowed for the material type and plant. Review the accounting document (FI) to see if the G/L accounts match expectations. Determine if the movement should be reversed and re-posted with the correct type. Typical fixes or next actions Reverse the incorrect movement with the reversal movement type and re-post correctly. Update user training or MIGO defaults to prevent repeated wrong selection. If the movement type configuration is wrong, escalate to the configuration team with documented evidence. For stock type issues, perform a transfer posting to move stock to the correct status. Support takeaway Movement type errors are often user selection issues, not system bugs. Before escalating, collect the material document number, the movement type used, the expected movement type, the material, plant, and storage location. A useful movement type ticket should show the business intent and the system result. Escalation signals The same wrong movement type is used repeatedly, suggesting training or process design issues. A correction movement affects inventory valuation, financial accounts, or month-end closing. The movement type behavior differs between plants or clients and configuration review is needed. The issue involves special stock (consignment, subcontracting, pipeline) with accounting implications. Boundaries and non-goals This page is a diagnostic frame, not a movement type configuration guide. It does not cover custom movement type design, WM movement types, or EWM-specific logic. It does not replace SAP's inventory management documentation. This is not official SAP documentation and not a replacement for system-specific analysis. Related Atlas Pages SAP Goods Receipt Diagnostics SAP Material Document Diagnostics SAP Batch Determination Diagnostics SAP Mm Procurement Overview ================================================== PAGE: SAP Outbound Processing Diagnostics URL: https://dkharlanau.github.io/atlas/diagnostics/sap-outbound-processing-diagnostics/ SECTION: diagnostics DOMAIN: SAP AMS TYPE: diagnostic guide SAP AREA: IDoc / ALE / outbound BUSINESS PROCESS: Integration TAGS: integration, sap-ale, diagnostics, outbound REVIEWED: 2026-06-13 ---------------------------------------- Home Knowledge Atlas Diagnostics SAP Outbound Processing Diagnostics Atlas Diagnostic SAP outbound processing diagnostics A first-pass structure for finding why an outbound message was not created, not sent, or arrived corrupted at the partner. ProcessIntegration SAP areaIDoc / ALE / outbound IndexingIndex, reviewed Core idea Outbound processing is the path from a SAP business document to an external system. When an expected outbound message is missing, stuck in the system, or arrives corrupted at the partner, the support goal is to trace the path from document creation through output determination, IDoc generation, and transmission to identify where it failed. Common symptoms Business document was created but no outbound IDoc was generated. Outbound IDoc exists but is stuck in status 30 or 03. Partner reports receiving the message but the data is wrong or incomplete. Multiple outbound IDocs were generated for the same business document. Outbound processing is slow and messages accumulate. Likely causes Output not determined: the output condition technique did not trigger the outbound message for this document. Partner profile missing: the receiver partner or message type is not configured in the outbound partner profile. IDoc generation error: the IDoc was created but failed during segment population due to missing master data. Transmission failure: the IDoc was generated but the RFC destination or port is unreachable. Duplicate trigger: the output was triggered multiple times due to document changes or custom logic. Where to check in SAP WE02 / WE05 — IDoc list filtered by direction 2 (outbound) and partner. NAST — output messages for the business document. WE20 — partner profile outbound parameters. SM59 — RFC destination test. SMQ1 — outbound qRFC queue status. Key tables / transactions / objects EDIDC / EDIDS — IDoc control and status. NAST — output messages. TRFCQOUT — outbound qRFC queue. Diagnostic workflow Identify the business document and the expected outbound message type and partner. Check NAST or the document output screen to see if the output was determined. If output was determined, check WE02 for the generated IDoc and its status. For status 30, check the partner profile (WE20) and RFC destination (SM59). For status 03, confirm with the partner whether the message was received. If the IDoc data is wrong, check the IDoc segments against the business document data. Typical fixes or next actions Create or update the output condition record if the output was not determined. Update the outbound partner profile to include the message type and receiver. Fix master data gaps that cause segment population errors. Fix the RFC destination or port configuration if transmission fails. Investigate duplicate triggers and adjust the change relevance or custom logic. Support takeaway Outbound issues are usually output determination, partner profile, or transmission problems. A useful ticket should include: business document number, message type, partner, IDoc number if it exists, expected versus actual status, and any error text from NAST, WE02, or SM59. Boundaries and non-goals This page is a diagnostic frame, not an outbound processing configuration guide. It does not cover output determination design, IDoc segment mapping, or port configuration. It does not replace SAP's IDoc documentation. This is not official SAP documentation and not a replacement for system-specific analysis. Related Atlas Pages Idoc Aif Integration Diagnostics SAP Idoc Status Diagnostics SAP Output Message Control Diagnostics ================================================== PAGE: SAP Purchase Order Creation Diagnostics URL: https://dkharlanau.github.io/atlas/diagnostics/sap-purchase-order-creation-diagnostics/ SECTION: diagnostics DOMAIN: SAP AMS TYPE: diagnostic guide SAP AREA: MM purchasing BUSINESS PROCESS: Procure to pay TAGS: procure-to-pay, sap-mm, diagnostics, purchasing REVIEWED: 2026-06-13 ---------------------------------------- Home Knowledge Atlas Diagnostics SAP Purchase Order Creation Diagnostics Atlas Diagnostic SAP purchase order creation diagnostics A first-pass structure for finding why a purchase order cannot be created, saved, or released. ProcessProcure to pay SAP areaMM purchasing IndexingIndex, reviewed Core idea Purchase order creation is the point where internal demand becomes a supplier commitment. Blocks at this stage prevent the entire procurement chain from starting. The support goal is to identify whether the block comes from master data, sourcing, release strategy, authorization, or document conversion issues. The fastest way to narrow the cause is to test the same material and supplier in ME21N directly: if manual creation works, the block is likely in automatic conversion or release strategy. Common symptoms ME21N or ME59N fails with a hard error or warning that prevents saving. Purchase requisition cannot be converted to purchase order. PO is created but immediately blocked by release strategy. Automatic PO creation from PR or MRP does not generate expected orders. PO saves but with wrong supplier, price, or delivery date. Likely causes Missing source of supply: no valid info record, source list, or quota arrangement exists for the material and plant. Supplier master issue: supplier is blocked, not extended to purchasing organization, or missing required roles. Release strategy block: the PO value, material group, or plant triggers a release strategy that requires approval. Authorization issue: the user lacks the activity or field-level authorization to create or change POs for this plant or material. PR conversion issue: the PR has a different plant, purchasing organization, or account assignment that does not match the PO context. Document type mismatch: the PR document type is not configured for automatic PO creation. Where to check in SAP ME21N / ME22N — manual PO creation and error messages. ME59N — automatic PO creation log. ME53N — purchase requisition display to check source of supply. ME23N — existing POs for the same material/supplier to compare. SU53 — authorization check after a failed transaction. Key tables / transactions / objects EKKO / EKPO — purchase order header and items. EBAN / EBKN — purchase requisition header and items. EINA / EINE — purchasing info record general and organization data. A017 — info record validity (condition). LFA1 / LFB1 — supplier master. Diagnostic workflow Identify the exact error message and transaction code where the block appears. Check if the issue is isolated to one material, supplier, plant, or user. Verify the source of supply: info record, source list, quota arrangement, or contract. Check the supplier master for blocks or missing organizational assignments. If release strategy is involved, identify the release code and who can approve. If automatic creation fails, check ME59N log for specific rejection reasons. Typical fixes or next actions Create or extend the source of supply (info record, source list) if missing. Unblock or extend the supplier master to the purchasing organization. Route the PO through the correct release strategy approval workflow. Adjust the PR to match the PO context or create the PO manually with correct data. Escalate authorization issues to the security team with SU53 evidence. What to capture first PO creation blocks are usually master data or sourcing issues, not system bugs. Capture: the PR number (if converting), material, plant, supplier, error message, transaction code, and whether the issue is new or recurring. Escalation signals PO creation fails for many users or plants, indicating a configuration or authorization change. The error relates to tax calculation, account assignment, or commitment logic that finance must validate. A supplier contract or info record appears incorrect and procurement must confirm the commercial terms. The issue blocks a business-critical procurement category or affects legal/compliance requirements. Boundaries and non-goals This page is a diagnostic frame, not a PO configuration guide. It does not cover release strategy setup, approval workflow design, or MRP batch scheduling. It does not replace SAP's purchasing documentation. This is not official SAP documentation and not a replacement for system-specific analysis. Next diagnostic steps Procure to Pay Map — use this map to relate the PO creation block to the full procure-to-pay diagnostic path. SAP Release Strategy Diagnostics — go here when the PO is created but blocked for approval. SAP Source Determination Diagnostics — check this if no source of supply is found. SAP Purchase Requisition Diagnostics — use this when the issue is converting a requisition into a purchase order. Practical checklist - [ ] Collect PR number, material, plant, purchasing organization, supplier, and exact error message. **Synthetic example:** PR 1234567890, material TEST_MAT_001, plant 0001. - [ ] Check ME21N/ME59N error log and SU53 if authorization is suspected. - [ ] Verify source of supply: info record, source list, quota arrangement, or contract in ME53N/ME23N. - [ ] Confirm supplier master is not blocked and is extended to the purchasing organization. - [ ] Check release strategy classification if the PO is created but held for approval. - [ ] Document whether the issue is isolated to one user, material, or plant. - [ ] Safety limit: do not create a PO with an unapproved supplier or bypass release strategy. Related Atlas Pages SAP Mm Procurement Overview SAP Source Determination Diagnostics SAP Release Strategy Diagnostics SAP Purchase Requisition Diagnostics ================================================== PAGE: SAP Purchase Requisition Diagnostics URL: https://dkharlanau.github.io/atlas/diagnostics/sap-purchase-requisition-diagnostics/ SECTION: diagnostics DOMAIN: SAP AMS TYPE: diagnostic guide SAP AREA: MM purchasing BUSINESS PROCESS: Procure to pay TAGS: procure-to-pay, sap-mm, diagnostics, purchasing REVIEWED: 2026-06-13 ---------------------------------------- Home Knowledge Atlas Diagnostics SAP Purchase Requisition Diagnostics Atlas Diagnostic SAP purchase requisition diagnostics A first-pass structure for finding why a purchase requisition cannot be created, approved, or converted to a purchase order. ProcessProcure to pay SAP areaMM purchasing IndexingIndex, reviewed Core idea Purchase requisition is the first document in the procure-to-pay chain. It captures internal demand but does not yet commit the organization to a supplier. When a PR is blocked, cannot be created, or fails conversion, the support goal is to identify whether the issue is in master data, account assignment, sourcing, release strategy, or user authorization. Most PR failures are not system errors: they are missing account assignments, unextended materials, or incomplete release strategies surfacing at the first document in the chain. Common symptoms ME51N fails to save or shows a hard error. PR is created but cannot be converted to PO (ME59N or ME21N). PR remains in status 'release strategy active' and cannot be approved. MRP-generated PR has wrong plant, quantity, or delivery date. PR account assignment is rejected during posting or conversion. Likely causes Master data issue: material not extended to plant, supplier blocked, or purchasing organization mismatch. Account assignment error: cost center, WBS element, or GL account is invalid or not open for posting. Release strategy block: the PR value or material group triggers an approval path that is not complete. Source determination failure: no valid info record, source list, or quota arrangement exists for automatic sourcing. Authorization issue: the user lacks authorization to create PRs for the plant, material group, or account assignment type. MRP parameter issue: lot size, safety stock, or planning horizon produced an unexpected PR quantity or date. Where to check in SAP ME53N — display PR and check status, account assignment, and source of supply. ME59N log — automatic PO creation rejection reasons. ME54N — PR release status. MD04 / MD05 — MRP list to see how the PR was generated. SU53 — authorization check after a failed transaction. Key tables / transactions / objects EBAN / EBKN — PR header and items. EKKO / EKPO — PO header and items (for converted PRs). AUFK — WBS / internal order master. CSKS — cost center master. Diagnostic workflow Identify the PR number and the exact error or status that blocks progress. Check ME53N for PR details: material, plant, quantity, account assignment, and source of supply. Verify master data: material plant extension, supplier status, and purchasing organization. Check release status if the PR is blocked for approval. Check MRP parameters if the PR was system-generated and has unexpected values. Test manual PO creation (ME21N) from the PR to isolate conversion issues. Typical fixes or next actions Correct the account assignment if the cost center or WBS element is wrong. Extend the material to the plant or unblock the supplier master. Complete the release strategy approval if the PR is blocked. Create or update the source of supply if automatic sourcing fails. Adjust MRP parameters if system-generated PRs are consistently wrong. What to capture first PR blocks are usually upstream master data or account assignment problems. Capture: PR number, material, plant, error message, account assignment, and whether the issue is isolated or recurring. When the PR came from MRP If the requisition was system-generated, treat it as an MRP exception. Verify the exception message in MD04/MD05, then check whether the root cause is a demand signal change, a supply delay, or a planning parameter in the material master. For a full diagnostic frame, see SAP MRP Exception Diagnostics. Escalation signals Requisitions are stuck across multiple users or plants, suggesting a release strategy or workflow failure. The requested material or service has no approved source, contract, or budget approval. MRP-generated requisitions repeatedly have wrong quantities, dates, or source of supply. The case requires a change to sourcing policy, approval limits, or procurement governance. Boundaries and non-goals This page is a diagnostic frame, not a PR configuration guide. It does not cover MRP logic, approval workflow design, or catalog integration. It does not replace SAP's purchasing documentation. This is not official SAP documentation and not a replacement for system-specific analysis. Related Atlas Pages SAP Purchase Order Creation Diagnostics SAP Release Strategy Diagnostics SAP Source Determination Diagnostics SAP MRP Exception Diagnostics SAP Mm Procurement Overview ================================================== PAGE: SAP qRFC and tRFC Diagnostics URL: https://dkharlanau.github.io/atlas/diagnostics/sap-qrfc-trfc-diagnostics/ SECTION: diagnostics DOMAIN: SAP AMS TYPE: diagnostic guide SAP AREA: RFC / ALE / integration BUSINESS PROCESS: Integration TAGS: integration, sap-ale, diagnostics, rfc REVIEWED: 2026-06-13 ---------------------------------------- Home Knowledge Atlas Diagnostics SAP qRFC and tRFC Diagnostics Atlas Diagnostic SAP qRFC and tRFC diagnostics A first-pass structure for finding why RFC calls are stuck, failing, or executing out of order. ProcessIntegration SAP areaRFC / ALE / integration IndexingIndex, reviewed Core idea Transactional RFC (tRFC) and queued RFC (qRFC) are the transport layers for many SAP integrations including ALE, IDoc, and custom interfaces. When RFC calls are stuck in a queue, fail with connection errors, or execute in the wrong order, the support goal is to identify whether the issue is in the RFC destination, the queue configuration, the executing function module, or the target system availability. Always test the RFC destination in SM59 before reprocessing entries in SM58 or SMQ1/SMQ2. Reprocessing a queue against a broken destination just creates the same failure again. Common symptoms SM58 shows multiple tRFC entries in error status. SMQ1 or SMQ2 shows queues with status SYSFAIL or MANUAL. IDoc status 03 but partner reports the document never arrived. RFC destination test (SM59) fails with connection or authorization error. Queue scheduler is not running or queues are not being processed. Likely causes RFC destination unreachable: the target system is down, network path is broken, or the gateway is not responding. Authorization failure: the RFC user lacks the required authorization in the target system. Queue blocked: a previous failed entry is blocking the entire queue (serialization). Function module error: the called function module fails in the target system due to data or application errors. Queue scheduler not running: the qRFC scheduler (QOUT scheduler or QIN scheduler) is not active. Where to check in SAP SM59 — RFC destination configuration and connection test. SM58 — tRFC monitor and error log. SMQ1 — outbound qRFC queue status. SMQ2 — inbound qRFC queue status. SM50 / SM66 — work process status if RFC is executing synchronously. Key tables / transactions / objects ARFCSDATA / ARFCSSTATE — tRFC data and status. TRFCQOUT / TRFCQIN — qRFC queue tables. RFCDES — RFC destination definitions. Diagnostic workflow Identify the RFC destination, function module, and the error symptom (stuck, failed, out of order). Test the RFC destination in SM59 to confirm basic connectivity. Check SM58 for tRFC errors and read the error text for each failed entry. Check SMQ1 / SMQ2 for queue status. Look for the first failed entry that may be blocking the queue. Verify the RFC user authorization in the target system if the error is authorization-related. Check if the queue scheduler is running and if the queue is registered for scheduling. Typical fixes or next actions Restart or correct the failed RFC entry in SM58 after fixing the underlying issue. Unblock the queue in SMQ1 / SMQ2 by deleting or moving the failed entry if it is blocking subsequent calls. Fix the RFC destination configuration if SM59 test fails. Update the RFC user authorization in the target system. Restart the queue scheduler if it is not running. What to capture first qRFC and tRFC issues are usually connectivity, authorization, or queue blocking problems. Capture: RFC destination, function module, queue name (if qRFC), error text, SM58 or SMQ1/SMQ2 status, and whether the issue is isolated or affecting multiple interfaces. Boundaries and non-goals This page is a diagnostic frame, not an RFC configuration guide. It does not cover RFC destination setup, SNC configuration, or load balancing. It does not replace SAP's RFC documentation. This is not official SAP documentation and not a replacement for system-specific analysis. Next diagnostic steps SAP RFC Destination Diagnostics — test connectivity and authorization for the RFC destination. IDoc and AIF Integration Diagnostics — go here when RFC errors appear together with IDoc failures. SAP Interface Monitoring Diagnostics — use this when multiple interfaces are affected at the same time. Practical checklist - [ ] Collect RFC destination, function module, queue name, and SM58/SMQ1/SMQ2 status. **Synthetic example:** destination TEST_DEST_01, queue Q_1234567890. - [ ] Test the RFC destination in SM59 and capture the connection or authorization error. - [ ] Check SM58 for failed tRFC entries and read the error text before restarting. - [ ] Check SMQ1/SMQ2 for SYSFAIL or MANUAL status and identify the first blocking entry. - [ ] Verify the RFC user authorization in the target system if authorization is suspected. - [ ] Confirm the queue scheduler is running and the queue is registered for scheduling. - [ ] Safety limit: do not delete or move a failed queue entry until the underlying cause is documented. Related Atlas Pages Idoc Aif Integration Diagnostics SAP Idoc Status Diagnostics SAP Interface Monitoring Diagnostics SAP RFC Destination Diagnostics ================================================== PAGE: SAP Release Strategy Diagnostics URL: https://dkharlanau.github.io/atlas/diagnostics/sap-release-strategy-diagnostics/ SECTION: diagnostics DOMAIN: SAP AMS TYPE: diagnostic guide SAP AREA: MM purchasing BUSINESS PROCESS: Procure to pay TAGS: procure-to-pay, sap-mm, diagnostics, purchasing REVIEWED: 2026-06-13 ---------------------------------------- Home Knowledge Atlas Diagnostics SAP Release Strategy Diagnostics Atlas Diagnostic SAP release strategy diagnostics A first-pass structure for finding why a purchase order or requisition is blocked by approval workflow. ProcessProcure to pay SAP areaMM purchasing IndexingIndex, reviewed Core idea Release strategy is the approval workflow that prevents a purchasing document from becoming a binding commitment until authorized users release it. When a document is stuck in release, the support goal is to identify which release strategy was triggered, which release codes are still open, who has the authorization to release, and whether the block is intentional or caused by a classification mismatch. The most common release cases I see are not missing approvers but classification mismatches: a changed material group or plant value selected a different strategy than the one the business expected. Common symptoms PO or PR shows status 'release strategy active' but no one can release it. Document was released but reverted to blocked status after a change. Wrong release strategy was selected — a low-value PO triggered a high-value approval path. Release approver is on leave or no longer has the required authorization. Release strategy classification values do not match the document characteristics. Likely causes Classification mismatch: the document's value, material group, or plant does not match the release strategy classification, causing the wrong strategy or no strategy to be selected. Missing release code: one or more release codes in the strategy have not been entered because the approver is unavailable or unaware. Authorization gap: the user attempting to release lacks the required authorization object for the release code and document type. Document change after partial release: changing a released document can reset the release status depending on the change relevance setting. Workflow integration failure: if workflow is used for release notification, the work item may be stuck or sent to the wrong agent. Where to check in SAP ME28 / ME29N — PO release (collective and individual). ME54N — PR release. CL20N — display classification values for the document. SWIA / SWI1 — workflow work items if workflow-driven release is used. SU53 — authorization check after a failed release attempt. Key tables / transactions / objects T16FC / T16FG — release strategy and release group definitions. CEBAN / CEKKO — release status for PR and PO. AUSP — classification values. SWW_WI_1 — workflow work items. Diagnostic workflow Identify the document number, type, and the release strategy that was selected. Check the release status to see which release codes are still open. Verify the classification values (value, material group, plant) match the expected release strategy. Check if the approver has the required authorization for the release code. If workflow is involved, check SWIA for stuck work items. Determine if the document change that triggered re-release was necessary or can be avoided. Typical fixes or next actions Route the document to the correct approver with documented business justification. Correct the classification values if the wrong release strategy was selected. Assign a delegate or temporary approver if the primary approver is unavailable. Escalate authorization issues to the security team with SU53 evidence. If workflow is stuck, restart or forward the work item after confirming the business context. What to capture first Release strategy blocks are usually process or authorization issues, not system errors. Capture: document number, release strategy, open release codes, the user who tried to release, the error message, and whether the issue is new or recurring. Escalation signals Documents are stuck because an approver is absent, inactive, or lacks authorization. The release strategy classification appears wrong for the document value, material group, or account assignment. Multiple users cannot release any documents, indicating a workflow or substitution configuration issue. The approval limit or strategy must be changed to reflect a new delegation of authority. Boundaries and non-goals This page is a diagnostic frame, not a release strategy configuration guide. It does not cover classification design, workflow builder setup, or approval hierarchy modeling. It does not replace SAP's purchasing documentation. This is not official SAP documentation and not a replacement for system-specific analysis. Next diagnostic steps Procure to Pay Map — use this map to see how release strategy fits into the wider procurement workflow. SAP Purchase Order Creation Diagnostics — go here when the release block prevents PO creation or saving. SAP Purchase Requisition Diagnostics — check this when the strategy applies to requisitions instead of purchase orders. SAP Invoice Verification Diagnostics — use this downstream if approved POs generate invoice mismatches. Practical checklist - [ ] Collect document number, type, release strategy, open release codes, and current status. **Synthetic example:** PO 1234567890, strategy ZS_001, code 01 open. - [ ] Check ME28/ME29N or ME54N for release status and missing approvers. - [ ] Verify classification values (value, material group, plant) with CL20N match the strategy. - [ ] Confirm the approver has the required authorization in SU53 after a failed release attempt. - [ ] Check SWIA/SWI1 for stuck workflow work items if workflow is used. - [ ] Document the business justification and assign a delegate if the primary approver is unavailable. - [ ] Safety limit: do not release a document whose classification or value changed after partial release without procurement confirmation. Related Atlas Pages SAP Purchase Order Creation Diagnostics SAP Purchase Requisition Diagnostics SAP Mm Procurement Overview ================================================== PAGE: SAP RFC Destination Diagnostics URL: https://dkharlanau.github.io/atlas/diagnostics/sap-rfc-destination-diagnostics/ SECTION: diagnostics DOMAIN: SAP AMS TYPE: diagnostic guide SAP AREA: Basis / ALE / RFC BUSINESS PROCESS: Integration TAGS: rfc, integration, sap-basis, diagnostics, distributed-systems REVIEWED: 2026-06-13 ---------------------------------------- Home Knowledge Atlas Diagnostics SAP RFC Destination Diagnostics Atlas Diagnostic SAP RFC destination diagnostics A first-pass structure for finding why an RFC destination fails, why tRFC or qRFC queues are stuck, or why cross-system calls return errors. ProcessIntegration SAP areaBasis / ALE / RFC IndexingIndex, reviewed Core idea RFC destinations in SAP define how one system calls another. When an RFC fails, the impact can be stuck IDocs, failed master data replication, missing transactional data, or batch job cancellations. The diagnostic task is to isolate whether the failure is in the network layer, the destination configuration, the target system availability, the user credentials, or the called function module. The SM59 connection test and authorization test separate network or credential failures from application failures in the target system. Run both before opening a Basis or security ticket. Common symptoms RFC destination test in SM59 returns "Connection refused," "Name or password incorrect," or "Program not registered." tRFC or qRFC queue in SM58 or SMQ1/SMQ2 shows repeated errors for a specific destination. IDoc is stuck in status 03 (data passed to port) but never arrives at the target system. Master data replication shows success in the source but the object is missing in the target. Background job fails with RFC-related short dump (CALL_FUNCTION_REMOTE_ERROR). Cross-system transaction fails with COMMIT_FAILURE or ROLLBACK_FAILURE. RFC performance is slow, causing timeouts in calling programs. Likely causes Network or firewall: the target system is unreachable due to network changes, firewall rules, or DNS resolution failure. Target system down: the target application server, message server, or gateway is not running. User credentials: the user in the RFC destination is locked, expired, or has incorrect password. Program not registered: for TCP/IP RFC destinations (e.g., PI/PO, external programs), the registered program is not running. Gateway or message server issue: the SAP gateway (sapgwXX) or message server is not responding. Load balancing misconfiguration: the logon group or message server parameters are incorrect. Function module error: the RFC reaches the target system but the called function module fails due to data or authorization issues. Where to check in SAP SM59 — RFC destination administration; test connection, Unicode test, and authorization test. SM58 — tRFC error log; check failed RFC calls and error texts. SMQ1 / SMQ2 — qRFC queue monitor; check outbound and inbound queues. SMGW — gateway monitor; check registered programs and active connections. SMLG — logon group load balancing; check group assignment and server availability. SM21 — system log; check for gateway or work process errors. ST22 — short dump analysis; check for RFC-related dumps in the calling or target system. AL11 — directory listing; check gateway trace files (dev_rd) if needed. Key tables / transactions / objects RFCDES / RFCDOC — RFC destination definitions. ARFCSDATA / ARFCSSTATE — tRFC execution data and status. TRFCQOUT / TRFCQIN — tRFC queue tables. SMQ1 / SMQ2 — qRFC queue monitor transactions. GWY_CONN — gateway connection table (via SMGW). USR02 — user master; check if the RFC user is locked or expired. Diagnostic workflow Identify the RFC destination name and the exact error message from SM59, SM58, or the application log. Test the connection in SM59: connection test, Unicode test, and authorization test. If the connection test fails, check network connectivity (ping, telnet to gateway port) from the Basis team. If the authorization test fails, check the user in USR02 for lock status, password expiry, or missing authorizations. Check SMGW for registered programs if the destination uses a registered RFC server program. Check SM58 for tRFC errors: note the transaction ID, error text, and retry count. Check SMQ1/SMQ2 for qRFC queue status if the destination uses queued RFC. Check ST22 in both source and target systems for RFC-related short dumps. If the connection succeeds but the function fails, check the target system application log (SLG1) for function module errors. Typical fixes or next actions Correct the RFC destination host name, IP address, or gateway service if network details changed. Unlock or reset the password for the RFC user in SU01. Restart the registered RFC program or server if it is not running. Restart the SAP gateway service (sapgwXX) if it is not responding. Reprocess tRFC errors in SM58 after fixing the underlying issue. Clear or restart qRFC queues in SMQ1/SMQ2 if they are stuck. Adjust the RFC timeout or retry settings if the issue is intermittent network latency. Escalate to the network or Basis team if the issue is infrastructure-related. What to capture first RFC destination failures are usually network, configuration, or credential issues. Capture: RFC destination name, source system, target system, exact error message, SM59 test results, and whether the issue is isolated to one destination or affects multiple. Boundaries and non-goals This page is a diagnostic frame, not an RFC configuration guide. It does not cover RFC destination creation, SNC/SSL setup, or PI/PO adapter configuration. It does not replace SAP's RFC and integration documentation. This is not official SAP documentation and not a replacement for system-specific analysis. Related Atlas Pages SAP qRFC and tRFC Diagnostics SAP IDoc Status Diagnostics SAP Interface Monitoring Diagnostics SAP ALE Distribution Model Diagnostics ================================================== PAGE: SAP Source Determination Diagnostics URL: https://dkharlanau.github.io/atlas/diagnostics/sap-source-determination-diagnostics/ SECTION: diagnostics DOMAIN: SAP AMS TYPE: diagnostic guide SAP AREA: MM purchasing BUSINESS PROCESS: Procure to pay TAGS: procure-to-pay, sap-mm, diagnostics, purchasing REVIEWED: 2026-06-13 ---------------------------------------- Home Knowledge Atlas Diagnostics SAP Source Determination Diagnostics Atlas Diagnostic SAP source determination diagnostics A first-pass structure for finding why the system cannot determine a valid supplier for a purchase requisition or order. ProcessProcure to pay SAP areaMM purchasing IndexingIndex, reviewed Core idea Source determination is the logic that selects which supplier should fulfill a procurement need. When it fails, the PR cannot be converted to a PO or automatic PO creation produces no result. The support goal is to identify which source element is missing or invalid: info record, source list, quota arrangement, contract, or preferred supplier setting. Common symptoms ME59N or ME21N reports 'no source of supply could be determined'. PR remains unassigned to a supplier after MRP run. Automatic PO creation skips certain materials even though a supplier exists. Wrong supplier is selected for a material that has multiple potential sources. Source list validity expired but users expected the supplier to remain valid. Likely causes Missing info record: no purchasing info record exists for the material, supplier, and purchasing organization combination. Source list block: the source list entry is blocked, expired, or not marked as relevant for automatic sourcing. Quota arrangement mismatch: the quota arrangement does not cover the required period or plant. Supplier master block: the supplier is blocked for purchasing at the plant or organization level. Plant / org mismatch: the material is not extended to the plant, or the supplier is not assigned to the purchasing organization. Where to check in SAP ME03 — source list display for material and plant. ME13 — info record display. MEQ1 — quota arrangement display. ME53N — PR item to see if a source was proposed. ME59N log — automatic PO creation rejection reasons. Key tables / transactions / objects EINA / EINE — purchasing info record. A017 — info record validity. ESLH / ESLP — source list header and items. EQBS / EQBP — quota arrangement. LFA1 / LFB1 — supplier master. Diagnostic workflow Identify the material, plant, and purchasing organization where source determination failed. Check ME03 for a valid source list entry. Check ME13 for a valid info record. Check MEQ1 for a quota arrangement if multiple suppliers exist. Verify the supplier master is not blocked and is extended to the purchasing organization. If automatic sourcing fails, test manual PO creation (ME21N) to isolate the issue. Typical fixes or next actions Create or extend the purchasing info record for the material and supplier. Update the source list to include the correct supplier with valid dates. Adjust the quota arrangement if the wrong supplier is being selected. Unblock the supplier master or extend it to the required organization. If the material has no fixed source, train users to create POs manually or maintain the info record. Support takeaway Source determination failures are almost always master data gaps. A useful ticket should include: material, plant, purchasing organization, the expected supplier, the transaction where the failure appeared, and whether a source list or info record ever existed. Escalation signals No valid source is found for a material across multiple plants or purchasing organizations. The selected source conflicts with an existing contract, quota arrangement, or procurement policy. Info records or outline agreements appear incorrect and procurement must confirm commercial validity. The issue affects a strategic material category or regulatory sourcing requirement. Boundaries and non-goals This page is a diagnostic frame, not a source determination configuration guide. It does not cover MRP sourcing logic, scheduling agreements, or outline agreements. It does not replace SAP's purchasing documentation. This is not official SAP documentation and not a replacement for system-specific analysis. Related Atlas Pages SAP Purchase Order Creation Diagnostics SAP Purchasing Info Record Diagnostics SAP Mm Procurement Overview ================================================== PAGE: SAP Stock Transfer Diagnostics URL: https://dkharlanau.github.io/atlas/diagnostics/sap-stock-transfer-diagnostics/ SECTION: diagnostics DOMAIN: SAP AMS TYPE: diagnostic guide SAP AREA: MM inventory management BUSINESS PROCESS: Inventory / Logistics TAGS: procure-to-pay, sap-mm, diagnostics, inventory-management REVIEWED: 2026-06-13 ---------------------------------------- Home Knowledge Atlas Diagnostics SAP Stock Transfer Diagnostics Atlas Diagnostic SAP stock transfer diagnostics A first-pass structure for finding why stock is stuck in transit, missing at destination, or posted with wrong valuation. ProcessInventory / Logistics SAP areaMM inventory management IndexingIndex, reviewed Core idea Stock transfers move goods between plants, storage locations, or stock types. The most common support issue is not the transfer itself but the mismatch between what left the source and what arrived at the destination. In-transit stock is invisible to MRP at the destination until receipt is posted, which creates planning gaps. The support goal is to trace the transfer document, confirm the goods issue, track in-transit status, and verify the receipt. In most cases the goods issue exists but the receipt was never posted. Check the receiving plant's goods receipt queue and physical receiving logs before assuming stock was lost. Common symptoms Stock shows as in transit but never arrived at destination. Destination plant shows shortage while source plant shows the goods issue was posted. Transfer order quantity does not match goods issue or receipt quantity. Valuation difference between source and destination after transfer. MRP at destination does not consider in-transit stock as supply. Likely causes Goods issue posted but receipt not posted: the physical shipment arrived but the receiving plant did not confirm it in the system. Partial shipment: only part of the transfer quantity was shipped, but the full quantity was expected. Wrong movement type: a one-step transfer was used when a two-step transfer was expected, or vice versa. Valuation area mismatch: source and destination plants use different valuation classes or currencies. Delivery or shipment document stuck: the transfer uses SD delivery and the delivery is blocked or incomplete. Where to check in SAP ME23N — if the transfer is PO-based, check the PO history for goods issue and receipt. MIGO — display the material documents for both issue and receipt. MB5T — in-transit stock report per material and plant. MB52 — stock overview at both source and destination. VL03N — if SD delivery is used, check delivery status and shipment. Key tables / transactions / objects EKPO / EKBE — purchase order items and history (for stock transport orders). MKPF / MSEG — material documents. MSLB / MSKA — special stock tables (if consignment or pipeline). LIPS — delivery items (if SD delivery involved). Diagnostic workflow Confirm the transfer type: one-step (301/311) or two-step (303/305, or stock transport order). Check if a goods issue was posted at the source and capture the material document. Check MB5T or MB52 for in-transit quantity. Check if a goods receipt was posted at the destination. If receipt is missing, verify physical arrival and post the receipt or investigate why it was not posted. If quantities differ, trace partial shipments, returns, or damage. Typical fixes or next actions Post the missing goods receipt at the destination if the goods physically arrived. Reverse and re-post the transfer with the correct movement type if the original was wrong. Update MRP views to consider in-transit stock if the planning gap is systematic. Escalate to logistics if the physical shipment never arrived or was damaged. Retail-specific: DC-to-store delivery failures In retail, stock transfers from a DC to a store often use stock transport orders (STOs) with SD deliveries. When a store does not receive expected stock, the issue may be in the STO, the delivery, the shipment, or the carrier. Check STO status: ME23N shows whether the STO is released, partially delivered, or fully delivered. Check delivery block: VL03N or VL06O shows if the outbound delivery is blocked for picking, packing, or goods issue. Check picking status: the delivery may be created but not yet picked due to DC capacity or wave scheduling. Check shipment status: VT03N or carrier tracking shows if the shipment is in transit, delayed, or delivered. Check store receiving: the delivery may have arrived physically but the store has not posted the goods receipt. A useful DC-to-store delivery ticket should include: STO number, delivery number, shipment number, expected delivery date, current status, and whether the issue is isolated to one store or affects multiple stores on the same route. What to capture first Stock transfer issues are usually process gaps between shipping and receiving, not system errors. Capture: source plant, destination plant, material, transfer document or PO number, goods issue document, expected receipt date, and current in-transit quantity. Escalation signals Stock is physically in transit but missing in the receiving plant, or vice versa, with financial impact. The transfer involves intercompany valuation, tax, or customs requirements beyond standard plant-to-plant posting. Multiple materials or plants show the same stock transfer discrepancy, indicating a configuration issue. The case requires a correction posting that affects inventory valuation or month-end closing. Boundaries and non-goals This page is a diagnostic frame, not a stock transfer configuration guide. It does not cover EWM-managed transfers, cross-company code transfers with intercompany billing, or pipeline materials. It does not replace SAP's logistics documentation. This is not official SAP documentation and not a replacement for system-specific analysis. Related Atlas Pages SAP Movement Types Diagnostics SAP Material Document Diagnostics SAP Goods Receipt Diagnostics ================================================== PAGE: SAP Three-Way Match Diagnostics URL: https://dkharlanau.github.io/atlas/diagnostics/sap-three-way-match-diagnostics/ SECTION: diagnostics DOMAIN: SAP AMS TYPE: diagnostic guide SAP AREA: MM / FI / invoice verification BUSINESS PROCESS: Procure to pay TAGS: procure-to-pay, sap-mm, diagnostics, invoice-verification REVIEWED: 2026-06-13 ---------------------------------------- Home Knowledge Atlas Diagnostics SAP Three-Way Match Diagnostics Atlas Diagnostic SAP Three-Way Match Diagnostics Practical steps to diagnose why PO, GR, and Invoice do not align in SAP. ProcessProcure to pay SAP areaMM / FI / invoice verification IndexingIndex, reviewed Core idea Three-way match in SAP compares purchase order (PO) quantities and prices against goods receipt (GR) and supplier invoice. When any leg differs, the invoice blocks or posts with a variance. The goal is to find which leg is wrong, not just clear the block. Common symptoms Invoice blocked in MIRO with quantity or price variance. GR/IR clearing account shows open items that do not net to zero. Missing goods receipt for a PO line even though the invoice arrived. Duplicate invoice warning (message type F5, F6, or custom check). Partial delivery creates confusion: one PO line has multiple GRs and invoices that do not sum cleanly. Invoice posted but PO history does not show the expected reference. Likely causes GR quantity differs from invoice quantity due to over-delivery, under-delivery, or unit-of-measure conversion. Invoice price differs from PO net price because of price changes, scales, or conditions not copied correctly. Tax code or tax amount mismatch between PO, GR, and invoice. Currency exchange rate differences for foreign-currency POs. GR was reversed or cancelled after invoice posting, leaving an unmatched invoice. Invoice was posted against wrong PO or wrong PO line. Delivery costs or unplanned delivery costs were added in MIRO but not reflected in PO conditions. Where to check in SAP ME23N — PO history tab shows GR and invoice references per line item. Check quantities, dates, and document flow. MIGO — review GR document, movement type, and whether it references the correct PO and line. MIRO / MIR4 — invoice document, blocked reason, and variance details. Check the Messages tab for block reasons. MR11 — GR/IR maintenance: lists open GR/IR items and allows write-off of small differences. FBL3N — line items on the GR/IR clearing account to see open debits and credits. ME2N / ME2L — PO list to confirm delivery status and invoice status per PO. Key tables / transactions / objects EKPO — PO item data (quantity, price, delivery status, invoice status). EKET — PO delivery schedule lines; useful for partial delivery scenarios. MKPF — GR document header. MSEG — GR document items; links to PO via LFBNR, LFPOS, LFBJA. RBKP — invoice document header. RSEG — invoice document items; links to PO and GR. EKBE — PO history (aggregated view of GR and invoice per PO item). BSEG / BSIS — accounting line items for GR/IR account. Diagnostic workflow Start with the blocked invoice in MIRO or the open GR/IR item in FBL3N. Identify the PO number and line item. In ME23N, compare PO quantity, GR quantity, and invoice quantity. If GR is missing, check MIGO for unprocessed inbound deliveries or warehouse delays. If quantities differ, check whether the tolerance limits in the vendor master or company code allow the difference. If price differs, compare PO conditions (ME23N Conditions tab) with invoice conditions in MIRO. For duplicates, check RBKP for existing invoices with the same reference, amount, and vendor. Use MR11 only after confirming the mismatch is not a real business issue. Typical fixes or next actions Release the invoice block if the variance is within tolerance and approved. Post a missing GR in MIGO if goods were physically received but not recorded. Request a credit memo from the vendor if the invoice overstates quantity or price. Reverse and repost the invoice against the correct PO line if it was posted incorrectly. Use MR11 to write off small, approved GR/IR differences that will not be cleared by future documents. Update PO price or conditions if the vendor price changed and the business agrees. Escalate to procurement or warehouse if the mismatch indicates a process failure (wrong goods received, theft, or system bypass). Support takeaway Three-way match failures are rarely a single-document problem. The operator should trace PO → GR → Invoice in that order, confirm which document is the outlier, and decide whether the fix is data correction or process change. Never clear GR/IR blindly without understanding why the mismatch occurred. Escalation signals The PO, GR, and invoice quantities or prices diverge by more than the business tolerance and root cause is unclear. The mismatch points to a recurring supplier issue or possible fraud (duplicate invoices, altered PO prices). Clearing the GR/IR account requires a manual adjustment that affects financial reporting or audit trails. The case involves subcontracting, consignment, or pipeline materials where standard three-way matching does not apply. Boundaries and non-goals This guide does not cover vendor master data issues, tax jurisdiction configuration, or custom invoice validation enhancements. It also does not replace SAP standard help or company-specific approval workflows. This is not official SAP documentation and not a replacement for system-specific analysis. Related Atlas Pages SAP Invoice Verification Diagnostics GR/IR Clearing Explained Goods Receipt Diagnostics Invoice Split Analysis MM Procurement Overview ================================================== PAGE: SAP Transport Governance Diagnostics URL: https://dkharlanau.github.io/atlas/diagnostics/sap-transport-governance-diagnostics/ SECTION: diagnostics DOMAIN: SAP AMS TYPE: diagnostic guide SAP AREA: Change and transport governance BUSINESS PROCESS: SAP AMS support TAGS: sap-ams, transport, governance, change-control, stms REVIEWED: 2026-06-13 ---------------------------------------- Home Knowledge Atlas Diagnostics SAP Transport Governance Diagnostics Atlas Diagnostic SAP transport governance diagnostics A first-pass structure for transport queue conflicts, import-order errors, and governance gaps. ProcessSAP AMS support SAP areaChange and transport governance IndexingIndex, reviewed Core idea Transport governance keeps multiple change streams from colliding. When imports fail because of queue conflicts, untracked dependencies, or unauthorized changes, the diagnostic goal is to identify the governance gap before fixing the individual transport. Common symptoms Multiple transports for the same object block each other in the import queue. Production import order differs from the order tested in quality assurance. A transport appears in the queue that was not approved for import. Rollback or overwrite is needed because an earlier transport was skipped. Cross-project transports create conflicts during release windows. Likely causes Parallel development: two work streams modify the same object without coordination. Queue skipping: an earlier transport was bypassed, breaking dependency order. Weak approval gate: transports enter production without proper review. Untracked dependencies: a transport relies on a configuration that is not in the same request. Emergency process bypass: urgent fixes skip normal governance and conflict with scheduled changes. Where to check in SAP STMS import queues — compare order across development, quality, and production. SE01 / SE10 — transport ownership, project assignment, and release status. Change approval records — check approval status and any emergency exceptions. Object lock reports — identify overlapping objects across transports. System change log — recent manual or emergency changes outside TMS. Key tables / transactions / objects E070 / E071 — transport request and object lists. TMSBUFFER — TMS buffer and queue state. TADIR — object directory for overlap analysis. Diagnostic workflow Map the import queue state and the intended import order for the release window. Identify transports that modify the same objects or depend on each other. Check whether any transport was skipped or imported out of order. Review approval records for transports in the production queue. Resolve conflicts by adjusting sequence, merging objects, or deferring changes. Document the governance gap and update the change-control checklist. Typical fixes or next actions Establish object-level coordination when parallel projects touch the same area. Enforce predecessor checks before importing into production. Require documented approval for every transport in the production queue. Add dependency checks to the release-readiness review. Keep emergency fixes in a separate track and merge them back into normal governance. Support takeaway Governance tickets are most useful when they show the queue state, the conflicting transport numbers, the intended import order, and the business reason for each change. Boundaries and non-goals This page is a governance diagnostic, not a full SAP Solution Manager ChaRM or transport strategy design. It focuses on queue and approval gaps that cause import failures. This is not official SAP documentation and not a replacement for system-specific analysis. ================================================== PAGE: SAP Vendor Master Replication Diagnostics URL: https://dkharlanau.github.io/atlas/diagnostics/sap-vendor-master-replication-diagnostics/ SECTION: diagnostics DOMAIN: SAP AMS TYPE: diagnostic guide SAP AREA: Vendor master / CVI / replication BUSINESS PROCESS: Master data governance TAGS: master-data, sap-mdg, diagnostics, replication REVIEWED: 2026-06-13 ---------------------------------------- Home Knowledge Atlas Diagnostics SAP Vendor Master Replication Diagnostics Atlas Diagnostic SAP vendor master replication diagnostics A first-pass structure for finding why a vendor was not replicated, arrived with wrong data, or created a duplicate in the target system. ProcessMaster data governance SAP areaVendor master / CVI / replication IndexingIndex, reviewed Core idea Vendor master replication moves supplier data through ALE, CVI, or MDG. The failures that matter most are missing purchasing organization or company code data, duplicate vendors in the target, and bank or tax details that differ between source and target. The diagnostic job is to separate replication model gaps from CVI synchronization gaps from key mapping gaps. Common symptoms Vendor created in source system but missing in target system. Vendor exists in target but purchasing organization or company code data is missing. Target system creates duplicate vendor instead of updating existing one. CVI synchronization creates a business partner but the vendor link is broken. Vendor bank details or tax number differ between source and target. Likely causes Replication model filter: the vendor account group or organizational unit is excluded from replication. CVI synchronization failure: the customer-vendor integration (CVI) did not create or link the BP correctly. Key mapping missing: the source vendor number is not mapped to the target system, causing a new vendor to be created. Organizational data filter: the replication sends general data but filters out purchasing organization or company code data. Target number range issue: the target system number range is exhausted or configured for external numbering while the source uses internal. Where to check in SAP XK01 / XK02 / XK03 — vendor master display in target system. WE02 — IDoc status if ALE replication is used. FLBP1 / FLBP2 — business partner display if CVI is involved. MDG replication log — if MDG is the source. Key mapping tables — source-to-target vendor number mapping. Key tables / transactions / objects LFA1 — vendor general data. LFB1 — vendor company code data. LFM1 — vendor purchasing organization data. BUT000 / BUT001 — BP header (if CVI is used). CVI_LINK — CVI link table between BP and vendor. Diagnostic workflow Identify the vendor number, source system, target system, and the expected versus actual result. Check the replication log or IDoc status to confirm the vendor was selected and sent. Verify the vendor exists in the target system (XK03) and check which views are present. If CVI is used, check FLBP1 for the linked BP and verify the CVI_LINK table. Check key mapping to confirm the source vendor maps to the correct target vendor. Compare organizational data (company code, purchasing org) between source and target. Typical fixes or next actions Update the replication model to include the missing account group or organizational data. Create or correct key mapping between source and target vendor numbers. Fix CVI synchronization issues by re-running CVI synchronization or correcting the BP link. Extend the vendor to the missing company code or purchasing organization in the target system. Adjust target number ranges if they conflict with the source numbering. What to capture first Before routing the issue, capture: vendor number, source and target systems, expected versus actual views, replication model, and any IDoc or CVI error. If CVI is involved, include the BP number and the CVI_LINK status. These facts separate a replication problem from a BP-link problem. Escalation signals Vendor data is missing or wrong in downstream procurement, finance, or payment systems. Replication failures affect a strategic supplier or multiple purchasing organizations. A duplicate vendor was created and needs merging with procurement and finance approval. The issue involves payment terms, bank details, tax number, or purchasing organization data with compliance risk. Boundaries and non-goals This page is a diagnostic frame, not a vendor replication configuration guide. It does not cover CVI setup, replication model design, or vendor account group configuration. It does not replace SAP's vendor master documentation. This is not official SAP documentation and not a replacement for system-specific analysis. Related Atlas Pages SAP Business Partner Replication Diagnostics SAP Cvi Synchronization Diagnostics SAP Key Mapping Diagnostics SAP Master Data Quality ================================================== PAGE: Order to Cash Map URL: https://dkharlanau.github.io/atlas/maps/order-to-cash-map/ SECTION: maps DOMAIN: Business operations TYPE: process map SAP AREA: SD / FI / logistics integration BUSINESS PROCESS: Order to cash TAGS: order-to-cash, sap-sd, sap-mm REVIEWED: 2026-05-06 ---------------------------------------- HomeKnowledge AtlasMapsOrder to Cash Map Knowledge Atlas Order to cash map A map for tracing where an O2C process stopped and which evidence should exist at each stage. DomainBusiness operationsTypeprocess mapReviewed2026-05-06 Where this fits This map is the companion to the Order to Cash concept page. It focuses on process tracing rather than general explanation. Core checkpoints Demand captured: customer, material, quantity, date, price context, and partner roles. Commitment made: availability, credit, pricing, and document validation. Fulfillment executed: delivery, picking, packing, goods issue, and logistics handoff. Billing posted: invoice, account determination, tax, output, and receivables impact. Cash resolved: payment, clearing, deductions, disputes, and credit feedback. Diagnostic questions What is the last document that exists? What is the expected next document or posting? Which master data, configuration, interface, or approval controls that transition? Related pages Order to Cash SAP ATP Is Not Inventory SAP Stock Exists but Is Not Promisable ================================================== PAGE: Procure to Pay Map URL: https://dkharlanau.github.io/atlas/maps/procure-to-pay-map/ SECTION: maps DOMAIN: Business operations TYPE: process map SAP AREA: MM / FI integration BUSINESS PROCESS: Procure to pay TAGS: procure-to-pay, sap-mm, procurement REVIEWED: 2026-05-06 ---------------------------------------- HomeKnowledge AtlasMapsProcure to Pay Map Knowledge Atlas Procure to pay map A practical map for connecting procurement demand, purchasing documents, goods receipt, invoice verification, and financial clearing. DomainBusiness operationsTypeprocess mapReviewed2026-05-06 Where this fits Procure to pay connects business demand with supplier commitment, physical receipt, invoice verification, and payment readiness. Core flow Demand is captured as a purchase requisition, MRP proposal, service request, or manual procurement need. The purchasing process turns that demand into a purchase order or another purchasing document. Goods receipt or service acceptance confirms that the supplier delivered what the business can recognize. Invoice verification compares commercial, receipt, and invoice evidence before finance clears or blocks payment. Diagnostic questions Where did the chain stop: requisition, order, receipt, invoice, clearing, or payment? Is the issue caused by document status, master data, tolerance, approval, or finance integration? Which team owns the failed control? Related pages SAP Master Data Quality Master Data Governance Failure Modes Operational Memory for SAP AMS ================================================== END OF MANIFEST — 41 verified pages included