Fd document

Functional Design Document
(FDD)
Subject
Date
INSERT COMPANY LOGO

REV 20 MAY 2013 Page i
DOCUMENT CONTROL
Document Version History
Date Author Version Change Reference
Document Owner
Name Department Email Contact #
281.
Document Purpose
Purpose User Community
The purpose of this document is to map all business
requirements to a functional design within Oracle. This
document is used to provide a systematic approach to the
automation of <project name)
Finance, Project Accounting, Developers,
Administration
Document Abbreviations
Abbreviation Description
AP Oracle Accounts Payable
AR Oracle Accounts Receivable
BPCC Blueprint Correspondence Course
BR Business Requirement
BRD Business Requirement Document
<APPLICATION> <APPLICATION>
BU Business Unit
CC Cost Center
DBA Database Administrator
FD Functional Design
FMV Fair Market Value
<DEPARTMENT NAME>
FX Foreign Exchange rate
GL Oracle General Ledger

Functional Design Document (FDD) __ Subject or Topic added here
REV 26 FEB 2013 Page ii
Abbreviation Description
HLR High Level Requirements
HR Oracle Human Resources
I/C Intercompany
ILT Instructor Led Training
<DEPARTMENT NAME>
N Navigation path within Oracle
OTL Oracle Time and Labor
OU Operating Unit
PA Oracle Project Accounting or Oracle Projects
SIT Special Information Type
TDD Technical Design Document
VOD Video on Demand
XCHG Abbreviation for the word cross charge. Refers to Cross Charge billing projects
created per operating unit to bill charges to another organization.
WBT Web Based Training
Key Stakeholders
Name Department/Group

REV 26 FEB 2013 Page iii
Table of Contents
DOCUMENT CONTROL........................................................................................................................ I
FUNCTIONAL DESIGN .........................................................................................................................4
1.1 <NAME> ACCOUNTING ........................................................................................................................6
1.2 LIST OF <DEPARTMENT NAME>S ..........................................................................................................7
1.3 PROJECTS SETUP PRE-IMPORT...............................................................................................................7
1.3.1. <Task Name> Task Setup...................................................................................................... 7
1.3.2. Transaction Source Setup...................................................................................................... 12
1.3.3. Expenditure Types Setup....................................................................................................... 14
1.3.4. <APPLICATION> Data Files Setup/Import......................................................................... 15
1.3.5. Proposed Design................................................................................................................... 32
1.4 INTERCOMPANY BILLING - BILLING BETWEEN DIFFERENT OPERATING UNITS ...............................................34
1.4.1. Autoaccounting Setup............................................................................................................ 35
1.4.2. Intercompany Setup............................................................................................................... 36
1.4.4. Proposed Design – Provider Operating Unit........................................................................ 37
1.4.5. Proposed Design – Receiver Operating Unit........................................................................ 45
1.5 INTRACOMPANY BILLING - BILLING WITHIN THE SAME OPERATING UNIT......................................................47
1.5.1. Autoaccounting Setup............................................................................................................ 48
1.5.2. Implementation Options Setup .............................................................................................. 51
1.5.3. Intracompany Setup .............................................................................................................. 52
1.5.4. Proposed Design................................................................................................................... 53
1.6 REPORTING......................................................................................................................................57
DOCUMENTATION QUESTIONS.........................................................................................................59
USER SIGN OFF.................................................................................................................................60

Page 4 of 61
FUNCTIONAL DESIGN
<Company Name> provides internal training for <COMPANY NAME> employees* who belong to
various organizations. <COMPANY NAME> uses the product <App Name>as their Talent Management
System. <APPLICATION> lists course offerings and track’s employee attendance records among many
other features. Currently the record of each employee’s training is provided to the <DEPARTMENT
NAME> each month. The <DEPARTMENT NAME> manually imports intercompany or intracompany
transactions via an ADI upload into Oracle GL. The tuition of the class is charged to the attendee’s cost
center, the Receiver Organization. A journal entry is also made to account for revenue to the
<Company Name>, which is the Provider Organization, for the training classes they provide. The goal
of this project is to automate intercompany and intracompany charges using Oracle’s standard cross
charge functionality. All tuition cost amounts are in USD.
Oracle Projects provides cross charge functionality to address internal billing within or across operating
units. Cross charges consist of transactions where the expenditure organization and project/task owing
organizations are different. <COMPANY NAME> currently uses Project’s intercompany billing
functionality where the expenditure organization and project owning organization are not in the same
operating unit. This method bills work performed by the provider operating unit to the project owned
by a receiver operating unit. The provider operating unit creates an Intercompany Receivables invoice,
which is then interfaced to Payables as an AP invoice in the receiver operating unit. Each <Department
Name> is a Provider organization while the trainee’s cost center is the Receiver organization. For cross
charges within an operating unit, intracompany billing will be setup in Projects using Borrowed and Lent
processing
This document outlines the <DEPARTMENT NAME> Cross Charge Billing process and addresses the
following functionality for the fair market value pricing model. This model assumes that the price of
tuition is based on what the cost would be in an open marketplace. This model includes only course
types of “Name”. The remaining course types ”Name” and ”Name” are part of the subscription based
pricing model, not included in this design. <APPLICATION> billing files transferred to PA will exclude
these course types.
 Intercompany Billing - Billing between different operating units.
o Creates internal AP/AR invoices and accounting entries to pass costs and share revenue
across organizations.
 Intracompany Billing - Billing within the same operating unit.
o Borrowed and Lent accounting creates accounting entries to pass costs and revenue
across organization without generating AP and AR invoices
 Adjustments - Processing of adjustment records to correct erroneous <APPLICATION> data
successfully transferred to Projects during a prior import. In addition a condition like the
following, which is not a correction to an erroneous record, may also be included in the file:
o A <Location> employee may take a temporary assignment in Korea and complete
training during this time. The Korean cost center should be charged for the tuition since
he took the class while assigned to the Korea location. This will need to be handled with
the submission of an adjustment because this business rule is not accounted for in
<APPLICATION>. Charges will go to the business unit and cost center of the employee at
the time of billing.
o Adjustments may include a reversal (negative amount) for the original transaction that
has been interfaced to Projects plus a new record to correctly account for the training

Page 5 of 61
transaction. However, it can also include only a reversal to undo a transaction that
should never have interfaced to Projects.
o Adjustments do not need to match a prior transaction. Adjustments without a prior
match will not contain values in column ‘ID’.
Setups - This document will only address new setups related to intercompany and intracompany billing.
The follow items are out of scope:
 External training is training taken by an employee from an organization outside of <COMPANY
NAME>. These transactions will not be included in the <APPLICATION> files.
∆ Note:
*Employees or contractors may attend training.
Signifies cross referenced text in the documentation is to follow. Hover over the underlined link while pressing the Ctrl
button to be taken to detailed information referenced elsewhere in this document.

