Different UOM being submitted than what shows in IC11

 4 Replies
 0 Subscribed to this topic
 38 Subscribed to this forum
Sort:
Author
Messages
Bev Edwards
Veteran Member
Posts: 366
Veteran Member
    When I look at the item in PO28, the uom is PK, which is correct, however somehow, BX was submitted on the PO.

    We're thinking that since the vendor changed the uom from BX to PK, we perhaps should be changing the IC12.

    Does anyone know if that's the correct step to follow in order for the correct UOM to be pulled from PO25.6? Does the IC12 have to have a Trasaction default value in order for the correct uom to be submitted?? 

    I attached some screen shots of this particular item setup. 

     Bev

    Attachments
    Red
    Veteran Member
    Posts: 87
    Veteran Member
      Bev,
      Going back to your previous topic, for a moment, if the UOM on the template was not identified on the Agreement, that would explain why it was dropping to Last Cost.

      Back to this topic, you could build both UOMs on the Agreement Line, assuming they are both valid for the supplier/contract. You have the option of using the Default Source UOM on the IC12, but if you select that option ALL ORDERS to the supplier through that IC02/IC12 will need to conform to that UOM. (Inventory/pick ticket requests use the Default Transaction UOM.) If you have templates and Par Locations that order in multiple UOMs, then you would want to leave the Default Source UOM blank. Really, once you asses the set up of your Templates and Par Locations, the real sticking point is any end-users that may order via Express Order/RQ10 or PO20. If the Default Source UOM is set, it will not allow them to release the document until the selected UOM conforms. If you leave the field blanks and the user leaves the field blank, the system will determine what it believes to be the most appropriate UOM through the processes it uses to determine the Agreement association (Agreement Type/Priority/Unit Cost/Agreement Reference). All other things being equal, the system will select the first line/UOM that was entered on the Agreement.

      Hope this makes sense.
      Red
      Learn from the Past. Prepare for the Future. Act in the Present.
      Bev Edwards
      Veteran Member
      Posts: 366
      Veteran Member
        Hi Red!
        The uom was defined, but was originally set to BX. I changed that to EA, however at the time, I was unable to change the From Location for that item from HOSP to LUM on the Line Detail tab in PO15.

        I finally did change it from HOSP to LUM, but at the moment, I'm drawing a blank as to how I accomplished this. At any rate, it didn't seem to have an effect as the price is still continuing to default incorrectly. I just sent a post to that topic a few mins ago with an update on what I just discovered.

        I'm re-reading your post in a few to wrap my head around what you explained. Sounds like once I understand it, I need to share with my colleague as well.

        Thank you!
        Bev Edwards
        Veteran Member
        Posts: 366
        Veteran Member
          Red,
            Just so I understand (at least one piece), if the IC12 has a Transaction default UOM, an item cannot be set up on multiple agreements with 2 different uom's, correct?

          For instance, we have many items that are ordered by the CA, but are also ordered by a LUM uom. CA would reside on one agreement and all LUM items would reside on our O & M LUM agreement. Therefore, all of these particular items would NOT have a Transaction Default uom on the IC12?
          Red
          Veteran Member
          Posts: 87
          Veteran Member
            Bev,
            Technically, the Default Transaction UOM is intended to govern the UOM that a Requester places on an inventory item. The Default Source UOM determines the UOM on Purchase Orders to the Supplier. That's the theory. So a single item in a single IC Location could issue product out in the EA (Default Transaction UOM) and replenish from the supplier by the CA (Default Source UOM). Early in version 8, when we first tested the functionality, we found that the Transaction UOM would inform the UOM on Purchase Orders if the Source UOM was left blank. It seems to me that this was fixed before we moved forward, but it may still be an issue without the correct patch.

            To go back to your question, the base answer is that the Default Transaction UOM should have no bearing on the Agreement. And the Agreement can hold multiple UOMs for an item. We actually campaigned for the Default Source UOM functionality in order to be able to populate agreements with all valid UOMs. For example, one IC Location may order the item only by the CA (as dictated by the Default Source UOM), but a different IC Location wants to order the item in an EA (as set by its Default Source UOM). Both locations could be participants to the same agreement; indeed, it would need to have both UOMs built on it.

            Getting clearer?
            Red
            Learn from the Past. Prepare for the Future. Act in the Present.