SAP SD SUPORTE

segunda-feira, 28 de agosto de 2023

COGI and it’s cohesion with SAP EWM : PP-EWM-Integration

Purpose:

This blog is aimed at explaining how the consumption posting delivery for production supply can create erroneous goods movement record, which technically called as COGI( Controlling Goods Issue) in SAP PP which itself is a transaction code as well.

Explanation and its Integration to SAP EWM:

COGI entries are created when manufacturing order which are marked as ‘‘Backflushed items” in master data( Material master, BOM, routing or settings in confirmation parameter) are unprocessed during manufacturing order confirmation and failed goods movement create an additional record which calls for COGI clearance.

EWM-PP-Integration storage location from which Consumption is posted is EWM managed

In EWM-PP-Interface, ERP system generate a consumption posting delivery when backflushing while confirming the manufacturing order. This consumption posting delivery is distributed to the EWM system. The outbound delivery order in the EWM system is not relevant for picking. The system posts goods issue immediately upon creating the outbound delivery order.

However, due to insufficient stock at PSA or missing batch, system creates a COGI entries. There may be various reasons as well which I will not disucss here as there many available documents are present in SAP community.

This blog will primarily focus how to set up COGi entries when storage location in question is EWM managed.

Staging of Orders and why COGI entries from PSA.

It is very important to understand why components once staged to PSA, still incorrect COGI is created despite stocks from Warehouse to PSA for the manufacturing order.

For pick parts in SAP ERP(Material staging indicator=1 in Control Cycle), system creates a separate outbound delivery item for each manufacturing order. In SAP EWM, this item has a reference to the manufacturing order. There is a reference between manufacturing order in ERP and warehouse task in EWM and it can be used for printing as well.

Once the warehouse task confirmation is done, the stock is not reserved for this order. Stock can be used it for any manufacturing order. That’s the 1 core reason of shortfall of quantity which creates an entry in COGI.

–> If business has a requirement of stock reservation for each staging items, they have to use Advance production Integration using staging of components by PMR( Production Material request).

Single-order staging(Pick parts) can be utilized to create warehouse tasks for each PMR separately. After the warehouse task confirmation, the stock is reserved for this PMR item. If business wants to use the stock for another manufacturing order,stock needs to be released.

We will not discuss the Advanced production Integration in detail as this will be part of latter blog series, only delivery based production this time.

Replications Steps:

Create an order and do WM staging.The storage location is EWM managed.

Check the delivery created after production order release in VL06O.

- Check the delivery created my manufacturing order.

Once staging outbound delivery is created, it is distributed to EWM and WT is created based on PPF settings.

–-> It is necessary to have PSA Bin assignment entries in /SCWM/PSASTAGE – Assign Bin to PSA/Product/Entitled for trigger staging of pick part items in EWM

So, after WT confirmation, products will be staged to PSA 1001006 as below.

Check the stock in PSA 1001006.
I have moved stock of material to 101155563 to some other PSA to create COGI entries

Confirm the production order CO11N. save the confirmation.

Check the Production order Goods movement tab. Only, 1 item is consumed.

Check COGI. Faulty goods is marked as Goods movement posting failed in SAP EWM.

Check the consumption posting delivery in /SCWM/PRDO

Delivery is created for 2 items, one item is posted with ZERO quantity and GI status is comped. One is GI posted successful.

The settings for consumption delivery OPC to trigger COGI is derived from Adjust Quantity. If system is unable to find the sufficient stock in PSA, it post zero quantity in delivery and update delivery status as completed.

Go to COGI, and correct the manufacturing order quantity as per available PSA quantity and push the COGI

Check the new entries created in /SCWM/PRDO.

–>The faulty component has been successfully posted with creation of additional delivery document in header.

Check the documented goods movement in Production order.

Both items have been posted now and COGI is cleared.

Issue faced in Batch managed items and Vendor Consignment

For a production order, you have batch managed material components which are backflushed items. It may happen that during manufacturing order confirmation, a consumption delivery is created for the backflushed components with EWM storage location. If there is no batch determined for these components in ERP, components are still included in consumption posting delivery. These components are processed not correctly as ”Zero Quantity of component is posted with delivery status as Completed and no COGI entries are created. COGI entries are blocked due to batch not determined.

