Self Service Procurement

Get Involved. Join the Conversation.


    Work Order Subtype usage in TAB Derivation for Requisitions
    Topic posted February 28, 2019 by AshokBlack Diamond: 60,000+ Points, tagged How-To, Requisition Processing, Requisition Web Services 
    111 Views, 3 Comments
    Work Order Subtype usage in TAB Derivation for Requisitions
    How to use Work Order Subtype in TAB derivation for Requistions

    Support / Customers

    I am writing this article based on a recent customer issue that surfaced a need to communicate this behavior.

    Business Problem:

    The customer uses work order sub types to create work orders. In the recent 19A integration of Work Orders with Procurement, the customer creates a requisition using a work order destination type. The customer had also defined charge account derivation mapping sets using the work order sub type. However, the charge account on the requisition was not derived using the mapping set definition.


    Work order sub type is used in TAB derivation rules to derive charge account. But the value for the sub type has to be captured in the transaction in question. In other words, when creating the requisition, there must be a value passed for this attribute for the application to then derive the charge account. 


    1. Currently, the attribute Work Order sub type is only used in deriving charge account as part of our Purchase Requisitions Web Service when creating an externally managed requisition for an OSP (Outside Service Processing) item

    2. When the user creates a work order based requisition through Self Service Procurement UIs, the work order sub type is not captured either explicitly or defaulted and so nothing is passed for charge account derivation. In other words, in the manual flows, sub type will not be used for charge account derivations

    3. Even in the OSP scenario outlined in 1. above, please note that you must pass the value of the CODE for the sub type and not the sub type name. (See attached screenshot). This is another thing to take note of that will help you derive the charge account based on this mapping set.

    4. There is an enhancement recorded for the scenario outlined in 2. above, but there are no timelines or plans at this point to design and implement this. If you require this to be supported, please log an idea in the Idea forum as per the process we follow for any enhancements that you wish to bring to our notice.



    • Ashok
    • Ed van Kessel

      We are experiencing the same issue with Option 2.  The enhancement request is BugDB:29357655 and we are working to get this resolved immediately

    • Ashok


      I actually based this article on that triage. At this point though, it is an enhancement and not a bug. There are no timelines at this point for when this can be achieved. I just wanted to let you know.