Generate Change Pointers in non Original System

I have developped in the inbound badis a trigger to generate the change pointers in a non-original system.
Do you know if there is a standard way to generate change pointers in a non-original system?
Landscape is as follow:
Original System => Intermediate System => Final System
I would like to generate change pointers in the Intermediate System to transfer master data into the Final System...

Hi,
Thanks for your reply.
the configuration for change pointers is already done, the problem is that if changes are send from the original system, it doesn't generate a change pointer in the intermediate system.
In the end, the intermediate system doesn't send the information to the final system as there are no change pointers generated by the changes received from the original system.
What I'm doing at the moment is to generate those change pointers in the inbound badi in the intermadiate system, I'm wondering if there is not a standard solution for this kind of implementation.
Cheers,
Lucien.

Similar Messages

Carry out repairs in non-original system only if they are urgent

Hi Experts,
I am getting this message "Carry out repairs in non-original system only if they are urgent" while i try to edit a z function module which i have created in the development system. Because of this I can't change the code, I need to use the insert, delete....buttons.
Please help , itz urgent.
Thanks & Regards,
Soumya.

Hello Soumya
Obviously the Z-function module was originally created on another development system. Therefore you get this message.
If you have transferred your function group to another development system then simply change the source system of the function group. You can do this using transaction SE03 (function "Change Object Entries...") or you can use function module TRINT_TADIR_MODIFY.
Regards,
Uwe

Error "Package in non-original system only modifiabl with Organizer Tools"

Assign Customer Objcet PROG to Package "Z001"(created by myself),it pop-up error "Package in non-original system only modifiabl with Organizer Tools"
how can i deal with this error?
could any warm-hearted fellow give me some tips ?
tks a lot !

Hi sophie,
i think you transported this package from another system to a new system and you are trying to modify the package.
just have a look at below link hop it will help ,otherwise let us know
http://help.sap.com/saphelp_nw04/helpdata/en/57/38de9b4eb711d182bf0000e829fbfe/content.htm
cheers
shibu

Msg in Dev Box - Carry out repairs in non-original system only if urgent

Hi, I noticed that I am getting the message "Carry out repairs in non-original system only if they are urgent" when I try to edit certain DTP's in my Development BW Envirionment. This is very unexpected and caught me by surprise.
1. Can anyone tell me what might be causing this?
2. Can anyone tell me what Table I might be able to peruse and determine what the source system is for this DTP?
Thanks for any help with this...

HI
You will get this warning for when modifying an object in ANY system, if that object was not created in that system, but transported from some other system. So, you will get this warning in your Quality/Test/Production systems for the objects which are transported from Development system.
Just ignore if it is in the DEV SYSTEM OR talk to the system administrator.
Hope u got it,
Thanx & Regards,
RavIChandra
Edited by: Ravichandra.bi on Dec 8, 2011 4:04 AM
Edited by: Ravichandra.bi on Dec 8, 2011 8:24 AM

Change pointers not being generated in case of Z fields (extension IDOC)

Hello,
My requirement is of generating change pointers when fields from customer master change ( z fields).
Actually this is working for standard fields, but not for z fields .
I have created a Z segment and added fields 'ADRC-STR_SUPPL3' & 'ADR3-FAX_NUMBER' and have written appropriate code for populating them in 'ZXVSVU01' of exit 'EXIT_SAPLVV01_001' .
However, when I try to run change pointers transaction BD21, it says 0 idocs and 0 communication params generated.I have added those fields properly in BD52 (object class - ADDRESSE).
If you change standard fields along with Z fields, it works, but if you change only the Z fields , it doesn't trigger a change pointer.
Is there something extra that we need to do in case of object class 'ADRESSE' ?
Please help.
Thanks,
Rachna.

Were you able to resolve the issue?
If yes, could you please share what was done to resolve it.
Your help will be greatly appreciated.

Carry out repairs in non-original....

I am trying to update a few programs that are z programs but I get the follow message each time I go into edit mode:
'Carry out repairs in non-original systems only if they are urgent'.
Is there a way for me to get rid of this message? I can't figure out how to update these programs.
Regards,
Davis

It is in change mode but I can't make any changes. I have to click the button that says INSERT and that inserts the following code:
[code]*{ INSERT &$&$&$&$ 1
*} INSERT[/code]
So each time I need to insert code I would have to click on this button which doesn't seem right to me.
Regards,
Aaron

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 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,

EWA on Non-ABAP System with Solution Manager EHP 1

Hi Experts,
We have recently updated our solution manager from SP Stack 16 to EHP1 (sp 18). we are now planning to set up EWA for non-abap components (EP 7.0). however, the only SAP note that i have been able to find is "976054 - Availability of EWA for Non ABAP components" but this is only limited up to SP 17. I have not been able to find any guides relating to EWA thru Solution Manager EHP1.
I would greatly appreciate if anyone can refer any documents or SAP notes that would enable setting up EWA for non-abap components thru Solution Manager EHP1.
We have also gone through the note 1332428, but we have'nt found it useful. We are still struggling to generate EWA report on Non-ABAP system.
Looking forward to your kind help.
Thanks and Regards,
Sarthak Syal

Hi Sarthak,
Good!!
Please do the following:
1) include the system in the Solution and scheduled the EWA session.Logical component should refer to the Non-ABAP System with no ABAP instance as relevant under the SID definition in SMSY-systems.
2) Is the Non -ABAP ( assuming its java) has the Software component defined and is mentioned as relevant under the SID with the component name and type.
3) Having said that SMD - Root cause Analysis functionality is configured-> check whether you are getting the Details for the Non-ABAP systems in the analysis Tabs of Root Cause Analysis.
This should be good to go. Wait for the session to get completed.
Thanks,
Jagan

Business content master data DataSources & change pointers

Hi,
Why general business content master data DataSources donu2019t have the behavior of the ones created for classification data with transaction CTBW. For the 1CL_* DataSources the corresponding message type RS* is created only when you run a delta initialization, and when you delete that initialization the change pointers for that message type become inactive. With general business content master data DataSources the change pointers are active all the time (even if you want to use those DataSources only for full updates). How can I, in BW, deactivate the change pointers for the DataSources Iu2019m not using?
Thanks!

I always assumed it was because BW hijacked the standard change pointers but in hindsight the change pointers are given a RS prefix so that must be wrong as the entries in BDPCV and BDCPS contain that prefix
But I assume you can run BD22 for the RS change pointers for non processed ones
Interesting question - I await other responses (my hunch is that they hijacked the BADI to write to the BD* tables and left the code in for RS* messages)

Hierarchy R3PRODHIER may only be changed in the original system

Hi Experts
I have created a new Product Hierarchy in R/3 when i try to replicated them into CRM by using initial replication of DNL_CUST_PROD1.system throwing an error saying : Hierarchy R3PRODHIER may only be changed in the original system R3LNT200. ....in the SMQ2 before doing initial replication of DNL_CUST_PROD1 status was green.
And again i try to replicated the DNL_CUST_PROD1 by reguest load which has run successfully and 3 blocks are generated then i run the initial replication of Material but status of initial replication status in waiting. which is not run i mean to say.
then i again created a Request load for Object Material and which is run success fully
but my problem is i did not see the new hierarchy and products too in Table COMM_PRODUCT
.and when i see status of the in DNL_CUST_PROD1in R3am1. which is in ABORT .
Hence i request you could you please help me inorder to make green status of the DNL_CUST_PROD1 in r3am1 so that i can able to nun material successfully
i would appreciate you help
thanking you
Regards
Swathi

Hi Swathi,
I'm assuming this development is copied from your production.
For example: Go to COMM_PRODUCT table and check the log sys field. Now it will show the Production Logical System. So you need to convert this value.
After the client copy, basis needs to execute BDLS transaction. This transaction is used to convert the logical systems in all the Database Tables.
     Perform this conversion only for Client Dependent Tables.
     Execute below conversion in CRM Development Box
                   CRMOLDLOGICAL SYSTEM to CRMNEWLOGICALSYSTEM
                   ECCOLDLOGICALSYSTEM to ECCNEWLOGICALSYSTEM
      In ECC Development Box
                   CRMOLDLOGICAL SYSTEM to CRMNEWLOGICALSYSTEM
                   ECCOLDLOGICALSYSTEM to ECCNEWLOGICALSYSTEM
Regards,
Bhanu

BATMAS IDocs not gettting generated using Change Pointers

Hi,
I have scenario where I am supposed to replicate Batch between R/3 & Ware House Systems. So, for this I am using the standard BAPI to generate IDocs correctly for the batch.
Now, when I go and change the document flow i.e. make changes to the Batch using transaction MSC2N and saving a new document is getting generated.
Change Pointers are active globally and also on the message type. Now when I use the transaction BD21 to generate IDocs, they are getting created successfully for the distribution model that is existing. Now, when I add a filter in my distribution model based on Plant IDocs are not getting generated.
Can any one let me know if I missed out any configuration step or else what needs to be done in order to solve this issue.
Raghuram.

Is this thread still valid? If not, please close the thread.
If so, as no response has been submitted, please rephrase your question and/or provide further information to describe your requirement.
Thanks
Jason
SDN SRM Moderator Team

Changing window size of script in Non original language

Hi Gurus,
Is there any option to change the window sizes of a script in NON ORIGINAL language. Generally it wont allow to change window sizes in NON ORIGINAL language.Is there any workaround.Please help.
Thanks & Regards,
Sam.

It is not possible to change the window size in non-original language.. only changes of windows paragraph formats are possible in original languages...
If your form is global templet.. make sure you inform the user and on there approval do customise your form and do the respective changes..
Close the thread once your question is answered.
Regards,
SaiRam

Mass change original system for objects

Is there a way to change the original systems for multiple objects at once?
So instead of changing them one by one, can the original system for objects be changed for multiple objects at once?
Kind regards,
Ben

I've checked with the Basis team, but they couldn't help me further.
For the moment we'll leave the objects like they are and Overwrite the originals when transporting.
Kind regards and thanks,
Ben

Mass change of the Original System

Hello Experts!!!
We need to do a massive change of the original system to avoid repair tasks. I know that thru SE03 or SM30->TADIR is possible, but we need to do it to all objects in the system.... I think It might exist a standar tool for that... what do you think???
Thanks a lot!!!!
Frinee

Also interesting: transport of copies / relocation of objects
http://help.sap.com/saphelp_nw70/helpdata/EN/57/38e1a94eb711d182bf0000e829fbfe/frameset.htm
Thomas

Generate Change Pointers in non Original System

Similar Messages

Maybe you are looking for