- Important TCodes and iDOC Types - summary
- SAP IDOC-Definition-Structure-Types-Format-Tables
- How to Create an IDOC end-to-end
- Another IDOC summary (at the bottom of this page
SR Related IDocs
IDoc is a way of communication. Communication can be conducted between SAP and SAP system or SAP and non-SAP system:
- SAP-SAP: ALE subsystem is used (Application Linking Enabling)
- SAP-non-SAP: EDI subsystem is used (Electronic Data Interchange).
Transactions
BD51 IDoc Function Module -> processing types
BD87 Status monitor for IDocs, trigger IDoc (status-dependent functionality)
BD64 Distribution model for sending IDocs
BD79 Modification of IDoc segments (ALE IDOC Segments: Initial Screen for Conversion Rules)
BDM2 IDoc Tracing
WE02 Display IDocs
WE05 IDoc list
WE09 Look for IDocs based on content of data record
WE19 Trigger IDoc in target system (status-dependent functionality)
WE20 Partner Profile and Partner Types for IDocs (BC-MID-ALE component)
WE30 Develop IDoc Types
WE47 Status maintenance for IDocs
WE60 IDoc Documentation and search by Segment Type
WE64 Process Codes in IDoc outbound and IDoc inbound
WE82 Output types and IDoc types (message type, basic type)
LX28 Relevant TO item for ext.system (IDOC) – LE-WM
LX30 Overview of WM messages ext.system (IDOC) – LE-WM
LX37 Linked objects (IDOC) – LE-WM
SM59 Setting connection between systems, for IDOC: Internal Connections / None
Other settings:
- SPRO SAP NetWeaver > Application Server > IDoc Interface / Application Link Enabling (ALE) > Basic Settings > Logical Systems > Define Logical System
- If "Send Multi" is checked, the system sends the shipment IDoc to ERP at the following points:
- arrival at checkpoint
- loading started
- loading completed,
- GI posted
- This setting has affect only if TPT = A. (Transportation Planning Type)
- If "Send Multi" is checked, the system sends the shipment IDoc to ERP at the following points:
- SAP Easy Access > Tools > Administration > Administration > Network > RFC Destinations > Internal Connections > None
Database Tables:
- EDIDC
- EDISEGMENT
Direction of the IDoc:
- inbound
- outbound
Structure of the IDoc:
- 3 main parts:
- Control Record (~ header level data)
- Data Records (fields filled with data about the actual status of the object)
- Status Records (historical data about the statuses of the IDoc)
- database tables behind them:
- EDIDC
- EDID4
- EDIDS
- Segments:
- we call parts of the IDoc segments
- parent and child segments
- custom segments can be added in BD79 transaction
Basic type of the IDoc:
- defines the structure of the IDoc:
- standard segments (mandatory or optional)
- number of segments (e.g. you can have only one, or 1-99 of the same type, e.g. deliveries assigned to the TUs)
- size of data fields
- relationship between the segments
- browser for defined structure and segments for a certain type of IDoc: transaction WE60
- typical SR IDoc basic type is SHPMNT05
Partner:
- the other side of the communication
- receiver or sender
- Business Partner, so it can be a vendor, customer, another SAP system
- for IDocs in SR it is usually LS – Logical System
- settings for Logical Systems: SAP NetWeaver > Application Server > IDoc Interface / Application Link Enabling (ALE) > Basic Settings > Logical Systems
- In old systems, in case of EWM as Add-On to ERP, you never use the own logical system as sending partner as it leads to errors. See page 11 of the LE-TRA integration How to guide.
- Resolved by 2847957 - SHPMNT IDoc triggers errors because the sender and the recipient are the same.
Process Code:
- It refers to a FM that will process the IDoc
- WE64 transaction
- e.g. IDOC_OUTPUT_SHPMNT – without namespace because it is not EWM specific
Check the content of an IDoc:
- WE02 transaction
- search with a wide date range. e.g. 01.01.2022-2023.12.31
- on the left side: IDoc types grouped to outbound and inbound category
- double click on SHPMNT
- open one of the results ->
- header data of this IDoc
- basic type: SHPMNT05 -> SR related
- Partner no. system and client number of the sender or receiver Logical System
- Partner Type LS
- Drop down Data Records
- E1EDT20 – only 1 can be in an SHPMNT05 IDoc from this parent segment
- TKNUM – external TU or VEH number
- E1EDL20 segment: VBELN: delivery number in the ERP
- E1ADRM1_SP - Carrier data
- Segments with Errors button can be used for IDocs in error
- header data of this IDoc
Statuses:
- initial status:
- inbound: 64
- outbound: 03
- successful:
- inbound: 53
- outbound: 16
- normal processing order for a successful outbound IDoc:
- 01 IDoc generated
- 30 IDoc ready for dispatch
- 03 Data passed to port OK
- 18 Triggering EDI subsystem OK
- 06 Translation OK
- 12 Dispatch OK
- 16 Functional acknowledgement positive – success
- each status is a validation step, and IDoc can fail at every step
- normal processing order for a successful inbound IDoc:
- 50 IDoc added
- 64 IDoc ready to be transferred to application
- 62 IDoc passed to application
- 53 Application document posted, the document number can be found by expanding this status node
Testing or editing IDoc:
- transaction WE19
- open your IDoc,
- double click on a segment to edit
- background:
- it creates a copy with status 70 for inbound, 33 for outbound
- the copy will stay in the system for reference only and can not be processed anymore
- the status of the edited IDoc itself becomes 69 for inbound and 32 for outbound
- they can be processed in BD87 or by batch jobs
- SE38 -> report RC1_IDOC_SET_STATUS – purpose: to set the status of the IDoc. It is usually required to set it to 68 – no further processing
Search for IDoc:
- IDoc numbers are different in sender and receiver system
- Check, if the IDoc number is available from the OBD: VL03N transaction: search for the delivery → Services for Object button (top left corner) → Relationships
- sometimes you do not have IDoc number, only a TU number
- sample TU number: 6100000012
- WE09 transaction:
- created on: delete the data
- Basic Type: SHPMNT05
- Search in segment… E1EDT20
- Search in Field TKNUM
- for Value 6100000012
Typical problems with IDoc:
- lock issue:
- due to parallel processing
- due to the scenario when a document should be modified by the inbound IDoc, and this document is already opened in change mode by a user
- IDoc processing fails ->
- SM12, check the locks
- reprocess IDoc once the locks are removed
- duplicate IDoc:
- the second one will fail
- solution:
- check what kind of data would be posted by the IDoc
- check if the data is already updated in the document in the receiver system
- if yes, set the IDoc status for the failed IDoc to 68 – "no further processing" with the above mentioned report
- mandatory segments missing:
- check the field in the object in the sender system – is the mandatory field filled?
- if yes, edit IDoc content and process IDoc manually again
- if yes, but issue is reproducible, submit an incident
- if no, fill the mandatory field and trigger IDoc sending again
- special or invalid characters: resend the IDoc without special characters
- time-date mismatch in TU vs in IDoc -> try to reproduce the issue, and submit an incident with the test case.
- check the field in the object in the sender system – is the mandatory field filled?
SR specific knowledge in IDoc:
- SCM-EWM-SR can be connected
- to LE-TRA component with SHPMNT05
- to TM with TPSSHT01
- terminology:
- TU / vehicle in EWM
- shipment in ERP
- freight order in TM
- SPRO → Extended Warehouse Management → Monitoring → ERP Integration → Transportation → Make Settings for Shipment IDoc Processing
- important: TU/VEH external number = ERP shipment number
- prerequisites:
- communication set up between the systems
- map shipment number and TU external number
- map Means of Transport and TU as packaging material: transaction /SCWM/PM_MTR
- If you have S/4HANA with TM integration, there are restrictions:
- cross-delivery HUs are not supported in TM, in EWM there is a BAdI to prevent that: /SCWM/EX_CORE_CONS
- EWM has a Transportation Management part, that can not be used with integration with TM (the same logic like in ERP: there is a WM part, if you have EWM, built-in WM can not be active)
- it is not possible to assign only a single delivery item to an S/4HANA shipment
- sample process:
- create delivery in ERP
- create HU in ERP
- create Shipment in ERP
- IDoc is generated in ERP
- IDoc is sent from ERP to EWM
- based on HU and settings the following objects will be created by IDoc processing EWM:
- one HU + PM_MTR optional checkbox checked -> TU
- one HU + PM_MTR optional checkbox not checked -> TU + VEH
- more HUs on the same level -> first HU is used for create VEH activity, remaining HUs are used to create TU activities
- nested HUs -> the highest level HU is used to create VEH activity, lower-level HUs to create TU activities
- deliveries get assigned to EWM VEH/TU
- GI is posted in EWM
- IDoc is generated in EWM
- IDoc is sent from EWM to ERP
- If a TU in EWM is a replica of an ERP shipment, and you delete it in EWM, the IDoc that we will send to ERP is TPSSHT01.
- PPF: check TU header level data for TranPlngTy. It is Transportation Planning Type (TPT). If it is set to B (Obligatory Internal Planning in EWM), then a PPF can be found on the TU: /SCWM/SR_SEND_SHPMNT, that will trigger SHPMNT05 IDoc creation automatically.
- IDoc in general is only sent for outbound TUs. We do not communicate back inbound TU. The schedule condition in standard says:
- "do not send the message for inbound TUs
IF ls_act-act_dir <> wmesr_sr_act_dir_outb.
RETURN.
ENDIF."
- "do not send the message for inbound TUs
Sources:
https://help.sap.com/doc/saphelp_ewm900/9.0/en-US/b6/5ca50ac0e647af8563f64a9bdec4d8/content.htm?no_cache=true
Help Portal: Integration of S/4HANA Shipments in Shipping and Receiving
Steps involved in IDoc set-up hashtag IDOCSetup
Setting up Inbound/outbound IDocs for system interfaces between systems can reduce the processing time of documents considerably. IDoc interfaces allows to transfer data in faster and safer way.
During order to cash cycle we come across multiple IDocs for data transfer. Few logical messages that can be used are mentioned below.
hashtag We receive this as inbound IDoc which will have all the header and line item details required for order creation. Processing this IDoc is capable of order creation in SAP system. This way we get the order created without any manual intervention which reduces risk of human error at order creation level. ORDERS:
Same Logical message type IDoc when generated for purchase order, it can be used to send the purchase order to vendor. Using EDI IDoc for purchase orders over traditionally used email/ telephone medium can reduce the overall purchasing time for the business and helps to maintain accuracy of data.
hashtag This can be used as a order confirmation response to customer once sales order is confirmed. ORDRSP:
Similar IDoc message when we received as inbound IDoc, it is a confirmation for our purchase order and is capable of updating delivery dates in purchase order.
hashtag: This can be used to notification ship to party about the shipment of goods after PGI is done. DESADV
Similar IDoc when received inbound to our system it acts as a shipping notification for our purchase order. This indicates that PGI has been done for our goods and vendor side and goods are on its way to our delivery address.
hashtag This IDoc can be used to send invoice to customer. With proper setting at customer’s system, it can also trigger automatic posting of invoice. INVOIC:
Similar IDoc inbound to our system acts as vendor invoice to us for purchase order.