project billing white paper

8/10/2019 Project Billing White Paper

1/7

Copyright 1998, G.R.Kinra, E.D.S. Corporation.

Customer Billing using Oracle Projects with Oracle Receivables

G. R. Kinra, C.P.A.Electronic Data Systems Corporation

Synopsis

This paper addresses Customer Billing for contractprojects, using Oracle Projects with OracleReceivables. It includes a review of the interfacebetween Oracle Projects and Oracle Receivables, adiscussion of the accounting treatment for revenueand receivable accounts, and relevant Oracle Projectsand Receivables setup options.

IntroductionOracle Receivables functionality includes the abilityto create customer invoices, receive payments againstoutstanding receivables, track and report on aging ofreceivables, and to record collections activityincluding customer calls and follow-up activities forunpaid invoices.

Oracle Projects extends this functionality byproviding a project management capability, includingthe ability to track the tasks required to complete aproject, and to accumulate charges for the resourcesused to perform these tasks.

In order to bill the charges for a project it is necessaryto complete certain setup requirements within OracleProjects and Receivables, and to subsequently followa carefully constructed sequence of operations totransfer a summary of the charges for a project fromOracle Projects into Oracle Receivables.

It is important to note that this transfer of costs andexpenditures from Oracle Projects to OracleReceivables can only be performed for contractprojects. In its native form, Oracle Projects does notsupport the creation of hybrid capital/contract

projects. Manual procedures must be developed inorder to capitalize a portion of the expenses for acapital project, and to bill certain other expensesfor the same project. Customizations and extensionsto Oracle Projects can also be developed to providethis functionality. These customizations are beyondthe scope of this paper.

Oracle Projects Invoice Flow

Before a contract project can be billed using OracleReceivables, the following sequence of operationsmust be completed within Oracle Projects:

Step-1: Create a contract project and identify

the customer for this project.

Create a task breakdown structure for the project.Identify the project manager for this project.Customer data is shared between Oracle Projects andReceivables. In order to bill a customer for a projectthe customer must have a Bill To address. It is alsodesirable to specify a contact for the Bill Toaddress, and to specify a Ship To address for theCustomer.

Step-2: Create a funding agreement with the

customer and fund the project.

If there is a previous funding agreement with thesame customer, it may be used to fund more than oneproject. It will be necessary to specify whether hardlimits will be imposed on the agreement for revenue

accrual and billing. If a hard limit is used it will notbe possible to accrue revenue or to bill past thefunded amount.

Step-3: Create an approved revenue budget for

the project.

The budget must be prepared at the same level atwhich the project has been funded. If the project hasbeen funded at the task level then the budget mustalso be prepared at this level. If the project has beenfunded at the project level, then the budget shouldnot reference any tasks, even though it may be

possible to do so.

Step-4: Submit, and baseline the budget

against the project funding.

Baselining the budget ensures that the revenue budgetequals the project funding.In certain situations, steps 1-4 may be automatedusing a special process called Quick


2/7


Agreement/Funding. For example, when there is afixed dollar amount for the funding agreement andrevenue budget, and when there is a single primarycustomer for the project.

Quick Agreement/Funding projects are created using

a project template that is linked to a templatecustomer. There is an agreement template for thiscustomer, and an Approved Revenue Budget whichhas been baselined against this agreement. When anactual project is created using the template project,the template customer is substituted for a realcustomer and funding agreements and baselinedrevenue budgets are created automatically.

Step-5: Review charges to be billed. Generate

revenue for expenditure items.

Review all billable tasks for the projects for whichinvoices need to be prepared, and the expendituresassociated with these project tasks. Each task has abillable field specification which can be used tocontrol the selection of billable charges.

Expenditures may be created automatically against aproject task when feeder systems (such as OracleMaterials, Oracle Payables etc.) input their chargesagainst specified project tasks within Oracle Projects.It is necessary to generate revenue for expenditureitems if the project uses a billing method that is basedon as work occurs. This may be performed byrunning the process PRC: Generate Draft Revenuefor a Single Project, or PRC: Generate DraftRevenue for a Range of Projects.

Step-6: Prepare a draft invoice for the project.

A draft invoice may be created by running the processPRC: Generate Draft Invoices for a Single Project,or PRC: Generate Draft Invoices for a Range ofProjects.

When running the process PRC: Generate DraftInvoices for a Range of Projects the projects that areselected are based on a set of pre-defined criteria.This may preclude generation of a draft invoice forprojects that do not meet these criteria. These criteriaare not employed when running the process PRC:Generate Draft Invoices for a Single Project

