Professional Documents
Culture Documents
MD50 - Elecon - Budgetary Control v1
MD50 - Elecon - Budgetary Control v1
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
Scope
Assumptions
The proposed solution is based on the following assumptions:
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.
Functional Details
Setups and Requirements
The Pre- requisite for this interface is to have a Cost budget at Task level in oracle
projects.
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)
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.
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
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.
We are using the transfer to project transaction type to transfer the Inventory item from
Common project to Awarded project.
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
o
o
o
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.
User Procedures
Program Navigation
NA
Running/Scheduling
First run:
Second run:
Third run:
Forth run:
Actor Action
System Response
Actor Action
System Response
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:
Value Sets
NA
Mail Subject
Test Plans
Actor Action
System Response
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
Actor Action
Check the Interface Status update
System
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.
Issue
Closed Issues
Resolution