Change pointers to trigger the IDOC

HI
I am having a selection screen with fields to create a custom info record (transaction VD51/ VD52 )
Customer
material
salesorganisation
distribution channel
division
if we can use change pointers to determine when procedure is triggered.
Please provide the steps for that (including change document)or we need to check the CDHDR table using the following fields.
Plz suggest

Change pointers is the one of the IDOC processing method in ALE.
In this once we make the config to any of messages type , if any changes are made in sending system then IDOC will be posted directly to destination with user interation.
Changes pointers are configured using BD50,BD51,BD53,BD61.
Change pointers are stored in tables BDCP and BDCPS (or BDCP2 in case of high-performance setting) - like CDHDR and CDPOS for change documents (but this is not a controlling table!).
1. Do you really need change pointers?
You need change pointers to distribute changes with the ALE SMD tool. If you do not use this tool, you do not need to write change pointers.
You can deactivate change pointers and activate them again with the transaction BD61.
2. Do you really need to activate change pointers for this messages type?
If some messages types are no longer to be distributed by change pointers, you can
deactivate change pointers for this message type.
You can deactivate change pointers for the message type
and reactivate them again in transaction BD50.
For reduced message types, deactivate the change pointer with the
Reduction tool (transaction BD53).
Applications which write change documents will also try to write change pointers for ALE operations. These are log entries to remember all modified data records relevant for ALE.
Most applications write change documents. These are primarily log entries in the
tables CDHDR and CDPOS.
Change documents remember the modified fields made to the database by an
application. They also remember the user name and the time when the modification
took place.
The decision whether a field modification is relevant for a change document is
triggered by a flag of the modified fields data element. You can set the flag with
SE11 by modifying the data element.
For the purpose of distributing data via ALE to other systems, you may want to
choose other fields, which shall be regarded relevant for triggering a distribution.
Therefore R/3 introduced the concept of change pointers, which are nothing else
than a second log file specially designed for writing the change pointers which are
meant to trigger IDoc distribution via ALE.
So the change pointers will remember the key of the document every time when a
relevant field has changed.
Change pointers are then evaluated by an ABAP which calls the IDoc creation, for
every modified document found in the change pointers.
The Change pointers are written from the routine CHANGEDOCUMENT_CLOSE
when saving the generated change document. So change pointers are automatically
written when a relevant document changes.
The following function is called from within CHANGEDOCUMENT_CLOSE in order to write the change pointers.
CALL FUNCTION 'CHANGE_POINTERS_CREATE'
EXPORTING
change_document_header = cdhdr
TABLES
change_document_position = ins_cdpos.
Activation of change pointer update :
Change pointers are log entries to table BDCP which are written every time a transaction modifies certain fields. The change pointers are designed for ALE distribution and written by the function CHANGE_DOCUMENT_CLOSE.
Change pointers are written for use with ALE. There are ABAPs like RBDMIDOC
which can read the change pointers and trigger an IDoc for ALE distribution.
The change pointers are mainly the same as change documents. They however can
be set up differently, so fields which trigger change documents are not necessarily
the same that cause change pointers to be written.
In order to work with change pointers there are two steps to be performed
1) Turn on change pointer update generally
2) Decide which message types shall be included for change pointer update
R3 allows to activate or deactivate the change pointer update. For this purpose it
maintains a table TBDA1. The decision whether the change pointer update is active
is done with a Function Ale_Component_Check
This check does nothing else than to check, if this table has an entry or not. If there is an entry in TBDA1, the ALE change pointers are generally active. If this table is empty, change pointers are turned off for everybody and everything, regardless of the other settings.
The two points read like you had the choice between turning it on generally or
selectively. This is not the case: you always turn them on selectively. The switch to
turn on generally is meant to activate or deactivate the whole mechanism.
The change pointers which have not been processed yet, can be read with a function
module.
Call Function 'CHANGE_POINTERS_READ'
The ABAP RBDMIDOC will process all open change pointers and distribute the
matching IDocs.
When you want to send out an IDoc unconditionally every time a transaction
updates, you better use the workflow from the change documents.
Reward if useful

Similar Messages

How to find out what are all the change pointers assoicated for an idoc ??

Hi ,
How to find out what are all the change pointers activated for an idoc ??
Thanks,
Varma

Verma,
You can check what are the active Change Pointers for the message type in tcode BD50
Use tcode BD61 to check whether change pointers are active or not??
Hope this helps..

Idoc serialization and change pointers automatic trigger

Hello Experts
How to trigger an Idoc automatically once the application has been saved ?
Scenario 1: Here serialization of message types are used, all the idocs in the serialization group must trigger & sent to the receiving system as per the sequence even if any field in the complete serialization group of message type changes (Note No Manual processing using reports Like RBDSER01, RBDSER02 etc..or Batch Jobs)
Scenario 2: Again Idoc has to trigger and sent to the receiving system as per the change pointer configuration once the application has been saved (Note: No manual processing like BD10, BD11 etc.. and no user exits has to invoke while saving the application).
Please let me know is this two cases can be implemented. Thank you in Advance.
Regards
Imran.

Hi Fernando,
I'm trying to accomplish the same thing that you were... trying to get a change pointer to be created based off the status change of a technical object (functional location or equipment).
Can you give me any detail on what you did?
Thanks,
John

Not able to trigger the idoc

Dear All
i need to trigger idocs from ECC6 to PI system, but it throws a message that destination port does not exists. both the RFC destinations are created and tested successfully ( could able to login remotely after testing)
ECC 6:
Logical System : T90CLNT090
RFC Destination : PI7CLNT001
Port : HIDDU
Partner Profile : PI7CLNT001
PI 7.1 :
Logical System : PI7CLNT001
RFC Destination : EC6CLNT800
Port : SAPECC
i went into the transaction we02 selected the idoc.. and edited the port and partner type and tried to trigger.. but "destination port "SAPECC" does not exists...
do i need to edit the IDOC in programme level, if yes, steps to edit the IDOC
Regards
Blue

Hi,
you need to pass the port of the SAP ECC created in the idoc i.e port should be HIDDU and not ECC..
Check at the partner profile parameters that the port assigned is HIDDU and rfc desination should be PI7CLNT001..
this needs to be handled at the partner profile configuration /distribution model only...
but not via programme...
Before this ensure that connections created are working fine (both connection and authorisation tests)..
HTH
Rajesh

Does changing a KeyValuePair trigger the PropertyChanged event in ObservableDictionary?

