Usual wisdom till R11i is that install base gets updated or created as customer product when we ship the product. This shipping must go through the inventory transaction (remember that we can ship no inventory items as well) in order for the IB to be updated or created. But to achieve the same for the order lines that do not go through shipping and inventory (like Bill Only lines with fulfillment), we used to extend Order line workflow (supported way) to plug in a function that sends a message to update or create instance. This used to be upon fulfillment.

Stating R12 this is a seeded functionality. The same function that is given to customize the workflow is added to the order line fulfillment code. Meaning all bill only lines (for that matter any line workflow that has fulfill node and item is IB trackable) automatically create or update the install base upon fulfillment. But again this is controlled by a profile option (OM: Automatically Interface Lines to IB on Fulfillment). You can control this behavior by setting this profile option value as Yes or No.

As we all know till recently we cannot change the item in IB once it is created (neither from UI nor from API) from any source (from IB UI or from Inventory). The reason is plain simple: too many dependencies. Serial number from inventory travels across from Inventory to IB when it is used in a transaction. Also if it is created in IB, it goes and sits in Inventory as well. Also counters are associated with inventory item and they get instantiated when IB is created for that item. This list is partial and goes on and on.

As you can see changing item associated with IB instance has some consequences. Nevertheless, people do make mistakes using wrong serial number when item is transacted and IB gets created or updated with that and subsequent issues ensue. Genuinely sometimes there is a need to change the item, if everything else seems OK.

Till R11i it is not possible and hence people have to do some creative work like issuing it out in inventory and receiving correct serial number or other methods like updating the serial number and expire it in IB and recreating it. Without question, this is a bit painful.

Now this is possible in R12. There is a new transaction type introduced for the application Complex Overhaul and Repair called Item Serial Change. If you use this transaction type in item instance update API, you can change item. But if you use CMRO product this transaction type can be used to execute a transaction to change the item. Of course, if there is a depot repair order open on this serial number, CMRO also cannot change the item. I am not fully clear on the business process that demands item change in that application, but if you have used it, please share. You can see a small presentation here and the script used is here.

Do you know that in R12 defaulting rules are extended to Quoting (ASO) (and hence to iStore?)? These defaulting rules work just like the existing defaulting framework in Order Management.

By default you get a number of conditional templates that you can use to default values (like default price list based on Order type). If the attribute is not available for building default condition template, you can have your own custom dependency rules.

To achieve this you have to write your rules into the aso_dependency_mappings table using a sql file (asodepmp.sql). This sql file can be found in $ASO_TOP/patch/115/sql/ directory. Add your dependency there and run the SQL again. This will create rows into the table mentioned above. After you run the SQL you have to run the program Order Capture Dependency Generator. This will create or alter the package bodies for packages ASO_QUOTE_HEADER_DEP_HDLR and ASO_QUOTE_LINE_DEP_HDLR.

Personally I have not tested all these yet, but if you have already tested and proved, please share your experience. This is a very good feature which we have been waiting for years.

Welcome to my blog! Here I will be posting some useful tips and information on implementing and using different Oracle Applications.