Project Partners Blog


Posts Tagged ‘oracle project manufacturing’

By Rajesh Silswal

In both Release 12 and 11.5.10, out-of-the box integration between Oracle E-Business Suite Projects and Oracle Enterprise Asset Management (EAM) allows the collection of maintenance costs into Oracle Projects from EAM. You can carry out maintenance activities, consume different resources and the resulting costs of those activities can be transferred into Oracle Projects. These can be brought in as an accounted cost or an unaccounted cost and will facilitate the analysis of Project Based P&L’s. Oracle treats internal maintenance costs as Work in Process (WIP) and is used in conjunction with an Oracle WIP Job. Utilizing Oracle Project Manufacturing enables the integration of Oracle Projects and EAM. Without configuring PJM along with Oracle Projects and Oracle EAM, you cannot leverage this standard out-of-the-box integration. Read the rest of this entry »

Businesses of various shapes and sizes across the globe continue to invest in and expand the footprint of their ERP applications. Much of this increased spend includes mission critical projects such as

1) Upgrades

2) Deploying new applications and

3) Migrating new businesses, acquired companies, countries and/or re-engineered processes into an existing “corporate” ERP.

So how do these companies begin the process? What are the key considerations in play to complete these daunting tasks within an Oracle ERP environment?

Oracle E-Business Suite Applications Releases 11i and R12, and Oracle Fusion Applications – the significant majority of existing Oracle ERP customers use these 3 applications suites.
Read the rest of this entry »

By Robert D. Anderson, CPA

During the last two years, Project Partners has been approached by several firms who run Oracle Order Management and now want to implement Oracle E-Business Suite Projects applications to provide a project-level profit and loss view, as well as contract and client profitability across the firm. Generally this request is happening at the same time the firm is undergoing massive growth and management wants it done quickly so they can get a handle on the growth that is happening and make sure it is profitable or identify problem areas quickly so action can be taken to prevent serious impact to the overall business.

The Oracle E-Business Suite Project Management module (PJT) does not create transactions but provides several tools to allow the tracking of financial transactions that are happening in the Project Costing and Project Billing applications. In addition, it offers both direct tracking in the tool and integration with project management tools, such as Microsoft Project Standard Edition and Primavera P6, as well as an open interface to interact with other similar management and scheduling tools in the market. Since the financial, resource and schedule information all resides in Oracle, the ability to leverage Key Performance Indicators and grouping them into Key Performance Areas, progress tracking and status reporting all combine to offer a strong tool to present the exceptions out of large volumes of data so the firm can take appropriate action at an early stage in the work. Read the rest of this entry »

Introduction

Oracle Projects may be integrated with Inventory and WIP. This integration allows the tracking of project related transactions in Inventory and WIP. Some of those transactions will be interfaced to Oracle Projects. The simplest Inventory transactions that will be cost collected and imported to Oracle Projects are miscellaneous inventory transactions.

  • Miscellaneous Issue from stock to a project,
  • Miscellaneous Receipt from a project into stocks.

Those miscellaneous transactions are imported into Projects from any Inventory organization, whether or not the organization was classified as Project Manufacturing Organization. In a PJM organization those transactions are eligible for cost collection only if the stock locator is of another project or has no project at all.

The following transactions will be cost collected and imported into Oracle Projects only when executed within a PJM organization:

  • Items receipts of a project related purchase orders for inventory destination. The items are delivered into a project locator of the inventory organization.
  • Items issued from a project locator to WIP job (work order) of other project, or from a non project locator to a project work order.
  • Project Transfers transactions which move items from one project locator to another project locator on the same organization, or from a non project to a project locator.
  • Inter Organizations transfers from a project locator or non-project locator to another project locator in the receiving organization.
  • Resources charging WIP work orders, which are project related. Resources may be employees’ labor time, outside processing supplier costs, machine usages etc.

Cost Management invokes the cost processor program for each inventory and WIP transaction, one by one, following their creation order. It calculates the cost amount of each transaction and may generate the accounting lines. When cost processor is responsible for generating accounting, it uses the accounts set up of Cost Groups and WIP Accounting Class. In a PJM organization you assign each project to the organization, and enter the project parameters. Among them you link a project to a single cost group and may link it to various WIP Accounting Classes. Cost Management system also offers some extensions that may be implemented for changing those default accounts.

