Oracle HRMS Online Training Sessions in October 2011

Dear Friends,
If you are looking for Instructor Led training for Oracle HCM suite (core HR, Payroll, Benefits etc.), Please register at Logicwala today.
KnowOracle and Logicwala is scheduling an exclusive Oracle HRMS techno-functional training. Our next batch is scheduled to start in October, and we are planning on either IST evenings or mornings depending on the number of students preference for each.

To register for the upcoming HCM Training seeions Click Here!

Cheers!
KnowOracle & Logicwala team.

Oracle EBS : Costing : Average Costing of Item

Average Costing of item stopes....

Error Code is like:
CST_MATCH_DATE_PERIOD
No Error
Etc...

Solution:
Step 1:
--get details how much lines having costed flag null

Select b.TRANSACTION_TYPE_NAME,a.costed_flag,a.error_code,
a.ERROR_EXPLANATION,a.*
from Mtl_material_transactions a,MTL_TRANSACTION_TYPES b
where ERROR_CODE is not null
and a.TRANSACTION_TYPE_ID=b.TRANSACTION_TYPE_ID

Step 2:
--finding error transaaction line

Select * from Mtl_material_transactions
where costed_flag = 'E'

Step 3:
--checking how much line not costed 

select count(*)
from mtl_material_transactions
where costed_flag = 'N';  --get count as 2013910

Step 4:
--updating error flag

update mtl_material_transactions
set costed_flag = 'N',
error_code = NULL,
error_explanation = NULL,
transaction_group_id = NULL,
transaction_set_id = NULL
--where costed_flag = 'E'
where transaction_id=49186079

Step 5:
runing cost manager

Step 6:
--check cost line count dcreaing

select count(*)
from mtl_material_transactions
where costed_flag = 'N';

If line count decreasing stops then just once again follow the
 steps 1 to step 6.Still problem is not resolve then check
 account_period_id and acc_distribution_id column 

from table Mtl_material_transactions
if these columns are blank then update with respective values.

Account period id should be find as:

select * from ORG_ACCT_PERIODS

after updation again follow step 1 to Step 6.

As count reach to zero means your costing process is completed.

Oracle Purchasing – Troubleshooting : PO to GL Debug

PO to GL reference debug………

– To debug for a PO , where should I start.
–Thats is possible, your PO get stuck somewhere, so what you have to do
–is to analyze which stage it stucked.Get po_header_id first and run each
– query and then analyze the data.For better understanding this is

–List all open–Stage 1: PO Creation :
–PO_HEADERS_ALL
select po_header_id from po_headers_all where segment1 =;
select * from po_headers_all where po_header_id =;
po_lines_all
select * from po_lines_all where po_header_id =;
po_line_locations_all
select * from po_line_locations_all where po_header_id =;
po_distributions_all
select * from po_distributions_all where po_header_id =;
po_releases_all
SELECT * FROM po_releases_all WHERE po_header_id =;

–Stage 2: Once PO is received data is moved to respective receving tables and inventory tables

–RCV_SHIPMENT_HEADERS

select * from rcv_shipment_headers where shipment_header_id in(select
shipment_header_id from rcv_shipment_lineswhere po_header_id =);

–RCV_SHIPMENT_LINES

select * from rcv_shipment_lines where po_header_id =;

–RCV_TRANSACTIONS

select * from rcv_transactions where po_header_id =;

–RCV_ACCOUNTING_EVENTS

SELECT * FROM rcv_Accounting_Events WHERE rcv_transaction_id IN(select
transaction_id from rcv_transactionswhere po_header_id =);

–RCV_RECEIVING_SUB_LEDGER

select * from rcv_receiving_sub_ledger where rcv_transaction_id in
(select transaction_id from rcv_transactions where po_header_id =);

–RCV_SUB_LEDGER_DETAILS

select * from rcv_sub_ledger_detailswhere rcv_transaction_id in (select
transaction_id from rcv_transactions where po_header_id =);

–MTL_MATERIAL_TRANSACTIONS

select * from mtl_material_transactions where transaction_source_id =;

–MTL_TRANSACTION_ACCOUNTS

select * from mtl_transaction_accounts where transaction_id in ( select
transaction_id from mtl_material_transactions where
transaction_source_id = =);

–Stage 3: Invoicing details

–AP_INVOICE_DISTRIBUTIONS_ALL

select * from ap_invoice_distributions_all where po_distribution_id in (
select po_distribution_id from po_distributions_all where po_header_id
=);

–AP_INVOICES_ALL

