, , , , , ,

Intercompany Invoicing Cycle

2.1. Intercompany Invoicing Cycle

When a sales order is entered in an operating unit, and if the shipping warehouse is part of a separate operating unit (may also belong to another SOB), then the goods can be shipped from the said shipping organization and the selling organization generates a customer invoice. Also the system automatically records an intercompany sale between the shipping organization and the selling organization by generating intercompany invoices. This is called Intercompany invoicing.

After entering the order in Selling operating unit, you can pick release and ship confirm the order from Shipping Operating unit. Then the following programs need to be run to ensure necessary Intercompany invoices are created ..

  1. Launch the Cost Manager in Inventory > Setup > Transactions > Interface Managers. If it is not active then go to Tools  and Launch Manager. Intercompany Invoices will not be generated unless this manager is active.
  2. In Shipping OU run ‘Create Intercompany AR Invoices’. Ensure that the items shipped have a price for ‘Internal Price List’.
  3. In Shipping OU run ‘Receivables AutoInvoice Program’
  4. In Selling OU run ‘Create Intercompany AP Invoices’. Ensure that the conversion rates between the functional currencies of above SOBs exist for the current date and GL period is open in both OUs.
  5. In selling OU run ‘Expense Report Import’ (Payables)

2.1.1. Transaction Steps

Create an Order in ‘Vision Operations’ OU and schedule it from D1 warehouse under ‘Singapore Distribution Centre’ OU as ..


After Pick release and shipconfirm the order, the delivery associated with the line is closed as ..

  • The Create Intercompany AR Invoices process creates invoice lines for order shipment transactions in Oracle Inventory where the shipping warehouse does not belong to the order entry operating unit.
  • The Oracle Receivables AutoInvoice program processes the records inserted into the interface tables by the Create Intercompany AR Invoices process.
  • Find the AR Invoice that has been generated in Shipping OU by querying for source ‘Intercompany’ and optionally by the Sales Order.

  • Create Intercompany AP Invoices process creates records in Payable invoices interface tables.
  • The Oracle Payables ‘Expense Report Import’ program processes the records inserted into the interface tables by the Create Intercompany AP Invoices process. All invoices created by the Create Intercompany AP Invoices program have Intercompany as their source.
  • Find the Payables Invoice that has been generated in Selling OU by querying for supplier and today’s date.

  • The customer invoice automatically gets created if the ‘Workflow background process’ is running. Find it in Selling OU by querying for the transaction source as ‘ORDER ENTRY’ and with a date range.

2.2. Set up steps

The below set-up steps are necessary for proper functioning of Intercompany invoicing cycle ..

  1. Define a customer and customer site in the selling operating unit.
  2. Define a supplier and supplier site in the shipping operating unit.
  3. Define Intercompany Relations
  4. Define price for the items in  ‘Internal Price list’

The organization itself is defined as a customer ‘Vision’, having a customer site in the selling operating unit as ..

The organization itself is defined as a supplier ‘Vision’, with a supplier site in the shipping operating unit as ..

Define Intercompany Relations as ..

Define price for the items in  ‘Internal Price list’ ..

/by
, , , , ,

SQL Queries for checking Profile Option Values

The following queries are useful to get the profile option values of a profile option at site, application, responsibility and user level

