Manhattan WMS PIX Logic

By | 2012/08/20

Manhattan Associates Warehouse Management System (WMS) is listed as a “leader” in Gartner’s recent Magic Quadrant for warehouse management systems.

Gartner's WMS Magic Quadrant

Gartner’s WMS Magic Quadrant

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:
    • Adjustments
    • Transfers
    • Receipts
    • Returns
    • 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
    • Damaged
    • Work Orders
    • Carton
    • Picked
    • Scrap/Transitional
  • 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.

PIX Logic Table

PIX Logic Table

48 thoughts on “Manhattan WMS PIX Logic

  1. Trevor North

    Hi

    I’m one of the two other people in the world interested in integration between Manhattan WMS and ERP systems (the Oracle Retail ERP system)
    I understood from a Manhattan consultant that the WMS system primarily uses flat files (either XML or Fixed Length).

    Oracle Retail uses a JMS messaging system with an XML payload for each transaction so it should be relatively straight forward to map the XML between WMS and Oracle Retail but I dont have any examples of the XML or fixed length flat files to work with.

    Did you look at using the flat files to do integration with or you integrate directly to your own custom table ?

    Regards
    Trevor

    Reply
    1. lhomsher Post author

      Hey Trevor – nice to meet one of the two (makes three of us total)!

      Your Manhattan consultant is correct – flat files. Our version doesn’t handle XML well (the parsing takes too much overhead), so we ended up creating triggers and stored procedures to monitor for changes and load the data into a data queue that’s picked up by the integration server (Websphere MB). So far, we’ve worked with just the PIX transactions — that’s where 90% of our transactions come from. We have a custom table that helps us identify which PIX transactions we “care about” and which to ignore.

      Are you planning to use an integration server, or are you connecting directly between the two systems?

      Let me know if you want any more details.

      Reply
  2. Trevor North

    Hi Lori

    The client has middleware to do the integrations but would be nice to see some actual flat files created by or loaded to manhattan to see what data is where.
    Are you able to post any of the files with an explanation of which fields are which e.g. PO Number etc.. ?

    Thanks

    Reply
    1. lhomsher Post author

      I can’t post actual Manhattan files, but I can share some of the PIX field mappings I’m using for the logic table. I’ll pull something together within the next few days and post.

      Reply
    2. lhomsher Post author

      Trevor – here are the primary fields and descriptions from the PIX table that were used to map receipts, adjustments, transfers, and returns to our ERP:
      PXTXTP: Transaction type \ these fields together identify
      PXTXCD: Transaction code / the type of transaction
      PXACCD: Action code
      PXCO: Represents company in our table
      PXDIV: Represents division
      PXINVA: Adjustment qty
      PXINAT: Adjustment type (Subtract or Add)
      PXSTYL: Item/Product code
      PXSFFX: Part of item/product code
      PXRSCD: reason code – used in returns
      PXCASN: unique LPN – useful for troubleshooting
      PXREF1, PXREF2, PXREF3: reference fields, unused in our environment
      PXREF4, PXREF5: reference fields used to determine which “bucket” to add/subtract from in ERP
      Note: we established the following buckets in Epicor: on dock, on hand, available, reserved, quality hold, damaged, unallocatable, work order.
      PXSHMT: Shipment number
      PXPON: PO number
      PXPOLN: PO line number
      PXCSRC: Cases received
      PXUNRC: Units received

      Reply
  3. Tim Sullivan

    Great stuff y’all. I’m working on a project to pull data from Manhattan’s WMS into SQL server for reporting. We are walking through the documentation trying to discern what data is where and what is best suited for our needs. Do y’all know of any good sources in the net for more Manhattan discussions like this one?

    Reply
    1. lhomsher Post author

      Tim – thanks for the comments! Unfortunately, I don’t know of any public Manhattan WMS forums, but I did come across this one (by Manhattan Associates): http://wmssupportforum.com/ExpertOpinions.aspx. I can tell you the PIX table seems to hold most of the transactional data, and it can be quite difficult to discern. To make matters more confusing, I think each implementation of Manhattan may use different fields, so my use may be different than yours. However, most of the standard transactions should be consistent (one would think).

      I succeeded in mapping these transactions from Manhattan to Epicor ERP web services: adjustments, receipts, and shipments. Let me know if you’d like more details on any of these transactions – I’d be happy to share my findings.

      Let me know if you come across anything helpful.

      Reply
  4. Ganesh

    Hi,

    I’m new to Manhattan WMS systems architecture. We are working on a Manhattan migration from V2008 to V2013. For the initial data conversion/migration from 2008 to 2013 we are planning to use ETL (Informatica).I heard that Manhattan uses XML formats . Should I be expecting to deal with XML source (V2008) and XML target (V2013)? Or can I directly extract from and load to the underlying DB tables.

    Thanks

    Reply
    1. lhomsher Post author

      Greetings! I think the answer depends on the particular implementation on each side. I have never worked through a migration of those specific WMS releases — our version was 2006 and we worked directly from the underlying DB tables. I would guess you can directly access the underlying DB tables, but your WMS support person or Manhattan Associates should be able to answer for your particular versions. I know a good Manhattan independent consultant, as well as a consulting company who has dozens of Manhattan experts, if you’d like to add someone like that to your project. Let me know if you’re interested and I can pass your contact info over to them.

      I’d be interested in knowing what solution you end up with, so feel free to post again in the future. Thanks and good luck with your project!

      Reply
      1. Ann

        Hi Lori,
        I am working on a team that is just starting the conversion of data from a db2 environment to Manhattan. We have always had two pieces of information that identifies an adjustment record. A transaction code that represent the type of adjustment….ie scrap, shrink or reclass..etc and a reason code – this represents why the adjustment was made. I noticed the two fields from your layout above of the PIX table –

        PIX table that were used to map receipts, adjustments, transfers, and returns to our ERP:
        PXTXTP: Transaction type \ these fields together identify
        PXTXCD: Transaction code / the type of transaction

        We have always had our two pieces of information on adjustment records to help with troubleshooting which manufacturing process caused the need for the adjustment.

        Would you mind explaining how you use these two fields for an adjustment record in your environment?

        Reply
        1. lhomsher Post author

          Hi Ann,
          I had to go back through some old notes to gather up more info on this. Here’s what I found. I hope it helps, but if you need more direction I can introduce you to an excellent Manhattan Associates consultant.

          We used PXTXTP 606 and PXTXCD 02 to indicate “inventory adjustments prior to putaway”. In our environment, this meant the inventory was “on dock” — meaning it’s been received but not yet putaway into a specific warehouse location.

          Unfortunately, I think Manhattan uses the 606 02 combination in other transactions as well, such as “directed putaway reserve location (release of PP lock code)”. This is an example of a PIX transaction pair, which involves 606 02 and 300 01. This combination takes inventory out of “on dock” and makes it available in the putaway location.

          Helpful? After being away from this for several years, this was a fun question to refamiliarize myself with this project, so thanks for your comments.

          Reply
  5. Manikanta

    HI i am new to Retail domain. Can you please let me know the full form of PIX (WMS PIX).

    Thankyou
    Manikanta

    Reply
    1. lhomsher Post author

      Hi Manikanta – the PIX format will depend on many variables, including your version of WMS, the transactions you’ve implemented, and any customization you’ve made.

      Here are the primary fields and descriptions from the PIX table we used to map receipts, adjustments, transfers, and returns to our ERP:
      PXTXTP: Transaction type \ these fields together identify
      PXTXCD: Transaction code / the type of transaction
      PXACCD: Action code
      PXCO: Represents company in our table
      PXDIV: Represents division
      PXINVA: Adjustment qty
      PXINAT: Adjustment type (Subtract or Add)
      PXSTYL: Item/Product code
      PXSFFX: Part of item/product code
      PXRSCD: reason code – used in returns
      PXCASN: unique LPN – useful for troubleshooting
      PXREF1, PXREF2, PXREF3: reference fields, unused in our environment
      PXREF4, PXREF5: reference fields used to determine which “bucket” to add/subtract from in ERP
      Note: we established the following buckets in Epicor: on dock, on hand, available, reserved, quality hold, damaged, unallocatable, work order.
      PXSHMT: Shipment number
      PXPON: PO number
      PXPOLN: PO line number
      PXCSRC: Cases received
      PXUNRC: Units received

      Reply
  6. CHETAN PATEL

    I AM CURRENTLY WORKING ON WMOS 2006 OPEN SYSTEM PLATFORM AND MY QUESTION IS IS THERE A WAY I CAN CHANGE THE PIX TRAN TO HOST OR IS THAT SOMETHING THAT REQUIRES MANHATTAN’S INVOLVEMENT ?

    BASICALLY WE ARE IN RETAIL ENV AND WITHIN WM THERE ARE PIX 300 01 08 AND 09 A (ADDITION) OR S (SUBTRACTION). THERE ARE TWO DIFFERENT FUNCTIONALITY THAT GENERATES THE SAME PIX TRAN AND I WANT TO CHANGE IF OPTION 1 THEN GENERATE PIX 300 XX XX ( XX IS NEW ACTION CODE OR SOMETHING) AND IF OPTION B THEN CREATE 300 XX XX. IS THIS DOABLE OR NEED MOD FOR THIS ?

    Reply
    1. lhomsher Post author

      I’m not certain but I think it may require a WMS modification. When our WMS was implemented, we used a consultant to help define these types of rules. Some could be handled through configuration, but others required modifications by Manhattan. ICCG is a company who specializes in Manhattan customizations and configuration. I haven’t talked with them in a few years, but they may be able to help you out.

      Here’s a bit more info about the specific PIX trans you mention…

      We were using 300 01 but not 08 and 09. Here’s my understanding of these numbers (as they applied to our implementation):

    2. 300 = PXTXTP = transaction type. In our environment, the 300 type correlated to one or both sides of a transfer pair (transferring inventory from/to something). For example, putaway jobs, transferring from one job to another, moving to/from quality hold or damaged or unallocatable, etc.
    3. 01 = PXTXCD = transaction code. All of our 300 transactions had either 01 or 04 in this field. Combined, the 300-01 and 300-04 transactions correlated to either Transfers or Adjustments on our ERP.
    4. PXACCD is the action code. I think this is where you are using 08 or 09. We used 05, 06, 14, 19, 20, 22, or wildcard. I didn’t need to use this field for my integration project, so it wasn’t part of the logic we built.
    5. Reply
  7. Manikanta

    Hi lhomsher,
    Thanks for the information. But can you please let me know ,what is the abbreviation of PIX.

    Thanks!
    Manikanta

    Reply
    1. lhomsher Post author

      This question made me dig through some fairly old notes, since this level of detail is long gone from the memory banks of my brain 🙂
      My notes say PIX is PXSTYL00. Here is the full list of touch-points we had between WMS and our order mgmt system (we were on version 2006 of WMS):
      1) Item Master(I5INPT00)
      2) ASN(I8INPT00 & I9INPT00) & PO
      3) Bill of Materials (IDINPT00)
      4) Work Orders (IOINPT00 & IPINPT00 & IQINPT00)
      5) Item Cross Reference (IRINPT00)
      6) Pick tickets (I1INPT00 & I2INPT00 & I3INPT00)
      7) PIX (PXSTYL00)
      8) Invoices or Ship Confirmations(O1OPUT00, O2OPUT00, 03OPUT00, O4OPUT00, O5OPUT00)
      9) Immediate Needs (Optional)(IAINPT00) – for cross dock process
      10) Vendor (IJINPT00)

      Reply
    2. Pramod

      Hi Manikanta,

      PIX stands for ‘Perpetual Inventory Transaction’

      Reply
  8. Florencia

    Hi Lori!
    I was looking for some information about Manhattan’s PIX messages and I found your article which is very interesting and useful.
    I´m working with middleware, and I need to do some integration using the type of message listed below:
    Header PIX:
    • TransactionType=603 TransactionCode=01 ActionCode= Null

    Detail PIX:
    • TransactionType=603 TransactionCode=02 ActionCode= Null

    Can you explain the meaning of this messages? I couldn’t find the definition in your other posts.

    According to the specification, the middleware has to join this messages (which Manhattan sends separately) and build a message to be sent to the destination.
    What I need to know is if Manhattan is able to join these messages before they are sent to the middleware. I think that with the table that you published above Manhattan has the information to do that, but I’m not sure cause I’ve never used it before. If it is possible, would it be hard to implement in Manhattan?

    Regards,
    Florencia

    Reply
    1. lhomsher Post author

      Florencia,
      We didn’t use the 603 transaction in our implementation, so I don’t know exactly what it represents in Manhattan (sorry). Regarding your question about joining the messages, we did this within our middleware (we were using IBM Message Broker). Our version of Manhattan (2006) did not provide a way of joining messages, so we had to build this logic into message broker as part of the process flow. One example of joined messages in our implementation: Transfer pairs, which were transaction types 606 and 300.

      Sorry I can’t be of more help regarding the 603 messages. You may need to contact a Manhattan Associates expert for more details. I can point you to some fee-based assistance, if you are interested.

      Reply
  9. Tim Sullivan

    Is there a way to “subscribe” to a thread on this site?

    Reply
    1. lhomsher Post author

      Not at this time, sorry. When I update the site, I’ll make sure to include that functionality.

      Reply
  10. RKnechtel

    Florencia,
    I’m in the middle of doing a Manhattan WMOS implementaion at my company. I have been assigned as “the PIX guy”. I’m finding PIX is a frustrating thing. We are using the 603 PIX you mention. Here is what I know:

    603-01 = ASN Receipt (Receipt header confirmation (ASN level)) <– This would be used to acknowledge/verify receipt of the item and to force close a PO.

    603-02 = ASN Receipt (Receipt variance – detail (ASN level)) <– This will show if an item receipt qty was more or less than the expected qty received.

    Now these work in combination with a PIX 100-02
    100-02 = iLPN Receipt <– used to process an individual pallet/skid receipt (one for each pallet/skid received)

    From what I can tell this is how it it seems the three receiving PIX work are like this:
    You get the PIX 100-02 (qty received for a iLPN – you get the ASN #, PO #, and PO line # with this PIX).
    Then once the -whole- ASN has been verified you get the PIX 603-01 (header record confirmation) saying "ok ASN # XXX has been received/verified",
    then you get the PIX 603-02 (variance PIX) that shows if you got an overage or shortage. You would get one of these per item that had an overage or shortage.

    Some of this depends on how your Manhattan system has been configured too.

    I hope this helps.

    Reply
    1. lhomsher Post author

      RKnechtel,
      Thanks for the additional info on the PIX 603 — and you have my sympathies for your “PIX guy” role. I can only imagine your frustrations…

      Your insight is extremely helpful — I suspect there aren’t very many PIX guys around (or they’re keeping their knowledge to themselves). Thanks again for taking the time to post… much appreciated!

      Reply
    2. doug

      There are well over 1000 PIXs you can configure and use withing WMi

      Reply
  11. Mukilarasan M

    Hi,

    I am currently working on Manhattan Migration project, I have experience in Redpraire WMS. Please any help me to understand the difference and source for initial understanding the Manhattan terms

    Reply
    1. lhomsher Post author

      Hi Mukilarasan M,
      Unfortunately, I’m not familiar with Redprairie WMS, so I cannot outline the differences for you. Manhattan has some resources available here: http://www.manh.com/resources. I also know of some Manhattan consultants, if you want to try that option just let me know.
      Sorry I can’t be of more help. Good luck to you!

      Reply
  12. David Andrew

    Hello,

    Thanks for all the info. I use MAHN 2013. When trying to change the pix exports frequency I am usually on the wrong node/listener to make the config change. Do you know how to switch the node/listener you are on besides playing log in log out Bingo to hopefully hit on the correct node?

    Reply
    1. lhomsher Post author

      David – I’m sorry, I don’t know anything about the listener. However, I do know an excellent Manhattan Assoc consultant. Would you like me to send his contact info via email?

      Reply
  13. Konrad C

    Hi Lori,
    I’m currently doing research on how to integrate our picking/replenishment automation system into our customer Manhattan based WMS system.
    Since you’ve been working with Manhattan WMS, do you know how to collect orders that are ready for picking and transfer requests for replenishment from such system?
    Can you point me to some documents or API descriptions that we could use?
    Any help is appreciated.

    Reply
    1. lhomsher Post author

      Hi Konrad,
      Unfortunately, I don’t have those details available to me at this time. However, I do know a couple of Manhattan WMS experts and would be happy to connect you if that helps. Let me know if it’s OK to provide your email to my contacts and I can arrange an introduction.

      Reply
      1. Konrad

        Hi Lori,
        Thanks for your reply, if you know such experts then I would appreciate if you could contact me with them, you can forward my company e-mail address.
        Many thanks,
        Konrad

        Reply
        1. lhomsher Post author

          Hi Konrad, I apologize for the delay. I sent my contact’s info to your email – he’s one of the BEST Manhattan Associates consultants. Hope he’s able to help. Best wishes!

          Reply
  14. Bill C.

    What is the field length of PXSTYL: Item/Product code in the PIX table?

    Reply
    1. lhomsher Post author

      Hi Bill,
      Unfortunately, I no longer work with Manhattan WMS and my old notes do not include details about field lengths. I know a great Manhattan consultant who can answer all of your questions. Let me know if you’d like me to introduce you.
      Best wishes,
      Lori

      Reply
  15. Alessandro

    Hi,
    I’m new in PKMS implementation.
    We need to integrate PKMS with SAP FMS.

    We have a scenario in which we need to manage over/under delivery in case of stock transfer order.
    We need to receive just one pix from PKMS, since we want to post the Good receipt at the end of verification process and need to post the whole order (instead of receiving partial good receipt for each carton scanned). That is due to our quality management system.

    We are thinking to use pix 603 to identify a GR with an over/under delivery, but the architecture board suggested us to use pix 606.

    Someone can explain me the difference between pix 603 and 606?

    it will be very helpful.

    Thank you!

    Reply
    1. lhomsher Post author

      Hi Alessandro,
      First a disclaimer – I do not actively work with Manhattan WMS at this time so this feedback is simply based on my past understanding, which may be dated and may not apply to your implementation.

      We used the pix 606 for receipt-related inventory transactions, such as moving inventory onto the dock, directed putaway, damages and quality holds. In most of these examples, the 606 was part of a pair that also included the 300 transaction. For example, moving inventory from ‘on dock’ to the putaway location would generate a 606-02 and a 300-01 — one transaction removes from ‘on dock’ and the other adds to the putaway loc.
      We also used 606 for general inventory adjustments, transfers, and returns.

      According to my notes, we used the 603 transaction for closing out items on a PO during receiving. Our integration project didn’t include any other use of the 603, but that may simply indicate our ERP didn’t care about the other 603 transactions. Here is the list of 603’s I was able to dig up.

      603 01 Receipt Header Confirmation
      603 02 Receipt Variance (Detail)
      603 03 Receipt Header Confirmation (Shipment/PO Level)
      603 04 Receipt Variance (Shipment/PO Level)
      603 05 Keyrec Confirmation (Shipment Level)
      603 06 Keyrec Variance (Shipment Level)
      603 07 Keyrec Confirmation (Shipment/PO Level)
      603 08 Keyrec Variance (Shipment/PO Level)
      603 09 Vendor ASN Header Confirmation (Shipment Level)
      603 10 Vendor ASN Receipt Variance (Shipment Level)
      603 11 Vendor ASN Header Confirmation (PO/Shipment Level)
      603 12 Vendor ASN Receipt Variance (Shipment/ PO Level)
      603 13 Return ASN Header Confirmation (Shipment Level)
      603 14 Return ASN Receipt Variance (Shipment Level)

      I suspect the use of transactions can vary depending on your specific implementation.
      Best wishes for a successful project!

      Reply
  16. SAJ

    Hi
    I bumped into this forum searching for information on can manhattan retain the original goods receipt date that was captured in legacy wms? as we are planning to migrate it to SCALE and what I hear that it’s not possible to retain the old GR date and once migrated into SCALE the inventory shall have a new GR date the date of migration to SCALE.

    Any help to clarify on above would be great. Am looking for option to retain the old GR date.

    Reply
    1. lhomsher Post author

      If I understand it correctly, it sounds like you are coverting into Manhattan Scale wms and are unable to retain the original receipt date? That sounds odd, since I think most companies would want to keep the original date intact. I’m sorry I can’t provide more guidance, but I can connect you with a great Manhattan consultant if you need further assistance.

      Reply
  17. arun

    what does this mean PXTXTP = ‘601’ AND PXTXCD = ‘002’ AND PXSHMT = ORCHESTRATE.PXREF1
    in pix

    Reply
  18. arun

    what does this mean PXTXTP = ‘601’ AND PXTXCD = ‘002’ AND PXSHMT = PXREF1 in pix
    Kindly help

    Reply
    1. lhomsher Post author

      We didn’t use PXTXTP 601. My notes show no reference to 601 being paired with PXTXCD 002, but this may not mean anything. Here’s what my notes show for PXTXTP 601:
      601 X X = Pickticket Status
      601 001 Pickticket Status Change

      PXSHMT is typically the shipment number and PXREF1 is a reference field. If you show both of these values being equal, I’d guess it is the shipment number for the transaction.

      I’m not sure this is much help. Best wishes to you!

      Reply
  19. Rahman

    Hi,

    I worked on WMS scale in my last project as a QA tester. May I know what is the relation or differences between PKMS and WMS and WMOS and WMS.

    I would be really helpful if some one could explain in this forum.

    Regards
    Rahman

    Reply
    1. doug

      PKMS was the original name. It has changed over the years from PKMS to WMS to now WMi. WMI represents it run and an AS400 i-series machine. WMos is Manhattan’s open systems . Hope this was what you wanted.

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.