Accounting Options for PJM Organization

When Project Manufacturing is enabled for all or certain inventory organizations, there are (starting 11.5.10) several alternative options for accounting, which differ in scope and path. On the setup form of a PJM organization you should select one value for each one of the following parameters:

  • GL Posting Option:
    • Manufacturing: All inventory and WIP transactions are accounted by Cost Management process in Inventory, and sent from Inventory to GL. The project-related transactions are interfaced from Inventory to Projects as accounted.
    • Projects: Inventory is not interfacing any material or WIP transactions to GL. The project-related transactions are interfaced from Inventory and WIP to Projects.
  • Account Option: This option is applicable only if GL posting option is selected as Projects.
    • Send Accounts to PA: Inventory and WIP transactions are interfaced to Projects with the accounts defined by the source. However, Projects will interface those to GL.
    • Use Auto Accounting: Inventory and WIP transactions are imported into Projects unaccounted. Oracle Projects is responsible for distributing those expenditures using Auto Accounting rules.

Inventory miscellaneous transactions imported from a PJM organization will always be accounted by Auto Accounting rules in Projects.

Several points regarding these options are worth noting when implementing Project Manufacturing:

  • When selecting the Projects value for the GL Posting option, only transactions that are cost collected into Projects are accounted and posted in GL. All other inventory transactions, which are not charged to projects, will not be affecting any GL accounts. Any inventory transaction that represents a change in the physical on-hand value of inventory without adding or reducing any value to the project accumulated cost will not be cost-collected nor accounted in GL.
  • WIP transactions represent resources adding value to the project-work-orders; hence those are always cost collected into Projects, and always accounted.
  • PO delivery transactions into Inventory or Shop-Floor, and any subsequent correction or return transactions will always be accounted and interfaced to Projects as well. This is true for non-project purchase orders as well.
  • When selecting the Projects value for the GL Posting option you have to enable a project number as a Common Project on the PJM organization setup form. In a PJM organization, users may enter transactions without project and task. By enabling a common project the system will capture any WIP and Inventory transactions with no project data, and interface those to Projects, all assigned to the predefined common project and task.

In the following paragraphs I would like to explain the advantages of interfacing unaccounted Inventory and WIP transactions to Projects.

Many companies use to apply indirect costs on top of direct costs. In Inventory and WIP you may setup overhead rates, and the cost processor calculates the additional cost elements, material overhead and resource overhead. Those overhead materials are cost collected and interfaced as separate burden expenditures. The alternative tool for applying overhead is the burdening functionality of Oracle Projects. Projects will not allow burdening of externally accounted transactions. However, when expenditures are imported as not accounted, Oracle Project’s burdening functionality can process the PJM transactions, and apply burden costs to those expenditures. The ability to use Project Burden allows companies to apply systematically the same burden multipliers on PJM and all other expenditures charged to the projects. For example, employees may sometime charge work order in WIP or charge directly a project and task on their timecard. Using this feature the burden calculation may be shared, and you could save the maintenance of duplicate rates schedules. In addition, Projects’ burdening allows for updates to the burden rates. The ability to re-burden and apply final burden multipliers, replacing the provisory initial multipliers is a unique feature available in Projects. There is no way to revise overhead rates in Inventory. Last point in favor of using project burdening over inventory overhead is the ability to treat differently the burden amounts based on project types. Company may choose to use burden on separate expenditure items (summarized burden items) for contract projects, but use burden on the same item for capital projects.

Some companies also need to account differently for billable versus not billable expenditures. Such feature is easily done in Projects, and is a lot more complex to achieve using the accounting engine of Cost Management in Inventory. You may set up transaction control in Oracle Projects to derive the billability of Inventory and WIP expenditure items. With the expenditure items marked as billable, you can use Auto Accounting rules of Projects to generate the appropriate accounting based on billability.

The accounting generation for project expenditures is easily configured and maintained when you use only Oracle Projects’ Auto Accounting. Companies which need to account for PJM transactions using rules based on project attributes, project organization, project classification, will find the easiest solution is to use Auto Accounting. Alternatively, achieving the same project-based accounting in Cost Management; would require developing the Accounting Generation Extension. This is a separate tool based on workflow engine, which requires extra development and maintenance effort. Even when you are using SLA in Oracle release 12, the configuration of accounting rules for Project’s source transactions is easier than the need to additionally configure similar rules for Inventory’s source transactions.