select * from ap_invoices_all where invoice_id in(select invoice_id from
ap_invoice_distributions_all where po_distribution_id in( select
po_distribution_id from po_distributions_all where po_header_id =));

–Stage 4 : Many Time there is tie up with Project related PO

–PA_EXPENDITURE_ITEMS_ALL

select * from pa_expenditure_items_all peia where
peia.orig_transaction_reference in( select to_char(transaction_id) from
mtl_material_transactionswhere transaction_source_id = );

–Stage 5 : General Ledger

–Prompt 17. GL_BC_PACKETS ..This is for encumbrances

SELECT * FROM gl_bc_packets WHERE reference2 IN (”);

–GL_INTERFACE

SELECT *FROM GL_INTERFACE GLIWHERE user_je_source_name =’Purchasing’AND
gl_sl_link_table =’RSL’AND reference21=’PO’AND EXISTS( SELECT 1FROM
rcv_receiving_sub_ledger RRSLWHERE GLI.reference22 =RRSL.reference2AND
GLI.reference23 =RRSL.reference3AND GLI.reference24 =RRSL.reference4AND
RRSL.rcv_transaction_id in(select transaction_id from
rcv_transactionswhere po_header_id ));

–GL_IMPORT_REFERENCES

SELECT *FROM gl_import_references GLIRWHERE reference_1=’PO’AND
gl_sl_link_table =’RSL’AND EXISTS( SELECT 1FROM rcv_receiving_sub_ledger
RRSLWHERE GLIR.reference_2 =RRSL.reference2AND GLIR.reference_3
=RRSL.reference3AND GLIR.reference_4 =RRSL.reference4AND
RRSL.rcv_transaction_id in(select transaction_id from rcv_transactions
where po_header_id =))

SELECT h.segment1 “PO NUM”, h.authorization_status “STATUS”,
l.line_num “SEQ NUM”, ll.line_location_id, d.po_distribution_id,
h.type_lookup_code “TYPE”
FROM po.po_headers_all h,
po.po_lines_all l,
po.po_line_locations_all ll,
po.po_distributions_all d
WHERE h.po_header_id = l.po_header_id
AND ll.po_line_id = l.po_line_id
AND ll.line_location_id = d.line_location_id
AND h.closed_date IS NULL
AND h.type_lookup_code NOT IN (‘QUOTATION’)

Oracle A.I.M. Methodology – template list

Oracle A.I.M. Methodology encompasses a project management methodology with documentation templates that support the life cycle of an implementation. The life cycle methodology and documentation templates allows A.I.M. to be a very useful tool for managing implementation projects successfully. This is a depiction of the A.I.M. methodology life cycle:

Application Implementation Method is a proven approach for all the activities required to implement oracle applications. there are eleven processes of implementation.

1. Business Process Architecture [BP] – This phase outlines:

• Existing Business Practices
• Catalog change practices
• Leading practices
• Future practices

BP.010 Define Business and Process StrategyBP.020 Catalog and Analyze Potential Changes

BP.030 Determine Data Gathering Requirements

BP.040 Develop Current Process Model

BP.050 Review Leading Practices

BP.060 Develop High-Level Process Vision

BP.070 Develop High-Level Process Design

BP.080 Develop Future Process Model

BP.090 Document Business Procedure

2. Business Requirement Definition [RD] - This phase explains about the initial baseline questionnaire and gathering of requirements.

RD.010 Identify Current Financial and Operating Structure RD.020 Conduct Current Business Baseline RD.030 Establish Process and Mapping Summary RD.040 Gather Business Volumes and Metrics RD.050 Gather Business Requirements RD.060 Determine Audit and Control Requirements RD.070 Identify Business Availability Requirements RD.080 Identify Reporting and Information Access Requirements

3. Business Requirement Mapping [BR] – In this phase the requirements of business are matched with the standard functionality of the oracle applications.

BR.010 Analyze High-Level GapsBR.020 Prepare mapping environment

BR.030 Map Business requirements

BR.040 Map Business Data

BR.050 Conduct Integration Fit Analysis

BR.060 Create Information Model

BR.070 Create Reporting Fit Analysis

BR.080 Test Business Solutions

BR.090 Confirm Integrated Business Solutions

BR.100 Define Applications Setup

BR.110 Define security Profiles

4. Application and Technical Architecture [TA] – This outlines the infrastructure requirements to implement oracle applications.

TA.010 Define Architecture Requirements and StrategyTA.020 Identify Current Technical Architecture

