Implementing iExpenses for a Global Professional Services Firm (Part 2)

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.

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.

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.

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.

Happy Tamil New Year - My blog registered at blogs.oracle.com

Happy Tamil New Year everyone !

Very happy to note that my blog has been registered at blogs.oracle.com.

Please keep visiting and any feedback is much appreciated.

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.