Monday, 13 April 2026

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

Tuesday, 27 January 2026

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

Sunday, 11 January 2026

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





Friday, 26 December 2025

A Guide to Quality Improvement - Six Sigma White Belt

Imagine you run a small coffee shop, and customers frequently complain about long waiting times during the morning rush. Some days are fine, but other days, people leave frustrated. This inconsistency is costing you money and reputation. Six Sigma is a methodology that helps solve exactly these kinds of problems by reducing variation and defects in any process.

The White Belt is your first step into the Six Sigma world, a foundational level that introduces you to the basic concepts and tools used to improve quality and efficiency in organizations.

What is Six Sigma?

Six Sigma is a data-driven approach to eliminating defects and improving processes. The term "sigma" refers to standard deviation in statistics. A process operating at Six Sigma produces only 3.4 defects per million opportunities, essentially near-perfect quality.

Real-life example: Amazon's delivery system aims for Six Sigma quality. When you order a product, you expect it to arrive on time, undamaged, and exactly what you ordered. Amazon constantly measures and improves every step of their delivery process to minimize errors.

The Five Core Principles of Six Sigma

1. Focus on the Customer

Everything starts with understanding what the customer values. In Six Sigma, we identify "Critical to Quality" (CTQ) characteristics, features that directly impact customer satisfaction.

Example: In our coffee shop scenario, customers value quick service (under 5 minutes), correct orders, and friendly staff. These are your CTQs.

2. Measure the Value Stream

Map out every step of your process and identify where value is added and where waste occurs.

Example: At the coffee shop, the process includes: taking orders → preparing drinks → payment → serving. By timing each step, you discover that 60% of delays happen during drink preparation because only one machine is used for all beverages.

3. Get Rid of Waste

Eliminate steps that don't add value to the customer.

Example: You notice baristas walk back and forth to the storage room multiple times per shift. Reorganizing supplies within arm's reach eliminates this wasted motion and saves 15 minutes per person daily.

4. Keep the Ball Rolling

Everyone in the organization must participate in improvement efforts. Communication and collaboration are essential.

Example: Weekly team meetings where baristas share observations about bottlenecks create a culture where everyone contributes ideas for improvement.

5. Be Flexible and Responsive

Processes must adapt to changing customer needs and market conditions while maintaining quality.

Example: When you notice a surge in mobile orders, you add a dedicated station for online orders instead of mixing them with walk-in customers.

DMAIC: The Six Sigma Roadmap

DMAIC is the structured problem-solving approach used in Six Sigma projects. Think of it as a recipe for solving any process problem.

Define

Clearly state the problem, project goals, and customer requirements.

Coffee shop example: Problem statement is "Customer wait time during morning rush (7-9 AM) averages 8 minutes, but customers expect service within 5 minutes. This results in 15-20 customers leaving daily."

Measure

Collect data to understand current performance and establish a baseline.

Coffee shop example: For two weeks, you track the exact time for each order from placement to delivery. You discover that average wait time is actually 8.5 minutes, with peak times reaching 12 minutes. You also measure how many drinks each barista makes per hour.

Analyze

Identify the root causes of defects or problems using data analysis tools.

Coffee shop example: Analysis reveals that 70% of delays occur because the espresso machine can only make two shots at a time, and 80% of orders contain espresso drinks. The root cause isn't staff speed, it's equipment capacity.

Improve

Develop and implement solutions to address root causes.

Coffee shop example: You invest in a second espresso machine and reorganize the workspace so two baristas can work simultaneously without bumping into each other. You also implement a system where simple drinks (black coffee, tea) are handled separately.

Control

Monitor the improved process to ensure gains are sustained over time.

Coffee shop example: You continue tracking wait times weekly and create a dashboard visible to all staff. You also establish a standard operating procedure so new employees follow the improved process. After one month, average wait time drops to 4.5 minutes, and customer complaints decrease by 85%.

Key Six Sigma Terminology

Defect: Anything that doesn't meet customer requirements. In our coffee shop, a defect could be wrong order, cold coffee, or wait time over 5 minutes.

Variation: Inconsistency in process outcomes. If your coffee tastes different each time, that's variation.

Process: A series of steps that transform inputs into outputs. Making a latte is a process.

Stakeholder: Anyone affected by the process or project, including customers, employees, and managers.