TA.030 Develop Preliminary Conceptual Architecture

TA.040 Define Application Architecture

TA.050 Define System Availability Strategy

TA.060 Define Reporting and Information Access Strategy

TA.070 Revise Conceptual Architecture

TA.080 Define Application Security Architecture

TA.090 Define Application and Database Server Architecture

TA.100 Define and Propose Architecture Subsystems

TA.110 Define System Capacity Plan

TA.120 Define Platform and Network Architecture

TA.130 Define Application Deployment Plan

TA.140 Assess Performance Risks

TA.150 Define System Management Procedures

5. Build and Module Design [MD] – This phase emphasizes the development of new functionality (customization) required by the client. It mainly details how to design the required forms, database and reports.

MD.010 Define Application Extension StrategyMD.020 Define and estimate application extensions

MD.030 Define design standards

MD.040 Define Build Standards

MD.050 Create Application extensions functional design

MD.060 Design Database extensions

MD.070 Create Application extensions technical design

MD.080 Review functional and Technical designs

MD.090 Prepare Development environment

MD.100 Create Database extensions

MD.110 Create Application extension modules

MD.120 Create Installation routines

6. Data Conversion [CV] – Data Conversion is the process of converting or transferring the data from legacy system to oracle applications. Ex. Transferring customer records from the legacy to the Customer Master.

CV.010 Define data conversion requirements and strategyCV.020 Define Conversion standards

CV.030 Prepare conversion environment

CV.040 Perform conversion data mapping

CV.050 Define manual conversion procedures

CV.060 Design conversion programs

CV.070 Prepare conversion test plans

CV.080 Develop conversion programs

CV.090 Perform conversion unit tests

CV.100 Perform conversion business objects

CV.110 Perform conversion validation tests

CV.120 Install conversion programs

CV.130 Convert and verify data

7. Documentation [DO] – Documentation prepared per module that includes user guides and implementation manuals.

DO.010 Define documentation requirements and strategyDO.020 Define Documentation standards and procedures

DO.030 Prepare glossary

DO.040 Prepare documentation environment

DO.050 Produce documentation prototypes and templates

DO.060 Publish user reference manual

DO.070 Publish user guide

DO.080 Publish technical reference manual

DO.090 Publish system management guide

8. Business System Testing [TE] – A process of validating the setup’s and functionality by QA(functional consultant) to certify status.

TE.010 Define testing requirements and strategyTE.020 Develop unit test script

TE.030 Develop link test script

TE.040 Develop system test script

TE.050 Develop systems integration test script

TE.060 Prepare testing environments

TE.070 Perform unit test

TE.080 Perform link test

TE.090 perform installation test

TE.100 Prepare key users for testing

TE.110 Perform system test

TE.120 Perform systems integration test

TE.130 Perform Acceptance test

9. Performance Testing [PT] - Performance testing is the evaluation of transactions saving time, transaction retrieval times, workflow background process, database performance, etc

PT.010 – Define Performance Testing StrategyPT.020 – Identify Performance Test Scenarios

PT.030 – Identify Performance Test Transaction

PT.040 – Create Performance Test Scripts

PT.050 – Design Performance Test Transaction Programs

PT.060 – Design Performance Test Data

PT.070 – Design Test Database Load Programs

PT.080 – Create Performance Test TransactionPrograms

PT.090 – Create Test Database Load Programs

PT.100 – Construct Performance Test Database

PT.110 – Prepare Performance Test Environment

PT.120 – Execute Performance Test

10. Adoption and Learning [AP] – This phase explains the removal of the legacy system and oracle application roll out enterprise wide.

AP.010 – Define Executive Project StrategyAP.020 – Conduct Initial Project Team Orientation

AP.030 – Develop Project Team Learning Plan

AP.040 – Prepare Project Team Learning Environment

AP.050 – Conduct Project Team Learning Events

AP.060 – Develop Business Unit Managers’Readiness Plan

AP.070 – Develop Project Readiness Roadmap

AP.080 – Develop and Execute CommunicationCampaign

AP.090 – Develop Managers’ Readiness Plan

AP.100 – Identify Business Process Impact onOrganization

AP.110 – Align Human Performance SupportSystems

AP.120 – Align Information Technology Groups

AP.130 – Conduct User Learning Needs Analysis

AP.140 – Develop User Learning Plan

AP.150 – Develop User Learningware

AP.160 – Prepare User Learning Environment

AP.170 – Conduct User Learning Events

AP.180 – Conduct Effectiveness Assessment

