Difference in COGI and CO1P

I have been searching and reading all the documents regarding COGI and CO1P, to know why some goods movements are held in COGI, while some in CO1P. I would like to share my knowledge on where I started and ended in learning about these transactions. Hope this document will be final stop if you are also searching for this topic.

Have a look at this article to know the basics of this topic.

Let us consider that auto goods movement is setup for confirmations of production orders in the below scenarios.

Confirmation is saved but goods movements are failed?

To find out the reason for this we have to go to transaction code:

COGI – Postprocessing of Error Records from Automatic Goods Movements

As the name suggests, we can process failed goods movements from here after correcting the errors.

Give the order number and execute

For example, error here is due to deficit in stock of goods posted. Until stock is updated in the system this posting will be held in COGI, from where we can post the goods later.

Now after updating the stock open COGI again, select the required line items and click on save to post the goods. If the confirmation details have to be changed double click on the line item or select the line item and click on change details button, and then post the goods by clicking on save button.

How to configure system to stop the confirmation process, when error occurs in Goods Movements?

This can be configured under the IMG node “Define Confirmation Parameters”

This indicator specifies that if you save a confirmation with goods movement errors (that is, backflushing or automatic goods receipt), then the system displays an error log before saving.

Confirmation saved and no goods movements failed, still stock is not updated in production order?

In this case you may have to go to transaction code:

CO1P – Predefined Confirmation Process

As the name suggests, this is an already defined step in configuration to process all goods movements of that day at later point of time. For example, to improve system performance all goods movements of an hour can be held and processed through CO1P in one go. This is setup in decoupled confirmation settings.

Give the order number and execute

Select the required line items and click on save to post the goods.

What is decoupled confirmation? How can it be setup?

To avoid the issues with response time of confirmation process, we can decouple the steps taking place during confirmation. Following are the processes which can be decoupled

• Automatic Goods Receipt
• Backflush
• Actual cost determination

The execution time of above processes can be defined under IMG node “Define Time for Confirmation Processes”.

Which means above three tasks can be configured to be processed immediately at the time of confirmation itself or else later in background. This setup is known as decoupled confirmation.

This process control key can be maintained under the node “Confirmation Parameters” for required order type.

Then the goods movements related to this confirmation will be held in CO1P, until they are processed manually or by a background job.

When the option “Later in Background Job” is selected, system saves the confirmation data in below tables :

• AFRP1 – Auto GR confirmation records
• AFRP2 – Backflush confirmation records
• AFRP3 – Actual costs confirmation records

Stock is not updated against the order even after processing the entries from CO1P?

In this case you may have to look into COGI, if there are any further errors which are to be resolved.

Ex: Stock Deficit, Authorization issue, Production order status etc.

Why does system post entries sometimes into COGI and sometimes into CO1P?

So coming to the point, if there are any errors due to which system is not able to post the goods movements then such items are held in COGI. On the other hand stock postings will be held in CO1P when configuration is predefined as mentioned in above steps.

There is one exception for this, when load on system is huge and if locks occur during the time of confirmation no error record is generated in COGI, but instead a request is generated for a later update because the system assumes that the lock is only temporary. These requests can be found in CO1P.

What are the programs to run COGI, CO1P in background?

CORUPROC, CORUAFWP and CORUAFW0 are the reports which can be scheduled in background, to clear the postings that are held in COGI/CO1P at regular intervals.

But they have limitation when working with COGI entries, as these cannot be cleared until respective error is resolved. For example if the entry is due to stock deficit, then it cannot be cleared by these reports until stock is updated in system.

All these entries are stored in table AFFW. At the start of any of above programs, a global lock is set for all entries in table AFFW as well as a global process lock for goods issue and goods receipt. So it is advisable, not to run these reports in parallel as it may lead to job cancellations. So maintain some time gap while scheduling the jobs with different reports. Also we can differentiate the errors in table AFFW with error message numbers, if there is no error message number against a line item then it can be seen in CO1P.

What are CO16N and COFC used for?

CO16N – Postprocessing incorrect confirmations

This transaction deals with failed confirmations, whereas COGI/COPI deals with failed goods movement.

Confirmations with errors can arise if they were entered in one of the following ways:

• Upload from a PDC system (see Upload )
• Online entry ( Fast Entry or Mass Processing )
• Entry via BAPI interface

Errors might be like Order does not exist, Order was locked, Order already confirmed etc.

COFC – Postprocessing of confirmations with errors in calculation of actual costs

The errors in cost calculations during confirmations will be updated in the Transaction COFC. So this is not related to posting of goods movements we discussed above.