Delivery Not Distributed to EWM After Creation in S/4HANA – Troubleshooting Guide

When an outbound delivery is created in ERP (VL01N/VL02N) but is not visible in EWM (/SCWM/PRDO), the issue is almost always related to integration trigger failure between ERP and EWM.

Since:

• Delivery exists in VL03N

• No short dump

• No visible queue error

• Integration worked earlier

This indicates the issue is likely related to distribution determination or message processing.

Let’s troubleshoot systematically.

---

1️⃣ Understand the Distribution Logic

In Embedded EWM:

1. Outbound Delivery is created in ERP

2. System determines warehouse number

3. Delivery relevance for EWM is checked

4. Delivery message is sent via qRFC

5. EWM creates Outbound Delivery Order (ODO)

If step 2, 3, or 4 fails → Delivery will not appear in EWM.

---

2️⃣ Most Common Root Causes (Real Project Experience)

---

🔹 A. Warehouse Number Determination Failed (Very Common)

Check in ERP:

SPRO → Logistics Execution → Shipping → Basic Shipping Functions → Shipping Point and Goods Receiving Point Determination

Verify:

• Shipping point assigned correctly

• Plant + Storage location mapped to warehouse number

If warehouse number is not determined, delivery will not be EWM-relevant.

---

🔹 B. Delivery Type Not Relevant for EWM

Check:

SPRO → Integration with Other SAP Components → EWM → Assign Delivery Type to Warehouse Process

Ensure:

• Delivery type is mapped to EWM warehouse

• Document category relevant for distribution

If delivery type is not marked as EWM relevant, system will not send it.

---

🔹 C. Queue Not Created (Silent Failure)

Even if SMQ2 is empty, check:

Transaction:
SMQ1 (Outbound Queue in ERP)

If no queue entry exists, distribution was never triggered.

Possible reasons:

• qRFC scheduler not running

• RFC destination issue

• Logical system mismatch

---

🔹 D. User Exit / BAdI Blocking Distribution

Check if any enhancement is active for delivery creation.

Common BAdIs:

• LE_SHP_DELIVERY_PROC

• /SCWM/EX_ERP_DLV_DISTRIBUTE

Custom logic may suppress EWM distribution under certain conditions.

This is common in mature projects.

---

🔹 E. Incorrect Integration Model / Logical System

Verify:

• Logical system assigned correctly

• Warehouse linked to correct ERP system

• RFC destination working (SM59 test)

If RFC is inactive, delivery will not transfer.

---

3️⃣ What to Check Immediately (Practical Sequence)

Follow this order:

✔ Step 1: Check Warehouse Number in Delivery

In VL03N → Header → Check warehouse number determination

✔ Step 2: Check SMQ1 in ERP

See if outbound queue entry exists

✔ Step 3: Check SMQ2 in EWM

Ensure inbound queue processed

✔ Step 4: Check SM59

Test RFC connection

✔ Step 5: Check SLG1

Object: /SCWM/ERP_INT or DELIVERY

---

4️⃣ How to Safely Troubleshoot in Production

⚠ Do NOT manually create ODO in EWM.

Safe approach:

1. Identify if queue exists

2. If queue stuck → fix and reprocess

3. If no queue → check delivery relevance configuration

4. If necessary → reverse delivery and recreate after fix

Never adjust tables directly.

---

5️⃣ Critical Configuration Objects for Delivery Integration

✔ Warehouse number determination
✔ Delivery type mapping to EWM
✔ Document category relevance
✔ RFC destination
✔ Logical system assignment
✔ qRFC scheduler active
✔ Integration BAdI implementations

---

6️⃣ Real Project Scenario

In one S/4HANA Embedded EWM project:

Issue:
Delivery created in ERP but not visible in EWM.

Root Cause:
Delivery type mapping was removed during transport.

System did not consider delivery EWM-relevant.

Fix:
Re-maintained delivery type mapping → recreated delivery → Distribution worked immediately.

No queue issue involved.

---

7️⃣ Golden Rule

If delivery does not appear in EWM:

