Change pointers for DELVRY03 Idoc

Hi,
I need to trigger DELVRY03 idoc whenever a delivery document is changed. I understand that one cud trigger a idoc on creation of delivery document using change pointers. But is it possible to use change pointers on edit of del. doc as well??
Also i guess delivery document is transactional data, hence message control might have to be used, but I am not aware how to configure the same for delivery documents.
If anyone could give me the steps to configure message control then it would be helpful.
Thanks in advance
Anand Chavan

HI Anand
Same kind of problem discussed here...
Change pointers
Hope it will helps you...
Cheers..
Vasu
<i>** REward Points if found useful **</i>

Similar Messages

Reprocessing change pointers for MATMAS idoc

Hi
I have a situation where i executed BD21 for changes to materials but no idocs were created due to some issue with the distribution model. Now i have fixed the issue and would like to re process all the materials which were changed. Since i have already executed BD21, now no new idocs are being generated. Is there a way to reprocess the changed materials and generate the idocs again.
Thanks
Nag

Hi Roger
Thanks for your inputs. I am trying to generate idocs through the change pointers and not using output determination.
When i executed BD21 the first time, idocs were not generated due to some config issues. But the job ended successfully saying that idocs were generated and marked all the changed material documents under change pointers (But in WE02, the idocs never showed up actually).
Now i have fixed the issue in config and want to generate the idocs using the change pointers. Is there any way to regenerate the same idocs using BD21 or some alternative.
Thanks
Nag

Activate change pointers for Z-idocs

Hi friends,
I've created a Z-idoc for some standard SAP tables (like TCJ1T, TCJ05 etc). I've written a function module which fetches all the data from the above-mentioned tables and pass it on to the idoc. So far so good.
Now the requirement is like, I need to pass only the updated records (insert/update/delete) in these tables to the idoc. I found that there are concepts like change document and change pointers assosciated with it. Again, the fields that I need to transfer in the above tables have their change document flag set. I've also created a Z-Object through SCDO to capture the changes. (I initially tried adding the tables in the standard object PROJ regenerated the programs, but the approach didn't work). The function modules generated through SCDO, i guess, have to be called somewhere, may be in an exit (I got an info in a previous question that it is never called automatically, but has to be called explicitly). The entries for most of the tables I'm working with are created via SPRO (which links to the Table Maintainence Generator for the above tables). I found that there are no user-exits for the transactions SPRO and SM30, to call these function modules in the first place.
Change pointers refer to the tables CDHDR and CDPOS, the tables which the change document updates (as found in the function module CHANGE_POINTERS_CREATE). Now, how do I track the updates on these tables, since the change pointers itself is dependent on the change documents and I couldn't find a place to incorporate the function module call that would update the change document tables?
Any help is appreciated.
Thanks & Regards
Anil Madhavan

Hi Anil,
In SM30 you have programmable events:
Environment -> Modification -> Events
Here's the link to documentation teaching how to create change documents:
http://help.sap.com/saphelp_47x200/helpdata/en/2a/fa015b493111d182b70000e829fbfe/frameset.htm
I'm also trying to learn how to access the needed data in these SM30 events so that I can call the function to generate the change document with the right data in SM30
Let me know if this was useful.
Bye,
Nuno

Change pointer for Extended IDOC

Hi guys,
I have Extended a standard IDOC MATMAS and added few additional fields into it.
Now i have make Change pointers enabled for this IDOC extension.
Is it possible?
Can some one guide me as to how can i create Change pointers for EXTENDED IDOC?
any extra steps required?
Sahil

Hi,
you can use BD52 transaction to add the extended idoc fields inorder to activite the change pointers for them.
Please note that the fields in the extended idoc should have chnage entry in CDHDR whenever you change the field in MM02 transaction. if not change pointer will not work.
If these fields are not marked in change entry in MM02 transaction you can use user exit while saving MM02 and then create the change document for them by coding inside those user exit.
Hope it helps,
Shanmugavel chandrasekaran.

ALE/IDOC-How to create Change Pointers for Custom Infotype

Hi,
My requirement is to transfer custom OM infotype changes using IDOCs.
But its not creating any change pointers for that infotype.
The message used is a copy of standard message OM_HRMD_A.
Can any one please help me out in this issue.
Thanks,
Sarika