Some components are in Vendor Consignment stock and some are in own stock in SAP- PP-EWM Integration. Requirement is that during production order confirmation,vendor consignment stock should be consumed with Stock determination functionality. If there is no consignment stock, own stock should be consumed. However, problems arise when even there is no stock in both the above categories, still a consumption delivery is created in ERP and queue is stuck in EWM.

Solution: SAP Consulting note 1947584 -( Backflush confirmation is sending items to EWM incorrectly) recommends for using an Implicit enhancement to create COGI entries. Implicit enhancement should be done at the end of Method IMSEG_TO_KOMDLGN_MAP using class /SPE/CL_EWM_MAN_SERVICES

With this modification, the consumption delivery is created without batch manged items and COGI entries are created for those items which are batch managed whose batch determination doesn’t happen in ERP.

For consignment stock, after implementation of this code, COGI entries will be created for no stock items as well.

Hence the COGI PP-EWM-integration topic ends here. I will wait for your comments and improvements to make this blog more productive.

SAP KBA 2353305-Partial Goods Issue posting fails for consumption Goods in EWM

Best regards

Shailesh Mishra

Source: https://blogs.sap.com/2019/06/03/cogi-and-its-cohesion-with-sap-ewm-pp-ewm-integration/

SAP EWM pack nested HU /Pack nested content

There are scenarios during outbound where the Source HU is picked from the warehouse and put it in Pick HU. These Pick HU’s are the load HU that is used to carry the product/source HU from pick location and bring up to packing stations to Pack the product in Shipping HU.

In some scenarios only the Source HU is packed into Ship HU whereas the pick HU has only role to transfer the product/Pick HU to destination location and gets deleted, in other scenarios, only the content of Source HU is packed in to Ship HU whereas the Source HU and Pick HU is deleted.

In SAP EWM we have options to pick and pack the product under different scenarios like: –

Pick HU/Load HU is consider as Destination HU packed in Ship HU.
Only the source HU content will be packed under Destination/Ship HU
Source HU will be packed under Destination /Ship HU and Pick/Load carrier will be deleted.

In this blog we will discuss only on point -3.

The nested HU and nested content can be achieved using “Control for Pick HU concept”.

The control for Pick HU can be configured at Warehouse process type level or at storage type level. In storage type level we have an option where the warehouse process type settings (for Control HU) will be given preference over storage type. Activating the control Pick HU at WPT level is more flexible and more process oriented as compared to configuring at storage type level and make system more location dependent.

Storage type level

Warehouse process level

Scenario

Now for scenario where the Source HU will be packed under Destination /Ship HU and Pick/Load carrier will be deleted. We will be using option as ‘BLANK.”

So, we have a source HU picked from the warehouse and while confirming we place the Source HU in to PICKHU.

Source HU

Pick HU created # while confirming the picking task.

PICK HU #

Source HU packed under Pick HU as Nested.

Now move the Pick HU to Packing station and pack the Source HU in to Shipping HU.

800000132 – SHIP HU created

Pack Source HU to Ship HU by drag drop from Pick HU to Ship HU.

On save the Pick HU will get deleted and only the source HU will be packed as Nested under Ship HU.

Blog By – Nithin Kumar (SCM-CLOUDBOOK)

Source: https://cloudbook.co.in/blog/ewm-pack-nested-hu-pack-nested-content/

Understanding license type Basic vs Advanced for SAP Extended Warehouse Management

Introduction

In this blog post I will bring your attention for a very common question raised by customers and about the features available on SAP Extended Warehouse Management for license type Basic and Advanced. It means, understand the difference between each license type in order to be able to maximize all the features for the solution designed.

During the life cycle project implementation, when closing the Explore phase or more lately at the beginning of Realize phase, customers and/or partners realized there is a potential impact on the solution designed depending on the license type available for SAP Extended Warehouse Management.

Let’s straight to the point and understand which features are part of the Basic License type in which are not. And how this information is relevant for customer to be license compliance and be able to use the all needed features for the warehouse system

Basic x Advanced License Type

Before explain the features available for license type, let’s recap and understand the deployment model for SAP Extended Warehouse Management. The solution can be deployed as Embedded or Decentral. In both case for On Premise or running SAP S/4HANA Cloud, private Edition.