👉 First confirm whether distribution message was created.
👉 If message not created → Configuration issue.
👉 If message created but not processed → Queue issue.

This distinction saves hours of troubleshooting.

---

🎯 Final Conclusion

If Delivery is not distributed to EWM after creation in S/4HANA, it is usually due to:

• Warehouse number determination failure

• Delivery type not EWM relevant

• Outbound queue not triggered

• RFC communication issue

• Enhancement logic blocking distribution

Structured integration troubleshooting will resolve the issue safely without production risk.

---

See less

Goods Issue Posted in ERP but Not Updated in SAP EWM – How to Fix Status Mismatch

This issue indicates a synchronization failure between ERP and EWM during the outbound integration process.

Since:

• GI is posted in ERP

• Material document is created

• EWM delivery still shows “Not GI Posted”

• Stock still visible in EWM

The problem is almost always related to queue processing or integration message failure from ERP to EWM.

Let’s troubleshoot step by step.

---

1️⃣ Understand the Integration Logic

In Embedded EWM:

1. GI is posted

2. ERP sends confirmation message to EWM

3. EWM updates delivery status

4. Stock is reduced in EWM

If step 2 fails → Status mismatch occurs.

This is NOT a picking issue — it is an integration confirmation issue.

---

2️⃣ Most Common Root Causes (Real Project Experience)

---

🔹 A. Inbound Queue Stuck in EWM (Most Common Cause)

Check:

Transaction:
SMQ2 (Inbound Queue in EWM)

Look for queue related to delivery number.

Possible statuses:

• SYSFAIL

• RETRY

• STOP

If queue is stuck, EWM never receives GI confirmation.

👉 Fix the root cause and reprocess LUW.

---

🔹 B. Outbound Queue Not Processed in ERP

Check:

SMQ1 (Outbound Queue in ERP)

If message not sent to EWM, EWM status will not update.

Sometimes queue is in READY but scheduler job is not running.

Check background job for qRFC processing.

---

🔹 C. CIF / Delivery Integration Issue

Verify:

• Logical system assignment

• Warehouse number mapping

• Integration model active

If integration object is inactive or incorrectly mapped, confirmation message fails silently.

---

🔹 D. Delivery Already Closed in ERP Before EWM Update

In rare cases:

If delivery is technically closed in ERP before EWM confirmation, status may not sync properly.

Check document flow carefully.

---

🔹 E. Manual GI Posted in ERP (Bypassing EWM Process)

If someone posts GI directly in ERP using VL02N instead of EWM-driven GI:

ERP updates stock, but EWM is not informed properly.

This is a common root cause in production.

---

3️⃣ What to Check Immediately

Follow this sequence:

✔ Step 1: Check SMQ2 in EWM

Look for inbound delivery queue

✔ Step 2: Check SMQ1 in ERP

Ensure outbound confirmation message processed

✔ Step 3: Check SM58

Look for tRFC errors

✔ Step 4: Check SLG1

Object: /SCWM/ERP_INT or /SCWM/DELIVERY

---

4️⃣ How to Safely Re-Synchronize Status in Production

⚠ Never change tables manually.

Safe options:

---

✅ Option 1: Reprocess Queue (Preferred)

If queue exists:

• Fix error

• Execute LUW again

• Monitor status update

---

✅ Option 2: Use EWM Correction Transaction

Transaction:
/SCWM/POST

If GI already posted in ERP, system may allow synchronization update.

---

✅ Option 3: Cancel & Repost GI (If Business Allows)

If integration completely failed:

1. Reverse GI in ERP (VL09)

2. Ensure queue working

3. Post GI again from EWM

⚠ Only after business approval.

---

5️⃣ When to Correct in ERP vs EWM?

Golden Rule:

👉 Never adjust stock manually in EWM to fix ERP mistake.

Always fix integration.

---

6️⃣ Real Project Scenario

In one S/4HANA Embedded EWM project:

Issue:
GI posted in ERP but EWM still showed open delivery.

Root Cause:
Outbound queue in ERP was stuck due to temporary RFC destination issue.