Page 6 of 61
1.1 <NAME> ACCOUNTING
The following entries were provided by <Name> to detail the accounting that should be generated
within Projects for cross charge transactions.
Recording of I/C Revenue by a <Department Name>
DEBIT: <GL Account>
I/C Balance Sheet Account that corresponds to client (employee’s division)
CREDIT: <GL Account>
I/C Revenue Account that corresponds to client (employee’s division)
Example: <Location> <Department Name> provides training to an employee from <Location> Port
DEBIT: <GL Account>
Example: <Name> <Department Name> provides training to an employee from <Location>
DEBIT: <GL Account>
Recording of I/C Training Expense by Attending Employee’s Cost Center
DEBIT: <GL Account>
I/C Training Expense account* that corresponds to the providing <Department Name>’s division
I/C Balance Sheet Acct that corresponds to providing <Department Name>’s division
Example: Employee from <Location> received training from <Location> <Department Name>
DEBIT: <GL Account>
Example: Employee from <Location> Port received training from <Name> <Department Name>
DEBIT: <GL Account>
*I/C Training Expense Accounts
<GL Account> <Location>

Page 7 of 61
1.2 LIST OF <DEPARTMENT NAME>S
The following table lists all <Department Name> names included in this project.
<Department Name> Listing
<Department Name> Name Business Unit/Cost Center Oracle Responsibility Name
<Department Name> <GL Account> <Responsibility Name>
1.3 PROJECTS SETUP PRE-IMPORT
The following sections list configurations that must be completed prior to importing <APPLICATION>
data into Projects.
1.3.1. <TASK NAME> TASK SETUP
A receiving project and task must be defined to import training tuition into Projects. Each Cost Center
has a cost center project which will be used to record these charges. Required setups for allowing cross
charges to be billed to these cost center projects must be completed, including adding a new task “Task
Name” to record Learning tuition. Additional setup includes adding the Non-Labor Bill Rate Schedule
‘<NAME>’ to the project as well as adding a new task “Task Name”.
To automate the creation of these tasks, design a new program(s) based on “<COMPANY NAME>:
Program Name” to add the <Task Name> task to every cost center project. This program will also
enable cross charging for Non-Labor expenditures by populating the non-labor flag in the Cross Charge
Options section of the project. The Non-labor Bill Rate Schedule named “<NAME>” will also be added
at the project level and on the new task. The existing program currently creates a task “Task Name” on
receiver projects. These tasks are used for cross charging setup purposes. The program sets the value
for the Intercompany Tax Receiving field to <Task Name>. Some of the department admin (cost center)
projects already have a valid value in this field (<Task Name> have been used).
The program name should be <COMPANY NAME>: Program Name
∆ Note: If valid values already exists on a cost center project, they should not be updated by the
program.

Page 8 of 61
<COMPANY NAME>: <Program Name> Parameters
 Receiving Operating Unit (optional)
 Projects/Templates (required) – Projects or Templates (∆ Note: This program will be run
once to update projects and can be run again to update templates)
1. Concurrent Programs - In System Administrator, create the new concurrent program.
N>System Administrator>Concurrent>Program>Define
Request Groups - Add the program(s) created above to the request group assigned to the
<COMPANY NAME> <Responsibility Name) responsibility. The program should only need to be run
once. Templates for department admin projects (Template Name) should be updated as well. If the
cost center project already has the other cross charge setups include a value set for the
Intercompany Tax Receiving Task field, then the program should only (a) add the <Task Name> Task
(b) set the cross charge flags and (3) add the bill rate schedule.
∆ Note: The program should not update projects that are already prepared to receive intercompany
billing if the program is run a second time.
2. Verify Results
Navigate to the tasks form on each receiver project to view the <Task Name> task. Settings from
the cross charge properties defined at the project level should have defaulted to the task.

Page 9 of 61
3. Next verify that the task <Task Name> has also been added.
Click the blue box next to the task to open the Task Options form and select Cross Charge. Settings
from the cross charge properties defined at the project level should have defaulted to the task.

Page 10 of 61
4. Navigate to the Cross Charge project options. The program should have inserted the task named
‘<Task Name>’ into the Intercompany Tax Receiving Task field only if the Intercompany Tax
Receiving Task value did not already exist. Some projects already have this value set to the <Task
Name> task.

Page 11 of 61
The program is successful if all the department admin (cost center) projects and templates have the
correct values:
 New <Task Name> task
a. Allow Charges from other Operating Units is checked
b. Non-Labor transfer price schedule is <NAME>
 Non-labor cross charge processing settings:
a. Allow Charges from other Operating Units is checked
b. Non-Labor transfer price schedule is set to <NAME>
c. Intercompany Tax Receiving Task field is populated with a valid task, preferably
named <Task Name>, but if one already exists it should not be overwritten

Page 12 of 61
1.3.2. TRANSACTION SOURCE SETUP
Transaction sources identify the source of external transactions imported into Projects. In addition, the
transaction source controls how Transaction Import processes these transactions.
The transactions being created are not true costs, but a mechanism for attributing revenue to the
<Department Name>, therefore enabling the ‘Raw Cost GL Accounted’ setting prevents these
transactions from being re-costed and accounted by Projects. However, cross charge accounting entries
generated from these transactions in Projects will be transferred to GL. Revenue will be posted to each
<Department Name> concurrently with costs posted to each employee’s Cost Center. Setup will be
completed by <Department Name> – <ORACLE>/Projects.
N>Responsibility Name>Setup>Expenditures>Transaction
The transaction source will be added to the following form.
Data for all values must be entered by dragging the bottom form bar to the right.

Page 13 of 61
The following table identifies values for all columns in the Transaction Source form.
Transaction Source Form
Column Name Column Value
Transaction Source <Enter Value>
Default Expenditure Type Class <Enter Value>
Raw Cost GL Accounted <Enter Value>
Import Raw Cost Amounts <Enter Value>
Import Burdened Amounts <Enter Value>
Import MRC Amounts <Enter Value>
Allow Duplicate Reference <Enter Value>
Import Employee Organization <Enter Value>
Allow Interface Modifications <Enter Value>
Purge After Import <Enter Value>
Allow Reversals <Enter Value>
Allow Adjustments <Enter Value>
Process Cross Charge <Enter Value>
Pre Processing Extension <Enter Value>
Post Processing Extension <Enter Value>
Processing Set Size <Enter Value>
Effective Date From <Enter Value>
Effective Date To <Enter Value>
Description <Enter Value>

