Revaluing Foreign Currency Balances
Asset and Liability accounts that are entered in foreign currencies must be revalued every period in accordance with FAS52 (Financial Accounting Standards). The Revaluation program adjusts the value of the balance sheet accounts based on current period exchange rates. It then generates revaluation journals with adjustments to the defined unrealized gain/loss account. The Revaluation program generates adjustments in the Functional Currency. If you have a Reporting Set of Books you must run revaluation once for each Primary and Reporting Set of Books. The Revaluation generates a revaluation batch containing a separate journal for each foreign currency. The revaluation batch automatically has its reversal period set to the next accounting period. When you run revaluation for the next accounting period, you must reverse and post the last accounting periods revaluation batch first.
You get to the Revalue balances form by following navigation path
Currency->Revaluation
Translating Foreign Currency Balances
The Translation process translates actual and budget account balances to another currency in accordance FAS52. The translation program uses three different exchange rates: period-average, period end, and historical. The translation program translates asset and liability accounts using the period end exchange rate, ownership/stockholder equity accounts using the historical exchange rate, and revenue and expenses accounts using period average exchange rate. The period average exchange rate is the average rate of all daily rates across the entire accounting period.
The profile option GL: Owners equity transaction rule effects how ownership stockholders equity account balances are translated. If the profile option is set to PTD, the net activity accounts of the accounting period are translated, then added to the corresponding prior period balances. If the profile set to YTD the balances, not the activities are translated and the translated amounts are the YTD Balances. There is no need to add the balances to previous balances.
Navigation
Currency-> Translation
Multiple Reporting Currencies
Multiple Reporting Currencies allows you to maintain accounting transactions in more than one functional currency. MRC is set up by creating one or more Reporting Set of Books.
MRC need if
Your company is located a member state of EMU and would like to report financial data, including transaction level data, in both your functional currency and the Euro.
You must regularly report financial data including transaction level data in more than one currency because your company is multinational.
MRC Works for following modules
Assets, CashManagment, Cost Management , General Ledger, Payables, Projects, Purchasing, Receivables.
MRC works differently depdning on whether you enter the transaction inn Oracle Subledger or Oracle GL. When you enter transaction in subledgers the accounting transactions are translated into the Reporting set of books as you enter the transaction. When you transfer to Oracle GL, you must transfer to both the primary set of books and the reporting set of books you should post the transferred subledgers accounting transactions to the primary set of books as well as to all reporting set of books.
When you enter transactions in GL, the journal entries entered in the Primary Set of Books are not translated immediately into any reporting Set of Books, when the Journal entries are posted
In the Primary Set of Books it will transferred to reporting Set of Books. In the reporting Set of Books you can post, revalue , translate and consolidate.
Thursday, August 21, 2008
Oracle Receivables
Maintaining Invoice and Credit Memo Transactions
In oracle Receivables transaction can be reviewed an updated after creation regardless of whether the transaction was created manually or imported using ‘Auto Invoice’.There are exceptions to this and some system options and profile options have to be set.
If the Allow change to printed transactions system option is ‘Yes’ you can update most of the transaction information, even if the transaction has been printed. However if there is activity against the transaction, you will not be able to make changes to many of the transaction attributes. Activity includes actions such as payments, credit memos, adjustments and including transactions on a consolidated billing invoice.
After your transactions have posted to your General Ledger, you can still update most of information. Receivables maintains a complete audit trail of all the posted changes you make to your accounting entries.
Receivable does not maintain an audit trail when you change a transaction that has not been posted.
Also what can be changed depends on various attribute settings on the transaction.
In addition to updating transactions, you may find the need to delete or void a transaction. Again, there are circumstances under which deleting or voiding a transaction can be accomplished.
Transaction Field Reference
When reviewing the tables, you will notice the tables indicate the field reference in down the left side of the table with the conditions going across the rows. Within the rows is the indication as to whether this field reference can be updated or not any exceptions that must be considered. By using these tables you will resolve many of your own issues as to why a user cannot update particular field on an invoice or credit memo.
When reviewing the update table you will note there are two sections, header and line levels.
Once you save the transaction, you cannot update the transaction number.
Additionally here are some profile options and system options that effect maintaining transactions.
System options can be set as follows
Setup/System/System Options/Trans and Customers Tab
Set allow change to printed transactions to Yes
Profile Options can be set as follows
Using the system administrator responsibility
Profile/System
Site level
Query in the field for the profile of choice. Some profile options that affect maintaining transactions are
AR: Update Due
AR: Change Customer on Transaction
Allow update existing sales credits
Sequential Numbering – Make the options is not null at all levels, has to contain a value at least one level.
Delete or Void Transactions
Deleting or voiding transactions can be accomplished depending on how your administrator has setup function security on you Oracle Receivables.
If the allow change to Printed Transactions system options is set to Yes and transactions have no activity against them, then the transaction have no activity against them, then the transactions can be removed by one of the following methods:
By delete record from the edit menu. This will delete invoice and any lines.
Invoice with rules cannot be deleted but you can create a credit memo and apply it to the invoice. The credit memo will create a credit entry offsetting the invoice debit entry.
Void the invoice by changing the invoice type in the Transaction window to a type with the Open Receivables and Post to GL options set to No. This will delete the payment schedule and cancel the distributions by removing the GL Date.
Delete the payment schedule by choosing incomplete button in Transaction window. This makes the invoice inaccessible for payment or crediting.
Maintaining Transactions Navigation
Navigate to the Transactions or the Transactions summary window:
Transactions/Transactions
Query the Transaction.
Change the transaction type to ‘void’ transaction type
Save
Transaction Table Information
Invoice : When an invoice is created the Header information is written to the RA_CUSTOMER_TRX_ALL table. Changes to any of the header information such as the customer invoice line information is written to RA_CUSTOMER_TRX_LINES_ALL, RA_CUST_TRX_LINE_GL_DIST_ALL, AR_PAYMENT SCHEDULES_ALL and RA_CUST_TRX_LINE_SALEREPS_ALL.
RA_CUST_TRX_LINES_ALL holds line details, what and how much is being invoices a nd what tax is applicable.
RA_CUST_TRX_LINES_GL_DIST_ALL stores information that need to be posted across General Ledger.
AR_PAYMENT_SCHEDULES_ALL keeps running totals of the Invoice amounts for line,tax and freight. Record both the original amounts and the amounts remaining.
RA_CUST_TRX_LINE_SALEREPS_ALL stores who get credited for the sale represented by the invoice.
Credit Memo
Credit memos are stored in the same tables as the invoices. RA_CUSTOMER_TRX_ALL hold the credit memo header information similar to that of the invoice credit memo line information is t stored in RA_CUST_TRX_LINES_ALL, RA_CUST_TRX_LINE_GL_DIST_ALL, AR_PAYMENT SCHEDULES_ALL, AR_RECEIVABLE_APPLICATIONS_ALL
RA_CUSTOMER_TRX_LINES ALL holds credit memo line detail information.
AR_Receivable_Applicaitons_all- stores how much of the credit memo is applied
In oracle Receivables transaction can be reviewed an updated after creation regardless of whether the transaction was created manually or imported using ‘Auto Invoice’.There are exceptions to this and some system options and profile options have to be set.
If the Allow change to printed transactions system option is ‘Yes’ you can update most of the transaction information, even if the transaction has been printed. However if there is activity against the transaction, you will not be able to make changes to many of the transaction attributes. Activity includes actions such as payments, credit memos, adjustments and including transactions on a consolidated billing invoice.
After your transactions have posted to your General Ledger, you can still update most of information. Receivables maintains a complete audit trail of all the posted changes you make to your accounting entries.
Receivable does not maintain an audit trail when you change a transaction that has not been posted.
Also what can be changed depends on various attribute settings on the transaction.
In addition to updating transactions, you may find the need to delete or void a transaction. Again, there are circumstances under which deleting or voiding a transaction can be accomplished.
Transaction Field Reference
When reviewing the tables, you will notice the tables indicate the field reference in down the left side of the table with the conditions going across the rows. Within the rows is the indication as to whether this field reference can be updated or not any exceptions that must be considered. By using these tables you will resolve many of your own issues as to why a user cannot update particular field on an invoice or credit memo.
When reviewing the update table you will note there are two sections, header and line levels.
Once you save the transaction, you cannot update the transaction number.
Additionally here are some profile options and system options that effect maintaining transactions.
System options can be set as follows
Setup/System/System Options/Trans and Customers Tab
Set allow change to printed transactions to Yes
Profile Options can be set as follows
Using the system administrator responsibility
Profile/System
Site level
Query in the field for the profile of choice. Some profile options that affect maintaining transactions are
AR: Update Due
AR: Change Customer on Transaction
Allow update existing sales credits
Sequential Numbering – Make the options is not null at all levels, has to contain a value at least one level.
Delete or Void Transactions
Deleting or voiding transactions can be accomplished depending on how your administrator has setup function security on you Oracle Receivables.
If the allow change to Printed Transactions system options is set to Yes and transactions have no activity against them, then the transaction have no activity against them, then the transactions can be removed by one of the following methods:
By delete record from the edit menu. This will delete invoice and any lines.
Invoice with rules cannot be deleted but you can create a credit memo and apply it to the invoice. The credit memo will create a credit entry offsetting the invoice debit entry.
Void the invoice by changing the invoice type in the Transaction window to a type with the Open Receivables and Post to GL options set to No. This will delete the payment schedule and cancel the distributions by removing the GL Date.
Delete the payment schedule by choosing incomplete button in Transaction window. This makes the invoice inaccessible for payment or crediting.
Maintaining Transactions Navigation
Navigate to the Transactions or the Transactions summary window:
Transactions/Transactions
Query the Transaction.
Change the transaction type to ‘void’ transaction type
Save
Transaction Table Information
Invoice : When an invoice is created the Header information is written to the RA_CUSTOMER_TRX_ALL table. Changes to any of the header information such as the customer invoice line information is written to RA_CUSTOMER_TRX_LINES_ALL, RA_CUST_TRX_LINE_GL_DIST_ALL, AR_PAYMENT SCHEDULES_ALL and RA_CUST_TRX_LINE_SALEREPS_ALL.
RA_CUST_TRX_LINES_ALL holds line details, what and how much is being invoices a nd what tax is applicable.
RA_CUST_TRX_LINES_GL_DIST_ALL stores information that need to be posted across General Ledger.
AR_PAYMENT_SCHEDULES_ALL keeps running totals of the Invoice amounts for line,tax and freight. Record both the original amounts and the amounts remaining.
RA_CUST_TRX_LINE_SALEREPS_ALL stores who get credited for the sale represented by the invoice.
Credit Memo
Credit memos are stored in the same tables as the invoices. RA_CUSTOMER_TRX_ALL hold the credit memo header information similar to that of the invoice credit memo line information is t stored in RA_CUST_TRX_LINES_ALL, RA_CUST_TRX_LINE_GL_DIST_ALL, AR_PAYMENT SCHEDULES_ALL, AR_RECEIVABLE_APPLICATIONS_ALL
RA_CUSTOMER_TRX_LINES ALL holds credit memo line detail information.
AR_Receivable_Applicaitons_all- stores how much of the credit memo is applied
ORACLE FUSION MIDDLEWARE
JDeveloper
Oracle JDeveloper is an integrated development environment (IDE) for building service oriented applications using the latest industry standards for JAVA,XML,Web Services and SQL.
Oracle J Developer supports the complete development life cycle with integrated features for modeling, coding, debugging, testing, profiling, tuning and deploying applications.
JDeveloper visual and declarative development approach and innovative Oracle Application Development Framework (Oracle ADF) work together to simplify application development and reduce nundane coding tasks, offering unparalleled productivity and a choice of technology stacks.
Although JDeveloper is mainly a Java Development tool it offers extensive support for development in related languages and environments as well. In addition to the Java capabilities ,JDeveloper enables XML based application development with features such as the XML Schema Modeler, XML code insight and visual editing, and XSLT debugging. Oracle JDeveloper also provides a full development and modeling environment for building database objects and stores procedures.
Applications developed with JDeveloper work with any data source and can be deployed on any J2EE compatible application server.
Oracle JDeveloper a 100% Java based tool is a cross platform IDE that runs on windows Linux, MAC and various unix based systems letting developers choose their preferred development platform.
Oracle JDeveloper is an integrated development environment (IDE) for building service oriented applications using the latest industry standards for JAVA,XML,Web Services and SQL.
Oracle J Developer supports the complete development life cycle with integrated features for modeling, coding, debugging, testing, profiling, tuning and deploying applications.
JDeveloper visual and declarative development approach and innovative Oracle Application Development Framework (Oracle ADF) work together to simplify application development and reduce nundane coding tasks, offering unparalleled productivity and a choice of technology stacks.
Although JDeveloper is mainly a Java Development tool it offers extensive support for development in related languages and environments as well. In addition to the Java capabilities ,JDeveloper enables XML based application development with features such as the XML Schema Modeler, XML code insight and visual editing, and XSLT debugging. Oracle JDeveloper also provides a full development and modeling environment for building database objects and stores procedures.
Applications developed with JDeveloper work with any data source and can be deployed on any J2EE compatible application server.
Oracle JDeveloper a 100% Java based tool is a cross platform IDE that runs on windows Linux, MAC and various unix based systems letting developers choose their preferred development platform.
Wednesday, August 20, 2008
11i and 12 i -Changes
11i and 12i
In 11i the field 'bank_account_id' acts as a relation key between the AP_CHECKS_ALL and AP_BANK_ACCOUNTS_ALL tables.
In 12 i the same field is no longer is used in 'AP_CHECKS_ALL' table.
In 12 i where 'CE_BANK_ACCT_USE_ID' is acts as a relation between 'CE_BANK_ACCT_USES_ALL' and 'AP_CHECKS_ALL'
highlights of release 12i
A single responsibility to access and transact on multiple organizations.
A single ledger to manage multiple currencies.
Ledger sets to manage accounting processes across ledger.
Centralized rules engines for tax, accounting and Intercomapny.
Centralized trading partners i.e Suppliers, Banks, First Party legal entities.
Simplified reporting via XML Publisher and DBI.
Netting across trading partners.
In 11i the field 'bank_account_id' acts as a relation key between the AP_CHECKS_ALL and AP_BANK_ACCOUNTS_ALL tables.
In 12 i the same field is no longer is used in 'AP_CHECKS_ALL' table.
In 12 i where 'CE_BANK_ACCT_USE_ID' is acts as a relation between 'CE_BANK_ACCT_USES_ALL' and 'AP_CHECKS_ALL'
highlights of release 12i
A single responsibility to access and transact on multiple organizations.
A single ledger to manage multiple currencies.
Ledger sets to manage accounting processes across ledger.
Centralized rules engines for tax, accounting and Intercomapny.
Centralized trading partners i.e Suppliers, Banks, First Party legal entities.
Simplified reporting via XML Publisher and DBI.
Netting across trading partners.
Tuesday, August 19, 2008
Oracle AIM Methodology
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 very useful tool for managing implementation projects sucessfully. This is a depiction of 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 )Buisness process archtechture-BP
This phase outlines - Existing Business Practices,Catalog change practices,Future practices
BP.010 Define Business and Process StrategyB
P.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 questionnarie and gathering of requirements. RD010 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 Gaps
BR.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 Strategy
TA.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 strategy
CV.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 strategy
DO.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
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 strategy
TE.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 Strategy
PT.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 Strategy
AP.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
Application Implementation Method is a proven approach for all the activities required to implement oracle applications. there are eleven processes of implementation.
1 )Buisness process archtechture-BP
This phase outlines - Existing Business Practices,Catalog change practices,Future practices
BP.010 Define Business and Process StrategyB
P.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 questionnarie and gathering of requirements. RD010 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 Gaps
BR.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 Strategy
TA.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 strategy
CV.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 strategy
DO.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
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 strategy
TE.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 Strategy
PT.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 Strategy
AP.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
General Ledger
Q) What is Planning Budget?
A) The plan for the future expenses is planning budget. It is a paper work. There is no funds requirement. It does not require journals. There are no restrictions for estimating of funds. It is a budget through which you cannot excercise budgetary control . But you can compare your actual budgets through inquiry window.
Q) After creating Journal Source how do we approve to the specific set of Books?
A) To approve journals from specific source, while creating the source 'Require Journal Approval'
check box should be enabled. To approve all the journals that come from different sources In the Set of Books window under 'Journaling' tab 'journal approval' should be enabled.
A) The plan for the future expenses is planning budget. It is a paper work. There is no funds requirement. It does not require journals. There are no restrictions for estimating of funds. It is a budget through which you cannot excercise budgetary control . But you can compare your actual budgets through inquiry window.
Q) After creating Journal Source how do we approve to the specific set of Books?
A) To approve journals from specific source, while creating the source 'Require Journal Approval'
check box should be enabled. To approve all the journals that come from different sources In the Set of Books window under 'Journaling' tab 'journal approval' should be enabled.
Subscribe to:
Posts (Atom)