Queue was in READY state but background job was inactive.

Fix:
Activated qRFC scheduler → Reprocessed queue → Status synchronized automatically.

No manual correction needed.

---

7️⃣ Practical Troubleshooting Flow

1. Check ERP GI document

2. Check SMQ1 in ERP

3. Check SMQ2 in EWM

4. Check SM58

5. Reprocess queue

6. Monitor delivery status in /SCWM/PRDO

Avoid direct stock adjustment.

---

🎯 Final Conclusion

If Goods Issue is posted in ERP but not updated in SAP EWM, it is usually caused by:

• Inbound queue stuck in EWM

• Outbound queue not processed in ERP

• RFC communication issue

• Manual GI in ERP

• Integration model misconfiguration

This is an integration confirmation failure — not a warehouse issue.

Proper queue monitoring and controlled reprocessing will resolve the inconsistency safely.

See less

When RF transaction screen flow is incorrect in SAP S/4HANA Embedded EWM, and GUI transactions work correctly, the issue is usually related to RF Framework configuration or screen flow control logic, not warehouse process configuration.

Since:

• RF transaction starts correctly

• Initial screen appears

• GUI works fine

• No dump or application error

The issue is most likely in RF screen sequencing configuration or custom enhancement logic.

Let’s troubleshoot systematically.

---

1️⃣ Check Logical Transaction & Presentation Profile

Go to:

Transaction:
/SCWM/RFUI

Then check configuration in SPRO:

EWM → Mobile Data Entry → RF Framework → Define Logical Transactions

Verify:

• Logical transaction assigned correctly

• Correct step sequence maintained

• Presentation profile assigned

If incorrect logical transaction is assigned, wrong screen sequence will appear.

---

2️⃣ Check Screen Flow Configuration

Path:

SPRO → EWM → Mobile Data Entry → RF Framework → Define Screen Flow Logic

Key checks:

• Screen sequence numbers

• Foreground/Background step indicator

• Verification profile

• Function code assignments

If sequence numbers are incorrect or step type is misconfigured, screens may:

• Skip steps

• Jump to wrong screen

• Not prompt mandatory fields

This is one of the most common issues.

---

3️⃣ Check Verification Profile

If mandatory fields are not prompted:

Check:

SPRO → EWM → Mobile Data Entry → RF Framework → Define Verification Profile

Verify:

• Required fields marked properly

• Field control active

• Profile assigned to logical transaction

If verification profile is missing or wrongly assigned, RF will skip mandatory input.

---

4️⃣ Check Warehouse Process Type (WPT) Influence

Although WPT is correct, check:

• Is WPT configured for background processing?

• Is auto-confirmation active?

• Is automatic WT confirmation enabled?

If auto-confirmation is active, RF may skip confirmation screens.

This is often mistaken as screen flow error.

---

5️⃣ Check BAdI or Custom Enhancements (Very Common in Real Projects)

Many projects enhance RF using:

BAdI:
/SCWM/EX_RFUI_EXTEND

or related RF framework enhancement spots.

Custom logic may:

• Skip screens intentionally

• Change next screen dynamically

• Suppress input fields

If issue exists only in certain warehouse or process type, enhancement is highly likely.

Always check:

SE19 → Active implementations for RF BAdIs

---

6️⃣ How to Debug RF Issues Safely

In QA or DEV:

1. Activate external breakpoint in RF function module

2. Use user-specific debugging

3. Test using /SCWM/RFUI

In Production (safe approach):

• Avoid hard debugging

• Use SLG1 (Application Log)

• Check RF logs

• Compare working vs non-working warehouse configuration

---

7️⃣ Check Presentation Device Settings

Sometimes issue occurs only on certain RF devices.

Check:

• Presentation profile

• Display profile

• Device template settings

Different device templates may suppress fields.

---

🔎 Real Project Scenario

In one Embedded EWM project:

Issue:
During picking, confirmation screen was skipped.

Root Cause:
Custom BAdI implementation dynamically changed next screen based on WPT.

