Fusion Costing BRD

BUSINESS REQUIREMENTS DOCUMENT
Cost Management
Actual Costing
Applications Release: Fusion v1.1
Author: Gerald Goodbody
Creation Date: 9/2/2009 7:20 PM
Last Updated: 12/10/2009 11:31 PM
Detailed Business Process: Product Management – Manage Cost Accounting
Business Process Activity: Record Cost Accounting
Business Process Tier: Cross Industry
Project ID: <RPS Project ID>
File URL: http://files.oraclecorp.com/…
Document Version: 3.0
Status: IN DRAFT, REVIEW FEEDBACK INCORPORATED, READY FOR APPROVAL,

APPROVED>
Template Version: 1.5
Disclaimer: The following is intended to outline our general product direction and is intended for information purposes. The
development, release, and timing of any features or functionality described for Oracle's products remains at the sole discretion of
Oracle.
Copyright  2019 Oracle Corporation

All Rights Reserved
Document Control
Document Control Instructions
Contributors
Name Role Content Contribution
Change Record
Date Name Version Change Reference
12/10/2009 Revised document posted on
Oracle Review after first round of
reviews.
Document References
Title Author Location Comments
Overview Oracle Corporation Confidential - For Oracle internal use only Page 2 of 28
Reviews and Approvals
Reviews and Approvals Instructions
Reviewers
Name Role Status Comments Version Date
Reviewed
Review Complete
Will Not Review
Srini Raghavan Product Management Pending review
Shyam Santhanam Product Management
Michel Bazinet Strategy
Anil Jain VP
Mandatory Approvers
Reviewed
Gerald Goodbody FDD Author Approved
Will Not Approve
Michel Bazinet Product Strategy Manager Approved
Will Not Approve
Anil Jain Project Manager
Additional Approvers
Reviewed
Srini Raghavan
Shyam Santhanam
OBIA teams (need to fill in) Approved 1.0 30-Nov-
Will Not Approve 2006
Table of Contents
1. Overview_________________________________________________________________________6
1.1 Introduction_____________________________________________________________________________6
1.2 Market and Competitive Analysis____________________________________________________________6
1.3 Requirement Use Case(s)__________________________________________________________________6
1.3.1 Use Case Information__________________________________________________________________________6
1.3.2 Primary Scenario______________________________________________________________________________6
1.3.3 Alternate Scenarios____________________________________________________________________________6
1.3.4 Error Scenarios_______________________________________________________________________________6
1.4 Business Process, Detail Business Process, Activity, and overall task flow address in BRD_______________6
1.5 Assumptions____________________________________________________________________________6
1.6 Customer Validation______________________________________________________________________6
2. Glossary__________________________________________________________________________7
2.1 Terms specific to BRD consumption/comprehension____________________________________________7
2.2 Terms to be added to Central Terms Repository (CTR)___________________________________________7
[Unique Term]______________________________________________________________________________________7
3. Business Requirements______________________________________________________________8
3.1 In Scope Requirements____________________________________________________________________8
3.1.1 [Requirement ID] - Requirement Name____________________________________________________________8
3.1.1.1 Requirement Description______________________________________________________________________8
3.1.1.2 Requirement Business Process Proposed Task Description___________________________________________8
3.1.1.3 Requirement General Information______________________________________________________________8
3.1.1.4 Analytic Requirements________________________________________________________________________8
3.1.1.5 User Interface Examples______________________________________________________________________9
3.1.1.6 Integration Requirement______________________________________________________________________9
3.1.1.7 Performance Requirements____________________________________________________________________9
3.1.1.8 Dependencies and Impacts____________________________________________________________________9
3.2 Out of Scope Requirements_______________________________________________________________10
3.2.1 [Requirement ID] - Requirement Name___________________________________________________________10
3.2.1.1 Requirement Description____________________________________________________________________10
3.2.1.2 Requirement Business Process Proposed Task Description__________________________________________10
3.2.1.3 Requirement General Information_____________________________________________________________10
3.2.1.4 Analytic Requirements______________________________________________________________________10
3.2.1.5 User Interface Examples_____________________________________________________________________11
3.2.1.6 Integration Requirement_____________________________________________________________________11
3.2.1.7 Performance Requirements___________________________________________________________________11
3.2.1.8 Dependencies and Impacts___________________________________________________________________12
4. Issues___________________________________________________________________________13
4.1 Open Issues____________________________________________________________________________13
4.1.1 Issue [Name, Number]_________________________________________________________________________13
4.2 Closed Issues___________________________________________________________________________13
4.3 Managed Exceptions_____________________________________________________________________13
5. Appendix: <Appendix Name>_________________________________________________________14
1. Overview
Overview Instructions
1.1 Introduction
This design document is a feature completion design for v1.1. It assumes prerequisite understanding
of existing Fusion v1.0 costing terminology, capabilities, functions, and structures. The actual cost
requirement dove-tails into the business requirements already satisfied with the existing Fusion Cost
Management v1.0 solution. This document focuses on just the new requirement components;
existing solutions are not repeated in this requirements document.
Especially important to comprehending this BRD is an understanding of the v1.0 Valuation Unit
concept. Also, the existing interface points with the surrounding applications.
The Actual Cost method is commonly recognized and accepted accounting method that our costing
product needs to support to have market credibility as a complete solution. This rounds out our cost
accounting method offerings. Oracle Fusion v1.0 has Average Cost and in v1.1 the plan is to add
new cost methods such as Actual cost, Standard Cost, and Periodic Average as alternative cost
methods that users can choose from. Actual costing is a method where the “actual” monetary amount
expended to purchase or manufacture goods stored in inventory is tracked by the costing system for
each receipt. The actual cost may include charges and expenses required to bring inventory into it’s
current saleable state. The actual cost also includes updates from vendor invoice prices where
applicable. More precisely, each receipt delivery (or putaway) into inventory has an actual cost. Each
delivery into inventory is logically tracked by the cost system as transactions flow through the
inventory system and each logically tracked delivery has its own cost history within the cost
accounting application. The word “actual” is in quotes because the definition of what “actual” really
means is largely user defined.
The scope of this business requirements document is focused on purchased items. Actual Cost for
other item sources such as manufactured items will be covered in other design documents.
International Accounting Standards IAS2 can be summarized as follows:
Inventory is stated at the lower of cost and net realizable value (IAS2.9) which is similar in principle
to lower of cost or market in US GAAP. Cost comprises all costs of purchase, costs of conversion
and other costs incurred in bringing items to their present location and condition (IAS2.10). To the
extent that individual items are identical, the first in first out (FIFO) or weighted average cost
formula is used (IAS2.25). Last in first out (LIFO) is not allowed under these standards
(IAS2.IN13).
Adobe Acrobat
Document
IAS #2
Note: customers may still require formulas such as LIFO if they operate in non-IAS conforming
jurisdictions or for other financial reporting purposes which are not bound by International
Accounting Standards.
1.2 Market and Competitive Analysis
Oracle Applications Unlimited products such as EBS, PeopleSoft, and JDE all provide some form of
Actual Cost method to users. This design intends to bring Fusion into parity with the superset of the
best capabilities of those solutions.
Moreover, the Actual Cost method gives users a powerful option for their accounting and thus can
greatly increase customer attraction to our Fusion solutions. Benefits of an Actual Cost method
include:
 With actual costing a very minimal amount of manual intervention is needed in the
