are a clever name for a triggering reason for outbound Idocs. Using a change pointer which is defined by customizing against any Change Document for any Message Type. From concept to implementation..

The concept

SAP has come up with a solution to keep track of relevant changes on a wide variety of documents such as the Purchase Order, a Contract or Master data (the Material). Change Documents are the mechanism used in many transactions to keep track of changes, it can even be set up for custom-build applications.For many changes, it's quite likely that other systems need to be notified and why not use Idoc's to get this change message across. Change pointers is where the SAP standard solution for keeping track of changes (Change document) meets the SAP standard solution for EDI (and ALE) messaging (Idocs).

How does it work ?

A steplist:
1. First the use of change pointers needs to be globally activated via transaction BD61 - Globally activate change pointers, then the change pointers need to be activated for the relevant message type, transaction BD50- Activate Change Pointers for the Message Type
2. Via customizing settings certain changes are flagged as "relevant to be used to trigger an outbound Idoc" (transaction BD52- Specify the fields for which Change Pointers need to be written). These settings are done for a predefined Idoc Message Type
3. The effect will be that when the above customized changes actually take place, e.g. a the Purchase Order quantity is changed, a change pointer is saved to a table. Effectively the change pointer acts as a "triggering reason for an predefined message type" (or even different message types).
4. At the end of the day, the change pointers are interpreted (normally via a batch job) via transaction BD21 - Idocs are written from the (already collected) Change Pointers

The outbound Idocs that are produced will have to be set up with an outbound processing code (via transaction WE41 - Outbound: Create a new outbound process code) to enable the system to produce the triggered Idoc. Nice detail on this: where an idoc with header segments and item segments is produced from a change pointer that was about an item change, the action code on the header is set to code 018 - Resend. This means the header data is only sent along to help the receiving system identify what the idoc is about (which is required of course). The additional information of this action code is the fact that nothing has changed on the header segments - so the receiving system can ignore most of the segment.

Technical background

Change pointers are held on tables BDCP - "Change pointer" and BDCPS - "Change pointer: Status". Table TBDME- "ALE supplement data for EDI message type" could be useful as well. In practice, these tables can be used to check a setup.

Some useful function modules where change pointers are concerned:
CHANGE_POINTERS_READ Read change pointers
CHANGE_POINTERS_STATUS_WRITE Write status records of change pointers
MASTERIDOC_CREATE_SMD_* Outbound IDOC logic using change pointers (*=message type)

• Prev
• Next