Posts

Posts

  • Boyuan Zhu
    How to Share Saved Searches with Other Users25.0
    Topic posted November 30, 2018 by Boyuan ZhuBronze Trophy: 5,000+ Points, tagged How-To in Procurement > Purchasing public
    Title:
    How to Share Saved Searches with Other Users
    Content:

    Oracle Purchasing Cloud users can create personal saved searches to store queries for future use. As a procurement administrator, you can create saved searches that are available to all users of that page. You can use this ability to share common queries important to your organization and to save your users the need to enter criteria manually. In this example, you will add a new saved search to the Manage Orders page and make the saved search available to all users.  

    1. Enter a sandbox and navigate to the page that you want to configure. 
    2. In the Settings and Actions menu in the top right corner, click Edit Page. 
    3. Make sure that the editor is in Design mode (View dropdown top left of the page).
    4. Set up your search criteria and save the search. 
    5. Publish the sandbox, and the saved search will be available for all users.
    Document:
  • Boyuan Zhu
    How to Import Orders and Agreements Using the ERP...45.0
    Topic posted November 1, 2018 by Boyuan ZhuBronze Trophy: 5,000+ Points, tagged Agreements, How-To, Orders, Web Services in Procurement > Purchasing public
    Title:
    How to Import Orders and Agreements Using the ERP Integration Service
    Content:

    You can use the ERP Integration Service to automate file based data import (FBDI) between your system and Oracle Procurement Cloud. For example, you can create a program to convert import data from your system into the FBDI CSV format, encode the resulting ZIP file into the SOAP payload, and invoke the integration web service with the payload. The following section contains example payloads for importing purchase orders, blanket purchase agreements and contract purchase agreements. 

    Each payload includes a ParameterList of parameters for the import job. The examples below explain, in order, what each parameter is and what values are valid. Note that the parameters and the order of the parameters differ for each job. To figure out the value for id based parameters, you can look at the values for previous jobs on the Scheduled Processes Page, as seen in the screenshot below.

    Import SPO 

    Payload:

    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:typ="http://xmlns.oracle.com/apps/financials/commonModules/shared/model/erpIntegrationService/types/" xmlns:erp="http://xmlns.oracle.com/apps/financials/commonModules/shared/model/erpIntegrationService/">
     <soapenv:Header/>
     <soapenv:Body>
     <typ:importBulkData>
     <typ:document>
     <erp:Content>INSERT YOUR ZIP FILE IN BASE64 ENCODING HERE</erp:Content>
     <erp:FileName>PoImportOrders.zip</erp:FileName>
     </typ:document>
     <typ:jobDetails>
     <erp:JobName>/oracle/apps/ess/prc/po/pdoi,ImportSPOJob</erp:JobName>
     <erp:ParameterList>204,100010026863783,NONE,204,2021,N,#NULL,N</erp:ParameterList>
     </typ:jobDetails>
     </typ:importBulkData>
     </soapenv:Body>
    </soapenv:Envelope>
    

    Parameters: 

    Procurement BU: Specify the id of the Procurement business unit that these documents should be imported into.

    Buyer: Specify the id of the buyer to be used when one is not included in the import data.

    Approval Action: NONE - Imports the document in Incomplete status requiring manual interaction. SUBMIT - Imports the document and submits it to the approval process after the document is imported. BYPASS - Imports the document in Open (approved) status without going through the approval process.

    Default Requisitioning BU: Specify the id of the Requisitioning business unit to be used when one is not included in the import data.

    Batch ID: Enter the value for your import data from the file-based data import template, to select the interface table data to be processed in the current run. For example: Batch ID = 123. Use it in conjunction with Import Source to identify the documents to be loaded to the application tables.

    Create or Update Item: Y to create an item that does not exist or update an existing item. N to not create or update any items. 

    Import Source: Enter the value for your import data from the file-based data import template, to select the interface table data to be processed in the current run. For example: Import Source = External Contracts. Use it in conjunction with Batch ID to identify the documents to be loaded to the application tables.

    Communicate Document: Y to have imported purchasing documents communicated to the supplier. N to not have imported purchasing documents communicated to the supplier.

     

    Import BPA 

    Payload:

    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:typ="http://xmlns.oracle.com/apps/financials/commonModules/shared/model/erpIntegrationService/types/" xmlns:erp="http://xmlns.oracle.com/apps/financials/commonModules/shared/model/erpIntegrationService/">
     <soapenv:Header/>
     <soapenv:Body>
     <typ:importBulkData>
     <typ:document>
     <erp:Content>INSERT YOUR ZIP FILE IN BASE64 ENCODING HERE</erp:Content>
     <erp:FileName>PoImportBlanketAgreements.zip</erp:FileName>
     </typ:document>
     <typ:jobDetails>
     <erp:JobName>/oracle/apps/ess/prc/po/pdoi,ImportBPAJob</erp:JobName>
     <erp:ParameterList>204,100010026863783,N,NONE,2021,#NULL,N</erp:ParameterList>
     </typ:jobDetails>
     </typ:importBulkData>
     </soapenv:Body>
    </soapenv:Envelope>
    

    Parameters: 

    Procurement BU: Specify the id of the Procurement business unit that these documents should be imported into.

    Buyer: Specify the id of the buyer to be used when one is not included in the import data.

    Create or Update Item: Y to create an item that does not exist or update an existing item. N to not create or update any items. 

    Approval Action: NONE - Imports the document in Incomplete status requiring manual interaction. SUBMIT - Imports the document and submits it to the approval process after the document is imported. BYPASS - Imports the document in Open (approved) status without going through the approval process.

    Batch ID: Enter the value for your import data from the file-based data import template, to select the interface table data to be processed in the current run. For example: Batch ID = 123. Use it in conjunction with Import Source to identify the documents to be loaded to the application tables.

    Import Source: Enter the value for your import data from the file-based data import template, to select the interface table data to be processed in the current run. For example: Import Source = External Contracts. Use it in conjunction with Batch ID to identify the documents to be loaded to the application tables.

    Communicate Document: Y to have imported purchasing documents communicated to the supplier. N to not have imported purchasing documents communicated to the supplier.

     

    Import CPA

    Payload:

    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:typ="http://xmlns.oracle.com/apps/financials/commonModules/shared/model/erpIntegrationService/types/" xmlns:erp="http://xmlns.oracle.com/apps/financials/commonModules/shared/model/erpIntegrationService/">
     <soapenv:Header/>
     <soapenv:Body>
     <typ:importBulkData>
     <typ:document>
     <erp:Content>INSERT YOUR ZIP FILE IN BASE64 ENCODING HERE</erp:Content>
     <erp:FileName>PoImportContractAgreements.zip</erp:FileName>
     </typ:document>
     <typ:jobDetails>
     <erp:JobName>/oracle/apps/ess/prc/po/pdoi,ImportCPAJob</erp:JobName>
     <erp:ParameterList>204,100010026863783,NONE,2021,#NULL,N</erp:ParameterList>
     </typ:jobDetails>
     </typ:importBulkData>
     </soapenv:Body>
    </soapenv:Envelope>
    

    Parameters: 

    Procurement BU: Specify the id of the Procurement business unit that these documents should be imported into.

    Buyer: Specify the id of the buyer to be used when one is not included in the import data.

    Approval Action: NONE - Imports the document in Incomplete status requiring manual interaction. SUBMIT - Imports the document and submits it to the approval process after the document is imported. BYPASS - Imports the document in Open (approved) status without going through the approval process.

    Batch ID: Enter the value for your import data from the file-based data import template, to select the interface table data to be processed in the current run. For example: Batch ID = 123. Use it in conjunction with Import Source to identify the documents to be loaded to the application tables.

    Import Source: Enter the value for your import data from the file-based data import template, to select the interface table data to be processed in the current run. For example: Import Source = External Contracts. Use it in conjunction with Batch ID to identify the documents to be loaded to the application tables.

    Communicate Document: Y to have imported purchasing documents communicated to the supplier. N to not have imported purchasing documents communicated to the supplier.

    Document:
  • Ashok
    How to view Approval History for older Requisitions45.0
    Topic posted July 21, 2018 by AshokBlack Diamond: 60,000+ Points, tagged Approvals/Notification, FAQ, How-To in Procurement > Self Service Procurement public
    Title:
    How to view Approval History for older Requisitions
    Summary:
    Viewing Approval History for older Requisitions
    Content:

    This article is to acknowledge some stellar work from Support for customer questions relating to viewing approval history on older requisitions.

    Premise:

    Requisitions for which approvals are completed do not carry approval history details beyond a certain time (a few weeks) at which point the workflow details are purged. There were customers asking about whether there was a way (other than using the View Document History from Manage Requisitions) to view approval history details for older requisitions. The business requirement here was one of Audit History and Tracking.

    Proposal:

    Support came up with this question and based on some tips provided by Development, came up with a query that they provided to retrieve approver names and details for Requisitions for which workflow details were not available via BPM.

    NOTES: 

    1. Approver Names may or may not be retained and so available depending on how old the requisition is

    2. This is a proposal that was useful to said customers. The intent of posting this is for you to review and make your own determination if this is helpful in your business context.

    Index of tables: Requisition_Headers_All, PO_Action_History, PER_Person_Names_F

    SELECT
    DISTINCT RHA.requisition_number ,
    PAH.OBJECT_TYPE_CODE ,
    PAH.SEQUENCE_NUM ,
    PAH.ACTION_CODE ,
    PAH.ACTION_DATE ,
    PPN.DISPLAY_NAME ,
    PAH.PERFORMER_ID
    FROM FUSION.PO_ACTION_HISTORY PAH ,
    FUSION.POR_REQUISITION_HEADERS_ALL RHA ,
    PER_PERSON_NAMES_F PPN
    WHERE PAH.object_id = RHA.requisition_header_id
    AND RHA.requisition_number IN ('39127')
    AND PAH.PERFORMER_ID = PPN.PERSON_ID
    ORDER BY PAH.SEQUENCE_NUM;

    The recommendation here was to use this and build a custom OTBI report to lead this proposal to its logical conclusion.

    I thought I would post this here to elicit conversation among yourselves to see if this is something that makes sense in your business and whether you have any other ideas for similar requirements.

    It would be helpful if you all could rate these kinds of articles to give us a heads up on what kind of articles customers want from us to help further education or knowledge requirements regarding the application.

  • Ashok
    How to Restrict Requesters in the Requester LOV34.9
    Topic posted June 27, 2018 by AshokBlack Diamond: 60,000+ Points, tagged Create Requisition, How-To, White Paper in Procurement > Self Service Procurement public
    Title:
    How to Restrict Requesters in the Requester LOV
    Summary:
    How to restrict Requesters in the Requester LOV
    Content:

    All

    We recently had a customer use case that cited the following requirement:

    The Manage Requisitions page allows users to search for requisitions belonging to other requesters using the Requester LOV. However, the LOV displays all persons that belong to any requisitioning BU in the organization. This customer wanted to restrict the search capability whereby the search results in the LOV would only return those Requesters belonging to the same business unit as the current requester.

    This is supported using some configuration via the Security Console.

    This attached document details the process and steps involved in such a configuration.

    NOTE: The idea here is exploratory that provides customers an idea of what is feasible using this infrastructure. The idea in publishing this to familiarize the customers with this feature capability and have the customers use their consulting and professional resources to use the infrastructure for their own specific business needs.

    Happy reading! As always, appreciate the feedback and ranking on whether this is helpful and ideas on what other articles would be of interest.

    Thanks

    Ashok

  • Ashok
    Part 2: Inventory Organizations, Deliver-to Locations,...25.0
    Topic posted November 17, 2018 by AshokBlack Diamond: 60,000+ Points, tagged Create Requisition, How-To, Requisition Processing in Procurement > Self Service Procurement public
    Title:
    Part 2: Inventory Organizations, Deliver-to Locations, Subinventories: Interactions in Self Service Procurement Flows
    Summary:
    An overview of how inventory organizations, deliver-to locations, subinventories interact in Self Service Procurement transaction flows
    Content:

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

    https://cloudcustomerconnect.oracle.com/posts/14d8d1cefd

    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.

  • Ashok
    Part 1: Inventory Organizations, Deliver-to Locations,...75.0
    Topic posted November 16, 2018 by AshokBlack Diamond: 60,000+ Points, tagged How-To, Inventory Cloud, Requisition Processing, Setup in Procurement > Self Service Procurement public
    Title:
    Part 1: Inventory Organizations, Deliver-to Locations, Subinventories: Interactions in Self Service Procurement Flows
    Summary:
    An overview of how inventory organizations, deliver-to locations, subinventories interact in Self Service Procurement transaction flows
    Content:

    Customers

    A lot of you have recently posted various issues/questions on topics that primarily relate to one idea:

    A better understanding of how the following entities are used in Self Service Procurement flows:

    a) Inventory Organization

    b) Deliver-to Location

    c) Subinventories

    Part 1:

    I am writing this article in the hope that it will clarify a lot of these questions on behavior, interactions and process.

    Part 2:
    I will be discussing why and how an understanding of these interactions is important in the next part. Stay tuned.

    1. Glossary:

    Before we go any further, let us get some terms understood clearly.

    A. Requisitioning BU:

    A business unit that has the business function 'Requisitioning' defined. This is the cornerstone of the Self Service Procurement application. See setup: Manage Business Unit for more details

    B. Inventory Organization:

    In the context of Self Service Procurement, the first thing to note is that the terminology you will see is 'Deliver-to Organization'. This is the inventory organization that carries master items that are then configured as part of catalogs or on master agreements to then make it available for shoppers in the shopping flows. Setup: Manage Inventory Organizations

    NOTE: For the purposes of this article, I will be using the two terms interchangeably

    C. Location:

    This typically represents a physical location where a requester's items ought to be delivered. Setup: Manage Locations

    D. Subinventory:

    A subinventory is a sub entity of an inventory organization. It typically represents a storage facility for items. Subinventories are setup in the context of an inventory organization. Setup: Manage Subinventories and Locators.

    2. Relationships:

    Here is a quick overview of how these entities are related (as far as Self Service Procurement flows go)

    1. A Requisitioning BU is associated with one or more inventory organizations using the Manage Business Unit attribute in the inventory organization setup (See Screenshot A in the attached word document)

    NOTES: One Requisitioning BU can be associated to multiple deliver-to organizations through this setup

    2. A Location is associated to an inventory organization in two ways:

    a) In the Inventory Organization setup, you select a location

    b) In the Manage Locations setup, you can associate that location to a 'default' inventory organization (See Screenshot B in the attached document)

    NOTES: 

    a) These are not reciprocal. One location can be assigned to several inventory organizations via a). But one location can only be assigned one inventory organization via b)

    b)  If no inventory organization is associated to a location in b), that is termed a 'Global Location'.

    3. A subinventory is associated with an inventory organization via Manage Subinventories and Locators setup. One inventory organization can have one or more subinventories associated with it

    4. A deliver-to organization is stamped on a requisition line primarily from the Requisition Preferences setup as follows:

    a) If the Deliver-to Location setup in Requisition Preferences is a 'Global' location, then the default deliver-to organization from the Configure Requisitioning Business Function setup is used

    b) If the Deliver-to Location setup in Requisition Preferences is associated to a deliver-to organization in the Manage Locations setup, then that is used

    NOTE: A requisition on multiple lines can be associated to different Deliver-to Organizations as you can deduce from the above.

    5. The list of subinventories available in the Requisition Preferences page is based on 2 factors:

    a) Until the Deliver-to Location is picked, the list of subinventories will be all subinventories that belong to any deliver-to organization associated with the Requisitioning BU

    b) After a Deliver-to Location is picked, the list of subinventories will be restricted to only those that belong to the deliver-to organization associated with that deliver-to location (See D above)

     

  • Ashok
    Purchasing Documents Pending Approval44.9
    Topic posted July 28, 2018 by AshokBlack Diamond: 60,000+ Points, tagged Approvals/Notification, Business Intelligence - BI, How-To in Procurement > Self Service Procurement public
    Title:
    Purchasing Documents Pending Approval
    Summary:
    A Report showing purchasing documents which are currently pending approval and the person they are currently assigned to.
    Content:

    My colleague had provided this article in the BI Analytics section a while ago. I thought it would be relevant to post it here for any new customers that are following this forum.

    Business Requirement:

    If you want a report that simply shows the current approver for a purchasing document (that is, you want to know with whom a document is pending), you can create one using the BPM UI Views. Please see the image in the attached document BPM UI View - PendingApproverReport. Note that you will need to create a seperate report (i.e. seperate BPM UI View) for each type of purchasing document approval process that you are interested in.

    If you need more details, such as how long the document has been pending with the current approver, the approver's email, their manager's email and so on, follow the instructions below to download and run a report created using BI Publisher. This is a single report which covers purchase orders, contract purchase agreements, blanket purchase agreements and requisitions

    How to generate / execute this Report:

    To add this content to your environment:

    1. For R13 (and higher) environments
      • Download RPT_PendingApprover.xdoz
      • Download DM_PendingApprover_R13.xdmz
      • Rename DM_PendingApprover_R13.xdmz to DM_PendingApprover.xdmz
    2. Log in to BI Publisher, click on the Catalogs link and locate the folder where you want to save the report and its corresponding data model e.g. Shared Folders>Custom

    3. Click the ‘Upload Resource’ icon

    4. Select the Data Model File (DM_PendingApprover.xdmz) and click to Upload

    5. Repeat Steps 3 & 4 for the Report File (RPT_PendingApprover.xdoz)

    6. Both the data model and report should now be successfully uploaded and visible in your catalog

    7. Select the report and click on ‘Open’ to run the report

    The following attributes are displayed on the report

    Document Type (i.e purchase order, agreement, requisition)
    Document Number
    Description
    Date document was submitted
    Current Approver (and their email, their manager)
    Date document was assigned to the current approver
    How many days have elapsed since document was submitted for approval

  • Aishwarya Pawar
    Supplier Profile Attachments Listing Report64.8
    Topic posted April 30, 2019 by Aishwarya PawarGold Medal: 3,500+ Points, tagged Business Intelligence, How-To in Procurement > Supplier Management public
    Title:
    Supplier Profile Attachments Listing Report
    Summary:
    Custom BIP Report displaying supplier profile attachments for recently created suppliers
    Content:

    This BIP report will show supplier profile attachments added to the supplier header for all suppliers created in the last 30 days.

    The attached Deployment Instructions.pdf contains steps for importing the data source and report to your instance.  Also attached is the Supplier Profile Attachments.catalog file that will allow you to import these to your instance.

    Image:
  • Manavalan Ethirajan
    How to reassign POs when buyer left the organization5.0
    Topic posted December 31, 2018 by Manavalan EthirajanSilver Medal: 2,000+ Points, tagged How-To, Orders in Procurement > Purchasing public
    Title:
    How to reassign POs when buyer left the organization
    Content:

    Requirement: Buyer has left the organization and there are volume of Purchase Orders that have not been changed to finally close. Need to provide additional rights to some other user to make the changes to the eligible Purchase Orders.

    Option 1:

    You can run a process to reassign purchasing documents from one buyer to another, including purchase agreements, contract agreements and purchase orders. To run the process use the Reassign Purchasing Documents task, from the Purchase Agreements or Purchase Orders work area. To use the Reassign Purchasing Documents task you must have a role with the Reassign Purchasing Document privilege. For example, Procurement Manager, Category Manager or Buyer. Refer the attached 'Reassign Purchasing Documents' image.

    Option 2:

    Set the other agent’s access to ‘Full’ for Purchase Orders in procurement agent setup. With this setup, other agents can access Purchase Orders created by buyers who left the organization. Please refer 'Manage Procurement Agents' image.

    Image:
    Document:
  • Ashok
    How to configure a Punchout Catalog via OSN25.0
    Topic posted November 15, 2018 by AshokBlack Diamond: 60,000+ Points, tagged How-To, Requisition Processing, Setup in Procurement > Self Service Procurement public
    Title:
    How to configure a Punchout Catalog via OSN
    Summary:
    How to configure a Punchout Catalog via OSN
    Content:

    Customers

    A lot of you have asked us to provide documentation on this specific process: Configuring a punchout catalog via OSN.

    Please review attached document.

    Do let us know if these need edits, additions or further details.