I am using the ObservableDictionary class available at:
http://blogs.microsoft.co.il/shimmy/2010/12/02/observabledictionaryof-tkey-tvalue-vbnet/
I will, for most of my code, be modifying KeyValuePair items that have already been added, and want an event to be triggered when I make these modifications. Both the Keys and Values properties are there, and they obviously change when a KeyValuePair
is modified, but will that trigger the PropertyChanged event? I was having trouble figuring out when the PropertyChanged event would get triggered, since the only place I could find in the code that raised the event was from inside the OnCollectionChanged
methods. Will the PropertyChanged event be triggered when I modify a KeyValuePair, or do I need to add PropertyChanged events to the KeyValuePair items myself? Any help would be appreciated. Thanks.
Nathan Sokalski [email protected] http://www.nathansokalski.com/

But I don't want to comment on it, I want to ask a question. Look at the existing comment: No reply to that (unless it was done privately).
Nathan Sokalski [email protected] http://www.nathansokalski.com/
So you are saying a comment about something can not be a question? When did that become some kind of planet earth law? And who's enforcing that?
Since the comment capability asks for a name and email address then perhaps shimmy would respond to your comment. You do understand your comment could be something like "If I use your class will changing a key/value pair cause the property changed event
to receive an event?".
But no, perhaps that would be too easy to contact the person that created the class in the first place to ask a question or communicate with on the product.
Since you are using the class then you should be able to determine if an event occurs when a key/value pair is altered. Or do you want somebody here to download and use the class and then provide you with information on how the class works or something?
It's not a simple class to run through. But I'll post it.
It seems to me the OnPropertyChanged sub gets called by the Private Sub OnCollectionChanged(ByVal action As NotifyCollectionChangedAction, ByVal newItems As IList) which seems relatively simple to figure out.
Imports System.ComponentModel
Imports System.Collections.Specialized
Public Class ObservableDictionary(Of TKey, TValue)
Implements IDictionary(Of TKey, TValue), INotifyPropertyChanged, INotifyCollectionChanged
#Region "Constructors"
Public Sub New()
m_Dictionary = New Dictionary(Of TKey, TValue)
End Sub
Public Sub New(ByVal dictionary As IDictionary(Of TKey, TValue))
m_Dictionary = New Dictionary(Of TKey, TValue)(dictionary)
End Sub
Public Sub New(ByVal comparer As IEqualityComparer(Of TKey))
m_Dictionary = New Dictionary(Of TKey, TValue)(comparer)
End Sub
Public Sub New(ByVal capacity As Integer)
m_Dictionary = New Dictionary(Of TKey, TValue)(capacity)
End Sub
Public Sub New(ByVal dictionary As IDictionary(Of TKey, TValue), ByVal comparer As IEqualityComparer(Of TKey))
m_Dictionary = New Dictionary(Of TKey, TValue)(dictionary, comparer)
End Sub
Public Sub New(ByVal capacity As Integer, ByVal comparer As IEqualityComparer(Of TKey))
m_Dictionary = New Dictionary(Of TKey, TValue)(capacity, comparer)
End Sub
#End Region 'Constructors
#Region "Fields"
Private Const CountString As String = "Count"
Private Const IndexerName As String = "Item[]"
Private Const KeysName As String = "Keys"
Private Const ValuesName As String = "Values"
Public Event PropertyChanged(ByVal sender As Object, ByVal e As PropertyChangedEventArgs) _
Implements INotifyPropertyChanged.PropertyChanged
Public Event CollectionChanged(ByVal sender As Object, ByVal e As NotifyCollectionChangedEventArgs) _
Implements INotifyCollectionChanged.CollectionChanged
Private m_Dictionary As IDictionary(Of TKey, TValue)
#End Region 'Fields
Protected ReadOnly Property Dictionary As IDictionary(Of TKey, TValue)
Get
Return m_Dictionary
End Get
End Property
Public Overloads Sub Clear() Implements ICollection(Of KeyValuePair(Of TKey, TValue)).Clear
If Dictionary.Count > 0 Then
Dictionary.Clear()
OnCollectionChanged()
End If
End Sub
Public Sub Add(ByVal item As KeyValuePair(Of TKey, TValue)) Implements ICollection(Of KeyValuePair(Of TKey, TValue)).Add
Insert(item.Key, item.Value, True)
End Sub
Public Sub Add(ByVal key As TKey, ByVal value As TValue) Implements IDictionary(Of TKey, TValue).Add
Insert(key, value, True)
End Sub
Public Sub AddRange(ByVal items As IDictionary(Of TKey, TValue))
If items Is Nothing Then Throw New ArgumentNullException("items")
If items.Count > 0 Then
If Dictionary.Count > 0 Then
If items.Keys.Any(Function(key) Dictionary.ContainsKey(key)) Then
Throw New ArgumentException("An item with the same key has already been added.")
Else
For Each i In items
Dictionary.Add(i)
Next
End If
Else
m_Dictionary = New Dictionary(Of TKey, TValue)(items)
End If
OnCollectionChanged(NotifyCollectionChangedAction.Add, items.ToArray)
End If
End Sub
Private Function Remove(ByVal item As KeyValuePair(Of TKey, TValue)) As Boolean _
Implements ICollection(Of KeyValuePair(Of TKey, TValue)).Remove
Return Remove(item.Key)
End Function
Public Function Remove(ByVal key As TKey) As Boolean Implements IDictionary(Of TKey, TValue).Remove
If key Is Nothing Then Throw New ArgumentNullException("key")
Dim item As TValue
Dictionary.TryGetValue(key, item)
Dim removed = Dictionary.Remove(key)
If removed Then OnCollectionChanged() 'FieldsNotifyCollectionChangedAction.Remove, New KeyValuePair(Of TKey, TValue)(key, item)
Return removed
End Function
Default Public Property Item(ByVal key As TKey) As TValue Implements IDictionary(Of TKey, TValue).Item
Get
Return Dictionary(key)
End Get
Set(ByVal value As TValue)
Insert(key, value, False)
End Set
End Property
Private Sub Insert(ByVal key As TKey, ByVal value As TValue, ByVal add As Boolean)
If key Is Nothing Then Throw New ArgumentNullException("key")
Dim item As TValue
If Dictionary.TryGetValue(key, item) Then
If add Then Throw New ArgumentException("An item with the same key has already been added.")
If Equals(item, value) Then Exit Sub
Dictionary(key) = value
OnCollectionChanged(NotifyCollectionChangedAction.Replace, New KeyValuePair(Of TKey, TValue)(key, value),
New KeyValuePair(Of TKey, TValue)(key, item))
Else
Dictionary(key) = value
OnCollectionChanged(NotifyCollectionChangedAction.Add, New KeyValuePair(Of TKey, TValue)(key, value))
End If
End Sub
#Region "ReadOnly methods and properties"
Public Overloads Sub CopyTo(ByVal array() As KeyValuePair(Of TKey, TValue), ByVal arrayIndex As Integer) _
Implements ICollection(Of KeyValuePair(Of TKey, TValue)).CopyTo
Dictionary.CopyTo(array, arrayIndex)
End Sub
Public Overloads ReadOnly Property Count As Integer Implements ICollection(Of KeyValuePair(Of TKey, TValue)).Count
Get
Return Dictionary.Count
End Get
End Property
Public ReadOnly Property IsReadOnly As Boolean Implements ICollection(Of KeyValuePair(Of TKey, TValue)).IsReadOnly
Get
Return Dictionary.IsReadOnly
End Get
End Property
Public ReadOnly Property Keys As ICollection(Of TKey) Implements IDictionary(Of TKey, TValue).Keys
Get
Return Dictionary.Keys
End Get
End Property
Public ReadOnly Property Values As ICollection(Of TValue) Implements IDictionary(Of TKey, TValue).Values
Get
Return Dictionary.Values
End Get
End Property
Public Function Contains(ByVal item As KeyValuePair(Of TKey, TValue)) As Boolean _
Implements ICollection(Of KeyValuePair(Of TKey, TValue)).Contains
Return Dictionary.Contains(item)
End Function
Public Function ContainsKey(ByVal key As TKey) As Boolean Implements IDictionary(Of TKey, TValue).ContainsKey
Return Dictionary.ContainsKey(key)
End Function
Public Function ContainsValue(ByVal value As TValue) As Boolean
Return Dictionary.Values.Contains(value)
End Function
Public Function TryGetValue(ByVal key As TKey, ByRef value As TValue) As Boolean _
Implements IDictionary(Of TKey, TValue).TryGetValue
Return Dictionary.TryGetValue(key, value)
End Function
Public Overloads Function GetEnumerator() As IEnumerator(Of KeyValuePair(Of TKey, TValue)) _
Implements IEnumerable(Of KeyValuePair(Of TKey, TValue)).GetEnumerator
Return Dictionary.GetEnumerator
End Function
Private Function GetIEnumerableEnumerator() As IEnumerator Implements IEnumerable.GetEnumerator
Return DirectCast(Dictionary, IEnumerable).GetEnumerator
End Function
Private Sub OnPropertyChanged()
OnPropertyChanged(CountString)
OnPropertyChanged(IndexerName)
OnPropertyChanged(KeysName)
OnPropertyChanged(ValuesName)
End Sub
Protected Overridable Sub OnPropertyChanged(ByVal propertyName As String)
RaiseEvent PropertyChanged(Me, New PropertyChangedEventArgs(propertyName))
End Sub
Private Sub OnCollectionChanged()
OnPropertyChanged()
RaiseEvent CollectionChanged(Me, New NotifyCollectionChangedEventArgs(NotifyCollectionChangedAction.Reset))
End Sub
Private Sub OnCollectionChanged(ByVal action As NotifyCollectionChangedAction,
ByVal changedItem As KeyValuePair(Of TKey, TValue))
OnPropertyChanged()
RaiseEvent CollectionChanged(Me, New NotifyCollectionChangedEventArgs(action, changedItem))
End Sub
Private Sub OnCollectionChanged(ByVal action As NotifyCollectionChangedAction, ByVal newItem As KeyValuePair(Of TKey, TValue),
ByVal oldItem As KeyValuePair(Of TKey, TValue))
OnPropertyChanged()
RaiseEvent CollectionChanged(Me, New NotifyCollectionChangedEventArgs(action, newItem, oldItem))
End Sub
Private Sub OnCollectionChanged(ByVal action As NotifyCollectionChangedAction, ByVal newItems As IList)
OnPropertyChanged()
RaiseEvent CollectionChanged(Me, New NotifyCollectionChangedEventArgs(action, newItems))
End Sub
#End Region 'ReadOnly methods and properties
End Class
La vida loca

