Download as doc, pdf, or txt
Download as doc, pdf, or txt
You are on page 1of 18

AIM

MD.50 APPLICATION EXTENSIONS


FUNCTIONAL DESIGN
Elecon EPC

Budgetary Controls for Project


Author:

Mukesh Kumar

Creation Date:

December 2, 2015

Last Updated:
Document Ref:

MD050

Version:

Draft 1a

Approvals:
Role
Change Leader

Name
Vivek Gupta

Signature

Preface
This document was designed to document Oracle Application Extentions
created for Elecon EPC, using the AIM methodologies. This document is
provided to track and document the entire extention process.

Intended Audience

Document Control
Change Record

Date

Author

Versio
n

Change Reference

Reviewers

Name

Tollgate

Position

Distribution

Copy
No.

Name

Location

1
1
1
1

Library Master

Project Library

Contents

Preface........................................................................................................ 2
Intended Audience.................................................................................2
Document Control.......................................................................................3
Functional Design Approval.........................................................................1
Functional Topical Essay..............................................................................2
Scope..................................................................................................... 2
Assumptions.......................................................................................... 2
Basic Business Needs............................................................................3
Functional Details........................................................................................ 4
Setups and Requirements......................................................................4
Detailed Solution description:................................................................4
User Procedures.......................................................................................... 8
Program Navigation...............................................................................8
Running/Scheduling...............................................................................8
User Test Plan........................................................................................ 8
Technical Overview......................................................................................9
Approach............................................................................................... 9
Module Design.......................................................................................9
Assumptions.......................................................................................... 9
Table and View Usage............................................................................9
Program Logic (pseudo code)................................................................9
Concurrent Program Parameters............................................................9
Test Plans.................................................................................................. 10
Unit Test Plan.......................................................................................10
Integration Test Considerations...........................................................10
SIT Test Considerations........................................................................10
Implementation Notes...............................................................................11
Design.................................................................................................11
Build.................................................................................................... 11
Testing.................................................................................................11
Open and Closed Issues............................................................................12
Open Issues.........................................................................................12
Closed Issues.......................................................................................12

Functional Design Approval


Approvals:
xxxxx
xxxxxxxxxxxxxxx

Classification: Elecon EPC Confidential

Functional Topical Essay


Elecon EPC engaged in Manufacturing and installation of raw materials
handlingeqipments,Elecon EPC has Operations across India with one operating unit,
Elecon EPC lately implemented Oralce Applications 12.1.1.3.Oracle Applications
Project accounting is used to create projects and manage the costing and billing
activites of all projects
This requirement of budgetary control in projects is coming up due to following reasons
Oracle Projects do not have the following features when it comes to applying budgetary
controls for following cases
There are no budgetary controls when a purchase order is defined with a destination type
of
Inventory
There are no budgetary checks during item movements across projects in PJM
Looking at this it is important that we deliver a proper / working custom solution for budgetary
controls.

Scope

The Scope is limited to development of the custom solution for


following purposes:

A.) Budgetary Control at PR, PO level - Users should not be


allowed to enter a PR ,PO if the approved cost budget is
exhausted for the expenditure type for a particular awarded
project

B.) When there is a transfer of raw material (inventory item)


from common project to the awarded project, the program
should check if the awarded projects task has enough budget
on it.

Assumptions
The proposed solution is based on the following assumptions:

Classification: Elecon EPC Confidential

Basic Business Needs

Requirement#

Description

Budgetary
controls for
Projects
Expenditure

Every project has a cost budget. Its important that various costs which are
incured for a projects are always funds checked aginst a cost budget that is
defined.

Classification: Elecon EPC Confidential

Functional Details
Setups and Requirements
The Pre- requisite for this interface is to have a Cost budget at Task level in oracle
projects.

Detailed Solution description:


A.) Budgetary Control at PR, PO level - Users should not be allowed to enter a
PR ,PO if the approved cost budget is exhausted for the expenditure type for a
particular awarded project.
Detailed below is how the custom component will work that will prevent POs that are raised
with a project and task reference from being submitted for approval if it is not within the
defined cost budget.
This funds check component will prevent the users from proceeding with the transaction.
The users will have to change the budget and on approval of the same they will be able to
submit the PO for approval.
Purchase order creation

