Key accounts - P2P Cycle

Here are some of the key accounts used in P2P(Procure to Pay) Cycle.

RECEIVING INVENTORY ACCOUNT

This is one of the clearing account.

The account is used for receipt accruals.

After receiving transactions are processed and the Transfer Transactions to GL process is run, the Receiving Inventory Account is cleared and the Material account is charged with the cost of the capitalized inventory .

You can specify this account when you define Receiving Information for your inventory organizations.

INVENTORY AP ACCRUAL

This is the account used by Purchasing to accrue your payable liabilities when you receive items you will capitalize as inventory.

This account represents your uninvoiced receipt liability and is usually part of your Accounts Payable Liabilities in the balance sheet.

Oracle payables relieves this account when the invoice is matched and validated.

So, you have to specify this account when you define Inventory Information for your inventory organizations in the Other Accounts tab.

AP LIABILITY ACCOUNT

This account defaults from the supplier site and is credited when a standard invoice is entered or debited when a credit memo or debit memo is entered. The account is relieved when the invoice is paid.

When you are creating an invoice, the liability account will get defaulted based on the hierarchy i.e., it can be from Financial options/Supplier /Supplier site.However you will still have an option to modify the Liability account by replacing the defaulted account.

(0r) do you see a different account getting defaulted during Invoice creation

EXPENSE AP ACCRUAL

This is the account used by Purchasing to accrue your payable liabilities when you receive items you will expense. This account represents your uninvoiced receipt liability when you run the Receipt Accruals - Period End process.

When you receive the goods,the accounting entry will be
Receiving Inv Dr
To Expense Accrual Cr

In Payables

Expense Accrual Dr
To Liability Cr.

So the Expense Accrual will knock-off

You can specify this account on the Accrual tab when you set up Purchasing Options.

MATERIAL ACCOUNT

An asset account is used for to tracks material cost .

In the average costing, this account holds your inventory and in transit values. Once you perform transactions, you cannot change this account.

You can specify this account when you define Inventory Information for your inventory organizations in the Valuation Accounts region for the Costing Information tab.

CHARGE ACCOUNT

This is the charge account is the account that will be charged for the purchase on either the balance sheet or income statement.

If the destination type for the distribution is Inventory, this account will be the Material account associated with the subinventory and you cannot override it. This is the balance sheet account that will be charged after inventory is capitalized.
If the destination type is expense, you can specify this account (provided it isn’t project related) and override any defaults. This account will be either an asset clearing account that will be included on the balance sheet or an expense account that will be included on the income statement. This account is either created or specified when you create a purchase order.
Look at the Material Account on the destination inventory organization, or (if specified), destination subinventory.
Under Inventory: Setup/Organizations/Parameters or Sub inventories

PURCHASE PRICE VARIANCE

This account is used to record differences between purchase order line price and standard cost.

The Purchase Price Variance is calculated when items delivered to inventory are costed.

You should note, this account is not used with the average cost method.

For example, assume the purchase order line price for an item was set at $100 per item but standard cost was set to $120 per item and you purchased 10 items. The Purchase Price Variance would be $200.

You can specify the Purchase Price Variance account when you define Inventory Information for your inventory organizations in the Other Accounts tab.

INVOICE PRICE VARIANCE

The variance account used to record differences between purchase order price and invoice price.

This account is used by Payables to record the invoice price variance for inventory items.

For expense items, the account generator uses the charge account to record any invoice price variance.

You can understand with this set of example, how its works;

1). Create a purchase order with expense type item having the above
Navigation: Purchasing->Purchase Orders->Purchase Orders

2). Receive the goods for this PO.
Navigation: Purchasing->Receiving->Receipts

3). Login as Payables manager, create an invoice and match it to the PO created in step 1.
Navigation:Payables->Invoices->Entry-Invoices

for example

PO Quantity=100
PO Price = 5

Now you match an invoice to the PO and Invoice(match) details are as follows:
Matched Quantity=100
Price on Invoice= 1

in this case, probably you have set the Invoice price variance account in define Organization Parameters form( alternate region: other accounts) same as the expense account on the PO

Invoice Price Variance= (PO Price - Invoice Price) x Qty. Invoiced

You can specify this account when you define Inventory Information for your inventory organizations in the Other Accounts tab.

‘File ->Export’ Function is troubling

‘File ->Export’ Function is troubling
Posted on November 13th, 2008 by Sanjit Anand | Print This Post | Email This Post

Hard Time this week for me ,struggling with Finance user from another entity to see unexpected things reported , Out of the box File -> export function was not working properly, some of them reported Browser crashing some of them reported data not exported 100% from form, some of them reported longer duration to export for nearly 500 records from Invoice Inquiry or Invoice Entry form.

There are few cases which user can experience

File - Export does not bring up a Save As prompt
File -Export may leads to Browser crashes
File - Export takes long time to export into Excel
File - Export not exporting 100% data from form
File - Export creates zero byte file
File -Export on selecting "Continue to End" causes system to hang
More less, these problems are encountered by some additional setup requirement in IE . Here are few troubleshooting points, if you are using IE 6 or 7.

1. Make sure your browser will have setup completed for these 2 categories:

ActiveX controls
Downloads
You should follow these Steps:

Go to IE Tools menu - Internet Options - Security - Custom Level
Adjust all the settings for ActiveX Controls and Downloads to be either 'enable' or prompt for zones Internet, Local Intranet, and Trusted Zones
Restart the browser and now test if the export process works
2. Make sure if users desktop are using a proxy server to access the web via MSIE. If you set "Bypass proxy server for local addresses" in Internet Options -> Connection -> LAN Settings check if the File > Export works without error.

3. Make sure you have set System Profile Options 'Export: Mime type' to 'text/tab-separated-values' or or 'application/vnd.ms-excel'

4.Delete Browser Cache > Tools > Internet Options > zone=temporary internet files : delete files {checked offline content}

