SAP EWM

Designing an Efficient & Audit-Compliant Physical Inventory Strategy in SAP EWM

Designing a Physical Inventory (PI) process in SAP EWM for large, 24/7 warehouses requires balancing audit compliance, system performance, and operational continuity. A well-designed PI strategy should minimize business disruption while ensuring full traceability of inventory adjustments.

Below are best-practice design principles used in real SAP EWM projects.

🔹 1. Full PI vs Continuous PI (Cycle Counting) – Recommended Approach

✔ Avoid Pure Annual Full PI

• Annual full PI in large warehouses causes:

  • Operational downtime

  • Performance issues

  • Increased error rates

• Use full PI only for audit reconciliation or exception handling

✔ Prefer Continuous PI (Cycle Counting)

Recommended approach:

• Use cycle counting as the primary PI method

• Schedule small, frequent PI documents

• Count bins/products based on risk and movement frequency

👉 This approach satisfies auditors while keeping operations running.

🔹 2. Designing PI Areas & Counting Intervals

✔ Define PI Areas Strategically

Create PI areas based on:

• Storage type (high rack, picking, bulk, VAS)

• Operational criticality

• Access restrictions

Example:

• High-rack storage → Quarterly PI

• Picking areas → Monthly PI

• Fast-moving SKUs → More frequent counts

✔ Use ABC Classification

• A-class products → Frequent PI

• B-class products → Medium frequency

• C-class products → Annual or semi-annual PI

👉 This reduces workload and improves accuracy where it matters most.

🔹 3. Controlling & Documenting Inventory Differences (Audit Focus)

✔ Enforce Difference Reason Codes

• Mandatory reason codes for all PI differences

• Separate codes for:

  • Damage

  • Theft

  • Process error

  • System issue

👉 Auditors expect clear business justification for every difference.

✔ Block Automatic Posting of Differences

Best practice:

• Do not allow direct difference posting

• Route differences through:

  • Supervisor review

  • Approval workflow

This ensures:

• Accountability

• Reduced incorrect postings

🔹 4. Authorization & Approval Design for Audit Compliance

✔ Segregation of Duties (SoD)

Design roles such that:

• Counter ≠ Approver ≠ Poster

• No single user can:

  • Count

  • Approve

  • Post differences

👉 This is a key audit requirement.

✔ Use Change Logs & Application Logs

• Activate change documents

• Use application logs for:

  • PI creation

  • Difference posting

  • Recount triggers

This provides:

• Full traceability

• “Who changed what and when”

🔹 5. Performance Best Practices for Large PI Volumes

✔ Avoid Large PI Documents

• Do not create PI documents for thousands of bins at once

• Split PI documents by:

  • Storage type

  • Area

  • Product group

✔ Schedule PI Jobs During Low Activity

• Create and process PI documents during:

  • Night shifts

  • Low-volume windows

• Avoid peak outbound periods

✔ Monitor System Load

• Track PI-related queues and logs

• Monitor background job runtime

👉 This prevents performance degradation in productive systems.

🔹 6. Recommended End-to-End PI Design (Summary)

✔ Continuous PI as primary strategy
✔ Risk-based counting (ABC analysis)
✔ Mandatory difference reasons
✔ Supervisor approval before posting
✔ Strict role segregation
✔ Small, controlled PI documents
✔ Regular audit reporting

SAP EWM Warehouse Task Not Created After Inbound Delivery

When an inbound delivery is successfully distributed to SAP EWM but Warehouse Tasks (WTs) are not created, the issue is usually related to process configuration gaps or missing master data, even if everything appears correct at first glance.
Below is a systematic checklist based on real project experience.

🔍 1. Check Inbound Delivery Item Status

• Go to /SCWM/MON

• Navigate to the inbound delivery item

• Verify the status:

  • “Putaway Relevance” must be active

  • Delivery item must be released for warehouse processing

👉 If the delivery is not released, WT creation will not trigger.

🔍 2. Verify Warehouse Process Type (WPT)

Check whether the correct Warehouse Process Type is determined:

• Go to SPRO → EWM → Goods Receipt → Warehouse Task → Define Warehouse Process Type

• Ensure:

  • Putaway relevance is active

  • Correct stock removal/placement control is set

  • Confirmation control is not blocking WT creation

👉 Wrong or incomplete WPT is one of the most common causes.

🔍 3. Check Putaway Strategy & Storage Type Search

• Verify Putaway Strategy in:

  • Product master (warehouse view)

  • Storage type search sequence

• Ensure:

  • At least one storage type is found

  • Storage type allows putaway

  • No capacity or bin restriction blocks WT creation

👉 If no valid storage type/bin is found, WT will not be created.

🔍 4. Check Product Master Data

In /SCWM/MAT1, confirm:

• Putaway control indicator is maintained

• Storage section / storage type indicators are correct

• Handling Unit requirement matches the process

• Batch/SLED settings (if applicable) are consistent

👉 Missing or incorrect product master data often blocks task creation silently.

🔍 5. Check Warehouse Task Creation Settings

• Verify whether WT creation is:

  • Manual

  • Automatic

  • Triggered by PPF

• If PPF is used:

  • Check PPF action status

  • Ensure action is processed successfully

👉 If WT creation is set to manual, system will not create tasks automatically.

🔍 6. Check Queue & Warehouse Order Settings

• Ensure a valid queue is determined

• Check:

  • Queue assignment

  • Warehouse Order Creation Rules (WOCR)

• Incorrect queue determination may prevent WT processing.

🔍 7. Check Application Logs & Queues

Always check:

• SLG1 – Application logs for hidden errors

• SMQ1 / SMQ2 – qRFC queues for stuck messages

👉 Many WT creation issues are visible only in logs, not on the UI.

✅ Final Recommendation (Real Project Insight)

In most productive systems, WT not created after inbound delivery is caused by:

1. Incorrect or incomplete Warehouse Process Type

2. Missing putaway strategy or storage type

3. Product master data gaps

4. Delivery not released for warehouse processing

5. PPF or queue-related issues