Change pointers in ALE/IDOCs

Hi guys,
Can any let me know step by procedure to implenent change pointers using IDocs including ALE settings as i am new to this concept.
Any step by step example will be helpful. useful answers will be rewarded.
Thanks in advance.
Regards,
vinay

Change pointers is the one of the IDOC processing method in ALE.
In this once we make the config to any of messages type , if any changes are made in sending system then IDOC will be posted directly to destination with user interation.
Changes pointers are configured using BD50,BD51,BD53,BD61.
Change pointers are stored in tables BDCP and BDCPS (or BDCP2 in case of high-performance setting) - like CDHDR and CDPOS for change documents (but this is not a controlling table!).
1. Do you really need change pointers?
You need change pointers to distribute changes with the ALE SMD tool. If you do not use this tool, you do not need to write change pointers.
You can deactivate change pointers and activate them again with the transaction BD61.
2. Do you really need to activate change pointers for this messages type?
If some messages types are no longer to be distributed by change pointers, you can
deactivate change pointers for this message type.
You can deactivate change pointers for the message type
and reactivate them again in transaction BD50.
For reduced message types, deactivate the change pointer with the
Reduction tool (transaction BD53).
Applications which write change documents will also try to write change pointers for ALE operations. These are log entries to remember all modified data records relevant for ALE.
Most applications write change documents. These are primarily log entries in the
tables CDHDR and CDPOS.
Change documents remember the modified fields made to the database by an
application. They also remember the user name and the time when the modification
took place.
The decision whether a field modification is relevant for a change document is
triggered by a flag of the modified fields data element. You can set the flag with
SE11 by modifying the data element.
For the purpose of distributing data via ALE to other systems, you may want to
choose other fields, which shall be regarded relevant for triggering a distribution.
Therefore R/3 introduced the concept of change pointers, which are nothing else
than a second log file specially designed for writing the change pointers which are
meant to trigger IDoc distribution via ALE.
So the change pointers will remember the key of the document every time when a
relevant field has changed.
Change pointers are then evaluated by an ABAP which calls the IDoc creation, for
every modified document found in the change pointers.
The Change pointers are written from the routine CHANGEDOCUMENT_CLOSE
when saving the generated change document. So change pointers are automatically
written when a relevant document changes.
The following function is called from within CHANGEDOCUMENT_CLOSE in order to write the change pointers.
CALL FUNCTION 'CHANGE_POINTERS_CREATE'
EXPORTING
change_document_header = cdhdr
TABLES
change_document_position = ins_cdpos.
Activation of change pointer update :
Change pointers are log entries to table BDCP which are written every time a transaction modifies certain fields. The change pointers are designed for ALE distribution and written by the function CHANGE_DOCUMENT_CLOSE.
Change pointers are written for use with ALE. There are ABAPs like RBDMIDOC
which can read the change pointers and trigger an IDoc for ALE distribution.
The change pointers are mainly the same as change documents. They however can
be set up differently, so fields which trigger change documents are not necessarily
the same that cause change pointers to be written.
In order to work with change pointers there are two steps to be performed
1) Turn on change pointer update generally
2) Decide which message types shall be included for change pointer update
R3 allows to activate or deactivate the change pointer update. For this purpose it
maintains a table TBDA1. The decision whether the change pointer update is active
is done with a Function Ale_Component_Check
This check does nothing else than to check, if this table has an entry or not. If there is an entry in TBDA1, the ALE change pointers are generally active. If this table is empty, change pointers are turned off for everybody and everything, regardless of the other settings.
The two points read like you had the choice between turning it on generally or
selectively. This is not the case: you always turn them on selectively. The switch to
turn on generally is meant to activate or deactivate the whole mechanism.
The change pointers which have not been processed yet, can be read with a function
module.
Call Function 'CHANGE_POINTERS_READ'
The ABAP RBDMIDOC will process all open change pointers and distribute the
matching IDocs.
When you want to send out an IDoc unconditionally every time a transaction
updates, you better use the workflow from the change documents.
To generate the IDOCS in case of change pointers we need to use the standard report
RBDMIDOC
we need execute the follwing t.code
BD61:to activate the change pointers globally
BD50,BD52: to activate message types ,and to enable the fileds for change pointers
Hope this link will help you regarding Change Pointer...
http://help.sap.com/saphelp_erp2005vp/helpdata/en/ba/c9c1c31253ed4596e3bbb74922cd4a/frameset.htm
Change Pointer Configuration and extraction in HRPay.
Infotypes to be logged are in:
V_T585A,
V_T585B,
& V_T585C
Please view the table contents to understand the structure of these tables and how they are linked. These help you identify the cluster tables which store the data.
Payroll Cluster Table PCL4 contains the cluster table reference. (Please refer to the table structure below:
Payroll Custer Tables
http://www.planetsap.com/HR_ABAP_payroll.htm
Cluster tables combine the data from several tables with identical (or almost identical) keys into one physical record on the database.
Data is written to a database in compressed form.
Retrieval of data is very fast if the primary key is known.
Cluster tables are defined in the data dictionary as transparent tables.
External programs can NOT interpret the data in a cluster table.
Special language elements EXPORT TO DATABASE, IMPORT TO DATABASE and DELETE FROM DATABASE are used to process data in the cluster tables.
PCL1 - Database for HR work area; (long text, etc)
PCL2 - Accounting Results (time, travel expense and payroll); (payroll results)
PCL3 - Applicant tracking data;
PCL4 - Documents, Payroll year-end Tax data (change logs, etc)
Database Table PCL4
The database table PCL4 contains the following data areas:
LA change logs (long term documents)
SA Short-Term Documents for HR Master Data
SB Short-Term Documents for Applicant Master
SRTFD (PC400) = trans class always A for master data (1) pernr (8) info type (4) modified date (8) modified time (8) seqnr (4)
Please note that for the extraction of data, you have to use the date portion of the SRTFD and not the field value AEDTM(since it is not primary key).
Naming convention for INCLUDES when defining clusters. These INCLUDES will define the work area key above and the cluster data that is returned from an IMPORT:
RPCnxxy0
n = 1, 2, 3 or 4 (for PCL1, PCL2, PCL3, PCL4)
xx = cluster ID
y = country grouping (0 for international otherwise country indicator T500L)
Description of Cluster Data using Cluster RX as an Example
The data description is stored in the include RPC2RX00 in accordance with the above naming conventions.
RPC1TX00 - Long text cluster ID in table PCL1
RPC2RUU0 - Payroll results for the US cluster ID in table PCL2
RPC4LA00 - Change log cluster ID in table PCL4
Importing Data (I)
The IMPORT command causes data objects with the specified key values to be read from PCLn.
If the import is successful, SY-SUBRC is 0; if not, it is 4.
REPORT ZRPIMPORT.
TABLES: PCLn.
INCLUDE RPCnxxy0. "Cluster definition
Fill cluster Key
Import record
IMPORT TABLE1 FROM DATABASE PCLn(xx) ID xx-KEY.
IF SY-SUBRC EQ 0.
Display data object
ENDIF.
See sample program for long text.
Importing data (II)
Import data using macro RP-IMP-Cn-xy.
Check return code SY-SUBRC. If 0, it is successful. If 4, error.
Need include buffer management routines RPPPXM00
REPORT ZRPIMPORT.
*Buffer definition
INCLUDE RPPPXD00.
DATA: BEGIN OF COMMON PART 'BUFFER'.
INCLUDE RPPPXD10.
DATA: END OF COMMON PART 'BUFFER'.
*import data to buffer
RP-IMP-Cn-xy.
*Buffer management routines
INCLUDE RPPPXM00.
Cluster Authorization
Simple EXPORT/IMPORT statement does not check for cluster authorization.
Use EXPORT/IMPORT via buffer, the buffer management routines check for cluster authorization.
rpcbdt00 - include needed for importing from database PCL4(la) (Change log cluster ID)
Please note that data for change pointers is stored at two levels: 1) Header which has the key info and 2) BELEGE which has the changed info ie. Old value and new value.
Check standard program RPUAUD00
Applications which write change documents will also try to write change pointers for ALE operations. These are log entries to remember all modified data records relevant for ALE.
Most applications write change documents. These are primarily log entries in the tables CDHDR and CDPOS.
Change documents remember the modified fields made to the database by an application. They also remember the user name and the time when the modification took place.
The decision whether a field modification is relevant for a change document is triggered by a flag of the modified fields data element. You can set the flag with SE11 by modifying the data element.
For the purpose of distributing data via ALE to other systems, you may want to choose other fields, which shall be regarded relevant for triggering a distribution.
Therefore R/3 introduced the concept of change pointers, which are nothing else than a second log file specially designed for writing the change pointers which are meant to trigger IDoc distribution via ALE.
So the change pointers will remember the key of the document every time when a relevant field has changed.
Change pointers are then evaluated by an ABAP which calls the IDoc creation, for every modified document found in the change pointers.
The Change pointers are written from the routine CHANGEDOCUMENT_CLOSE when saving the generated change document. So change pointers are automatically written when a relevant document changes.
The following function is called from within CHANGEDOCUMENT_CLOSE in order to write the change pointers.
CALL FUNCTION 'CHANGE_POINTERS_CREATE'
EXPORTING
change_document_header = cdhdr
TABLES
change_document_position = ins_cdpos.
Activation of change pointer update :
Change pointers are log entries to table BDCP which are written every time a transaction modifies certain fields. The change pointers are designed for ALE distribution and written by the function CHANGE_DOCUMENT_CLOSE.
Change pointers are written for use with ALE. There are ABAPs like RBDMIDOC which can read the change pointers and trigger an IDoc for ALE distribution.
The change pointers are mainly the same as change documents. They however can be set up differently, so fields which trigger change documents are not necessarily the same that cause change pointers to be written.
In order to work with change pointers there are two steps to be performed
1) Turn on change pointer update generally
2) Decide which message types shall be included for change pointer update
R3 allows to activate or deactivate the change pointer update. For this purpose it
maintains a table TBDA1. The decision whether the change pointer update is active
is done with a Function Ale_Component_Check
This check does nothing else than to check, if this table has an entry or not. If there is an entry in TBDA1, the ALE change pointers are generally active. If this table is empty, change pointers are turned off for everybody and everything, regardless of the other settings.
The two points read like you had the choice between turning it on generally or selectively. This is not the case: you always turn them on selectively. The switch to turn on generally is meant to activate or deactivate the whole mechanism.
The change pointers which have not been processed yet, can be read with a function module.
Call Function 'CHANGE_POINTERS_READ'
The ABAP RBDMIDOC will process all open change pointers and distribute the matching IDocs.
When you want to send out an IDoc unconditionally every time a transaction updates, you better use the workflow from the change documents.
Arunsri
Posts: 307
Registered: 12/3/07
Forum Points: 246
Re: change pointers method
Posted: Feb 27, 2008 11:08 AM in response to: satish abap E-mail this message Reply
hi,,
Activating Change Pointers
Use
You can activate change pointers in the HR system to avoid distributing the entire structure when you make changes to the HR-ORG model, and distribute instead only the changes that you have made.
Procedure
1. In the Implementation Guide (IMG, transaction SALE), choose Modeling and Implementing ® Master Data Distribution ®Replication of Modified Data ® Activate Change Pointers ‑ Generally.
2. Set the activation status Activate Change Pointers ‑ Generally, and save your entry.
3. Choose the activity Activate Change Pointers for Message Types.
4. Set the active indicator for the message type HRMD_ABA.
5. Save your entries.
also see this link,
http://help.sap.com/saphelp_47x200/helpdata/en/ba/c9c1c31253ed4596e3bbb74922cd4a/frameset.htm
http://help.sap.com/saphelp_47x200/helpdata/en/ba/c9c1c31253ed4596e3bbb74922cd4a/frameset.htm
Check the links below;
http://help.sap.com/saphelp_nw70/helpdata/en/f1/035c8cae3d11d3b540006094192fe3/frameset.htm
http://help.sap.com/saphelp_nw70/helpdata/en/12/83e03c19758e71e10000000a114084/frameset.htm
Reward if useful

