SAP IDoc Interface Go-Live Checklist (Free)

0%

0 of 33 items complete

15 critical items still open - these are the highest-risk gaps.

Download checklist:

Configuration

Logical systems for sender and receiver exist and are assigned to clients (BD54, SCC4)CRITICALRFC destination is created and the connection and authorization test pass (SM59)CRITICALPort is defined with the correct RFC destination or file path (WE21)CRITICALPartner profile exists for the correct partner type, number and message type (WE20)CRITICALOutput mode is set deliberately: immediate or collect with a jobProcess code and function module are assigned for inbound messages (WE42, WE57)CRITICALMessage type is linked to the IDoc type and release (WE82)Distribution model is maintained where ALE is used (BD64)Change pointers are activated where master data is distributed (BD50, BD61)

Testing

Happy path IDoc is created, transmitted and posted end to endCRITICALTest cases include missing master data and expect a clear status 51 messageCRITICALLarge volume test is run with realistic IDoc counts and packet sizesDuplicate IDoc scenario is tested and the target does not double postCRITICALSequence-sensitive messages are tested for out of order deliverySpecial characters and long text fields are tested in the segmentsReprocessing from BD87 or WE19 succeeds after the data is fixedAuthorization for the technical user is tested with the real rolesCRITICALUnit conversion, date and number formats match on both systems

Monitoring and support

Dispatch job for outbound status 30 is scheduled (RSEOUT00)CRITICALInbound processing job for status 64 is scheduled (RBDAPP01)CRITICALJob for error IDocs and retry policy is agreed (RBDMANI2 or workflow)Alert or report lists IDocs in error by message type and agetRFC and qRFC monitoring is checked regularly (SM58, SMQ1, SMQ2)Named owner and runbook exist for each common error statusCRITICALArchiving and deletion of old IDocs is planned (SARA, object IDOC)Table growth of EDIDC, EDID4 and EDIDS is estimated

Cutover and rollback

Transports are in the right order and imported into productionCRITICALPartner profile and port settings are checked after the transport, not assumedInterface is switched on only after master data is loadedCRITICALBusiness owner confirms first live IDocs after cutoverRollback plan describes how to stop sending and how to hold IDocs at status 30CRITICALCommunication to partners and downstream teams is sent with timingHypercare period and staffing are agreed

Aim to complete every item marked critical before go-live. Unchecked critical items are the first thing to review in the go/no-go meeting.

Want a second review before go-live?

Optional: have an SAP integration specialist walk through your checklist results and open risks.

Optional. The tool and every export work without this. No spam.

How to use the checklist

Work through the four groups with the developer, the functional owner and the Basis administrator in the same call. Tick items as you verify them in the system, not from memory. Export the list to PDF or Excel and attach it to the go/no-go record so there is evidence of what was checked.

Why configuration is checked first

Partner profiles, ports and process codes are client specific and are often customized by transport or manual entry. A transport can import a program yet leave profile entries missing in production. Treat these as the highest risk because they cause silent failures: the IDoc is created but never leaves, or it arrives and gets stuck at 56 or 64.

Monitoring is part of the interface

An interface without a monitoring plan is unfinished. Jobs that dispatch and process IDocs need a schedule and a failure alert. Someone must own error statuses with a documented fix per message. Plan archiving early, as EDIDC, EDID4 and EDIDS grow quickly on busy interfaces and slow every query against them.

Common mistakes

Teams test only with a clean data set, skip duplicate testing, and discover on day one that the technical user lacks an authorization object. Another repeat issue is going live without the retry job, so one temporary network error leaves IDocs waiting for days.

Frequently Asked Questions

How many IDoc tests are enough before go-live?

There is no fixed number. Cover the happy path, each known error status, duplicates, volume and authorization. A set of 15 to 30 well chosen cases is common for a single interface, with higher coverage for financial postings.

Should outbound IDocs be sent immediately or collected?

Immediate transfer gives low latency and suits low volumes. Collecting IDocs and sending by job reduces load and suits high volumes and batch-style partners. Whichever you choose, document it and schedule the job when you collect.

What do I do with IDocs created before cutover?

Decide before go-live. Either process and clear them, or delete them from the test client, and make sure test partner profiles do not exist in production. Leftover test IDocs in the queue are a common source of confusing alerts.

How long should IDocs be kept?

That depends on audit and business needs. Many companies keep processed IDocs online for weeks to a few months, archive them with SARA for longer retention, and delete after the legal period. Agree it with finance and compliance.

If your interface support is mostly manual, Netray can help build a monitoring assistant over IDoc tables, with read-only access and the query shown for every answer.

Talk to an Expert Explore More Free Tools

Related Tools

SAP

More SAP tools

See all

SAP IDoc Interface Go-Live Checklist