Sending all project-related transactions to GL through one source – Projects – eliminates the need to reconcile between project costs and their respective journal entries generated and posted by Inventory. Using the single path also eliminates the need to manage the period close of the inventory organization. Since Inventory would no longer be an accounting source, the closing of accounting periods for each inventory organization can be obsoleted.

All the above mentioned factors call for using a unified tool for generating project-based accounting. Those points become clear advantages when meeting the following two characteristics: Inventory and WIP transactions of a PJM organization are mostly project related; and when accounting rules are based on projects flows of revenue versus costs. If, on the other hand, the majority of Inventory cost is non project, you might not use the recommended method above.

In cases where companies require accounting in GL for significantly high amounts of the Inventory Materials asset account, the alternative method may be favorable. In these cases, using the classic Inventory flow for accounting and interface directly to GL has indeed a significant advantage. When there is high value of non-projects transactions in a PJM organization, those costs will charge a single common project. Oracle Projects, however, does a poor job in accounting for the balance of on-hand inventory by the end of each period. Oracle Projects setup at a PJM organization might not be a good solution for physical inventory based accounting.

Today’s topic deals with using Oracle Project Management (PJT) in a Project Manufacturing (PJM) environment.

PJM is a solution delivered by Oracle to enable ATO/ETO type firms that design and build manufactured items to client specifications. Each client order is managed as a project (due to hard time and budget constraints) but the execution is done primarily in Project Manufacturing.

PJT provides integrated automation solutions for use by a project manager (PM). There are some integration points and some issues that need to be highlighted in using these 2 solutions together.

Integration Points

  1. Resource Classes
  2. ==> Materials: Can be setup to refer to inventory items from specified (in resource class screen) Item Master and Item Category set.

    ==> Equipment: Can be setup to refer to BOM resources (Labor and Equipment) setup in Manufacturing.

  3. Deliverables
  4. ==> Deliverable Type of ‘Item’ allows for associating Items that can be setup as Inward or outward bound deliverables

    ==> For Purchased deliverables, you can setup deliverable actions for Purchasing which allows you to automatically create Purchase Reqs in PO for those items.

    ==> For Manufactured deliverables, you can setup deliverable actions for Shipping which collects additional information and then allows you to place a demand on the MRP and once the item is manufactured place a ship order on the item right from the deliverable action screen.

Issues
One major consideration in using the 2 solutions together is the level at which delivered items are planned for in PJT. The users can choose to plan at the (summary) delivered item level or at the (detailed) BOM components of the delivered items level. In either case there are issues to be considered in how this will be handled.

1) If planning at the summary level, the issue arises with collection of Manufacturing actuals and how these actuals are mapped to the planned summary items in the workplan for proper actual v/s planned reporting. The issue is as follows: When a delivered item is planned at a summary level, the actuals from Mfg come at the detailed BOM Component items level as these items are charged to the project as they are consumed in the build out of the summary item. Now when these actuals come to PA, they are stamped with the detailed Component Item and as this does not map to the planned item, it is mapped to the workplan as an unplanned actual: thereby doubling the cost.

==> The solution to this is to collect the final summary item on each mfg transaction as the detailed items are issued from inventory (in a DFF on the transaction). Then after these transactions are cost collected and pushed into the PA-Transaction-Interface table and before the transaction import process is run in PA, we need to change the item on the transactions from the detailed component to the summary item fro the DFF on the Transaction. Now when this transaction is pulled into PA and subsequently mapped to the Workplan it will show up correctly as actuals against the summary planned item

2) If planning at the detailed item level is desired, the issue comes of how to identify all the detailed components needed in the build out of the delivered item in order to plan for them on the workplan. In this case the Delivered items should be setup as a deliverable in order to place the Demand on the MRP as needed. Once this is done, there 2 choices

==> Manually figure out the detailed components and enter them as task assignments on the workplan

==> Have a custom – batch process, that reads the deliverable items and then fetches the detailed components from the BOM explosion of the item in BOM and automatically add them as task assignments to the task associated with the deliverable item.

That’s it for now and remember:

There is no better way to manage a business than to Manage by Project.

PS: I welcome all comments / trackbacks / pingbacks / queries to my nascent venture here. I will try