Basic Changes:
Functional design
1. Set Of Books is replaced by the term Ledger.
2.
Accounting entries for transactions happening in all the applications
such as Purchasing,Cost Management,Payables will go to General Ledger
through a common module called "Subledger Accounting (SLA)" which is
introduced in R12 and accounting entries can be viewed at SLA menu.
3. Accounting entries can be created manually at SLA level and can be transferred to General Ledger by running the program 'Transfer to GL'.
4. SLA gives the flexibility to derive the accounts using Account Derivation Rules for the transactions happening in the Procure to Pay cycle and the accounting entries using those derived accounts can be transferred to General Ledger. Also it gives the flexibility to modify the journal category as Receiving/Accrual/Inventory for the event classes such as Period end accrual,Receipt into Receiving Inspection,PO Delivery into Inventory and so on.
3. Accounting entries can be created manually at SLA level and can be transferred to General Ledger by running the program 'Transfer to GL'.
4. SLA gives the flexibility to derive the accounts using Account Derivation Rules for the transactions happening in the Procure to Pay cycle and the accounting entries using those derived accounts can be transferred to General Ledger. Also it gives the flexibility to modify the journal category as Receiving/Accrual/Inventory for the event classes such as Period end accrual,Receipt into Receiving Inspection,PO Delivery into Inventory and so on.
5.
SLA has the option to generate the accounting entries for respective
subledgers in Draft mode or Final mode. Accounting entries can be
created in Draft mode first in SLA which is a rough or draft entry to
see whether the journal needs any modification in terms of account code
or journal category. These draft entries will not get transferred to GL
at any point of time. If any modification is required, it can be done
using the features available in SLA and the accounting entries can be
created in Final mode once the user feels that the journals do not need
any modification. When the entries get created in Final mode in SLA, it
will override the entries already created in Draft mode and these final
mode entries alone will get transferred to GL.
5.
The concept of Secondary Ledger has been introduced so that you can
have two different accounting methods set at ledger level, for eg;
Accrual basis accounting method for Primary ledger and Cash basis
accounting method for Secondary ledger, and the ledgers can have
different chart of accounts/currencies/calenders. Actual and
Encumbrance entries in the Procure to Pay cycle can be generated in
secondary ledger also along with the entries in Primary ledger.
Technical design
1. The column set_of_books_id has been replaced with ledger_id in GL Tables
2.
As a part of Subledger Accounting, new SLA tables XLA_AE_HEADERS,
XLA_AE_LINES and XLA_DISTRIBUTION_LINKS have been introduced through
which the accounting entries flow to GL.
3.
PO details will not available in reference
columns(reference_1,reference_2...) in tables GL_JE_LINES and
GL_BC_PACKETS. Hence accounting entries in these tables can be retrieved
only using SLA tables and GL_IMPORT_REFERENCES table.
4. Receiving Subledger/Inventory subledger/Payables subledger is not directly linked to table GL_JE_LINES,instead it is linked through the subledger tables XLA_AE_HEADERS, XLA_AE_LINES and XLA_DISTRIBUTION_LINKS.
5. XLA_AE_LINES table is mapped to GL_IMPORT_REFERENCES table with the gl_sl_link_id and gl_sl_link_table columns. The linking columns between GL_IMPORT_REFERENCES and GL_JE_LINES tables are je_header_id and je_line_num.
4. Receiving Subledger/Inventory subledger/Payables subledger is not directly linked to table GL_JE_LINES,instead it is linked through the subledger tables XLA_AE_HEADERS, XLA_AE_LINES and XLA_DISTRIBUTION_LINKS.
5. XLA_AE_LINES table is mapped to GL_IMPORT_REFERENCES table with the gl_sl_link_id and gl_sl_link_table columns. The linking columns between GL_IMPORT_REFERENCES and GL_JE_LINES tables are je_header_id and je_line_num.
Setting up of Encumbrance:
Defining the Subledger Accounting Method:
Defining the Subledger Accounting Method:
Navigation:
General Ledger>Set up>Financials>Accounting Set up Manager>Accounting Set ups
Query the ledger and you can find the option for setting up the Subledger Accounting Method
Subledger Accounting Method is having the option of
General Ledger>Set up>Financials>Accounting Set up Manager>Accounting Set ups
Query the ledger and you can find the option for setting up the Subledger Accounting Method
Subledger Accounting Method is having the option of
a) Standard Accrual
b) Encumbrance Accrual
c) Standard Cash
d) Encumbrance Cash
b) Encumbrance Accrual
c) Standard Cash
d) Encumbrance Cash
If
Encumbrance needs to be enabled, then the Subledger Accounting Method
has to be set as "Encumbrance Accrual" in case of Accrual basis
accounting method or "Encumbrance Cash" in case of cash basis accounting
method for the ledger.
If Encumbrance is not used, then the Subledger Accounting Method has to be set as "Standard Accrual" or "Standard Cash" for the ledger.
Difference in Behavior between 11i and R12:
1. In 11i, Encumbrance related set ups include enabling the Budgetary control flag for the set of books, defining the Reserve for Encumbrance a/c, enabling the encumbrance for REQ,PO and INVOICE in Financial Options.
Where as in R12, Subledger Accounting Method has to be set for the ledger in addition to other set ups done in 11i. If it is set to "Standard Accrual", Encumbrance cannot be used for that ledger even though the Encumbrance is enabled for the REQ,PO and INVOICE in Financial Options.
If Encumbrance is not used, then the Subledger Accounting Method has to be set as "Standard Accrual" or "Standard Cash" for the ledger.
Difference in Behavior between 11i and R12:
1. In 11i, Encumbrance related set ups include enabling the Budgetary control flag for the set of books, defining the Reserve for Encumbrance a/c, enabling the encumbrance for REQ,PO and INVOICE in Financial Options.
Where as in R12, Subledger Accounting Method has to be set for the ledger in addition to other set ups done in 11i. If it is set to "Standard Accrual", Encumbrance cannot be used for that ledger even though the Encumbrance is enabled for the REQ,PO and INVOICE in Financial Options.
2.
In 11i, there is an option to choose different encumbrance types for
REQ,PO and INVOICE in Financial options but in R12, Financial options
does not have the LOV to choose the encumbrance type. By default,
Requisition encumbrance will be "Commitment", PO encumbrance will be
"Obligation" and invoice encumbrance will be "INVOICE". If any of these 3
encumbrance types is not enabled in GL > Set up > Journal >
Encumbrance, then the respective document REQ/PO/Invoice will throw
budgetary control exception and will fail funds check.Generation of Encumbrance Entries:
Functional design
On
Reserving and Approving the Requisition(PR)/Purchase Order(PO),
Encumbrance amount gets reflected in Funds Inquiry screen and the
encumbrance entries can be viewed in SLA menu in Purchasing module.
Navigation:
Purchasing>Accounting>SLA:User Main Menu>Accounting events
Query by transaction dates,ledger name and transaction number which is the PR/PO number
Following Accounting entries will be available in the HTML page
Budget a/c DR
Reserve For Encumbrance CR
Purchasing>Accounting>SLA:User Main Menu>Accounting events
Query by transaction dates,ledger name and transaction number which is the PR/PO number
Following Accounting entries will be available in the HTML page
Budget a/c DR
Reserve For Encumbrance CR
There
is an option to do funds check before taking the RESERVE and APPROVE
action on the PR/PO by navigating to Tools > Check funds in
Requisitions and Purchase Order forms to see the funds check behavior
before approving the PR/PO. This funds check activity will create a
draft entry in SLA and once the document is reserved, encumbrance entry
will get created in Final mode overriding the draft entry already
created for the "Check funds" action. If the funds check fails due to
insufficient funds on taking the RESERVE action, entries will get
created with Invalid status in SLA.
The
Concurrent Request "Transfer Journal Entries to GL" has to be submitted
from Purchasing Responsibility to create the encumbrance entries in GL.
On running this request, encumbrance entries created in Final mode
alone will get transferred to GL.
Difference in Behavior between 11i and R12:
1.
In 11i, encumbrance entries will get transferred to GL by running the
concurrent program "Program-Create Journals" from GL responsibility. But
in R12, "Transfer Journal Entries to GL" has to be submitted from
Purchasing Responsibility to create the encumbrance entries in GL.
2.
In 11i, it is not possible to view the encumbrance entries in
Purchasing module, where as in R12, the entries can be viewed from SLA
menu in Purchasing.
3. In 11i, a credit against the Reserve For Encumbrance a/c (RFE) can be seen only at the time of posting the Encumbrance debit entry in GL. But in R12, RFE a/c gets credited along with the budget a/c debit entry which can be viewed from SLA menu in Purchasing.
3. In 11i, a credit against the Reserve For Encumbrance a/c (RFE) can be seen only at the time of posting the Encumbrance debit entry in GL. But in R12, RFE a/c gets credited along with the budget a/c debit entry which can be viewed from SLA menu in Purchasing.
Technical design
On
reserving and approving the PR/PO, encumbrance entries get generated in
table GL_BC_PACKETS with column source_distribution_type as
'PO_REQ_DISTRIBUTIONS_ALL' for PR and 'PO_DISTRIBUTIONS_ALL' for PO and
column source_distribution_id_num_1 as req distribution id for PR and po
distribution id for PO.
Encumbrance entries will also get generated in the table PO_BC_DISTRIBUTIONS which has been newly introduced in R12. This table has the columns 'reference4' and 'reference3' columns where the PO/PR number and distribution id gets populated.
These accounting entries are also populated in the table XLA_AE_LINES. The table XLA_AE_HEADERS will show whether the encumbrance entry is created in Draft mode or Final mode or Invalid mode indicated by the column accounting_entry_status_code and it will also show whether the entry is transferred to GL or not indicated by the column gl_transfer_status_code.
Encumbrance entries will also get generated in the table PO_BC_DISTRIBUTIONS which has been newly introduced in R12. This table has the columns 'reference4' and 'reference3' columns where the PO/PR number and distribution id gets populated.
These accounting entries are also populated in the table XLA_AE_LINES. The table XLA_AE_HEADERS will show whether the encumbrance entry is created in Draft mode or Final mode or Invalid mode indicated by the column accounting_entry_status_code and it will also show whether the entry is transferred to GL or not indicated by the column gl_transfer_status_code.
The tables PO_BC_DISTRIBUTIONS and XLA_AE_HEADERS are linked with the column 'event_id'.
The tables XLA_AE_HEADERS and GL_BC_PACKETS are linked with the column 'ae_header_id'.
The tables XLA_AE_HEADERS and XLA_AE_LINES are linked with the column 'ae_header_id'.
The tables XLA_AE_HEADERS and GL_BC_PACKETS are linked with the column 'ae_header_id'.
The tables XLA_AE_HEADERS and XLA_AE_LINES are linked with the column 'ae_header_id'.
Once
the entries are populated in GL and those entries are posted, records
from the table GL_BC_PACKETS will get deleted but the entries in
table PO_BC_DISTRIBUTIONS will remain always.
Difference in Behavior between 11i and R12:
In 11i, Encumbrance entries created in GL_BC_PACKETS will be directly moved to GL_JE_LINES by running the CJE program, whereas in R12, Encumbrance entries gets generated in a new table PO_BC_DISTRIBUTIONS and also in XLA tables in addition to GL_BC_PACKETS.
In 11i, Encumbrance entries created in GL_BC_PACKETS will be directly moved to GL_JE_LINES by running the CJE program, whereas in R12, Encumbrance entries gets generated in a new table PO_BC_DISTRIBUTIONS and also in XLA tables in addition to GL_BC_PACKETS.
Receipt Accounting:
As mentioned earlier, accounting entries for transactions happening in Receiving subledger and inventory subledger will flow to GL only through SLA which involves a new process called "Create Accounting process".
As mentioned earlier, accounting entries for transactions happening in Receiving subledger and inventory subledger will flow to GL only through SLA which involves a new process called "Create Accounting process".
Create Accounting process for Online Accruals:
When
purchase order is set to accrue at receipt, accounting entries get
created in Receiving subledger once the receiving transactions are done.
Then the Create Accounting process should take place to create journals
in SLA accompanied by Transfer to GL process and posting which are
optional. Users can choose whether they want the journal import and
posting also to happen at the same time when the create accounting
process is done or the Transfer to GL/Posting can be done explicitly.
But if encumbrance is enabled, it is always preferred to do the Transfer
to GL and Posting along with the create accounting process by having
the values for parameters 'Transfer to GL' and 'Posting in GL' as YES
while submitting the create accounting program. For more details on
this, please refer to Note.728064.1.
Another main implication of this model of doing the GL transfer and
posting along with create accounting process in one shot is that, on
failure of Journal Import, the data will be rolled back to SLA tables
and hence there will not be any data in GL interface.
This
Create Accounting Process involves two concurrent programs Create
Accounting-Receiving which can be submitted from Purchasing>View
Requests or from Cost Management Responsibility > SLA menu >
Create Accounting and Create Accounting-Cost Management which can be
submitted from Cost Management Responsibility > SLA menu. "Create
Accounting - Receiving" only accounts for Expense destination PO
Receipt. "Create Accounting - Cost Management" accounts for all
transactions costed by EBS Cost Management, which includes:
- Expense destination PO Receipt
- All Inventory transactions including inventory destination POs
- WIP transactions
- Accrual Write Off transactions
- All Inventory transactions including inventory destination POs
- WIP transactions
- Accrual Write Off transactions
Parameters used while submitting the Create Accounting concurrent program:
- Ledger - Ledger (SOB) name to be given
- End date - Accounting entries to be created for all receipts TO DATE
a) Draft - Draft mode creates the SLA journals as Draft which can be modified. Hence these entries will not get transferred to General Ledger and it will be available only in SLA. Once the entries created in Draft mode are verified and confirmed, Create Accounting program has to be run in Final mode and the entries getting created now will override the draft entries in SLA and will get transferred to General Ledger.
b) Final - Final mode creates SLA journals which can not be modified and can be transferred to General Ledger. - Report - Options available are Detail or Summary
- Transfer to General Ledger - Yes or No - If the mode is set to Final and the value for this parameter is set to No, then the accounting entries will get created only in SLA table and it will not be available in gl_interface or GL. You need to submit the program "Transfer to Gl" in Cost Management Responsibility > SLA to transfer the entries created in Final mode from SLA to General Ledger.
- Post in General Ledger - Yes or No
a) Online Accruals with Expense destination:
Functional design
When the PO which is set to accrue at receipt is received and delivered to expense destination, Receipt Accounting happens in Receiving subledger. Then the Create Accounting process has to be submitted to generate the receipt accounting in SLA and GL.
This receipt accounting includes encumbrance reversal entries if the PO is encumbered, otherwise it just includes the actual entries. These entries can be viewed in SLA menu in Cost Management module.
Functional design
When the PO which is set to accrue at receipt is received and delivered to expense destination, Receipt Accounting happens in Receiving subledger. Then the Create Accounting process has to be submitted to generate the receipt accounting in SLA and GL.
This receipt accounting includes encumbrance reversal entries if the PO is encumbered, otherwise it just includes the actual entries. These entries can be viewed in SLA menu in Cost Management module.
Navigation:
Cost Management,SLA > SLA >SLA: Inquiry > Accounting event
Query by transaction dates and ledger name
Following Accounting entries will be available in the HTML page
Cost Management,SLA > SLA >SLA: Inquiry > Accounting event
Query by transaction dates and ledger name
Following Accounting entries will be available in the HTML page
AP Accrual a/c CR
Receiving Inspection a/c DR
Charge a/c DR
Receiving Inspection a/c CR
Receiving Inspection a/c DR
Charge a/c DR
Receiving Inspection a/c CR
If encumbrance is enabled, encumbrance reversal also can be viewed as follows
Budget a/c CR
Reserve For Encumbrance DR
Budget a/c CR
Reserve For Encumbrance DR
These entries can also be viewed from Receiving Transaction Summary > View Accounting.
In
encumbrance enabled environment, once the receiving process is done,
Create Accounting process and posting in GL has to be completed in order
to get the encumbrance reversal and actuals to hit the GL funds inquiry
simultaneously as the funds availability calculation in Funds Inquiry
screen will consider the encumbrance reversal and actuals only when they
are posted in GL.
Note:
R12 SLA architecture does not have this design initially. This new
design is introduced by a patch which is explained in more detail in Note.728064.1 to maintain accurate funds availability for the budget account at any point of time.
Technical design
When
purchase order has Accrue on Receipt set to YES, Receiving Transaction
Processor generates the accounting entries in RCV_RECEIVING_SUB_LEDGER
upon Receipt and Deliver of the PO. Then the Create Accounting process
should take place to create SLA journals which will insert records in
XLA_AE_HEADERS, XLA_AE_LINES and XLA_DISTRIBUTION_LINKS. These
accounting entries will be available in the table XLA_AE_LINES. The
event type code in XLA_AE_HEADERS for this Encumbrance Reversal entry is
DELIVER_EXPENSE and the event type code in XLA_AE_HEADERS for these
actual entries will be RECEIVE for receipt accounting and
DELIVER_EXPENSE for delivery accounting.
The tables RCV_RECEIVING_SUB_LEDGER and XLA_DISTRIBUTION_LINKS can be linked using the column source_distribution_id_num_1. The value of rcv_sub_ledger_id has to be given as source_distribution_id_num_1 for the source_distribution_type "RCV_RECEIVING_SUB_LEDGER" in XLA_DISTRIBUTION_LINKS table.
The tables RCV_RECEIVING_SUB_LEDGER and XLA_DISTRIBUTION_LINKS can be linked using the column source_distribution_id_num_1. The value of rcv_sub_ledger_id has to be given as source_distribution_id_num_1 for the source_distribution_type "RCV_RECEIVING_SUB_LEDGER" in XLA_DISTRIBUTION_LINKS table.
b) Online Accruals with Inventory destination:
Functional design
When
the PO is received and delivered to inventory destination, Receipt
Accounting happens in Receiving subledger and Deliver Accounting happens
in inventory subledger. Then the Create Accounting process has to be
submitted to generate the receipt accounting and deliver accounting in
SLA and GL. This deliver accounting includes encumbrance reversal
entries if the PO is encumbered, otherwise it just includes the actual
entries.
View
Accounting from Receiving Transaction Summary will show the accounting
entries for RECEIVE transaction. To view the actual entries for DELIVER
transaction, navigate to Material Distributions form which will show the
accounting entries once the deliver transaction is costed. To view
these actual entries and Encumbrance Reversal entries in SLA after
create accounting process is done, navigate to
Cost Management Resp>SLA>Inquiry>Accounting event
Query by transaction dates and ledger name
Query by transaction dates and ledger name
Following Accounting entries will be available in the HTML page
AP Accrual a/c CR
Receiving Inspection a/c DR
Material Valuation a/c DR
Receiving Inspection a/c CR
Receiving Inspection a/c DR
Material Valuation a/c DR
Receiving Inspection a/c CR
If
encumbrance is enabled, encumbrance reversal also can be viewed as
follows provided the flag "Reverse encumbrance" is checked in
organization parameters > Costing tab.
Budget a/c CR
Reserve For Encumbrance DR
Budget a/c CR
Reserve For Encumbrance DR
In
encumbrance enabled environment, once the receiving process is done,
Create Accounting process and posting in GL has to be completed in order
to get the encumbrance reversal and actuals to hit the GL funds inquiry
simultaneously as the funds availability calculation in Funds Inquiry
screen will consider the encumbrance reversal and actuals only when they
are posted in GL.
Note:
This design related to encumbrance reversal and actuals hitting the
funds inquiry after posting is yet to be implemented which will be done
soon as this design is restricted only to expense destination POs and
not for inventory. As of now, for inventory destination POs, there is a
limitation in funds availability calculation where encumbrance reversal
hits the funds inquiry at the time of receipt and delivery where as
actuals hits the funds inquiry only at the time of posting the actual
entries in GL after the create accounting process. Therefore delaying
the create accounting process will result in incorrect funds
availability. This limitation will be overcome by introducing the same
design for inventory destination which is already done for expense POs.
Technical design
When
purchase order has Accrue on Receipt set to YES and
destination_type_code is set to Inventory, Receiving Transaction
Processor generates the accounting entries in RCV_RECEIVING_SUB_LEDGER
upon Receipt and Cost manager generates the accounting entries in
MTL_TRANSACTION_ACCOUNTS upon Deliver of the PO. Then the Create
Accounting process should take place to create SLA journals which will
insert records in XLA_AE_HEADERS, XLA_AE_LINES and
XLA_DISTRIBUTION_LINKS. These accounting entries will be available in
the table XLA_AE_LINES. The event type code in XLA_AE_HEADERS for this
Encumbrance Reversal entry is PO_DEL_INV and the event type code in
XLA_AE_HEADERS for these actual entries will be RECEIVE for receipt
accounting and PO_DEL_INV for delivery accounting.
The
tables MTL_TRANSACTION_ACCOUNTS and XLA_DISTRIBUTION_LINKS can be
linked using the column source_distribution_id_num_1. The value of
inv_sub_ledger_id has to be given as source_distribution_id_num_1 for
the source_distribution_type "MTL_TRANSACTION_ACCOUNTS".
Difference in Behavior between 11i and R12:
1. In 11i, Receiving Transaction Processor creates the Receipt Accounting entries in Receiving Subledger as well as in GL_INTERFACE. Journal Import will be done to transfer the entries to GL_JE_LINES where as in R12, Receiving Transaction Processor will create the entries only in Receiving Subledger. Create Accounting Program has to be run to create SLA journals which in turn will trigger the journal import.
1. In 11i, Receiving Transaction Processor creates the Receipt Accounting entries in Receiving Subledger as well as in GL_INTERFACE. Journal Import will be done to transfer the entries to GL_JE_LINES where as in R12, Receiving Transaction Processor will create the entries only in Receiving Subledger. Create Accounting Program has to be run to create SLA journals which in turn will trigger the journal import.
2.
In 11i, if encumbrance is enabled, encumbrance reversal and actuals
will undergo funds check when these entries are populated in
gl_interface and GL funds inquiry will reflect the encumbrance reversal
and actuals even before posting the entries in GL. But in R12,
encumbrance reversal and actuals will hit the GL funds inquiry only when
these entries are posted in GL even though funds check happens in SLA
itself.
c) Period End Accruals:
Functional design
When the PO which is set to accrue at period end is received and delivered to expense destination and Receipt Accruals Period End program is submitted, accounting entries get created in Receiving subledger during period end for the PO shipments which has the received quantity greater than billed quantity. Then the Create Accounting process has to be submitted to generate the receipt accounting in SLA and GL.
Functional design
When the PO which is set to accrue at period end is received and delivered to expense destination and Receipt Accruals Period End program is submitted, accounting entries get created in Receiving subledger during period end for the PO shipments which has the received quantity greater than billed quantity. Then the Create Accounting process has to be submitted to generate the receipt accounting in SLA and GL.
This create accounting process is accompanied by Subledger
Multiperiod Accounting program which gets spawned automatically to
generate the reversal for the accrual entries for the next period in
SLA. Depending
on the value for the parameter "Transfer to GL" given while submitting
the create accounting program, Journal import will happen and the
accrual entries for the current period and next period will get
transferred to GL.
Note: Since SLA does the accrual reversal automatically for the next period which gets transferred to GL, Auto Reversal feature available in GL should not be used in R12.
Otherwise, it will result in duplication of accrual reversal entries in
GL. To get more details on Auto-Reversal feature and its impact on
Period end accruals in R12, please refer to Note.873399.1
During this create accounting process, it has to be ensured that the end date given while submitting the Create Accounting program is greater than or equal to the first date of the next period in which accrual reversal is supposed to happen. If the end date of Create Accounting program is less than the first date of the next period, accrual entries for the current period alone will get created in Final mode and will get transferred to GL, where as the reversal entries will get created in SLA with status as 'Incomplete' and it is not eligible to get transferred to GL at any point of time. If the GL period is closed for the current period or for the next period, period end accrual entries and reversal entries will get created only in SLA. To transfer these entries to GL, the concurrent request "Transfer Journal entries to GL-Receiving" needs to be submitted after opening the GL period.
This
receipt accounting includes encumbrance reversal entries if the PO is
encumbered, otherwise it just includes the actual entries. These entries
can be viewed in SLA menu in Cost Management module and it cannot be
viewed from Receiving Transactions Summary > Tools > View
Accounting.
Navigation:
Cost Management>SLA Resp>SLA>Inquiry>Journal entries
Query by transaction dates and ledger name
Following Accounting entries will be available in the HTML page
AP Accrual a/c CR
Charge a/c DR
Cost Management>SLA Resp>SLA>Inquiry>Journal entries
Query by transaction dates and ledger name
Following Accounting entries will be available in the HTML page
AP Accrual a/c CR
Charge a/c DR
If encumbrance is enabled, encumbrance reversal also can be viewed as follows
Budget a/c CR
Reserve For Encumbrance DR
Reserve For Encumbrance DR
for the period in which Receiving is done and for the next period,you can see the reversal entry as
AP Accrual a/c DR
Charge a/c CR
AP Accrual a/c DR
Charge a/c CR
If encumbrance is enabled, encumbrance reversal also can be viewed as follows
Budget a/c DR
Reserve For Encumbrance CR
Reserve For Encumbrance CR
As
mentioned for online accruals with Expense destination, in encumbrance
enabled environment, once the receiving process is done, Create
Accounting process and posting in GL has to be completed in order to get
the encumbrance reversal and actuals to hit the GL funds inquiry
simultaneously as the funds availability calculation in Funds Inquiry
screen will consider the encumbrance reversal and actuals only when they
are posted in GL.
Note:
R12 SLA architecture does not have this design initially. This new
design is introduced by a patch which is explained in more detail in Note.728064.1 to maintain accurate funds availability for the budget account at any point of time.
Encumbrance will get reversed from the PO once the invoice is validated.Encumbrance on the PO will get converted to Invoice encumbrance. On doing Create Accounting for the invoice, Encumbrance on the invoice will also get reversed. But this invoice encumbrance reversal and Actuals will get reflected in Funds Inquiry screen only when these entries are posted in GL.
Technical design
When
Purchase Order has Accrue on Receipt flag set to NO, Receipt Accruals
Period End program generates the accounting entries only in
RCV_RECEIVING_SUB_LEDGER. Then the Create Accounting process should take
place to create SLA journals which will insert records in
XLA_AE_HEADERS, XLA_AE_LINES and XLA_DISTRIBUTION_LINKS. These
accounting entries will be available in the table XLA_AE_LINES. The
event type code in XLA_AE_HEADERS for this Encumbrance Reversal entry is
PERIOD_END_ACCRUAL and the event type code in XLA_AE_HEADERS for these
actual entries will be RECEIVE for receipt accounting and
PERIOD_END_ACCRUAL for delivery accounting.
The tables RCV_RECEIVING_SUB_LEDGER and XLA_DISTRIBUTION_LINKS can be linked using the column source_distribution_id_num_1. The value of rcv_sub_ledger_id has to be given as source_distribution_id_num_1 for the source_distribution_type "RCV_RECEIVING_SUB_LEDGER" in XLA_DISTRIBUTION_LINKS table.
The tables RCV_RECEIVING_SUB_LEDGER and XLA_DISTRIBUTION_LINKS can be linked using the column source_distribution_id_num_1. The value of rcv_sub_ledger_id has to be given as source_distribution_id_num_1 for the source_distribution_type "RCV_RECEIVING_SUB_LEDGER" in XLA_DISTRIBUTION_LINKS table.
Difference in Behavior between 11i and R12:
1.
In 11i, Receipt Accruals Period End program creates the Receipt
Accounting entries in Receiving Subledger as well as in GL_INTERFACE.
Journal Import will be done to transfer the entries to GL_JE_LINES where
as in R12, Receipt Accruals Period End program will create the entries
only in Receiving Subledger. Create Accounting Program will create SLA
journals and 'Transfer Journal entries to Gl' program will move the
entries to GL from SLA.
2.
In 11i, Accrual entries need to be reversed manually in the next period
whereas in R12, reversal of accrual entries for the next period will
happen automatically
3.
In 11i, if encumbrance is enabled, encumbrance reversal and actuals
will undergo funds check when these entries are populated in
gl_interface and GL funds inquiry will reflect the encumbrance reversal
and actuals even before posting the entries in GL. But in R12,
encumbrance reversal and actuals will hit the GL funds inquiry only when
these entries are posted in GL even though funds check happens in SLA
itself
Note:
R12 SLA design has no impact when Periodic Average Costing (PAC) is
used as it follows the same 11i approach. Accounting entries created in
PAC will not go to SLA and it will not undergo the create accounting
process. Instead it will get transferred to GL via gl_interface from PAC
distributions . But the perpetual accounting entries will also happen
along with PAC entries where the perpetual accounting will follow the
SLA design. But those entries should not get imported from SLA to GL as
PAC accounting will be transferred to GL. To restrict the GL import of
perpetual accounting entries, "Transfer to GL" option in organization
parameters should be set to None for organizations which use PAC so that
xla_ae_headers for perpetual accounting will have the
gl_transfer_status_code as "NT" and it will not be picked by the journal
import process.
Accrual Reconciliation Process:
a) Accrual Reconciliation Reports:
After completing the Receipt transactions and Invoice matching, Create Accounting program has to be run in Final mode along with the subsequent transfer of entries to General Ledger after which the Accrual Reconciliation Process has to be started.
"Accrual Reconciliation Load Run" program has to be submitted with transaction date as the parameter which will populate the data in two tables called CST_RECONCILIATION_SUMMARY and CST_AP_PO_RECONCILIATION. Now run the Accrual Reconciliation Report for the operating unit and do the reconciliation. There are 3 different types of Accrual Reconciliation Report
1. AP and PO Accrual Reconciliation Report - This report shows the transaction details based on each accrual account for each PO distribution with the Receiving transaction amount and invoice transaction amount with a net balance greater than zero.
After completing the Receipt transactions and Invoice matching, Create Accounting program has to be run in Final mode along with the subsequent transfer of entries to General Ledger after which the Accrual Reconciliation Process has to be started.
"Accrual Reconciliation Load Run" program has to be submitted with transaction date as the parameter which will populate the data in two tables called CST_RECONCILIATION_SUMMARY and CST_AP_PO_RECONCILIATION. Now run the Accrual Reconciliation Report for the operating unit and do the reconciliation. There are 3 different types of Accrual Reconciliation Report
1. AP and PO Accrual Reconciliation Report - This report shows the transaction details based on each accrual account for each PO distribution with the Receiving transaction amount and invoice transaction amount with a net balance greater than zero.
Parameters used while submitting the program:
Operating Unit - Select the Operating Unit for the report
Title - Enter your title for the report
Sort by - Parameter to specify how to sort the data at the distribution level - Valid Values - Age in days,Total Balance,Vendor,PO number (default)
Aging Period Days - The number of days by which to group transactions sorted in descending order
Item From and Item To - Range of items to consider for this report
Vendor From and Vendor To - Range of Vendors to consider for this report
Min Outstanding Balance and Max Outstanding Balance - Limits of distribution balance to dispaly
Balancing Segment From and Balancing Segment To - Range of balancing segment to consider for this report
2. Summary Accrual Reconciliation Report - This report shows the total balances for each accrual account without any distribution details and individual transaction amount and also shows whether that summarized accrual balance is related to AP PO transaction or AP no PO transaction or Miscellaneous Inventory transaction.
Parameters used while submitting the program:
Title - Enter your title for the report
Sort by - Parameter to specify how to sort the data at the distribution level - Valid Values - Age in days,Total Balance,Vendor,PO number (default)
Aging Period Days - The number of days by which to group transactions sorted in descending order
Item From and Item To - Range of items to consider for this report
Vendor From and Vendor To - Range of Vendors to consider for this report
Min Outstanding Balance and Max Outstanding Balance - Limits of distribution balance to dispaly
Balancing Segment From and Balancing Segment To - Range of balancing segment to consider for this report
2. Summary Accrual Reconciliation Report - This report shows the total balances for each accrual account without any distribution details and individual transaction amount and also shows whether that summarized accrual balance is related to AP PO transaction or AP no PO transaction or Miscellaneous Inventory transaction.
Parameters used while submitting the program:
Operating Unit - Select the Operating Unit for the report
Title - Enter your title for the report
Balancing Segment From and Balancing Segment To - Range of balancing segment to consider for this report
Title - Enter your title for the report
Balancing Segment From and Balancing Segment To - Range of balancing segment to consider for this report
3.
Miscellaneous Accrual Reconciliation Report - This report shows the
transaction details based on each accrual account which got hit because
of Miscellaneous Inventory transactions and AP NO PO
transactions.Accrual amount will be displayed for each transaction along
with the source whether it is INV or AP.
Parameters used while submitting the program:
Operating Unit - Select the Operating Unit for the report
Title - Enter your title for the report
Sort by - Parameter to specify how to sort the data at the distribution level - Valid Values - Item,Transaction Date (default) , Amount
Date From - Starting date of time period to display for this report
End Date - Ending date of time period to display for this report
Item From and Item To - Range of items to consider for this report
Min Amount and Max Amount - Limits of transaction amount to display
Balancing Segment From and Balancing Segment To - Range of balancing segment to consider for this report
Difference in Behavior between 11i and R12:
1. In 11i, the Accrual Rebuild Reconciliation Report which was required to be run to populate the accrual reconciliation table is now replaced by "Accrual Reconciliation Load Run" program in R12. The table PO_ACCRUAL_RECONCILE_TEMP_ALL has been replaced by the tables CST_RECONCILIATION_SUMMARY and CST_AP_PO_RECONCILIATION in R12.
2. 11i has only one Accrual Reconciliation Report which will show all the transactions for the accrual account irrespective of whether it is Miscellaneous INV transaction or AP NO PO transaction. But in R12 there are 3 different reports, one for AP-PO individual transactions, one for Miscellaneous transactions showing the individual transaction details for source INV and AP and one for showing the summarized accrual balance for all transaction types.
3. 11i has the option of running the Accrual Reconciliation Report with net accrual balance as 0 as well as net accrual balance greater than 0. But in R12, Accrual Reconciliation Report will show only the transactions having net accrual balance greater than zero.
Title - Enter your title for the report
Sort by - Parameter to specify how to sort the data at the distribution level - Valid Values - Item,Transaction Date (default) , Amount
Date From - Starting date of time period to display for this report
End Date - Ending date of time period to display for this report
Item From and Item To - Range of items to consider for this report
Min Amount and Max Amount - Limits of transaction amount to display
Balancing Segment From and Balancing Segment To - Range of balancing segment to consider for this report
Difference in Behavior between 11i and R12:
1. In 11i, the Accrual Rebuild Reconciliation Report which was required to be run to populate the accrual reconciliation table is now replaced by "Accrual Reconciliation Load Run" program in R12. The table PO_ACCRUAL_RECONCILE_TEMP_ALL has been replaced by the tables CST_RECONCILIATION_SUMMARY and CST_AP_PO_RECONCILIATION in R12.
2. 11i has only one Accrual Reconciliation Report which will show all the transactions for the accrual account irrespective of whether it is Miscellaneous INV transaction or AP NO PO transaction. But in R12 there are 3 different reports, one for AP-PO individual transactions, one for Miscellaneous transactions showing the individual transaction details for source INV and AP and one for showing the summarized accrual balance for all transaction types.
3. 11i has the option of running the Accrual Reconciliation Report with net accrual balance as 0 as well as net accrual balance greater than 0. But in R12, Accrual Reconciliation Report will show only the transactions having net accrual balance greater than zero.
4.
In 11i, Accrual Reconciliation Report can be run for a specific data
range and accrual balances can be checked for a specific period. But in
R12, Accrual Reconciliation Report always shows the 'as on date' accrual
balance and the report cannot be run for a specific date range.
b) Accrual Write-off Process:
Once the accrual entries for the PO or invoice are shown in Accrual Reconciliation Report, Accrual Write-off can be done using Cost Management or Purchasing responsibility>Accounting>Accrual write offs>AP and PO. This will delete the accrual entry from CST_AP_PO_RECONCILIATION table and populate the write off transaction in CST_WRITE_OFFS table. This write off transaction can also be viewed in the form View Write offs.
Accounting entries have to be created in SLA and GL for these write off transactions by submitting the Create Accounting program.This can be viewed in SLA menu by navigating to Tools > View Accounting in the View Write offs form.
Once the accrual entries for the PO or invoice are shown in Accrual Reconciliation Report, Accrual Write-off can be done using Cost Management or Purchasing responsibility>Accounting>Accrual write offs>AP and PO. This will delete the accrual entry from CST_AP_PO_RECONCILIATION table and populate the write off transaction in CST_WRITE_OFFS table. This write off transaction can also be viewed in the form View Write offs.
Accounting entries have to be created in SLA and GL for these write off transactions by submitting the Create Accounting program.This can be viewed in SLA menu by navigating to Tools > View Accounting in the View Write offs form.
Following Accounting entries will be available in the HTML page for a RECEIVE transaction
Accrual a/c DR
Offset a/c CR
Similarly for an AP PO MATCH transaction
Offset a/c CR
Similarly for an AP PO MATCH transaction
Accrual a/c CR
Offset a/c DR
Offset a/c DR
This Offset a/c will always be the Invoice Price Variance account.
Accounting
events for this write off transaction will show the Event status as
"Final Accounted" once the Create Accounting program is submitted and
the entries are transferred to GL.
Difference in Behavior between 11i and R12:
1. The table PO_ACCRUAL_WRITE_OFFS_ALL has been replaced by the table CST_WRITE_OFFS in R12.
2.
In 11i, accounting will not get created for the write off transaction
and accrual entry has to be manually adjusted in GL whereas in R12,
Create Accounting program will create the accrual entry for the write
off transaction in SLA as well as in GL and hence manual adjustment of
accrual entry is not required.
Comments
Post a Comment