Production order confirmation via custom design

[alex_alex85]

Hello,

We have custom program for Production orders confirmation. It uses BAPI_PRODORDCONF_CREATE_TT.
I think there is some known issue, when sometimes entries are stuck in CO1P due to posting in update mode. As advised, to avoid CO1P entries BAPI_GOODSMVT_CREATE can be used.
But unfortunately for us it is not an option.

>> The process we have:
1. Users confirm Production orders through custom tool
2. Background job for CORUPROC is run every 5 minutes

>> The problems we have:
1. Sometimes during confirmation users ignore the fact that Goods receipt did not happen. They see that nothing happened and post it one more time. Later CO1P is processed and we have situation, that Goods receipt were duplicated.
2. Sometimes when user is working with particular Production order and at the same time the job CORUPROC is processed using the same order. It leads to receiving entry in CO16N with error "User locks the order" which can be processed only manually.

>> So the question is how it is better to avoid the issues? If we can not re-design the program, probably we can add check giving to user the restricting message.
1. I'm not sure in which moment entries go to CO1P. Is it possible during confirmation to catch it and show to user the message, kind of: "Goods receipt is stuck in CO1P..." ?
2. If point 1 is possible, is it possible to distinguish CO1P entry from entries COGI and CO16N?
3. If it is not possible to catch CO1P entry during confirmation. Probably after confirmation, wait a few seconds and then check AFFW table and give the message if entries are found? But how to distinguish CO1P entry from entries COGI and CO16N?
4. Any other options or hints? Maybe I need to think in other direction.

Thanks.

[DominikTylczyn]

Hello @alex_alex85 

I think you are facing 3 different kinds of potential issues in your process:

1. Permanent or semi-permanent errors e.g. a user tries to post a confirmation for a non existing production order or for an order that is not released yet
2. Transient locking errors i.e. a user tries to post a confirmation for an order that is being processed and thus is locked
3. Material movements posting errors, i.e. COGI entries

In my opinion there is no silver bullet solution or "one ring to rule them all". So all look at them one by one.

Permanent or semi-permanent errors You can implement validations in your custom application to prevent this kind of errors. Also make sure to report messages coming back from BAPI_PRODORDCONF_CREATE_TT so a user know if confirmation has been posted or not. Also consider using TESTRUN parameter to quickly verify data provided to the BAPI.

A verification to consider is to check if a user tries to post the same confirmation i.e. for the same production order, for the same quantity, etc. multiple times within short time. That might indicate that they are posting duplicates.

Transient locking errors Here you can use POST_WRONG_ENTRIES parameter to decide if confirmations failed due to locking conflicts should be rejected or saved in the error pool for reprocessing with CO16N:

The approach would depend on the nature of your confirmation process. If you have a high volume process and want to allow parallel confirmation postings for the same production order, go with POST_WRONG_ENTRIES = 2 to save erroneous confirmations in the error pool. Notice however that this will save both confirmation with locking conflicts and with exceptions to the pool.

Material movements posting errors Due to its design BAPI_PRODORDCONF_CREATE_TT can post material movements synchronously in the same LUW together with confirmations. Therefore COGI entries are unavoidable in case of material movements posting errors. I think the best approach here is to educate users about that and teach them to verify confirmations in production orders, not material movements as they can still be waiting for reprocessing in COGI.

In any case, I think running CORUPROC every 5 minutes is too frequent. You are introducing more locking conflicts this way.

Last point, educate the users that if your application posts a confirmation successfully, they don't need to verify that and might not see the confirmation or material movements in the production order immediately. The confirmation might have been written to the error pool for latter processing. Of course a production admin has to monitor the error pool with CO16N and COGI.

Best regards

Dominik Tylczynski

[alex_alex85]

Hi Dominik, Thanks for the clarification.

Transient locking errors - this feature is already in use.

Material movements posting errors - we can consider this also.

Permanent or semi-permanent errors - there is a question. We can not reprodue CO1P entry for test purposes and can not check what we have in BAPI with CO1P. Is it known if the BAPI return something, which says that it is related to CO1P? Not to lock error, not to COGI etc. But particularly to CO1P. Or we are able to check whether the posting was done or not only after Confirmation was completed?