11. Production Migration [PM] – The process of “decommissioning” of legacy system and the usage(adoption) of oracle application system.

PM.010 – Define Transition Strategy

PM.020 – Design Production Support Infrastructure

PM.030 – Develop Transition and Contingency Plan

PM.040 – Prepare Production Environment

PM.050 – Set Up Applications

PM.060 – Implement Production Support Infrastructure

PM.070 – Verify Production Readiness

PM.080 – Begin Production

PM.090 – Measure System Performance

PM.100 – Maintain System

PM.110 – Refine Production System

PM.120 – Decommission Former Systems

PM.130 – Propose Future Business Direction

PM.140 – Propose Future Technical Direction

thanks – Shivmohan Purohit

Deleting a Schedules Request

How to delete the saved schedules, which were saved from the ‘Schedules’ tab of the ‘Submit Request’ window.
There is no standard functionality to delete any saved schedule.

The saved schedules are being stored in the table fnd_conc_release_classes_vl.
Select release_class_id, application_id, release_class_name schedule_name,
description, class_type schedule_type
from fnd_conc_release_classes_vl
where owner_req_id is null
and enabled_flag != ‘N’
and nvl(start_date_active,sysdate) <= sysdate
and nvl(end_date_active, sysdate) >= sysdate
order by release_class_name

If you want to delete any saved schedule from the LOV, then you can perform any of the following:
Delete the row from the table FND_CONC_RELEASE_CLASSES_VL for the saved schedule.
OR
It will be better to update the ENABLED_FLAG = ‘N’ for the saved schedule instead of deleting the row from the table FND_CONC_RELEASE_CLASSES_VL.

thanks – shivmohan

Oracle Financials – A Case Study

Here sharing recent communication on options to implement oracle Apps, i like you all to share you thoughts on this below scenario

I need the list of points or concerns  we need to take care of at the time of migration from 11.5.9 to 11.5.10.2.

Also I am in need information for M&A (merger and acquisition) perspective.
Say Company A acquires Company B. Company A is on 11.5.10.2 and Company B is on 11.5.9
Now A wants to get B on the same instance (11.5.10.2) as a separate operating unit. In this case what are the areas we need to concentrate on.
e.g. Common Item Master, Customer base.., B’s interfaces with some 3rd party system, Transaction between A and B…… etc

It would be very great if you could help me with this information …

—————————————————————–

Here if we consider this M&A , where Company A on 11.10 is target/ parent and company B is on 11.9 as legacy / secondary.

This case is like adding new operating unit in 11.10 for Company A , where it has advantage that Company B is already on Oracle with a lower version. Now here I think few thought to start with
GL Chart Of Accounts – This need to review the COA structure between A and B , having more different will make things more complex , having same will be great benefit. COA structure will drive the complexity of whole exerercise.
SOB and MRC – need to review the kind of SOB and MRC setup in both A & B , this will drive the kind of impact it will have and complexity of whole exercise.

As point 1 and 2 will form the foundation for merging B in A , and will outline the base architecture for remaining transaction and mater data to move in Company A.
Supplier/ Party / Customer / Employee/ Item / Inventory – all these master data need to review for company B and see if it duplicating or it need some mapping/ merging / cleaning or translation etc ,
GL transaction / GL history / GL Balance – this need to bring in A , this will depend on GL COA and GL SOB structure changes happened from B to A
AP ( open Invoice, payment history ) – this will business decision if they like to bring , the strong advice is to close all open invoice and keep history transaction in kind of archinve database for Company B till legally it require, This need to review if these are really require to bring in Company A where they may or may not useful.
AR ( Transaction , receipts  , history etc ) – This is recommended to bring in A , because this is surely impact the cash flow and allow lot of benefit to make future analysis and drive cash operations. Company A having any kind of Datawahrehouse , then I would recommend to bring all AP and AR transaction and history there directly rather bringing them in Apps and then send to DWH.
For fixed assets – I don’t see it could be much issue, all assets need to bring in A , and surely this can be manually if they are less in volume or  in automated way if large enough.

Another aspect to look for is Third party integration, Customization , Extension, Custom Reporting – As company B is moving to higher version so it need to consider as upgrade for them , from that point of view, you need to review if any changes needed in integration, or enhance/decommission customization, any more reports or less report need to migrate from B to A.

All above thoughts are surely very high level and brief , based on complete study , it will be more than 200 action items or more will outline only for fianancials to bring from Company  B to A , so it is very much driven from GL Structure between B and A and IT strategy of organization.

