Month: November 2020

RVTPT-020: Subroutine rvtoe_RmaPushApi() – EQuantity cannot be greater than original ordered quantity. returned error

On By windows7bugsIn Oracle Applications(R12), Oracle relatedLeave a comment

A single music track, movie, event, product… changes the life for many & in my case it was a single API by Oracle!

“oe_order_pub.process_order” that comes with Oracle Applications (We are using EBS R12)

The firm for which I work is using an inhouse developed module for the complete retailing & I take the credit of developing the full solution using this ONE API/around this API.

From a mere “Oracle Forms & Reports” developer with some knowledge about Oracle database, developing around this single API to facilitate Sales Orders and Returns (RMA) slowly shaped me in to whatever I am today.

We are using this custom module from last 11 years and I wouldn’t say there were no issues. We’ve many sales outlets and most of them are connected to the datacenter using ADSL data lines. Sometimes the connections caused, other times code caused, few other times some internal bugs caused problems were there, however against the volume of sales transactions those we make yearly, limited to numbers those could be counted in fingers.

So, recently I was contacted by the sales team, to resolve an issue with a sales return, with lines stuck “Awaiting Return” status. While inspecting the transaction, I realized that the salesmen tried to return this SO multiple times and instead of 2 lines against the sales order, there were 20 lines (10 attempts). I cleared whole those lines with errors and tried to receive the materials once again, bringing up the error:

RVTPT-020: Subroutine rvtoe_RmaPushApi() - EQuantity cannot be greater than original ordered quantity. returned error
 Cause:        Subroutine rvtoe_RmaPushApi() - EQuantity cannot be greater than original ordered quantity. returned an in

Eventually, I landed upon the Oracle support document “RMA Receipt Error:RVTPT-020: Subroutine rvtoe_RmaPushApi() – EQuantity Cannot Be Greater Than Original Ordered Quantity (Doc ID 2409611.1)” & according to the document, this situation arises when there are multiple transactions trying to do a RMA against the same quantities! So I ran couple of quick queries like below:

Select * from oe_order_lines_all where header_id  = (Select header_id from oe_order_headers_all where order_number='18016698');

Fetched all the line ids from the lines table against the order number & then tried to see where exactly the line ids were refernced. Whenever a RMA is facilitated the lines table fills in the columns “REFERENCE_HEADER_ID” and “REFERENCE_LINE_ID” with the header_id and line_id values from the original sales order. All I had to make sure that the line ids were referenced multiple times.

Select * from oe_order_lines_all where reference_line_id IN (4656844, 4656845);

As expected, I was able to find four lines (expected 2 lines only) and was able to track down the 2nd RMA that was automatically created by the API due to some unknown reasons (I said there were few problems using the API)

Based on the suggestions available with the support document, I cancelled the duplicate RMA transaction (Actually another Sales Order with the next immediate document number) & created a new receipt for the Sales Order that was stuck with lines having “Awaiting Return” flow status.

Hope this helps few out there.

rajesh

EBS R12 Cloned Instance | opatch

On By windows7bugsIn NOT a DBA, Oracle database 11gLeave a comment

Not being a DBA has it’s own perks ;) Freedom to try to fix everything that do not look “legit” from all angles.

My last attempt was to rebuild “Central Inventory” for a cloned instance of Oracle Applications R12 (EBS 12.0.6) on Linux. This instance was cloned from a certified platform, to a totally unsupported platform. In addition to, the DBAs those migrated from 10g R2 to 11g R2 left much of the post clone activities pending immediately once after the instance came online.

So, trying to patch Oracle database 11gR2(11.2.0.4) brought me to a situation that never existed:

  • “opatch” was “not” recognized as a command!
  • “opatch lsinventory” run always screamed about corrupt/missing central inventory location.

The “opatch” not being recongized as a command was due to $ORACLE_HOME/OPatch path missing, easily fixed by adding the path to the existing $PATH environment variable for the Oracle user.

One of the other issues you might face up with 11.2.0.4 could be the unsupported opatch version. You need to replace the current opatch version with the latest supported. Please refer to patch #6880880 & Install the patch marked in the below image

Please read the “README” to know how to replace the existing version with the latest supported.

Once the opatch stack taken care of, we still need to fix the central inventory, that keeps reported as being missing.

