Oracle Apps Purchasing Interview Questions / FAQs


Q1. What is the Basic Purchasing Setup for Requisition Import?

A: If importing requisitions from Inventory,
input a value for the profile option INV: Minmax Reorder Approval. If the value of INCOMPLETE is selected, the result will be imported Requisitions that require an approval. If the value is APPROVED, then the requisitions cannot be queried in the Requisition entry form; rather, the Requisition Summary form will have to be utilized to view information on the imported approved requisitions.

If importing requisitions from MRP, input a value for the profile option MRP: Purchasing By Revision. This profile option is important if you are using multiple revisions per item and using sourcing rules to create Purchase Orders or Releases. This profile option indicates whether or not to pass on the item revision to the purchase requisition.
Setup/Organizations/Purchasing - Default Alternate Region Requisition Import Group-By Field. The Requisition Import process will first look at the Group By parameter selected when the process is submitted; should this parameter be left blank, the system will then look to the Group-By field residing in the Purchasing Options form. If you expect releases to be created from the requisitions, which you import, make sure the profile option PO: Release During Req Import is populated with the correct value. The choices for this profile are Yes or No. If the profile is set to Yes and all sourcing rule information is properly set up, then blanket releases will be created via the Create Releases process. If the profile is set to No, the Create Releases process will not run at the completion of Requisition Import and all releases will have to be created manually via Auto Create.

Q2. How does Requisition Import determine the grouping method for incoming pieces of data?

A:
This function groups requisitions. It first assigns values to REQUISITION_LINE_ID and REQ_DISTRIBUTION_ID; the function then groups Requisitions based on the REQ_NUMBER_SEGMENT1 column. All requisitions with the same NOT NULL REQ_NUMBER_SEGMENT1 are assigned the same REQUISITION_HEADER_ID. The function then groups Requisitions based on the GROUP_CODE column. All requisitions with the same value in the GROUP_CODE column are assigned the same REQUISITION_HEADER_ID. It then groups based on the GROUP_BY parameter, which takes on the value of DEFAULT_GROUP_BY if not provided. GROUP_BY could be one of the following: BUYER, CATEGORY, ITEM, VENDOR, LOCATION or ALL.


 
Q3. How is the PO_INTERFACE_ERRORS table purged and does this data have any dependencies?

A:
Oracle Purchasing provides the Requisition Import Exceptions Report, which can be used to diagnose records in Error in the PO_REQUISITIONS_INTERFACE_ALL table. It also has an option to purge the Error records in PO_REQUISITIONS_INTERFACE_ALL and the corresponding Error message in the PO_INTERFACE_ERRORS table: - Responsibility: Purchasing Super User
- Navigation: Reports/Run, then select Requisition Import Exceptions Report
There is a parameter titled 'Delete Exceptions'. If you select 'Yes', then records in the PO_REQUISITIONS_INTERFACE_ALL table with a status of ‘ERROR' and the corresponding records in the PO_INTERFACE_ERRORS table will be deleted. You can also restrict the deleted records by selecting the Batch_id and the Interface Source code. The dependency is between PO_REQUISITIONS_INTERFACE_ALL (transaction_id) and PO_INTERFACE_ERRORS (interface_transaction_id)

Q4. How is the list of values derived for the Import Source column within the Requisition Import report parameters window?

A:
The list of values for the Import Source parameter drives off of the records, which currently reside in the PO_REQUISITIONS_INTERFACE_ALL table. Within this table is the column, INTERFACE_SOURCE_CODE, which contains the source from where the data was created and in turn is the same value that shows in the list of values. Example: Say that there are currently 20 rows In PO_REQUISITIONS_INTERFACE_ALL.Ten of the rows have an INTERFACE_SOURCE_CODE of 'INV', and the other ten rows have an INTERFACE_SOURCE_CODE value of 'WIP'. When the user then goes to view the list of values, it will show 'INV' and 'WIP' in the list, as those are the only sources currently loaded and unprocessed in the interface table.

Q5. What methods are available in the application to resolve errored records in the PO_INTERFACE_ERRORS table?

