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 with Oracle Projects. The most straightforward Inventory transactions that will be cost collected and imported to Oracle Projects are miscellaneous inventory transactions.

• Miscellaneous Issue from stock to a project,
  
• Miscellaneous Receipts 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 project-related purchase orders for inventory destination. The items are delivered to a project locator of the inventory organization.
  
• Items are issued from a project locator to a WIP job (work order) of another project or from a nonproject locator to a project work order.
  
• Project Transfers transactions that move items from one project locator to another project locator in the same organization or from a nonproject to a project locator.
  
• Inter Organizations transfer 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 usage, 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 developing 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. The 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 specific 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 for by the 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 the GL posting option is selected as Projects.
  • Send Accounts to PA: Inventory and WIP transactions are interfaced with 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.

Auto Accounting rules will always account for inventory miscellaneous transactions imported from a PJM organization 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 for and posted in GL. All other inventory transactions, which are not charged to projects, will not affect any GL accounts. In addition, 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 for 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 for and interfaced with Projects. This is true for non-project purchase orders as well.
  
• When selecting the Projects value for the GL Posting option, you must 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 joint 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 will explain the advantages of interfacing unaccounted Inventory and WIP transactions with Projects.

Many companies use to apply indirect costs on top of direct costs. For example, 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 for, Oracle Project’s burdening functionality can process the PJM transactions and apply burden costs to those expenditures. Using Project Burden allows companies to systematically apply the same burden multipliers on PJM and all other expenditures charged to the projects. For example, employees may sometimes charge work orders in WIP or a project and task directly 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. The last point in favor of using project burdening over inventory overhead is the ability to treat differently the burden amounts based on project types. The company may 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 a 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 that need to account for PJM transactions using rules based on project attributes, organization, and classification will find the easiest solution 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 the 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 the project’s source transactions is easier than the need to additionally configure similar rules for inventory 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 factors require 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 project 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 interfacing directly with GL has a significant advantage. When there is high value of non-project transactions in a PJM organization, those costs will charge to a single common project. However, Oracle Projects does a poor job of 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.