Change Pointers Issue

Hi
Pls any body can give me step by step settings to save the changes to the DB tables(Change Log)
I am trying to read change pointers for a 1) FAGL_011PC table.But when ever i change the data using T Code FSE2 the data is saving in this table but the changes are not getting saved in CDHDR/CDPOS.
Chagne Log Check Box in tech Settings I Activated.
What shouls i Do ?
Thanks in Advance
PREETI Raj

Hi,
Change pointers is the one of the IDOC processing method in ALE.
In this once we make the config to any of messages type , if any changes are made in sending system then IDOC will be posted directly to destination with user interation.
Changes pointers are configured using BD50,BD51,BD53,BD61.
Change pointers are stored in tables BDCP and BDCPS (or BDCP2 in case of high-performance setting) - like CDHDR and CDPOS for change documents (but this is not a controlling table!).
1. Do you really need change pointers?
You need change pointers to distribute changes with the ALE SMD tool. If you do not use this tool, you do not need to write change pointers.
You can deactivate change pointers and activate them again with the transaction BD61.
2. Do you really need to activate change pointers for this messages type?
If some messages types are no longer to be distributed by change pointers, you can
deactivate change pointers for this message type.
You can deactivate change pointers for the message type
and reactivate them again in transaction BD50.
For reduced message types, deactivate the change pointer with the
Reduction tool (transaction BD53).
Applications which write change documents will also try to write change pointers for ALE operations. These are log entries to remember all modified data records relevant for ALE.
Most applications write change documents. These are primarily log entries in the
tables CDHDR and CDPOS.
Change documents remember the modified fields made to the database by an
application. They also remember the user name and the time when the modification
took place.
The decision whether a field modification is relevant for a change document is
triggered by a flag of the modified fields data element. You can set the flag with
SE11 by modifying the data element.
For the purpose of distributing data via ALE to other systems, you may want to
choose other fields, which shall be regarded relevant for triggering a distribution.
Therefore R/3 introduced the concept of change pointers, which are nothing else
than a second log file specially designed for writing the change pointers which are
meant to trigger IDoc distribution via ALE.
So the change pointers will remember the key of the document every time when a
relevant field has changed.
Change pointers are then evaluated by an ABAP which calls the IDoc creation, for
every modified document found in the change pointers.
The Change pointers are written from the routine CHANGEDOCUMENT_CLOSE
when saving the generated change document. So change pointers are automatically
written when a relevant document changes.
The following function is called from within CHANGEDOCUMENT_CLOSE in order to write the change pointers.
CALL FUNCTION 'CHANGE_POINTERS_CREATE'
EXPORTING
change_document_header = cdhdr
TABLES
change_document_position = ins_cdpos.
Activation of change pointer update :
Change pointers are log entries to table BDCP which are written every time a transaction modifies certain fields. The change pointers are designed for ALE distribution and written by the function CHANGE_DOCUMENT_CLOSE.
Change pointers are written for use with ALE. There are ABAPs like RBDMIDOC
which can read the change pointers and trigger an IDoc for ALE distribution.
The change pointers are mainly the same as change documents. They however can
be set up differently, so fields which trigger change documents are not necessarily
the same that cause change pointers to be written.
In order to work with change pointers there are two steps to be performed
1) Turn on change pointer update generally
2) Decide which message types shall be included for change pointer update
R3 allows to activate or deactivate the change pointer update. For this purpose it
maintains a table TBDA1. The decision whether the change pointer update is active
is done with a Function Ale_Component_Check
This check does nothing else than to check, if this table has an entry or not. If there is an entry in TBDA1, the ALE change pointers are generally active. If this table is empty, change pointers are turned off for everybody and everything, regardless of the other settings.
The two points read like you had the choice between turning it on generally or
selectively. This is not the case: you always turn them on selectively. The switch to
turn on generally is meant to activate or deactivate the whole mechanism.
The change pointers which have not been processed yet, can be read with a function
module.
Call Function 'CHANGE_POINTERS_READ'
The ABAP RBDMIDOC will process all open change pointers and distribute the
matching IDocs.
When you want to send out an IDoc unconditionally every time a transaction
updates, you better use the workflow from the change documents.
Regards,
Shiva Kumar