For all project related procurement activity, users will be entering projects details
on all PO transactions (PO distribution level)
Projects Deatils consists of following components
Project name
Task
The PO/ blanket release cost that will be considered for funds check should
include non- recoverable taxes (compared against landed cost defined in the
budget for that task)
The projects budget is defined against expenditure Type, Project and task. If time
phased cost budget is available, then budgetary checks should ensure that based
on the expenditure item date given, necessary checks are fired
For ex. If budget for Jan is 100 and Feb is 200, in Jan a PO for only 100 can be
issued even if project level budget is 300. Also note that if no purchases are made
in Jan and Feb has purchases of 50, then in March user can procure up to 250 +
budget available for month of March
Available budget to be calculated using the following logic detailed below
Budgeted Cost [ (approved POs inclusive of non recoverable taxes) (unmatched
project invoices) (stock items issued to project)]

Few Checks :
The Budget type should be Approved budget type (version should be the
latest one)

Classification: Elecon EPC Confidential

Task Details:

Approved cost budget: You can navigate to this page by (N)budget -> enter the
project number and budget type -> approved cost budget Details.
(however I dont think you need to do all this , budgets are defined for all the task ).
The below screenshot with budget at each task needs to be refered to know the
budget limit on each task.

Classification: Elecon EPC Confidential

Now the action steps will be in Purchasing.


Fund check process:
Navigate PO -> purchase order- While raising a PO the program should check the cost on
the task and consider all the previous cost incurred on the TASK for calculation and
allow/restrict the PO approval as per the result(fund check pass/fail).

Classification: Elecon EPC Confidential

So we have to refer the Total amount on the PO as highlighted on PO form.and check the
cost budget allocated on the task and then do a fund check.

Detailed audit records will be created, which will enable proper auditing for the
approvals for each and every PO capturing the following details

Date on which the PO was submitted for approval


Available budget at the time of PO approval
PO value at the time PO approval
Budget (Latest Baselined Version) version from which the values were picked
up
Project & Task ID
Expenditure Item date / PO Creation Date

Calculation of Available budget


The available budget will be calculated by grouping the costs into various heads and
calculating the total cost
Cost
Type

Purchase Order
Approved POs
Closed POs
Closed for Receiving POs
Closed for Invoicing POs
Finally Closed POs
Releases from Blanket POs
that are
Approved Releases
Closed Releases
Closed for Receiving Releases
Closed for Invoicing Releases
Finally Closed Releases

Invoice
All Unmatched and
Validated Invoices.
Exclude Prepayments,
Credit
Memo
and
Debit Memo.

PO/ Blanket Release amount


+ Non recoverable Taxes.
( Non recoverable taxes will
be identified on the basis Mod
VAT flag, if checked it is
recoverable
else
non
recoverable, this check will be
done only if the Receiving
Inventory is excisble else all
taxes
applied
will
be
considered)
Error Message to be displayed on funds Check:
Funds check failure for Project <Project No> Task <Task No>. Available Budget is
<Avail. Budget> for period <Period Name>
B.) When there is a transfer of raw material (inventory item) from common project
to the awarded project, the program should check if the awarded projects
task has enough budget on it.

We are using the transfer to project transaction type to transfer the Inventory item from
Common project to Awarded project.

Classification: Elecon EPC Confidential

Detailed below is how the custom component will work that will prevent transfer of items
across projects if the receiving project (will be identified by Locator, Locator will have the
project and task number which has to be referred for checking the cost budget on each
Task) does not have sufficient funds to receive the item.
This funds check component will prevent the users from proceeding with the. The users will
have to change the budget and on approval of the same they will be able to proceed with
the transfer.
Material movement in store across projects and tasks
Scenario is explained in detail below.
There is an issuing project , usually a common project (P1) which has a budget
defined as 1000 on TASK 1.1
There is a receiver Project(P2) which has a budget defined as 500 on TASK 1.1
Item I1 of value 100 is purchased for Project P1 and is available in store for P1
There is a request to move this item to P2
As there is enough budget transaction should be allowed
After this transaction P1s available budget will be back to 1000 again and P2s
available budget will be 400
In case P2 doesnt have enough budget this MOVE transaction should not be
allowed
Available budget to be calculated using the following logic
Budgeted Cost [ (approved POs inclusive of non recoverable taxes) (unmatched
project invoices) (stock items issued to project)]

