Recently a few different opportunities have surfaced around data collection during the requisition, procurement and payment processes. Oracle provides some unique tools at each stage that can help.
At the Requisition level, you can set up DFFs, at the Header or Line level, and even control whether these flow down to the Purchase Order automatically.
A DFF can be global, where it appears for every single requisition, or be Context Sensitive, where users have to make a selection for the type of values, before they are presented with the options. The challenge with DFF’s is curating them to the experience. If you make it Global, then all requesters on all requisitions will see the values. If you make them context sensitive, then you rely on users to view and select the right context, very easy for them to forget.
Another option is an Information Template. These are built on the DFF architecture, but they are able to be associated to a Smart Form, Item, or Purchasing Category. This helps you to enforce that they are used, but comes with one glaring limitation: Punchouts.
Smart Forms are a great way to have users enter Non Catalog requisitions without using the Non Catalog Request feature. You can default values and limit the data required, and give them useful names to help users find the right form for their special request; and you can put the Information Template at the bottom.
Punchouts are a direct link to the supplier’s site to search and order items, which are then brought back and added to the Oracle Requisition. Information Templates can only be put here if they are associated to the purchasing category; and usually you are mapping a supplier’s UNSPSC category back to your internal category. The Information Template could be associated to all of those categories as required, but then it would also appear for catalog purchases of the same categories, which may not be the desired outcome.
As the application ships, neither DFF’s nor Information Template values are included in the Approval Notification. DFF’s are available for the approval notification routing, but Information Templates are not. DFFs are in the data model, so they are easy to add to the notification, while Information Templates must be added to the data model. Not impossible, just extra steps that must be taken, and you should always take care that you are doing it because it supports the business process.
At the Purchase Order level, you still have the option to use DFFs, with similar limitations as a Requisition regarding how to ensure the right values are presented to the user.
However, instead of Information Templates, Oracle has recently added a new tool called Compliance Checklists, which brilliantly makes use of the Supplier Qualification Management architecture to create a checklist. Fundamentally, this is a Questionnaire using Questions and Question Branching and Acceptable Responses–all very understandable to an SQM power user but maybe new to your buyers. They will need an update to their Procurement Agent access in order to use these.
The flow is that a buyer will go create a compliance checklist, then on the purchase order, they associate the PO to the checklist. It is a 1:1 mapping; one checklist per PO, one PO per checklist.
Where this solution falls short is in making sure that the Buyer is filling out the correct checklist template, and in routing the checklist to the right team. While you can use checklist status as an approval attribute, this downstream rule is not as handy as an inline validation to ensure the PO has the right checklist template. And, Oracle is relying on the Buyer to fill out the checklist.
Oracle should combine the concepts: Drop the Information Template model and shift all information capture to the SQM model being used in Compliance Checklists. It is more robust than DFF architecture because of question branching, LOV functions with radio buttons to select multiple values, and the ability to make attachments mandatory based on response type, and it should be simple to expand this already re-cycled function to the new area.
Then, add the association features of Information Templates to SQM functions, similar to the validation rules that determine which questionnaires are added to a supplier registration request, and allow us to associate checklists to Smart Forms, Items, Categories, and add Punchouts to the list. It would also be good to have validations based on project details like funding source, and the spend against overhead cost centers, for federal grant purchases. Finally, give us the ability to route a questionnaire to internal users, similar to SQM, so that a checklist could be generated at the requisition or PO level, and routed to a user to fill and send back, instead of relying on the buyer to gather the data.
This addition would make Oracle a powerful tool for all purchasing types, but especially for higher education grants based purchases, where competitors have an easy advantage to sell.
Here is a relatively similar Idea already gaining tracting! https://community.oracle.com/customerconnect/discussion/745030/compliance-checklist-ability-to-attach-to-a-requisition-or-contract