Page 14 of 61
1.3.3. EXPENDITURE TYPES SETUP
Expenditure types classify the cost assigned to each expenditure item. Expenditure types have been
created to identify the cost to attend internal training provided by <COMPANY NAME> <Name> or
<COMPANY NAME>. Other expenditure types per division are listed below.
The expenditure type must be derived based on the <Department Name> that conducts the training. If
training was completed by <Name>, the expenditure type name will be <Account Number> <COMPANY
NAME> <Task>. If training was completed by the <Location> <Department Name>, the expenditure
type name will be <Account Number> <DEPARTMENT NAME> - AME
The expenditure type class is set to Miscellaneous Transaction and Supplier Invoices for these
expenditure types. Setup will be completed by <Department Name> – <ORACLE>/Projects.
<Responsiblity Name>>Setup>Expenditures>Expenditure Types
List of Expenditure Types (one for each division) - This setup is already in Production.
Expenditure Type Name Description
Effective
From
Date
[ ]
Associated Oracle
<Department Name> Name
<Expenditure Name>
<COMPANY NAME>
TUITION
1-Jan-00 <Department Name>
<Expenditure Name>
<Department Name>
Tuition –
<Expenditure Name>
<Department Name>
Tuition – Greater
<Location>
1-Jan-13
<Department Name>
<Expenditure Name>
<Department Name>
Tuition – <Location>
1-Jan-13
<Department Name>
<Department Name>
<Expenditure Name>
<Department Name>
Tuition –
<Department Name>

Page 15 of 61
1.3.4. <APPLICATION> DATA FILES SETUP/IMPORT
Oracle Projects can only generate intercompany and intracompany accounting entries for transactions
that have been recorded in Projects. Since <APPLICATION> transactions are first recorded in
<APPLICATION>, the transactions must be interfaced to Projects to be processed as cross charge
transactions. The transactions will not be sent to GL from Projects as they are not actual expenses but
rather transactions used to record tuition costs.
The following configuration outlines some of the architectural requirements necessary to import
<APPLICATION> files into Projects.
1. File Naming Convention
The following data provides the naming convention for each <APPLICATION> file.
a. Completions for <Enter Name>:
<Naming Convention>
b. Completions for <Enter Name>only (does not include <Name> transactions):
<Naming Convention>
c. Completions for <Enter Name>:
<Naming Convention>
d. Completions for <Enter Name>
<Naming Convention>
e. Completions for <Enter Name>:
<Naming Convention>

Page 16 of 61
f. <Enter Name>:
<Naming Convention>
g. Adjustments:
<Enter Name> This file is manually created and thus the file extension name is in
lowercase ‘csv’. The file extension is not being used by the custom Projects insert program for
processing files since all files except the adjustments file has the extension CSV in uppercase.
The uppercase designation is systematically created by <APPLICATION>. The file date is equal to
the date the <Employee Title> FTPs the file. The adjustment file does not contain X’s in the file
name since X’s are automatically system generated by <APPLICATION>.
∆ Note: Adjustment Transactions using Current Exchange Rates: Due to the number of
adjustments anticipated and the amounts involved in adjusting the current foreign exchange
rates for past period adjustment transactions, a decision has been made that the current FX rate
will be used since the amounts are immaterial. As a result, adjustments for past periods will use
the foreign exchange rate for the current period. The week ending date will be determined by
the sysdate of import.
∆ Note: Adjustment File Template and Entry: An adjustment template will be distributed for
data entry by the <Employee Title>. Records entered into the file should be manually cut and
paste from the original billing files that were submitted in previous billing cycles from the
Coordinators of other global locations. This helps to prevent any data import errors.
Since the adjustments file contains an ID column and “ID” is the first two characters of the file, it
is necessary to place one blank space in front of the “I” in “ID”. This helps to maintain the
formatting of the file and allow import into PA. Ensure that there is only one blank space before
the characters “ID” located in the first column of the adjustments file.
L = Used to identify all files as a file that records <Department Name> transactions.
File Name Dates and X’s = The date in the file names (excluding the adjustments file) is the
date that <App Name> puts on the file which will be the current Sunday that the file is
generated. All X’s represent a character generated by <APPLICATION>.
2. File Type
The files interfaced from <APPLICATION> will be of type CSV. Setup is performed by the
<Department Name>.

Page 17 of 61
3. <APPLICATION> File Location and Transfer
Data Location/Transfer (Setup is performed by the <Employee Title>)
 <APPLICATION> non-encrypted Billing Reports are scheduled to run at 10PM.
 <APPLICATION> will copy files to the following <APPLICATION> FTP location:
ftp://ftp1.<Application>.com/Reports/Billing/. The files take about 4 minutes total to generate.
The <APPLICATION> files would only include the data for the previous week which includes the
prior Sunday up to the most recent Saturday that occurs before Sunday at 10:30pM CST.
 A cron job will run weekly at 10:30PM CST every Sunday) to initiate a file transfer from
<APPLICATION> FTP to the <COMPANY NAME> <ORACLE> Database Server Inbound folder. The
path is / /<DEPARTMENT NAME>_int_bill/inbound. The <APPLICATION> files are also
transferred to a backup folder and the following FMV folder
(shares<Location>grouplocal<Oracle>extractFMV ). <Employee Title>s, Project
Accountants and <DEPARTMENT NAME> users have access to view the read-only
<APPLICATION> files. <COMPANY NAME> uses secure file transfer protocol to transfer files
between applications. During the transfer a log file is generated by the database server
containing a record of successful or failed transfers.
o The custom program in PA (<COMPANY NAME>: <Program Name>), scheduled to run on
Mondays at 5AM,will transfer the <APPLICATION> data from the <COMPANY NAME>
<ORACLE> Database Server Inbound folder to the PA_Transaction_Interface_All table.
o Next the scheduled PA program PRC: Transaction Import (Mondays 6AM) transfers
<APPLICATION> data from the interface table to the PA expenditures tables.
<APPLICATION
> Billing
Reports
Created on
Sun 10PM
Reports Copied
to
<APPLICATION>
FTP by Sun
10:05PM
Reports Copied
to <ORACLE>
Inbound folder
on Sun 10:30PM
Reports
Copied to
Backup Folder
Reports
Copied to
FMV Folder
PA Program
Copies Data to
Interface Table
on Mon 5AM
PA Transaction
Import Runs on
Mon 6AM

Page 18 of 61
4. File Handling Notification Email
A notification will be sent to the <Employee Title> and to the <Employee Title>s (<COMPANY NAME
email address) to inform them of the files that were transferred from <APPLICATION> to the
<ORACLE> Inbound folder. The following is an example email.
From: Oracle Alert - [<Company Name><Oracle>@<Company Name>ibmp1.<Company
Name>.com]
To: <COMPANY Email>
Subject: Enter here
The following FMV billing files have been extracted and successfully transferred from
<Application> (Live)
<File Name>
<File Name>
<File Name>
<File Name>
<File Name>
5. Purging Data/Data Retention
According to the <DEPARTMENT NAME> Retention Policy, all <APPLICATION> files must be saved
for a period of 7 years before they are purged. An automated job will run to delete all files older
than 7 years from the <COMPANY NAME> <ORACLE> Database Server and the <ORACLE> extract
folder at the appropriate time. This activity is performed by the <Department Name>.
6. <APPLICATION> Data File Mapping
The same predefined column information will be included in each <APPLICATION> data file. Seven
<APPLICATION> data files will be imported into PA as miscellaneous transactions.
Completions (File 1-5 of 7):
o ENTER DESCRIPTIONS HERE
Penalties (File 6 of 7):
Adjustments (File 7 of 7): .
7. <APPLICATION> Data File Mapping for PA_Transaction_Interface_All table. The table below maps
the columns in the <APPLICATION> file to the columns in the interface table.
<APPLICATION> Data Mapping Table
Source: PA Transaction
Interface All Table
Source:
<APPLICATION>
Data Files
PA_Transaction_ Interface_All Table
Column Name Column Name Column Values
TRANSACTION_SOURCE Not Defined The new transaction source “<COMPANY
NAME> <Subject>” will be used by the
custom program ( 1.3.2)
BATCH_NAME Not Defined The batch name will be derived by the
custom program. The batch name should use

