View the “Status Monitor” of other user’s workflow

To allow user to view different user’s workflow, you must make user can select “Workflow Owned By” field in “Status Monitor“. To enable user to do that,

1. Log in the responsibility “Workflow Administrator Web Applications” with sysadmin user and password.

2. Go to Administration tab (window).

3. Change “Workflow System Administrator” to user name, responsibility name or “*”.

  • If user name, the user can view all workflow and other user can only view his/her own workflow;
  • If responsibility name, the user who has this responsibility can view all workflow;
  • If *, anyone can view all workflow.

XLA_MO_TOP_REPORTING_LEVEL (MO: Top Reporting Level)

The captioned profile option has been obsoleted in Oracle R12 version. All the customized report used this profile option “MO: Top Reporting Level” and value set “XLA_MO_REPORTING_LEVEL” should be re-written.

If customer used this profile option in his 11i custom reports , Customer might have been using this profile option to set the reporting level at SoB,Legal Entity or Org. However, in Release 12 the highest level is always a Ledger. Thus, these profiles are no longer needed in Release 12 and you will need to update the custom reports by basing them ledger and Mo profiles instead of SoB and MO: Top Reporting Level.

Object Version Number (object_version_number)

Object Version Number (OVN) is a column in a database table. It is used to track multiple changes to a record. When a new row is inserted, the OVN is set to 1. As updates are performed on the row through the Forms, the OVN is incremented. The OVN is transferred with a queried row. If an update is attempted when the change is saved to the table, the current OVN is compared with the value being passed back from the transaction. If the two are the same, the update can be committed to the table. If the two are different, the update is rejected and flagged with an error. The transaction must be re-queried, and the update made again to the more current version of the row.

APIs and Forms use OVNs similarly. Every published API has the p_object version_number control parameter.

For Create APIs, this parameter is defined as an OUT parameter: the API assigns the object version number to 1 for row inserts. For Update APIs, the parameter is defined as IN OUT, and is mandatory in the API call.

The current value must be passed in the API call and it is compared to the version on the row in the table. If the versions are different, the error HR_7155_OBJECT_LOCKED is raised. The information can be re-queried for a more current version.

Script to Initiatialize Application Context

DECLARE
v_user_id      NUMBER;
v_resp_id      NUMBER;
v_resp_appl_id NUMBER;
BEGIN
SELECT a.user_id,
a.responsibility_id,
a.responsibility_application_id
INTO v_user_id,
v_resp_id,
v_resp_appl_id
FROM FND_USER_RESP_GROUPS_DIRECT a,
fnd_user b,
FND_RESPONSIBILITY_VL c
WHERE a.user_id        =b.user_id
AND a.responsibility_id=c.responsibility_id
AND b.user_name        =    ‘&User_Name’
AND c.responsibility_name =    ‘&Responsibility_Name’;
fnd_global.APPS_INITIALIZE (v_user_id, v_resp_id, v_resp_appl_id);
END;

All SO lines are closed but SO is still “Booked”. Why?

If you are still use the Oracle standard workflow “Order Flow – Generic” and “Close – Order”,  Oracle will close the order header by the last day of the month when all the lines are closed.  Sometimes it makes your user a little confused.

If you need to close the order header as soon as all order lines are closed, please refer to metalink document 397364.1 to customize above two workflows or email me to discuss.

PO Submission Validation/Check

We all know there’s a button call “Approve…” in the right bottom of the PO ENTRY form. When you click it, what happens?

We all experienced that an error message said like “shipment line is not equal to po line, etc.”, so it looks Oracle Purchasing executes some validation/check process when you click “Approve” button.

Yes, you’re right. The package PO_DOCUMENT_CHECKS_PVT handle this validation/check. The procedure po_submission_check under the package is the main procedure. It calls some other procedures (also within this package) to do validation progress by progress against the document type, for example, for standard PO, PO_DOCUMENT_CHECKS_PVT.po_submission_check calls PO_CHECK procedure to do the checks.

The structure of PO_CHECK procedure looks like below

“l_progress := ‘001’;
……..;

l_progress := ‘002’;
……..;

l_progress := ‘003’;
……..;

l_progress := ‘004’;
……..;”

So if you want to add some more validations restriction, you can add some new segment code like

“l_progress := ‘XXX_CUS01’;
…….;”

It looks very flexible.

For some more information/application about this design, please see the post later.

Query a Specific User’s Authorized Concurrent Requests

Somebody always asked that if I have this report, which responsibility I can run this report in, what I can do in the system, etc. There’s no a separate form to show you these question. I prepared a simple report to answer these questions by SQL Developer and export it to an XML file. If it is helpful for your works, feel free to download, extract it and import to your SQL developer.

Download: User’s Requests

To import the xml file, from here!

Reference:  The previous post “Oracle SQL Developer Report“.