Table of Contents
Introduccion
In SAP to transfer master data between different systems, one of the possibility is using IDoc with Change Pointers functionality. Using IDocs activated by Change Pointers you can transfer master data from the central SAP system to other systems in the landscape and other integrated systems. You can configure Change Pointers to flag master data changes (Create/Update/Delete) in SAP. Using these flags, outbound iDocs generated in SAP can be directed to different receiving systems. The flagged master data changes are stored in Change Pointers table BDCP2 in SAP.
In one of my mission the client changed very often the replenishment assigned to the stores (in Retail SAP model), therefore the quantities of changer pointer were important replenishment master data table WRPL. This quantites can produced a dump of memory in the creation of IDoc RPLMAS. One of the solution proposed by SAP is to use the program “RBDMIDOC_SELECT_DATE” and this one works for ARTMAS but not for RPLMAS.
In this article we will look at my analyse and solution.
Let’s get to work :)
Little review outgoing IDoc
Intermediate Documents:
IDoc is an SAP object that transfer data of a business transaction from one system to another in the form of electronic message. IDoc is an acronym for Intermediate Document. The transfer from SAP to non-SAP system is done via EDI (Electronic Data Interchange) subsystems, whereas for transfer between two SAP systems ALE is used.
IDoc can be triggered in SAP system or in EDI subsystem. This depends on the direction in which IDoc is sent and is called Inbound IDoc or Outbound IDoc accordingly. In case of outbound flow, IDoc is triggered in SAP through document message control which is then sent to EDI subsystem. EDI converts the data from IDoc into XML or equivalent format, and then sends the data to partner system through the Internet.
So, IDoc can be separated by:
Inbound IDoc : These are IDocs which get the data into SAP system from external source or other external system.
Outbound IDoc: These are IDocs which are sent out from SAP system to any other external system.
In our case we will focus on mainly parameters in outbound IDoc:
| Step | transaction | Description |
|---|---|---|
| 1 | WE31 | Create segments IDoc |
| 2 | WE30 | Create basic IDOC type and release the segments and basic type |
| 3 | WE81 | Create message type |
| 4 | WE82 | Link the message type standard with IDOC type |
| 5 | BD61 | Change pointer globally activation |
| 6 | BD50 | Change pointer for message type activation |
| 7 | BD52 | Select the table fields for which change pointer will be created |
| 8 | BD60 | Select the function module is used to create IDOC from change pointer |
| 9 | BD54 | Create a new logical system |
| 10 | BD64 | Add the message type to distribution model |
The main parameter in charge to read the change pointers and create IDocs is the module function used in BD60.
1-Program RBDMIDOC_SELECT_DATE
The solution proposed is to use the standard program RBDMIDOC_SELECT_DATE. This program is similar to RBDMIDOC but allows you to select a change pointer package according to a specific date in the selection screen. The pack is determined from the last untreated change pointers BDCP2-PROCESS <> “X” and the creation date defined in the selection screen.
2-Creation module function Z for RPLMAS IDoc
In the parameter transaction BD60 the function module “MASTERIDOC_CREATE_SMD_RPLMAS” is called to create the IDoc RPLMAS, but it doesn’t have the time limit variables like the function “MASTERIDOC_CREATE_SMD_ARTMAS”.
In case of ARTMAS function module:
And in the RPLMAS function module:
Then the solution was to creation of “ZRPLMAS” and “Z” function module to set in transaction DB60 with time limit in the call function “CHANGR_POINTERS_READ”.
Note:
1) Also update the “if” condition filter message type in the function module to acccept the new ZRPLMAS.
2) If you use the program “RWRPLCHK” to remove information in the table WRPL, take care of launching before and after RPLMAS with option:
- Consistency Check for Replenishment Data
Tables MARC and WRPL contain redundant data that should always be identical. In certain circumstances, however, inconsistencies can occur. This report eliminates inconsistencies in table WRPL by overwriting table WRPL with the entries from table MARC.
- Removing of replenishment data
Previously, there was no option to delete replenishment master data and the accompanying movement data apart from by completely archiving a material. This report enables you to delete entries from tables WRPL and WRPT. Only entries that have an RP type that is not relevant for replenishment are deleted e.g. ND.
Thank you for the initial photo.
Photo by Chris Lawton on Unsplash