Skip to main content

IDocs Basics for functional consultants

IDocs is an abbreviated form of Intermediate Documents. Data from SAP will send in the form of IDoc between SAP ----> SAP or SAP ----> Non SAP.

Type of data exchanged between systems
  • Master Data 
  • Transactional data
Master Data

Master Data can be manually / Automatically pushed. The manual push of master data can be done by respective transaction codes and we can schedule the batch job for an auto push of master data.

Sample T.Codes
  • Send Material Master Data ---> BD10
  • Send Customers Master Data ---> BD12
  • Send Vendor Master Data ----> BD14
  • Send Cost Center Data  ---> BD16

Transactional Data

Transaction data such as Sales Order, Delivery, Purchase Orders etc will be sent through Output Setup where IDocs will be triggered based on the Output with Medium '6'.

The output type is linked with Message type in the partner profile.

To enable an exchange of change data between system then we are required to create a new output type to trigger during sales document changes and then assign at partner profile level with change pointer need to be enabled.

Change Pointer
  • Required fields to trigger change pointers to be maintained in T.Code BD52 for the required message type.
  • The system will consider only the fields maintained in the T.Code BD52 to trigger change pointers. 
  • Table - BDCP2 will be filled for any changes done to the fields in the master data and system will pick records from the table and push the data through BD21. 
  • Change log will create system performance issues and need to be archived regularly daily. So just for that reason, T.Code BD22 need to be scheduled as a batch job.
Partner profile maintenance is system specific and need be maintained by a functional consultant as a part of the cutover activity where Message type is linked between IDoc type, Process Code.


Structure of IDoc

1. Control Records
2. Data Records
3.Status Records

Control Records

 This contains sender system, Receiver system details, Type of data being sent and Time log

Data will be stored in EDIDC table

Data Records

This is the main data container which carries the data.

Data will be stored in EDID4 table

Status Records

This will provide the status of the IDocs ie., Success, Failure etc.

01-49 status is dedicated to Outbound processing

51-99 status is dedicated to the inbound processing

Below is the status which we will see regularly.

01- Successfully created and passed to the partner system
03 - Data passed to port
30 - Data ready to be processed
53- Successfully received from the partner system
51- Document Failed to be posted
64 - Data ready to be processed
68 - No further processing  required

Change Status of the IDoc

There is a common requirement to change the status of the IDoc. In this case, there is a standard program RC1_IDOC_RESET_STATUS can be used.

Useful T.Codes :
  • List of IDocs --> WE02/WE05
  • Reprocessing of failed IDocs ---> BD87
  • Tracing of partner system IDocs ---> BD87
  • Search IDocs by Content --> WE09
  • IDocs Area Menu ----> SALE
  • IDocs Test processing ---- > WE19
  • Trigger IDocs based on change pointers ---> BD21
  • Archieve Change points ---> BD22
  • Partner Profile maintenance ---> WE20
  • Port Definition ----> WE21
  • Change document items for Message type  ---> BD52
  • Define Message type ----> WE81
  • Assign message type to IDoc type ---> WE82
  • Assign Outbound process Code for Message type ---> WE41
  • Assign Inbound process Code for Message type ---> WE42
  • View IDoc Type - WE30
  • View Segement - WE31

Comments

Post a Comment

Popular posts from this blog

M7021 : Deficit of stock relevant error message during Material Document Cancellation

Issue : When posting a Cancellation for a Material Document in transaction MIGO, you see error 'M7021 Deficit of not stock relevant' although the Purchase Order is setup with an Account assignment. Material / Batch is not managed on Stock Level even though material is valuated. Resolution : The issue is due to program bug and require to implement note - 2502183 - Slog: correction for quantity check. This note is applicable for S/4 HANA 1610 (S4CORE 101) and 1709 (S4CORE 102).
4 comments
Read more

Add Custom fields to sales order screen in Additional Tab B - Header

SAP has provided Additional data Tab A and Tab B for the addition of custom fields to the Standard sales order screen. Screens 8309, 8310 are used for header level and 8459,8460 for item level. Prior to this, we are required to append the custom fields of the Sales order sub screen in VBAK or VBAP. Pass Custom field values in PAI of screen 8309 within Chain statement CHAIN. FIELD: VBAK-<Custom Field 1>         VBAK-<Custom Field 2>         VBAK-<Custom Field 3> ENDCHAIN. Thank you.
Post a Comment
Read more

User Exits in Delivery

FORM routine USEREXIT_REFRESH_DOCUMENT (include MV50AFZ1) Purpose The FORM routine USEREXIT_REFRESH_DOCUMENT is used for the initialization of your own data areas before the processing of a new delivery document. Call The routine is called from within the standard routine BELEG_DATEN_INIT (SAPMV50A). Basically, the data initialization is called on the following occasions: FORM routine USEREXIT_DELETE_DOCUMENT (include MV50AFZ1) Purpose If a delivery is deleted, you can delete your own dependent data using this FORM routine. Call The FORM routine is called from the FORM routine BELEG_LOESCHEN (SAPMV50A) if the document can be deleted completely. Immediately after the FORM routine  USEREXIT_DELETE_DOCUMENT is called, the document backup is called for which the logically deleted delivery is removed from the database. FORM routine USEREXIT_READ_DOCUMENT (include MV50AFZ1) Purpose The exit is used to make your own data availabl...
1 comment
Read more