Oracle Cloud 26B: Smarter WMS, Mobile, Integration, and Logistics

The Oracle Cloud 26B release is not just another quarterly update it reflects a clear evolution in how warehouse operations, integrations, and decision-making are being reimagined.

From my perspective working across Oracle Cloud WMS and Fusion integrations, what stands out is how closely these enhancements align with real-world operational challenges that teams face every day.

Let’s break this down.

First, the WMS capability enhancements are quietly powerful. Many organizations struggle with balancing standardization and flexibility in warehouse processes. The new updates move closer to that sweet spot offering improved configurability while maintaining control. This is particularly relevant in high-volume or multi-client environments where exceptions are the norm, not the exception.

Then comes the Redwood mobile experience, which in my opinion is one of the most impactful shifts. Warehouse operations live and die on usability. If the UI slows users down, adoption drops. Redwood is clearly designed with the operator in mind cleaner navigation, faster interactions, and a more intuitive flow. This is not just a UI upgrade; it directly impacts productivity on the floor.

On the integration side, the introduction of OAuth-based authentication is a major step forward. Many of us have seen the pain points around managing integrations securely across WMS, ERP, and external systems. OAuth simplifies this while strengthening security posture something that becomes critical as ecosystems grow more connected.

What really signals the future, though, is the continued push toward AI-driven capabilities. We are moving beyond transactional systems into intelligent platforms. Whether it’s predictive insights, smarter task prioritization, or data-driven decision support, AI is no longer optional, it’s becoming embedded into the core of supply chain execution.

And finally, the logistics improvements reinforce the need for tighter synchronization between warehouse and transportation. In reality, warehouse efficiency means little if it is not aligned with outbound planning and delivery execution. These enhancements help bridge that gap.

From a consulting standpoint, this release raises an important point:

Technology is no longer the constraint. Adoption and execution are.

The organizations that will benefit the most from 26B are not the ones that simply upgrade, but the ones that actively rethink their processes, retrain their users, and realign their integration strategies.

Because ultimately, features don’t drive transformation, decisions do.

A visual process flow can show how warehouse execution, mobile users, integration, AI, and logistics improvements connect in one story.

• Release update.
• Warehouse operations.
• Mobile execution.
• Integration and security.
• AI and logistics optimization.

26B Release

• Enhanced WMS capabilities
• Redwood Mobile improvements for floor users
• OAuth-secured integrations with ERP and external apps
• AI-enabled smarter decisions
• Better logistics execution and responsiveness

That sequence works well because it moves from system capability to user adoption, then to connectivity, intelligence, and finally business impact.

Thank You,
Pratip Chatterjee

Why Oracle Cloud WMS and ERP Inventory Go Out of Sync - and How to Fix It

Oracle Cloud WMS and Oracle ERP are designed to work together, but inventory mismatches still happen in many real implementations due to wrong planning. The most common reasons are UOM differences, transaction timing gaps, integration failures, manual adjustments, and process variation across warehouse operations.

The core problem
In Oracle environments, WMS often operates with real-time warehouse execution, while ERP inventory may rely on different update timing or integration logic, which can create temporary or persistent mismatches. Oracle customer discussions also show a concrete example: ERP can work with primary or secondary UOM at the sales order level, while WMS typically assumes primary UOM, which causes shipping and inventory discrepancies. Oracle documentation also confirms that integration errors are visible in WMS Cloud interfaces and that failed records must be corrected and reprocessed, which shows how fragile inventory sync can become when master data or dependent data is missing.

Why it happens
The most common causes are:

• Unit-of-measure mismatches between ERP and WMS.
• Different transaction timing, where one system posts faster than the other.
• Integration failures or validation errors in inbound and outbound messages.
• Manual stock corrections that do not flow cleanly across systems.
• Data structure differences and poor master data quality.

These issues become more visible in high-volume businesses because even a small delay or mismatch can multiply across thousands of transactions per day.

What it looks like in industries