Thanks – Please share you thoughts to help in outline better approach

Account Recievables – Conversion – Invoices

Whenever we are going in for implementation of Receivables module, we have to consider the necessity of bringing in customer open balances from the old system to Oracle Receivables.

Some of the key questions that needs to be addressed before we take up a conversion activity. This is just a sample list and not an exhaustive one:

1. What are the different types of invoices in existing system Provide invoice samples? (invoices, credit/ debit memos, commitments, chargebacks)

2. Do we need to migrate only open invoices?

3. Do we migrate closed invoices also, if yes, then for what time period?

4. Please explain the invoice numbering mechanism? Is it automatic?

5. What are the interfaces from/to your existing receivables system?

6. Will the old system still be in place for querying and reporting purpose?

One can adopt one of the following three strategies for conversion:

1. Consolidate all the open balances customer-wise and create a single open invoice for each customer in the new Oracle system. The advantage of this system is that it is quite easy and not data intensive and makes good business sense in case of small businesses with very few customers. The major demerit of this approach is that later on one cannot track the individual invoices which the customer had sent and can become an audit issue also. In case of dispute over payment, this invoice will remain open till the dispute is resolved. Also, aging of invoices and dunning history will be lost.

2. Bring in all the open and partially paid invoices, credit/debit memos into the new system. Migrate all the unapplied and partially applied receipts to the new system. The advantage of this process of conversion is that you can track all open invoices individually and apply the correct receipt to correct invoice. Also, the conversion effort will be moderately low compared to case if you migrate all open and closed invoices. The disadvantage of this approach is that you cannot have a track of closed invoices in the new system. Also, it would be tough to handle scenarios where there is a dispute regarding incorrect receipt application, etc. This is the most common approach taken for receivables invoice, credit/debit memo and receipt migration.

3. Migrate all open and closed invoices to the new system. Reapply the migrated receipts to invoices in the new system. This approach makes sense if your receivables data is quite small else the effort involved in migrating all closed invoices and credit memos to the new system does not make much business sense.

The next question that arises is how we should migrate the invoices, credit/debit memos and receipts to the new system. Oracle provides standard interfaces to load the same. We can also use tools like Dataloader or manually key in the data into Oracle.

In this article i will talk of invoice, credit/debit memo conversion only. Prior to invoice migration, customer migration should be over apart from other pre-requisites. Following is the list of pre-requisites that should be completed prior to invoice, credit/debit memo conversion:

•Set-up of Customer Payment Terms should be complete

•Set-up of Currencies should be complete (this is necessary in case you have foreign currency invoices also)

•Set-up of Transaction Types should be complete

•Set-up of Accounting Rules should be complete

•Set-up of Tax rates and Tax codes should be complete

•Set up for sales representative should be complete

•Set up for debtor area should be complete

•Set up for income category should be complete

•Automatic customer invoice numbering should be set to ‘No’

•Customer and Customer address should be migrated in the system

•Disable the Invoice interface purge program so that the data successfully imported should not get purged in the interface table.

•Set up for invoice batch source name should be complete

In the next step extract Invoice data from the legacy files and using SQL loader populate the interface tables RA_INTERFACE_LINES_ALL and RA_INTERFACE_DISTRIBUTIONS_ALL. Submit the Auto Invoice open interface program. Data from the two interface tables will be uploaded to the following base tables using the Invoice open interface program:

•RA_CUSTOMER_TRX_ALL

•RA_CUSTOMER_TRX_LINES_ALL

•RA_CUST_TRX_LINE_GL_DIST_ALL

•RA_BATCHES_ALL

•RA_CUST_TRX_LINE_SALESREPS_ALL

•AR_RECEIVABLE_APPLICATIONS_ALL

•AR_PAYMENT_SCHEDULES_ALL

•RA_INTERFACE_ERRORS_ALL

Ensure that the Purge Interface check box is not checked when you submit the Autoinvoice program. In the Autoinvoice errors form you can see the error corresponding to failed records. Correct the errors in the interface table and rerun the Autoinvoice program. Submit the Autoinvoice Purge Program separately. Only records that have been successfully processed by Autoinvoice are purged.

Using autoinvoice you can migrate invoices, credit/debit memos and on-account credits into Oracle. However, you have to set grouping rules (Navigation > Setup > Transactions > Autoinvoice > Grouping Rule) to group lines to create one transaction and ordering rules (Navigation > Setup > Transactions > Autoinvoice > Line Ordering Rules) to determine the order of the transaction lines on a particular invoice.