Page 19 of 61
Interface All Table
Source:
<APPLICATION>
Data Files
the same name of the <APPLICATION> file
that was used to populate the interface table.
the resulting batch name should be as follows
for an ILT completion file: <File name>
EXPENDITURE_ENDING_DATE Not Defined This date should be derived as the week
ending Sunday based on the transaction’s
import date. Previously the transcript
completion date was used but this change
was made to minimize currency exchange
rate differences.
The Transcript Completion Date will be null in
Penalty files because the training was not
completed. It may also be blank in the
Adjustments file if the Adjustments file
includes a reversal of a penalty transaction.
The transcription completion date will be set
to the import date. The expenditure ending
date will be the dame as discussed above.
EMPLOYEE_NUMBER User ID The attendee’s user id in each
<APPLICATION> file is the employee’s actual
Oracle HR employee number and will be
imported into the Employee Number column.
ORGANIZATION_NAME ILT Facility Parent It is assumed that only one organization
should be derived for the BU/CC combination
in the ILT Facility Parent column. If more
than one organization is found by the custom
program, the program should default the
Organization_Name to <Name> <Department
Name>. However, this transaction should
appear on the exceptions report to notify
users that the organization_name was set to
<Name>.
The Providing organization is to be derived
from the 3rd and 4th segments of the ILT
Facility Parent <COMPANY NAME>-GRE-
<Account> -P where <Account> is the
business unit and <Account> is the cost
center. Find the organization and the costing
operating unit with the value for the costing
business unit and cost center that matches
these two segments. If unfound, use the
costing operating unit of the organization to
handle Department LTD scenarios. This issue
occurs when the Billing OU <> Costing Op
Unit. Transaction should be accounted for in
the Costing OU.
The Organization_Name is derived from the
cost center name of the <Department

Page 20 of 61
Interface All Table
Source:
<APPLICATION>
Data Files
Name> that performs the training. This
means the organization name in the Oracle
HR organization table that will be associated
with the Business Unit (BU) and Cost Center
(CC) values listed in the ILT Facility Parent
column of the <APPLICATION> files with the
exception of the <Name> <Department
Name>, in either of the following formats:
<COMPANY NAME>-<Number> or
<COMPANY NAME>-HOU-<Number> -P. The
P is generated by <App Name> and can be
ignored.
Currently, the <APPLICATION> files do not
populate the <Name> <Department Name>
name in the ILT facility Parent column. As a
result, derive the value <Department Name>
when the training type equals ‘Material’,
‘Online Class’ ‘Curriculum’ or ‘Video’.
∆ Note: It is possible that the value in the ILT
Facility Parent column may be “Department
Name”. This is due to a user selecting the
incorrect parent facility in <APPLICATION>.
As a result, if the program encounters this
incorrect value, set to <Name> <Department
Name> and show this transaction on an
exceptions report.
EXPENDITURE_ITEM_DATE n/a This value will be set to the import date.
For penalty files the Transcript Completion
Date will be null. Set the date equal to the
import date.
The adjustment files may include a reversal of
a record that was in the penalties file. As a
result, the record will not have a transcript
completion date. Set the date equal to the
import date.
PROJECT_NUMBER Cost Center Ref The cost center that an employee belongs to
is identified in the Cost Center Ref column.
This GL number can then be used to derive
the cost center project name which always
begins with the cost center number.
∆ Note: Some cost centers have more than
one cost center project which is made unique
by appending a business unit to the cost
center. Use the employee’s business unit to
determine the project number if more than
one cost center project exists. Ignore closed

Page 21 of 61
Interface All Table
Source:
<APPLICATION>
Data Files
cost center projects.
For example the following two projects exist
for cost center <Name> Human Resources:
<Account>. By using the Cost Center Ref
value for the employee, the BU that the
employee belongs to can be determined.
Project <Account> belongs to business unit
<Account>. So if the employee belongs in BU
<Account>, set the project number to
<Account>.
TASK_NUMBER Not Defined Verify that the task ‘<Task Name>’ exists on
the cost center project. If not, an email alert
should be sent and the value DUMMY should
be the value placed in the interface table for
the blank task. It can then be fixed manually
when the project is corrected. The task
number will be derived by first identifying the
project_number above. The task_number on
the project will always begin with “<Task
Name>”.
EXPENDITURE_TYPE Not Defined To derive the expenditure type, select the
tuition expenditure type for the division of
the <Department Name> facility providing
the training. For example, if <Department
Name> is providing the training they are
under the <Department Name>, so the
expenditure type is the one associated with
the account code and the expenditure type
name <Department Name>: <Account>
<DEPARTMENT NAME>:
LIST DEPARTMENTS AND ACCOUNTS
∆ Note: There may be cases in the future
where several expenditure type names begin
with the same GL account code. As a result,
the full expenditure type name must be used
in deriving the expenditure type for the
<APPLICATION> transaction.
RAW_COST Training Price This is the tuition charged for the class.
∆ Note: Training can be given free in some
cases. As a result, the training price column
in the <APPLICATION> files will be $0. The
custom program should ignore records with a
0 dollar training price.
EXPENDITURE_COMMENT
Transcript Completion
Date
User Full Name (Pull
last name only)
Training Title
The comment field should be derived from
the values in the Transcription Completion
Date, Employee Last Name, Training Title, and
Transcript Status columns. The comment
should begin with the Transcript Completion
date, followed by a ‘.’ and then the