Change Pointers Needed

Hi All,
Please give me a scenario to expalin about change pointers.
Regards,
Srik

Change Pointer Configuration and extraction in HRPay.
Infotypes to be logged are in:
V_T585A,
V_T585B,
& V_T585C
Please view the table contents to understand the structure of these tables and how they are linked. These help you identify the cluster tables which store the data.
Payroll Cluster Table PCL4 contains the cluster table reference. (Please refer to the table structure below:
Payroll Custer Tables
http://www.planetsap.com/HR_ABAP_payroll.htm
Cluster tables combine the data from several tables with identical (or almost identical) keys into one physical record on the database.
Data is written to a database in compressed form.
Retrieval of data is very fast if the primary key is known.
Cluster tables are defined in the data dictionary as transparent tables.
External programs can NOT interpret the data in a cluster table.
Special language elements EXPORT TO DATABASE, IMPORT TO DATABASE and DELETE FROM DATABASE are used to process data in the cluster tables.
PCL1 - Database for HR work area; (long text, etc)
PCL2 - Accounting Results (time, travel expense and payroll); (payroll results)
PCL3 - Applicant tracking data;
PCL4 - Documents, Payroll year-end Tax data (change logs, etc)
Database Table PCL4
The database table PCL4 contains the following data areas:
LA change logs (long term documents)
SA Short-Term Documents for HR Master Data
SB Short-Term Documents for Applicant Master
SRTFD (PC400) = trans class always A for master data (1) pernr (8) info type (4) modified date (8) modified time (8) seqnr (4)
Please note that for the extraction of data, you have to use the date portion of the SRTFD and not the field value AEDTM(since it is not primary key).
Naming convention for INCLUDES when defining clusters. These INCLUDES will define the work area key above and the cluster data that is returned from an IMPORT:
RPCnxxy0
n = 1, 2, 3 or 4 (for PCL1, PCL2, PCL3, PCL4)
xx = cluster ID
y = country grouping (0 for international otherwise country indicator T500L)
Description of Cluster Data using Cluster RX as an Example
The data description is stored in the include RPC2RX00 in accordance with the above naming conventions.
RPC1TX00 - Long text cluster ID in table PCL1
RPC2RUU0 - Payroll results for the US cluster ID in table PCL2
RPC4LA00 - Change log cluster ID in table PCL4
Importing Data (I)
The IMPORT command causes data objects with the specified key values to be read from PCLn.
If the import is successful, SY-SUBRC is 0; if not, it is 4.
REPORT ZRPIMPORT.
TABLES: PCLn.
INCLUDE RPCnxxy0. "Cluster definition
Fill cluster Key
Import record
IMPORT TABLE1 FROM DATABASE PCLn(xx) ID xx-KEY.
IF SY-SUBRC EQ 0.
Display data object
ENDIF.
See sample program for long text.
Importing data (II)
Import data using macro RP-IMP-Cn-xy.
Check return code SY-SUBRC. If 0, it is successful. If 4, error.
Need include buffer management routines RPPPXM00
REPORT ZRPIMPORT.
*Buffer definition
INCLUDE RPPPXD00.
DATA: BEGIN OF COMMON PART 'BUFFER'.
INCLUDE RPPPXD10.
DATA: END OF COMMON PART 'BUFFER'.
*import data to buffer
RP-IMP-Cn-xy.
*Buffer management routines
INCLUDE RPPPXM00.
Cluster Authorization
Simple EXPORT/IMPORT statement does not check for cluster authorization.
Use EXPORT/IMPORT via buffer, the buffer management routines check for cluster authorization.
rpcbdt00 - include needed for importing from database PCL4(la) (Change log cluster ID)
Please note that data for change pointers is stored at two levels: 1) Header which has the key info and 2) BELEGE which has the changed info ie. Old value and new value.
Check standard program RPUAUD00
Applications which write change documents will also try to write change pointers for ALE operations. These are log entries to remember all modified data records relevant for ALE.
Most applications write change documents. These are primarily log entries in the tables CDHDR and CDPOS.
Change documents remember the modified fields made to the database by an application. They also remember the user name and the time when the modification took place.
The decision whether a field modification is relevant for a change document is triggered by a flag of the modified fields data element. You can set the flag with SE11 by modifying the data element.
For the purpose of distributing data via ALE to other systems, you may want to choose other fields, which shall be regarded relevant for triggering a distribution.
Therefore R/3 introduced the concept of change pointers, which are nothing else than a second log file specially designed for writing the change pointers which are meant to trigger IDoc distribution via ALE.
So the change pointers will remember the key of the document every time when a relevant field has changed.
Change pointers are then evaluated by an ABAP which calls the IDoc creation, for every modified document found in the change pointers.
The Change pointers are written from the routine CHANGEDOCUMENT_CLOSE when saving the generated change document. So change pointers are automatically written when a relevant document changes.
The following function is called from within CHANGEDOCUMENT_CLOSE in order to write the change pointers.
CALL FUNCTION 'CHANGE_POINTERS_CREATE'
EXPORTING
change_document_header = cdhdr
TABLES
change_document_position = ins_cdpos.
Activation of change pointer update :
Change pointers are log entries to table BDCP which are written every time a transaction modifies certain fields. The change pointers are designed for ALE distribution and written by the function CHANGE_DOCUMENT_CLOSE.
Change pointers are written for use with ALE. There are ABAPs like RBDMIDOC which can read the change pointers and trigger an IDoc for ALE distribution.
The change pointers are mainly the same as change documents. They however can be set up differently, so fields which trigger change documents are not necessarily the same that cause change pointers to be written.
In order to work with change pointers there are two steps to be performed
1) Turn on change pointer update generally
2) Decide which message types shall be included for change pointer update
R3 allows to activate or deactivate the change pointer update. For this purpose it
maintains a table TBDA1. The decision whether the change pointer update is active
is done with a Function Ale_Component_Check
This check does nothing else than to check, if this table has an entry or not. If there is an entry in TBDA1, the ALE change pointers are generally active. If this table is empty, change pointers are turned off for everybody and everything, regardless of the other settings.
The two points read like you had the choice between turning it on generally or selectively. This is not the case: you always turn them on selectively. The switch to turn on generally is meant to activate or deactivate the whole mechanism.
The change pointers which have not been processed yet, can be read with a function module.
Call Function 'CHANGE_POINTERS_READ'
The ABAP RBDMIDOC will process all open change pointers and distribute the matching IDocs.
When you want to send out an IDoc unconditionally every time a transaction updates, you better use the workflow from the change documents.
Arunsri
Posts: 307
Registered: 12/3/07
Forum Points: 246
   Re: change pointers method