A:
Oracle Purchasing provides the Requisition Import Exceptions Report, which can be used to diagnose problems with the records, which have currently errored out in the PO_REQUISITIONS_INTERFACE_ALL table.
- Responsibility: Purchasing Super User
- Navigation: Reports/Run, then select Requisition Import Exceptions Report
There is a parameter titled 'Delete Exceptions’. If this is populated with 'Yes', then all records in the PO_REQUISITIONS_INTERFACE_ALL table with a status of ‘ERROR’will be deleted when the report is executed. If the parameter is set to ‘No', then you will see the errors from the report and be able to manually fix the data in the table, if so desired; then, upon completion of the data correction, run Requisition Import again to process the modified rows in the interface table.


Q6. Can Requisition Import handle multiple currencies?

A:
Requisition Import is capable of handling multiple currencies, provided that all rate types and currency conversions have been defined.

Q7. Can Requisition Import handle multiple distributions?

A:
Requisition Import can handle multiple distributions.

Q8. Is it possible to have all requisitions created from MRP to be imported with a status of INCOMPLETE?

A:
It is not possible to have Requisitions created from MRP imported into the Oracle Purchasing application with a status of INCOMPLETE. The MRP Application inserts all data into the PO_REQUISITIONS_INTERFACE_ALL table with an AUTHORIZATION_STATUS of APPROVED. Therefore, when the Requisition Import program runs, all requisition lines from MRP are created with a Status of APPROVED. If requisitions are created from MRP and the AUTHORIZATION_STATUS is not APPROVED, then please contact support for assistance.

 
Q9. Is it possible to have all requisitions created from Inventory - Min-Max Planning to be imported with a status of INCOMPLETE?

A:
Yes, it is possible to have all requisitions created from Min-Max Planning with a status of INCOMPLETE. If the desired outcome is Min-Max requisitions showing a status of INCOMPLETE, it is necessary to set the profile option: INV: MinMax Reorder Approval to Incomplete. Conversely, if this profile option is set to Approved, all requisitions imported from Min-Max Planning will be imported with an approval status based on the approval authority of the user initiating the Requisition Import process.

 
Q10. How can I achieve creating 10 requisitions for 10 lines populated into the interface table, instead of 1 req. with 10 lines?

A:
Requisitions are grouped according to the selection chosen by the initiator of the process, based on the parameter of 'GROUP BY’. If this parameter is left blank, the value will default from the Default alternate region of the Purchasing Options form.
- Responsibility: Purchasing Super User
- Navigation: Setup -> Organizations -> Purchasing Options
Default alternate region
If the value selected is ALL, then all requisition lines will be on the same requisition. Any other value will group the lines on requisitions based on the value selected.

Q11. Is Requisition Import organization-specific?

A:
Requisition Import is operating unit-specific. Within the PO_REQUISITIONS_INTERFACE_ALL table lies the column ORG_ID.Upon Initiating the Requisition Import program, the profile 'MO: Operating Unit' is queried to derive the value of ORG_ID tied to the login running the program. Then the Requisition Import program executes, all records in the interface table which are the same as the organization listed in the 'MO: Operating Unit' profile will be processed. If you don't see any valid Import source when you launch Reqimport but if you had already populated the Interface table then you have to check the org_id Column you populated. this org_id will be your operating unit tied to your Applications log-in responsibility. If the org_id is NULL then you can see you record in the Import Source.

Q12. When using encumbrance, is there any validation on the GL Date, ensuring the appropriate periods are open?

A:
The Requisition Import program will perform date integrity checks against the date value in the PO_REQUISITIONS_INTERFACE_ALL.GL_DATE field. This field GL_DATE, is reserved for systems operating under Encumbrance Accounting constraints. It is necessary to ensure that the encumbrance year is opened for the GL_DATE being specified.

Q13. How can I achieve grouping by Vendors?

A:
First check to see if any records in PO_REQUISITIONS_INTERFACE_ALL have a value for the GROUP_CODE or REQ_NUMBER_SEGMENT1 columns. If there is no value in either of these two columns, then the Requisition Import Program uses the Default Group By that you setup to group requisition lines. Also Navigate to Purchasing -> Setup -> Purchasing Options and Check the group by setting.