Page 22 of 61
Interface All Table
Source:
<APPLICATION>
Data Files
Transcript Status Employee’s Last Name followed by a ‘.’. Next
add the abbreviated Training Title. Truncate
the training title after 40 characters, followed
by a ‘.’ and the Transcript Status.
ORG_ID ILT Facility Parent This column should be derived based on the
operating unit id of the <Department Name>
that performed the training
None Transaction Type
(Debit, Credit or
Penalty)
Ignore this column. Values will not be
imported into PA.
None Division Ignore this column. Values will not be
imported into PA.
None Training Start Date Ignore this column. Values will not be
imported into PA.
None Training End Date Ignore this column. Values will not be
imported into PA.
RAW_COST and Quantity Transaction
Withdrawal Charge
Ignore this column for ILT, Online Class,
Video, Material and Curriculum
<APPLICATION> files.
Quantity is a required field in the Project’s
interface table and is therefore defined
below.
For Penalty and Adjustment <APPLICATION>
files: If the Transcript Status column value
includes the word “Withdrawn” derive the
Raw Cost amount and the Quantity values
from the Transaction Withdrawal Charge
column in the <APPLICATION> files. ∆ Note
that any transaction status with the word
‘Withdrawn’’ should be included. For
example, if the Transcript Status value is
‘Withdrawn / Past Due’, set the Raw Cost and
Quantity values to the amount in the
Transaction Withdrawal Charge column.
RAW_COST and Quantity Transaction No Show
Charge
Ignore for ILT, Material, Online Class, Video
and Curriculum <APPLICATION> files.
Quantity is a required field in the Project’s
interface table and is therefore defined
below.
For Penalty and Adjustment <APPLICATION>
files: If the Transcript Status column includes
the words “No Show” derive the Raw Cost
amount and the Quantity values from the
Transaction No Show Charge column in the
<APPLICATION> files. ∆ Note that any
transaction status value with the word ‘No
Show’’ should be included. For example, if

Page 23 of 61
Interface All Table
Source:
<APPLICATION>
Data Files
the Transcript Status is ‘No Show / Past Due ’,
set the Raw Cost and Quantity values to the
amount in the Transaction No Show Charge
column.
∆ Note: Currently in <APPLICATION>
production there have not been any cases of
‘No Shows’ because a manager may send
another employee in place of the one who
was originally scheduled for the class.
However, the program code should
handle/expect this case for the future.
Employee_Name User Full Name The Employee_Name column will
automatically be populated by Projects based
on the value in the Employee_Number
column.
None Business Unit Ref This is the business unit that the employee
belongs to. Use this column to determine the
business unit/cost center project for the
employee. See the Cost Center Ref column
definition explained above.
Incurred_by_Organization_id ILT Facility Parent Derive the internal organization id for each
<Department Name> organization based on
the ILT Facility parent value.
Quantity Training Price This is a required field in the Project’s
interface table. Set the value equal to the
Training Price for the following files only: ILT,
Material, Online Class, Video and Curriculum.
For deriving the Quantity value from the
Penalty and Adjustment files, see the
following column definitions listed above:
Transaction Withdrawal Charge and
Transaction No Show Charge.
Orig_Transaction_Reference ID This is a required field in the Project’s
interface table to reference the unique value
of a transaction in its source system.
<APPLICATION> provides a unique ID for each
transaction in all files.
None ILT Facility Name Ignore this column. Values will not be
imported into PA.
None Training ID Ignore this column. Values will not be
imported into PA.
Column Values Required during PRC: Transaction Import. After data has been transferred to the
PA_Transaction_Interface_All All table, it must be imported into Projects by each Provider
Organization using PRC: Transaction Import. Oracle Projects Users Guide: For each valid
transaction, Transaction Import imports the transactions and creates corresponding expenditure
records in the Oracle Projects expenditure tables; expenditure records include expenditure
batches, expenditures, and expenditure items. Use the following table to derive the values for the
required expenditure table columns so that the import program can complete successfully. The
following fields must be defined and inserted into the interface table for Transaction Import to run

Page 24 of 61
Interface All Table
Source:
<APPLICATION>
Data Files
successfully. All tuition cost amounts are in USD. However, the fields in the
PA_Transaction_Interface_All table must be populated such that the transaction currency is USD
though the functional currency is not. The conversion date will be the system date when the trans
actions are imported.
Acct_Raw_Cost Training Price ln_raw_cost * conversion rate --
ROUND(ln_calc_cost,2),
Acct_Rate_Type N/A Set to ‘Department Name’
Denom_Currency_Code N/A Set to ‘USD’
Acct_Raw_Cost Training Price ln_raw_cost * conversion rate --
ROUND(ln_calc_cost,2)
Denom_Raw_Cost Training Price ln_raw_cost: Training price from the file (In
USD),
Acct_Rate_Date N/A Sysdate
Acct_Exchange_Rounding_Limit N/A 2
Acct_Exchange_Rate N/A ln_calc_cost_rate – Conversion rate.
Dr_Code_Combination_Id ILT Facility Parent Obtain the code combination ID from the
GL_Code_Combinations table for the
following combination for each
<APPLICATION> record.
Segment1 = Business Unit of Provider
Organization
Segment2 = '000000'
Segment3 = [Natural Account]*
Segment4 = '000'
Segment5 = '0000'
*Account provided by Finance department.
Cr_Code_Combination_Id ILT Facility Parent Obtain the code combination ID from the
GL_Code_Combinations table for the
following combination for each
<APPLICATION> record
Segment1 = Business Unit of Provider
Organization
Segment2 = '000000'
Segment3 = [Natural Account]*
Segment4 = '000'
Segment5 = '0000'
*Account provided by Finance department.
GL_Date n/a The date should be equal to the import date.
8. Custom Interface Program(s) <COMPANY NAME>: <Program Name>
Create a custom program(s) to run across all operating units. The program(s) will retrieve the
<APPLICATION> records from the FTP server, validate the data and then insert into the
PA_TRANSACTION_INTERFACE_ALL table. Subsequently, each Provider Operating Unit must import
the files from the interface table into the PA expenditures tables.

Page 25 of 61
a. Program Requirements
 Expenditure Type Class: Each <APPLICATION> transaction will import into PA as a
miscellaneous non-labor transaction.
 Custom Program Schedule: The program will be scheduled to run weekly on Sundays at
1:30AM CST (Time is subject to change).
 Duplicates: The custom program will not check for duplicates. It is assumed that the