Posted: Feb 27, 2008 11:08 AM    in response to: satish abap       E-mail this message      Reply
hi,,
Activating Change Pointers
Use
You can activate change pointers in the HR system to avoid distributing the entire structure when you make changes to the HR-ORG model, and distribute instead only the changes that you have made.
Procedure
1. In the Implementation Guide (IMG, transaction SALE), choose Modeling and Implementing ® Master Data Distribution ®Replication of Modified Data ® Activate Change Pointers ‑ Generally.
2. Set the activation status Activate Change Pointers ‑ Generally, and save your entry.
3. Choose the activity Activate Change Pointers for Message Types.
4. Set the active indicator for the message type HRMD_ABA.
5. Save your entries.
also see this link,
http://help.sap.com/saphelp_47x200/helpdata/en/ba/c9c1c31253ed4596e3bbb74922cd4a/frameset.htm
http://help.sap.com/saphelp_47x200/helpdata/en/ba/c9c1c31253ed4596e3bbb74922cd4a/frameset.htm
Check the links below;
http://help.sap.com/saphelp_nw70/helpdata/en/f1/035c8cae3d11d3b540006094192fe3/frameset.htm
http://help.sap.com/saphelp_nw70/helpdata/en/12/83e03c19758e71e10000000a114084/frameset.htm
Reward points hope this helps u,