FMCG
FMCG companies move fast, with short shelf life, frequent replenishment, and high SKU turnover. If WMS and ERP are not synchronized, the result can be overstocks, stockouts, and inaccurate replenishment decisions, especially when promotional demand spikes suddenly. In that environment, even a small UOM or timing mismatch can distort available stock and disrupt dispatch planning.

Retail
Retail is highly sensitive to inventory accuracy because store replenishment, e-commerce fulfillment, and returns all depend on trusted stock balances. Oracle’s retail WMS documentation highlights how integration errors must be identified, corrected, and reprocessed, which shows how operationally disruptive a bad interface can be when merchandise flow is continuous. In retail, the real business risk is not just an inventory mismatch, it is lost sales and broken customer promise.

Healthcare
Healthcare has a different pressure point: stock accuracy directly affects patient care. Oracle has highlighted new healthcare inventory capabilities that automate stock tracking, update balances, and trigger replenishment because manual processes can cause delays, shortages, and poor visibility. In hospitals and labs, inventory sync failures can mean missing critical supplies at the wrong time, which is much more serious than a standard warehouse discrepancy.

How to fix it
A practical fix is not one single setting, it is a control framework:

• Standardize UOM rules across ERP and WMS before go-live.
• Use automated integration and near-real-time sync instead of manual batch reconciliation.
• Monitor interface errors in WMS and reprocess failed records quickly.
• Lock down master data governance for items, UOM, locations, and ownership rules.
• Define a clear exception process for manual adjustments so every correction is traceable.

Run frequent cycle counts and reconciliation audits to catch drift early.
Oracle’s own integration guidance for WMS Cloud shows that validation failures are surfaced in interface screens and corrected records can be reprocessed, which makes operational monitoring essential rather than optional. Oracle also provides integration recipes to sync inventory, purchase orders, receipts, and shipments between ERP/SCM Cloud and WMS Cloud, reinforcing that structured integration is the right direction.

A simple example
Imagine a retailer receiving 100 cartons of an item. If ERP records the order in carton units but WMS processes the shipment in pieces, inventory may appear correct in one system and wrong in the other until the transaction is converted consistently. In healthcare, the same kind of mismatch could prevent replenishment of critical consumables, which is why Oracle has pushed automation and RFID based replenishment to improve visibility and reduce manual entry errors.

Oracle Cloud WMS and ERP inventory go out of sync when organizations expect software to fix a process problem that actually needs master data control, integration discipline, and exception management. The companies that solve it best are the ones that treat inventory accuracy as a cross-functional operating model, not just an IT project.

Thank You,

Pratip Chatterjee

Oracle WMS Cloud receiving setup

Oracle Warehouse Management Cloud (WMS) receiving setup can be a bit tricky at first, especially if you're coming from on-prem systems like EBS, but once you get the hang of it, it's super efficient for handling inbound inventory. This guide walks you through the key configuration steps, followed by real-world transaction examples using RF (radio frequency) screens, and wraps up with common pitfalls I've seen in live implementations along with fixes. I'll keep it practical, like I'm chatting over coffee about a project we just wrapped up.

Key Prerequisites Before Setup

Before diving into receiving configs, make sure your foundation is solid: locations (receiving docks/stations), items/SKUs with correct UOMs and lot/serial flags, vendors set up with quality flags if needed, and host integration for ASNs (Advance Shipment Notices) from ERP like Fusion SCM or EBS.

Without these, you'll hit roadblocks during transactions. Pro tip: Test in a sandbox first—Oracle's UI is intuitive, but changes propagate fast.

Step 1: Configure Receiving Parameters

Head to Configuration > Inbound > Receiving Parameters. This is where you define rules for how items enter the warehouse, like blind receiving (no ASN expected) or ASN-required.

• Set Receiving Type: Choose "ASN Only", "Blind", or "Mixed" based on your suppliers. For most ops, "ASN Only" ensures accuracy.
• Enable Quality Control: Flag vendors/items for QC if they have high defect rates; the system auto-routes to the QC screen.
• LPN Generation: Auto-create License Plate Numbers (LPNs/totes) or manual.
• Save and add to RF menu under Inbound screens.

