Manhattan Associates Warehouse Management System (WMS) is listed as a “leader” in Gartner’s recent Magic Quadrant for warehouse management systems.
I have brief (but INTENSE) experience with Manhattan WMS. One of the reasons it’s such a good WMS is that it keeps track of inventory throughout the warehouse. When a product is received, it’s “on dock”. When it is scanned for movement it’s in “transition”. When it’s scanned to a location it is “put away”. Every single scan is tracked as transactions within WMS PIX table. This detailed, transactional attention to every scan of a product allows companies using Manhattan’s WMS to experience very high inventory accuracy rates. At my company, we’ve experienced physical inventory accuracy of 100%!
We’re working on a tech project that requires us to integrate Manhattan’s WMS with another system (Epicor ERP). As a result, we need a complete understanding of the Manhattan WMS PIX table, which keeps track of all inventory movements. Now that I understand it, I’m sharing this obscure bit of tech here, for the benefit of the two other people in the world who may find this interesting (also the process of writing it out helps solidify my understanding).
Here are a few rules we were able to identify about data within the PIX Table:
- The PIX Table provides transactional records for the following ERP-like transactions:
- Inventory Sync (to ensure a balance between 2 systems) – these end up being adjustments as well.
- Adjustments always have a reason code. If there is a reason code in the PIX record, then the PIX transaction is an adjustment for the purposes of most ERP-like systems.
- Inventory “buckets” can fall into any number of categories, but the following are common when mapping to an ERP:
- Available (ie: available for orders)
- On Dock
- Quality Hold
- Work Orders
- Whenever the Adjustment or Transfer involves “available” inventory, the PIX transaction type/code will be either 300-01 or 300-04.
- Receipts are 606-03 transaction type/code.
- Returns are 606-04 transaction type/code.
- Adjustment/transfer transactions to/from any bucket except “available” use various 606-xx and 608-xx transactions. For example, our system uses the following transaction types: 606-02, 606-06, 606-13, and 608-12.
- PIX transactions can be single transactions or PAIRS. PAIRS are always transfers and normally involve moving inventory into or out of the “available” bucket. Since “available” is always represented by 300-01 or 300-04 and other adjustment/transfer “buckets” are represented by 606-xx or 608-xx, PAIR (2) transactions are required to move anything to/from available.
- PAIRS are linked by a transaction number and include a sequence number, to indicate which transaction within the PAIR should be processed first.
The PIX table also has many transactions that aren’t required for integration with outside systems (depending, of course, on how much detail you want to keep track of on the other system). For example, if the warehouse is moving product from one bin to another, our ERP doesn’t really care. We’ve configured our ERP to keep track of bucket ‘categories’, not actual bin locations.
We’ve found the best way to manage the logic is to build a logic table. Ours looks like this – except it contains over 100 lines. With this type of logic table, it is easy to activate new transactions and simply map them to the appropriate transaction in the ERP system. In our case, the Epicor ERP transaction is a web service, which I’ve documented here.