cancel
Showing results for 
Search instead for 
Did you mean: 

PREQ REL

Former Member
0 Kudos

Hi,

Can any one please let me know why the PREQ REL elements cannot get CIFF'ed to R/3?

In this case, the PREQ REL's and also the PREQ's are not going to R/3 but the CONREL's are going to R/3

To meet the PREQ RELs requirement there is enough supply (it is pegged to PRDN and PLND orders)

Thanks,

SS

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

SS,

When you say that the PReqRel is not going to R/3, the supply situation usually has nothing to do with it. Are you getting any CIF errors? How about the CIF and ATP logs (SLG1)?

A common reason is that the Purchase req for STOs has not been properly configured in R/3. A high level test of this is that you should be able to manually create a stock transport Purchase req manually in R/3, and source it, without any errors or warnings. You should then be able to convert this manually in R/3 to a STO, again without errors or warnings.

Best Regards,

DB49

Former Member
0 Kudos

Hi DB49,

Thanks for the response.

we have run CCR and OM17 and have seen no errors. I wll check the logs and let you know.

In R/3, what settings do I have to check?

The PUR REQ of the source location is also no appearing in R/3 and we have run CCR for it also and no errors seen

Thanks,

SS

Former Member
0 Kudos

SS,

When you are working with STOs/STprs in APO, you FIRST must have performed all MM settings in R/3 for stock transport orders and stock transport purchase reqs. APO does not actually create the purchase req in R/3, it just sends a signal to R/3, and then R/3 creates the purchase requisition. The core interface then replicates the appropriate information back to APO. A failure to create usually generates an error message in one or more logs, or blocks a queue with an error message, and these messages will direct you to the specific problem.

When you tried to manually create a stock transport purchase req in R/3, as I instructed earlier, what were your findings? When you tried to convert your manual Stock Transport purch req to a sto in R/3, what were your findings?

Best Regards,

DB49

Former Member
0 Kudos

Hi DB49,

Thanks again for responding

Since this is a prdn system , I am not able to ask the user to do the PR to PO conversions and we do not have access to the quality/dev systems . So I am not able to update you on that

I have seen the material A for which the issue exists and is supposed to be supplied from PLANT 1 to PLANT 2

So PLANT 2 is the receiving location and the MAINTENANCE VIEW FOR DISTRIBUTIN DEFINITION of APO shows that the for PLANT 2, there is no EXTERNAL PROCUREMENT defined to update the data to corresponding R/3 system. Does it mean that since the Purchase requistions of the receiving location(PLANT 2) are not updating to R/3 system , the PREQ REL's of the source location (PLANT 1) will also not update to R/3

Can this be a reason why the PREQ REL's are not going to R/3 and also not getting captured in CCR