1) Obtain Profile Option values for Profile Option name like ‘%Ledger%’ and  Responsibility name like ‘%General%Ledger%’
SELECT
substr(pro1.user_profile_option_name,1,35) Profile,
decode(pov.level_id,
10001,’Site’,
10002,’Application’,
10003,’Resp’,
10004,’User’) Option_Level,
decode(pov.level_id,
10001,’Site’,
10002,appl.application_short_name,
10003,resp.responsibility_name,
10004,u.user_name) Level_Value,
nvl(pov.profile_option_value,’Is Null’) Profile_option_Value
FROM 
fnd_profile_option_values pov,
fnd_responsibility_tl resp,
fnd_application appl,
fnd_user u,
fnd_profile_options pro,
fnd_profile_options_tl pro1
WHERE
pro1.user_profile_option_name like (‘%Ledger%’)
and  pro.profile_option_name = pro1.profile_option_name
and  pro.profile_option_id = pov.profile_option_id
and  resp.responsibility_name like ‘%General%Ledger%’ /* comment this line  if you need to check profiles for all responsibilities */
and  pov.level_value = resp.responsibility_id (+)
and  pov.level_value = appl.application_id (+)
and  pov.level_value = u.user_id (+)
order by 1,2;
2) Obtain all Profile Option values setup for a particular responsibility. Replace the responsibility name as per your requirement.
SELECT
substr(pro1.user_profile_option_name,1,35) Profile,
decode(pov.level_id,
10001,’Site’,
10002,’Application’,
10003,’Resp’,
10004,’User’) Option_Level,
decode(pov.level_id,
10001,’Site’,
10002,appl.application_short_name,
10003,resp.responsibility_name,
10004,u.user_name) Level_Value,
nvl(pov.profile_option_value,’Is Null’) Profile_option_Value
FROM 
fnd_profile_option_values pov,
fnd_responsibility_tl resp,
fnd_application appl,
fnd_user u,
fnd_profile_options pro,
fnd_profile_options_tl pro1
WHERE
pro.profile_option_name = pro1.profile_option_name
and  pro.profile_option_id = pov.profile_option_id
and  resp.responsibility_name like ‘%General%Ledger%’
and  pov.level_value = resp.responsibility_id (+)
and  pov.level_value = appl.application_id (+)
and  pov.level_value = u.user_id (+)
order by 1,2;

Similarly, you can tweak the above queries to obtain Profile Option Values set for a particular User or a particular application.

/by
, , , , ,

Tracing techniques in oracle applications

This is one of the good reference documents from metalink.

WHAT TO SET UP BEFORE GENERATING THE TRACE

These steps must be performed by the DBA on the database server.

1. Set TIMED_STATISTICS to TRUE.
   For performance issues, make sure TIMED_STATISTICS is turned on, before attempting to generate the trace.

   Set the following in the init.ora file:
      TIMED_STATISTICS=TRUE
      OR
      in SQL*Plus: ALTER SYSTEM SET TIMED_STATISTICS=TRUE;

2. Set the location of the trace output.
   Set the following in the init.ora file: USER_DUMP_DEST =

3. Create the PLAN_TABLE to hold the output of the explain plan. Run the SQL script called UTLXPLAN.SQL to create this in the apps schema. This script is usually in $ORACLE_HOME/rdbms/admin.

4. If the init.ora file has been updated, you must shut down and restart the database before the changes will take effect.
   TYPES OF TRACE – HOW TO TURN TRACE ON
   Regardless of the type of trace file you create, make sure you note the time that you create it.

1] Form Trace

Toggle trace on/off on the form, to trace specific application functions. Make sure you go in fresh (sign off/on to the application), since somequeries are cached and may not be executed on subsequent visits to theform.

From the menu, select Help–>Diagnostics–>Trace to turn trace on (when checked, it is on).
   Perform the action to be traced.
   From the menu, turn trace off, by selecting Help–>Diagnostics–>Trace (it should now be unchecked).

2] Concurrent Program Trace
   A. This will turn trace on for each execution of this program. In Release 11.0 and lli, check the Enable Trace checkbox for the concurrent program on the Concurrent Programs form. After running the program to be traced, make sure you uncheck the Enable Trace checkbox.
   Select the System Administrator responsibility.
   Navigation = Concurrent -> Programs -> Define. Query the concurrent program you want to trace. Check the Enable Trace checkbox and save.
   OR
   B. How to generate a raw trace file with binds and/or waits for 11.5.10:
