Every WMS implementation needs to deal with interfaces. This includes host interfaces, e.g. interfacing with SAP, Oracle, JDE, etc. and also to the automation equipment. Many times the project plan calls for these tasks at the wrong time and that can lead to overall delays and rework. Timing this activity correctly is critical to the overall success of the project.
Many times the customer’s past experience with interfacing influences their decision to start interface discussion prematurely — but such proactive approach is not helpful. So one thing we need to establish upfront is that JDA/BY will be able to handle any type of interface requirement. If you can send it RP can process it! So do not lose your sleep over it.
Abstract is the Key
We need to understand that the actual project is WMS implementation and not the interfaces. Interfaces need to be understood abstractly as just another mechanism to provide data. Nothing more and nothing less. So once it is established that JDA/BY can do any type of interface work then we need to focus on WMS solution summary and not interfaces.
Proper place for Interfaces in the Project Plan
At a very high level, the project plan should be as follows:
- Key customer resources get rained on the solution set.
- Software is installed in development environment
- A Proof of Concept exercise is done with standard solution: This highlights the interfaces
- A solution summary is developed: Interfaces are called out here
- Interface Discussion
A completely wrong approach will put the interface discussion ahead in the plan. I have seen instances where the interface discussion is done even before the software is installed. Such meetings are not very productive because the customer’s resources do not understand JDA/BY and the implementer does not understand customer requirements — so as a result a sub-par interface diagram is created.
Host Interface Matrix
Host interfaces are simply a mechanism to provide data to JDA/BY . It is not different from manual data entry from that aspect. Solution summary should be firmly established before this discussion starts. One way to approach this is that the customer could simply take screenshots from RedPrairie client and highlight the data that they expect to come from a host system — that will be easier than going through spreadsheets with cryptic column names. Any JDA/BY implementer should be able to take such a document and convert that to an actual interface.
Similarly, for data going to host, the customer SME (Subject Matter Expert) can highlight the data that they would expect to populate the host system.
MHE Interfaces
MHE (Material Handling Equipment) interfaces are no exception. The full solution summary should first describe the use cases in terms of RF flows. This should be done even if majority of the picking is done by MHE. This provides a baseline for testing. Once this is done, MHE use cases should be defined and an equivalence diagram should be created. This diagram will describe how MHE picking, for example, is equivalent to RF picking. A diagram like this will form the basis for MHE interface discussions. This will also help during development and unit testing phases.
MHE Emulator
Ability to emulate MHE messages is key to a successful implementation. Unfortunately, many MHE systems do not provide such capability. This becomes a challenge if MHE system communicates over sockets. A simple emulator can be created by RedPrairie integrator where you can create a system that represents the host system and listens for messages. You can verify MHE protocol in this way. You can use similar techniques to send completion messages back to WMS.
When sending data to MHE, typical triggering point is the pick release process. pckwrk table(s) should form the basis for data that is sent to MHE for picking. Custom columns can be added here to incorporate any unique concepts but this should generally be the starting point.
The transactions back from MHE will typically call a flavor of “move inventory”. If we have an equivalence of these use cases to RF screens then this can be a relatively simple exercise.
Another approach may be to have a folder with raw messages and create a simple groovy command that sends data from this folder to the WMS. You can also use “telnet” to send data.
Interesting WMS Concepts for MHE
RedPrairie WMS provides several concepts that can form the basis for providing data to MHE at proper level. Often I have seen that new concepts are introduced in this regard which adds needless complexity and testing headaches:
- Idea of picking cartonization
- Idea of lists that can group cartonized cartons
- Non cartonized picking directly to a tote
- Pick Release process and associated standard triggering points like “register picks released”
- Replenishment Configuration concepts
For most picking systems, e.g. Pick To Light, the MHE system will have a location table with similar locations as JDA/BY. Inventory levels in JDA/BY will be assumed to be accurate as well. In such systems orders are allocated within RedPrairie and at pick release time we send data to the MHE system. RJDA/BY concepts are a “shoe in”. By the time pick release is done — we know exactly which carton needs inventory from which MHE locations so appropriate messages can be constructed. When MHE system completes a pick — some systems will tell exactly what was picked while some will simply say “this tote is picked”. In either case — processing of such a message should simply call “move inventory”. Sometimes implementer would make this interface needlessly complicated by a false assumption that “move inventory will be too expensive”. This unproven and untested notion will then translate to new concepts and make the whole implementation overly complicated. It is always best to not over-engineer this step and simply pick the inventory in JDA/BY when it is picked in MHE.
MHE system from this point on may have multiple stops, e.g. audit station, weight station, etc. Such locations may be handled as simple P&D locations or hops. In either case — if MHE system can send a message in these cases — that message should translate into a “move inventory” call. Refer to this article if you have a use case where certain percentage of totes need to be audited.
Every implementation may be slightly different but always have the following goals:
- Do not invent new concepts
- Always equate to corresponding RF use cases
Summary
Interfacing capabilities are a strong suit for JDA/BY WMS systems. Do not let some bad past experiences influence the project plan too much. Considering interfaces as just another type of data entry method simplifies the project a great deal. Based on the type of implementation — you may need significant hours, but those should not translate to significant complexity. Proper abstraction that preserves the core JDA/BY concepts will go a long way.
Originally published on saadwmsblog.blogspot.com
