# SAP IDoc Interface Go-Live Checklist

> Source: https://netray.co/tools/sap-idoc-interface-go-live-checklist
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Free Tools

## Short answer

A practical checklist covering configuration, testing, monitoring and cutover steps before an IDoc interface goes into production.

## Category

sap

## Erp

SAP ECC / S/4HANA

## Audience

- SAP integration developer
- SAP project manager
- SAP Basis administrator

## Tool

**Kind:** checklist

**Groups:**

#### Configuration

**Items:**

**Text:** Logical systems for sender and receiver exist and are assigned to clients (BD54, SCC4)

**Critical:** true

**Text:** RFC destination is created and the connection and authorization test pass (SM59)

**Critical:** true

**Text:** Port is defined with the correct RFC destination or file path (WE21)

**Critical:** true

**Text:** Partner profile exists for the correct partner type, number and message type (WE20)

**Critical:** true

Output mode is set deliberately: immediate or collect with a job

**Text:** Process code and function module are assigned for inbound messages (WE42, WE57)

**Critical:** true

Message 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

**Items:**

**Text:** Happy path IDoc is created, transmitted and posted end to end

**Critical:** true

**Text:** Test cases include missing master data and expect a clear status 51 message

**Critical:** true

Large volume test is run with realistic IDoc counts and packet sizes

**Text:** Duplicate IDoc scenario is tested and the target does not double post

**Critical:** true

Sequence-sensitive messages are tested for out of order delivery

Special characters and long text fields are tested in the segments

Reprocessing from BD87 or WE19 succeeds after the data is fixed

**Text:** Authorization for the technical user is tested with the real roles

**Critical:** true

Unit conversion, date and number formats match on both systems

#### Monitoring and support

**Items:**

**Text:** Dispatch job for outbound status 30 is scheduled (RSEOUT00)

**Critical:** true

**Text:** Inbound processing job for status 64 is scheduled (RBDAPP01)

**Critical:** true

Job for error IDocs and retry policy is agreed (RBDMANI2 or workflow)

Alert or report lists IDocs in error by message type and age

tRFC and qRFC monitoring is checked regularly (SM58, SMQ1, SMQ2)

**Text:** Named owner and runbook exist for each common error status

**Critical:** true

Archiving and deletion of old IDocs is planned (SARA, object IDOC)

Table growth of EDIDC, EDID4 and EDIDS is estimated

#### Cutover and rollback

**Items:**

**Text:** Transports are in the right order and imported into production

**Critical:** true

Partner profile and port settings are checked after the transport, not assumed

**Text:** Interface is switched on only after master data is loaded

**Critical:** true

Business owner confirms first live IDocs after cutover

**Text:** Rollback plan describes how to stop sending and how to hold IDocs at status 30

**Critical:** true

Communication to partners and downstream teams is sent with timing

Hypercare period and staffing are agreed

**Scoring Note:** 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.

## Content

**Intro:** IDoc interfaces fail in production for dull reasons: a missing job, a wrong partner profile, no one owns the errors. This checklist covers what to confirm before you switch an interface on.

**Sections:**

#### How to use the checklist

**Body:** 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

**Body:** 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

**Body:** 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

**Body:** 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.

**Cta:** 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.

**Faq:**

#### How many IDoc tests are enough before go-live?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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.

## Search terms

idoc interface checklist, sap interface go live checklist, ale idoc testing checklist, idoc partner profile checklist, sap integration cutover checklist, idoc monitoring setup, idoc error handling checklist, sap interface test plan

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json