Detailed Functional Components of iExpenses:
1. Expense Report Entry:
1.1 Create Expense Report:
· Employees log on to Oracle Web Expense and enter their expense report using a standard Web browser.
· Employees enter general information about their expense report in the Report Information region.
· Employees enter their expenses in the Enter Receipts region.
· iExpense offers a “disconnected solution”, to meet the needs of employees with limited access to the corporate intranet. Employees can enter expense reports off line, and save them for later submission, when intranet access is available.
· The disconnected expense reporting process involves the following:
· Employees use the Download Expense Spreadsheet function to save a copy of Client’s expense spreadsheet template locally. Employees must be connected to the corporate intranet in order to use the Download Expense Spreadsheet function.
· Employees use an expense spreadsheet to enter their expense reports while disconnected from the corporate intranet.
· Employees use the Upload Expense Spreadsheet function to transfer expense reports created with a spreadsheet to iExpense. Once uploaded, the transferred information appears as an expense report in iExpense, and employees can update, save, or submit it. Employees must be connected to your corporate intranet to use the Upload Expense Spreadsheet function.
· iExpense automatically populates the Cost Center field with the cost center of the employee requesting reimbursement.
· For manager approval, employees direct their expense report to their manager. When required, employees can redirect their expense report for approval by entering a value in the Override Approver field of the expense report template.
1.2 Review:
· iExpense enables employees the opportunity to review their expense report before they submit it.
· Employees use the View Receipts region to view expense lines in the order they entered them.
· The View Receipts region also identifies the expense lines for which your accounts payable department requires original receipts.
· Employees can use the Expense Summary region to view weekly summaries of their expense reports.
· The Expense Summary region displays amounts for each expense type. Employees can click on amounts to see detailed information for the receipt(s) that make up that amount.
· iExpense enables employees to check the status of their expense report(s).
· Employees can see whether their expense reports have been approved by their manager.
· Employees can see whether the accounts payable department has reviewed their expense reports.
· To view expense report statuses, employees choose the View Expense Report History function from the main menu.
· If an employee’s expense report has been adjusted by the accounts payable department, the employee can choose the View Expense History function, to see why an adjustment was made to their expense report.
1.3 Submit Expense Report:
· Employees submit their expense report using a standard Web browser.
· After employees submit their expense report, it is their responsibility to send original receipts to the accounts payable department for verification.
2. Validation:
2.1 Server Side Validation:
· The Server Side Validation process adds required information to the AP Expense Report Headers, and AP Expense Report Lines tables in order for the workflow approval processes and the Payables Invoice Import program to function properly.
· The accounts payable department can query and view Web Expense reports only after the expense reports pass the Server Side Validation process.
2.2 Manager (Spending) Approval Process:
· The Manager (Spending) Approval Process routes expense reports to managers for their approval.
· If an expense report receives manager approval, it transitions to the AP Approval Process.
· If a manager rejects an expense report, the expense report transitions to the Rejection Process.
· When managers reject expense reports, The Rejection Process begins.
· With this process, the employee is notified that their expense report(s) has been rejected.
· Employees can retrieve, fix, and resubmit rejected expense reports by using the Modify Expense Reports function.
2.3 AP Approval Process:
· The AP Approval Process first determines whether expense reports require the approval of the accounts payable department as defined in the AP Expense Report Workflow.
· If accounts payable approval is not required, the process automatically gives accounts payable approval.
· If expense reports require accounts payable approval, then the process waits for the results of the accounts payable department review.
· The accounts payable department uses the Expense Reports window in Oracle Payables to review, adjust, short pay, and approve iExpense reports.
· The accounts payable department approves expense reports by checking the Reviewed by Payables check box.
· Once the expense report has been approved by the accounts payable department, the Invoice Import program in Oracle Payables converts the expense report into an invoice for payment.
3. Payables:
3.1 Payables Import Process:
· Submit the Payables Invoice Import program in Oracle Payables to convert expense reports into invoices.
· An iExpense report is eligible for Invoice Import after successfully completing the AP Expense Report workflow process.
· When expense reports cannot be imported, Payables prints the Invoice Import Rejections Report.
· If the expense report is rejected, correct the problems, and resubmit the Payables Invoice Import program.
3.2 Accounts Payable Approval/Pay Expense Reports:
· iExpense enables you to enforce company expense report and reimbursement policies.
· To enforce policies, the accounts payable department uses the Expense Reports window in Oracle Payables to approve, adjust, or short pay employee expense reports.
· When the accounts payable department adjusts an expense report, the AP Approval workflow process informs the employee of the reason for, and the amount of, the adjustment.
· When the accounts payable department short pays an expense report, the Shortpay Unverified Receipt Items workflow does the following:
· Creates a new expense report from the lines which have missing required receipts, and/or creates a new expense report from the lines which have inadequate justifications.
· Eliminates the lines the accounts payable department short paid from the original expense report and approves it.
· Once the accounts payable department has approved, and/or adjusted the employee’s expense report, a payment is created for the invoice in the same manner as other invoices.
4. The Expense Report Template:
4.1 Descriptive Flexfields:
· Descriptive Flexfields enable employees to enter additional information about receipts not otherwise captured in iExpense.
· Descriptive Flexfields can be defined so they appear as either a text box with a poplist that contains a list of values, a check box, or a text box.
· Descriptive Flexfields have two different kinds of segments or fields, global and context sensitive.
· Context sensitive segments appear only when an employee selects expense types to which you have associated flexfield segments.
· Global segments always appear in the Enter Receipts region, regardless of the expense type an employee chooses.
· The Descriptive Flexfields defined for Web Expense also appear in the Expense Reports window in Oracle Payables.
· To plan context sensitive and global descriptive flexfields for use in iExpense you must:
· Determine for which expense types you want to collect additional information. These are the context sensitive segments.
· Determine what information you want to collect regardless of expense type. These are the global segments.
· Determine how you want employees to enter information. You can choose from the following three methods:
· a text box with a poplist that contains a list of values
· a check box
· a text box.
4.2 Multiple Expense Templates:
· An expense template defines the list of expense types (airfare, car rental, meals, etc.) employees can choose from when they enter their expense reports.
· You can define multiple expense report templates for use with iExpense.
· If you define multiple expense report templates, employees can select an expense report template from a list of values in the Report Information region.
4.3 Original Receipts:
· When you define expense report templates for use with iExpense, you can indicate whether an original receipt is required for an expense type.
· You can also indicate that an original receipt is required only if the expense exceeds a certain limit.
· The employee can see whether an original receipt is required in the View Receipts region of iExpense.
· Employees have the ability to indicate that they do not have an original receipt by checking the Original Receipt Missing check box in the Enter Receipts region.
· iExpense can be set up so when employees check the Original Receipt Missing check box, it changes the status of a receipt from required to unrequired.
4.4 Refund/Credit Tracking:
· Set up iExpense so employees can enter negative receipts (credit lines) when creating an expense report.
· Employees enter negative receipts to report refunds from a previous reimbursed expense (I.e., the refund of an unused airline ticket).
4.5 Required Justifications:
· Set up iExpense so employees are required to enter justifications for specific expenses.
· When you define an expense report template, you can indicate whether justification is required for the expense.
4.6 Required Purpose:
· Set up iExpense so employees are required to provide a purpose for their expense report.
· When you define an expense report template, you can indicate whether a purpose is required for the expense.
4.7 Expense Report Number Prefixes:
· You can define a prefix for every expense report entered in iExpense.
· Entering a prefix value enables you to easily identify invoices in Oracle Payables originally created as iExpense employee expense reports.
Friday, April 18, 2008
Implementing iExpenses for a Global Professional Services Firm (Part 2)
Revenue Recognition and Invoicing Rules explained
Revenue recognition principle is an important accounting principle, which is the main difference between cash basis accounting and accrual basis accounting. In cash basis accounting revenues are simply recognized when cash is received no matter when and how the services were performed or goods delivered. In accrual basis accounting revenues are recognized when they are (1) realized or realizable and (2) earned no matter when cash is received.
Revenue recognition criteria according to US GAAP:
USSEC's SAB104 states that revenue generally is realized or realizable and earned when all of the following criteria are met:
1. Persuasive evidence of an arrangement exists;
2. Delivery has occurred or services have been rendered;
3. The seller's price to the buyer is fixed or determinable; and
4. Collectability is reasonably assured
Invoicing Rules and Accounting Rules:
In Oracle AR, the invoicing and accounting rules help create invoices that span several accounting periods. Accounting rules determine the accounting period or periods in which the revenue distributions for an invoice line are recorded. Invoicing rules determine the accounting period in which the receivable amount is recorded.
Accounting Rules:
Accounting rules determines revenue recognition schedules for invoice lines. Different accounting rules can be assigned to each invoice line. Using Accounting rules, the number of periods and the percentage of the total revenue to recognize in each period can be specified. Also accounting rules can be Fixed or Variable Duration.
Clients can also create rules that will defer revenue to an unearned revenue account. This helps in the delay of specifying the revenue recognition schedule until the exact details are known. When these details are known, clients use the Actions wizard to recognize the revenue.
Invoicing Rules:
Invoicing rules determines when to recognize receivable for invoices that span more than one accounting period. Clients can only assign one invoicing rule to an invoice. Receivables provides the following invoicing rules:
• Bill In Advance: Use this rule to recognize your receivable immediately.
• Bill In Arrears: Use this rule if you want to record the receivable at the end of the revenue recognition schedule.
Using Invoices with Rules:
Assigning Invoicing Rules:
• Invoicing rules determine whether to recognize receivables in the first or in the last accounting period.
• Once the invoice is saved, you cannot update an invoicing rule.
• If Bill in Arrears is the invoicing rule, Oracle Receivables updates the GL Date and invoice date of the invoice to the last accounting period for the accounting rule.
Assigning Accounting Rules To Invoice Lines:
• Accounting rules determine when to recognize revenue amounts.
• Each invoice line can have different accounting rule.
Creating Accounting Entries:
• Accounting distributions are created only after the Revenue Recognition program is run.
• For Bill in Advance, the offset account to accounts receivable is Unearned Revenue.
• For Bill in Arrears, the offset account to accounts receivable is Unbilled Receivables.
• Accounting distributions are created for all periods when Revenue Recognition is run.
Running The Revenue Recognition Program:
• The Revenue Recognition program gives control over the creation of accounting entries.
• Submit the Revenue Recognition program manually through the Run Revenue Recognition window.
• The Revenue Recognition program will also be submitted when posting to Oracle GL.
• The program processes revenue by transaction, rather than by accounting period.
• Only new transactions are selected each time the process is run.
Tuesday, April 15, 2008
Implementing iExpenses for a Global Professional Services Firm (Part 1)
Client and Business Case - Global Professional Services Firm executing projects globally wanted to implement Oracle Internet Expenses to support employee expense reporting and reimbursement. Oracle iExpenses was implemented to enable Client employees to independently enter and submit their expense reports on-line, real time, utilizing a standard Web browser or a Web-enabled mobile device. Oracle Workflow was configured to automatically routes expense reports for approval and enforce reimbursement policies. Oracle iExpenses integrates with Oracle Payables and Oracle Projects to provide quick processing of expense reports for payment.
Key Features implemented - The implementation of iExpense enabled the client to benefit from the following functionalities:
1. Enable employees to record, and submit expense reports using a standard Web browser.
2. Provide employees a “disconnected solution” when access to a corporate intranet is not available.
3. Use Descriptive Flexfields to enter additional information about expense related receipts not otherwise captured in the Expense Template.
4. Define multiple Expense Templates. Employees can choose from a List of Values the Expense Template(s) available.
5. Define Expense Templates, and indicate whether an original receipt is required for the expense type so employees are aware of the original receipts requirement.
6. Use Oracle Workflow with Oracle Web Expense to automatically route expense reports for approval, and enforce reimbursement policies.
7. Use Oracle Web Expense to seamlessly integrate with Oracle Payables so expense reports can be quickly processed for payment.
8. Create “Authorized Delegates” to authorize a user to enter expense reports for another employee. (i.e., An executive assistant is given the authority to enter expense reports for their manager.)
9. Indicate in the Expense Template if original receipts are required.
10. Allow employees to enter negative receipts to report refunds, or credits against their reported expenses.
High Level Business Flow:
Key Components of the implementation:
In my next post, I will try and expand on each of the key components implemented above.
Monday, April 14, 2008
Configuring for TAX in Oracle Apps (Rel 12)
Supported Tax Software Versions - Following Vertex and Taxware Versions are Certified for Release 12:
Vertex Q Series 3.2
Taxware 3.5.0
Please be sure to mention to Vertex / Taxware that you would need file for Release 12. The data files have been changed in Release 12 and you can not use the same file as in Release 11i or before.
Loading Tax information into Rel 12i:
1) Please get datafile from tax partners (Vertex or Taxware) in R12 format .
2) Copy file to a Linux or Unix directory. Filename - *.dat. Please note that loading the datafile into interface table is a part of the Request Set and will not need to be done manually.
3) Click "Tax Managers" resp
4) Click "Schedule Request Set" link under "Requests"
5) Select "E-Business US Sales and Use Tax Import Program" from the "Request SetName" LOV
6) In the first stage,
a) Enter "File Location and Name" parameter (directory in which partner datafile has been placed, filename could be *.dat) e.g. "/home/user/zx/TMD2.dat" ,
b) select "2" (for Taxware) or "1" (for Vertex) for the "Tax Content Source" parameter,
c) and select a Tax Regime Code (new or migrated) for "Tax Content Source Tax Regime Code" parameter.
7) Click "Next" twice to submit the request.
8) Check the status of programs
9) After completion, data will be loaded into TCA Geography model and EBTax entities - Tax, Status, Rates, Jurisdictions.
R12 Oracle E-Business Tax Configuration (By Mariluci Pereira - Metalink)
1. Basic Tax Configuration:
Tax Definition: comprises the tax data that you set up for each tax regime and tax that your company or institution is subject to. The Tax Authority designates the regulations and rates that apply to the tax regime.
Required Task List:
a) External Dependencies
1. Create First Party: Legal Entity and Establishments
2. Create Reporting and Collecting Tax Authorities
b) Tax Configuration
1. Create Tax Authorities Party Tax Profiles
2. Create Tax Regimes
3. Create First Party Legal Entity Party Tax Profile
4. Create Tax
5. Create Tax Status
6. Create Tax Jurisdictions
7. Tax Rate
2. Managing Party Tax Profiles:
The configuration tier identifies the factors that participate in determining the tax on an individual transaction. These “taxability” factors are: party, product, place and process.
3. Configuration Owners and Service Providers:
a) Tax Configuration Ownership
b) Tax Configuration Options
c) Configuration for Taxes and Rules
d) Configuration for Product Exceptions
e) Service Subscriptions
f) Legal Entity and Operating Unit Configuration Options
g) Event Classes
h) Configuration Owner Tax Options
4. Fiscal Classifications:
Fiscal classifications provide tax determination values for situations where the party, product, or transactions are factors in tax determination. You set up a fiscal classification type to identify a category of fiscal classification that has a potential tax implication; you assign fiscal classification types to tax regimes and taxation countries. You set up fiscal classification codes under a fiscal classification type to provide additional granularity to a particular fiscal classification category. When creating tax rules, you use fiscal classification types as determining factors and fiscal classification codes as condition set values.
5. Setting Up Tax Rules:
You create tax rules by translating the tax regulations of a tax authority into determining factors and tax conditions that the E-Business Tax tax rules engine uses to evaluate the applicability of a tax on each transaction line. Tax rules determine: the applicability of a tax; the place of supply and tax jurisdiction of the transaction; the tax registration; the tax status and tax rate; the recovery rate (if applicable); and the taxable basis and tax formula to use in calculation.
6. Setting Up Tax Rules – Determining Factors:
Determining factors are the key building blocks of your tax rules. They are the variables that are passed at transaction time or derived from information on the transaction. Determining factors fall into four groups, namely: Party, Product, Place and Process. A determining factor is an attribute that contributes to the outcome of a tax determination process, such as a geographical location (place) or tax registration status (party). Determining factors can be used in tax rules, taxable basis formula, and tax regime determination.
Please read the Metalink whitepaper to get detailed step by step instruction on how to setup each of the above configurations in Oracle Apps.
Reference Notes:
Metalink Doc ID’s = 461084.1, 552390.1, 466575.1, 456310.1
AP Check fraud prevention in Oracle Apps - Payee Match with Positive Pay
Client and Business Case – A large multinational corporation wanted to implement a very tight check fraud prevention tool while implementing Oracle Payables. This was because of the reason that with today’s technology, it has become much easier for individuals to commit check fraud. The corporation was concerned with the recent increase in check fraud activity perpetrated against itself, hence they needed a more effective fraud-fighting tool within Oracle Apps.
Solution - In order to reduce Client’s susceptibility to check fraud, Payee Match was implemented. Payee Match is a tool used by corporations and financial institutions to match the amount and serial numbers on checks as well as the name of the payee given out in the “Payee Zone” on the check.
Payee Match service works independently of the Positive Pay Service. It matches all the data in the “Payee Zone” on the face of Client’s checks. This service usually works in conjunction with the Positive Pay service.While Positive Pay verifies the amount and the serial numbers of the check Payee Match provides a third line of defense against check fraud by verifying the payee name and address. Payee Match matches a file, sent by the Client, to the checks presented for payment at the bank. The Client will have the choice to pay or reject any non-matched items.
Payee Match generates pay or no pay alerts on the following data elements:
a) Issued date
b) Serial Number
c) Amount
d) Transit Number
e) Bank Identifier
f) Account Number
g) Payee Name
h) Payee Address.
High level Solution Steps:
1. Develop a Custom Positive Payee match Report in Oracle to include all the data elements of Payee Match as per the structure required by the Client.
2. Run the Positive Payee Match Report
3. Format the text file generated by the Positive Payee Match Report as per the format agreed to with the banks.
4. Custom Scheduler Process --FTP the file to the desired location in the server as per the bank’s specification
5. Bank will tabulate and send the results of payments by payee detailing the count for each pay cycle in a text file to the desired location on the FTP Server.
6. Custom Scheduler Process will grab the text file sent by bank from the designated location and sends it to the desired location on the Oracle server.
Detailed User Procedures:
In order to achieve the payee match solution the following steps need to be performed:
1. Development of a custom report on the lines of the standard Positive Payee Match report in Oracle.
2. Run the report and format the resulting text file as per the bank’s format.
3. Custom Scheduler Program will extract the file from the oracle server and FTP it to the FTP server from where the bank can download the same. This will be on a daily basis with at least one pay cycle per day throughout the week beginning from Sunday and ending on Friday.
4. Need to create an image map of Client check stock; anything inside the image map is called the “Payee Zone”. The Payee Zone is read using OCR technology and converted into a text string, with each element being separated by a space. All punctuation and white space is removed from the string. All information contained in the Payee Name Zone of the physical check must be included in the fields “Check Sequence 1” through “Check Sequence 10” in order of appearance on the physical check (top to bottom, left to right.)
5. Once the scanned data is converted to a text string, the matching software combines all of the Check Sequence fields from the Client issued file into a string, and separates each field element with a space. It then compares this string to the scanned data from the check. This comparison identifies any discrepancies that may have been caused by fraudulent activity. If any discrepancies are detected between the two strings, the check is examined manually. If it is determined that the mismatch is not caused by a computer error, then Client is notified of the discrepancy with a pay / no pay decision, via email or fax.
6. The Bank will upload the file with the count of the payments in the particular pay cycle to the FTP server from where the custom scheduler program can retrieve and send it over to the designated location in the Oracle server.
Saturday, April 12, 2008
Happy Tamil New Year - My blog registered at blogs.oracle.com
Overview of Bank Reconciliation using Oracle Cash Management
Bank Reconciliation Process - Bank accounts are the assets of the company and must be explained as part of the audit requirements. Bank reconciliation can reveal fraud as well as errors. Reconciliation is the process of explaining the difference between two balances which could be due to legitimate reasons like timing differences.
Bank Reconciliation uses the following formula:
Bank Account Balance in Oracle Financials + Items on Bank Statement, but not in Financials
Items in Financials, but not on Bank Statement = Balance as per Bank Statement
Both types of differences are to be analyzed to determine whether the source of discrepancy was error or a legitimate difference and action initiated accordingly.
Legitimate differences occur due to the following reasons:
1. Timing differences – Check Issued but not presented or Checks Deposited but not cleared.
2. Bank charges and other items unknown till the bank statement is received.
3. Fees for currency conversion
4. Unprocessed Transactions
These differences once identified have to be eliminated by making appropriate accounting entries.
Reconciliation Process:
Bank transactions entered directly into GL or generated from Payables, Receivables or Payroll can be reconciled with CM.
1. Loading the Bank Statement:
The transactions can be reconciled manually or automatically by loading an electronic statement directly into CM. Loading is done using the bank statement open interface where a bank statement in the requisite flat file format is uploaded into CM tables. The automatic reconciliation looks for certain match criteria to determine whether a transaction and a bank statement line are one and the same.
2. Reconciling Journal Entries:
The journal entries entered directly in GL can be reconciled with the bank statement. The Auto reconciliation program matches a journal line description with the bank statement line transaction number.
3. Reconciling Payments:
Supplier payments entered in Payables can be reconciled to the bank statement lines in CM. The payment status against each check is updated as “Reconciled”.
4. Reconciling Receipts:
Receipts created in Receivables can also be reconciled to the bank statement lines in CM. CM updates the status of the receipts to “Reconciled” and creates appropriate accounting entries for transferring to GL. Payables and Receivables can generate reconciliation accounting entries for cash clearing, bank charges and foreign currency gain or loss.
5. Reconciling other Transactions:
Certain transactions like bank charges, interest credits, specific exchange rate applied against foreign currency transactions, customer receipts returned due to bounces etc, are known only when the bank statement is received. These would not have been initiated from Oracle Applications. CM is the primary point of entry for these transactions.
Importing Bank Statements and Validation:
Use CM’s Reconciliation programs to:
•Validate the information in the bank statement open interface tables
•Import the validated bank statement information
•Perform an automatic reconciliation after the import process completes
The AutoReconciliation program performs the following validations on loading bank statement information into the bank statement open interface tables:
•Bank statement header validation
•Control total validation
•Statement line validation
•Multicurrency validation
Reconciling Bank Statements Automatically:
Use AutoReconciliation program to automatically reconcile any bank statement in Oracle CM. There are three versions:
1. AutoReconciliation: Use this program to reconcile any bank statement that has already been entered in CM.
2. Bank Statement Import: Use this program to import an electronic bank statement after loading the bank file with a SQL*Loader script.
3. Bank Statement Import and AutoReconciliation: Use this program to import and reconcile a bank statement in the same run. After the program has been run, review the AutoReconciliation Execution Report to identify any reconciliation errors that need to be corrected and re-run the program again if corrections are done.
Thursday, April 10, 2008
Accounting for Refunds within Oracle Payables
Refund Scenario - A supplier will send a request for a deposit of prepayment to the Accounts Payable group. The following is a basic overview of the standard account suggested by Oracle for the entry of a prepayment with a refund from the supplier.
1. Enter a prepayment invoice to the supplier.
Prepayment Account (default) - DR.
Liability Account - CR.
2. Pay the prepayment invoice to the supplier.
Liability Account - DR.
Cash Clearing Account - CR.
3. Reconcile payment in cash management.
Cash Clearing Account - DR.
Cash Account - CR.
The supplier sends a refund check for ‘some amount’ (XX) of the original prepayment.
___________________________________________________________________________________________
4. The Accounts Payable person enters a ‘dummy’ invoice with invoice number ‘Refund XXXXX’ in the amount of the refund.
Expense Account DR. ******Cash Account workaround.
Liability Account CR.
5. Match the invoice to the original prepayment invoice.
Liability Account DR.
Prepayment Account (default) CR.
___________________________________________________________________________________________
At this point, the refund has never been officially recorded in Payables or in Cash Management. The refund will not show any or Oracle’s standard reports. Oracle’s standard process for recording refunds of prepayments includes an additional step to record the refund in Payables and in Cash Management.
6. The Accounts Payable person enters a ‘dummy’ Debit Memo.
Liability Account DR.
Expense Account CR.
7. The debit memo is ‘paid’ with the entry of the refund check.
Cash Clearing DR.
Liability Account CR.
8. The refund is reconciled through Cash Management
Cash DR.
Cash Clearing CR.
___________________________________________________________________________________________
******The Cash account can be used for logging the payment to the correct GL account. However, there are no provisions to have the refund show up on the AP standard reports or to be cleared through Cash Management.
Monday, April 7, 2008
Retrospective Payroll Processing in Oracle Payroll
Client and Business Case - A global manufacturing company wanted to automate the retrospective pay calculation in Oracle Payroll for critical payroll processes like retrospective pay awards, temporary promotions, secondments, retro pay for part timers etc.
Solution - Oracle Payroll allows you to make back pay adjustments through the RetroPay process. Key points include:
–Inputs to pay that were originally correct have now changed retroactively.
–You receive late notifications of promotions.
–You can run the RetroPay process from the submit Requests window.
How Retro Pay Works - Oracle Payroll now rolls back and reprocesses all the payrolls for the assignment set from the date you specified. The system compares the old balance values with the new ones and creates entry values for the RetroPay elements based on the difference. These entries are processed for the assignments in the subsequent payroll run for your current period.
No changes are made to your audited payroll data.
Configuration - All payroll elements configured during the implementation are assessed for whether they are “retropay’able” or not. Usually all regular payments and allowances are considered eligible for retropay. Voluntary deductions and some non-recurring payments are not normally eligible but can be made so if required.
For each eligible element a corresponding “Retropay Element” is also configured. These elements will hold the results of any pay adjustments calculated by the “Retropay” process.
A number of Retropay element “Groups” may also be configured. I.e. There will almost certainly be a group which includes all eligible elements but there could be another group which is just for bonus related adjustments. This gives flexibility when running retropay to restrict the process to just those items where you are notified that a change is due.
Operational steps - Immediately prior to every payroll calculation the “Retropay Notifications” report should be run. This lists any system changes that indicate a retrospective adjustment may be due. E.g. One or more employees may have had a late or corrected entry of a new allowance, change of Grade, change of Grade Step placement etc.
Using the “Retropay Notifications” report you can establish the assignments, period and elements for which retrospection is needed.
If a retrospective calculation is needed, then run the standard “Retropay by Element” process.
Input parameters are :-
Assignment set – if you want to restrict the run to selected assignments
Retropay element group – if you want to restrict the run to selected elements
Start date – this is the earliest date you want the system to recalculate from
End date – this is the latest date you want the system to recalculate up to
The process recalculates for the assignments, period and elements indicated. Any resulting adjustments are attributed to each relevant retropay element and entered into the current pay period for processing in the full payroll gross to nett run. In this way the results of the previous period(s) payrolls are not amended. The adjustments will only affect values and be costed in the current payroll period.
How the notification process works - During the implementation “Dynamic Triggers” will be configured. These identify when a change has occurred in the database which could mean an adjustment to pay is needed. E.g. There will be dynamic triggers to detect changes in Grade, Spinal Point, Standard Hours, Contract Type, FTE, Allowances etc. The “Retrospective Notifications” process uses these triggers to notify you of the items which need retrospective calculation.
How the calculation process works - Assume a retropay run is for March and April with the adjustments to be paid in May. The system retrieves all balances for the assignment as at end of February payroll and notionally recalculates all eligible elements for March and April. These notional element results are compared by the system with the original actual results in March and April for the same elements. Any differences are automatically entered onto the relevant retropay element in May. The end result will be exactly the same as if a payroll clerk had manually calculated the adjustments needed and manually keyed them onto adjustment elements in the current pay period.
Optimising use of the Retropay functionality - It can be seen that as the exact same system process is used to recalculate as was used in the original payroll calculation, then elements which have derived values will automatically be correctly recalculated by the retropay process.
e.g.
Allowance X has a formula attached which specifies that the allowance value is 10% of basic salary plus 2% of all contractual allowances. If basic salary and all contractual allowances are part of the retropay set then Allowance X will also be recalculated.
If the allowance has no formula and is populated by a user keying in an arbitrary amount then it will not be affected by retropay on other elements. The only way this would generate a retropay adjustment would be if the original allowance entry were changed, i.e. different start/end date or value.
During the implementation, due consideration should be given to how elements are configured to enable maximum use of the retropay functionality.
Pay Awards - When revising the values on a pay scale due to a pay award it will be essential to datetrack to the correct effective date when the new values come/came into force. You can apply the pay award in advance of the effective date or after it. If it is applied late then restrospective calculations will be due and the operational steps outlined above will need to be followed. If you have applied the pay award in advance then the old rates will be applied until the effective date of the pay award when the new rates will automatically be applied. If this occurs mid-period then the calculated values will be pro-rated accordingly.
Temporary Promotions, Secondments etc. - Any employee who is in a role which is not their usual substantive assignment will still be eligible for retropay adjustments on their substantive assignment for the period before their Temporary Promotion or Secondment started, and also on their extra assignment for the Promotion or Secondment.
Part Timers - It can be seen that as the exact same system process is used to recalculate as was used in the original payroll calculation, then elements which are pro-rated according to a part-timers FTE will still be pro-rated in exactly the same way.
Overlapping Retrospective Runs - It is possible that having run Retropay in June to recalculate March-May, you then have reason to run it in September for April-August. This is perfectly legitimate and the system will correctly process the second retropay run which overlaps the time period covered by the first run.
Sunday, April 6, 2008
Implementing Oracle GCS (Part 2)
Client and Business Case - Global Manufacturing client wanted to implement GCS in Oracle GL to enable consolidation within Oracle. The steps involved in configuring GCS are detailed in the following sections.
I. DEFINE SETS OF BOOKS (SOB):
1. Where all subsidiaries share a single SOB which consists of the same COA, accounting calendar, and currency, it is purely a reporting kind of consolidation requiring FSG tool. No separate consolidation SOB is required
2. Where each subsidiary and the parent company require their own SOB meet their operational or local accounting needs:-
2.1 If Parent SOB can be touched, then data transfer can take place to the Parent SOB.
2.2 Else, a separate consolidation SOB is required where data transfer has to take place.
3. Where companies use non-Oracle Applications, Create dummy SOBs within the GCS parent’s database instance. Each of these SOBs represent the subsidiary SOBs on disparate application instances. The consolidation can happen to Parent SOB or a separate consolidation SOB.
II. GATHER DATA FROM DISPARATE INSTANCES OR NON–ORACLE GL SYSTEMS:
GCS provides a convenient interface to import subsidiary data from any external source,
such as a separate database instance of Oracle GL, or an entirely separate non–Oracle
accounting system. There are two options available for gathering data from diverse sources:
1. Applications Desktop Integrator (ADI) to work in a spreadsheet environment. Simply transfer the subsidiary information from the external system into ADI’s journal worksheet. Then upload the entries to the GCS system where it can be posted.
2. SQL Loader to load data from diverse sources into the GCS open interface.
III. MAP SUBSIDIARIES TO PARENT:
To consolidate multiple SOB that have different functional currencies, accounting calendars,
or charts of accounts, first map subsidiaries’ COA to parent’s COA. A consolidation mapping is a set of instructions for mapping accounts or entire account segments from a subsidiary SOB to the parent SOB. When one subsequently transfers amounts from a subsidiary to parent, GL creates an unposted consolidation journal batch in parent SOB based on the subsidiary’s mapping information.
IV. PREPARE YOUR SUBSIDIARY DATA:
Prepare subsidiary data by revaluing and translating balances before transferring the balances to parent.
1. Revalue Balances - If any subsidiary SOB has balance sheet accounts that are denominated in a foreign currency, revalue the balances to reflect the impact of any changes in exchange rates. Post the resulting revaluation journal.
2. Translate Balances - If any subsidiary SOB uses a functional currency different from parent, translate the account balances into the parent SOBs’ functional currency before transferring the subsidiary data to parent.
3. Multiple Reporting Currencies (MRC) - If MRC is used, then consolidate directly from subsidiary’s reporting SOB to parent SOB. Revaluation needs to be run on the primary and reporting SOB before consolidation. The primary issue to consider when deciding whether to consolidate directly from a subsidiary’s reporting SOB is: What accounting rules govern the parent’s and subsidiary’s business environments?
V. TRANSFER DATA:
1. Transfer the balances or transactions to be consolidated from subsidiary SOB to parent.
2. GL accumulates subsidiary information based on the mapping rules defined, then populates the GL_INTERFACE table with the consolidation data.
3. Journal Import must be run, to create an unposted consolidation journal batch in parent SOB.
4. One can initiate a subsidiary–to–parent transfer from the subsidiary or from the parent SOB.
5. One can transfer balances (Actual / Budget) or transactions (Actual only).
VI. POST CONSOLIDATED DATA:
Once the subsidiary data has been transferred to parent SOB, one needs to combine the subsidiary and parent data. This involves several steps:
• Run Journal Import if it was not chosen as one of consolidation run options.
• Review the unposted journal batch created by the transfer and subsequent Journal Import.
• Post the consolidation journal in parent SOB.
VII. ELIMINATE BALANCES:
The Oracle GL Automatic Intercompany Eliminations program eliminates intercompany balances. Create an elimination set which is a batch of one or more elimination journal entries.
1. Full Eliminations: Elimination sets can optionally use an elimination company to fully eliminate a group of intercompany elimination entries for a set of subsidiaries.
2. If your elimination journals are out of balance, you can specify balancing options to either allow out of balance journals to be created or to post the net difference to an alternative account. In addition, threshold rules can be applied to prevent the creation of elimination journals if the net difference exceeds a specific amount, a percentage of a particular account, or a percentage of the total journal.
3. You generate the elimination set every period to automatically create the elimination journal entries. You have the option of automatically posting the journal or wait till you review it.
4. You can also use the Consolidation Workbench to track the elimination status of your elimination sets and post any generated elimination sets.
5. Formula–Based Eliminations: If you have formula–based elimination entries or you want to eliminate average balances, use Oracle GL’s recurring journals feature.
6. The Automatic Intercompany Eliminations program automatically generates eliminating entries per the rules specified.
VIII. REPORT:
Use the FSG as the mechanism to sum up the subsidiaries to produce consolidated results in case of Single SOB. In case of companies having multiple SOB / non-Oracle Application, use FSG to report on consolidated results. Use the ADI to extend reporting to the spreadsheet environment. ADI allows to create and publish consolidated reports in HTML format to the Internet or corporate intranet.
IX. ANALYZE:
1. Use full drilldown capabilities to drill from consolidated balances down to subsidiary journal lines and subledger detail. GCS enables to drill from consolidated balances in the parent SOB directly to the subsidiary SOB within the same instance. In case of companies having disparate applications, one cannot drilldown to the subledger detail.
2. Directly link data to Oracle Financial Analyzer, an online analytical processing (OLAP) application, to analyze consolidated balance and prepare operational and financial analyses for your management team. One can also drill between a subsidiary’s translated balance to its original balance. GCS also provides you with the ability to drill between summary accounts, detail accounts, and the original journal entries, down to The subledger detail.
Saturday, April 5, 2008
Posting Payroll Costs to General Ledger
The 5 places are :-
1. Payroll – Each active payroll must have segments setup for Costing and Suspense. This is normally maintained by technical Payroll Sysadmin staff.
Navigation = HR Responsibility >People> Enter and Maintain > Assignment > Salary Information > Entries:
6. Final Setup
There is one final setup step to map the CostAllocation Flexfield segments to the corresponding segments in the GL Chart of Accounts KFF.
There are two report processes available.
1. Cost Breakdown Report for Costing Run
2. Cost Breakdown Report for Date Range
These reports simply select a set of payroll calculation results according to run parameters and report on them.
There is one process for collecting Payroll costs.
3. Costing - This process collects a set of payroll calculation results, attributes them to the full GL analysis code and creates an output file in the correct format for posting to GL. The file can be viewed via the normal view process results function.
There is one process for transferring the costs.
4. Transfer to GL - This process takes the results file and moves it to a designated area on the file server from where it can be uploaded to GL under the control of an authorised GL user.
There is one process for retrospective costing adjustments.
5. RetroCosting Process - This process recalculates costs and compares the results with the original costing process results to identify and differences.
Understanding Mass Additions
Client and Business Case - One of my clients (Oil and Gas - Retail) who implemented Oracle Assets needed a simpler way to:
1. Convert Fixed Assets data from legacy system for Go-Live
2. Add new assets or cost adjustments from other (Oracle or Non Oracle) systems to the Oracle Assets system automatically without reentering the data
Mass Additions - The Mass Additions process lets you:
1. Load (convert) assets automatically from an external source. You can review new mass addition lines created from external sources before posting them to Oracle Assets. You can also delete unwanted mass addition lines to clean up the system.
2. You can also load (convert) asset data into Oracle Assets using the Create Assets Feature in the Applications Desktop Integrator (ADI), which allows you to import data from an Excel spreadsheet.
3. Maintian Assets data - The mass additions process lets you periodically add new assets or cost adjustments from other systems (like Oracle AP, Oracle Projects ) to your Asset system automatically without reentering the data.
Mass Additions Features:
1. Review Mass Additions - Clients can review newly created mass addition lines for entering additional mass addition source, descriptive, and depreciation information, assign the mass addition to one or more distributions, or change existing distributions. Once the mass addition is ready to become an asset, change the queue to POST. On Posting Mass to FA this mass addition becomes an asset. The Mass Additions post program defaults depreciation rules from the asset category, book, and date placed in service which can be overridden
2. Add to Existing Asset - Clients can add a mass addition line to an existing asset as a cost adjustment. Choose whether to change the category and description of the existing asset
to those of the mass addition and whether to amortize or expense the cost adjustment. When one changes the queue name to POST for a mass addition line which is being added to an existing asset, the queue name is changed to COST ADJUSTMENT. This makes it easy to differentiate between adding a new asset or adjusting an existing asset.
3. Merge Mass Additions - Clients can merge separate mass addition lines into a single mass addition line with a single cost. The mass addition line becomes a single asset when one
Posts Mass Additions. One can only merge mass additions in the NEW, ON HOLD, or user–defined hold queues. Choose whether to sum the number of units. When one posts the merged line, the asset cost is the total merged cost.
4. Split Mass Additions - Clients can split a mass addition line with multiple units into several single unit lines. The original line is put in the SPLIT queue as an audit trail of the split. The resulting split mass additions appear with one unit each, and with the same existing information from the source system. Each split child is now in the ON HOLD queue which can be reviewed to become a separate asset.
5. Post Mass Additions to FA - Use the Post Mass Additions to FA program to create assets from mass addition lines in the POST queue using the data entered in the Mass Additions window. It also adds mass additions in the COST ADJUSTMENT queue to existing assets.
6. Clean Up Mass Additions -The Delete Mass Additions program removes mass addition lines in the following queues:
• Mass additions in the SPLIT queue for which child mass addition lines created by the split has already been posted.
• Mass additions in the POSTED queue that have already become assets
• Mass additions in the DELETE queue.
7. Create Mass Additions from Invoice Distributions in Payables - Mass Additions adds assets and cost adjustments directly into FA from invoice information in Payables. The Create Mass Additions for Oracle Assets process sends valid invoice line distributions and associated discounts from Payables to an interface table in FA. One reviews them in and determines whether to create assets from the lines.
Pre-requisites steps for seemless Mass Additions Process:
1. Register the Accounts - Account Type Must Be Asset: Register the clearing accounts to be used as Asset accounts. The create mass additions process selects Payables invoice line distributions charged to clearing accounts with the type of Asset.
Define Valid Clearing Accounts in FA: For each asset category in FA for which invoice line distributions are to be imported from Payables, define valid asset clearing and construction–in–process clearing accounts. These accounts must be of type Asset. The create mass additions
process only imports lines charged to accounts that are already set up in asset categories.
2. Define Items with Asset Categories - Clients can define a default asset category for an item in Purchasing or Inventory. Then when one purchases and pays for one of these items using
Purchasing and Payables, the mass additions process defaults this asset category. If mass addition lines for an item are to appear in FA with an asset category, Cleints must:
• Define a default asset category for an item in the Item window in Purchasing or Inventory
• Create a purchase order for that item
• Receive the item in either Purchasing or Inventory
• Enter an invoice in Payables and match it to the outstanding purchase order
• Approve the invoice and Post the invoice to GL
After cleint runs create mass additions, the mass addition line appears with the asset category specified for the item.
3. Enter Invoices in Payables - While entering a new invoice in AP, charge the distribution to a clearing account that is already assigned to an asset category. The line amount can be either positive or negative.
4. Units - If one enters a PO with multiple units and match it completely to an invoice in payables, the Create Mass Additions process uses the number of units specified by the original PO for the mass addition line. Mass addition lines created from invoices entered directly into AP without matching to a PO default to one unit. After one approves and posts the invoice in AP, run the Create Mass Additions process to send valid invoice line distributions to FA.
5. Handle Returns: Clients can easily process and track returns using mass additions.
6. Conditions For Asset / Expensed Invoice Line Distributions To Be Imported - For the mass additions create process to import an invoice line distribution to FA, these specific conditions must be met:
• The line is charged to an account set up as an Asset account. (Expense in case of expense asset)
• The account is set up for an existing asset category as either the asset clearing account or the CIP clearing account
• The Track As Asset check box is checked. (It is automatically checked if the account is an Asset account)
• The invoice is approved and The invoice line distribution is posted to Oracle GL from AP
• The GL date on the invoice line distribution is on or before the date specified for the create program
• AP must be tied to the same GL SOB as the corporate book for which one want to create mass additions
7. Running the Create Mass Additions For FA Program in Payables - Clients can run Create Mass Additions for FA as many times as during a period. Each time it sends potential asset invoice line distributions to FA. AP ensures that it does not bring over the same line twice.
Thursday, April 3, 2008
Consolidation in Oracle GL (Part 1)
Client Profile - Global clients who want to implement Consolidation functionality within Oracle GL. Other consolidation methods include Financial Consolidation Hub (FCH) and use of Hyperion cubes to generate Consolidated reports.
Consolidation - is the period–end process of combining the financial results of separate subsidiaries with the parent company to form a single, combined statement of financial results. Clients can consolidate any number of subsidiaries that use different SOBs and having different COA, currencies and calendars.
GL Consolidation Tools - There are basically two consolidation tools which can be used for consolidation within Oracle GL.
1. Financials Statement Generator (FSG) - Used for consolidating financial information for businesses using a single SOB or using different SOB that share the same calendar and COA.
2. Global Consolidation System (GCS) - GCS is a multi-source consolidation solution that can accumulate information from diverse financial systems, geographic locations, including Oracle and non-Oracle Applications. With GCS one can consolidate data from multiple SOBs, multiple instances and non-Oracle applications.
What Can Be Consolidated? - With GCS, one can consolidate any business dimension at any level of detail from any point of view:
1. Any Source: Data from any source system, including ledger, databases, or other accounting systems can be consolidated
2. Any Chart of Accounts: Subsidiaries can use separate COA from the parent to address unique operational accounting practices and meet local statutory requirements. GCS enables you to consolidate across diverse charts of accounts.
3. Any Calendar: Subsidiaries can use different accounting calendars from the parent. GCS enables you to consolidate across calendars.
4. Any Currency: Subsidiaries can use a functional currency which differs from the functional currency of the parent. GCS revalues and translates all subsidiary balances to ensure consistent consolidated results.
5. Any Level of Detail: Consolidate detail transactions, detail balances and summary balances.
6. Any Balance Type: Consolidate any balance type; including actual, average, translated, budget, and statistical balances.
Implementation Considerations -
•Do all subsidiaries share the same SOB? If yes, then FSG can be used to meet the requirement.
•Do all subsidiaries have different SOB? If yes, then:
They share the same COA and calendar – Use FSG
They reside in the same instance – Use FSG
•Do all lines of business use GL as their operational accounting system?
•Is a separate consolidation SOB required to keep consolidation data separate from transactional data or can the companies be consolidated in the parent SOB?
•Is a separate elimination company required to segregate eliminations or can it happen in the parent company?
•Are companies to be consolidated at Balance level or Transaction level?
Other Uses of GCS:
1. Changing Chart of Accounts (COA) after implementation. GCS can be use to map values from old COA to new COA and balances from old SOB can be transferred to new set of books.
2. Changing the Accounting Calendar after implementation. GCS can be used to map and transfer account balances from the old period to the new period.
In my next article, I will explain in detail the various steps involved in setting up GCS in Oracle GL.