Baseline: Current performance level before improvements. Our coffee shop baseline was 8.5 minutes average wait time.

Seven Types of Waste (DOWNTIME)

Six Sigma teaches us to identify and eliminate waste. Remember the acronym DOWNTIME:

Defects: Products or services that don't meet requirements. Example: A cappuccino made with whole milk when customer ordered skim milk.

Overproduction: Making more than immediately needed. Example: Brewing full pots of specialty coffee that sit and get stale.

Waiting: Idle time when nothing productive happens. Example: Barista waiting for espresso shots to finish.

Non-utilized talent: Not using people's skills effectively. Example: Your experienced barista spending most time on cash register instead of training others.

Transportation: Unnecessary movement of materials. Example: Storing cups in the back room requiring constant trips to restock.

Inventory: Excess supplies taking up space and money. Example: Ordering too many seasonal syrups that expire before use.

Motion: Unnecessary movement by people. Example: Barista walking 20 steps to reach milk that could be stored closer.

Excess processing: Doing more than customer requires. Example: Creating elaborate latte art when customers just want their coffee quickly during rush hour.

Basic Six Sigma Tools for White Belts

1. Process Mapping

Draw a flowchart showing every step in your process. This visual representation helps everyone understand the workflow and identify improvement opportunities.

Coffee shop process map: Customer enters → Joins queue → Places order → Payment processed → Order ticket printed → Barista reads ticket → Gathers ingredients → Prepares drink → Calls customer name → Customer receives drink

2. Cause and Effect Diagram (Fishbone Diagram)

This tool helps brainstorm all possible causes of a problem, organized into categories like People, Process, Equipment, Materials, and Environment.

Example: For slow service, causes might include undertrained staff (People), complicated ordering system (Process), old espresso machine (Equipment), poor ingredient organization (Materials), and cramped workspace (Environment).

3. Pareto Chart

This 80/20 rule tool helps prioritize which problems to solve first by showing that typically 80% of problems come from 20% of causes.

Example: After tracking complaints for a month, you find that 75% of customer dissatisfaction comes from just two issues: wait times and order accuracy. Focus your improvement efforts here first.

4. Check Sheets

Simple data collection forms to track how often specific events occur.

Example: Create a tally sheet where staff mark each time wait time exceeds 5 minutes, noting the time of day and suspected cause.

The Benefits of Six Sigma

Cost Reduction: Fewer defects mean less wasted materials and time. Our coffee shop reduced wasted ingredients by 30% after improving order accuracy.

Customer Satisfaction: Faster, more reliable service creates happy customers who return and recommend you to others.

Employee Engagement: When staff participate in improvements, they feel valued and take ownership of quality.

Competitive Advantage: Organizations using Six Sigma can offer better quality at lower prices than competitors.

Data-Driven Decisions: Instead of guessing what's wrong, you use facts and measurements to guide improvements.

Getting Started with Six Sigma as a White Belt

As a White Belt, you don't need to lead complex projects. Your role is to understand the basics and support improvement initiatives in your workplace.

What you can do:

  • Recognize waste and variation in your daily work
  • Participate in team improvement discussions
  • Collect data accurately when asked
  • Follow standardized procedures
  • Suggest small improvements based on your observations
  • Understand how your work impacts customers

Real workplace example: A hospital receptionist with White Belt training noticed patients often filled out the same information on multiple forms. She suggested creating one comprehensive intake form that could be photocopied for different departments. This simple change saved each patient 10 minutes and reduced errors from transcription.

Common Misconceptions

Myth 1: Six Sigma is only for manufacturing. Reality: Six Sigma works in healthcare, finance, education, retail, government, anywhere there are processes to improve.

Myth 2: You need advanced statistics knowledge. Reality: White Belts need only basic understanding. Advanced analysis is done by Green and Black Belts.

Myth 3: Six Sigma eliminates all defects immediately. Reality: It's a journey of continuous improvement. Results take time and sustained effort.

Myth 4: Six Sigma is just common sense. Reality: While some concepts seem obvious, Six Sigma provides structure, discipline, and tools to actually implement improvements that stick.

Conclusion

Six Sigma White Belt knowledge empowers you to see your work through a quality improvement lens. Whether you're making coffee, processing insurance claims, teaching students, or assembling products, the principles remain the same: understand customer needs, measure current performance, identify root causes, implement improvements, and sustain results.