5. You should also delete C:program files/oracle/jinitiator/jcache/*

6. Make sure you disable Pop-up Blocker

7. If you have still an issue , try this based out of note :338545.1

Make sure you have checked step 1,2,3.
Login to AP responsibility and try exporting from the data from Invoice workbench after search for invoice batch.
Are you able to export?
If not ,Go to (Tool Bar) Help -> Diagnostics -> Examine
Set Block = ENVIRONMENT
Set Field = FND_EXPORT_DEBUG
Set Value = TRUE
Export and observe the messages that are generated during the export process.
What is the last pop up message ?
Try to run the following piece of code in SQLPLUS*
declare
db_file number;
mime_type varchar2(255) :='text/plain' ;
out_string varchar2(32767) :='Just some plain text that is stored' ;
web_server_prefix varchar2(500);
url varchar2(500);
begin
fnd_global.apps_initialize(user_id => ,resp_id => ,resp_appl_id => );
DBMS_SESSION.SET_NLS('NLS_LANGUAGE','AMERICAN');
db_file :=fnd_gfm.file_create(content_type =>mime_type,program_name=> 'export');
fnd_gfm.file_write_line(db_file,out_string);
db_file :=fnd_gfm.file_close(db_file);
url:=fnd_gfm.construct_download_url(fnd_web_config.gfm_agent,db_file,TRUE);
dbms_output.put_line(url);
end;

If still not able to fix, ask Oracle for further resolution.

8.If you are not able to 100% export in excel do a quick check

Run this query immediatly after Export get completed
select count(*) from fnd_lobs where program_name='export';

If counts not matches then you need to recreate the index using script $FND_TOP/sql/aflobbld.sql. This is because the File/Export functionality of EBS uses system LOB columns to store temp data before it is outputed to a browser. If that temp data becomes large enough as the result of large export query set, then the max_extents limitation of the column is reached thereby causing the export to fail.

Most of my user experinces these issues with WIN2K or XP SP1 and SP2, but not with SP3.No clue for me with service pack.

Is there any linkage with window XP or 2000 .Net Framework installation and Service pack in client desktop for this feature? Do share some thoughts if anyone got such kind of issue in past.

Multi-Org Credit Checking and Global Exposure [ID 209479.1]

Global exposure involves credit check using overall exposure calculated from
ALL ORGANIZATIONS (this is the term associated with Gobal Exposure) or credit
exposure calculations using SINGLE organization.

There are two levels available for this type of credit checking:

1. Customer level credit checking and the overall credit limit defined at
this level will be used.

2. Org Default level credit checking and the overall credit limit defined
at this level will be used.

3. Site level and Item category level are not applicable to global exposure
because customer sites are specific to an organization only and currently
the item category credit checking is limited only to the specific sale order
being credit checked.

4. Global Exposure usage:

Site Level: Not Available
Customer Level: Available
Item Category Level: Not Available
Customer Default Level: Available

5. In order to enable Global Exposure, Navigate to Order Management Super User &
gt;
Setup > Credit > Define Credit Usage Rules. Enable a checkbox option
called
"Global Exposure". If a rule has been assigned to a credit profile,
then modification of the rule set is not allowed. If a rule is new or
not assigned to a credit profile, then modification is allowed.

6. There are two different currency modes that can be implemented.
Navigate to System Administrator > Profile > System and query
up the profile AR: Credit Limit profile. The valid values are either
SINGLE or MULTI.

7. If currently using SINGLE currency mode, the following needs to be performed:

a. Navigate to System Administrator > Profile > System and query up the
AR: Credit Limit Selection. Set this to MULTI.

b. Navigate to Order Management Super User > Setup > Credit - Define
Usage Rule Sets. Create a usage rule set and check the 'Global Exposure&
quot;
checkbos.

c. Navigate to Order Management Super User > Setup > Credit >
Assign the usage rules. Assign the usage rules to the Customer profile
and/or Org default profile type.

d. Navigate to Order Management Super User > Setup > Credit >
Initialize the Summary tables if using Pre-Calculate Exposure. This
will populate
the summary table with credit exposure information. The Pre-Calculate
Exposure and use of the summary tables is controlled by a flag
in Order Management Super User > Setup > Credit > Define Credit
Check
Rule > Exposure tab.

e. Navigate to Order Management Super User > Reports and select the
Credit Exposure Report to verify the exposure amounts.

8. If in MULTI currency mode, a new Usage Rule set can be created or
and existing Usage Rule set can be updated. In order to create a new
Usage Rule Set:

a. Navigate to Order Management Super User > Setup > Credit >
Define Usage Rule Setups
b. Check the Global Exposure checkbox

c. Create/Update the required Customer level credit profile limits
in one of two ways. Navigate to Order Management Super User >
Setup > Customer > Profile Class and create a profile class
by navigating to Order Management Super User > Setup > Customer >
Profile Class.

d. Either create a Customer Level credit profile limit or create
the Default Organization level credit profile limits.

e. To establish a Customer Level credit profile, either establish
credit limits using a profile class group name or define credit
limits on a specific customer.

f. Navigate to Order Management Super User > Setup > Credit > Profile
Class. Name the class and click the credit check checkbox in the Profile
Class tab. Change to the Profile Class Amounts tab and enter a
credit limit that will be associated with this class. An example
of profile classes might be Excellent (credit rating), Average (credit
rating), or High Risk (credit rating).

g. Associating the profile class with the customer will.
establish this
credit limit to a group of customers. The advantage is that one
change to a profile class will establish the new credit limit to all
customers associated with the profile class rather than changing each
customer individually.

h. To associate the profile class to the customer, navigate to Order Management
Super User > Customer > Standard. Query up the customer and enter
the profile class in the Profile: Transaction tab and check the
Credit Check checkbox.

i. If there are exceptions to the profile class assignments or a customer
has specific credit limits, in the Order Management Super User >
Customer > Standard > Profile Amounts tab, enter an overall credit
limit and order credit limit. This amount will override any profile
class that has been established.

j. To establish a default Organization level credit, navigate to
Order Management Super User > Credit > Define Profile Class and
create a profile class of type Organization Default. Now establish
the credit limits. These credit limits will be used during the
credit checking process if there is no customer credit limit
established.

k. Assign the usage rules to the Customer and/or Org default type profiles
by navigating to Order Management Super User > Credit > Assign Usage
Rules.

l. Run the Initialize Credit Summaries by navigating to Order Managment
Super User > Credit > Initialize Credit Summaries. This will perform
the pre-exposure calculations that populate summary tables. If using
pre-exposure calculations make sure the flag is set in Order Management
Super User > Credit > Define Credit Check Rules > Exposure tab.

m. Run the Credit Exposure Report to verify exposure amounts by
navigating to Order Management Super User > Reports, Requests >
Reports > Credit Exposure report.

9. In order to update an existing Usage Rule set in MULTI currency mode:

a. The usage rule set can be currently either not assigned or assigned to
any credit profile.

b. If the Usage rule set is not assigned yet to any credit profile,
navigate to Order Management Super User > Credit > Define Usage
Rule Set and check the Global Exposure checkbox. Also, assign
the usage rule with the customer profile and/or org default using
Order Management Super User > Credit > Assign the Usage Rule.

c. Next, run the Initialize Credit Summaries by navigating to
Order Management Super User > Credit > Initialize Credit Summaries.
This will populate the summary tables with pre-exposure information.
When using pre-exposure calculation, make sure the flag is set in
Order Management Super User > Credit > Define Credit Check Rules >
Exposure tab.

d. Run the Credit Exposure Report by navigating to Order Management
Super User > Report,Request > Credit Exposure Report.

e. If the usage rule set is already assigned, unassign the usage rule
set. The system does not allow updates to an existing usage rule
set that has already been assigned. Navigate to Order Management
Super User > Credit Assign usage rule set and unassign.

f. Update customer credit limits.

g. Update Usage Rule Sets within Order Management Super User > Credit >
Define Usage Rules and check the option Global Exposure.

h. Reassign the usage rule with the appropriate Customer profile and/or
Org default using Assign Usage Rules under Order Managment > Setup
Credit > Assign Usage Rules.

i. Navigate to Order Management Super User > Credit > Initialize
Credit Summaries to populate the summary tables with the pre-calculate
credit exposure information.

j. Navigate to Order Management Super User > Reports,Requests > Reports
and run the Credit Exposure Report and verify the exposure amounts.


10. During Booking and Pick release/shipp.
ing process, the multi-currency
credit engine api is called and gets the exposure. It uses the following
as input data:

Order Management Orders from ALL Organizations
AR Exposure from ALL Organizations
Usage Rules (Order Managment > Credit > Define Usage Rules)
Credit Profiles (Order Management > Credit > Define Credit Profiles)
Usage Rule Assignments (Order Management > Credit > Assign Usage Rules)
Credit Check Rule (Order Management > Credit > Define Credit Check Rule)

Note: The credit check rule is associated with a transaction type in
Order Management Superuser > Setup > Transaction Type > Define &
gt;
Credit Check Rule block.

10. There have been some modifications to existing tables. Columns have
been added.

a. The CUST_ACCT_PROFILE_ID column in HZ_CUSTOMER_PROFILES maps to this
same column in HZ_CUST_PROFILE_AMTS.

b. The PROFILE_CLASS_ID column in HZ_CUST_PROFILE_CLASSES table maps to
this same column in HZ_CUST_PROF_CLASS_AMTS.

c. The CREDIT_PROFILE_ID column in HZ_CREDIT_PROFILES table maps to
this same column in HZ_CREDIT_PROFILE_AMTS.

d. The above six tables can be mapped to the HZ_CREDIT_USAGES table using
the CUST_ACCT_PROFILE_AMT_ID column from HZ_CUST_PROFILE_AMTS
and PROFILE_CLASS_AMOUNT_ID from the HZ_CUST_PROF_CLASS_AMTS and
CREDIT_PROFILE_AMT_ID column from the HZ_CREDIT_PROFILE_AMTS.

e. HZ_CREDIT_USAGES contains a unique record derived from the above
tables. The CREDIT_USAGE_ID column uniquely identifies the rows and
the row will also contain a column called the CREDIT_USAGE_RULE_SET_ID.

f. The column CREDIT_USAGE_RULE_SET_ID points to a column in the
HZ_CREDIT_USAGE_RULE_SETS and this is where the GLOBAL_EXPOSURE_FLAG
can be found. From this table can be derived the CREDIT_USAGE_RULE_ID column
that will map to the HZ_CREDIT_USAGE_RULES.


11. Here are the package bodies and modified procedures that include the global
exposure credit checking functionality:

OE_CREDIT_ENGINE_GRP
OE_CREDIT_CHECK_ORDER_PVT (Check_order_exposure)
OE_CREDIT_CHECK_LINES_PVT (Check_Order_Lines_Exposure)
OE_CREDIT_CHECK_UTIL (Get_order_exposure and Get_Limit_Info)
OE_CREDIT_EXPOSURE_PVT (Get_Exposure).

Is It Possible to Setup A Different Credit Limit For Each Customer/Site Level?

Can One Setup A Different Credit Limit For Each Customer/Site Level And Assign The Same
Usage Rule For All Customers?

See specific details questions for this scenario below:

a. Do they need to assign the same usage rule to each customer's credit profile? This would
take a lot of work.

OR

b. If no usage rule is assigned for the customer credit profile, will the operating unit
default will be used, while the credit limit of the customer/site level is used?

OR

c. I think the other way is to set assign usage rule to the profile class and do
Tools > Cascade credit usages, but let's say for now, that we don't have a credit
profile defined for the profile class. This would essentially be the same as a. only
taking away the manual work.

As per design:

Credit Limits can be set at the following 5 levels:

1) Item category
2) Bill to Site
3) Customer account
4) Party
5) Operating Unit

The above sequence is also followed while deriving the credit check details like credit
limit and order limit. Metalink note 365866.1 explains the same in a detailed way.

Now, coming to credit usage rule.Credit usage rule is needed only when multi-currency
exposure calculation or global exposure calculation(calculation of exposure across
operating units) is needed.

The credit check process behaves the following way:

1) It follows the hierarchy mentioned in the metalink note 365866.1.
2) At every level first it checks if any credit usage rule is attached at that level
or not.If there is any attached ,then it gets the credit limits order limits and the
multi-currency details from the credit usage rule set up else it gets the details
from that level credit profile set up.

E.g : Lets say customer level credit checking is enabled.So if any credit usage rule
is attached to customer or customer profile (attached to customer),then the credit
checking details are derived from usage rule set up.If no usage rule is attached to
customer or customer profile,then single currency(Transaction currency) credit
checking happens and details are picked from the customer standard form only

What is the Purpose of Pre-Calculated Exposure in Credit Checking?

The use of Pre-Calculated Exposure was incorporated to improve performance. Previous versions of credit checking calculated customer exposure accessing underlying transactional tables. When a credit check request was executed, underlying transaction tables were summed to generate customer balance information.

Using the pre-calculated exposure option, credit checking will validate exposure against balance information stored in a summary table. The summary table is updated as often as your business practices require, and updates to the table are performed by submitting the Initialize Credit Summaries concurrent program. This program accesses both Oracle Receivables and Order Management transactional tables. It should be scheduled to run periodically, based on your specific business needs. Please refer to Note.293409.1: 'How Often Should Initialize Credit Summaries be Run?'

Pre-calculated exposure amounts can be either:
- Real time transactional data summarized at a specific point in time
- Exposure amounts imported into Oracle Order Management exposure tables
- Real time transactional data summarized at a specific point in time plus exposure amounts imported into Oracle Order Management exposure tables

If Credit Check Rule is set at the Sales Order Level, the use of Pre-Calculated Exposure is not mandatory and you can uncheck the flag. If Credit Check Rule is set at the Sales Order Line Level the Pre-Calculated flag cannot be unchecked.

The Exposure Tag

Use Pre-Calculated Exposure
===========================
This prevents the exposure from being calculated in real time. The Initialize Credit Summaries process must be run on a regular basis to obtain latest account balances from Accounts Receivable.

For Example:

The Initialize Credit Summary Process has been run.

The Credit Exposure Report shows that the Customer has an available balance of <$50> (i.e this amount is owed) and has an overall limit of 100 at site level. Orders booked for this customer will be placed on Hold.

The customer now makes a cash payment of $75 which is recorded and cleared in Receivables.

At this point a new order is created and booked. This order is place on credit check hold, Why ? Running the Credit Check Exposure report for the customer and credit rule shows that no change has been made to the available amount. If at this point you then run the Initialize Credit Summaries report followed by the credit Exposure Report. You will see that the balance Will change and in this example a credit amount of $25 is available. The Initialize Credit Summary process has updated credit tables in Order Management and the newly calculated balance will be used to determine if an order should be placed on hold.

Include Open Receivables Balance and Include Uninvoiced Orders
==============================================================
Either one or both of the attributes must be selected (the application will ensure that at least one of these is chosen).

Include Open Receivables Balance:
---------------------------------
The Open Receivables balance will be used to calculate the credit amount available to the customer. The balance used is the customer balance taking into account any cleared payments. If Pre-Calculated flag is set the receivables balance used will be the balance of the account when the Initialize Credit Summary process was last run.

Include Payments at Risk:
-------------------------
Selecting this attributes will also include in the customer balance payments, that are at Risk, i.e payments that have not yet been cleared.

Include Uninvoiced Orders:
--------------------------
If selected uninvoiced orders will be included in amount of credit that is available. I.e Uninvoiced orders that have been booked will reduce the amount of credit available.

==========================

The following are examples of how credit rule setup impacts exposure as shown in the Credit Exposure Report.

The receivables balance for the Customer is <5.61> - credit
Value of Orders Booked but not invoiced is $405 - this includes a single order for $45 that is on credit check hold. The credit holds have been cleared for the other orders.

EXAMPLE 1.
==========

Do NOT Use Pre-Calculated Exposure
Do Not Include Open Receivables Balances
Include Uninvoiced Orders
Do Not Include Orders Currently On Hold

| |---------------Credit Limit Currency ---------------|
| Overall Limit Exposure Available
--- --------------------- -------------------- -------------------

USD 47.00 360.00 <313.00>

EXAMPLE 2.
==========

Do NOT Use Pre-Calculated Exposure
Include Open Receivables Balances
Include Uninvoiced Orders
Do Not Include Orders Currently On Hold


| |---------------Credit Limit Currency ---------------|
| Overall Limit Exposure Available
--- --------------------- -------------------- -------------------

USD 47.00 354.39 <307.39>

EXAMPLE 3.
==========

Do NOT Use Pre-Calculated Exposure
Include Open Receivables Balances
Include Uninvoiced Orders
Include Orders Currently On Hold


| |---------------Credit Limit Currency ---------------|
| Overall Limit Exposure Available
--- --------------------- -------------------- -------------------

USD 47.00 399.39 <352.39>


EXAMPLE 4.
==========

Use Pre-Calculated Exposure
Include Open Receivables Balances
Include Uninvoiced Orders
Include Orders Currently On Hold

At the point a number of orders have been created and booked in Order Management. The following demonstrates how the Initialize Credit Summary process impacts Credit Exposure.

1. Value of orders created in OM, but not interfaced to AR is $225.
2. Initialize Credit Summary process is executed
3. Credit Exposure report shows exposure as $219.39 ($225 less $5.61 credit balance in AR)
4. New Orders Created in OM to the value of $180
5. Credit Exposure Report re-run and this still shows the credit exposure as $219.39
6. Initialize Credit Summary Process is executed
7. Credit Exposure Report re-run and this now shows the credit exposure as $399.39 ($225 + $180 lesss $5.61 credit balance in AR)


CREDIT EXPOSURE PRIOR to Initialize Credit Summary Process

| |---------------Credit Limit Currency ---------------|
| Overall Limit Exposure Available
--- --------------------- -------------------- -------------------

USD 47.00 219.39 <172.39>


CREDIT EXPOSURE AFTER Initialize Credit Summary Process

| |---------------Credit Limit Currency ---------------|
| Overall Limit Exposure Available
--- --------------------- -------------------- -------------------

USD 47.00 399.39 <352.39>


=============================


REPORTS / PROCESSES:
====================

Initialize Credit Summaries Table Concurrent Program
Order Management enables you to periodically rebuild a credit exposure image

Credit Check Processor Concurrent Program
The Credit Check Processor program can be run on demand to re evaluate Booked orders that have not been shipped yet.

Credit Exposure Report
The Credit Exposure report can be used to analyze your customers total credit exposure.

How Often Should Initialize Credit Summaries be run?

Assumption: Use Pre-Calculated Exposure is checked on the Exposure tab of the Credit Check Rules form.

The frequency with which you run Initialize Credit Summaries is business dependent. However, Oracle can provide some recommendations.

1. If you want your customer's credit exposure to be very close to the online credit exposure calculation, then you will need to run it frequently (maybe this is hourly). Be careful as the parameter for Initialize Credit Summaries is Lock Tables. The tables to be locked are AR tables, so make your decision wisely as running Initialize Credit Summaries may impact your AR application users.

......If you want to lock the AR tables when you run Initialize Credit Summaries, it might be best to do this at night when no other users will be impacted.

3. When you first create a customer you would like to invoke credit checking on (or make changes to an existing customer's credit limit/order credit limit), then you will need to run Initialize Credit Summaries.

.....As a side note, if you make changes to an existing customer's credit limit/order credit limit and you want to re-credit check existing orders, run the credit check processor concurrent request.

4. If you enter all of your collections by let's say 2PM, then you should run Initialize Credit Summaries after that time to calculate a more accurate credit exposure.

5. If you enter many orders for a particular customer on a daily basis and want credit checking to include each order in the credit exposure, then you run Initialize Credit Summaries after each order or every other order.



Summary: The frequency with which you run Initialize Credit Summaries will be based on your business needs. Oracle has provided the above guidelines to give some insight as to when you might want to run Initialize Credit Summaries .

credit limit for customers by group

How to set credit limit for customers by group

For example, there are 3 customers in a group and you want to have one credit limit for the group.

Credit Limit can only be defined at Party level, Account level or Site level.

Your option would be:

Group the customers (accounts) by party then set up a credit limit for each party because you can have multiple customer accounts under one party.

OR

Set up party/child relationship between parties and assign a credit limit to the parent party. The same credit limit also applies to the child parties.

Please see Note 564463.1 for more detailed information.

Good document on Oracle Metalink for Credit check rule information

ORDER MANAGEMENT SUITE - INVOICING LIBRARY [ID 436483.1]

Credit Checking Limits Hierarchy

Credit Checking Limits Hierarchy

In Oracle Receivables, you can setup Credit limit (which is nothing but the overall
credit limit) and order credit limit at the following levels:

1. Item category level
2. Site level
3. Customer level
4. Party level (This level is applicable only if Credit Management is installed)
5. Operating Unit Default level.


For Customers in
11.5.10 - Before 11.5.10 CU2 (If OEXUCRCB.pls is less than 115.82.11510.2)
11.5.9 - Before Patch 4473667 (If OEXUCRCB.pls is less than 115.69.1159.14)

1.Item category level
If Credit Check not enabled => Go for Site Level
If Credit Check is enabled and both credit limit and order credit limit are NULL/BLANK => Go for Site Level
If Credit Check is enabled and either credit limit or order credit limit is NOT NULL => Use them

2.Site level
If Credit Check not enabled => Go for Customer level
If Credit Check is enabled and both credit limit and order credit limit are NULL/BLANK => No Credit Check
If Credit Check is enabled and either credit limit or order credit limit is NOT NULL => Use them

3.Customer level
If Credit Check not enabled => Go for Party level is
Credit Management is installed else go for Operating unit default level
If Credit Check is enabled and both credit limit and order credit limit are NULL/BLANK => No Credit Check
If Credit Check is enabled and either credit limit or order credit limit is NOT NULL => Use them

4.Party level (This level is applicable only if Credit Management is installed)
If Credit Check not enabled => Go for Parent Party,if any available, else go to Operating Unit Default limits.
If Credit Check is enabled and both credit limit and order credit limit are NULL/BLANK => No Credit Check
If Credit Check is enabled and either credit limit or order credit limit is NOT NULL => Use them

5. Operating Unit Default Level
If both credit limit and order credit limit are NULL/BLANK => No Credit Check
If either credit limit or order credit limit is NOT NULL => Use them

For customers in
11.5.10 - After 11.5.10 CU2 (if OEXUCRCB.pls is equal or higher than 115.82.11510.2)
11.5.9 - After Patch 4473667 (if OEXUCRCB.pls is equal or higher than 115.69.1159.14)

1.Item category level
If Credit Check not enabled => Go for Site Level
If Credit Check is enabled and both credit limit and order credit limit are NULL/BLANK => Go for Site Level
If Credit Check is enabled and either credit limit or order credit limit is NOT NULL => Use them

2.Site level
If Credit Check not enabled => No Credit Check
If Credit Check is enabled and both credit limit and order credit limit are NULL/BLANK => Go for Customer level
If Credit Check is enabled and either credit limit or order credit limit is NOT NULL => Use them

3.Customer level
If Credit Check not enabled => No Credit Check
If Credit Check is enabled and both credit limit and order credit limit are NULL/BLANK => Go for Party level is
Credit Management is installed else go for Operating unit default level
If Credit Check is enabled and either credit limit or order credit limit is NOT NULL => Use them

4.Party level (This level is applicable only if Credit Management is installed)
If Credit Check not enabled => No Credit Check
If Credit Check is enabled and both credit limit and order credit limit are NULL/BLANK => Go for Parent Party,
if any available, else go to Operating Unit Default limits.If party hierarchy is setup using Trading Community
Architecture, then credit checking will look into this hierarchy also, to check if there is any parent available.
If yes, then it looks into the limits of the parent also. If parent limits are also NULL, then it goes for
Operating Unit Default level
If Credit Check is enabled and either credit limit or order credit limit is NOT NULL => Use them

5. Operating Unit Default Level
If both credit limit and order credit limit are NULL/BLANK => No Credit Check
If either credit limit or order credit limit is NOT NULL => Use them

Credit Checking Setup in Order Management

In order to trigger automatic Credit checking on sales orders it is necessary that the credit checking is enabled for the order type, customer profile and payment terms associated with the transaction.
Credit check set up involves the following setup steps:

Step1:Credit Check Rules Setup
Step2:Customer Profiles Setup
Step3:Payment Terms Setup
Step4:Order Types Setup

If any one of order type, customer profile and payment terms does not have credit checking enabled, the sales order will not be credit checked . Sales orders that pass credit check at all the three points are allowed to progress normally. Those that fail will have credit check failure hold placed on either the order header or order lines.

Step 1 : Credit Check Rules Setup
(N) Setup->Rules->Credit

In the rules window enter Name of Credit Check Rule .
In the effective dates field enter today’s date(optional) as the starting date and leave the end date as blank.
In the credit check level drop down list, Select Sales order.
In the Credit hold level drop down list select the Sales order option.
Choose the conversion type as corporate.
Accept all other defaults and save your rule and close the window.

Step 2 : Customer Profiles Setup
(N) Customer->Standard

Enter the customer name or Number and Click on OK to open the customer.
In the Addresses tab, select the address for the bill to site that you want to enable credit checking and click on the Open button.

As per Note 365866.1, the conditions for the site level credit
check is as follows
After 11.5.10 CU2.
* If Credit Check not enabled(site level) => No Credit Check
* If Credit Check is enabled and both credit limit and order credit limit are NULL/BLANK => Go for Customer level
* If Credit Check is enabled and either credit limit or order credit limit is NOT NULL => Use them
In (T) Profile: Transaction ensure the Credit Check box is checked

In (T) Profile: Amounts, '''select the currency USD''' and change the order credit limit to 5000

Step 3 :Payment Terms Setup
(N) Setup->Orders->Payment Terms

Query for the Payment Term 30 Net and ensure that the credit check check box is selected.
Save your work and exit the form.

Step 4 :Order Types Setup
(N) Setup->Transaction Types->Define

Query for the Transaction Type Mixed and once the record is retrieved choose the credit check rule
Enter the name of credit check rule created in the previous step in the credit check rule region in the ordering field.
This indicates that when the order is booked, the credit check rule will be applied and when the order amount exceeds the credit limit then a hold will be applied.Save your work and close the window.

To release the credit check hold, go to Actions->Release Holds, enter a Reason,
and click on Release.

Tips For Personalizing The E-Business Suite 11i Login Page (AppsLocalLogin) [ID 468971.1]

Goal
You would like to personalize the AppsLocalLogin.jsp login page to add specific text, change the logo, etc. This document describes the supported and non supported methods to achieve one's ends.

Solution
1. Attributes of the login page

It is possible to control the display of some attributes of the login page, for instance user name or password hints, language switchers, forgot password link, corporate policy message, etc.

For this, you need to set the profile option 'Local Login Mask' (FND_SSO_LOCAL_LOGIN_MASK) with a number being the sum of the mask values described in the table below:


Description
Mask value

Hint for Username (USERNAME_HINT) 01

Hint for Password (PASSWORD_HINT) 02

Cancel button (CANCEL_BUTTON) 04

Forgot Password link (FORGOT_PASSWORD_URL) 08

Registration link (REGISTER_URL) 16

Language Images (LANGUAGE_IMAGES) 32

Corporate Policy Message (SARBANES_OXLEY_TEXT) 64



* For instance the value 32 (default) displays only the language icons and value 127 will show all the attributes on the page. Please see the attached screen shots as an example.

* The change takes effect immediately after re-login to E-Business Suite.


2. Message texts

It is possible to modify or add text on the login page by changing the value of some messages.
The following table shows the related messages and their default value:

Description Default value
FND_SSO_WELCOME Login
FND_SSO_EBIZ_SUITE E-Business Suite
FND_SSO_COPYRIGHT_TEXT Copyright (c) 2007, Oracle. All rights reserved.
FND_SSO_SARBANES_OXLEY_TEXT Corporate Policy Message



To change the value of a message:

1. Go to "Application Developer" responsibility
2. Select "Messages" from the menu
3. Query the message name and then enter your message text in the "Current Message Text" field
4. Save changes and exit
5. Clear cache and bounce Apache to see the change

* Note that some messages can be used elsewhere that in the login page
and can be updated by a patch

* If you want to change also the default branding 'E-Business Suite' on other pages, to match the text on the login page (defined by FND_SSO_EBIZ_SUITE message), then follow the steps below:

a. Login with System Administrator responsibility
b. Navigate: Application ---> Function
c. Query the function 'FWK_HOMEPAGE_BRAND'
d. Replace the value of the 'User Function Name' with the desired text
c. Logout and login to see the change (you shouldn't need to clear caches and bounce apache)

* The 'FND_SSO_SARBANES_OXLEY_TEXT' message is only displayed when the mask
value 64 is added to the profile option 'Local Login Mask'. The text will appear at the bottom of the page. Please review Note 391826.1 if you want to add a long text.




3. Corporate branding logo



The Oracle logo is displayed on various E-Business Suite pages and can be changed by setting the
'Corporate Branding Image for Oracle Applications' (FND_CORPORATE_BRANDING_IMAGE) profile option to the full path name of an image file (.gif) that contains your corporate image.

However it is not possible to use this method for AppsLocalLogin.jsp since it is hard coded with the Oracle logo image file 'FNDSSCORP.gif'.
The non supported solution consists in:


1. Go to the $OA_HTML directory
2. Backup the AppsLocalLogin.jsp file
3. Copy your own corporate branding image under $OA_MEDIA directory
4. Edit the AppsLocalLogin.jsp file :

from :

ImageBean imgBean1 = new ImageBean("/OA_MEDIA/FNDSSCORP.gif", FND_ORACLE_LOGO);

to :

ImageBean imgBean1 = new ImageBean("/OA_MEDIA/", FND_ORACLE_LOGO);

5. Clear caches and bounce Apache to see the change

* If you prefer the same corporate branding logo be displayed on all pages, including the login page, then you can backup the FNDSSCORP.gif file and modify it with your prefered graphic software.


4. Other modifications

AppsLocalLogin.jsp being a Java Server Page you can change the HTML or Java code (for instance with JDeveloper), create you own messages in the Messages Dictionnary thru AOL responsibility, etc., if you want to add other customizations. This is considered a customization and thus not supported by Oracle. If you apply patches replacing AppsLocalLogin.jsp the file will be overwritten.


Warning: the Login page being an access to E-Business Suite, be careful and always do a backup of the related files before doing any direct update.

References
NOTE:275875.1 - Oracle Application Framework Troubleshooting Release 11i (11.5.10)
NOTE:275878.1 - Oracle Application Framework Development FAQ Release 11i (11.5.10)
NOTE:275880.1 - Oracle Application Framework Release 11i Documentation Roadmap
NOTE:391826.1 - FND_SSO_SARBANES_OXLEY_TEXT Does Not Line Wrap On AppsLocalLogin.jsp
Oracle Applications System Administrator’s Guide - Configuration

Tips For Personalizing The E-Business Suite r12 Login Page

Tips For Personalizing The E-Business Suite r12 Login Page (MainLoginPG) [ID 741459.1]

Goal
You would like to personalize the Release 12 login page (MainLoginPG) to add specific text, change the logo, etc. This document describes the methods to achieve one's ends.

Solution
1. Main attributes of the login page

In Release 12 the attributes of the login page are controlled thru the Framework personalizations.
To change them you can either:

Enable the Personalize Region links by setting the 'Personalize Self-Service Defn' profile option to 'Yes' at Site level (or at user level for GUEST user) then click on the desired links on the login page

or:

Go to 'Functional Administrator' responsibility => choose 'Personalizations' tab and enter the value
"/oracle/apps/fnd/sso/login/webui" in the 'Document Path' field then click on the Go button.
The document names available are:

/oracle/apps/fnd/sso/login/webui/MainLoginPG
/oracle/apps/fnd/sso/login/webui/loginRG
/oracle/apps/fnd/sso/login/webui/loginRN
/oracle/apps/fnd/sso/login/webui/LangImagesRN

Click on the pencil icon (Personalize Page) for the document you want to change. The 'Choose Personalization Context' will be displayed. Click on the 'Apply' button to display the personalization page. It will show the personalization structure and the item attributes. Select 'Complete View' radio button and click on the 'Expand All' link. At this stage you can choose the desired item attribute. Click on the pencil icon to edit.

a. Login zone
(document name: /oracle/apps/fnd/sso/login/webui/loginRN)

The following table lists the attributes that you can change:

Attribute
Image: (corporateBrandingImage)
Image: people image
Image: globalTop image
Image: global image
Message Text Input: User Name
Message Text Input: Password
Submit Button: Submit
Submit Button: Cancel
Message Styled Text: Forgot your password
Message Styled Text: Register Here
Message Choice: Accessibility


You can edit the properties of an attribute. For instance, if you don't want an attribute to be displayed, set the property 'Rendered' to false (e.g. Cancel button or Accessibility field).


b. Language zone
(document name: /oracle/apps/fnd/sso/login/webui/LangImagesRN)

For instance if you have one language and don't want to display this zone, then change the property 'Rendered' to false for the 'Table Layout'.


2. Message texts

A message text is used for certain attributes. The "Tip Message Name" property allows you to change
the message name and use a customized message. Please note that is considered as customization and
may be reverted by patches delivering new messages.

To change the value of a standard message:

1. Go to "Application Developer" responsibility
2. Select "Messages" from the menu
3. Query the message name (e.g. "FND_SSO_FORGOT_PASSWORD") then enter your message text in the "Current Message Text" field
4. Save changes and exit
5. Clear cache and bounce Apache to see the change


Below are the messages, with default value, used in the login page:

Message Name Value
FND_SSO_HINT_USERNAME (example: michael.james.smith)
FND_SSO_HINT_PASSWORD (example: 4u99v23)
FND_SSO_FORGOT_PASSWORD Login Assistance
FND_SSO_REGISTER_HERE Register here



The profile option "Corporate Branding Image for Oracle Applications" controls the
corporate branding image "ORACLE" displayed at the top of all OA Framework pages.
If no value is set for this profile, OA Framework renders the corporate branding image by using the $OA_MEDIA/FNDSSCORP.gif file.

If you change the value of this profile with the name of your custom image you will see your logo in all pages except in the login page because the "FNDSSCORP.gif " is hard coded in MainLoginPG.xml.

Hence if you want to change the corporate branding image with your own logo and thus in all pages including the login page the simplest solution is to:

- rename the FNDSSCORP.gif file for backup
- edit the FNDSSCORP.gif with your preferred graphic software
- log out and log into the Applications
- you should see the new logo at the top of all the page (including the login page)



In case you want a different logo for the login page then the only (non supported) solution consists in editing the $FND_TOP/mds/sso/login/webui/MainLoginPG.xml file,

from:

oa:image id="corporateBrandingImage" source="/OA_MEDIA/FNDSSCORP.gif" /

to:

oa:image id="corporateBrandingImage" source="/OA_MEDIA/" /
Of course you will need to import the customized MainLoginPG.xml into the MDS repository
using the XMLImporter tool (please review Note 344204.1 for the exact command line).



4. Footer

Different elements are displayed at the bottom of the page:

About this page

- go to System Administrator responsibility => Profile => System
- change the value of 'FND: Diagnostics' profile option to "Yes" to display this link


Privacy Statement and Copyright

- login to the Applications
- click on the link "Personalize Page" at the top of the Oracle Applications Home Page
- click on "Choose Context" button
- select "OA Footer" for the scope, click on "Apply" button
(the document name should be/oracle/apps/fnd/framework/webui/OAFooter)
- in the this page "Personalize Region: Standard Footer" you can change the item Privacy (Destination URI and Text properties) and the item Copyright (Prompt property)

Note that these changes will apply on all pages.


5. Other modifications

Using JDeveloper tool you can create framework extensions. You can create your own messages in the Messages Dictionnary thru AOL responsibility, etc. This is considered a customization and thus not supported by Oracle.


Warning: the Login page being an access to E-Business Suite, be careful when doing personalizations and customizations.



References
NOTE:391554.1 - Oracle Application Framework Documentation Resources, Release 12
NOTE:468971.1 - Tips For Personalizing The E-Business Suite 11i Login Page (AppsLocalLogin)
NOTE:473539.1 - How to Replace the Globe and People Images of the Release 12 Login page
NOTE:579917.1 - How to Personalize Login page in R12?
NOTE:344204.1 - How to use XMLImporter/XMLExporter to import/export personalization

Canceling Long Running Queries in Oracle Applications 11i

Oracle strongly recommends that customers wishing to use the Cancel Query feature upgrade to Developer 6i patch 14 (Forms version 6.0.8.23.x) or later.

Customers using Developer 6i patch 13 (Forms version 6.0.8.22.x) must apply patch 2974236 to use all the cancel query features outlined in this document.

Oracle Applications does not support the Cancel Query feature for releases 10SC, 10.7NCA and 11.0 .

For information on the Cancel Query feature with earlier patch set releases, please see Metalink Note 241012.1 titled 'Canceling Long Running Queries in Earlier Versions of Oracle Applications 11i'

Canceling Long-Running Queries (Overview)
On occasion, a user may start a long-running query, grow tired of waiting, and close the browser. This section considers the implications of such an action, and describes a new feature that can help in this situation.

The middle-tier Forms Server process is basically single-threaded, and queries are normally executed in Blocking mode. If the client is killed, the Forms Server process still waits for the query to complete. This means that the Forms Server process will only time out when control has been returned from the database, at which point it will terminate when it can no longer communicate with the PC client. Cleanup will also take place for the database session.

The same principle applies in the case of a long-running transaction that calls a stored procedure from client-side PL/SQL. The key point is that in all such cases the query must run to completion before the middle tier process terminates and cleanup takes place.

If the query takes longer than about 5 seconds, a dialog box will appear that allows the user to cancel the query by clicking a Cancel button. This Cancel Query feature (sometimes called Non-blocking mode, as it is based on SQL*Net non-blocking functionality) is the only way to terminate a query without killing the Forms session.

This capability only applies to queries issued by form blocks or LOVs. It will not work for transactions such as stored procedure calls or queries executed from PL/SQL.
If you are using Oracle Applications 11i Release 7 (11.5.7) or later, or are using FND mini-pack D or later you must set the profile option FND:ENABLE_CANCEL_QUERY to Yes in order to enable this feature. This can be set at site, application, responsibility or user level. Setting this profile to Yes also adds a call to set_form_property in the standard APPCORE when-new-form-instance event, which sets the INTERACTION_MODE property to NON_BLOCKING.

If you are using Oracle Applications 11i prior to Release 7 (11.5.7) and FND mini-pack prior to D, you must apply patch 1675290, and follow the instructions in its readme file to be able use this feature.

Actions that will cause the dialog to appear:
For any block populated via a query issued by Oracle Forms directly, the dialog will appear if the time to fetch the records for the query exceeds the threshold.
When a query is run against a block that is part of a master-detail relation, the dialog may appear and disappear several times if multiple detail blocks are involved.
For any LOV which is based on a SQL statement, if the LOV is explicitly invoked by the user with an action such as Edit List of Values, the dialog will appear if the time to execute and fetch all records for the query exceeds the threshold.
With an operation that fetches many records, such as Go-Last Record or Action-Export, the records are fetched in batches of multiple rows at a time. The dialog will appear if the time to fetch all the records exceeds the threshold.
Queries issued from Find Windows will cause the dialog to appear if the threshold time is exceeded.
Actions that will not cause the dialog to appear:
Spreadtable blocks that are predominantly used by the CRM suite of products will not activate the Cancel Query feature. Java blocks, Java Beans and PLSQL queries that are not activated by forms will not activate this feature.
For a query run against a block that is part of a master-detail relation, the dialog will only appear if the time to populate a particular block exceeds the threshold.
LOVs that open automatically as a result of validation errors or non-unique entries.
Any LOV that has been coded as a user exit, including items such as concurrent request parameter LOVs or Flexfield segment LOVs. Oracle Applications user-exits call private Forms API’s to display an array built by the user-exit in a Forms LOV window. As the query is executed by the user-exit, Forms runtime has no control over it, so is unable to cancel it.
Any form processing involved with creating, committing, updating, deleting a record.

--------------------------------------------------------------------------------

Tuning Cancel Query
You must be on Forms 6i patchset 14 (6.0.8.23.x) or Forms 6i patchset 13 (6.0.8.22.x) with patch 2974236 applied, for all the options described below to be available. As cancel query introduces additional overheads you may wish to tune it to minimize any additional resource requirements.

As Cancel Query is enabled in Oracle Applications 11i by setting the profile FND_ENABLE_CANCEL_QUERY at the appropriate level, some customers may wish to enable cancel query for power users only due to the additional overheads. In this case the profile should be set at User level for these users only.

Cancel Query makes use of OCI level non-blocking queries. The middle tier Forms server process starts the query in non-blocking mode, then unlike a normal blocking query, control is returned to the forms code.

While the query is running, Forms polls the OCI layer until the query completes and records are returned. As well as polling to see if the database has finished executing the query, the forms server process also polls the Forms Java client to initially display the cancel query dialog, and then detect if the cancel button has been pressed. If the cancel button has been pressed by the end user, Forms will call the OCI function to terminate the query. At the time the query is terminated, some records may have already been fetched, so an incomplete record set may be returned in some cases.

While the query is running in non-blocking mode, the user is unable to do anything in the current forms UI except cancel the query. They cannot work in another form if they have multiple forms open.

Cancel query obviously imposes an additional overhead, as it needs to poll the database to see if the query has completed, and also poll the client to see if the user has cancelled it. You may experience the following issues -

Extra round trips between the forms server and the client. The Forms server polls the client once every second after the first 2 seconds by default. System Administrators can set environment variables to change the defaults. See below.

User Wait Time (i.e. the time the user has to wait for the query to complete and control returned to the user) may increase, particularly for queries which fetch a lot of records. Note that by default queries on Forms blocks only fetch enough records to display the first screen full, and fetch additional records as you scroll through. Therefore a query which potentially returns a million rows will not cause a problem because forms is smart enough to only fetch the first few rows. An LOV always fetches all records selected by the query.

CPU on the middle tier will increase. CPU will also increase on the client but that isn't normally a problem, as the client PC is not normally running anywhere near capacity. Middle tier CPU is more important. In cancel query we have to strike a balance between CPU usage on the middle tier and User Wait Time. Polling the database more often increases CPU usage, but reduces user wait time, particularly for queries which fetch a lot of records. The database polling interval is configurable - see The Database Polling Interval section below.

The following environment variables can be set to tune Cancel Query. Guidance is provided, but in some cases the optimal value is yet to be established, hence the reason for making everything configurable;


--------------------------------------------------------------------------------

Tuning round trips between the Middle Tier and the Client
Changes to the environment variables below will only affect Forms Server Listener implementations. Forms Servlet Listener users should go to the Forms Servlet Listener section below.

Minimizing network round trips between the middle tier and client is important, particularly if the bandwidth is limited, or the end user in on a WAN. Three environment variables have been introduced to tune the client round trips. Despite the names of the variables, they now control the round trips for all queries. The environment variables need to be set when the Forms server is started. They apply to all users with cancel query enabled. The defaults are set slightly differently for Oracle Applications users of the Forms runtime.

Initial Delay (FORMS60_LOV_INITIAL):
Specify the time in milliseconds
Default 1000 (2000 for Oracle Applications)

Minimum Polling Period (FORMS60_LOV_MINIMUM):
Specify the time in milliseconds.
Default 500 (1000 for Oracle Applications)

Network Latency Weighting (FORMS60_LOV_WEIGHT):
Specify the time in milliseconds.
Default 0 (16 for Oracle Applications)

FORMS60_LOV_INITIAL
This can be set between 1000 and 32000, and is the value in Milliseconds before the cancel query dialog initially appears. By setting this to 32000, it means the cancel query dialog will not appear until after 32 seconds have passed, and more importantly, no round trips will be generated between the Forms server and the client until after 32 seconds. If you set it to 32000, in most cases no extra network traffic will be generated by cancel query, except in the case of queries which really are candidates for being cancelled. range is 1000 to 32000. 5000 or 10000 would be a good starting point. Set to 32000 if your network is slow or heavily loaded.

The default value for Oracle Applications is set to 5000 milliseconds.
Autoconfig Users
Autoconfig users with TXK (FND) Autoconfig Template Roll Up M ( Patch 4709948 ) or later, should update this value through Autoconfig. If you are using an earlier version, you may also apply patch 3563654 to obtain this functionality.

You may alter the value for the FORMS60_LOV_INTIAL parameter as follows;

Login to 'Oracle Applications Manager'
Select 'Site Map' -> 'Monitoring' Tab -> 'System Configuration' -> 'Applications Context'
Click on 'Edit Parameters' for the 'Applications' tier.
Select 'OA_VAR' from the 'Search' drop down menu, enter 's_f60lov' in the adjacent field and press the 'Go' button.
Alter the value for the 'forms 60 LOV initial' parameter and press the 'Save' button.
Non-Autoconfig Users
To alter the value for this environment variable please follow the steps below:-

On Unix:

Stop the Forms Server process.

Update the 'Oracle Forms 6.0 environment variables' section of your '$APPL_TOP/< SID >.env' file with; (Using 2000 milliseconds as an example)

FORMS60_LOV_INITIAL="10000"
export FORMS60_LOV_INITIAL

Source the environment, then restart the Forms Server process.

On Windows:

Stop the Forms Server process.

Update the 'Oracle Forms 6.0 environment variables' section of your '$APPL_TOP/< SID >.cmd' file with; (Using 10 seconds (10000 milliseconds) as an example)

FORMS60_LOV_INITIAL=10000

Source the environment, then restart the Forms Server process.

FORMS60_LOV_MINIMUM
This environment variable can be set to anything between 1000 and 32000 and is the value in Milliseconds between subsequent polling of the client from the middle tier. The more often you poll, the faster the query will be cancelled when you press the button, but at the expense of more network round trips. Although you can only set one value for all users, but you can set FORMS60_LOV_WEIGHT to automatically vary the time between polling based on network latency. The suggested range for FORMS60_LOV_MINIMUM is 1000 to 5000.

The default value for Oracle Applications is set to 1000 milliseconds.
Autoconfig Users
Autoconfig users with TXK (FND) Autoconfig Template Roll Up M ( Patch 4709948 ) or later, should update this value through Autoconfig. If you are using an earlier version, you may also apply patch 3563654 to obtain this functionality.

You may alter the value for the FORMS60_LOV_MINIMUM parameter as follows;

Login to 'Oracle Applications Manager'
Select 'Site Map' -> 'Monitoring' Tab -> 'System Configuration' -> 'Applications Context'
Click on 'Edit Parameters' for the 'Applications' tier.
Select 'OA_VAR' from the 'Search' drop down menu, enter 's_f60lovminimum' in the adjacent field and press the 'Go' button.
Alter the value for the 'forms 60 LOV minimum' parameter and press the 'Save' button.
Non-Autoconfig Users
To alter the value for this environment variable please follow the steps below:-

On Unix:

Stop the Forms Server process.

Update the 'Oracle Forms 6.0 environment variables' section of your '$APPL_TOP/< SID >.env' file with; (Using 2000 milliseconds as an example)

FORMS60_LOV_MINIMUM="2000"
export FORMS60_LOV_MINIMUM

Source the environment, then restart the Forms Server process.

On Windows:

Stop the Forms Server process.

Update the 'Oracle Forms 6.0 environment variables' section of your '$APPL_TOP/< SID >.cmd' file with; (Using 2000 milliseconds as an example)

FORMS60_LOV_MINIMUM=2000

Source the environment, then restart the Forms Server process.

FORMS60_LOV_WEIGHT
This environment variable can be set between 0 and 32000. It defines a weighting factor, which takes account of the actual network latency to automatically adjust the polling period. You may have some users on the LAN with low latency, and other users on the WAN with high latency. All users may want to use cancel query, but the extra round trips will be more of a problem for the WAN, so this allows you to automatically decrease the frequency of the network round trips for users on slow networks and is utilized in the following equation;

x = minimum period (from FORMS60_LOV_MINIMUM) + weighting factor (from FORMS60_LOV_WEIGHT) * avg roundtrip time

Initially, there will be a certain amount of trial and error involved in finding the optimal value for this variable. We would suggest starting with the default value of 16, then increase/decrease by small amounts until the desired performance is obtained. If you do not wish to alter the interval then this value should be set to 0 (zero).

The default value for Oracle Applications is set to 16.
Autoconfig Users
Autoconfig users with TXK (FND) Autoconfig Template Roll Up M ( Patch 4709948 ) or later, should update this value through Autoconfig. If you are using an earlier version, you may also apply patch 3563654 to obtain this functionality.

You may alter the value for the FORMS60_LOV_WEIGHT parameter as follows;

Login to 'Oracle Applications Manager'
Select 'Site Map' -> 'Monitoring' Tab -> 'System Configuration' -> 'Applications Context'
Click on 'Edit Parameters' for the 'Applications' tier.
Select 'OA_VAR' from the 'Search' drop down menu, enter 's_f60lovweight' in the adjacent field and press the 'Go' button.
Alter the value for the 'forms 60 LOV weight' parameter and press the 'Save' button.
Non-Autoconfig Users
To alter the value for this environment variable please follow the steps below:-

On Unix:

Stop the Forms Server process.

Update the 'Oracle Forms 6.0 environment variables' section of your '$APPL_TOP/< SID >.env' file with; (Using 0 as an example)

FORMS60_LOV_WEIGHT="0"
export FORMS60_LOV_WEIGHT

Source the environment, then restart the Forms Server process.

On Windows:

Stop the Forms Server process.

Update the 'Oracle Forms 6.0 environment variables' section of your '$APPL_TOP/< SID >.cmd' file with; (Using 0 as an example)

FORMS60_LOV_WEIGHT=0

Source the environment, then restart the Forms Server process.


--------------------------------------------------------------------------------

Cancel Query with Long List LOV's
Longlist LOV's are a special case and do not use OCI non-blocking calls - it actually uses blocking calls at OCI level. Cancel query functionality is implemented between fetches, therefore it is only possible to cancel when a fetch completes and control is returned to the forms runtime internal code by the OCI layer. You cannot cancel if the initial execute and fetch takes an excessive time, or a subsequent fetch takes an excessive time.

In general longlist LOV queries should be tuned to perform adequately by Oracle development and the only time you need to cancel is when you enter inappropriate reduction criteria resulting in a long delay due to too many rows getting returned. In this case cancel query should work well.

FORMS60_BLOCKING_LONGLIST
This environment variable can be used to turn the cancel query feature on or off for Longlist LOV's. The default value is ‘FALSE’, which means cancel query is enabled for Longlist LOV's.

There is little reason to turn off cancel query for longlist LOV's. As the queries are always executed in blocking mode you will not save middle tier CPU. If network bandwidth is a real problem, but you still want cancel query for block queries you could turn it off.

The default value for Oracle Applications is set to FALSE.
Autoconfig Users
Autoconfig users with TXK (FND) Autoconfig Template Roll Up M ( Patch 4709948 ) or later, should update this value through Autoconfig. If you are using an earlier version, you may also apply patch 3563654 to obtain this functionality.

You may disable the cancel query functionality for Longlist LOV's as follows;

Login to 'Oracle Applications Manager'
Select 'Site Map' -> 'Monitoring' Tab -> 'System Configuration' -> 'Applications Context'
Click on 'Edit Parameters' for the 'Applications' tier.
Select 'OA_VAR' from the 'Search' drop down menu, enter 's_f60blocklist' in the adjacent field and press the 'Go' button.
Alter the value for the 'form 60 blocking longlist' parameter and press the 'Save' button.
Non-Autoconfig Users
To disable cancel query for Longlist LOV's, please follow the steps below:-

On Unix:

Stop the Forms Server process.

Update the 'Oracle Forms 6.0 environment variables' section of your '$APPL_TOP/< SID >.env' file with;

FORMS60_BLOCKING_LONGLIST="TRUE"
export FORMS60_BLOCKING_LONGLIST

Source the environment, then restart the Forms Server process.

On Windows:

Stop the Forms Server process.

Update the 'Oracle Forms 6.0 environment variables' section of your '$APPL_TOP/< SID >.cmd' file with;

FORMS60_BLOCKING_LONGLIST=TRUE

Source the environment, then restart the Forms Server process.


--------------------------------------------------------------------------------

Cancel Query with Standard LOV's
In theory cancel query should never need to be activated for standard LOV's. As there is no way to modify the query and re-execute it, any long running query is a performance problem, which needs to be fixed by Oracle Applications Development. Cancel query will not solve the underlying problem. Therefore from Forms patchset 14 we run all standard LOV's in blocking mode and offset some of the increase in middle tier CPU due to cancel query, with minimal loss of functionality. It will also reduce network round trips, but in general standard LOV queries will be quick, and will have completed before any client process round trips are generated.
FORMS60_ENABLE_LOV_CANCEL_QUERY
This environment variable is set to FALSE, which means cancel query is disabled for Standard LOV's (all standard LOV's will run in blocking mode). This parameter should not be changed.


--------------------------------------------------------------------------------

The Database Polling Interval
A new database polling algorithm is introduced in Forms patchset14, which should help to reduce the additional middle tier CPU used by cancel query. The new polling algorithm should use less CPU than all previous implementations.

By default we now poll every 100 milliseconds to check whether the query has completed, with sleeps in between. The more often we poll, the more CPU it uses. However if we don’t poll often enough, we will experience increases in user wait time, and in particular queries which fetch large numbers of rows, or forms which repopulate multiple detail blocks.

This is the reason we decided to disable cancel query for standard LOV’s by default (see above), as standard LOV’s which returned 1000+ records were affected most when we increased the polling interval. As we couldn't really see a need for cancel query on a standard LOV, it made more sense to disable it so we could run with a higher polling interval and reduce the middle tier CPU overhead.

FORMS60_NONBLOCKING_SLEEP
This variable allows you to alter the sleep period as required. For example, if this is set to "200" you will get a sleep period of 200 milliseconds between polling. This should be set as high as possible without impacting user-wait time. It’s not clear what the optimal value is at this time, hence the reason we made it configurable, but either 100 milliseconds (the default) or 200 milliseconds would be a good starting point. The optimal value probably be somewhere between 100 milliseconds and 400 milliseconds - any higher and it would probably start to impact user wait time.

The default value for Oracle Applications is set at 100 milliseconds
Autoconfig Users
Autoconfig users with TXK (FND) Autoconfig Template Roll Up M ( Patch 4709948 ) or later, should update this value through Autoconfig. If you are using an earlier version, you may also apply patch 3563654 to obtain this functionality.

You may disable the cancel query functionality for Longlist LOV's as follows;

Login to 'Oracle Applications Manager'
Select 'Site Map' -> 'Monitoring' Tab -> 'System Configuration' -> 'Applications Context'
Click on 'Edit Parameters' for the 'Applications' tier.
Select 'OA_VAR' from the 'Search' drop down menu, enter ' s_f60nonblockingsleep' in the adjacent field and press the 'Go' button.
Alter the value for the 'forms 60 non-blocking sleep' parameter and press the 'Save' button.
Non-Autoconfig Users
To alter the value for this environment variable please follow the steps below:-

On Unix:

Stop the Forms Server process.

Update the 'Oracle Forms 6.0 environment variables' section of your '$APPL_TOP/< SID >.env' file with; (Using 200 milliseconds as an example)

FORMS60_NONBLOCKING_SLEEP="200"
export FORMS60_NONBLOCKING_SLEEP

Source the environment, then restart the Forms Server process.

On Windows:

Stop the Forms Server process.

Update the 'Oracle Forms 6.0 environment variables' section of your '$APPL_TOP/< SID >.cmd' file with; (Using 200 milliseconds as an example)

FORMS60_NONBLOCKING_SLEEP=200

Source the environment, then restart the Forms Server process.


--------------------------------------------------------------------------------

Forms Listener Servlet
If you are using the Forms Listener Servlet, then MaxBlockTime defined in formservlet.properties must be set to a value larger than the maximum cancel query polling interval. For example if;


FORMS60_LOV_INITIAL=10000
FORMS60_LOV_MINIMUM=20000
FORMS60_LOV_WEIGHT=0

Then set MaxBlockTime=25000 or higher.

If you set FORMS60_LOV_WEIGHT to a non-zero value, you will have to calculate the maximum polling interval based on the highest network latency. Set MaxBlockTime at least 5000ms higher than the maximum polling interval.

Failure to set MaxBlockTime to a value larger than the maximum polling interval will result in a loss of performance. If it's undefined (as in older versions of the configuration files), it defaults to 1000ms.

For the Forms Listener Servlet, the FORMS60_* environment variables are defined in the configuration file formservlet.ini

For further information on Forms Listener Servlet, see MetaLink Note id 201340.1 titled, 'Using Forms Listener Servlet with Oracle Applications 11i'.


--------------------------------------------------------------------------------

Open Enhancements (For Consideration)
Bug 823698 - Customize text/size of Cancel Query dialog and error message when query is cancelled
Bug 974350 - Mouse pointer flickers during non-blocking query on a Block/List of Values