A missing SAP DRC prerequisite cannot be assigned safely from a supplier name or a contract label. The correct owner depends on what the customer’s system should contain, what it actually contains and which party has the authority and capability to resolve the verified difference.
Provider changes make weak evidence visible because the technical history often remains inside the outgoing provider’s ticketing system. In this article, you will learn how to build a portable support-dependency record, distinguish product issues from customer changes and route a missing prerequisite without guessing contractual responsibility.
Start with the missing technical fact
Do not begin with “SAP, partner or customer?” Begin with the expected prerequisite and the process it supports. The team must establish three facts before assigning an action.
- Applicability: should the object or behavior exist for this product, release, component level and country process?
- Delivery path: should it arrive through a support package, SAP Note, manual activity, configuration or another prerequisite?
- Local state: is the expected standard state absent, partially delivered, modified or present but failing?
A country checklist cannot answer these questions. Use verifiable SAP system facts from the actual SID and client, together with the current licensed instructions for the selected scenario.
Build a support-dependency record that survives provider changes
The record should be short enough for an engineer to review and complete enough for a routing decision. Store it in a customer-controlled location, not only in a provider portal.
- Requirement and country process being tested
- Source application and document direction
- SID, client, SAP product, release and relevant component levels
- Expected object or behavior and the official basis for expecting it
- Locally observed repository, configuration and SNOTE evidence
- Prerequisites and manual activities already checked
- Customer modifications or enhancements in the affected path
- Reproducible business test and exact failure evidence
- Proposed resolver and why that party can act
- Retest that will prove resolution
This record can travel with the issue if the first resolver rejects it. It also prevents the incoming provider from rebuilding the technical history from memory.
Separate accountable owner from technical resolver
The customer retains accountability for scope, access, change approval and acceptance. A technical resolver may be SAP support, an implementation provider, a managed-service provider, an integration provider or an internal SAP team. Contract terms determine who is obliged to perform the work.
Do not use the resolver decision as a legal interpretation of a contract. Use it to identify the next party technically able to investigate or correct the verified condition, then route the work through the customer’s actual support and change process.
Route the issue using evidence
Route to SAP support for a reproducible standard-path issue
An SAP incident may be appropriate when the supported product, release and scenario are confirmed, the expected SAP-delivered object or behavior is absent or defective, known prerequisites have been checked and the failure can be reproduced in the standard path.
The incident package should contain the smallest reproducible example, relevant component evidence, local Note or object status, application log and business impact. Do not ask SAP support to decide the customer’s tax scope, approve a custom mapping or choose a commercial provider.
Route to the implementation or support provider for customer-side work
A provider may be the technical resolver when the standard prerequisite exists and the remaining work is authorized Note implementation, configuration, transport handling, custom code, mapping, monitoring or provider integration within the agreed scope.
Do not create a custom replacement for a suspected missing standard object merely to close the ticket. First resolve whether the standard prerequisite should exist and which supported delivery path applies.
Route to customer change control for an approval or scope decision
Customer approval is required when the next action changes configuration, repository objects, transports, interfaces, master data or production behavior. The customer also owns the approved entity and transaction scope and the acceptance criteria for the business process.
A provider can prepare evidence and a change proposal. Production authorization remains inside the customer’s control framework.
Keep the issue unresolved when applicability is not proved
If the team cannot prove that the object belongs in the installed release, do not assign a remediation task. Create an applicability investigation with a named owner, required source and decision date.
“Unavailable” is not the same as “missing.” A collector may be unable to read a fact because of authorization, an unsupported probe or incomplete system access. Resolve the evidence problem before declaring a product defect.
Handle modified or partially delivered objects separately
An expected object may exist but differ from the delivered standard because of a customer modification, enhancement or incomplete correction. That is not the same condition as a missing object.
- Modified object: compare the customer change with the current correction instructions before deciding the implementation path.
- Interrupted Note implementation: preserve SNOTE processing evidence and review prerequisites and affected objects.
- Support package expected, object absent: verify component level and installation consistency before proposing a substitute.
- Object present, process still failing: reproduce the functional error and investigate configuration, master data and integration evidence.
Prepare the handover before the provider changes
Export the technical history while the outgoing team and its records are still available. The handover should let the new resolver continue from the last proven state.
- Open incidents and their current external references
- Candidate Notes and locally observed statuses
- Unresolved prerequisites and evidence gaps
- Modified objects and related transports
- Configuration decisions and approving owners
- Representative test documents and results
- Platform or integration identifiers needed for reconciliation
- Next action, blocker and acceptance test for every open item
Do not transfer credentials, private keys or unrestricted production access inside the handover pack. Access should be re-established through the customer’s approved identity and authorization process.
Use one closure rule for every resolver
The issue should not close because a supplier accepted the ticket or an object now exists. Close it when the expected baseline is proved, the approved action is completed and the named business test passes.
Ownership rule: the accountable customer owner controls scope and approval. The technical resolver is the party that can act on the evidenced condition under the applicable entitlement and contract. The evidence record remains portable between both.
Official working resources: SAP Document and Reporting Compliance documentation, SAP Notes and Knowledge Base information and SAP release and maintenance information. This article addresses technical routing and evidence. Entitlement and contractual responsibility must be confirmed from the customer’s agreements.