records sent from <APPLICATION> are correct. If errors exist, the <Department Name>
must send an adjustments file to PA. The program will not match negative transactions.
Credit Memo’s may also be created to resolve duplicates or errors.
b. File Failure: If the program fails to process a transaction or places dummy values in the interface
table, a notification should be sent to the <ORACLE> <Department Name> email address <Enter
Email>. If all files successfully transfer, this email should not be sent.
Expenditure Exception Email – An email will be sent if DUMMY values are inserted into the PA
interface table detailing the error and identifying the transaction. Transactions should be
viewed in the Review Transactions form. However, it does not pull all the <APPLICATION>
records in error. Modify the <COMPANY NAME>: Reset Transaction Import Records program by
adding a new parameter ‘Transaction Source’. This will allow the Transaction Source of
“<COMPANY NAME> <Subject>” to be selected. Once the program is run all the <APPLICATION>
will return when the form is accessed.
Dummy Values - A dummy value may be put into the interface table when valid values
cannot be determined by the program. Set the corresponding field value that erred to
the word “Dummy”. A user can then correct the value in the custom Review
Transactions ( 10) form after fixing whatever configuration problem exists.
Cost Center Dummy Value - The cost center number of the employee’s organization
should always be listed in the <APPLICATION> file and should be inserted into the
interface table as the project number. If this cost center number is not a valid project
number, the custom program should check for another project number with the same
prefix followed by the business unit of the cost center.
o For example, check to see if cost center <Account> is valid. If not, try cost
center number <Account>. If neither cost center number is valid, still insert the
Cost Center Ref value from the <APPLICATION> file into the project number field
of the interface table. The transactions should still be placed on an exception
report. If there is no cost center assigned to the employee in HR and thus the
cost center of the employee cannot be determined, then the custom program
should set the project number to DUMMY.
Task Number Dummy Value - The task number should always be set to “<Task Name>”
in the interface table. If the task does not actually exist on the cost center project, add
this transaction to the exception report listing the project number. Additionally, if the
cost center project does not exist, the program should still insert “<Task Name>” as the
task number and list the transaction on the exception report.
c. Notification Email Alert – Data File Rejections
This email alert should be sent under the following conditions:
If there are no <APPLICATION> files found.

Page 26 of 61
If a file is corrupt and cannot be processed by the custom Projects program.
If the file extension is not csv.
The email alert should only be fired after it checks whether files exist in the <ORACLE>
database folder.
∆ Note: Some files may contain no data such as the Video file. At the time of this
documentation no video billing transactions exist in <APPLICATION>. The file will still be
generated but the column data will be blank. As a result, the custom program will not import
any data into Projects for this file.
Email Alert Format – Billing File Rejections
Name>.com]
To: <email address>
Subject: <COMPANY NAME> <subject>
The following are a list of <APPLICATION> file rejections:
File Name Error Message
-------------- -------------------------------------------------------------
d. Notification Email Alert – Expenditure Exceptions
This email alert should be sent under the following conditions:
If the custom insert program could not derive a value for a record and placed the word
DUMMY in one or more fields in the interface table.
A listed value in a <APPLICATION> file is invalid such as a non-numerical value in the
Cost Center ref column.
The email alert should only be fired after it checks whether the program <COMPANY
NAME>: <Program Name> has completed successfully.
Email Alert Format
Name>.com]
To: <email address>
Subject: <COMPANY NAME> In<subject>
A file will be sent with an attached Excel email. The body of the email will be blank due to the
limitations of the alert program. The Excel file will contain data for the following columns.
File Name ID* Batch Name** Rcv CC Num Employee Name Operating Unit Error Message
------------ ---- ---------------- ---------------- --------------------- ------------------ -------------------
Provider Organization Name Provider Operating Unit Name Receiver Operating Unit Name
------------------------------------- ---------------------------------------- ----------------------------------------
*ID is the first column in all <APPLICATION> files.
** Batch Name can be found in the Review Transactions form

Page 27 of 61
e. Notification Email Alert – Expenditure Exceptions Error Messages
The following table provides an explanation of each error message from the Expenditures
Exception email above. The value Dummy will be placed in the custom Oracle Project’s Review
Transactions form if applicable.
Excel File Expenditure Exception Notification
Error Message Error Meaning
Error in deriving Employee Org Name The employee's organization name could not be
derived based on the value in the user ID column in
of the <APPLICATION> file
Error in deriving Provider Organization/
Prov Org is set to "<Name> <Department
Name>" as Org details cannot be found for
ILT Facility Parent
Failed to derive provider organization name.
Employee operating Unit is different from
projects operating unit/No valid project
When the employee operating unit and project
operating unit are not the same, the project number
will be inserted and appended with "-D". D =
Dummy. The project does not exist; as a result,
insert the employee's cost center appended with "-
D".
Error in deriving Expenditure Ending Date Failed to derive expenditure ending date.
Error in deriving Employee Details for the
Employee: <Employee Number>
Could not find employees organization/operating
unit.
Project does not exist - Inserted CC value
from file to interface table
Could not find the valid cost center project.
Task # set to “<Task Name>” though no task
# was found
The <Task Name> task does not exist for the project
or no project exists.

Page 28 of 61
Excel File Expenditure Exception Notification
Cross Charge Proj with type "XCHG" does
not exist in the provider org
The Cross charge project with project type “XCHG”
does not exist in the Provider Operating Unit for the
Receiver Operating Unit of the expenditure being
created.
Error in deriving expenditure type Failed to derive expenditure type. The Expenditure
type is derived using the division of the provider
organization. If the program is unable to derive the
provider organization or division details, this
exception occurs.
CCID not found for: <BU>-000000-
ACCOUNT-000-0000 combination
Failed to derive the code combination id for the
columns Dr_Code_Combination_Id. May fail if the
BU is not valid.
Failed to insert data to Interface Table If for any other reason a record failed to insert into
pa_transaction_interface_all table. This error
message will be appended with Oracle's standard
error information for the failure to insert in to the
interface table.
f. Data Validations
The program should validate the following:
 The corresponding indirect cost center project with project type “<Name>” exists and is
open in each Receiver Operating Unit, for each tuition expenditure created.
 <Task Name> tasks and <Task Name> tasks exist on the Cost Center receiver projects.
 The expenditure type derived is active.
 A contract cross charge project with project type “XCHG” exists in each Provider Operating
Unit for the Provider Operating Unit of the expenditure being created. A notification should
be sent to the <ORACLE> <Dept> email address (email) if the correct cross charge project
does not exist.
 All organizations and GL accounts are active.
The program does not have to validate the following:
 Employees are active
g. Data Validations – Invalid Transactions
 The <Department> allows test data to be entered into <ORACLE> Production for certain
business reasons. As a result, the insert program should ignore any of the following values
and not transfer this data to the PA_TRANSACTION_INTERFACE_ALL table.
<APPLICATION> Column Name: User Full Name
First name = Test
Last name = Placeholder
Or the following User Full Name’s

Page 29 of 61
<APPLICATION> Column Name: Division
Division = <COMPANY NAME> Admins
<APPLICATION> Column Name: User ID
User ID = <Number>
<APPLICATION> Column Name: ILT Facility Parent
<Department Name>
If the ILT Facility Parent value in a <APPLICATION> file is “<Department Name>”, (which
is an incorrect value selected by a user) the program should replace this value in the
interface table with “<Name> <Department Name>” and this transaction should appear
on the exception report.”
Lastly, it is assumed that only one organization should be derived for the BU/CC
combination in the ILT Facility Parent column of a <APPLICATION> file. If more than one
organization is found by the custom program, the program should default the
Organization_Name column of the interface table to <Name> <Department Name>.
However, this transaction should appear on the exceptions report to notify users that
the organization name was set to <Name>.
∆ Note:
The completions and penalties files will always contain positive values for the following columns
where applicable: Training Price, Transaction Withdrawal Charge and Transaction No Show
Charge. The adjustments file may contain both positive and negative values for the following
columns where applicable: Training Price, Transaction Withdrawal Charge and Transaction No
Show Charge.
h. Output Report
The insert program should produce an output file listing the following with each record that
has an exception:
<APPLICATION> File Name
Provider Organization Name
Provider Operating Unit Name
Receiving Cost Center Number
Receiving Operating Unit Name

Page 30 of 61
Employee Number
Employee Organization Name
Tuition Amount
Expenditure Item Date
Training Title
Exception error description
Total Counts of records inserted into PA_Transaction_Interface_All from each batch
processed. Identify Total Count of records in error.
9. Project’s Standard Review Transactions form
Navigate to this form to correct records that are in err in the interface table.

Page 31 of 61
10. Project’s Standard Review Transactions form - <COMPANY NAME> Review Transactions
This custom form can be used to correct transactions that erred when inserted into the
PA_TRANSACTIONS_INTERFACE_ALL table.
Enter the transaction source “<COMPANY NAME> <Subject>” and select the Transaction Status of
your choice and press the Find button to return erred transactions. Transactions can be fixed in this
form and then reimported by pressing the Import button.
11. Interface Program Setup
Create the <COMPANY NAME>: <Program Name> program in the Concurrent Programs form. Setup
will be completed by the <Employee Title>. N>System Administration>Concurrent>Program>Define
12. Request Groups - Add the <COMPANY NAME>: <Program Name> program to the request group
assigned to the <COMPANY NAME> <esponsibility>. Setup will be completed by the <Employee
Title>. N>System Administrator>Security>Responsibility>Define
13. <APPLICATION> Adjustments
Each adjustment file may contain a negative record that reverses a previous entry in Projects. The
file may also include a new positive record to correctly account for the entry that was reversed with
a negative. However, for some special billing cases that cannot be captured in <APPLICATION> and
the completions file, the <Department Name> will only include a positive record in the adjustments
file.

Page 32 of 61
1.3.5. PROPOSED DESIGN
The following instructions outline the process to interface <APPLICATION> data into Projects.
1. Log into <COMPANY NAME> Global Projects responsibility to run the custom interface program,
<COMPANY NAME>: <Program Name>. If errors occur, fix and rerun program.
N><COMPANY NAME> <responsibility?>Other>Requests>Run

Page 33 of 61
2. Transaction Import - Project Accountants must login to the Project’s responsibility of the Provider
organization and run Transaction Import. The program will transfer <APPLICATION> transactions
from the PA_Transaction_Interface_All table to the PA_Expenditures_All tables. This program will
run daily or according to each <DEPARTMENT NAME>’s schedule. All transactions will import into
PA as costed and therefore do not need to be distributed. If errors occur, correct and rerun
program. Some adjustments may also be done in the Batch Entry forms.
N>Other> Requests >Run
Transaction Source: <COMPANY NAME> Inte<Name>
Batch Name: Automatically system generated
--------------------Process Ends--------------------

Page 34 of 61
1.4 INTERCOMPANY BILLING - BILLING BETWEEN DIFFERENT OPERATING UNITS
Future Process
Cross charge transactions between different operating units and legal entities are defined as intercompany transactions in Oracle Projects. AP and
AR invoices are generated to account for costs and revenue between the Provider and Receiver Organizations. The <Department Name> that
provides training is known as the Provider Organization in PA. The cost center of the employee that signed up for training is known as the Receiver
Organization.

Page 35 of 61
1.4.1. AUTOACCOUNTING SETUP
The following Autoaccounting Setup must be completed per operating unit to generate intercompany
revenue accounting entries. Setup will be completed by <Department Name> – <ORACLE>/Projects.
N><Responsiblity Name>>Setup>AutoAccounting>Assign Rules

Page 36 of 61
1.4.2. INTERCOMPANY SETUP
The following setup is required to generate AP and AR invoices and should already be setup per operating
unit. Setup will be completed by <Department Name> – <ORACLE>/Projects.
 Provider/Receiver Controls
 Transfer Price Rules
 Transfer Price Schedules
 Cost Center Project for each Receiving Operating Unit (Indirect Project)
 Cross Charge Billing (XCHG) Project for each Providing Operating Unit (Contract Project)
 Agreement
 Revenue Budget
For instructions on how to setup the functionality above, see the Cross Charge Setups document below.
<Attach file here>

Page 37 of 61
1.4.4. PROPOSED DESIGN – PROVIDER OPERATING UNIT
The following design will describe the process of generating AR invoices for each <Department Name>. It
will be followed by instructions on how to view AP invoices in the operating unit of each Cost Center.
1. The transactions that have been imported into PA ( 2) can be viewed in Expenditure Inquiry.
N><Responsiblity Name>>Expenditures>Expenditure Inquiry> All
Verify that the Transcript Completion Date, Employee Last Name, Training Title and Transcript Status
are correct in the Comment field.

Page 38 of 61
Verify that the Employee/Supplier and Employee Number columns are populated.
Verify that the autoaccounting is correct.
2. Next identify the cross charge billing project in the Provider Operating Unit to generate an
intercompany billing invoice. This program will be scheduled to run automatically. Run PRC: Generate
Intercompany Invoices for a Single Project. N><Responsiblity Name>>Other>Requests>Run
3. Verify report output results. If exceptions exist, correct and then rerun the generate intercompany
invoice program.
4. Review the draft invoice that has been generated in the Invoices Review form.
N><Responsiblity Name>>Billing>Invoice Review
In the Find Invoices form, enter the draft invoice number from the output of the PRC: Generate
Intercompany Invoices program.

Page 39 of 61
Review the invoice and its details.

Page 40 of 61
5. Approve and save invoice.
6. Release Invoice and save.

Page 41 of 61
The invoice will be released and the AR invoice number will be generated.
∆ Note: An AP invoice will be generated after the invoice is interfaced to AR and tied back to PA. In
addition, the AP status field will also be updated at this time.

Page 42 of 61
7. Interface the invoice to AR.
8. Verify report output results. If exceptions exist, correct and then rerun the streamline program. This
program will be scheduled to run automatically.
The following programs are initiated during the stream line process.
Report Output (In sequence):
 PRC: Interface Intercompany Invoices to Receivables
 Autoinvoice Import Program
 PRC: Tieback Invoices from Receivables
 Prepayment Matching Program
9. Return to the Invoice Review form to see the updated AP Status field. The AP invoice that has been
generated in the receiving operating unit will have the same number as the AR invoice imported into
AR.

Page 43 of 61
10. Login to AR to view invoice.
N>AR Manager>Transactions

Page 44 of 61
11. A user can return to Expenditure Inquiry to verify that the accounting is correct on the transaction.
--------------------Process Ends--------------------

