APO->R3 cif queue blocked for planned orders

[Former Member]

Hello everyone

Does anyone have any input on the following?

We run a PP/DS setup in APO with capacity planning. We have resources in APO that we use for capacity management, one for lead time (shared by many products across product lines) and several capacity resources (work centers ciffed over) for managing the actual capacity.

Planned orders are created in APO via CTP during SD order entry as well as regular heuristic planning runs.

Now, it can happen that a planned order can’t be created at times. Perhaps we are missing a PDS, perhaps the material was deleted in R3 without complete cleanup, any number of issues can occur where we can’t create a planned order.

Similarly at times it is not possible to convert a planned order into a production order. Usually due to some sort of master data issue.

These issues of course cause CIF queue errors, and we then handle these. However sometimes it happens that tons of other LUWs get stuck behind LUWS with issues like described above. This means that one “bad” planned order can block tons of other stuff. We’ve had an entire days worth of planned orders/production order conversions get stuck due to this.

What we see is that a bunch of LUWs get stuck with status WAITING and waiting for one of the bad orders.

What we do not get is why this happens, what exactly controls if planned orders get stuck in the CIF? From our perspective we don’t really care if the bad orders don’t get to R3, that will be dealt with in time but it’s very bad if they can block all the other “good” orders.

Does anyone know anything what can block planned orders or production order conversions in the CIF when transmitting from APO to R3?

It’s not clear to me what determines what blocks the queue and what does not.

[Former Member · Accepted solution]

Simon,

If 'tons' of LUWs are being blocked by your SYSFAILs, it implies that you need to increase the frequency with which you review the queues. 

During mass processing in APO, the system may generate tens of thousands of planned orders.  In order to provide consistency, SAP core interface serializes all queues of similar type.  This means that the orders should be created/changed/deleted in the same sequence in the destination system as they were created/changed/deleted in the source system.  If you are not using postprocessing, then the system also creates 'blocks' of orders.  Each block is processed at one time.  A SYSFAIL of any member order in a block will cause the other members of the block to 'wait'.

So, the short answer to your question "... what exactly controls if planned orders get stuck in the CIF..." is "any failure in the block".  Default block size is 100 orders.  Block size may have been altered to a different value in your system. /SAPAPO/CP3

To avoid such problems, you have several choices.  You can decide to collect changes, and then publish planning results to ERP periodically instead of directly. /SAPAPO/C4

http://help.sap.com/saphelp_scm70/helpdata/EN/ab/4f6c39c71c0324e10000000a114084/frameset.htm

Or, you can decide to turn on Error Handling. /SAPAPO/C2

http://help.sap.com/saphelp_scm70/helpdata/EN/f4/85ece6da3ba745b595c194c52903f5/frameset.htm

Or, you can just monitor the queues more frequently.  For an established system, with well controlled master data, and direct publishing of planning, I generally reduce my monitoring to once a day.  For newer implementations, or systems with inconsistent master data, I will monitor more frequently, until the underlying problems have been managed.

Best Regards,

DB49

[Former Member · Accepted solution]

You're right DB, it is probably much more a question of having people work in a disciplined way with regards to master data than a system issue. Thanks for the explanation about the waiting queues.

[Former Member]

Hi Simon - It is a standard functionality of CIF not to send bad data to ECC, for example - if the planned order was created with a Production version which is not valid in ECC and hence you would experience queue blockages.

I am not too sure if you have tried enabling Post processing? Probably it is worth trying to implement/configure post processing so that blocked queeus can be moved and later you can process them?

This is only applies for Transactional data. Faulty queues no longer lead to queue blocks. Instead, they are logged in post processing records in the relevant target system for the data transfer. You can then call these post-processing records at a later time point in CIF Post-processing (transaction code /SAPAPO/CPP. Once the error has been corrected you can again send the objects to the relevant target system.

These below links might be helpful:

http://valconusa.com/uploads/Managing_SCM_APO_CIF_4x.pdf

http://help.sap.com/saphelp_scm50/helpdata/en/f4/85ece6da3ba745b595c194c52903f5/content.htm

http://help.sap.com/saphelp_scm41/helpdata/en/dd/511e41751af04990c8f49ec32cf602/content.htm

Thanks,

Murali

[Former Member]

We have in fact looked into postprocessing in the past but as i understood it it would only help for purely transactional issues?

The errors we get are almost always caused by bad or missing master data, would it help in those cases? It would indeed help if the error would be sort of put aside and the other records could be sent. Thank you for the input & links, it looks interesting.

[Former Member]

Hi Simon - For having clean CIF you should be have good master data and it is always a challenge.

If you are inclined towards custom development, I can suggest something which can help atleast avoid some bad data getting across to APO. For us it reduced 60 - 70% of our CIF errors with the below kind of development and also by enabling CIF post processing.

Before you decide to turn on a product to be planned in APO, create a custom Tcode to validate it has pre-requite master data.

Create a custom field on one of the MRP Views which needs to be activated before the product is sent across to APO. Also, enhance that field in CFM1 or RIMODGEN to have that field checked for all of your integration models.

In order to turn that field active, below is the logic you can try to implement,

For example, if a product is in-house manufactured, then it needs to have a valid production version. The logic should check if the product is in-house produced then it should validate if it has a valid production version and enable the custom field.

If externally procured, you can say to validate it has info record, Special procurement key or Source list, contracts etc etc to activate that field and similar kind of logic for 'X' materials.

Additionally, you can have Change pointers to the PV's to be run frequently atleast 3-4 times a day so that the changes made to Production versions get across to APO.

One more thing which I found useful was to use PPM Selection date " Resolution According to End Date of Production Version" which helps a lot to your PPM models, incase if you are using PPM's.

May be you can take some clues from the above and see if it helps.

Thanks,

Murali

[Former Member]

Those are some pretty good ideas, thanks.