Embedded deployment means, run SAP Extended Warehouse Management on the same client of SAP S/4HANA, which is possible since SAP S/4HANA 1610. On the other hand, Decentralized deployment means roughly, run SAP Extended Warehouse Management in a different system of SAP S/4HANA but totally integrated with the core solution for Master data and Transactional Data.

I encourage you to check the latest SAP Note S/4HANA 2022 version SAP note 3218648 – SAP S/4HANA 2022 FPS00 and FPS01: Release information and restrictions for EWM in SAP S/4HANA, where you can find detailed information of all features and limitation available for each SAP EWM deployment type.

The license type differentiation for Basic or Advanced is only applicable for embedded deployment cases.. The Decentral deployment always requires the advanced license type, it means, all the features available on product can be used by customer without any risk on being noncompliance. You can also find the definition of extended features which trigger to need for the EWM license in case of embedded EWM on SAP S/4HANA Feature Scope Description on chapter “SAP S/4HANA LOB functions”.

From the solution perspective it is documented on the following IMG Customizing path: Extended Warehouse Management / Master Data / Acknowledge Use of Advanced Functions.

Features included in each license type

Once customers understand that, the License type is only relevant for Embedded deployment model, questions may arise such as “What features are included on basic license type?”

For Basic license type, customers are able to perform the main process end to end such as, Inbound, Outbound, Production Integration, Quality management integration, etc. Below you can find all the process included on basic license:

Inventory Management
Inbound Processing
Outbound Processing
Internal Warehouse Movements
Physical Inventory
Reporting (Warehouse Management Monitor, Analytics)
Resource Management
Quality Management
Production Integration
Integration with Transportation Management (ASR)
IDOC Integration to third-party MFS systems (SAP Note 2873423)

The advanced license might be required in case of customer would use some features enclosed of the main process, for example, the outbound process designed is required to use Wave management or, the production integration is required to use JIT – Just in Time. It means that the Advanced license type is required in case of use some specific SAP EWM features, such as:

Material Flow System (MFS)
Wave Management
Transportation units
Yard Management
Labor Management
Cross Docking
Value Added Services (VAS)
Warehouse Billing
Kitting
Dock Appointment Scheduling (DAS)
Slotting
Cartonization planning
Distribution Equipment
JIT
WIP Tracking
Warehouse Zones for advanced interleaving

License Management

The list of the extended objects for SAP EWM embedded is technically found on table /SCWM/EXT_OBJ. SAP Product Solution Team provide 2 reports for customers perform in their system in order to know which objects is being used on their warehouse system with usage detail

Report /SCWM/RP_COMPLIANCE_CHECK is available since S/4HANA 2016 (and higher) and provides the information if the customizing or the licensing is compliance or non-compliance for each warehouse system.
Report /SCWM/RP_LICENCE_SELF_AUDIT is available since S/4HANA 2022 (and higher) and provides by warehouse number a view by month of usage of Basic and Advanced features by total number of items per month, number of average items per day and active working days, compliance or non-compliance from the customizing perspective

Conclusion

Customers should be aware about the license type available on their solution and which features are enclosed on the license type. Also, be able to run audit reports which detail the usage of the features and how compliance customer is running the solution

Thanks,

Brought to you by the SAP S/4HANA RIG team.

Source: https://blogs.sap.com/2023/08/20/understanding-license-type-basic-vs-advanced-for-sap-extended-warehouse-management/

PHYSICAL INVENTORY in Embedded EWM

PURPOSE :

In this blog i would like to explain the process of Physical Inventory and its basic function .We will also discuss the configuration to be done for carrying out PI process.

PHYSICAL INVENTORY

Physical Inventory is a process to count the actual shop floor quantity and compare with book entry quantity.
This process may plan for year wise, continuous or product specific with pre-defined time periods.
Physical Inventory process can be carried out for Un-restricted stock type, Quality stock, blocked stock.
Physical Inventory Process can be carried out using two ways :-

PRODUCT SPECIFIC PROCESS:-

This means wherever the product lies, it is applicable for physical count.

STORAGE BIN SPECIFIC PROCESS:-

This means whatever the product in the storage bins; it is applicable for physical count.

NOTE:

Physical Inventory Area and Activity Area will be in 1:1 ratio.

CONFIGURATION :-

DEFINE PHYSICAL INVENTORY AREA:-

PATH: Spro—Img—SCM EWM—EWM—Internal warehouse processes —physical Inventory—physical Inventory Area specific settings—Define physical Inventory Area.