Transaction Example: 

Create ASN via REST API or UI (Inbound > Shipments > Create Shipment). Say PO#123 for 100 units of ITEM001 (case UOM). ASN arrives with Shipment#SH001. RF user scans the dock, the shipment, and the SKU system matches and prompts for quantity (e.g., scan 10 cases into LPN TOTE-001).

Step 2: Set Up Sort and Receive Rules

If you're doing high-volume DTC or cross-dock, enable Sort and Receive under Configuration > Inbound > Sort and Receive Config. This splits ASN contents by SKU/PO into totes before full receipt.

• Define rules, e.g., "If SKU=ITEM001 and PO=123, sort to TOTE-A; else new tote."
• Add receiving stations (locations like DOCK1).
• Assign to RF menu: Create screen "RF-SortReceive" and link it.

Transaction Example: ASN SH001 unloaded at floor. RF flow: Scan Receiving Station (DOCK1) > Shipment (SH001) > SKU (ITEM001). The system applies the rule, suggests TOTE-A (if it exists), or creates TOTE-002. Scan tote barcode, confirm qty=10, optional damage mark. Inventory increments in tote; repeat for next SKU. End tote when full status flips to "Received," sending history to host.

Step 3: Define Putaway Rules (Post-Receipt)

After receiving items, they need a home. Go to Configuration > Inbound > Putaway Zones/Rules. Link to locations like bulk/reserve.

• Zone by ABC (high-value to secure areas) or FIFO.
• Enable auto-putaway directives.

Transaction Example: From "Received" LPN (TOTE-001), RF screen "Putaway LPN." Scan LPN > suggested location (e.g., BAY-A-01). Confirm transfer. If an override is needed (space issue), scan the alternate.

Step 4: RF Menu and Screen Setup

Tie it together in Configuration > Screen Sets > RF Menu. Add screens like "Receiving," "Sort & Receive," and "QC Hold" in sequence.

Test end-to-end: ASN in > Receive > Sort if needed > Putaway.

Transaction Example (Full Flow): ASN 50 EA ITEM002 (serial tracked). RF: Dock scan > SH002 > ITEM002 > Serial#SN123 (system validates unique) > LPN NEW > Receive. If QC flagged, it diverts to the QC screen for inspection/approval.

Common Issues and Fixes

Here's where things go sideways in real projects, I've debugged these dozens of times.

Issue 1: "Serial/Lot Validation Error" During Receive

Happens with interfaced ASNs from EBS/Fusion; serials duplicate or mismatch.

Resolve: Check Inbound > Serial Control (allow duplicates? Pre-allocate?). Purge invalid serials via the Purge screen. REST API tip: Validate serials pre-send. Test: Receive dummy ASN with bad serial—error logs in Monitor > Inbound Errors.

Issue 2: No Tote Suggested or "Ambiguous Shipment Detail"

Sort rules misfire or multi-PO ASN.

Resolve: Review Sort/Receive Config, ensure rules cover edge cases (e.g., expiry prompt). Add fallback "Create New Tote." RF prompts for batch/expiry to disambiguate. Monitor rules via Reports > Inbound Rules Audit.

Issue 3: QC Not Triggering or Stuck in Hold

Vendor flag ignored, or QC screen missing from menu.

Resolve: Vendors > Edit > Enable QC. Add QC screens to RF. For stuck: Inbound > Holds > Release (reason code). Audit via Inventory History.

Issue 4: ASN Not Visible/Partial Receive Stuck

Host integration lag or partial quantity mismatch.

Resolve: Use Blind Receive as backup. Check Messages > Inbound Queue for errors. Reprocess via UI if <100% received.

Final Tips for Going Live