business flows for a cost accountant. The costs are typically captured by nature in
purchasing and accounts payable as a normal part of the business transactions and the actual
cost method simply uses those amounts in the cost accounting without any further data
entry required for cost accountants except on a rare exception basis. Thus, the emphasis for
the Cost Accountant role becomes simply to identify and act on rare exception conditions
which frees the Cost Accountant to spend more of their time on other value add business
initiatives.
 Actual costing can be a tremendous savings on administrative costs. As opposed to

standard costing, actual costing is much less effort. There is no need to set and maintain
standards. Standard can still be maintained if users wish, but they are not used in the actual
cost accounting flows.
 Actual cost is a very a robust, reliable, self correcting approach, as opposed to

approaches such as average costing. Errors and mistakes are isolated to a particular
inventory instance, they are easily corrected, and do not easily propagate or pollute other
inventory instances. For example, errors and mistakes won’t distort a shared average cost.
 The actual cost approach is extremely accurate and exacting, as opposed to both average
and standard. Actual cost is not a rough standard, or an average… actual cost is as actual
and accurate as users define it to be.
 When built correctly, the actual costing approach has very clean and simple logic. This
simplicity makes for a very powerful approach for our customers with a very high degree of
reliability and low maintenance effort.
 Actual cost can be recognized as a visionary competitive advantage for Oracle. Our
competitors have decent average and standard costing solutions, but few have a good actual
cost solution.
 GAAP Regulatory requirement
Our designs and the actual solution should live up to those value propositions.
Good and Bad of Apps Unlimited Solutions:

EBS
 limited tracking of actual costs through the supply chain (through interorg transfers)
 lacks user defined cost element granularity
 as goods flow through supply chain, cost element visibility is lost
 limited ability to capture cost update information from AP to restate costs of prior
depletions
PeopleSoft
PeopleSoft has a very robust actual cost system, including landed cost. However, some limitations
include:
 limited tracking of actual costs through the supply chain (through interorg transfers)
 very good plumbing to capture data and perform accounting functions, but a lack of good
business analytics that use the wealth of information… such as gross margin analytics
where uses could use the information for business decisions.
JDE
The JDE solution for actual cost is really a “last cost” solution. It uses the last actual cost to value
inventory and cost transactions. This is not GAAP conformant. [michel to confirm]
Guiding Vision for Fusion
A common problem with most costing solutions available to customers today, is gaps in the ability of
the systems to capture and track costs all the way through the supply chain. Our guiding vision is to
build solutions that give customers the ability to really understand the profitability of their products.
This means in the cost accounting domain, we need to provide the ability to capture the relevant
product costs and track those costs as products flow all the way through the supply chain. The actual
cost method is the gold-standard for that vision.
1.3 Requirement Use Case(s)
1.3.1 Use Case Information

