You know that feeling: with so many features in the JDA WMS, understanding which ones to avoid can feel almost as challenging as the implementation itself.

Does your HOST system require a single 945 EDI (ship confirm) transaction per order? What happens when it receives more? Lost productivity and revenue.

So, why was the order shipped multiple times?

It wasn’t. Unfortunately, you have fallen victim to standard functionality that, while sometimes helpful, can wreak havoc when not fully explored.

In short, the WMS allowed the order to be split and shipped separately. Let’s explore some of the ways that the WMS will allow this to happen.

Forklift working in warehouse facility.


When orders are being planned into shipments within the WMS, there are a multitude of rules evaluated to determine whether orders can be combined or should be split apart.

If you never want an order to be split or multiple orders to be combined, these rules are dead weight for you and while not adding value, they add risk.

A notorious rule is: maximum weight. It can bite most often when new items are ordered and the footprint has an overstated weight. If the order appears over-weight, it will be split into multiple shipments.

In order to mitigate this risk, we recommend not allowing newly introduced items to be putaway before their configuration is validated.  A standard workflow can be set up to enforce this requirement.


To be perfectly blunt, if your HOST system manages back orders, you never want the warehouse management system to attempt this as well.

The WMS can be used without a HOST system which means it knows how to manage back orders and will do so on an order by order basis if you tell it to.

If an order is setup to allow one or more of its lines to be back ordered, once its original shipment has been completed, the WMS will allow any unfulfilled line to be planned into another shipment.

By now, the one ship confirm (945) transaction allowed for that order has been generated and sent off to your HOST system. It has closed the order out and initiated the customer billing process.

Typically, the folks planning shipments within the WMS don’t have the visibility to determine that an order has already partially shipped and when planned again, a new shipment is born.

Ideally, when initially mapping your HOST and WMS transactions, the back order setting would be identified and your supply chain partner would be quick to show you why it should be avoided.


Using LTL carriers within the WMS provides much-needed flexibility. You don’t have to explicitly create move plans and tie shipments to trailers. You can focus on loading pallets onto the carrier’s trailer and they will most likely consolidate and shuffle things around within their network.

One aspect of that flexibility can bite you if you’re not careful. The WMS does not require the entire order to be loaded onto one trailer, it will happily split your shipment allowing you to put pallets on the next trailer or on another LTL carrier’s trailer for that matter.

When closing the trailer and attempting to dispatch, the WMS will ask the user if they want to proceed when an order is not fully loaded. The user has the option to stop the operation and review the situation, but if they don’t you now have an order split over two shipments and invoicing has been compromised.

All is not lost, this functionality is controlled by permissions and can quickly be removed from roles and user accounts. When disabled, the user closing an affected trailer will be denied and someone will need to load the remaining inventory or pull the offending inventory off the trailer.


These are just some of the more common pitfalls that plague new and existing implementations involving HOST systems that cannot accommodate multiple ship confirm transactions.

We love to share what we’ve learned and even more so, we love to hear how others have met similar challenges and triumphed.