CO1P和AFFW表中有记录，前台COGI界面不显示

一、现象描述：

     生产订单报工后，物料没有反冲，用COGI事务代码进入后也查不到数据。经检查物料主数据、工艺路线等一些基础数据设置都是正常的。通过查后台表AFFW发现在表中是有数据。

二、原因分析：

Few things due which records are posted to CO1P are as below,

1. Object lock(Order being processed by another user).

2. Problem with data transfer from PP to HR module, when the workcenter is linked to SAP HR.

3. Error messages in goods movement, which does not have an excat message number description when it has to go to COGI.

4. If the confirmation process is set to update in background process(Program).

Generally we recommend to run program "CORUPROC"(CO1P) and "CORUAFWP"(For COGI) in background with defined frequency to automatically clear of simple Issues like object lock etc...

Hope this helps your understanding to resolve the Issue,

Regards,

Prasobh

原因由以下几种导致：

1、对象锁（订单正在处理另一个用户）。

2、从PP工作中心时，被链接到SAP HR的人力资源模块，数据传输问题。

3、错误消息。货物移动，没有一个excat消息数描述时，

4、如果确认过程中被设置为在后台进程（程序）进行更新。

三、解决方法  

针对单个订单使用“CORUPROC”（CO1P），不建议使用该方法

建议创建后台JOB运行CORUAFWP程序，每天晚上自动跑一次，之后所有的AFFW表中的数据都会显示到COGI前台界面中。

  

通常情况下，对PPO做GI或GR的时候，出现的异常可以在COGI中间被列出；在这些数据进入COGI之前，系统会把这些数据记录在CO1P中；换句话说，系统有时会出现DB的更新延时，当延时发生的时候，“错误”数据会先存在CO1P中，数十分钟或者数小时后，会自动进 入COGI。

Cause and Prerequisites
The problem is caused by technical settings in the system.
Solution
In Customizing of the confirmation for PM/PP/PP-PI/PS orders, you can
define a process control (Transaction OPKC). With it, the time of update
can be determined for the following processes each:
o automatic goods receipt
o backflushing
o actual costs
The following times can be assigned:
o immediately in the dialog mode
o immediately in the update program
o later in the background job

If automatic goods receipts or backflushings should be immediately posted
in the update program, sometimes it is possible that the goods movement is
not immediately updated during the confirmation but that only request
record are created.

This happens for the following technical reason: the posting of goods
movements in the update program is started from an online process. For
this, an update process is created in addition to an online process. The
update process runs independently of the online process. For example, the
dialog process can already be completed but the update process of the goods
movements still runs or has not started yet. It is not possible to send
messages, dialog boxes, or dialogs to the online process or have them
issued from the update process.

The following situations may occur when goods movement are updated in the
update program:
o Goods movement is successful
o Goods movement is not successful => error record (COGI)
o Lock situation => request record
In the case of a lock situation, an error record which can be reprocessed
with Transaction COGI is not created. However, a request record is created
instead. Such request records can be displayed with Transaction CO1P. It is
also possible to selectively update individual markings from the list of
markings.

可通过如下方法处理：
1、如果生产订单中出现“预定的实际成本”错误，则用CO1P进行处理，选中错误的行，保存，然后再去COFC中进行处理。
2、用COFC查询错误记录，选中错误记录-->保存.如果已经维护了作业价格，则系统自动读取该作业价格，如果未维护则无法保存 

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.

 

CO1P 是处理在订单确认时数据产生列队状态下进行手工将其列队前置 ,即由于系统慢，导致订单确认事业处理不能及时进行，用CO1P就让其强制系统优先处理该业务。
COGI是记录由于操作不当导致反冲物料不能实际过账的业务。进行手工修正后保存即可。

出现CO1P的原因是设置了分离反冲,可以有两种方法解决:
1、报工后，手工运行CO1P
2、每天设置后台JOB，运行CORUPROC
我以前的问题是后台作业运行后，仍然存在CO1P，所以我就设置了2次，问题就变相解决了

 

 

https://blog.csdn.net/weixin_38957344/article/details/81293867

【病情症状】

组件倒冲和/或自动收货的确认过账时，货物移动却只有部分更新或直接没有更新，然而，仅创建了请求记录。可以在配置中设置自动收货和/或立即更新程序过账的处理控制。

重要事项：以下事务，即使在配置（OPK4）中的处理控制设置了“立即联机”，货物移动通常会由于技术原因，在更新程序中过账。

1. CO13，CORS：截止4.6版本
2. CO12，CORR
3. 确认BAPIs：

      BAPI_PRODORDCONF_CANCEL

      BAPI_PRODORDCONF_CREATE_HDR

      BAPI_PRODORDCONF_CREATE_TE

      BAPI_PRODORDCONF_CREATE_TT

 

【病情起因】

该问题是系统的技术设置引起的。

 

【对症下药】

PM/PP/PP-PI/PS订单的确认配置中，可以定义处理控制（OPKC），该事务可以确定以下处理过程的更新时间：

1. 自动收货
2. 倒冲
3. 实际成本

可以分配以下的时间给上述处理过程：

1. 立即联机
2. 在后台工作
3. 立即在更新程序中

如果自动收货或倒冲应“立即在更新程序”中，不过有些时候，货物移动在确认期间并没有立即更新货物移动，而仅仅创建了请求记录。

出现上述情况的原因如下：更新程序中的货物移动过账是从联机过程即开始的，为此，除联机过程外，还会创建一个更新过程，并且，更新过程独立于联机过程运行。例如：联机过程已经完成，但货物移动的更新过程仍在运行或尚未开始，这时，无法向联机过程发送消息，对话框或对话，也无法从更新过程中发送消息，对话框或对话。更新程序中更新货物移动时，可能会出现以下情况：

1. 货物移动是成功的
2. 货物移动不成功=>错误记录（COGI）
3. 锁定情况=>请求记录

锁定情况下，系统不会在COGI创建可以重新处理的错误记录，而会在CO1P中创建请求记录。还可以从标记列表中，选择性地更新这些标记记录，建议定期计划更新这些记录工作。以下report可以运用与此：

1. CORUPROC：从4.0A版本（AFFW和AFRPx标记）
2. CORUAFWP：从3.1H版本（AFFW标记）
3. CORUAFW0：只有3.0/3.1版本（AFFW标记）

CORUPROC Report应从4.0版本开始使用。