Automated Flow
Task Type
Cost Accountant Central to Role Regularly, Frequently
Role/Importance/Usage
System design should minimize the need for user interaction in the automated process.
Role Comments The interaction should be on exception basis. Cost Accountant can then spend time on
other productive business tasks.
See Use Case
Requirements
1.3.2 Use Case
Actual Costing for Purchased Items
Goal:
The system automates the accounting for inventory transactions at actual
cost, including both (a) inventory value of receipts in inventory, and (b)
cost of depletions
Scope:
Actual Costing for Purchased items flows; non-manufacturing flows
Preconditions:
Costing User defines the costing setup structure, including valuation units
Costing User defines an item as an actual cost item
Buyer creates purchase orders with estimated material, tax, and freight
amounts
Receiver enters receipts of goods at the receiving dock in the same
business unit as the Buyer
Receiver then enters that the goods were putaway into inventory
Sales clerk creates a sale of some of the inventory to a customer
Shipping clerk enters a depletion of goods to satisfy a sale
Cost Accountant runs costing engines or schedules the appropriate cost
processing engine(s) to run on a user defined frequency
Accounts payable person receives a vendor invoice for the goods and
sets up the payment
Cost Accountant runs costing engines. Or it has been scheduled the
appropriate cost processing engine(s) to run on a user defined frequency
Main Success Scenario:
Transactions are cost accounted at actual cost with a minimum of manual
intervention by cost accountants
Base Case:
The System assigns a cost to the receipt based on the amounts from the
Purchase Order
The System assigns the receipt costs to the putaways into inventory
The System determines which receipts to logically consume in order to
satisfy the depletion
The System calculates the cost of the shipment based on actual known
cost of receipts consumed.
The System adjusts the receipt and shipment costs based on new actual
cost information that becomes known
Cost Accountant can view cost data about the various transactions &
events, and user can view the accounting entries
Cost Accountant can view various inventory valuation analytics
Business Managers can view the true gross margins of their sales, using
actual sales amounts and actual costs
Guarantees:
The quantity and cost of each receipt transaction is distinctly maintained
The true actual cost can be updated an unlimited number of times and
receipts and depletions will be adjusted to reflect the newly known actual
cost
The system has a full history of the actual costs that were known as of any
point in time
There is a match between (a) the amounts flowing into inventory, and (b)
the amounts accrued by the purchasing and accounts payables systems
The costing system data model has the logical onhand qty for each item-
valuation unit based on cost accounting assumption
Shipments are logically consumed by costing logic from the appropriate
valuation unit, thereby depleting the appropriate receipts in FIFO order
FIFO consumption happens within the valuation unit for any combination
of user defined control attribute level actual costing (lot, serial, item level,
etc.)
Actual Cost Inventory value is the sum of: each receipt transaction's
quantity multiplied by the cost of that receipt transaction
Extensions
Retroactive price adjustment from purchasing
Update newly known actual cost using same rules that are used
with the perpetual average cost engine
Costs entered et receiving or costs given by external Landed Cost system
Update the newly known actual cost to reflect this cost
information
User cost adjustments
Update newly known actual cost using same rules that are used
with the perpetual average cost engine
User can adjust inventory value to reflect a change in
acquisition cost of the item
User can adjust inventory value to reflect a change in value of
the item (lower of cost or market)
Miscellaneous receipts; non purchase order receipts entered in inventory
system
User must enter the actual cost for miscellaneous receipts
Cost adjustment from Accounts Payable in a subsequent period
The cost engine should try to post all adjustments in the period
of each transaction being adjusted; if that period is already
closed, use the next opne period
Overhead costs
Overhead costs can become components of the "actual cost";
same flow as perpetual average
Backdated Inventory Transactions
Follows the same rules as perpetual average
Cost Adjustments on Inventory Transfers
The true actual cost should follow the receipt transaction as it
flows into other inventory locations
Changes to actual cost through transfers should be offset
against the profit in inventory cost element
The goal of the solution is to report true actual costs, gross
margins, inventory value all the way across an extended supply
chain
Depletions of inventory for purposes other than sales
The same depletion logic applies to any type of depletion:
expense, project issues, etc.
Non Actual Cost Methods
The system always can capture and store basic Actual Cost
History regardless of item's cost profile
1.4 Business Process, Detail Business Process, Activity, and overall task flow address in BRD
Business Process Flow Instructions
Primary business process activity to be enhanced
Cross Industry
Product Management
Manage Cost Accounting
Record Cost Accounting
Manage Inventory Valuation
Analyze Product Cost
Business Process Diagram
1.5 Assumptions
This design assumes prerequisite understanding of existing Fusion v1.0 costing terminology, capabilities, functions, and
structures. The actual cost requirement dove-tails into the business requirements already satisfied with the existing v1.0
solution. This document focuses on just the new requirement components; existing solutions are not repeated in this
requirements document.
Especially important to comprehending this BRD is an understanding of the v1.0 Valuation Unit concept. Also, the existing
interface points with the surrounding applications.
1.6 Customer Validation
Customer Validation Instructions
[If section not applicable, indicate so and provide a reason]
Customer Name Date(s) of Sections Link to Validation Database with feedback
validation Reviewed
2. Glossary
Glossary Instructions
2.1 Terms specific to BRD consumption/comprehension
Cost Org – A cost org is a collection of one or more inventory organizations. An inventory organization is usually thought
of as a warehouse, but the four walls can be virtual walls and what makes up a warehouse is up to how users are able to
stratify their physical inventory and what they would like to define as a “warehouse”.
Item – An inventory item.
Receipt Transaction – A receipt transaction is intended as one way of describing an inventory item instance. It is
somewhat synonymous with a “layer” of inventory, but we avoid using that term for that purpose because it could be
confused with a purchase order receipt. A single purchase order receipt can spawn many inventory “deliveries” or
“putaways” and each delivery or putaway is a logical “layer” in inventory in the costing model.
Delivery / Putuaway -- A “delivery” into inventory, or “putaway” into inventory can be used synonymously. A Purchase
Order Receipt can spawn into many inventory deliveries or putaways. For example a Purchase Order Receipt of 10 units
of an item could result in a two deliveries to inventory; one delivery for a quantity of 7 and another delivery for a quantity
of 3. The delivery level is the atomic “layer” that the costing data model tracks. Purchasing and Payables estimate costs
and allocate amounts paid to vendors as low as the receipt level, so in simple cases, all the deliveries from a receipt would
have the same actual cost. However, users can adjust inventory value down at the atomic delivery/putaway level. Also, a
single receipt delivery could spawn into more deliveries via a bin to bin transfer. For example, if a user transferred 2 units
from the 7 unit delivery into another bin location, there would then be three distinct “deliveries” or layers tracked in the
costing architecture.
Valuation Unit – A generic user defined attribute driven subcategory of Item. Valuation units could be things such as
lotid’s, serialid’s, grades, or any other classification that the inventory system is capable of tracking. In costing, the receipts
that qualify for depletion are only those within the same valuation unit as the depletion. For example, if there is depletion
for lot “a”, only the receipts of lot “a” qualify for satisfying the depletion. This is how the costs of lot “a” flow into the
accounting for the depletions of lot “a”. The valuation unit that users define for an item is what determines the granularity
and precision of their actual cost accounting for depletion transactions.
Layer – A layer is a generic term for the atomic level of inventory instance at which the costing architecture tracks quantity
and cost. The layer that the costing architecture tracks is at the delivery level. Valuation Units have one to many layers.
Effective Date-Time – The effective date-time marks the point at which a new piece of cost information becomes known
to the costing system, and the point at which the newly revised actual cost became known. As time passes, more cost
information may become available about a particular receipt and delivery. At first, the cost information available about a
receipt may be limited to the estimate that was on the purchase order. This estimate can be revised with purchase order
price updates over time, even after receipts have already happened. The estimate of the true cost can again be revised when
the receipt arrives and more information is known about various elements of the total cost at that time. Again, more cost
updates can come from further cost estimate revisions, and again from accounts payable when the actual vendor invoices
arrive and processed for payment. Even after processing vendor invoices for payment, even more cost updates about the
receipt can arrive in the form of adjustments and planned cost rebate incentives where the amount of the rebate is not
known until after the accumulation of event and thresholds met over time.
Cost Component – A generic granular component of cost. Cost information coming into costing from external software
modules such as Purchasing, Accounts Payable, Landed Cost Management systems, etc. come in as components of cost.
Within costing we categorize the components of cost into Cost Elements.
Cost Elements – A cost element is the level that costs are tracked through inventory. A cost element is a categorization of
cost components.
2.2 Terms to be added to Central Terms Repository (CTR)
None identified.
[Unique Term]
[Definition]
3. Business Requirements
Business Requirements Instructions
3.1 In Scope Requirements
3.1.1 Forward Flow Actual Costing for User defined levels
The ability to account for inventory transactions using actual cost for any user defined valuation unit
flow. Valuation units can be at any level, as determined by the existing valuation unit architecture.
This includes at the item level, lot id level, serial id level, and so on. User will be able to choose
either a FIFO or LIFO flow of goods within the valuation unit. The example in the Appendix shows
how this should work.
3.1.1.1 Requirement General Information
Must Have
Priority
Apps Unlimited Feature,
Source(s) Actual Costing is an International Standards conforming and Generally
Accepted Accounting Policy which can be adopted in a wide range of
companies around the world.
Source Details
PeopleSoft, EBS, JDE
Reference System ID
All industries
Primary Target Industry/ies
Secondary Target Industry/ies

