IDOCs: Useful Tips to remember while configuration

[Former Member]

I am sharing few not often used tips of IDOCs in this article. Generally i have seen people trying to achieve many things programmatically by coding in the user exits etc. While we have some SAP standard ways of achieving them like idoc Views,encryption,acknowledgements etc which can easily be achieved by configuration.

Suppressing unwanted segments- The standard Idoc types are assigned to various message types and applications. An idoc may contain various segments which are not required in some scenarios. Also, sometimes some unwanted data is sent to other applications. We may manually suppress the unwanted segments inside some user exit of the processing function module through ABAP code. But there can be some consequences of using this technique and this may not be a reliable method. Instead of this approach, Standard SAP provides reduced message type and Idoc View techniques to achieve the same solution.

• Reduced Message types- we can create a Z message type with reference to a few standard message types where we can remove the unwanted segments while using the standard function module for idoc processing. The below steps illustrates the implementation of the reduced message type.
  • Open T-code BD53 and specify the reduced Z message type with the reference message type.
  • Now select or deselect the segments as per the requirement on the next screen.
    

                   

• Idoc Views - Idoc views is a similar technique to suppress the unwanted idoc segments. It supports more message types and basic types. The below steps illustrates the implementation of the idoc views
  • Open t-code WE32 and specify the idoc view name.
  • Provide the Message type, Basic type and Extension. Extension name is not mandatory
  • Select the segments and child segments from the next screen and save the view.

    

Specify the view name in the partner profile while doing the configuration.

Basic Level data encryption in IDOCs- An idoc can contain some sensitive information like credit card details of customer, phone numbers, pricing information etc. If we want this data to be encrypted for display purpose only. We can encrypt some data in the Idocs for display purpose only, like the customer care representative can see the last 5 characters of the credit card number or phone number (Phone XXXXX-53108).The transaction display authorization to some particular users can be managed by standard idoc authorization objects but if we don't want some particular fields in segments to be displayed to the users. We can use transaction WECRYPTDISPLAY.

This transaction is just a maintenance view of table EDCRYPTDISPLAY. We can maintain particular segments of an idoc in this transaction. Once data is maintained, In all the display transactions like WE02, WE05,WE07, WE09,WE10 etc. This sensitive data will be displayed as '*'.

We can also change the masked character by creating a custom function module. This method has limitations that the data is actually not encrypted in the database. Anyone can check the correct values in the database table if they have the access.

Change IDOC Data/Control parameters programmatically- The failed Idoc can be reprocessed from the transaction BD87. Like, if an idoc fails due to master data issue, we can correct the master data and then reprocess the idoc. But there is a limitation - we cannot change the idoc data for reprocessing. If our idoc has wrong data, we cannot reprocess it as it will fail once again.

*** try at your own risk***

So for few idoc status, we can programmatically change the contents of an IDOC, to change the data of an IDOC follow the below steps.

• Call FM EDI_DOCUMENT_OPEN_FOR_EDIT to open the idoc for editing. Remember we can't change all idoc status and STATUS_IS_UNABLE_FOR_CHANGING Exception will be raised in case the status is not editable.
• Read the data returned by the above FM and make the changes to the data.
• Call FM EDI_CHANGE_DATA_SEGMENT importing the changed data.
• Call FM to EDI_DOCUMENT_CLOSE_EDIT to commit the changes. Once this FM is called the idoc data will be changed and the changes will be committed in the database. The status of the idoc will be changed to 69 (IDoc was edited).

If we want to add the idoc to the inbound queue directly after editing. While calling the FM EDI_DOCUMENT_CLOSE_EDIT we can set  'status_75' flag as X. The Idoc status will change to 75 and the IDoc will be added to the queue.

We can also use EDI_CHANGE_CONTROL_SEGMENT to change the control data.

Idoc Acknowledgement for ALE and EDI scenarios

Idoc acknowledgement is an idoc by receiver just to inform the sender about the state of the outbound Idoc. The acknowledgment Idoc changes the status of the outbound idoc of the sender to a particular status depending upon negative or a positive acknowledgement. There are several Idoc status which can tell the state of the outbound idoc in the receiver system.

SAP has provided different idocs for ALE and EDI Scenarios.

• STATUS IDoc -  We can use the STATUS idoc for EDI scenario. The message type is STATUS and Idoc type is SYSTAT01. We have 2 standard inbound process codes STA1 and STA2 for IDOC processing. This Idoc has only one segment E1STATS. The acknowledging idoc number is filled in the docnum field of the E1STATS.
• ALE AUDIT IDoc - We can use this idoc for ALE scenarios. The Message type is ALEAUD and Idoc type is ALEAUD01. A single ALE Audit idoc can contain Idoc of 500 IDocs.

The acknowledgement idoc changes the status of the outbound idoc. The below Idoc status can be changed by the outbound IDoc.

IDoc Status	Description
14	Interchange Acknowledgement positive
15	Interchange acknowledgement negative
16	Functional acknowledgement
17	Functional acknowledgement negative
40	Application document not created in target system
41	Application document created in receiving system