The coffee shop example we followed throughout this article demonstrates that Six Sigma isn't complicated theory, it's practical problem-solving. By reducing wait times from 8.5 to 4.5 minutes, the shop served more customers, reduced complaints, increased revenue, and created a better work environment for staff.

Your journey in Six Sigma starts with awareness. Begin noticing waste, variation, and improvement opportunities in your daily work. Ask "why" when problems occur. Collect simple data. Share observations with your team. These small actions create the foundation for larger improvements.

Remember, every Six Sigma Black Belt started as a White Belt. The expertise comes from applying these basic principles consistently over time. Quality improvement isn't a destination, it's a mindset that turns everyday challenges into opportunities for excellence.


Thank You,
Pratip Chatterjee

Wednesday, 24 December 2025

Overview of Oracle Procurement Modules

Oracle EBS Procurement consists of several integrated modules.

Core Modules

  • iProcurement - Self-service requisitioning
  • Purchasing - Purchase Orders, RFQs, Quotations
  • iSupplier Portal - Supplier collaboration
  • Sourcing - Strategic sourcing and negotiations
  • Supplier Lifecycle Management (SLM) - Supplier qualification and management

Supporting Modules:

  • Payables - Invoice processing
  • Inventory - Stock management
  • Receiving - Goods receipt

Setup Components

Financial Options:

Setup Navigation: Purchasing > Setup > Organizations > Financial Options

Key Setups:

  1. Operating Unit - Legal entity for transaction processing
  2. Business Group - HR organization
  3. Inventory Organization - Warehouse/stock location
  4. Purchasing Options - Control purchasing behavior

Example:

  • Operating Unit: US Operating Unit
  • Inventory Org: Seattle Warehouse
  • Set "Use Approval" = Yes to enable approval workflows

Document Types & Numbering

Standard Document Types:

  • Standard PO - Regular purchases
  • Planned PO - Blanket with scheduled releases
  • Blanket PO - Agreement without quantities
  • Contract Agreement - Terms only, no items

Example Setup:

Document Type: Standard Purchase Order
Numbering: Manual/Automatic
Format: PO-2025-####
Security Level: Hierarchy/Public/Private

Purchase Requisition (PR)

Creation Methods:

  1. Manual entry in Purchasing
  2. iProcurement self-service
  3. Min-Max planning
  4. Reorder point planning
  5. MRP/Planning suggestions

Requisition Types:

  • Internal (stock items)
  • Purchase (external procurement)

 

Purchase Order (PO)

PO Creation Process:

Method 1: Auto Create from Requisition

Navigation: Purchasing > Purchase Orders > AutoCreate
- Select approved requisitions
- Group by: Supplier, Site, Buyer
- Create PO automatically

Method 2: Manual PO Creation

Navigation: Purchasing > Purchase Orders > Purchase Orders

PO Header Information:

  • Supplier Name and Site
  • Buyer
  • Currency
  • Payment Terms (Net 30, 2/10 Net 30)
  • FOB (Free on Board)
  • Freight Terms

PO Line Details:

  • Item/Description
  • Category
  • Quantity
  • Unit Price
  • Need-by Date
  • Destination Type (Inventory/Expense)
  • Charge Account

PO Shipment:

  • Ship-to Location
  • Requestor
  • Receipt Routing (Standard/Inspection/Direct Delivery)

PO Approval Process

Approval Hierarchy:

  • Position-based
  • Supervisor-based
  • Amount-based

Approval Statuses:

  • Incomplete
  • Approved
  • In Process (awaiting approval)
  • Requires Reapproval

Receipt Types

Standard Receipt:

  • Against PO
  • Direct delivery to inventory
  • Three-way match (PO-Receipt-Invoice)

Inspection Receipt:

  • Quality check required
  • Accept/Reject decision
  • Move to inventory after acceptance

Receipt Routing

1. Standard Routing (2-Step): Receive → Deliver

2. Inspection Routing (3-Step): Receive → Inspect → Deliver/Return

3. Direct Delivery (1-Step): Direct to final destination (expense)

Return to Supplier/Vendor

Reasons for Returns:

  • Defective items
  • Wrong items shipped
  • Damaged in transit
  • Over-shipment

Thank You,
Pratip Chatterjee

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, a...