All Regions
Target Region(s)
All
Target Country/ies
Cost Accountant, Product Manager, General Managers, CFO, CEO,
Target Roles
3.1.2 Adjustments from AP, PO, and User Cost Adjustments
The ability to capture and track cost changes from any source such as AP, PO, and from User Cost
Adjustments. Actual Cost inventory value is restated to the updated cost and any previous depletion
costs are also restated to the true cost as given by the adjustment. This is a unique capability of the
actual cost method: it is possible for user to configure the system so that the cost of goods sold is
always stated at the true actual cost, all the way through the supply chain.
Another type of adjustment is an adjustment, typically down (but in some industries potentially up)
to net realizable value. This happens when inventory somehow becomes impaired, or for whatever
reason, its marketable value becomes lower than what the true cost was.
When a user needs to adjust inventory value down to “net realizable value” under IAS 2.9 (similar to
the “lower of: cost or market” rule under US GAAP), it should be possible to do it without impacting
any of the true cost information. It should be possible for users to retain the cost elements that hold
what the true costs were. The reduction to net realizable value should be done via a contra-cost cost
element type which tracks the allowances, impairments, or reductions to the value of the inventory.
This approach satisfies our guiding vision to track true costs through the supply chain.
Must Have
Priority
Source Details
Reference System ID
All industries