Q14. Why some times Requisition Import Process fails to create Requisitions when the Data is imported from MRP?

A:
Ensure that you use revision number for the item. This is mandatory when you use the profile option  “Purchasing by Revision”. The value will indicate whether to pass on item revision to the purchase requisition. You can update this profile at the site level. If this profile is set to Yes, then the item used for requisition import process should have a revision number. Now when you repeat the process the Requisition Import works and the requisitions will be created Successfully from MRP.

Q15. How does Requisition Import Process generate Accounts?

A:
It can be either one of 2 methods for accounts to be generated:
1. By a valid CCID or
2. By a valid combination of account segments.
We do not generate the accounts using the Account generator process. We only validate the charge_account_id or by a valid combination of Account segments which are populated in the interface table. This is the existing functionality.

Q16. How can automatically approve the Requisitions I am creating?

A:
There are two ways of doing this:
1. You can populate records in the Interface table with status as APPROVED. In this case the Approval process is not called after creating the Req. with APPROVED status.
2. If you still want the Requisitions created to go through the approval process then you have to set Requisition Import Parameter 'Initiate Approval after Reqimport' to 'Yes' when Launching the Requisition Import Concurrent Program. For the Requisition to be automatically Approved, the APPROVER_ID value from PO_REQUISITIONS_INTERFACE_ALL must have authority to approve the Requisition. If that user does not have approval authority, then the Requisition will be in status = IN PROCESS and forwarded up that user's Approval Hierarchy.

Q17. How will I get the trace and detailed log for the Requisition Import Process?

A:
You have to set the profile 'PO: Set Debug Concurrent On' to 'Yes to get the detailed log and Database level for the Requisition Import Process.

Q18. When I load the Requisition Interface and create Requisitions it always does Sourcing. How can I stop sourcing from happening?

A:
You have to set the autosource_flag in the Requisition interface to 'N' to avoid vendor Sourcing

Q19. How can I avoid sourcing from overriding my vendor information?

A:
You have to set the autosource_flag to 'P' for partial sourcing.

Q20. How does Requisition Import process use the Group-By parameter while launching Requisition Import?

A:
The Requisition Import process will first look at the Group By parameter selected when the process is submitted; should this parameter be left blank, the system will then look to the Group-By field residing in the Purchasing Options form. To setup in Purchasing option Form the Navigation is Setup/Organizations/Purchasing Options - Default Alternate Region Requisition Import Group-By Field.

Q21. What does the 'MRP: Purchasing by Revision' and 'INV: Purchasing by Revision' do?

A:
The profile 'MRP: Purchasing by Revision' is maintained by MRP and the 'INV: Purchasing by Revision' profile is maintained by Inventory. This profile option is mainly used by the respective products to determine if the Item Revision needs to be populated while loading the Requisition Interface Tables. Most of the bugs related to these profiles are that sourcing gets affected during Req Import. If the Blanket PO has the Item Revision and the Item in the Interface table does not have the Item Revision field populated, then Sourcing could be a Issue and Releases will not be created. 

Q22. How do I get the Tax log file for the Requisition Import process?

A:
To get the log file please follow the steps below.
Step 1:
-------
Set Profile Option 'Tax: Debug File Directory'
Set the profile option Tax: Debug File Directory to a server side directory where a file that contains log messages will be created. You can set this profile option only at the Site level.
Note: This directory must be set as the value of one of the Oracle initialization parameters, 'UTL_FILE_DIR' To see the current value of UTL_FILE_DIR, issue the following SQL statement in the apps schema:
select value from v$parameter where name = 'utl_file_dir' 
If this parameter does not contain a value, modify the initialization parameter file init<db_name>.ora to add the parameter and a value for it (where <db_name> is the name of your database).
Step 2:
-------
Set Profile Option Tax: Debug Flag
Set the profile option Tax: Debug Flag to Yes to create a file with debugging information. Set this profile option at the User level. A log file called <USERNAME>.log will be created in the directory specified by the profile option Tax: Debug File Directory (where <USERNAME> is your login username).
Note: The form should be closed after the transaction is saved.