Hi Sarika,
How did you solve this issue? We are also facing a similar problem, it will be helpful if you could explain how you found out the solution.
Thanks
Anu.

Change pointers for the ZSEGMENT of IDOC Extension.

Hello Experts,
We are working on the SAP version ECC 5.0.
Our requirement is creating the ZZField and use this field to interface with legacy systems in the trnx FD02 and table KNB1.
We have created the ZZField in table KNB1 and also ZSEGMENT for the IDOC DEBMAS06.
We want to add the IDOC change pointers proramme for this ZSEGMENT that is being created.
I know there are two methods of doing this:
OLD METHOD:USER EXIT....
NEW METHOD:CALL CUSTOMER FUNCTION'...'
I tried the old method with the user EXIT_SAPLVV01_0001 for the Cutomer master.
But I am getting the error as
PROGRAMME NAMES zx....ARE PRESERVED FOR THE INCLUDES OF EXIT FUNCTION GROUPS.
Can any one tell me how do i need to write the programme for the IDOC CHANGE POINTERS for the ZSEGMENT?
Thank you.

Our requirement is creating the ZZField and use this field to interface with legacy systems in the trnx FD02 and table KNB1.
We have created the ZZField in table KNB1 and also ZSEGMENT for the IDOC DEBMAS06.
in the above question watr the fields ur going to populate in KNB1 TABLE or in ZSEGMENT FOR DEBMAS06.
CAN U PL GUIDE ME..
thanking u...
ajay

Regarding change pointers for HRMD_A

Hi Abapers,
I need to distribute changes to HR master data to a middleware system. hence i have activated the change pointers for the message type: HRMD_A. now my idoc is populating the infotype segments whenever it is changed with all fields.
But a particular change (on an infotype) should be sent individually in two different runs of RBDMIDOC run to the middleware. Ex: Vendor A needs changes to be sent to it on a weekly basis whereas Vendor B needs changes to be sent to it on a biweekly basis. When an employee X has a change on infotype 2, this change should be sent to middleware in both instances separately in different IDOCS at different times when RBDMIDOC program is run (by capturing change pointers pertinent to the message type of the particular vendor).
What are the changes required for ALE config.? Do i need to create a new message type for vendor B and configure. Please help.
Thanks.

Hi sudarshan,
Yuo need to create Z program to trigger IDOC.
As you need to set read status of change pointer as X after yuo send it to both system.
So you need to create Z table to keep track of this whether you have send to sys a or Sys B..
If you willl not update read status in will cause performance prob.
Hope this helps.
Dhiraj.

How to create change pointers for IT6 when custom table Z777A changes?

Situation: We are using custom table Z777A (copied T777A and added fields) to store building locations. Employee's IT6 subtype 92 retrieves valid work address building locations from table Z777A.
Problem: Whenever there are updates to Z777A, we need to find all IT6 subtype 92 records that use the changed building location from Z777A and create IDOC's The change pointer entry will need to be for the IT6 subtype 92 row that is affected.
Question: Can anyone give me specific details as to how this can be accomplished? Thanks.

Hi,
MASTER DATA CHANGES DISTRIBUTION BY CHANGE POINTER TECHNIQUE:
Step 1: Creating change document object in SCDO transaction.
Step 2:Assigning tables to the change document object.
Step 3:Specifying change document items in transaction BD52.
Step 4: Activating change pointers for the message type HRMD_ABA in transaction BD50.
Step 5:Activating change pointers globally.
Step 6:Executing program RBDMIDOC in SE38, Specifying message type HRMD_ABA.
with regards,
M.Sreeram.

Change pointers for custom message type

Hi All,
Please help me with questions.
1. The requirement is to add two additional fields to CSCK table and then activate change pointers for COSMAS. My question is when I activate the change pointers for COSMAS will it send this two z fields when there is a change?
2. I dont see a message type in BD50 for a standard IDOC Internal_order? Can I add that standard message type? How can I do this? WIll this create an IDOC when ever there is a change in data?
Thanks.