What are change pointers

What are change pointers?
where do we process them,
where do we configure them
and what is its fuinctionality
please advice
Edited by: kittu reddy on Feb 11, 2008 5:02 AM
Edited by: kittu reddy on Feb 11, 2008 5:03 AM

hi,
Applications which write change documents will also try to write change pointers for ALE operations. These are log entries to remember all modified data records relevant for ALE.
Most applications write change documents. These are primarily log entries in the
tables CDHDR and CDPOS.
Change documents remember the modified fields made to the database by an
application. They also remember the user name and the time when the modification
took place.
The decision whether a field modification is relevant for a change document is
triggered by a flag of the modified field’s data element. You can set the flag with
SE11 by modifying the data element.
For the purpose of distributing data via ALE to other systems, you may want to
choose other fields, which shall be regarded relevant for triggering a distribution.
Therefore R/3 introduced the concept of change pointers, which are nothing else
than a second log file specially designed for writing the change pointers which are
meant to trigger IDoc distribution via ALE.
So the change pointers will remember the key of the document every time when a
relevant field has changed.
Change pointers are then evaluated by an ABAP which calls the IDoc creation, for
every modified document found in the change pointers.
The Change pointers are written from the routine CHANGEDOCUMENT_CLOSE
when saving the generated change document. So change pointers are automatically
written when a relevant document changes.
The following function is called from within CHANGEDOCUMENT_CLOSE in order to write the change pointers.
CALL FUNCTION 'CHANGE_POINTERS_CREATE'
EXPORTING
change_document_header = cdhdr
TABLES
change_document_position = ins_cdpos.
Activation of change pointer update :
Change pointers are log entries to table BDCP which are written every time a transaction modifies certain fields. The change pointers are designed for ALE distribution and written by the function CHANGE_DOCUMENT_CLOSE.
Change pointers are written for use with ALE. There are ABAPs like RBDMIDOC
which can read the change pointers and trigger an IDoc for ALE distribution.
The change pointers are mainly the same as change documents. They however can
be set up differently, so fields which trigger change documents are not necessarily
the same that cause change pointers to be written.
In order to work with change pointers there are two steps to be performed
1) Turn on change pointer update generally
2) Decide which message types shall be included for change pointer update
R3 allows to activate or deactivate the change pointer update. For this purpose it
maintains a table TBDA1. The decision whether the change pointer update is active
is done with a Function Ale_Component_Check
This check does nothing else than to check, if this table has an entry or not. If there is an entry in TBDA1, the ALE change pointers are generally active. If this table is empty, change pointers are turned off for everybody and everything, regardless of the other settings.
The two points read like you had the choice between turning it on generally or
selectively. This is not the case: you always turn them on selectively. The switch to
turn on generally is meant to activate or deactivate the whole mechanism.
The change pointers which have not been processed yet, can be read with a function
module.
Call Function 'CHANGE_POINTERS_READ'
The ABAP RBDMIDOC will process all open change pointers and distribute the
matching IDocs.
When you want to send out an IDoc unconditionally every time a transaction
updates, you better use the workflow from the change documents.

Avoiding change pointers for data with status planned

Hi,
we have to distribute HCM-data, standard infotypes and customer infotypes, into other SAP sytems. One of the receiving systems must not get data with the status planned (istat = 2).
Which would be the best way to avoid planned data in the receiving system? Is it possible to avoid creating change pointers for planned data in the delivering system or have I to delete the planned data in the receiving system while processing the idocs via user-exit?
Best regards
Stefan

Dear Stefan,
You can create the change pointers manually from the IDOC data (e.g.with FM CHANGE_POINTERS_CREATE) during the inbound processing within of the customer-exits of enhancement RHALE001 or within an own BAdI implementation of BAdI HRALE00INBOUND_IDOC.
Or else you can use method IDOC_DATA_FOR_RECEIVER_MODIFY of BAdI HRALE00OUTBOUND_IDOC. In this case please make sure that note 1292241 is implemented.
Hope it helps,
Christine

Generating the IDocs for some particular segments only......

Hi Gurus,
I have activates the change Pointers for generating the IDocs whenever the master dtaa is changed.
Is there any technique so that I can recive the IDocs containing only those segment's data which is relevant for me.
Abhi....

The question I have asked is not related to Inbound I Docs processing.
Actually I am sending the IDocs to Non-SAP system whenever any change is made to the master data, using the Change Pointers.
Now, the situation is that the file that is getting generated contains the data corresponding to many segments. So, is it possible to restrict the segments/fields for which the data is generated.
Thanks In Advance.......
Abhi.,,