All Regions
Target Region(s)
All
Target Country/ies
Target Roles
3.1.3 Reverse Flows
The ability to account for the reverse supply chain flows using an “actual” cost. Reverse supply
chain flows include returns to vendor, returns from customers, and inventory adjustments that
increase inventory quantity. Also there will be the need for the costing system to be capable of
arriving at a default “actual cost” and allow users to adjust inventory value to net realizable value.
In the return to vendor scenario, the actual cost of the layer is consumed from inventory. The
amount of credit the vendor may offer can be different than that logical layer’s cost. A gain/loss on
returns to vendor would be created to balance the difference.
In the return from customer scenario, the actual cost of the incoming layer should be valued at the
lower of cost or net realizable market value. The system may suggest a reasonable proposed cost
basis as the default “actual” cost based on recovering prior transaction history. Prior transaction
history might include the ability to get the original cost of the item that is returned, if it is available
and relevant. If the original cost is not available or relevant, the system should use a default cost to
value the returned inventory (see a couple paragraphs below for details on this). However, there
needs to be a way for user to review those proposals and adjust them to net realizable value where
applicable (see a couple paragraphs below for details on this). Also, users should have the ability to
add costs due to return processing. Additional costs could come from applying overheads to return
from customer transactions or from manual user cost adjustments. The general accounting treatment
is: credit to customer is a contra sale and the value going into inventory is a contra-cost of goods
sold. That generic accounting treatment works the same way whether the original sales order is
known or not known.
When there is a return from customer for replacement, there is sometimes a temptation to take a
shortcut and skip some of the documentation or “paperwork” (ie since it’s just a replacement,
simply receive the old goods and issue the new ones). While it may be desired to shield users from
some of the background details for some scenarios, in the background, a consistent record keeping
approach should be followed. Streamlining the user interface is ok but taking shortcuts on the
background record keeping is not recommended and should be avoided because it has the risk of
leaving holes in the system records and in the audit trails. Flows in and out of inventory should
always were possible reference the appropriate documentation. All receipts of inventory from
customers should reference a return material authorization document, along with a link to a credit
memo invoice. All shipments to customers should have an association with a customer purchase
order, a sales order, and customer invoice. In a retail setting, by nature, some of the paperwork is
streamlined and relaxed, because the phases of the transaction flow tend to all happen at once at the
cash register, but retail flows are beyond the scope of this BRD document.
In the case where a user is making a positive physical inventory quantity adjustment that increases
inventory onhand quantity per the system’s records, typically, the user has no way of knowing the
origin of that quantity. A user took a physical inventory count and for whatever reason the physical
count did not match the quantity according to the system. In all likelihood this means there was a
previous record keeping mistake which now requires user to make the physical inventory adjustment
without knowing what the true actual cost of the item really was. In this case the costing system will
need to assign a default “actual cost” to those incoming quantities (putaways / deliveries).
For the returns from customer and positive inventory adjustments flows, many inventory systems
have rudimentary approaches for allowing users to enter an incoming cost for these types of
transactions, if at all. In fact, in many settings, it would be preferred that the inventory system and
inventory users not be burdened with coming up with an inventory valuation; rather it is often
preferred that the costing system apply a consistent approach to valuation based on accounting
policy. For the case where the transaction comes into the costing system with no cost, our costing
solution should have a way to automatically set a proposed default cost. How the proposed cost is
set should be configurable by users for the item if we allow more than one option. The first option
we will allow would be based on the most recent actual cost for the same item in the valuation unit.
The system can later be enhanced to allow for more valuation methods in this scenario over time.
For returns from customers, the transaction flow would be a receipt and a delivery to inventory.
After the receipt and before the delivery to inventory, there may be a physical disposition step where
a user would assess the returned goods suitability for restocking as something available to be sold.
The item may require, cleaning, repackaging, or the price may need to be marked down. At this step
there is an opportunity for a user to adjust the cost information based on these factors before putting
the items back into inventory. The Landed Cost BRD covers this step of the flow in more detail.
When there are incoming quantity transactions where the history and source of the quantity and or
the condition and value of the quantity might be mysterious and worth investigation, the cost system
should provide the cost accountant a user interface to indicate that they may wish to manually
examine the valuation of the items and potentially adjust the valuation. Whether or not the cost
accountant would perform this manual examination would be based on the significance of the
amounts (the materiality principle). The user interface should contain information for assessing the
materiality of the transactions such as quantity, unit cost, and the extended value (qty x unit cost) of
the transaction. In the initial release, this requirement can be achieved in a simple way and further
enhanced over time.
For the reverse flows, a cost accounting user needs to have the ability, if desired, to adjust inventory
value down to a net realizable value in the manner described in 3.1.2. Especially in the case of
customer returns, this would give users the ability to reset inventory value to its original true cost
and at the same time track reductions to inventory valuation due to having been returned.
Must Have
Priority
Source Details
Reference System ID
All industries

