Program execution during RIMODAC2..will it always reach to cif user exit

[Former Member]

Hello ,

We are implementing cif user exit for Purchase Order at R3 side to capture additional date field. So logic to capture additional date field is put in user exit CIFPUR01. We have RIMODAC2 background job for Purchase order running on daily basis.

if there is no change in standard Purchase Order objects. When RIMODAC2 is executed for purchase order Integration models ..will program execution still always reach to R3 user exit part of the program irrespective of if any change in standard purchase order object has happened or not.

Will appreciate your answer.

Thank you

Best Regards

Nilesh Patil

[Former Member · Accepted solution]

Nilesh,

RIMODAC2 activates the IM. It typically has very little to do with any userexits that modify the data transfer itself. Since all userexits are locally built by your company, it is impossible for us to predict what will happen.

Of course, you will find out exactly how it works when you implement the userexit in your test environment.

Best Regards,

DB49

[Former Member]

Thank you Loknath and Will....

I regret for delay in reply...was stuck into some other issues.

Thank you

Nilesh

[Former Member]

Hi Will,

Thanks for your perspective..Business guys also keep creating new artciles ( materials) in R3 very often as its Reatil Scenario and RIMODAC 2 captures that delta and send it across. So almost every alternate day new articles are created in R3 and RIMODAc2 does get scope to send that delta. But on the day when there is no new article creation in R3...it should not do anything as far as sending data is concerned.

I searched this forum and many a times questions are asked about how to trigger CIF for custom field.But I have not seen any answer so far....If you or anyone has any idea then please share.

Thank you

Nilesh

[wilian_segatto]

Hi Nilesh!

OK, now I understood your requirement a little better...

If you are transferring materials, the following behavior applies:

a) BTE Immediate transfer for Material Master is on: changes in materials are transferred immediately to APO. New materials will be included in the next execution of RIMODGEN/RIMODAC2. Change Pointers are also taken into account in the RIMODAC2 execution.

b) ALE Change Pointers are on: changes are not transferred automatically. RIMODGEN/RIMODAC2 is the only way of transferring changes. Change pointers are marked as processed.

c) No change transfer. RIMODINI should be triggered to get the systems in sync.

These settings should be maintained at /CFC9.

What you can do is to have this setting for Material Master at ALE Change Pointers. Then you should use transactions /BD50 and /BD52 to register the custom fields that will trigger the creation of change pointers.

Then on the next RIMODGEN/RIMODAC2 execution the changed and new objects will be set to APO.

Will

[Former Member]

Hello Nilesh,

May be not an expert advice. here is something you could try

I understand this date/event/field that is changing elsewhere in ECC needs to be CIFd through some standard req/rcpt document to APO, to do something in APO ! or may be not. Using RIMODAC2 always. Well for documents this model is always active so lets try to make best possible use of such a design.

This is what I can think of.

1. Copy the field changing elsewhere to an freely available-if domain matches or new z field field in document table..header or item wherever relevant (of the document you are concerned to update APO)

2. Block the outbound Q in ECC and check what internal tables are being carried by the Q.

3. See if the value is passed through one or more of these internal Q tables. In alll likelihood it doesnt as it carries only required standard info to APO in standard. If not you can code this in ECC CIF outbound user exit so that one or more relevant internal tables carries this field to APO. Keep trying until you get this through the internal tables.

4.Now Block the Q in APO inbound and see if the value is coming through

5.Now decide where in APO you want to store this date and what you want to influence in APO. e,g if you want to change a requiremnt/recpt date of the document or convert a document into delivery based on a threshold or trigger something else to ECC or APO or a workflow etc.

Typically you would do such a thing to change requirement/receipt valuation dates in APO based on some updates to ECC documents or events or workflow status or some indicator. The standard practice would be schedule the documents some how (using the field you mentioned as condition key within condition techniques in ECC or APO or even with static hard coding) to schedule the document. What then goes to APO should serve the purpose e.g. expedite, delay of valuation date. e.g. delivery date, material availability date. This approach should keep reconciliation and reorganization reports also in sync.

Regards,

Loknath

[Former Member]

Hi DB,

Thanks for your reply and noted your points for roles of functional/ technical people and also other suggestions.

The field that's being transferred is not a part of standard PO. That field resides in some other table (TXPDAT.). We have put logic to capture latest value of that field in user exit and then send it to APO. Problem is that change in this field does not trigger CIF. take a case.... someone change that field value in R3 and after this there are no changes in Purchase Order Object in R3 ...CIF will not get triggered ...user exit will not capture changed value of that field and the change will not flow to APO.