1. Log into applications as System Administrator and Navigate to the System Profile Values Form. Select the profile called Concurrent: Allow Debugging and change the value to Yes at the appropriate level.
2. Allow pop-ups on your browser.
3. Navigate to the Submit a New Request form and select a job and enter all parameters for that job
4. Select the Debug Options Button and this will take you to Create Debug Rule in Oracle Application Manager
5. Select the appropriate Debug Option Value for SQL Trace only and then check the box
6. Hit OK twice and then Submit the job
7. Raw trace file with options selected will be located in the appropriate directory.

3] Database Level Trace
   This will turn trace on for all processes that are running in the instance and should only have to be used in Release 10.7, for concurrent programs. (This has to be done by the DBA.)
   Set the following in the init.ora file:SQL_TRACE=TRUE
   Shut down and restart the database.After generating the trace file, shut down and restart the database with the original init.ora.

4] Report Trace
If you are on 10.7 and need to trace an Oracle Report, you can modify the report to turn trace on for that session.
   a. Convert the report from rdf to rex: $ORACLE_HOME/bin/r25convm batch=yes userid=> stype=rdffile source=REPORT_NAME.rdf dtype=rexfile overwrite=yes
   b. Edit the rexfile and search for the beforerep trigger in the report.
      Locate the following code:
         IF (:p_trace_switch = ‘Y’) THEN
            SRW.DO_SQL(‘alter session set sql_trace TRUE’);
         END IF;
      Comment out the IF and END IF lines.
   c. Save the report.
   d. Convert the report from rex to rdf: $ORACLE_HOME/bin/r25convm batch=yes userid= > stype=rexfile source=REPORT_NAME.rex dtype=rdffile overwrite=yes

5] Self Service page (like a Forms trace, but for self service web apps)
   a. Set the FND:Diagnostics profile: Responsibility = System Administrator
      Navigation: Profile > System User: Enter User name
      Query the Profile: ‘FND:Diagnostics’
      Set the ‘FND:Diagnostics’ profile to Yes at User level

   b. Login to Self Service under the same user the profile was set for.
   c. Turn Trace on: Click the Diagnostic link at the top of the page.
      It shows two options: Show Log and Set Trace Level
      Select ‘Set Trace Level’
      Click Go.
      Select one of the following options:
      Disable Trace – used to end the trace
         Trace (Regular) – just like a forms trace
         Trace with Binds – record the bind variables in the trace
         Trace with waits – Good for performance issues
         Trace with binds and waits – combines both of the above
      Click Save.
    
   d. Perform the action to be traced in Self Service.
      Multiple trace files may be generated in the usual trace directory.
   e. Turn trace off: Select the Diagnostic link
      Click on option: Set Trace Level
      Note all of the trace numbers listed
      Click Go
      Select: Disable Trace
      Click Save

WHAT TO DO AFTER GENERATING THE TRACE FILE

These steps should be performed by the DBA, on the database server.

1. Find the trace directory. Get the location of user_dump_dest. Log into SQL*Plus as the apps user.
   select value from V$PARAMETER where name = ‘user_dump_dest’
2. Find the trace file for your process.Go to the directory you found in step 1 (in UNIX, use cd). Look for a file (.trc) that was created at the time you started your process (in UNIX, use ls -ltr).
3. Run tkprof with explain plan. Go to a directory in which you have write privilege (in UNIX, use cd).

Run tkprof:
tkprof explain=

HOW TO GET AN EXPLAIN PLAN FOR A SQL STATEMENT

Sometimes you may have a need to get an explain plan for a specific SQL statement. If you have the sql statement, you can get the explain plan for it.
This should be run on the same instance that the sql statement came from.
In your apps account —
Run the following script:
delete from plan_table
where statement_id = ‘tmp’

explain plan

set statement_id = ‘tmp’
for

/
set pages 100
col operation format a36
col options format a11
col object_name format a30

select lpad(‘ ‘,2*(level-1))operation operation,

options, object_name
from plan_table
where statement_id = ‘tmp’
connect by prior id = parent_id
and statement_id = ‘tmp’
start with id = 1
and statement_id = ‘tmp’
order by id
/
delete from plan_table
where statement_id = ‘tmp’
/
commit;

/by