All Regions
Target Region(s)
All
Target Country/ies
Target Roles
3.1.4 Negative Inventory
Most inventory systems allow users to consume inventory from the system even if the onhand
quantity is driven negative according to the perpetual inventory computer records. Typically this is
because, even though the computer records don’t show it, the inventory really is physically there and
user would like to go ahead and enter the physical movement into the system. But at some point,
user will need to make sure the system is caught up to physical reality (negative inventory is
obviously not physically possible) by processing pending receipts or inventory adjustments.
From an accounting standpoint, the existing v1.0 negative inventory options will need to be
supported for actual cost methods: Always cost negative, cost down to zero quantity, and don’t cost.
When the always cost method is in place, the portion of the depletion that is driven negative will
need to be assigned a temporary estimated cost, then when there is sufficient quantity, that
transaction will need to be restated to true actual cost. When the transaction is restated to true actual
cost, it follows the period end accounting paradigm established in v1.0. The transaction retains it’s
cost date, so if the period of the transaction is still open, the accounting date will be set to be in that
same period; if the period was already closed by the time the restatement occurs, the accounting date
will be in the next open period. In the cost down to zero and don’t cost scenarios, the true cost will
be stated when there is sufficient quantity to complete the costing. If sufficient quantity isn’t entered
before the close of a period, the costing of the transaction will occur in the open period when
sufficient quantity finally is entered into the system.
Obviously, users should try to avoid significant negative inventory situations at the end of a period.
Various existing audits and reports will help users avoid negative inventory situations which could
materially impact their financial statements.
Must Have
Priority
Source Details
Reference System ID
All industries

All Regions
Target Region(s)
All
Target Country/ies
Target Roles
3.1.5 Backdated Transactions / Cost Cutoff
A backdated transaction is when an inventory user enters an inventory transaction into the inventory
system on an untimely basis. It is a transaction that physically happened one day but wasn’t entered
into the system until another later day. We ask the inventory system to simply capture the data entry
date, and the real physical transaction date which defaults to the entry date in most systems, but in
the case of backdating, a user would modify the default to the actual date the event physically
happened.
The actual cost methods need to support the cost cutoff’s and backdated transactions. Transactions
up to the cost cutoff date are processed; transactions after the cost cutoff date are held for costing
until the cost cutoff date is moved out to a date greater than or equal to the transaction date on the
transaction. Backdated transactions are reordered, but only reordered back to the point after any
previously costed (previous runs of cost process) transaction.
For example, assume that costing was run up through Oct 31 with a cost cutoff of Oct 31.
Transactions with a transaction dates of Oct 30 have already been processed. This costing run on
Nov 2, is processing some inventory transactions that have some backdated transactions for Oct 29,
Oct 30, Oct 31, and there are also some non-backdated transactions for Nov 2. The costing logic
should put the Oct 29 transactions at the front of the stack, but since there were already some Oct 30
transactions processed, the costed date will need to be Oct 30, then the Oct 30 transaction dates will
come next and finally the Oct 31 transaction dates. The Nov 2 transaction dates would not be
processed until the cost cutoff date is moved out to Nov 2 or greater.
Must Have
Priority
Source Details
Reference System ID
All industries

All Regions
Target Region(s)
All
Target Country/ies
Target Roles
3.1.6 Overheads
Actual cost receipts and depletions will be capable of having overhead costs applied by the overhead
rules engine. The business rules and paradigm follows the same methodology as for perpetual
average cost items.
Must Have
Priority
Source Details
Reference System ID
All industries

All Regions
Target Region(s)
All
Target Country/ies
Target Roles
3.1.7 Tracking costs through inter-organization transfers
It must be possible to configure the system to maintain and track actual cost details through the
supply chain, or collapse cost details as configured by user. This includes internal markups and
“profit in inventory”. Our philosophy is to give users the ability to track cost details all the way
through the supply chain, but we don’t force it, we give them the options.
When there are cost adjustments after an inventory transfer has taken place, user can choose whether
or not that cost adjustment propagates through inter-organization transfers. For example if goods
were received in Org A at $10 each and 1 unit is transferred to B, then later there is a cost update
from AP that $11 was paid to vendor, then the true cost of those goods is really $11 and an
adjustment of $1 is required. User should be able to choose what to do with the $1. It can be cleared
to a period expense as a gain/loss at A on the inter-organization transfer. Or, the $1 can be kept in
inventory by revaluing the inventory at B to $1, or if B has shipped it to C, then the $1 continues
from B to C. And if C has shipped the item, then the $1 can flow into C’s cost of goods sold as well.
When cost adjustments flow through the supply chain, they should not change the inter-organization
internal transfer price, even in cost plus price scenarios. Once the inter-organization transfer price is
set for a transaction, it should remain constant. The change would be to the relevant cost element for
the cost and the profit in inventory cost element. For example, if the internal transfer price had been
set to $15 and the additional $1 was an additional cost to the material cost element, then the material
cost element would be adjusted from $10 to $11 and the profit in inventory would be adjusted from
$5 to $4.
Must Have
Priority
Source Details
Reference System ID
All industries

All Regions
Target Region(s)
All
Target Country/ies
Target Roles
3.1.8
3.1.8.1 Requirement Business Process Proposed Task Description
Must Have
Priority
Source Details
Reference System ID
All industries

