Cost Date - Transaction Date - Accounting Date
Cost Date - Transaction Date - Accounting Date
Fusion CST: FAQ Cost Cutoff Date - Cost Date - Transaction Date- Accounting Date (Doc ID To Bottom
1304094.1)
Purpose Yes
Questions and Answers No
What are various "dates" in costing and what is the significance of each of these ?
What is the Cost Cutoff Date? Document Details
How to use cost cutoff date options?
What are backdated transactions? Type:
Status: FAQ
Why did my transaction costing date move to a future date from the transaction date in inventory ? PUBLISHED
Last Major
Backdating of Transactions: Examples Update: 07-May-2020
Last 06-Jul-2023
Why is my cost date not same as my Accounting Date in GL for the journals and cost distributions displayed on Review Cost Update: English
Accounting Distributions? Language:
Related Products
APPLIES TO:
Oracle Fusion Cost
Management
Oracle Fusion Cost Management - Version 11.1.11.1.0 and later
Oracle Fusion Cost
Oracle Fusion Cost Management Cloud Service - Version 11.13.19.07.0 to 11.12.1.0.0 [Release 1.0]
Management Cloud
Information in this document applies to any platform.
Service
PURPOSE
Information Centers
This FAQ is intended to address the cost cutoff date option, backdated transactions, and the costing date of transactions. Information Center:
Fusion Applications
Supply Chain
QUESTIONS AND ANSWERS Management [108.2]
When the cost processors are run, users specify the cost cutoff date option and the cutoff date for all cost organization books
that are being processed. The cost cutoff date is the last day on which the cost processor will process transactions for an
accounting period. If you are consistently getting cost processor runs without any records, please check to see if the cost cutoff
date is in the past.
You can set the cutoff date option to User-Defined or Auto. The User-Defined option requires you to specify the cutoff date;
while the Auto option saves you the effort of redefining the cutoff date which is automatically moved forward by the cost
processor. Under the Auto option, the cost processor moves the cutoff date forward up to the last date of the earliest open cost
period, and then it stops until the period is closed. After the period is closed, the cost processor advances the cutoff date into
the next open period, and so on. However if a transaction is successfully preprocessed after the cutoff date, then the cutoff date
for that cost organization book moves forward to the date of the last successfully preprocessed transaction; this could happen,
for example, if the cutoff date option was originally set to User-Defined and subsequently changed to Auto.
One of the purposes of the cost cutoff date is to allow backdating of transactions. For example, if you set the cost cutoff date to
October 31, you can still process October transactions that were entered in November for the period ending October 31 by
backdating them to October 31 or earlier. However, when the cost cutoff date advances forward to a date past October 31, the
transactions can no longer be backdated to October 31 or earlier, and they are processed with the forward date. If you set a cost
cutoff date at October 31, the cost processor will queue up but not process any transactions with a date after October 31. If you
subsequently need to backdate transactions to a date before October 31, you can process these transactions before any
transactions with dates of November 1 and beyond. You can also backdate transactions to any date after October 31, with the
assurance that these transactions will be processed in the correct order when the cost cutoff date moves forward.
Why did my transaction costing date move to a future date from the transaction date in inventory ?
SCENARIO 1 The cost date can be different from the transaction date and moved to a future date, if there is no onhand in the
valuation unit and the transaction is a issue transaction and the cost profile setup allows "negative onhand inventory" to Always.
For example you are processing a sales order issue transaction before you have onhand in the inventory, then this transaction
costing will be put on hold and once the onhand is received later , the transaction will be cost processed and the costing date of
the transaction will be equal to the receipt leg of the arriving onhand. In these cases the cost processor will show a warning
message with "Issue transaction is fully costed but not yet fully depleted due to unresolved negative inventory quantities". If the
cost profile is set to never enable negative onhand , then the transaction will error in cost processing with message : "Issue
transaction was put on hold to avoid generating negative inventory"
After costing processes it and posts the transactions to GL, the Accounting date will be in UTC ( on display UI as well as in db)
and the period
SCENARIO wll be July
2 Inventory and not August.
transaction date will consider the user preferred timezone and will display all dates in User timezone .
however , costing does not consider this since these are accounting data, this will show only in the server timezone. This gives a
[illusion
In future, release 13date
of transaction and being
more),different
it is planned
from to provide
costed a option
date, to pick
however this
in the preferred
database bothtimezone at thewill
these dates legal
be entitiy
stored level
in theand
period start and end
server timezone. Thedates alongiswith
difference costing
merely onlydate andUI.
on the accounting date
This might will consider
mislead the userthis
intowhen displaying
thinking dates] accounted
the transaction
with a different date than what was expected.
SCENARIO 3 :
Example
Transaction date in inventory was created as back dated transaction with expectation that costing will process these transactions
with the
User transaction
timezone date entered
is in CHINA. in Inventory.
User Preferred timezone is set to Beijing time. Server timezone is UTC.
however, before
User creates the creation
a transaction at of this AM
05:00 transaction
August 1stcosting already
Beijing time, processed
for user thea transaction
expectationwith date
is that thelater to the entered
transaction is created in the
transaction
new Augustdate. Due
period. to this
After reason and
transaction becasue
is saved, thecosting can only
transaction dateprocesses
shows thetransactions
time in usersequentially and in layers,
preferred timezone though
and shows thethe
transaction
transaction date
date is
asin1st
the past, 5
August the costing
AM. Howeverwill give it adatabase,
on the cost dateinventory
that is later to the
stores thetransaction
transactiondate
dateafter
as 9 all
PMthe
Julycurrent
after existing
cost dates for
converting the item/valuation
to UTC, unit related
which is techincally cost
still July layers.
period.
Reivew
The userItem Costs Ui
preferred will givedisplay
timezone this "last
for use cost date"
transaction information
date whichinto
confuses users might help users
believing understandiswhat
the transaction mightinbenew
recorded theperiod
cost
date for a given back dated
however this is not the case. transaction date in inventory.
Review below section ofr Backdating of transactions and cost date derivation logic in more detail.
transaction was put on hold to avoid generating negative inventory
After costing processes it and posts the transactions to GL, the Accounting date will be in UTC ( on display UI as well as in db)
and the period
SCENARIO wll be July
2 Inventory and not August.
transaction date will consider the user preferred timezone and will display all dates in User timezone .
however , costing does not consider this since these are accounting data, this will show only in the server timezone. This gives a
[illusion
In future, release 13date
of transaction and being
more),different
it is planned
from to provide
costed a option
date, to pick
however this
in the preferred
database bothtimezone at thewill
these dates legal
be entitiy
stored level
in theand
period start and end
server timezone. Thedates alongiswith
difference costing
merely onlydate andUI.
on the accounting date
This might will consider
mislead the userthis
intowhen displaying
thinking dates] accounted
the transaction
with a different date than what was expected.
SCENARIO 3 :
Example
Transaction date in inventory was created as back dated transaction with expectation that costing will process these transactions
with
User the transaction
timezone date entered
is in CHINA. in Inventory.
User Preferred timezone is set to Beijing time. Server timezone is UTC.
however, before
User creates the creation
a transaction at of this AM
05:00 transaction
August 1stcosting already
Beijing time, processed
for user thea transaction
expectationwith date
is that thelater to the entered
transaction is created in the
transaction date. Due to this reason and becasue costing can only processes transactions sequentially
new August period. After transaction is saved, the transaction date shows the time in user preferred timezone and in layers, though
and shows thethe
transaction
transaction date
date is
asin1st
the past, 5
August the costing
AM. will give
However it adatabase,
on the cost dateinventory
that is later to the
stores thetransaction
transactiondate
dateafter
as 9 all
PMthe current
July after existing
cost dates for
converting the item/valuation
to UTC, unit related
which is techincally cost
still July layers.
period.
Reivew
The userItem Costs Ui
preferred will givedisplay
timezone this "last
for use cost date"
transaction information
date whichinto
confuses users might help users
believing understandiswhat
the transaction mightinbenew
recorded theperiod
cost
date for athis
however given back
is not thedated
case.transaction date in inventory.
Review below section ofr Backdating of transactions and cost date derivation logic in more detail.
By setting the cost cutoff date for a cost accounting period, you can manage which transactions are processed in that period,
including backdated transactions. The following examples illustrate how the cost processor sets the accounted date for
backdated transactions.Assume that the current date is November 2, the cost cutoff date is October 31, and the following costed
and uncosted transactions are in process:
Below, the inventory transaction is backdated to position A. The transaction will be costed with accounting date B before the
transactions 2 and 3 are processed.
Below, the inventory transaction is backdated to position C. The transaction will be costed with accounting date C after the
transactions 2 and 3 are processed.
Below, the inventory transaction is backdated to position C. The transaction will be costed with accounting date C after the
transactions 2 and 3 are processed.
Below, the inventory transaction is backdated to position D. The transaction will be costed with accounting date D after the cost
cutoff is moved past October 31.
Why is my cost date not same as my Accounting Date in GL for the journals and cost distributions displayed on
Review Cost Accounting Distributions?
Cost date derivation logic is independent on current cost period status. However the accounted date is dependent on the GL
period status. The current open GL period and the current open Costing period need not be the same.
If the current GL period is closed, then cost processor will simply move the GL_date on the distribution to a open GL period. This
can be a past period or a future period for give transaction date.
Costing only requires that atleast one open Costing and GL period exist when ever distributions are processed and posted.
So if the current
OracleGL period
Cloud is closed
> Oracle and futureGL
Software Cloud >period
OracleisEnterprise
open, costing will sweep
Resource the distribution
Planning GL date
Cloud > Oracle to Cost
Fusion first day of this
Management Cloud Service > Cost
open period.
Management > Costing UI and Dashboard
DueKeywords
to this there will be a mismatch between Cost Date and GL date which is nothing but the Accounted date when SLA
processes
ACCOUNTING;
these transactions
ACCOUNTING
takingPERIODS;
the GL date
BACKDATED;
passed by Cost
COSTING;
Processor.
CREATE COST ACCOUNTING DISTRIBUTIONS; CURRENT PERIOD; CUTOFF DATE; DATE
FROM; DATES; DISTRIBUTION; FIRST PERIOD; FUTURE; GL DATE; GL_DATE; PERIOD STATUS; REVIEW COST ACCOUNTING DISTRIBUTIONS; SUBLEDGER;
Hence it is important
SWEEP; that any
TRANSACTION; GL and Costing Period be open when cost processes processes a transaction. This will help the
UNACCOUNTED
processesor to derive a GL date. Else the records will remain unprocessed and in error state with specific errors messages on the
Translations
processor log reporting that GL period is closed. or Costing period is closed.
English Source Japanese 日本語
If no open period exist, processor will error with
Cost period
Back not open - if no costing period can be found
to Top
Copyright
and GL period not open - if no GL period can (c) 2023, Oracle. All rights reserved.
be found. Legal Notices and Terms of Use Privacy Statement
Didn't find what you are looking for? Ask in Community...
Related
Products
Oracle Fusion Applications > Supply Chain Management > Cost Management > Oracle Fusion Cost Management > Cost Processing > Create Cost
Accounting Distributions
So if the current
OracleGL period
Cloud is closed
> Oracle and futureGL
Software Cloud >period
OracleisEnterprise
open, costing will sweep
Resource the distribution
Planning GL date
Cloud > Oracle to Cost
Fusion first day of this
Management Cloud Service > Cost
open period.
Management > Costing UI and Dashboard
DueKeywords
to this there will be a mismatch between Cost Date and GL date which is nothing but the Accounted date when SLA
processes
ACCOUNTING;
these transactions
ACCOUNTING
takingPERIODS;
the GL date
BACKDATED;
passed by Cost
COSTING;
Processor.
CREATE COST ACCOUNTING DISTRIBUTIONS; CURRENT PERIOD; CUTOFF DATE; DATE
FROM; DATES; DISTRIBUTION; FIRST PERIOD; FUTURE; GL DATE; GL_DATE; PERIOD STATUS; REVIEW COST ACCOUNTING DISTRIBUTIONS; SUBLEDGER;
Hence it is important
SWEEP; that any
TRANSACTION; GL and Costing Period be open when cost processes processes a transaction. This will help the
UNACCOUNTED
processesor to derive a GL date. Else the records will remain unprocessed and in error state with specific errors messages on the
Translations
processor log reporting that GL period is closed. or Costing period is closed.
English Source Japanese 日本語
If no open period exist, processor will error with
Cost period
Back not open - if no costing period can be found
to Top
Copyright
and GL period not open - if no GL period can (c) 2023, Oracle. All rights reserved.
be found. Legal Notices and Terms of Use Privacy Statement
Didn't find what you are looking for? Ask in Community...
Related
Products
Oracle Fusion Applications > Supply Chain Management > Cost Management > Oracle Fusion Cost Management > Cost Processing > Create Cost
Accounting Distributions