PP COGI and SMQ2

0. SAP Process Overview – Error lists

Complex operational processes has driven SAP to high-end software to manage those. Errors are normal but the reason for them can be quite complex. Error solving is a must so SAP, especially MRP works in order. There are three major error list (SMQ1/ SMQ2/ COGI) which trained staff should solve on a daily basis.

1. Primary demand from the customers will be mainly created via ERP-SD-elements Customer Order and Scheduling Agreements
2. The Material Requirement Planning (MRP) runs centrally in ERP-MM where SAP-Replenishment Elements like Purchase Requisitions or Planned Orders are created. Formula: Demand ./. Stock = SAP-Replenishment Elements. It is crucial that consumption in step 7 being done à stock being reduced.
3. Production Planning is done in ERP-PP (Inhouse Production). Planned orders (PLAUF) being switched to Production Orders (FAUF). Basis are Bill of Material (BoM), Routing and Working Center.
4. Intercable uses as a Non-SAP Manufacturing Excecution System (MES) from company ProSeS.
5. ProSes transfers the confirmations of each operation per Production Order (FAUF) to the SAP System. The monitoring of this interface being done via SMQ1.
6. Most components being consumed via backflush while confirmations being send. Three major criteria must be fulfilled so backflush work properly: Correct Supply Area, enough stock and correct batch. If such a criteria is not correct or not on time an error being created in COGI list and manual processing is necessary.
7. Material handling as well supply operation to Supply Area is done via SAP-EWM. EWM is the leading stock system which is not directly integrated in ERP. The synchrony of EWM and ERP stock must be monitored via SMQ2. Only the ok EWM movements which being transferred to ERP reduce the stock in ERP. Asynchronous stock lead to a wrong MRP and can cause run-out items.

1. Processing of Error Records from backflushing (GER Nachbearbeitung von Fehlersätzen aus retrograde Warenbewegungen) COGI

The process Backflush offers a good automatic consumption of components/ stock. Next step the MRP considers the reduced stock and creates new demand. On the other hand it can be risky if the Backflush fails but physically components being consumed. The stock still exist in the system hence MRP will not create new demand. Risk of out-of-stock items are given.

The processing of Error Records COGI should be cleared daily.

Then you receive the current list with errors:

When you double-click on each line you access the goods movement detail list with adaption fields:

On 05.01.2021 the FAUF 1046626 wanted to backflush 70 pcs. of component 305369 with batch (GER Charge) 1000043961 on Supply Area (GER Produktionsversorgungsbereich PVB) C0M-001!

Here are some reasons why it failed:

• FAUF confirmation/ backflush occured earlier than EWM movement to Supply Area C0M-001 be done
• Component 305369 being delivered but with wrong Batch
• Component 305369 being delivered but to wrong Supply Area (PVB)
• Component 305369 being delivered but systemwise the stock was less than required 70 pcs.

In our example we have 12.02.2021 so many weeks already passed so to detect the failure is difficult:

• Check Physical Stock /SCWM/MON (material and Batch): Result no stock
• Check FAUF 1046626 if component list ok. 8.280 PCs. being delivered:

• Check component –> 8.280 pcs. of component 305369 should be backflushed
• Check documented movements. It is important that no storno (movement type 262 exists, otherwise calculate manually). The deviation is only 6 pcs and you can see that already the 70 psc have been backflushed. Therefore the a.m. COGI can be deleted. It seems the confirmation out out MES were sent twice:

Be careful to delete COGI lines but if so proceed as shown:

Only well trained staff should proceed COGI. Some more details can be retrieved from attached file in German:

2. qRFC Monitor EWM –> ERP (SMQ2)

EWM is a kind of satellite module with ERP. The leading operations concerning stock and material handling being done in EWM. On the other hand the whole MRP inclusive ERP stock being done in ERP. An online interface between EWM and ERP keeps stock data permanent in sync. Errors can occur and so the stock between EWM and ERP can differ which leads to an incorrect MRP with a risk for a out-of-stock item. Hence the SMQ2 being developed to work thru the errors and bring both systems in sync again.

Access via direct SAP transaction SMQ2:

Double-Click on one item:

Double-Click again to see error code:

Access via EWM transaction (/SCWM/MON) and Excel download for better overview:

The SMQ2 interface permantely tries to process the queues. So when error setting being done the queue automatically disappears. On the other hand new queues can occur from the previous one.

For SMQ2 error solving certain Expertise is necessary. Some examples in German can retrieved from following files:

Sometimes even Debugging might be necessary: