If you are anything like me you were trained from the beginning that forms development was done on a shared server.  In the cases that you came onto a client where such a mechanism was not enabled you would go through the effort of ftp’ing all of the relevant forms and libraries to your desktop and make your modifications within Oracle Forms Builder installed on your local machine.  You would compile your form to make sure it had no errors, but you would move your form back to the server and generate your fmx there.  Up until recently I never questioned that methodology as it always worked fine.

On a client site part of a consultant’s job is to mentor the legacy staff.  In a lot of cases these individuals have no exposure to Oracle technology.  Recently an employee at a client came to me because he was having several issues working on a form on his desktop.  His issues were as follows:

1.  When opening the form it gave him a message that it was unable to find other forms and another that stated it was unable to find libraries.

This was a simple enough fix.  We had him to go his windows registry (run->regedit) and modify the FORMS_PATH variable to include the location of the forms and libraries.  This was of course after we made sure he downloaded all the forms and libraries in question.

2.  After successfully compiling the form, he attempted to run it and was given an error as follows:  “FRM-10142: The HTTP listener is not running on <local computer name> port 8889.  Please start the listener or check your runtime preferences.”

This again was an easy one.  Forms Builder 10G is web based so the app server instance has to be running to serve up the form.  First we modified the DEFAULT.env file located in the ORACLE_HOME/forms/server folder to make sure that the FORMS_PATH variable matched what we did in the system registry earlier.  Then we went to Oracle Forms Builder from the windows start menu and choose “Start OC4J Instance”.

Once this was done we were able to run the form and the apps server instance served it up, but we promptly received another error:

3.  After app server served up the form, a form trigger error occurred:  “FRM-40375: ON-ERROR trigger raised unhandled exception ORA-06508.”

Now the first thing we checked was ORA-06508 which states the following:

It was only after we opened and compiled all of the attached libraries and forms that this error went away and the form served up correctly.  The error occurs because of an incompatibility between forms and libraries compiled on a Linux box vs. a windows box.  This is why the forms served up just fine on a Linux server implementation of forms but not on the local windows install.  As you can imagine some of the native forms have a large number of forms and libraries attached making it impractical to do this all of the time.

For a custom form that does not leverage many native EBS libraries or forms you would not have a difficult time doing the development on your desktop.  However, for extension to native forms, stick with doing your development on the Linux server.

Deferred COGS is a new feature introduced in Release 12. The basic fundamental behind the enhancement is that the COGS is now directly matched to the Revenue.

Prior to this enhancement, the value of goods shipped from inventory were expensed to COGS upon ship confirm, despite the fact that revenue may not yet have been earned on that shipment. With this enhancement, the value of goods shipped from inventory will be put in a Deferred COGS account. As percentages of Revenue are recognized, a matching percentage of the value of goods shipped from inventory will be moved from the Deferred COGS account to the COGS account, thus synchronizing the recognition of revenue and COGS in accordance with the recommendations of generally accepted accounting principles.

Whist this helps solve some key accounting issues, There are some key issues one needs to be aware of:

• Currently Deferred COGS accounting cannot be turned off in release 12.

• The activity of recording COGS recognition is now a multi-step process

• Run AR Revenue Recognition, and Submit Accounting Processes

• Run a set of concurrent processes in Cost Manager to record Sales Order and revenue recognition transactions and to create and cost COGS recognition transactions. These COGS recognition transactions adjust deferred and earned COGS in an amount that synchronizes the % of earned COGS to earned revenue on Sales Order shipment lines.

• Record Order Management Transactions: records new sales order transaction activity such as shipments and RMA returns in Oracle Order Management.

• Collect Revenue Recognition Information: determines the percentage of recognized or earned revenue related to invoiced sales order shipment lines in Oracle Receivables.

• Generate COGS Recognition Events: creates and costs COGS recognition events for new sales order shipments/returns and changes in revenue recognition and credits for invoiced sales order shipment lines.

The end result of these activities is a series of COGS Recognition Material Distributions. However these distributions will not be visible on the Material Transaction screen, unless the ‘Include Logical Transaction’ checkbox is checked.

Recently “The Business Week” June 15, 2009 ran an article titled ‘Taking AIM at outsourcers on US Soil’ If passed, the bill would bar companies with more than 50 employees in the U.S. from landing any additional work visas if more than half their US workforce is made up of H-1B or L-1 visa holders.  It definately appears there will be some controversy up on the hill.  If acted upon it would put a stop to the addition of H-1B resources coming to the US.  Senators Dick Durbin (D-Ill.) and Chuck Grassley (R-Iowa) are the two authoring the bill.  It would be good to hear your opinion on the subject…..I have mine!

After back and forth volleys with Oracle Support in getting Configurator to work correctly in R12 with SSL and load balancers (as well as great support from our DBA Team) I thought it would be good to share what is missing from some documentation within metalink (at least at time of this post) and hope it saves you time in the setups.

1) Review Section 4.4.3.1 AltBatchValidateURL, Oracle® Configurator Implementation Guide, Release 11i, Part No. B13604-03 and also Oracle® Configurator Implementation Guide Release 12 Part No. B28682-02 page 4-15.  Note that the R12 documentation should be updated as the URL needs to be slightly different for R12 as in step 2 below.  This is what caused our issue!

2) Check the value of the setting in cz_db_settings for AltBatchValidateURL. Use this statement to check it:
SELECT * from cz_db_settings where upper(setting_id) = ‘ALTBATCHVALIDATEURL’   If no rows are returned then run the following sql insert statement:
INSERT INTO cz_db_settings (setting_id, section_name, data_type, value, desc_text) VALUES (’AltBatchValidateURL’,’ORAAPPS_INTEGRATE’,4,’http://hostname:portnum/OA_HTML/configurator/UiServlet’,’Non-secure URL’)

If a row is returned then validate that the value is correct based on the above url.  If not then you can update the cz_db_settings table as follows: update cz_db_settings
set value = ‘http://hostname:portnum/OA_HMTL/configurator/UiServlet’ where setting_id = ‘AltBatchValidateURL’

3) Validate the the profile option for “BOM:Configurator URL of UI Manager” is set to: http://hostname:portnum/OA_HTML/configurator/UiServlet

Hopefully the R12 documentation is updated in the near future to guide others in the process.

Recently on a R12 project the business had a requirement to enable the attachment functionality on one of the WIP forms.  I would like to share 4 steps that can be done to enable attachments to work on just about any Oracle EBS form.

First, verify that you have the “Application Developer” responsibility assigned to your userid.  If not, then log in with System Administrator responsibility and grant yourself the “Application Developer” responsibility or have someone with System Administrator rights grant you that responsibility.

Steps to enable Attachments in WIP “View Move Transactions” Form (WIPTQSFM).

1. Determine which form, block and base table the attachments will be for.  Log into Oracle R12 with WIP responsibility and navigate to “View Move Transactions” form.  Navigation: Work in Process –> Move Transactions –> View Move Transactions.  Query up a record.  Using the “Examine” functionality under the “Help” Menu and “Diagnostics” sub-menu find the block where you want to have attachments enabled.  In this case W_MOVE_TXNS_V is the block for form WIPTQSFM.  In addition, determine what the base table is for this form.  Once you have noted what form, block and base table to use it’s time to switch to “Application Developer” responsibility as the following steps assume you have switched responsibilities.

2. Create Document Entity -  Navigation: Attachments –> Document Entities.  Query up the base table you determined in step one.  If there is no record then add a record for the base table.  In this case we have inserted a new record for “WIP_MOVE_TRANSACTIONS” base table.  The entity ID we used “WIP_MOVE” and for the entity name we used “Move Transactions” and the prompt also “Move Transactions”.  The application should be self explanatory, but just in case use “Work in Process”.

3. Create Document Category (Document categories provide security by restricting the documents that can be viewed or added via a specific form or form function. When a user defines a document, the user assigns a category to the document. The attachments form can only query documents that are assigned to a category with which the form or form function is associated).

Navigation: Attachments — > Document Categories.  Query up the category starting with “WIP%”.  If no category exists then create a category.  In this example I have used “WIP Move” as the category name and assigned to the Work in Process application.  Save the record

4. Create Attachment Function - Navigation: Attachments –> Attachment Functions.  Query up functions starting with “WIP%” if the function you are looking for does not exist you will need to create new record.  In this example I have created a new function called “WIP_WIPTQSFM” designating the form from step 1 above.  The User Name field we called “View Move Transactions” and verified the “enabled” checkbox was checked.  Next click on the Categories button and assign the category from the previous step to this function. (We used “WIP Move”.  Next click on the Blocks button and enter the block name from step 1 above (”W_MOVE_TXNS_V”) and set the method to be “Allow Change”.  Next click on the entities button.  Use the LOV and select “Move Transactions” as the Entity defined in step 2.  The display method can be set to “Main Entity”.  You can leave the “Privileges” and SQL statement tabs default.  However, you will want to change the primary key fields to the following: Key 1: PARAMETER.ORG_ID and Key 2: W_MOVE_TXNS_V.TRANSACTION_ID.  Note: You must have at least one key defined.  Enter the names of the fields in the calling form from which the primary keys for the entity can be derived. Use the syntax block.field. You must include the block name (for example, W_MOVE_TXNS_V.TRANSACTION_ID). Use the unique column on the base table if you must.

Once you have completed these steps you can test out the “enabled” attachment functionality by switching to a Work in Process responsibility and navigate to “View Move Transactions”, query up a transaction and the attachment icon should now be active.

You can also find out more on attachments by searching metalink.