Step-7: Approve the draft invoice.

Projects that have been approved are frozen andmust be billed. An approved draft invoice cannot bechanged or deleted . It may be adjusted through thecreation of credit invoice transactions against it.

Canceling an approved invoice causes the creation ofa credit memo for the entire amount of the invoice.

Step-8: Release the draft invoice.

This makes the draft invoice eligible for interfacefrom Projects to Receivables.

Step-9: Transfer draft invoices from Oracle

Projects to Oracle Receivables

Extract the released draft invoices from OracleProjects using the process PRC: Interface Invoicesto Receivables. This creates an intermediateinterface file of the exported draft invoices that mustsubsequently be imported into Oracle Receivablesusing the Receivables AutoInvoice MasterProgram.

When an invoice is imported successfully into OracleReceivables it contains a transaction flexfield thatidentifies the project being billed.

Step-10: Tieback the transferred draft invoices

within Oracle Projects.

Tieback the transferred draft invoices within OracleProjects by running the process PRC: TiebackInvoices from Receivables This process marks thedraft invoices in Oracle Projects as being eitherrejected or accepted during the attempt to importthe invoices into Oracle Receivables. Data within theinterface file that has not been processed successfully

is removed.

Steps 9-10 may be combined by running the processPRC: Submit Interface Streamline Processes, withthe streamline option XI: Interface Draft Invoice toAR. This is the preferred approach for interfacingdraft invoices from Oracle Projects to Receivables.Although the Streamline process is rumored to beless error-prone than running the interface,AutoInvoice, and tieback processes separately, theredo not appear to be any documented instances wherethe results obtained using one approach differ fromthe other.

One benefit of the separate process approach is that itprovides more control in selecting the projects forwhich draft invoices are to be transferred from OracleProjects to Oracle Receivables. In contrast, theStreamline approach ports all draft invoices thathave been approved and released for processing,including any previously rejected draft invoices thatare still awaiting correction. These draft invoices will


3/7


simply make another iteration through the interfaceprocesses without any adverse impact.

Oracle Receivables Invoice Flow

Draft invoices that are imported successfully into

Oracle Receivables, will be placed into a completestatus by the AutoInvoice import program. Theseinvoices are ready for review, and for billing to thecustomer. Any changes to the generated invoicesrequire setting the invoice into an incompletestatus. It is now possible to make any changes thatare desired. These changes will not be reflectedwithin Oracle Projects, and this is not a recommendedpractice.

After a customer billing has been performed, thenormal flow will consist of applying the receipt ofpayments to outstanding invoices, tracking

uncollected invoices, and running the Receivablesinterface to General Ledger.

Receivables Invoice FlexField Data

Each Receivables invoice that has been importedfrom Oracle Projects includes information about theproject within certain invoice transaction flexfields,and this can be used as a cross-reference to theinformation within Oracle Projects. There is noautomated cross-reference between OracleReceivables and Oracle Projects.

If automatic invoice numbering is in effect, theinvoice number within Oracle Receivables will not bethe same as the draft invoice number within OracleProjects. The invoice reference field will containthe project number. In addition, each Receivablesinvoice contains a transaction flexfield that includesthe following information: Batch Source ContextValue (PA INVOICES), Project Number, DraftInvoice Number, Agreement Number, ProjectOrganization, and Project Manager.

In addition, each line item within the Receivablesinvoice will contain each of these fields within a line

transaction flexfield. If this information is not neededit can be suppressed from display by making thenecessary change and re-compiling the descriptiveflexfield. Do not disable or remove any one of theseflexfield segments from the invoice record itself.

Oracle Projects Draft Invoice Status

The status of a draft invoice within Oracle Projectsdetermines its eligibility for selection when runningthe PRC: Interface Invoices to Receivables.

Un-approvedAfter a draft invoice has been created it is initiallyplaced in an Un-approved status, and may be deletedif needed. A change to the dollar amounts of billingevents, followed by regeneration of the draft invoiceautomatically replaces the draft invoice with theupdated values.

Approved

Once a draft invoice has been approved it is frozenand cannot be changed or deleted. The billing eventsthat have been included in the preparation of this

draft invoice are tagged as billed. These eventscannot be altered, and will not be included if a newdraft invoice is requested for this project.

Released

A released draft invoice is eligible for transfer fromOracle Projects to Oracle Receivables.

Transferred

A draft invoice that has been placed within theintermediate interface file awaiting the import intoOracle Receivables is conferred the transferredstatus. Running the tieback process without runningAutoInvoice at this point will remove the draftinvoice from the interface file and place it in areleased status.

Rejected

A rejected draft invoice is one that has not beeninterfaced successfully into Oracle Receivables afterattempting to run the AutoInvoice process. It is stilltreated as an approved draft invoice based on itsearlier approval, and still cannot be changed, updated,or deleted.The Receivables AutoInvoice Master Programupdates the contents of the Interface tables, andAutoInvoice cannot be re-run without completelyrefreshing the data within the interface tables.If the Receivables AutoInvoice Master Programfails to import a draft invoice successfully into theReceivables system, it is essential to run the tiebackprocess, resolve the cause of the errors, and re-run the


4/7


5/7


Setup Requirements in Oracle Projects

and Oracle Receivables

Centralized vs. Decentralized Billing

The first decision that one faces in performing thesetup for billing within Oracle Projects is whether to

use centralized or decentralized billing.

Centralized billing refers to a situation where all theinvoices that are interfaced from Oracle Projects toOracle Receivables are to be imported with the pre-defined transaction type PA Invoice. To performcentralized billing the value of the InvoiceProcessing Organization Level in the system setupimplementation options for billing must be left blank.It may be necessary to directly edit the Oracledatabase tables in order to input a blank value intothis field. The presence of any value in this field otherthan a blank implies that decentralized billing is to be

performed.

Decentralized Billing provides a set of transactiontypes for invoices and credit memos for each invoiceprocessing organization within the organizationhierarchy. Each project within Oracle Projects isassociated with a project managing organization, thatis selected from one of the leaf level organizationswithin the organization hierarchy. A typicalorganization hierarchy is structured into a definedhierarchy of levels. With decentralized billing onemust specify the desired Invoice ProcessingOrganization Level in the system setup

implementation options for billing. When invoices areinterfaced from Oracle Projects to Receivables theyare imported with a transaction type that is set to theOrganization Name of the invoice processingorganization for the project. This organization is theparent organization at the invoice processingorganization level for the projects managingorganization.

Batch Source

The system setup implementation options for billingprovide a critical specification value for the Batch

Source that will be used to interface the desiredinvoices from Oracle Projects into OracleReceivables. The default value for the batch source isPA INVOICES. The definition of this batch sourceis provided within the seed data within the OracleReceivables transactions setup. The PA INVOICESdefault batch source identifies PA Invoice as theStandard Transaction Type.

A change to the default batch source of PAINVOICES is not permitted when using centralizedbilling. A change to the default value is stronglydiscouraged for decentralized billing since it involvesseveral related setup changes within Projects andReceivables, including the specifications of context

sensitive flexfield definitions for the ReceivablesInvoice Transaction, and the Invoice LineTransaction descriptive flexfields.

Automatic invoice numbering for PA INVOICESmay be turned off since invoice numbers are assignedfrom Project Billing.

The AutoInvoice options settings for PAINVOICES must specify the grouping rule PAGROUPING RULE which references the lineordering rule PA LINE ORDER. The grouping ruledetermines how Projects invoice lines are to be

grouped during the creation of a Receivables invoiceline. Line Ordering rules determine how to orderProjects invoice lines when applying a grouping rule.Do not change the grouping and line ordering settingsfrom the values provided by Oracle.

AutoAccounting:

The AutoAccounting setup for Oracle Projects iscritical to the implementation since it determineswhich accounting codes are used to charge revenue,receivable, and the un-billed receivable accounts.AutoAccounting comprises the creation of rules forthe assignment of segment values within the Chart ofAccounts (COA) structure, and the subsequentassignment of these rules to the segments within theCOA structure. The AutoAccounting treatment inOracle Projects overrides the specifications in OracleReceivables for all transactions that originate inOracle Projects and are interfaced into OracleReceivables.

The simplest type of AutoAccounting rule specifies aconstant value, that can be assigned to a segment inthe COA structure.

Look-up sets can be established to map the value of aselected project field to a desired value for a selectedsegment within the COA structure. For example, ifone of the segments within the COA structure islocation, then it may be possible to map the projectmanaging organization value to a desired locationcode. This mapping may be referenced in a rule, andthe rule may be assigned to the AutoAccountingtreatment for a selected segment in the COAstructure.


6/7