All Regions
Target Region(s)
All
Target Country/ies
Target Roles
3.1.8.3 Analytic Requirements
Additional Actual Cost method needs to be added to existing v1.0 inventory value and gross margin
analytic capabilities. This BRD has a brief overview; for more details refer to the v1.1 BI and
Analytics BRD.
3.1.8.3.1 Inventory Value Analytics at Actual Cost
Add the ability to show inventory value at Actual Cost throughout our existing inventory value
analytics delivered in Fusion v1.0 for items using the Actual Cost – Cost Profile.
.How can the organization more efficiently use working capital (money).
Key Question
The total capital (money) invested in inventory, what the inventory being held
Key Answer is now worth
Display
Period
Yes
Information Available
Influence decisions to improve uses of working capital (money).
Resulting Action
Additional Information
3.1.8.3.2 Gross Margins Using Actual Cost
Add the ability to show gross margins using Actual Cost throughout our existing gross margin
analytics delivered in Fusion v1.0 for items using the Actual Cost – Cost Profile. Users should be
able to use these analytics to understand their true gross margins and be able to drill into true and
real cost detail and transaction level details for determining what actions will improve product
profits.
How can the organization improve profits?
Key Question
How much gross margin the various stratifications of products are producing
Key Answer for the organization.
Display
Period
Yes/No
Influence product design, distribution, sales, and sourcing strategies and
Resulting Action tactics to produce better profits for the organization.
3.1.8.4 User Interface Examples

[Description &/or examples of user interface, based on mock-ups/prototypes or competitive
screenshots]
User Cost Adj UI. This UI should let users add cost elements to an item layer and make adjustments
to cost elements of an item layer. It differs a little from perpetual average cost adjustments, in that
adjustments are made to individual layers rather than a single average cost which spans many layers.
The adjustment UI should capture user information for audit trail. The UI should allow user to select
a reason code which could be used as an attribute in the SLA accounting rules; different reasons
might require slightly different accounting treatments.
Review Item Costs for Actual Costing UI. For any given item whether or not the item is using an
Actual, Standard, or Average cost method, it should be possible for users to see the actual purchase
cost history (including “purchases” from other warehouses – transfers). Actual cost purchase history
is available regardless of the cost accounting method. Additionally users should be able to see the
current layers on hand and the actual cost of each layer and by cost element. It could potentially be a
separate UI from the Average Cost UI, or just a separate tab on a common Item Cost Inquiry UI.
3.1.8.5 Integration Requirement
3.1.8.5.1 Integration Requirement Name
No new requirement. This extends the base v1.0 architecture. Outbound Integration with Business
Intelligence. Some calculations will need to be extended or adjusted.
Add another section for Cost Service at valuation unit level Move this to FDD.
Outbound
Direction
Yes
Asynchronous
BI products
Expected Consumers
Consuming Process
Industry Standard
3.1.8.6 Performance Requirements

3.1.8.6.1 Background Processing engine
The solution needs to support medium to large customers. This is a background processing engine.
We can assume that typically customers will process their accounting for transactions on a daily
basis in a processing “window” that is within the day’s slow period, such as during the night, where
this process won’t compete for computing resources needed by real time user and customer facing
applications and business flows. However, we should also anticipate that as the world becomes more
connected, global and online, more and more businesses are operating 24/7 and the window of slow
time is shrinking. We will need to architect our solutions so the processing can be offloaded to
database servers that won’t be competing with customer facing business flows for computing
resources.
Average Customer Large Customer
Online: Number of
Concurrent Users
Online: Transaction
Volume
Online: Expected
Response Times
100,000 transactions per day 1,000,000 transactions per day
Batch: Average Batch
Size
20 min. 2 hours
Batch: Maximum
Process Time
Daily Daily
Batch: Frequency
3.1.8.7 Dependencies and Impacts
Dependencies and Impacts Instructions

This BRD isolates the solution to the Cost Management application. No impacts to other product
areas are identified.
3.1.8.7.1 Dependencies
Dependency On (Product) Description Related Related Use

Requirement(s) Case(s)
3.1.8.7.2 Impacts
Impact To (Product) Description Related Related Use

BI Products Add Actual Cost to all BI

products
3.2 Out of Scope Requirements
3.2.1 Costing Lots
3.2.1.1 Requirement Description

Costing Only Lots is not covered in this BRD. It may be a separate BRD to be included in an
undetermined future release.
Costing Only Lots is the scenario where the lot is not tracked within the inventory system but the
costs are tracked by lot in the costing system. For example, there may be a special order for a part
that was ordered at high volume with discounts for a particular customer. The part is exactly the
same part that many other customers use as well. Assume 100 was ordered special for a customer at
a discounted price of $9 each. But there are also 20 other units in stock of the same part that all
other customers can order too and those cost $10 each because there were not special ordered. When
a customer orders that part, inventory simply depletes 1 unit from the 120 onhand (they all look
exactly the same) and the cost of that sale would be reported at $10 each. But, when the special
customer orders their 100 units, again, inventory would deplete any of the remaining 119 to satisfy
that order (they all look exactly the same), but the cost of that sale would be reported at $9 each.

Must Have, Should Have, Nice to Have
Priority
Source(s)
Source Details
Reference System ID
Target Region(s)
Target Country/ies
Target Roles
3.2.1.3 Analytic Requirements

3.2.1.3.1 Analytic Requirement Name
[Description of analytic requirement]
Key Question
Key Answer
Display
Period
Yes/No
Resulting Action
3.2.1.4 User Interface Examples

[Description &/or examples of user interfaces, based on mock-ups/prototypes or competitive
screenshots]
3.2.1.5 Integration Requirement
3.2.1.5.1 Integration Requirement Name
[Description of integration requirement]