Fix:
Adjusted enhancement logic and tested in QA.

After transport, RF flow worked correctly.

No standard config issue.

---

🛡 Practical Troubleshooting Sequence

Follow this order:

1. Verify Logical Transaction

2. Check Screen Sequence configuration

3. Verify Verification Profile

4. Check WPT auto-confirm settings

5. Review BAdI implementations

6. Compare working warehouse vs failing warehouse

Never change screen flow directly in production without testing.

---

🎯 Final Conclusion

Incorrect RF screen sequence in SAP EWM is usually caused by:

• Wrong logical transaction assignment

• Incorrect screen flow configuration

• Missing verification profile

• Auto-confirm settings in WPT

• Custom BAdI enhancement logic

GUI working fine confirms that the issue is RF framework-specific.

Systematic review of RF configuration and enhancements will resolve the issue safely.

See less

Warehouse Order Created but Not Assigned to Resource in SAP EWM – Root Cause & Fix

When Warehouse Orders (WO) are created but not assigned automatically to a resource in SAP EWM, the issue is usually related to queue configuration, resource setup, or activity area mismatch.

Even if WT creation, WOCR, and queue determination appear correct, automatic assignment will not work unless all assignment conditions are fulfilled.

Below is a step-by-step troubleshooting guide based on real project experience.

---

🔎 What Controls WO-to-Resource Assignment?

Automatic WO assignment depends on:

• Queue determination

• Resource assignment to queue

• Resource group configuration

• Activity area mapping

• Warehouse Order Creation Rule (WOCR)

• Resource type and activity

If any link is missing, WO remains unassigned.

---

🛑 Most Common Root Causes

1️⃣ Resource Not Assigned to Correct Queue (Most Common)

Check:

• /SCWM/RSRC → Display Resource

• Verify assigned queue

If the WO queue is Q_PICK_01 but the resource is assigned to Q_PICK_02, automatic assignment will not occur.

👉 This is the #1 real-world cause.

---

2️⃣ Resource Group Not Linked Properly

Verify:

• Resource group assigned to resource

• Resource group allowed for correct activity

Mismatch between WOCR and resource group prevents assignment.

---

3️⃣ Activity Area Mismatch

If WO is created for Activity Area A1, but resource is configured for Activity Area A2:

→ Assignment will fail silently.

Check:

• Activity area in WO

• Activity area allowed for resource

---

4️⃣ Resource Type Incorrect

Ensure resource type supports:

• Picking activity

• Correct warehouse number

Sometimes resource is created but not configured for required activity.

---

5️⃣ Automatic Assignment Not Activated

Check:

• Queue configuration allows automatic assignment

• WOCR settings do not restrict assignment

• No capacity restrictions blocking assignment

If capacity limit reached, WO may remain open.

---

🧪 Step-by-Step Troubleshooting Guide (Production Safe)

Follow this order:

Step 1

Check queue assigned to WO in /SCWM/MON.

Step 2

Check resource assignment to same queue in /SCWM/RSRC.

Step 3

Verify activity area in WO matches resource configuration.

Step 4

Review resource group mapping.

Step 5

Check WOCR for grouping restrictions.

Step 6

Review application logs (SLG1) for hidden assignment messages.

This structured approach avoids random configuration changes.

---

⚠ Common Configuration Mistakes

• Resource assigned to wrong warehouse number

• Resource active but not logged into correct queue

• Queue created but not linked to resource group

• Activity area copied but not updated

• Capacity check blocking assignment

• Testing done with different resource than configured

These small gaps commonly block automatic assignment.

---

📊 How Queue, Resource Group & Activity Area Impact Assignment

All four must align for automatic assignment to work.

---

✅ Final Recommendation

In most productive systems, automatic WO assignment fails because:

• Resource not assigned to correct queue

• Activity area mismatch

• Resource group configuration incomplete

Always start troubleshooting from queue alignment, then validate resource configuration.

Once queue + activity + resource mapping are aligned, automatic assignment works immediately.

See less