Pilot one dock with 2-3 SKUs. Use Oracle's monitor screens daily for errors. Integrate with Track & Trace for end-to-end visibility. If you're on 26A/B, leverage AI/ML for predictive receiving. Drop a comment if you hit snags; I'm happy to tweak for your setup!

This setup has slashed receiving times by 40% in my past UAE projects. Questions? Let's discuss.

Thank You,

Pratip Chatterjee

Oracle WMS: The Gap Between Design and Warehouse Reality

After working on Oracle WMS implementations across industries, regions, and warehouse models, one truth keeps repeating itself:

Oracle WMS rarely fails because of technology.
It struggles when design assumptions collide with warehouse reality.

On paper, Oracle WMS Cloud is powerful, flexible, and mature. In real warehouses, however, success depends on how well solution design reflects actual floor behavior, operational constraints, and human habits. This article explores where the gap typically appears and how experienced teams close it.

1. The Perfect Process Assumption

During solution design workshops, processes often look clean and linear:

• ASN arrives on time
• Goods are received exactly as per ASN
• Putaway follows system-suggested logic
• Picking is wave based and uninterrupted
• Packing and shipping flow smoothly
• Design documents assume process discipline and data accuracy.

Warehouse Reality On the floor:

• ASNs are late, incomplete, or wrong
• Mixed pallets arrive without labels
• Urgent receipts bypass standard flows
• Pickers interrupt tasks to handle priorities
• Supervisors override system logic to meet cut-off times

The gap: Oracle WMS is configured for ideal conditions, while the warehouse operates in controlled chaos.
Lesson: Design for exception handling first, not last.


2. Underestimating Master Data Complexity

Master data is treated as a one-time setup activity:

• Item attributes
• UOM conversions
• Storage dimensions
• Handling characteristics
• Often copied from legacy systems without validation.

Warehouse Reality:

• Item dimensions are outdated or estimated
• Catch weight items behave differently than defined
• Same SKU is handled differently by different teams
• Packaging changes without system updates
• This leads to:
• Putaway failures
• Slotting inefficiencies
• Pick task fragmentation
• Space utilization issues

The gap: Oracle WMS is only as intelligent as the data feeding it.
Lesson: Master data governance is an operational discipline, not a project checklist item.

3. RF Screen Design vs Operator Behavior

• RF screens are configured using standard flows
• Minimal customization to stay vanilla
• Assumption that users will follow screen prompts

Warehouse Reality:

• Operators memorize shortcuts
• Screens with too many validations slow down work
• Extra confirmation steps are bypassed mentally, if not systemically
• Temporary workers struggle with complex RF flows
• This results in:
• Workarounds
• Increased training dependency
• Resistance to system adoption

The gap: RF screens are designed for compliance, not usability.
Lesson: RF design must follow operator ergonomics, language simplicity, and task rhythm.

4. Wave Planning vs Operational Urgency

• Clean wave templates
• Defined cut-off times
• Planned allocation strategies
• System driven task interleaving

Warehouse Reality

• Last minute priority orders
• Partial inventory availability
• Manual picking for VIP customers
• Management pressure to just ship it
• Wave plans get canceled, split, or manually overridden.

The gap: Wave planning assumes predictability; warehouses live on urgency.
Lesson: Design flexible wave strategies and support real time task prioritization.

5. Integration Design That Ignores Timing

• Interfaces designed by entity
• Happy path message flows
• Clear ownership between WMS, ERP, TMS

Warehouse Reality

• Messages arrive late or out of sequence
• Partial failures block transactions
• Retry logic is unclear to operations
• Users wait without visibility
• This causes:
• Inventory mismatches
• Shipping delays
• Manual reconciliations

The gap: Integration design focuses on structure, not timing and recovery.
Lesson: Design integrations with operational monitoring, retries, and exception dashboards.

6. Reporting Designed for Management, Not Operations

• Standard Oracle reports
• Daily or weekly summaries
• KPI dashboards for leadership

Warehouse Reality

• Supervisors need live visibility
• Floor teams need actionable alerts
• Delays are identified too late