Among the most robust rule specifications are thosethat determine the value to be assigned to a segmentin the COA structure based on an SQL statement. Forexample, this type of rule could be used to set thevalue for a segment in the COA structure based on thevalue of a given flexfield for the project.

Create Invoice Organization Transaction Types

within Oracle Receivables.

If decentralized billing is to be used, it will benecessary to run the process IMP: Create InvoiceOrganization Transaction Types from OracleProjects to create transaction types within OracleReceivables for each invoice organization within theorganization hierarchy. Before running this processplease ensure that a standard transaction type hasbeen defined for the Receivables Batch Sourceidentified in the Project Billing Setup SystemImplementation Options.

The Receivables Batch Source PA INVOICES hasa Standard Transaction Type of PA Invoice. TheProject Billing system setup should identify PAINVOICES as the Invoice Batch Source andspecify a desired Start Organization and InvoiceProcessing Level. Running the job IMP: CreateInvoice Organization Transaction Types fromOracle Projects will create an invoice and a creditmemo transaction type within Oracle Receivables foreach organization at the specified invoice processinglevel within the Organization Hierarchy, up to andincluding the Start Organization.

The output from the job provides a summary ofupdate statistics and a typical Oracle job completionmessage. Examine the counts in the report and ensurethat the expected number of updates were performed.It is probably a good idea to sign on to OracleReceivables and query the system to determine if theexpected transaction types have been created.

AutoAccounting specifications for the transactiontypes created will be based on the AutoAccountingspecifications for the Standard Transaction Typefor the Batch Source. However, the AutoAccountingfor all Receivables invoices that originate fromOracle Projects is determined by the AutoAccountingsetup in Oracle Projects, not the AutoAccounting set-up in Oracle Receivables.

Budget Control

In order to permit the creation of a revenue budget fora project, the budget control for the project type

must permit the creation of a revenue budget withinthe Oracle Projects setup. This specificationdesignates a budget entry method such as Budgetby Project for the selected project type.

Lessons Learned:The following points highlight some key areas withinOracle Receivables and Oracle Projects. Theseobservations are based on experience using the GUIversion of these products during a big-bangimplementation project of the Oracle Financials andMaterials applications suite.

Setting up the organization hierarchy for theimplementation, establishing the invoice processingorganization, and creating organization transactiontypes within Oracle Receivables requires a substantialinvestment of time and energy during the

implementation. Use the Project Billing DEMOdatabase provided by Oracle as an immediate testarea to review the implications of making certainsetup selections.

All AutoAccounting values for Revenue andInvoice accounts should be defined beforeattempting to push a draft invoice from OracleProjects to Oracle Receivables.

It will not be possible to use QuickAgreement/Funding for invoices related to damageclaims, if the customer to be invoiced is not known at

the time when a contract project must be created.

There is no interface going from Oracle

Receivables back to Oracle Projects. It is not possibleto determine which projects have been paid basedsolely on the information within Oracle Projects. It isnecessary to refer to Oracle Receivables for allinformation pertaining to payment of outstandinginvoices.

Oracle Projects is not a financial application,

and the product makes no provision to track thecharges that are being accumulated within OracleProjects based on G/L account number. If it isnecessary to use the information in Projects as asubsidiary ledger for the General Ledger, thenbalancing requirements between the General Ledgerand Oracle Projects may require customizations andextensions to Oracle Projects.


7/7


Credit memos that are created directly in OracleReceivables for Oracle Projects invoices will not bereflected within Oracle Projects.

Customization of Oracle Projects and/orReceivables using descriptive flexfields implies that

any reporting requirements against the customflexfields will need to be processed using customreports.

In order to meet customer billing requirements, it

may be necessary to customize the standard landscapeformat invoice generated by Oracle Receivables,replacing it with a more traditional portrait format.If the project start date or project description must beprinted on the invoice, then this information may beobtained by accessing the project for a given invoiceusing the information in the interface header attributefields for the invoice.

Performance using the GUI client-server versionof Oracle Projects and Receivables leaves a little tobe desired. Load times of forms such as theReceivables Transactions form consistently exceeded10-15 seconds. Access to data varies, and dependson the information being retrieved. It is probably notwise to make routine requests for information usingnon-indexed retrievals.

About the Author

Mr. G. R. Kinra, C.P.A is an Enterprise SystemsConsultant within the Oracle Practice at ElectronicData Systems Corporation, with expertise in theimplementation of three-tier client-server applicationsystems.

project billing white paper

Documents