This check will happen for Items that are directly transferred to project and
task locators from stock sub inventory ( common raw materials ) at the WIP
component issue time.It has to check the DJ project and the TASK reference.
The TASK should have sufficient cost budget to allow the transaction.

Detailed audit records will be created, which will enable proper auditing for the
approvals for each and every PO capturing the following details
o
o

Date on which the material was transferred between projects


Available budget at the time of transfer

Classification: Elecon EPC Confidential

o
o
o

Item value at the time of transfer


Budget (Latest Baselined Version) version from which the values were
picked up
Project & Task ID

Calculation of Available budget


The available budget will be calculated by grouping the costs into various heads and
calculating the total cost

Cost
Type

Purchase Order
Approved POs
Closed POs
Closed for Receiving POs
Closed for Invoicing POs
Finally Closed POs
Releases from Blanket POs
that are
Approved Releases
Closed Releases
Closed for Receiving Releases
Closed for Invoicing Releases
Finally Closed Releases

Invoice
All Unmatched and
Validated Invoices.
Exclude Prepayments,
Credit
Memo
and
Debit Memo.

PO/ Blanket Release amount


+ Non recoverable Taxes
( Non recoverable taxes will
be identified on the basis Mod
VAT flag, if checked it is
recoverable
else
non
recoverable, this check will be
done only if the Receiving
Inventory is excisble else all
taxes
applied
will
be
considered)
Error Message to be displayed on funds Check:
Funds check failure for Project <Project No> Task <Task No>. Available Budget is
<Avail. Budget> for period <Period Name>

Classification: Elecon EPC Confidential

User Procedures
Program Navigation
NA

Running/Scheduling
First run:
Second run:
Third run:
Forth run:

User Test Plan


The tables below list various scenarios to complete unit testing
Use Case 1
Actors
Purpose
Precondition
Assumption
Create New projects in Oracle and tasks will be interfaced from primavera to Oracle
PA
Actor

Actor Action

System Response

Program Output and Status update when interface is success


Actor

Actor Action

System Response

Program Output and Status update when interface fails


Actor

Classification: Elecon EPC Confidential

Actor Action

System Response

Technical Overview
This document defines the technical components required to
implement customization of Elecon EPC Primavera P6 to Oracle
PA.

Approach
Module Design
NA.

Assumptions
The assumptions are listed below:

Table and View Usage

Program Logic (pseudo code)


Primavera to Projects:

Concurrent Program Parameters

Value Sets
NA

Classification: Elecon EPC Confidential

Output file path

Success file name

Error file name

Mail Subject

Test Plans

Unit Test Plan


Use Case 1
Actors
Purpose
Precondition
Assumption
Create New projects and Interface to Primavera
Actor

Actor Action

System Response

Program Output and Status update when interface is success


Actor
Functional
Team/
System/Fun
ctional
Team

Actor Action
Check the Interface Status update
Email Generation and Format

System Response
Check to see if the concurant program updates
status on DFFs as required
Email should be triggered to Distribution list
and Mail output should show succeeded
records in expected Format

Program Output and Status update when interface fails


Actor
System

Actor Action
Check the Interface Status update

System

Email Generation and Format

Integration Test Considerations

SIT Test Considerations

Classification: Elecon EPC Confidential

System Response
Check to see if the concurant program updates
status on DFFs as required
Email should be triggered to Distribution list
and Mail output should show errored records in
expected format

Implementation Notes
<>

Design
Functional Design
Functional Design Approval

Technical Design
Design Review

Final Acceptance

Build
Development was done on <description of hardware>, to work with
Release 12.1.3 of Oracle Applications. All coding follows the standards
defined in the Build Standards document for ETIL.
Program Files
The files required for this customization are as follows:
File

Description

Coded By

Testing
The customizations were tested in ETIL EleconEPC 's test environment
before being moved to production. See the Link Test scripts for more
information.

Classification: Elecon EPC Confidential

Open and Closed Issues


Open Issues

Issue

Closed Issues

Classification: Elecon EPC Confidential

Resolution

You might also like