Self Service Procurement

Get Involved. Join the Conversation.


    Part 2: Inventory Organizations, Deliver-to Locations,...
    Topic posted November 17, 2018 by AshokBlack Diamond: 60,000+ Points, last edited November 19, 2018, tagged Create Requisition, How-To, Requisition Processing 
    146 Views, 2 Comments
    Part 2: Inventory Organizations, Deliver-to Locations, Subinventories: Interactions in Self Service Procurement Flows
    An overview of how inventory organizations, deliver-to locations, subinventories interact in Self Service Procurement transaction flows

    In Part 1, we reviewed the various entities in play and how they are interlinked here:

    In this part, we will examine impact on creating and editing requisitions with these entities and associations.

    1. Shopping for an Expense Item:

    When the requesters shop for an item, the items visible are based on the deliver-to organization associated with that Requisitioning BU. This is known. But which deliver-to organization?

    That is set from the deliver-to location on your requisition preferences. Ok, let's continue.

    Now when the user shops for an item, adds to cart and navigates to the Edit Requisition page, the deliver-to location, destination type (Expense)  default from the Requisition Preferences setup

    Now, let's say the user wants to switch Deliver-to Location to a different one of his choice, but his choice is not available in the selection. Why?

    The choices available to the user are:

    a) Any 'Global' location or

    b) Any other deliver-to locations that are specifically associated with the deliver-to organization stamped on the requisition line.

    In either case the location has to be associated with the same deliver-to organization  as the one stamped on the requisition line.

    So, how is a deliver-to organization stamped on the requisition line?

    This is where the Requisition Preferences come into play. The deliver-to location that is set guides the system to identify which deliver-to organization is stamped on the line. (See Part 1 for how this works)

    NOTE: The user cannot choose a deliver-to location here that does belongs to a different deliver-to organization. This is the question many customers seem to want to get clarification on. The model works on a deliver-to organization being identified on a specific line and CANNOT be modified.

    So what do I do if I want a different deliver-to location that belongs to a different deliver-to organization?

    Well, then delete this line, go back to requisition preferences and select the deliver-to location that you want (that belongs to a different deliver-to organization) and then come back and shop

    NOTE: The item has to be available in that deliver-to organization too.

    See how this works?

    2. Shopping for an Inventory Item:

    The concept is akin to the expense item flow. We are however now introduced to a new entity - Subinventories. Thankfully, the logic of how this works is the same as the deliver-to location. Let me explain.

    In Part 1, you saw how subinventories are modeled. Now the list of subinventories available to the requester on the Edit Requisition line is based on the deliver-to organization stamped on the requisition line (as we saw earlier). Often customers ask, but I want a different subinventory and I don't find it. Why?

    The answer is simple: That subinventory is modeled under a different organization. Once the requester has selected an item, the deliver-to organization is stamped and done. It cannot be modified. The list of subinventories available at this point is all those that are modeled within that organization.

    So the process to select a different subinventory is the same as earlier. Change the Requisitioning Preferences to a different deliver-to location (that uses a different deliver-to organization where your choice of subinventory is modeled). Then engage in a new flow.

    Customer Feedback:

    Of  late, we are hearing of business requirements around this. Some customers are suggesting that they need flexibility for requesters to choose any deliver-to location or subinventory of their choice and not be constrained by the deliver-to organization being stamped on the line.

    I offer you this:

    1. While the requirement is simple, the design and implementation behind it is perhaps needlessly complex. Deliver-to organizations do more than just model deliver-to locations and subinventories. They drive and control items that a user can see. They drive the transfer price for internal items and so on.

    2. Modeling it in such an open ended fashion has to be looked into carefully taking into account, item, accounting, costing, pricing ramifications.

    3. Other flows using Requisition Preferences defaulting for these entities:

    Similar to 1. and 2. above, when users navigate to the Enter Requisition Line page (advanced requesters), the same defaulting behavior occurs on that page too. The deliver-to location, subinventory are all attributes that are controlled by the deliver-to organization derived from Requisition Preferences.

    I am hoping I have demystified and answered some of the lingering questions that we have seen on forum posts, bugs or even enhancements.

    Please convey your feedback to see how I can improve this or any other article that you review.



    • Ramesh Radhakrishnan

      Thanks Ashok. Good explanation on the Deliver to Organization concepts. I know lot of customers posted various questions around this. Hope this gives good understanding on the functionality. Great document!!

      - Ramesh

    • Ashok

      Yes, the intent was to explain these ideas so customers understand the impact of configuring these entities and also hopefully have clarity on why the design works the way it does.