Page 45 of 61
1.4.5. PROPOSED DESIGN – RECEIVER OPERATING UNIT
Each Provider Operating Unit must import the Payables Invoice that was generated during the tieback
between AR and PA in the Provider Operating Unit.
Payables Open Interface Import
1. This program may be scheduled to run automatically by operating unit.
N> AP CSUP>Other>Requests>Run.
2. Verify results. If exceptions exist, correct and then rerun the import program.

Page 46 of 61
3. The invoice number will be the same as the AR invoice number generated in the provider organization
( 6). Query the invoice. N>AP Manager>Invoices>Entry>Invoices.
--------------------Process Ends--------------------

Page 47 of 61
1.5 INTRACOMPANY BILLING - BILLING WITHIN THE SAME OPERATING UNIT
Future Process
Cross charge transactions within the same operating unit will be processed through Project’s Borrowed and Lent functionality. Borrowed and Lent
processing creates accounting entries to pass costs and share revenue between the provider and receiver organizations within a legal entity. The
<Department Name> that provides training is known as the Provider Organization in PA. The organization of the employee that signed up for training is
known as the Receiver Organization.

Page 48 of 61
1.5.1. AUTOACCOUNTING SETUP
Setup AutoAccounting Rules to generate the correct accounting entries for borrowed and lent transactions.
Setup will be completed by <Department Name> – <ORACLE>/Projects.
N><Responsiblity Name>>Setup>AutoAccounting>Assign Rules
1. Setup the Borrowed And Lent Debit Account for Miscellaneous Transactions.

Page 49 of 61
2. Setup the Borrowed And Lent Credit Account for Miscellaneous Transactions.

Page 50 of 61

Page 51 of 61
1.5.2. IMPLEMENTATION OPTIONS SETUP
To enable borrowed and lent accounting within an operating unit, enable the Processing Method Borrowed
and Lent in the Cross Charge tab of the Implementation Options form. Setup will be completed by
<Department Name> – <ORACLE>/Projects.
N><Responsiblity Name>>Setup>Systems>Implementation Options>Cross Charge

Page 52 of 61
1.5.3. INTRACOMPANY SETUP
The following cross charge setups is required per operating unit to generate borrowed and lent
transactions. Setup will be completed by <Department Name> – <ORACLE>/Projects.
 Transfer Price Rules
 Transfer Price Schedules
 Cost Center Project for each Receiving Operating Unit (Indirect Project)
 Agreement
 Revenue Budget
For instructions on how to setup the functionality above, see the Cross Charge Setups document.
<add file here?
Receiver Controls
In addition to the setup required above, Receiver Controls must also be defined for intracompany
accounting. Each <Department Name> operating unit must be defined in the Receiver Controls section to
charge cost centers within the same operating unit.
N><Responsiblity Name>>Setup>Costing>Provider and Receiver Controls.

Page 53 of 61
1.5.4. PROPOSED DESIGN
The following design will instruct users in how to generate borrowed and lent transactions within Projects.
Since the Provider OU and the Receiver OU are the same, all transactions can be viewed in the same
operating unit.
Expenditure Inquiry
1. Transactions can be viewed in Expenditure Inquiry once they have been imported into AP ( 2). Use
folder ‘Folder’ to view Cross Charge columns. ∆ Note that the transactions remain unprocessed until
borrowed and lent amounts are distributed. N><Responsiblity Name>>Expenditures>Expenditure
Inquiry> All

Page 54 of 61
Verify that the Transcript Completion Date, Employee Last Name, Training Title and
Transcript Status are correct in the Comment field.
Verify that the Employee/Supplier and Employee Number columns are populated.
2. Distribute Borrowed and Lent transactions and interface to GL. This process may be setup to run
automatically. N>Other>Requests>Run>PRC: Submit Interface Streamline Processes: DXC: Distribute
and Interface Borrowed and Lent Amounts to GL

Page 55 of 61
3. Run the following programs in the order listed below.
 PRC: Distribute Borrowed and Lent Amounts Set the ‘Process Through Date’ parameters to
the correct week ending date of the transactions.
 PRC: Borrowed and Lent Amounts Distribution Report
 PRC: Interface Cross Charge Distributions to General Ledger
 Journal Import
 PRC: Tieback Cross Charge Distributions from General Ledger.
View all output files for exceptions and correct any transactions that are in error. Next, reimport the
transactions into GL.

Page 56 of 61
4. You may return to Projects to verify that all transactions have been fully processed. N><Responsiblity
Name>>Expenditure Inquiry>Expenditures>All
--------------------Process Ends--------------------

Page 57 of 61
1.6 REPORTING
1. <COMPANY NAME>: <Report Name>- Create a new Report for the <Department Name>s to be able
to review their revenue/billing from Intercompany and Intracompany transactions. This report
should be included in the following Oracle responsibilities per Operating Unit: <Responsiblity Name>,
<Responsiblity Name>, and <Responsiblity Name>.
Parameters
Hierarchy (Default to Reporting Hierarchy)
Starting Organization
Starting GL Date
Ending GL Date (Default to Starting GL Date)
(GL Date of AR Invoice Number or Borrowed/Lent transaction)
Detail Required – Yes/No
Detail Columns
Receiving Project Number
Receiving Project Organization
AR Invoice Number or “Borrowed/Lent” designation
Status - If AR Invoice Number, exists display status as in the <COMPANY NAME>: <Report Name>
Total transfer price by Receiving Project Organization for expenditures with source <COMPANY
NAME>: <Subject>
Summary Columns
Receiving Project Number
Receiving Project Organization
Total of transfer price by Receiving Project Organization for expenditures with source <COMPANY
NAME>: <subject>
2. <COMPANY NAME>: <Report Name> – Can be used to identify Intercompany transactions that have
not been processed. ∆ Note: This report is already in production. No programming required. This
report should be included in the following Oracle responsibilities per Operating Unit: <Responsiblity
Name>, <Responsiblity Name>, and <Responsiblity Name>.
3. Concurrent Programs - In System Administration, create a concurrent program for the report. Setup
will be completed by the <Employee Title>. N>Concurrent>Program>Define

Page 58 of 61
4. Request Groups - Add the programs created above to the request groups assigned to Project
Superuser responsibilities. The program will then be available to run in the associated responsibility.
Setup will be completed by the <Employee Title>.
N>System Administrator>Security>Responsibility>Define
--------------------Process Ends--------------------

Page 59 of 61
DOCUMENTATION QUESTIONS
# Question Response Person Assigned to
Question/Comments
Determine how the class name
will be abbreviated to fit into
the Expenditure Comment field.
1
2
3
4
5
6
7
8
9
10
11
12
13

Page 60 of 61
USER SIGN OFF
1. Executive Sponsor Date
2. Business Project Owner Date
3. Project Management Office Date
4. Business Process Owner I Date
5. Business Process Owner II Date
6. Business Process Owner III Date

Fd document

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Fd document

Similar to Fd document (20)

Recently uploaded

Recently uploaded (20)

Fd document