[oratest@bak clone]$ opatch lsinventory
 Oracle Interim Patch Installer version 11.2.0.3.25
 Copyright (c) 2020, Oracle Corporation.  All rights reserved.
 Oracle Home       : /u01/oratest/TEST/db/tech_st/11.2.0
 Central Inventory : /u01/oratest/TEST/db/tech_st/11.2.0/inventory
    from           : /u01/oratest/TEST/db/tech_st/11.2.0/oraInst.loc
 OPatch version    : 11.2.0.3.25
 OUI version       : 11.2.0.4.0
 Log file location : /u01/oratest/TEST/db/tech_st/11.2.0/cfgtoollogs/opatch/opatch2020-11-11_10-35-04AM_1.log
 LsInventorySession failed: OPatch failed to locate Central Inventory.
 Possible causes are:
     The Central Inventory is corrupted
     The oraInst.loc file specified is not valid.
 OPatch failed with error code 73

Let us see how to rebuild the Central Inventory for the EBS R12 cloned instance now.

If your current server (the one that has the cloned instance of the application) never had an Oracle installation executed from the same, will not have /etc/oraInst.loc file, instead the file must be available under $ORACLE_HOME & the file MUST BE pointing towards the source server paths. For example, my cloned instance oraInst.loc contents are like below:

>cat oraInst.loc
 inventory_loc=/u05/oraprod/oraInventory
 inst_group=oinstall

where inventory_loc path wrong for the current server.

You may create something equivalent to what already exists with the oraInst.loc file, for example (in my case) a path like /u01/oratest/oraInventory as “Oracle” user.

So, you need to amend the oraInst.loc file that is available with $ORACLE_HOME path like below

>cat oraInst.loc
 inventory_loc=/u01/oratest/oraInventory
 inst_group=oinstall

Now you can proceed building the Central Inventory.

logon as Oracle user

SHUTDOWN THE DATABASE & ALL OTHER ORACLE DATABASE RELATED SERVICES

  1. source the environment
  2. switch to $ORACLE_HOME/appsutil/clone
  3. execute ouicli.pl (./ouicli.pl)

Now, We will attach the current ORACLE_HOME with the Central Inventory. Many things could go wrong here, so make sure that you refer the document “How to create, update or rebuild the Central Inventory for Applications R12” in case if you are stuck for reasons those are not mentioned in this post.

As Oracle user

switch to $ORACLE_HOME/oui/bin

Execute 

./runInstaller -ignoreSysPrereqs -silent -attachHome -invPtrLoc $ORACLE_HOME/oraInst.loc \
 ORACLE_HOME=$ORACLE_HOME ORACLE_HOME_NAME=""

Example:

./runInstaller -ignoreSysPrereqs -silent -attachHome -invPtrLoc $ORACLE_HOME/oraInst.loc \
 ORACLE_HOME=$ORACLE_HOME ORACLE_HOME_NAME="TEST_Oracle_HOME"

If there are no issues, you should get ” ‘AttachHome’ was successful ” confirmation once after the installer finishes the execution.

Test opatch once again

>opatch lsinventory

The above should provide you an output like below:

[oratest@bak bin]$ opatch lsinventory
 Oracle Interim Patch Installer version 11.2.0.3.25
 Copyright (c) 2020, Oracle Corporation.  All rights reserved.
 Oracle Home       : /u01/oratest/TEST/db/tech_st/11.2.0
 Central Inventory : /u01/oratest/oraInventory
    from           : /u01/oratest/TEST/db/tech_st/11.2.0/oraInst.loc
 OPatch version    : 11.2.0.3.25
 OUI version       : 11.2.0.4.0
 Log file location : /u01/oratest/TEST/db/tech_st/11.2.0/cfgtoollogs/opatch/opatch2020-11-11_10-42-05AM_1.log
 Lsinventory Output file location : /u01/oratest/TEST/db/tech_st/11.2.0/cfgtoollogs/opatch/lsinv/lsinventory2020-11-11_10-42-
 Local Machine Information::
 Hostname: bak.localdomain.com
 ARU platform id: 0
 ARU platform description::
 There are no Interim patches installed in this Oracle Home.
 
 OPatch succeeded.

That’s all folks. You can proceed with your patching for the database now! Hope this helps few certified DBAs out there ;)

rajesh