In a day time...whenever PO is changed, on realtime basis that change in PO will be CIFFed across and at all those instances changes in field will be picked by user exit.....but any change in that field done after change in standard PO will not go across to APO...We are finding ways to trigger CIF for change in that extra field.....Out of 100 cases such cases will be say 10 per day

I was thinking if we run RIMODAC2 ....there should be some condition in program which checks if change has happened in standard PO object....if yes then only capture that change(delta) ...but i was checking possibility that if there is no change then also if it goes and execute user exit ...in user exit we have put logic to capture changed field and then forcibly trigger CIF

I am looking for ways to the points as underlined or any other way to trigger cif for custom field. I have tried to explain the scenario. Not sure if message is clear.

Thanks

[Former Member]

Nilesh,

Your requirement is clear. You want to CIF across some type of 'expedite' data as transactional data. SAP does not have a standard integration model for expedites. I speculate that SAP did not provide this functionality as 'standard' because expedites are typically irrelevant for a planning system. Now, your client wants you to torture the Purchase order Integration model into performing this task. One wonders why this bit of info is so important to have resident in APO, but I will assume that the client has already balanced the business benefit with the cost.

Let me begin by saying that I do not provide advice about enhancement implementations in these forums. My personal opinion is that most of them are not nearly worth the cost and effort to implement and maintain. I do not encourage enhancements.

My opinion is not shared widely.

You might want to also consider opening your viewpoint a bit, to something more like 'what is the best way to get the data from ERP to SCM'. There are many methods of moving data.

I reiterate that these details are the purview of the assigned Technical staff. If they are not up to the task, the client should consider engaging a technical consultant with abilities that match his needs.

Or, maybe one of the other forum members will save him some rupees, by adding their own insights.

Best Regards & Good luck,

DB49

[wilian_segatto]

Hi Nilesh!

I would recommend that you check the available user exits and enhancements in the /SPRO transaction of your

SCM system.

The activation of the IM via RIMODAC2 will not be useful for your transactional data (orders). Orders will flow to APO directly without any RIMODAC2 execution. So I believe you should implement your coding in the SCM Inbound.

Will

[Former Member]

Thanks you for your reply DB.

I asked this quetsion with understanding that any CIF user exit once implemented for a particluar object comes in picture once we try to CIF that object across by any CIF related programs..So during CIFFing data for that object ( say Purchase Order) it definitely hits user exit and catches logic in user exit. I am working at clients end and their ABAPers are not experienced in APO , so they are finding it difficult to find this logic in CIF program.

Your further comments are welcome. If anyone has teh answer, please share. I will appreciate your feedback.

Thank you

Best Regards

Nilesh Patil

[Former Member]

Nilesh,

I am no longer sure I understand the question.

RIMODAC2 activates the model. Once a model is activated, if someone changes certain specific fields in an R/3 object, then these changes are sent to SCM, either immediately or via change pointers. All this happens irrespective of IM userexits.

If this same field in this same object is changed in R/3, and a userexit also has been implemented, the userexit will execute according to its design, performing whatever task it has been programmed to do.

If you create and implement a userexit, it begins working at that moment in time that it is installed. Data that flowed across 'yesterday' to SCM is not affected. Data that flows across 'tomorrow' will be affected. Data in R/3 will usually only flow across to SCM if there is some kind of triggering event, usually a database 'change' transaction (e.g., ME22N for POs) The mere act of installing a userexit will not generally affect existing data on either side. The userexit only affects data that flows across the IM. Unchanged records in the R/3 database will generally not be sent to SCM by the IM, and will not be subject to userexit processing.

It is not generally the responsibility of a functional consultant to explain the workings of a userexit to a technical consultant. It is enough that the functional identifies the userexit, and specifies the business requirement in as much detail as possible. The developer is then responsible for carrying out the coding. Technicals are generally expected to be competent enough to determine from the userexit docs, and from the surrounding code, how a userexit works. They can also raise a message to SAP. In the end, it is all just ABAP, although userexit implementations can be quite challenging. SAP seldom provides enough details in their documentation. Once the Technical has finalized the code, Functional and Technical together then perform unit testing, before passing the mods to users for integration testing.

If your client's coders are unable to manage the task, perhaps they should engage your company to provide technical expertise, as well as functional expertise.

Best Regards,

DB49