(In any business scenario , will there ever be a need to update the PREQ RELS's to R/3 from APO ???)

Thanks,

SS

Former Member
0 Kudos

SS,

Let's see. This is a production system, so no testing is permitted.

You can't access quality.

You can't access dev.

Bizarre. Just how did you expect you were going to fix this problem?

Actually, you can ask the users to perform testing. A Planning or Purchasing Key user could easily perform such tests, and all without disrupting any business critical data. When all is said and done, someone is going to have to test somewhere. Maybe that should be the first thing you solve. Who will be troubleshooting the problem to arrive at a solution. Right now, it seems like that won't be you. If you are a consultant, speak to your team lead about authorization. If you are an employee, speak to your supervisor, same subject.

Anyhow, your statement that the problem exists on a production system implies that configuration is not the problem (the functionality of such configuration would have been fully tested before going 'live', right?)

I have seen the material A for which the issue exists and is supposed to be supplied from PLANT 1 to PLANT 2

So PLANT 2 is the receiving location and the MAINTENANCE VIEW FOR DISTRIBUTION DEFINITION of APO shows that the for PLANT 2, there is no EXTERNAL PROCUREMENT defined to update the data to corresponding R/3 system. Does it mean that since the Purchase requisitions of the receiving location(PLANT 2) are not updating to R/3 system , the PREQ REL's of the source location (PLANT 1) will also not update to R/3

I believe you said that CONRELs were already working OK, yes? CONRELs use the same interface data channels (both to and from) as Purchase reqs.

(In any business scenario, will there ever be a need to update the PREQ RELS's to R/3 from APO ???)

Are you joking? That is the problem that started this conversation, isn't it?

If CONRELS are working OK, and if PREQRELs are not OK, and R/3 config is OK, then look for an enhancement that the client has installed that is interfering.

You still haven't said anything about the logs or queue errors. Are these also not available to you?

Best Regards,

DB49

Former Member
0 Kudos

Hi DB49,

The logs do not have any thing about the PREQRELS and queeues are clear

The CONRELS that have got updated have the source location as PLANT 1 and Target locatoin as PLANT 3

The troubling PREQRELS have source location as PLANT 1 and Target locatoin as PLANT 2 and for PLANT 2 , the EXTERNAL PROCUREMENT has not been defined in the DISTRIBUTION FUNCTION in SPRO. But for PLANT 1 the external procurement has been defined in the DISTRIBUTION FUNCTION in SPRO

I was asking the importance of PREQRELS about updating to R/3 in any business scenarion becasue in the DISTRIBUTION FUNCTION in SPRO and in CCR, I did not see any element like PREQREL (I have seen only PIR's, PR, PO, SO etc).So wanted to clarify on it

Thanks

SS

Former Member
0 Kudos

SS,

Ah. Your original statement

In this case, the PREQ REL's and also the PREQ's are not going to R/3 but the CONREL's are going to R/3

was a bit misleading.

So, in your case, logs would be clear. SCM has not even attempted to send these objects to R/3, so there is nothing to report. Likewise, it would not attempt to send CONRELS to R/3 for plant 2, you would eventually face the same problem for these objects as well for plant 2.

It seems you are unsure as to what these objects actually are doing. In SCM these objects are mapped to R/3 MRP elements in configuration. IMG > APO > GATP > General Settings > Maintain Category. 'Category Text' is the abbreviated category you will see in various screens, such as //rrp3. Scroll to the right, you will see more info, and the final columns show the mapped MRP element, which you are probably more familiar with. If you don't have access to spro, use se16 to browse the view /SAPAPO/V_ATP03.

So, for BH PReqRel, it is mapped to R/3 MRP element U2, which is described as a Purchase Requisition. If you look in R/3 config (OMD5), you will see that U2 is abbreviated in MD04/5 as PRqRel and PchReqRel, and described as "Release order for a stock transfer requisition". Your long text in both systems may differ somewhat, since the texts are modifiable by the customer.

By these facts, you can intuit that when you CCR in APO against "Purchase Requisitions", you will be including these objects. However, be aware that CCR only works properly when all Interfaces are established. In your case, Publishing is/was incomplete. You can't always rely on CCR to identify such problems.

Best Regards,

DB49

Former Member
0 Kudos

Hi DB49,

Sorry for the mislead

I have gone through the View and I understand the mapping

Now can I assume that the issue I have expressed is coming becasue of not defining EXTERNAL PROCUREMENT in DISTRIBUTION FUNCTION in PLANT 2 ??

In the logs, if there is some change to the PREQREL, then will it captured in the log as PREQ or PREQREL?

Thnaks,

SS

Former Member
0 Kudos

SS

Now can I assume that the issue I have expressed is coming becasue of not defining EXTERNAL PROCUREMENT in DISTRIBUTION FUNCTION in PLANT 2 ??

Absolutely. STOs = purchase orders; STPrs = purchase reqs. Both are considered 'External'. If you wish to publish these data back to R/3 (and you do) then you must create a distribution model.

And, just so you are not confused, for external, in publication, for STOs, 'Location no.' refers to destination plant.

Depending on how your logs are set up, you are not likely to see much info for a successful transfer. I don't recall the exact contents of an unsuccessful detailed PR transfer log, but most logs contain detail that mentions the function module, the product number, GUID, and the order/item number. Probably some other stuff....I don't think the word PREQREL actually ever appears in the log, but I could be wrong. Start by checking 'all logs'. If the list is too long, go for 'only important logs' or 'only very important logs'. If you see nothing, then logging is probably not turned on.

By the way, you might want to investigate how this publication entry was overlooked. Making all the required publication entries is normally part of the documented go-live procedure, and is typically assigned to a specific person or team.

Best Regards,

DB49

Former Member
0 Kudos

Thanks so much DB49

Your inputs were of a great help. I am closing the loop

Thanks,

SS

Answers (0)