Here we need to create separate physical Inventory area for separate Activity area. As PIA: AA is to be done in 1:1 ratio.
Here select the IOWH-RK01 row and click on Permitted Documents
Here we assign the product specific and storage bin specific procedures in terms of permitted document types.
Similarly create separate PIA for every Activity Area. Below is the attached document for your reference.

PHYSICAL INVENTORY AREA CONTROL PARAMETERS:

Putaway physical Inventory:

PI document generates at the time of first putaway in to a storage bin during fiscal year.

Low stock check without Physical Inventory:

We check this Bar, then system will check the minimum value we maintain and if it’s below minimum value system will propose for PI.

Low stock check without physical Inventory:

This Indicator is for alerting low stock check during fiscal year without creating a PI document.

Posting after Count Entry:

This check box is for posting the PI document automatically after count with reference to assigned tolerance group, if the difference is below tolerance group system posts PI document automatically.

Display Book quantity:

Here system displays the Inventory book qty, when the count results are entered. The display of the book Inventory qty enables to check the count quantity entered.

Display item Object:

Indicates that object information is to be displayed as suggested (default) lines when a count result is entered for a location-specific (for example, storage- bin-specific) physical inventory.

Ex- HU 1 is storage at storage bin 01-01-01. HU 2 and HU 3 are packed in HU 1. HUs 2 and 3 each contain the product 4711.

Stock overview:

Storage bin 01-01-01 —> HU 1

HU 1 —-> HU 2

HU 2 —-> Product 4711

HU 1 —-> HU 3

HU 3 —-> Product 4711

HU complete:

If you set this indicator, a handling unit can be counted as “complete” at the time of count entry. That is to say, a counter accepts the complete hierarchy of a handling unit without counting any other HUs it might contain or all the products packed in the handling unit.

HU Counting method:

It specifies whether counter want to count collectively the number of handling unit (HU) or the no of items inside a handling unit

PERIODICITY OF STORAGE BIN CHECK:-

PATH: Spro—Img—SCM EWM—EWM—Internal warehouse processes —physical Inventory—physical Inventory Area specific settings—Define physical Inventory Area—Periodicity of storage bin check.

ASSIGN PHYSICAL INVENTORY AREA TO ACTIVITY AREA:

PATH: Spro—Img—SCM EWM—EWM—Internal warehouse processes —physical Inventory—Warehouse number specific settings—Assign Physical Inventory Area to Activity Area.

Here Assign the Activity area to physical Inventory Area.

DEFINE NUMBER RANGE FOR PHYSICAL INVENTORY DOCUMENT:

Physical Inventory document number ranges are year specific. If maintain year “9999”, then no need to maintain during year ending activities.

PATH: Spro—Img—SCM EWM—EWM—Internal warehouse processes —physical Inventory—Warehouse number specific settings—Define Number ranges for Physical Inventory documents.

SPECIFY PHYSICAL INVENTORY SPECIFIC SETTINGS IN THE WAREHOUSE:

In this area we maintain WH control parameters for each Warehouse.

PATH: Spro—Img—SCM EWM—EWM—Internal warehouse processes —physical Inventory—Warehouse number specific settings—Specify physical Inventory specific settings in the Warehouse.

DEFINE TOLERANCE GROUP FOR DIFFERENCE ANALYZER:

PATH: Spro—Img—SCM EWM—EWM—Internal warehouse processes —physical Inventory—Warehouse number specific settings—Define Tolerance Group for difference Analyzer.

DEFINE TOLERANCE GROUP FOR POSTING DIFFERENCE:

PATH: Spro—Img—SCM EWM—EWM—Internal warehouse processes —physical Inventory—Warehouse number specific settings—Define Tolerance Group for Posting Difference.

DEFINE TOLERANCE GROUP FOR RECOUNTING:

Here you define physical inventory tolerance groups for the recount of a physical inventory document in a warehouse number, and assign value-based and quantity-based (percentage) tolerance values to these activities.
If the difference exceeds tolerance limit, system automatically propose to recount. Result of recounting is to create a new PI document with deleting existing document.

PATH: Spro—Img—SCM EWM—EWM—Internal warehouse processes —physical Inventory—Warehouse number specific settings—Define Tolerance Group for Re-counting