how do the change pointers work in RBDMIDOC

[Former Member]

Hi All,

We are using RBDMIDOC for delta loads and I would like to understand how do the change pointers work

for example i changed a record today and a change pointer has been created so when i execute the program it will pick that record.tomorrow i will change one more record and execute the program again ,will it pick the previous change also or only the current change

Thanks

Bala Duvvuri

[Former Member]

Bala,

understood!!

So, coming back to Salai's advise ... how about that?

[Former Member]

hi Bala,

If change pointers are configured properly each time you change the entry new change pointer is created...

Once IDoc is sent for a change next time only new change is checked and send

thanks

Gaurav.

Edited by: gaurav.singh on May 25, 2010 7:26 AM

[Former Member]

Gaurav,

You mean to say once we execute the change pointers and generate idocs ,we cannot execute them again and generate the idocs .

can we change this behaviour so that we can execute the change pointers again and again and generate idocs for same changes

Thanks

Bala Duvvuri

[Former Member]

Hi Bala,

Yes you can do that.

Also provide me details.

I am assuming that you created a FM for change pointers which you have attched in BD60.

In this you have to use some date format to trigger already send IDOC's.

Can you plz provide detail that why you want to trigger already send IDOC's. It will generate some duplicacy of data.

Regards,

Narendra

Edited by: Narendra GSTIT on May 25, 2010 1:02 PM

[Former Member]

Hi bala,

you can do both once change pointer created and IDoc is generated for that and you want to create IDoc again for that change that is also possible. And if you dont want once send change to go again that can also be done . AS i m using change pointer for my ZIDoc's

I m pretty sure this is possible.

[Former Member]

>

> Can we change this behaviour so that we can execute the change pointers again and again and generate idocs for same changes

Of course you can - that is what I was trying to explain last week - if you want to do this, you can use transaction PFAL every time ...

(assuming, you are still talking about HRMD_ABA?)

[Former Member]

Mylene,

We would like to use RBDMIDOC only for delta loads so can we create idocs again and again for change pointers.

We have a scenario where message type HRMD_A is used for two logical systems for two diff purposes.we are planning to create two jobs for RBDMIDOC because we want to send the data to two systems at different times.so when we execute the first job it will create idoc but when we run the second job will it trigger the idocs for the change pointers again

Thanks

Bala Duvvuri

[Former Member]

No, RBDMIDOC will make IDOCs out of change-pointers only once. After that run, they are 'used-up'. Same with RHALESMD.

Everything you want to do after that has to be run using PFAL.

[Former Member]

Mylene,

I dont have authorisations to execute RBDMIDOC.but i executed RHALESMD and i can execute change pointers again and again

Thanks

Bala Duvvuri

[Former Member]

As per my knowledge, you can not achieve your functionality unless if you implement new enhancement frame work enhancements (if you are on ECC) in std. sap FM/prog.!! I dont know whether Can i mention here a non-sap web site or not? if you search google you can find a tutorial about it.

thanq

[Former Member]

Bala,

One way you can work around the limitations of BD21 for your requirements, is to set the partner profiles of the HRMD_A idocs to be "Collect IDocs" instead of "Transfer Immediately". This was your idocs will be generated by the change pointers and remain in status 30 but they will not be sent out.

Then you can submit the idoc send job (RSEOUT00) for these partner profiles separately for HRMD_A.

I'm assuming that you dont have any overlaps of these documents.

Optionally, you can also set up multiple models and use different filters for them.

Salai.

[Former Member]

>

> Bala,
> 
> One way you can work around the limitations of BD21 for your requirements, is to set the partner profiles of the HRMD_A idocs to be "Collect IDocs" instead of "Transfer Immediately". This was your idocs will be generated by the change pointers and remain in status 30 but they will not be sent out.
> 
> Then you can submit the idoc send job (RSEOUT00) for these partner profiles separately for HRMD_A.
> 
> I'm assuming that you dont have any overlaps of these documents.
> 
> Optionally, you can also set up multiple models and use different filters for them. 
> 
> Salai.

Bala,

actually - this are two very nice ideas. OTOH, with your requirements, why not skip changepointers alltogether an use PFAL instead of everything? You could schedule it as a background job and run it separately for the different target systems ...

[Former Member]

Mylene,

PFAL is not working as expected.When i select reporting period as today and select update mode it is fetching all the records which are valid as of today not the records which are changed today so we would like to go for change pointers using RBDMIDOC or RHALESMD

Thanks

Bala Duvvuri

[Former Member]

Bala,

understood!!

So, coming back to Salai's advise ... how about that?

[Former Member]

Mylene,

I am going discuss that option with my client

Thanks

Bala Duvvuri

[Former Member]

Hi Bala,

It will check only current record. i.e. check the new entries from CDPOS & CDHDR tables as per your setting done in BD50, BD52, BD60 & BD61 tcodes.

Regards,

Narendra

[Former Member]

Hi Bala,

This in reply of your previous thread which you closed ie of two logical system

wat i have found is that when you debugg the FM associated to HRMD_A in BD60 you will get the entries of logical system in ITAB say DIST_MODEL[] . IF you enhance this FM removing unwanted logical system then may be you can send IDoc only to desired system..

[Former Member]

Hi,

Change pointers are saved in table BDCP2.  When you execute RBDMIDOC, the table is read and unprocessed records are selected for processing.  Once a record is processed, an "X" is put in field PROCESS.  on subsequent runs, since the field is marked processed, it will not be selected again.

You should run BD22 weekly or monthly to clear processed change pointers from the table.  If the table is allowed to build up too much, performance will be impacted.  Also Basis should monitor the table for records that are never processed and make a decision to either process them or turn off the change pointer.  BD22 will also delete these Obsolete change pointers.

[geshy_m]

Hello,

Looking to create change pointers to trigger an IDOC in ecc system for Purchase Orders created and sent from an external system. The purchase orders are transferred to ECC system through RFC.How can we trigger IDOC for PO's with change  pointers. Thanks.