Reg : change pointer mechanism for triggering the IDOC for delivery note

Hi ,
I am working on a change pointer mechanism for triggering the IDOC for delivery note and will be using this message class DESADV.
So SAP has suggested for assigning the message class DESADV with the function module in MASTERIDOC_CREATE_SMD_DESADV in BD60 transaction code.
So I was looking to create this MASTERIDOC_CREATE_SMD_DESADV function module in SAP and SAP suggesting that we should create this MASTERIDOC_CREATE_SMD_DESADV function module as same as the function module MASTERIDOC_CREATE_SMD_MATMAS.
So do anyone knows that is there any tool has been provided by SAP for creating this function module MASTERIDOC_CREATE_SMD_DESADV in SAP system for triggering the change pointer mechanism for outbound Delivery.
Thanks !
Regards,
Kiran

Hi,
When you are change pointer the system itself will take care of sending the changed master data to your partner system and the user will not have any intervention. If you really wanted to have that then you need to use the change pointers to read the master data which is modified in a custom program and then display that on the screen. Once the user selects that master data records then trigger an IDOC for creating the idoc for that master data and also flag that master data record as processed in the SAP BDCPS standard table, so that the same record will not be picked. If you wanted to know how the change pointers piece of code is written go through the program RBDMIDOC and you can understand how the change pointers logic is written.
Thanks,
Mahesh.

Automatic Trigger of Idoc Sending to PI on Material Master Create/Change

Hi All,
I would like to ask how to automatically trigger sending of idoc on material master create/change without using a standard transaction like BD10. I already tried using MASTER_IDOC_DISTRIBUTE in the material master change user exit. It does send the idoc but my problem is when an inbound idoc creates a material, it will then pass through the userexit and use MASTER_IDOC_DISTRIBUTE again.
Any suggestions? Or do you have a better solution for this? My requirement is when uer goes throgh MM01/MM02 an idoc will automatically be sent to PI.
Thanks.

First of all a quick comment to your present solution. If it works and your only problem is that you'd like to suppress triggering the IDoc creation when a material is created/updated via inbound IDoc then you might want to just fix that. There's many possible ways to approach this, it all depends how much you want to change and what your processes are (I sorted the listed ones in order of personal preference, though the list is not complete for sure):
<ul style="list-style:circle;">
<li>Export some flag to memory when processing an IDoc that you can import in your exit and thus recognize that you don't want to send an IDoc. Depending on how you are processing your inbound IDoc BAdI BADI_MATMAS_ALE_IN might work; you might find others if this is not applicable or sufficient. If you're working on ECC 6.0 you could also consider coding the export of the flag in an implicit enhancement spot in your function modules used for IDoc processing.</li>
<li>Evaluate in your existing coding the transaction code SY-TCODE; most likely you should see a clear difference between your IDoc processing and the other updates where you want to trigger the IDoc.</li>
<li>Most likely the IDoc processing triggers function module MATERIAL_MAINTAIN_DARK (e.g. MATERIAL_INPUT_MATMAS01 does); this function module uses a global variable FLAG_BAPI_CALL to indicate the non-dialog processing. So if you feel adventurous you could evaluate this flag in your coding.</li>
</ul>
Change pointer won't really do you any good if your functionality is already working without them apart from the trigger. Even if you write change pointers, you still have to implement the trigger functionality, so essentially back to square one...
In general another good option is often to use workflow events that are already triggered. I.e. in your case business object BUS1001006 almost does the trick. It has events for ViewCreated and Created, but unfortunately lacks events for material updates (and I didn't see any other appropriate object that has it and a quick trace while updating a material didn't fire any appropriate event).
Cheers, harald

Auto Trigger DEBMAS IDoc for a customer change

Hello Experts,
I have a business case where in I need to auto trigger the DEBMAS IDoc when ever customer details are changed. What is that I need to do in SAP to trigger the IDoc automatically.
Please help
Thanks in Advance,
Suma

Hello Suma,
Please follow this.....
Automatic generation of IDOC when we change the MASTER DATA:
Change Pointers:
Change documents are working based on change document technique which
tracks changes made to the key documents (Material Master, Customer Master,
Vendor Master.Etc) in SAP.
Changes made to the keydocuments are recorded in the change document Header
table i.e. CDHDR and Item table CDPOS, Additional change pointers are written
in the BDCP and BDCPS tables.
Change pointers technique is used to initiate the outbound process automatically
when master data is created or changed.
A standard program RBDMIDOC is sechuled to run on periodic basis to evaluate the change pointers for a message type and starts the ALE process for distributing the Masterdata to the appropriate destination.
'Object' is collection of fields of different database tables. T.code for creating an object
is SCDO.
Configuration for Change Pointers:
1. BD61 Active change pointers generally
- Check the checkbox "Change pointers activated -generally"
- Save it
2. BD50 Active change pointers for Message Type
Message Type Active
DEBMAS Check the check box
3. BD52 Maintain Table Views
Enter the Message type "DEBMAS" and press enter.
For example
OBJECT TABLE NAME FIELD NAME
DEBI KNA1 NAME1
5. WE21 Port
6. WE20 Partner Profile
7. BD64 Distribution Model
Use RBDMIDOC program.for executing this program we need to give message type like
MATMAS or
DEBMAS or
CREMAS
depending on your requirement.
go to SE38 tcode Maintain variants then use the same back in scheduling.
STEPS IN BACKGROUND SCHEDULING:
Use tcode SM36
Click Job wizard in the button set
Click Continue
Enter Job name and press continue
Select ABAP program and press Continue
enter Program name and press continue
and again press Continue
set Schedule type immediately and continue
Select periodic job checkbox, press continue
Select none of the above and click on other periods give one-minute and then press create
Press continue and then press complete.
Hope this resolves your issue....
please reward if helpful...
Thanks,
Sree

Idoc not Trigerring for Change Pointers in CREMAS only for 2 fields

Hi All,
I am trying to trigger the Idoc for 2 fields ( Contact Person First Name & last Name) KNVK-NAMEV and KNVK-NAME1. I have maintained the fields in BD52. Whenever I change the fields, entries get created in CDHDR, CDPOS and BDCP. But the Idloc doesnt get triggerred. But if I change any other fields of LFA1 or LFB1 for the same vendor, the Idoc gets created. Can anybody please help out on this?
Thanks,
Geetha

Hi,
Just check after executing the program "RBDMIDOC" idocs getting triggered or not.
Thanks,
Asit Purbey.

Change pointers to trigger the IDOC

Similar Messages

Maybe you are looking for