Hello Oscar,
1. Which changes should be relevant for creation of COSMAS-IDoc, you have to define in BD52.
2. You need to define INTERNAL_ORDER in WE20. In BD64 you add BAPI "InternalOrder.SaveReplica", filters can be added.
Best Regards, Dirk

How to implement Change pointers for Purchase order - ME22N - Custom Fields

Hi Experts,
Can you please tell me how to implement - Change Pointer for Custom fields in IDOC.
I am working on IDOC - For purchase order - acknowledgements - in custom screen/tab in ME22N.
Everything is working fine according to my requirement.
All i need to know is the process of - Creating/Change - Change pointers for Custom fields.
1.How to implement change pointers for custom fields.
2.Can we maintain - Change Document - for custom fields at data element level?
P.S. - I have browsed many previous - forums before posting a new discussion.
please share your inputs...
explaining how to create/implement - change pointers for custom fields will help me .
Regards,
Karthik Rali.

Hi,
To maintain Change Document for custom field:
1. Check if "Change document" checkbox is set in data element.
2. Find Change Document Object for transaction.
   You can use SQL trace - ST05.
   Look there for line with table CDHDR and statement insert values
   (for example for transaction KA02 Change Document Object is KSTAR)
3. Regenerate update program for this Change Document Object in transaction SCDO
Change documents for z-fields schould be generated.
I am not sure about change pointers but they are configured somehow in BD61 and BD50.

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

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 for HR master data

Hi I am trying to setup change pointers for HR Master data , in relation to HRMD_A06 idoc , I did all the steps for setting up change pointers.
Transaction bd52 for my reduced IDOC shows 0 entries, When i did the same for customer master data , BD52 had some entries by itself .
I can't produce any HRMD_A06 Idocs , What am i doing wrong? Should the entries in BD52 be added manually for all the fields i need?
Any help is much appriciated.
Sudheer

Hi,
guess it's not necessary to see some entries in bd52 (it's enough to activate in bd53).
Do you have configured RBDMIDOC (otherwise no IDocs will get generated).
Or you run t-code bd21 for testing. Standard way is to run the report RBDMIDOC in a periodic background job.
A good description could be found here (p. 12):
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/30139fb0-360c-2a10-1e9f-9d5417754983
Regards
Patrick
Edited by: Patrick Koehnen on Aug 12, 2008 3:40 PM

Why change pointers for master data, why not change message?

Hi Gurus,
I have one doubt about Idoc.
When changes to master data has to be sent Change pointers are configured and used. (CDPOS & CDHDR). In case of the transaction data change change idoc is used as is the case with orders (we use ORDCHG for ORDERS message type to send the chnage details to a order which was already sent to other system.
Why we can't use change idoc or message type whatever, instead of Chnage pointers in case of master data or vice versa in case of transaction data.
Your valuable input will be rewarded with suitable points!!
-B S B.

Change pointers are getting stored in the tables BDCP and BDCPS. As SAP suggests these tables should be as small as possible. And Master data are not much frequently changed data.
As you compare with the transactional data, you need to change them many times in the real scenario. If we also process the transaction data via chnage pointer, these changes BDCP is getting more and more entries.
RBDCPCLR is the program used to process the change pointer. If you have much data in the BDCP table, this program will take much time to run.
So, we use the change pointers for the master data only.
Regards,
Naimesh Patel

Change Pointers for Infotypes - HR Master Data distribution

Hi,
I want to distribute HR infotypes Master Data to other systems...
How do I activate Change pointers for HR infotypes?
Do I have to use idoc HRMD_A or HRMD_B?
Do I have to distribute thru PFAL transaction?
Can I do that a employee change the data of an infotype send the idoc authomaticly?
Thanks in advance.
Regards.
Urtzi.

Thanks Roman,
I've looking also for idoc HRMD_ABA. What is the diference between HRDM_ABA and HRMD_A?
When I press SAVE in PA20 doing changes in an employee system distributes authomatically HRMD_ABA but not HRMD_A. Is it correct?
So, if that is correct could I say the following:
- To distribute HRDM_A we can use report RBDMIDOC scheduleing periodic JOB.
- iDoc HRDM_ABA is distributed when saving data in standard transactions.
Is that correct?
Regards.
Urtzi.

Change pointers for DELVRY03 Idoc

Similar Messages

Maybe you are looking for