blueyonder-wms

Classifies Blue Yonder WMS warehouse operations by risk and gates consequential inventory actions.

Updated Aug 17, 2026
One-click install
npx skills add https://github.com/MetaFloor-AI/metafloor-scm-plugin-openai --skill blueyonder-wms-metafloor-ai
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: blueyonder-wms
Source: https://github.com/MetaFloor-AI/metafloor-scm-plugin-openai/tree/main/skills/platforms/warehouse/blueyonder-wms
Command: npx skills add https://github.com/MetaFloor-AI/metafloor-scm-plugin-openai --skill blueyonder-wms-metafloor-ai

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Operating Blue Yonder WMS (RedPrairie / JDA / Luminate) involves actions that move physical stock, overwrite on-hand inventory, or re-shape warehouse-wide behavior, and a wrong move causes real losses, phantom inventory, or mis-shipped goods. This Skill gives an AI agent the operator judgment to classify each warehouse action as read, reversible write, committing write, or destructive, and to pause consequential ones for human approval. ## Core Features & Use Cases - Risk-classified operation matrix: Maps every Blue Yonder WMS operation family (wave release, task confirmation, inventory adjustment, cycle count, ship confirm, policy and MOCA changes) to a gating level with named-approver rules for destructive actions. - Object and state model: Explains on-hand vs available, ILPN/OLPN nesting, allocation, wave vs waveless flow, and the RF-directed task lifecycle so the agent reasons about state rather than nouns. - Gotchas and recovery playbooks: Documents 24 causal failure chains (short picks, double-posted confirmations, stale on-hand, hold releases) plus recovery tables showing what can and cannot be undone. - Use Case: When asked to adjust inventory to match the ERP, the agent recognizes this as a destructive direct write to the book, requires a physical re-count and named approver, and refuses to force-match a host discrepancy. ## Quick Start Ask the agent how to safely release a wave or post an inventory adjustment in Blue Yonder WMS and it will classify the action, state the blast radius, and gate it appropriately.

Frequently Asked Questions about blueyonder-wms

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I safely release a wave in Blue Yonder WMS?

Wave release is a committing write: it allocates on-hand to every line and generates task work, starving the available pool for other orders. Read on-hand first, confirm what the release will consume, and gate it with human approval before releasing.

What is the difference between on-hand and available inventory in Blue Yonder?

Available equals on-hand minus allocated minus non-available statuses like hold, QC, and damage. Raw on-hand includes stock that is reserved or unusable, so promising against it over-commits inventory and causes short picks.

Blue Yonder WMS vs Manhattan WMS for warehouse execution?

Both share an object model of LPNs, waves, tasks, and allocation, but Blue Yonder is policy- and MOCA-driven with an ILPN/OLPN split, while Manhattan uses a single generic LPN and has no MOCA layer. Do not apply Blue Yonder policy logic to a Manhattan site.

Why did a retried pick confirmation double-post inventory?

A network or RF retry on a pick confirm, ship confirm, or adjustment can post the move twice, creating phantom inventory or a double goods issue. Before retrying, re-read the state to check whether the first call already posted.

When should I not adjust WMS inventory to match the ERP?

Never adjust WMS on-hand purely to force a match with the host, because a quantity delta is usually an in-flight transaction not yet posted, especially on legacy batch interfaces. Reconcile the transaction stream instead, or you write a phantom loss or gain on both sides.

Is a MOCA command safe to run directly in Blue Yonder?

A read-only MOCA query is safe, but a hand-run MOCA command that writes inventory, adjusts on-hand, or forces a task bypasses RF-flow validations and is treated as destructive. If you cannot confirm a command is read-only, gate it as destructive.