Hello,
Sign up to join our community!
Sign up to join our community!
Please sign in to your account!
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
RF Picking Confirmed but Goods Issue Not Posted in SAP EWM – What Could Be the Reason?
RF Picking Confirmed but Goods Issue Not Posted in SAP EWM This issue is very common in SAP S/4HANA Embedded EWM projects, especially during outbound go-live. If: Warehouse Tasks are confirmed Picking status is complete Stock moved to staging area No queue or dump error But Goods Issue (GI) is not pRead more
RF Picking Confirmed but Goods Issue Not Posted in SAP EWM
This issue is very common in SAP S/4HANA Embedded EWM projects, especially during outbound go-live.
If:
Warehouse Tasks are confirmed
Picking status is complete
Stock moved to staging area
No queue or dump error
But Goods Issue (GI) is not posted, then the issue is usually related to PPF action, status management, or outbound process control.
Let’s analyze it step-by-step.
1️⃣ Understand Important Concept
In EWM:
👉 Picking confirmation ≠ Goods Issue posting
GI is a separate step and is normally triggered by:
PPF action automatically
OR
Manual /SCWM/POST transaction
OR
Separate RF transaction (if configured)
Many projects assume GI posts automatically after picking — but that depends on configuration.
2️⃣ Most Common Root Causes (Real Project Experience)
🔹 A. PPF Action Not Triggered (Most Common)
Goods Issue in EWM is controlled by PPF Action Profile.
Check in:
Transaction:
/SCWM/PRDO
Open outbound delivery → Go to Actions tab
Look for action like:
/SCWM/PGI
Goods Issue
Outbound Delivery GI
Check:
Is action scheduled?
Is action processed?
Any processing log error?
If PPF is not scheduled, GI will never post.
🔹 B. PPF Condition Record Missing
Check configuration:
SPRO → EWM → Cross Process Settings → PPF → Define Action Profiles
Ensure:
Correct action profile assigned to document type
Condition record maintained
Processing time correct (Immediate or Background)
If condition is missing, action will not trigger automatically.
🔹 C. Outbound Delivery Status Not Fully Complete
Even if picking appears complete, check:
/SCWM/PRDO → Document Status
Verify:
Picking Status = Completed
Loading Status = Completed
Goods Movement Status = Not Started
If loading or staging is incomplete, GI may not trigger.
🔹 D. GI Requires Separate RF Step (Project Design Dependent)
Some projects configure RF flow like:
Pick
Stage
Load
Post GI
If separate RF transaction is configured for GI, picking confirmation alone will NOT trigger GI.
Check logical transaction in RF configuration.
🔹 E. Queue or ERP Communication Issue
Even if no visible queue error, check:
Transaction:
SMQ2
Look for outbound queue to ERP.
Sometimes queue is in READY but not processed.
Also check:
SM58 (tRFC errors)
3️⃣ How to Safely Trigger GI in Production
If delivery is ready but GI not posted:
Option 1 (Safest)
Use transaction:
/SCWM/POST
Select delivery → Execute GI manually.
Option 2
Reprocess PPF action in:
/SCWM/PRDO → Actions → Execute manually
⚠ Never directly change delivery status tables in production.
Always reprocess through standard transaction.
4️⃣ Configuration Objects Commonly Missed
✔ PPF Action Profile
✔ Condition Record for GI
✔ Document Type → Action Profile assignment
✔ WPT auto-confirm settings
✔ RF Logical Transaction sequence
✔ Staging & Loading completion settings
5️⃣ Real Project Scenario
In one S/4HANA Embedded EWM project:
Issue:
RF picking completed successfully but GI not posted.
Root Cause:
PPF condition record for Goods Issue was not maintained after transport.
System was not triggering action automatically.
Fix:
Maintained condition record in QA → Transported to Production → Reprocessed PPF.
GI posted successfully.
6️⃣ Practical Troubleshooting Sequence
Follow this order:
Check document status in /SCWM/PRDO
Check PPF action status
Verify condition records
Confirm loading/staging complete
Check SMQ2 & SM58
Test manual GI using /SCWM/POST
This avoids unnecessary configuration changes.
🎯 Final Conclusion
If RF picking is confirmed but Goods Issue is not posted in SAP EWM, it is usually due to:
PPF action not triggered
Missing condition record
Incomplete loading status
Separate RF GI step required
ERP queue issue
Picking confirmation alone does NOT guarantee GI posting.
Proper PPF and status verification will resolve the issue safely.
-
See lessRF Transaction Not Displaying Correct Screen Sequence in SAP EWM – How to Troubleshoot?
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 GRead more
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:
Activate external breakpoint in RF function module
Use user-specific debugging
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:
Verify Logical Transaction
Check Screen Sequence configuration
Verify Verification Profile
Check WPT auto-confirm settings
Review BAdI implementations
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 lessPosting Change Not Triggered Automatically After Goods Receipt in SAP EWM – What Could Be Wrong?
This issue is typically related to configuration or QM follow-up control rather than a system defect. Since: Goods Receipt is successful Stock is visible in EWM Manual Posting Change works No queue errors or dumps The problem is almost always in automatic posting change determination logic. Let’s anRead more
This issue is typically related to configuration or QM follow-up control rather than a system defect.
Since:
Goods Receipt is successful
Stock is visible in EWM
Manual Posting Change works
No queue errors or dumps
The problem is almost always in automatic posting change determination logic.
Let’s analyze it step-by-step.
1️⃣ Check QM Integration First (Most Common Cause)
If QM is active, after GR:
Stock is posted to Quality Inspection (Q) stock
Automatic posting change to Unrestricted (F) happens only after Usage Decision (UD)
👉 Go to ERP side:
Transaction QA32
Check:
Is inspection lot created?
Is Usage Decision completed?
If UD is not completed, posting change will NOT trigger automatically.
This is the most common real-project scenario.
2️⃣ Verify Follow-Up Action Configuration
Path:
SPRO → EWM → Cross Process Settings → Posting Change → Define Follow-Up Actions
Check:
Source stock type (e.g., Q)
Target stock type (e.g., F)
Warehouse number
If follow-up action is not maintained correctly, system will not generate Posting Change WT.
3️⃣ Check Stock Type Determination
Path:
SPRO → EWM → Cross Process Settings → Stock Type Determination
Ensure:
Correct stock type group
Correct availability group
Proper mapping maintained
If mapping is missing, automatic logic will not work.
4️⃣ Verify Warehouse Process Type (WPT) Determination
Path:
SPRO → EWM → Cross Process Settings → Warehouse Task → Determine Warehouse Process Type
Check:
Posting Change indicator active
Correct WPT assigned
Even if WPT exists, wrong determination settings will stop automatic WT creation.
5️⃣ Check Product Master Settings
Transaction:
/SCWM/MAT1
Under Warehouse Data:
Stock type group maintained?
Posting change indicator maintained?
If not, automatic posting change will not trigger.
6️⃣ Logs & Monitoring
If no error is shown, check:
✔ /SCWM/MON → Posting Change Node
✔ SLG1 → Object: /SCWM/POST
✔ SMQ2 → Queue status
✔ /SCWM/PRDI → Delivery status
🔎 Real Project Example
In one Embedded EWM project:
Issue:
Stock remained in Quality stock after GR.
Root Cause:
Usage Decision was not completed in QA32.
After completing UD, automatic posting change WT was created.
No configuration change required.
🛡 Safest Approach in Production
Do NOT change configuration directly.
First verify QM status.
Validate stock type mapping in QA system.
Transport changes properly if needed.
Test with one document before mass processing.
🎯 Final Conclusion
If Posting Change is not triggered automatically after GR in SAP EWM, it is usually due to:
Pending Usage Decision (QM)
Missing follow-up action configuration
Incorrect stock type determination
WPT determination issue
Missing product master settings
Structured troubleshooting will identify the issue without risky changes in production.
See lessWarehouse Order Created but Not Assigned to Resource in SAP EWM – How to Fix?
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,Read more
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 ResourceVerify 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 lessSAP EWM Activity Area Not Determined During Warehouse Task Creation – Step-by-Step Troubleshooting Guide
The error “Activity Area Not Determined” during Warehouse Task (WT) creation in SAP EWM usually occurs when the system cannot link the storage bin, storage type, and activity configuration properly for the picking process. Even if delivery, stock, and Warehouse Process Type (WPT) appear correct, WTRead more
How to Control Warehouse Task Creation Based on Product Shelf Life (SLED) in SAP EWM?
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 validatiRead more
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:
Then enhancement is required.
Commonly Used BAdI in Real Projects:
/SCWM/EX_CORE_STOCK_REMOVAL
or
/SCWM/EX_WHO_CREATE
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:
/SCWM/EX_CORE_PTS_DET
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:
🔑 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
How to Design an Effective Slotting and Rearrangement Strategy in SAP EWM for High-Pick Warehouses
Designing an Effective Slotting & Rearrangement Strategy in SAP EWM for High-Pick Warehouses Slotting & Rearrangement in SAP EWM is extremely powerful — but in high-volume warehouses, it can easily fail if treated as a purely system-driven exercise. The key principle from real projects is: SRead more
Designing an Effective Slotting & Rearrangement Strategy in SAP EWM for High-Pick Warehouses
Slotting & Rearrangement in SAP EWM is extremely powerful — but in high-volume warehouses, it can easily fail if treated as a purely system-driven exercise.
The key principle from real projects is:
Below is a practical, field-tested approach used in productive implementations.
🔹 1️⃣ Start With Business Segmentation (Not System Criteria)
Before defining slotting rules, segment products into:
Fast movers
Medium movers
Slow movers
Seasonal movers
Promotion-driven SKUs
Use:
Historical picking data
Lines per day
Order frequency
Quantity per order
👉 Do not rely only on material master attributes.
Use real warehouse movement data.
🔹 2️⃣ Defining Meaningful Slotting Criteria
Best practice is to combine physical + demand-based attributes.
✔ Recommended Slotting Criteria Mix
Demand-Based
Pick frequency (lines per day)
Quantity picked per period
ABC classification (based on movement)
Velocity index
Physical-Based
Weight
Volume (cube)
Handling constraints
Hazardous classification
HU type
🔴 Common Mistake
Using only:
Weight
Volume
Static ABC class
Without dynamic demand.
👉 Slotting must be demand-driven in high-pick warehouses.
🔹 3️⃣ Handling Seasonal Fluctuations
For seasonal businesses:
✔ Run slotting simulation quarterly
✔ Maintain season-based classification
✔ Avoid monthly full rearrangement (too disruptive)
Best practice:
Major rearrangement → Quarterly
Minor adjustments → Monthly
High-impact SKUs → As needed
🔹 4️⃣ Rearrangement Strategy – Be Realistic
❌ What Fails in Real Projects
Daily rearrangement proposals
Moving thousands of bins at once
System-generated moves without operational validation
Result:
Warehouse team rejects process
Rearrangement tasks ignored
✅ What Works
✔ Limit rearrangement to top 10–20% movers
✔ Set movement threshold (only move if benefit is significant)
✔ Restrict to specific storage types
✔ Schedule rearrangement during low activity windows
👉 Slotting should optimize 20% SKUs that drive 80% picking.
🔹 5️⃣ Balancing Optimization vs Operational Feasibility
System-optimized bin ≠ Operationally practical bin.
Consider:
Picker route logic
Ergonomic access
Aisle congestion
Replenishment impact
Best practice:
Validate proposals with warehouse supervisor
Run simulation before execution
Implement zone-based picking logic
Slotting must align with physical warehouse layout.
🔹 6️⃣ Performance Considerations in Large Warehouses
When running slotting jobs on 100,000+ bins:
✔ Run in background job
✔ Split by storage type
✔ Limit product selection range
✔ Avoid full-warehouse simulation during peak hours
✔ Monitor system load
Never run large slotting jobs during peak outbound windows.
🔹 7️⃣ Governance & Change Management (Critical for Success)
Slotting often fails due to business resistance.
Best practice:
✔ Create clear approval workflow
✔ Document movement justification
✔ Measure KPI impact (travel time, pick rate)
✔ Show improvement data to business
When business sees reduced picker travel time → acceptance increases.
🔹 8️⃣ Real Project Lessons Learned
✔ What Worked
Quarterly slotting review
Dynamic ABC classification
Limited rearrangement scope
Supervisor validation
KPI tracking
❌ What Failed
Over-automation
Daily rearrangement
Ignoring operational constraints
Moving low-impact SKUs
No performance analysis
🔑 Final Recommendation
For high-pick warehouses:
Make slotting demand-driven
Focus on top-moving SKUs
Limit rearrangement frequency
Validate system proposals operationally
Use slotting as strategic optimization — not daily maintenance
The most successful projects treat slotting as:
See less
Warehouse Task Not Created After Outbound Delivery Replication in SAP EWM – How to Troubleshoot?
When an outbound delivery is successfully replicated to SAP EWM but Warehouse Tasks (WTs) are not created, the issue is usually related to status management, configuration gaps, or background action failures — even if everything appears correct at first glance. Below is a real-project, systematic trRead more
When an outbound delivery is successfully replicated to SAP EWM but Warehouse Tasks (WTs) are not created, the issue is usually related to status management, configuration gaps, or background action failures — even if everything appears correct at first glance.
Below is a real-project, systematic troubleshooting approach.
🔍 1. Check Delivery Status (Most Commonly Missed)
Go to /SCWM/MON → Outbound Delivery Order (ODO) and verify:
Important Status Fields:
Warehouse Process Status
Picking Status
Overall Status
Goods Issue Relevance
WT Creation Relevance
👉 If delivery is not “Released for Picking”, WT will not be created.
Very often, the delivery exists but is not fully warehouse-relevant.
🔍 2. Check Whether Automatic WT Creation Is Triggered
WT creation may depend on:
Manual creation
Automatic creation via PPF
Wave management
Background job
✔ If PPF is used:
Check:
PPF action profile assigned
Action determination successful
Action status processed without error
Missing or inactive PPF action = No automatic WT.
🔍 3. Verify Warehouse Process Type (WPT) Deeply
Even if WPT is “maintained”, check:
Picking control indicator
Stock removal rule
Confirmation control
Activity area assignment
👉 Incorrect picking control can silently prevent WT creation.
This is one of the top root causes.
🔍 4. Validate Storage Type Search & Stock Availability
Even with correct search sequence:
Is stock actually available in correct stock type?
Is stock blocked or in quality?
Is batch determination failing?
Is stock in different availability group?
Check:
/SCWM/MON → Stock Overview
Product warehouse view
👉 If no valid source bin is found, WT will not be created.
🔍 5. Check Wave Management (If Active)
If wave management is used:
Delivery may require wave release
WT is created only after wave release
Check wave status
Many projects forget this dependency.
🔍 6. Queue & WOCR Validation
Even if queue exists:
Is correct queue determined?
Is resource assigned to that queue?
Is WOCR restricting WT grouping?
Incorrect queue determination can prevent processing.
🔍 7. Check Application Logs (Very Important)
Go to SLG1 and check for:
Object: /SCWM/DELIVERY
Object: /SCWM/WAVE
Object: /SCWM/WHSE_TASK
Often errors appear in logs but not on delivery UI.
🔍 8. Check qRFC Queues
Even if no visible errors:
Check SMQ1 / SMQ2
Look for stuck or temporary blocked entries
Reprocess failed messages if needed
Queue issues can delay WT creation.
🔍 9. Confirm Delivery Is Not Blocked
Check:
Credit block
Incompletion log
Delivery block indicators
GI relevance
Blocked deliveries will not trigger picking.
🔍 10. Product & Warehouse Data Validation
Check in /SCWM/MAT1:
Warehouse product maintained
Activity area assigned
Storage type indicators correct
No inconsistent stock removal rule
Missing activity area assignment is a common hidden cause.
✅ Most Common Real Project Root Causes
From real implementations, WT not created is usually due to:
Delivery not fully released for picking
Missing or failed PPF action
Incorrect picking control in WPT
No valid source stock found
Wave not released
Activity area not assigned
Queue mismatch
Application log errors
✅ Recommended Troubleshooting Order (Production Safe)
Follow this sequence:
1️⃣ Check delivery status
2️⃣ Check PPF action
3️⃣ Check stock availability
4️⃣ Validate WPT
5️⃣ Review wave status
6️⃣ Check application logs
7️⃣ Check queues
This minimizes business impact and avoids unnecessary configuration changes.
🔑 Final Project Insight
In 80% of cases, the issue is not a system error, but:
Status not properly triggered
Automatic action not configured
Warehouse process control misaligned
Always validate process flow sequence, not just configuration.
See less