Controlling Warehouse Task Creation Based on Product Shelf Life (SLED) in SAP EWM

In pharmaceutical and regulated industries, controlling remaining shelf life during WT creation is critical for compliance. While FEFO and sort rules help, they are not sufficient to fully enforce minimum SLED validation.

A robust design requires a combination of:

• Standard configuration

• Batch determination strategy

• Stock removal control

• Enhancement (if strict blocking is required)

Below is the recommended real-project approach.

---

🔹 1️⃣ Understand Standard System Behavior First

Standard SAP EWM supports:

✔ FEFO (First Expired First Out)
✔ Batch determination
✔ Shelf life relevance in product master
✔ Sort rules based on SLED

However:

❌ Standard FEFO does not block WT creation if minimum remaining shelf life is not met.
❌ It only sorts stock — it does not enforce business rule validation.

That is why configuration alone is often insufficient.

---

🔹 2️⃣ Outbound Picking – Best Practice Design

✔ Step 1: Maintain SLED & Minimum Remaining Shelf Life

In product master:

• Maintain shelf life expiration data

• Maintain minimum remaining shelf life

Ensure batch classification is correct.

---

✔ Step 2: Use FEFO + Sort Rule (First Level Control)

Configure:

• Stock removal strategy = FEFO

• Sort rule based on expiration date

• Batch determination active

This ensures:
👉 System proposes oldest valid stock first.

But this alone does not enforce 90-day rule strictly.

---

✔ Step 3: Enforce Hard Stop Using BAdI (Recommended for Pharma)

If business requires:

“Do not create WT if remaining SLED < 90 days”

Then enhancement is required.

Commonly Used BAdI in Real Projects:

or

These BAdIs allow you to:

• Validate remaining shelf life dynamically

• Compare SLED against current date

• Throw error message

• Prevent WT creation

This is the most reliable approach in regulated environments.

---

🔹 3️⃣ Inbound Putaway – Directing Short SLED to Fast-Pick Areas

For inbound control:

✔ Option 1: Storage Type Search Sequence

Define:

• Storage type determination based on:

  • Shelf life remaining

  • Stock type

  • Putaway control indicator

But this requires enhancement if dynamic logic is complex.

---

✔ Option 2 (More Flexible): BAdI for Storage Type Determination

Common BAdI used:

This allows:

• Reading SLED at GR

• Determining remaining days

• Assigning storage type dynamically

  • Short SLED → Fast picking area

  • Long SLED → Bulk storage

This is widely used in pharma implementations.

---

🔹 4️⃣ Recommended Overall Architecture

For strict pharma compliance:

✔ Configuration Layer

• FEFO strategy

• Sort rule

• Batch determination

• Minimum remaining shelf life in material master

✔ Validation Layer (Enhancement)

• BAdI to enforce minimum remaining SLED

• Hard error if criteria not met

✔ Putaway Optimization Layer

• Dynamic storage type determination via BAdI

This ensures:

• Compliance

• Audit readiness

• Controlled WT creation

---

🔹 5️⃣ Common Design Mistakes

❌ Relying only on FEFO
❌ Not validating remaining days dynamically
❌ Ignoring time zone/date calculation
❌ Allowing manual override without audit log
❌ Not testing edge cases (partial batch, mixed HU)

---

🔹 6️⃣ Real Project Recommendation

In pharmaceutical projects:

✔ Always implement enhancement for SLED validation
✔ Log validation messages for audit
✔ Prevent manual bypass
✔ Test year-end date transitions
✔ Document SLED logic in functional specification

Because in regulated industries:

Compliance requirement > Standard convenience.

---

🔑 Final Answer to Your Question

✔ Is configuration alone enough?

No — configuration handles sorting but not strict blocking.

✔ Is BAdI required?

Yes, if business requires minimum remaining shelf life enforcement.

✔ Which BAdIs are commonly used?

• /SCWM/EX_CORE_STOCK_REMOVAL

• /SCWM/EX_WHO_CREATE

• /SCWM/EX_CORE_PTS_DET (for putaway logic)

---

See less