The gap: Reports explain what happened, not what needs action now.
Lesson: Operational reporting must be real time, role based, and decision oriented.

7. Change Management Is Treated as Training

• User training sessions
• SOP documents
• UAT sign-off

Warehouse Reality

• Long-tenured staff resist new logic
• Supervisors revert to old habits
• System is blamed for productivity dips

The gap: Training explains how, not why.
Lesson: Change management must align system logic with warehouse incentives and KPIs.

Oracle WMS Cloud is not a warehouse solution. It is a warehouse behavior management system.
The closer your design reflects real human behavior, physical constraints, and daily pressure, the smaller the gap becomes. And when that gap closes, Oracle WMS delivers exactly what it promises.

Thank You,

Pratip Chatterjee

Why middleware exists in an Oracle Cloud WMS landscape

Oracle Cloud WMS is robust within the warehouse, but it is not a comprehensive enterprise system. In almost every real implementation, WMS must exchange data with:

• Oracle Fusion ERP (Inventory, Order Management, Procurement, Manufacturing)
• TMS
• Planning systems
• Legacy ERPs
• 3PL systems
• Automation systems (WCS, MHE, conveyors, ASRS)
• External partners, vendors, customers

These systems do not speak the same language, follow the same timing, or have the same error-handling expectations.

Middleware sits in between and does five core jobs:

1. Transforms data
2. Orchestrates processes
3. Decouples systems
4. Manages errors and retries
5. Secures and governs integrations

Without middleware, WMS becomes tightly coupled and fragile. OIC is Oracle’s PaaS integration layer. It is not just an interface tool. It combines:

• Application Integration
• File-based Integration
• API Management (basic)
• B2B Trading Partner Management
• Visual orchestration
• Tracking and monitoring

Master Data Interfaces (ERP → WMS)

Interface	Direction	Trigger	Pattern	Notes
Item Master	ERP → WMS	Scheduled / On change	Asynchronous (API or File)	Large volume, rarely needs real-time
Item Categories	ERP → WMS	Scheduled	Asynchronous	Used for task rules, wave logic
UOM Conversions	ERP → WMS	Scheduled	Asynchronous	Critical for picking accuracy
Customers	ERP → WMS	Scheduled / On change	Asynchronous	Address normalization needed
Suppliers	ERP → WMS	Scheduled	Asynchronous	Mainly for receiving
Locations / Warehouses	ERP → WMS	One-time + delta	Asynchronous	Organization to facility mapping
Price Lists (if used)	ERP → WMS	Scheduled	Asynchronous	Often optional in WMS

Transactional Inbound Interfaces (ERP → WMS)

Interface	Direction	Trigger	Pattern	Notes
Sales Orders	ERP → WMS	Order release	Asynchronous (Event/API)	Near real-time preferred
Transfer Orders	ERP → WMS	TO creation	Asynchronous	Often high volume
Purchase Orders	ERP → WMS	PO approval	Asynchronous	Used for ASN matching
Work Orders (Manufacturing)	ERP → WMS	WO release	Asynchronous	If manufacturing integrated
ASNs	ERP / Supplier → WMS	ASN creation	File or API	File still common
Return Orders	ERP → WMS	RMA creation	Asynchronous	Requires inspection logic

    

Outbound Execution Interfaces (WMS → ERP)

Interface	Direction	Trigger	Pattern	Notes
Shipment Confirmation	WMS → ERP	Ship confirm	Asynchronous (Event/API)	Triggers invoicing
Inventory Transactions	WMS → ERP	Real-time / batch	Asynchronous	Adjustments, moves
Receiving Confirmation	WMS → ERP	Receipt completion	Asynchronous	PO receipt
Cycle Count Results	WMS → ERP	Count approval	Batch (File/API)	Often daily
Physical Inventory	WMS → ERP	PI close	Batch	Finance controlled
Returns Receipts	WMS → ERP	Receipt	Asynchronous	Impacts credit memo

Thank You,

Pratip Chatterjee