Inbound/Outbound
Direction
Yes/No
Asynchronous
Expected Consumers
Consuming Process
Industry Standard
3.2.1.6 Performance Requirements
3.2.1.6.1 [Performance Requirement Name]
[Description of Performance Requirement]
Average Customer Large Customer
Online: Number of
Concurrent Users
Online: Transaction
Volume
Online: Expected
Response Times
Batch: Average Batch

Size
Batch: Maximum
Process Time
Batch: Frequency
3.2.1.7 Dependencies and Impacts
Dependencies and Impacts Instructions

3.2.1.7.1 Dependencies
Dependency On (Product) Description Related Related Use

3.2.1.7.2 Impacts
Impact To (Product) Description Related Related Use

4. Issues
Issues Instructions
4.1 Open Issues
4.1.1 Issue [LIFO]

Related Features
Date Raised
Priority High
Medium
Low
Owner
Raised by
Interested Parties
Target Date
LIFO is becoming less prominent. We are only doing a basic LIFO method, but there may be
country specific requirements with target market potential that we are not addressing in this BRD.
Those country specific requirements will probably be covered in a separate BRD document as the
opportunities become prioritized.
4.2 Closed Issues
4.2.1 Issue [Name, Number]

Related Features
Date Raised
Priority High
Medium
Low
Owner
Raised by
Interested Parties
Target Date
Date Closed
[Include issue description and resolution here]
4.3 Managed Exceptions
4.3.1 Issue [Name, Number]

Related Features
Date Raised
Priority High
Medium
Low
Owner
Raised by
Interested Parties
Date Exception Approved
BugDB ID
[Include issue description and follow up actions]
5. Appendix: Actual Cost - Use Case Example
Use Case Basis:
 Three receipts into inventory, into two different "valuation units" (see definition in Glossary)
 One shipment out of one of the valuation units that will need to consume from two of the receipt transactions to be
satisfied
 A cost adjustment due to a difference between what AP pays vendor and PO estimate of cost
 Inventory value is at the actual cost of each receipt
 Cost of Goods Sold is at the actual cost of the receipts consumed to satisfy the sale.
 The sum of debits and credits to inventory equals the sum of: [quantity on hand of each receipt transaction
multiplied by the current actual cost of each receipt transaction]
High Level Example of Business Object Flow and Tracking. High level business results and proof.
Appendix Instructions

Fusion Costing BRD

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Fusion Costing BRD

Hochgeladen von

Copyright:

Verfügbare Formate

BUSINESS REQUIREMENTS DOCUMENT

Author: Gerald Goodbody

Creation Date: 9/2/2009 7:20 PM

Last Updated: 12/10/2009 11:31 PM

Detailed Business Process: Product Management – Manage Cost Accounting

Business Process Activity: Record Cost Accounting

Business Process Tier: Cross Industry

Project ID: <RPS Project ID>

File URL: http://files.oraclecorp.com/…

Document Version: 3.0

Status: IN DRAFT, REVIEW FEEDBACK INCORPORATED, READY FOR APPROVAL,

Template Version: 1.5

Copyright  2019 Oracle Corporation

Shyam Santhanam Product Management

Michel Bazinet Strategy

5. Appendix: <Appendix Name>_________________________________________________________14

1.2 Market and Competitive Analysis

 Actual costing can be a tremendous savings on administrative costs. As opposed to

 Actual cost is a very a robust, reliable, self correcting approach, as opposed to

 GAAP Regulatory requirement

Good and Bad of Apps Unlimited Solutions:

Guiding Vision for Fusion

1.3 Requirement Use Case(s)

1.3.1 Use Case Information

1.3.2 Use Case

Actual Costing for Purchased Items

Business Process Diagram

1.6 Customer Validation

Customer Validation Instructions

[If section not applicable, indicate so and provide a reason]

2.1 Terms specific to BRD consumption/comprehension

Item – An inventory item.

[If section not applicable, indicate so and provide a reason]

3.1 In Scope Requirements

3.1.1 Forward Flow Actual Costing for User defined levels

3.1.1.1 Requirement General Information

Secondary Target Industry/ies

3.1.2 Adjustments from AP, PO, and User Cost Adjustments

3.1.2.1 Requirement General Information

Secondary Target Industry/ies

3.1.3 Reverse Flows

3.1.3.1 Requirement General Information

Secondary Target Industry/ies

3.1.4 Negative Inventory

3.1.4.1 Requirement General Information

Secondary Target Industry/ies

3.1.5 Backdated Transactions / Cost Cutoff

3.1.5.1 Requirement General Information

Secondary Target Industry/ies

3.1.6.1 Requirement General Information

Secondary Target Industry/ies

3.1.7 Tracking costs through inter-organization transfers

3.1.7.1 Requirement General Information

Secondary Target Industry/ies

3.1.8.1 Requirement Business Process Proposed Task Description

3.1.8.2 Requirement General Information

Secondary Target Industry/ies

3.1.8.3.1 Inventory Value Analytics at Actual Cost

3.1.8.3.2 Gross Margins Using Actual Cost

3.1.8.4 User Interface Examples

3.1.8.5 Integration Requirement

3.1.8.5.1 Integration Requirement Name

3.1.8.6 Performance Requirements

3.1.8.6.1 Background Processing engine