Accounting Entries – Fixed Assets

In this article, we will cover accounting entries made by Oracle Fixed Asset module (FA). First we will cover some of the natural accounts that are setup and then we will cover what entries are made.

In the Assets module, following are some of the accounts we setup. Some accounts (like Clearing) are used by other modules as well.

Note: All of these accounts are natural accounts, and are created as flexfield values for the natural account (GL account) segment.

	Account	Segment Qualifier
1	Asset Cost	Asset Account
2	Asset Clearing	Asset Account
3	Depreciation Expense	Expense Account
4	Accumulated Depreciation	Contra-Asset Account
5	Deferred Depreciation Reserve	Liability Account
6	Deferred Depreciation Expense	Expense Account
7	Depreciation Adjustment	Expense Account
8	Proceeds of Sale Clearing	Asset Account
9	Cost of removal Clearing	Liability Account
10	Gain & Loss	Revenue Account

Here are the entries made by FA.

Transaction	Natural Account	Debit	Credit
Asset is added	Asset Cost	$100
	Asset Clearing		$100
Asset Depreciation	Depreciation Expense	$100
	Accumulated Depreciation		$100
Asset Retirement – W/o proceeds and W/o removal cost	Accumulated Depreciation	$60
	Gain/Loss	$40
	Asset Cost		$100
Asset Retirement – With Proceeds, W/o Cost of removal	Accumulated Depreciation	$60
	Gain/Loss	$40
	Gain/Loss		$10
	Proceeds from Sale	$10
	Asset Cost		$100
Asset Retirement -  With Cost of removal	Accumulated Depreciation	$60
	Gain/Loss	$40
	Gain/Loss	$5
	Cost of removal Clearing		$5
	Asset Cost		$100

Accounting entries for the Asset Life Cycle

Finally am able to put the detailed accounting entries for the Asset Cycle. As highlighted in one of the post Oracle Assets creates journal entries for the following general ledger accounts:

1. Asset Cost
2. Asset Clearing
3. Depreciation Expense
4. Accumulated Depreciation
5. Revaluation Reserve
6. Revaluation Amortization
7. CIP Cost
8. CIP Clearing
9. Proceeds of Sale Gain, Loss, and Clearing
10. Cost of Removal Gain, Loss, and Clearing
11. Net Book Value Retired Gain and Loss
12. Intercompany Payables
13. Intercompany Receivables
14. Deferred Accumulated Depreciation
15. Deferred Depreciation Expense
16. Depreciation Adjustment

The setup of these accounts is done while you defining the asset books as per below. The number for above accounts can usually map it with Oracle seeded screen of setup;.

Fig 1: Accounts and accounting in Fixed Assets

Fig 2: Accounts and accounting in Fixed Assets

Next we will see the different accounting at various transactional events.

 Depreciation Accounting

Whenever you run depreciation, Oracle Assets creates accounting entry with your accumulated depreciation accounts and your depreciation expense accounts. Oracle Assets creates separate journal entries for current period depreciation expense and for adjustments to depreciation expense for prior period transactions and changes to financial information.

Oracle Assets creates the following journal entries for a current period depreciation charge of AU$ 200:

 Current and Prior Period Addition

Read this previous post on mass addition:

The recoverable cost is AU$ 4,000 and the method is straight-line 4 years. You purchase and place the asset into service in Year 1, Quarter 1.

You place an asset in service in Year 1, Quarter 1, but you do not enter it into Oracle Assets until Year 2, Quarter 2. Your payables system creates the same journal entries to asset clearing and accounts payable liability as for a current period addition.

 Merge Mass Additions

When you merge two mass additions, Oracle Assets adds the asset cost of the mass addition that you are merging to the asset account of the mass addition you are merging into. Oracle Assets records the merge when you perform the transaction. Oracle Assets does not change the asset clearing account journal entries it creates for each line, so each of the appropriate clearing accounts clears separately.

 Construction-In-Process (CIP) Addition

You add a CIP asset. (CIP assets do not depreciate )

 Capitalization

Once you decide that a CIP asset is completed you can capitalize it very easily.

Navigation: Assets > Capitalize CIP Assets

A capitalization transaction is similar to an addition transaction: you place the asset in service so you can begin depreciating it. When you capitalize an asset in the period you added it, Oracle Assets creates the following journal entries:

When you capitalize an asset in a period after the period you added it, Oracle Assets creates journal entries that transfer the cost from the CIP cost account to the asset cost account. The clearing account has already been cleared.

 Deleted Mass Additions

Oracle Assets creates no journal entries for deleted mass additions and does not clear the asset clearing accounts credited by accounts payable. You clear the accounts by either reversing the invoice in your payables system, or creating manual journal entries in your general ledger.

Asset Type Adjustments

If you change the asset type from capitalized to CIP, Oracle Assets creates journal entries to debit the CIP cost account and credit the asset clearing account. Oracle Assets does not create capitalization or reverse capitalization journal entries for CIP reverse transactions.

Cost Adjustments to Assets

Understand this way, you placed an asset in service in Year 1, Quarter 1. The recoverable cost is AU$4,000. The life of your asset is 4 years, and you are using straight-line depreciation. In Year 1, Quarter 4, you receive an additional invoice for the asset and change the recoverable cost to AU$4,800.

Expense will go at it:

Amortized

Reinstatement

Current Period Reinstatement

 Reclassification

Read these post for greatest

• details Reclassification of assets
• Asset Reclass Programmatically

When you reclassify an asset from office equipment to computers in Year 1, Quarter 3. The asset cost is AU$4,000, the life is 4 years, and you are using straight-line depreciation

 Transfer Asset

Read this earlier post on asset transfer .

In Year 2, Quarter 2, you transfer the asset from cost center 100 to cost center 200 in the current period

In Year 3, Quarter 4, you transfer the asset from the ABC Manufacturing Company to the XYZ Distribution Company.

you place the same AU$4,000 asset in service with two units assigned to cost center 100. In Year 2, Quarter 3, you realize the asset actually has four units, two of which belong to cost center 200. If all units remain in the original cost center, Oracle Assets does not create any journal entries.

Take a note, majority of case the accounting entry happen when you run Create Journal or create accounting .Hope this helps.:)

AP Invoice Technical Details with Functional Inputs

AP Invoice Technical Details with Functional Inputs

When Invoice Booked and Saved
=============================
One row created in ap_invoices_all and its distribution lines created in ap_invoice_distributions_all

When Invoice Validated :
======================
ap_invoice_distributions_all.MATCH_STATUS_FLAG='A'
ap_invoice_distributions_all.ACCOUNTING_EVENT_ID=NOT NULL(Here 1370092)
one row created in ap_accounting_events_all with accounting_event_id=ap_invoice_distributions_all.ACCOUNTING_EVENT_ID ap_accounting_events_all.EVENT_STATUS_CODE='CREATED' ap_accounting_events_all.SOURCE_TABLE='AP_INVOICES'
ap_accounting_events_all.SOURCE_ID=ap_invoice_distributions_all.INVOICE_ID=
AP_INVOICE_ALL.INVOICE_ID

When Invoice Accounted :
=====================
ap_invoice_distributions_all.ACCRUAL_POSTED_FLAG='Y'
ap_invoice_distributions_all.POSTED_FLAG='Y' ap_accounting_events_all.EVENT_STATUS_CODE='ACCOUNTED'
ONE ROW CREATED IN AP_AE_HEADERS_ALL where AP_AE_HEADERS_ALL. accounting_event_id=ap_accounting_events_all.accounting_event_id Rows created in ap_ae_lines_all
where AP_AE_HEADERS_ALL.ae_header_id=ap_ae_lines_all.ae_header_id as
below The number of rows generally created in ap_ae_lines_all counted as 1)
one row for invoice with ap_ae_lines_all.AE_LINE_TYPE_CODE='LIABILITY'
ap_ae_lines_all.SOURCE_TABLE='AP_INVOICES' ,ap_ae_lines_all.source_id=ap_invoices_all.invoice_id2)
Other rows are created for the invoice distribution lines (one line per invoice distribution line).ap_ae_lines_all.AE_LINE_TYPE_CODE='CHARGE',
SOURCE_TABLE='AP_INVOICE_DISTRIBUTIONS',
ap_ae_lines_all.SOURCE_ID=AP_INVOICE_DISTRIBUTIONS.INVOICE_ID

When Invoice Approved :
========================
ap_invoices_all.WFAPPROVAL_STATUS='MANUALLY APPROVED', initially it was 'REQUIRED'

When Payment Created
=====================
when payment created the one record created in ap_checks_all table.

When Payment Accounted
=============================
When payment document accounted then one row is created in ap_accounting_events_all table.
AP_invoice_payments_all.ACCOUNTING_EVENT_ID=
ap_accounting_events_all.ACCOUNTING_EVENT_ID
ap_accounting_events_all.EVENT_STATUS_CODE='ACCOUNTED'. andap_accounting_events_all.source_id=AP_INVOICE_PAYMENTS_ALL.check_id.

After Doing the Payment (paid) of invoice with Created Payment Document
=============================================================
ap_invoices_all.payment_status_flag='Y' BEFORE 'N'It creates the linKing between ap_invoices_all and ap_checks_all by AP_INVOICE_PAYMENTS_ALL.one row created in AP_INVOICE_PAYMENTS_ALL with reference of invoice id.
AP_INVOICE_PAYMENTS_ALL.ACCRUAL_POSTED_FLAG='Y'
AP_INVOICE_PAYMENTS_ALL.CASH_POSTED_FLAG='Y'
AP_INVOICE_PAYMENTS_ALL.POSTED_FLAG='Y'and when get void the AP_INVOICE_PAYMENTS_ALL.REVERSAL_FLAG='Y' unless it is 'N'
When payment got accounted the one row created in ap_accounting_events_all with ap_accounting_events_all.source_id=AP_INVOICE_PAYMENTS_ALL.check_id and AP_INVOICE_PAYMENTS_ALL.source_table='AP_CHECKS'

After Clearing Check from cash management
=====================================
open payment document and create accounting for it, showing partial now.
after successfull accounting of the document:
one line is created in AP_PAYMENT_HISTORY_all with new accounting _event_id.
AP_PAYMENT_HISTORY_all.accounting_event_id=
ap_accounting_events_all.accounting_event_idone new line created in ap_accounting_events_all with EVENT_TYPE_CODE='PAYMENT CLEARING'and AP_INVOICE_PAYMENTS_ALL.source_table='AP_CHECKS'
ap_accounting_events_all.source_id=AP_INVOICE_PAYMENTS_ALL.check_id andAP_PAYMENT_HISTORY_all.accounting_event_id=
ap_accounting_events_all.accounting_event_id
one row created in AP_AE_HEADERS_ALL with new accounting_event_id and two rows in this case created in ap_ae_lines_all with AE_LINE_TYPE_CODE='CASH CLEARING ' AND 'CASH',SOURCE_TABLE='AP_CHECKS'.

When Posted in GL (GL_POSTING)
===============================
after running the request "Payables Transfer to General Ledger".The ap_ae_lines_all.GL_SL_LINK_ID populates.AP_AE_HEADERS_ALL.GL_TRANSFER_FLAG='Y'AP_AE_HEADERS_ALL.
GL_TRANSFER_RUN_ID IS NOT NULL AP_AE_HEADERS_ALL.TRIAL_BALANCE_FLAG='Y'

AP Invoice Validation Status

AP Invoice Validation Status

(See Metalink doc ID 301806.1)
There is no column in the AP_INVOICES_ALL table that stores the validation status. Invoice distributions are validated individually and the status is stored at the invoice distribution level. This status is stored in AP_INVOICE_DISTRIBUTIONS_ALL.MATCH_STATUS_FLAG.
Valid values for the column are:

A – Validated (it used to be called Approved)
N or null – Never validated
T – Tested but not validated

The invoice header form derives the invoice validation status based on the following:
‘Validated’
- If all of the invoice distributions have a MATCH_STATUS_FLAG = ‘A’
‘Never Validated’
- If all of the invoice distributions have a MATCH_STATUS_FLAG = null or ‘N’
‘Needs Revalidation’
- If there are any rows in AP_HOLDS that do not have a release code.
- If any of the invoice distributions have a MATCH_STATUS_FLAG = ‘T’.
- If the invoice distributions have MATCH_STATUS_FLAG values = ‘N’, null and ‘A’ (mixed).

  Query:
========

select distinct match_status_flag from ap_invoice_distributions_all 

R12- Important AP Tables and Brief Narrative

AP_SUPPLIERS:
This table replaces the old PO_VENDORS table.
It stores information about your supplier level attributes.
Each row includes the purchasing, receiving, invoice, tax, classification, and general information.
Oracle Purchasing uses this information to determine active suppliers.
The supplier name, legal identifiers of the supplier will be stored in TCA and a reference to the party created in TCA will be stored in AP_SUPPLIERS.PARTY_ID, to link the party record in TCA.
AP_SUPPLIER_SITES_ALL:
This table replaces the old PO_VENDOR_SITES_ALL table.
It stores information about your supplier site level attributes.
There is a row for unique combination of supplier address, operating unit and the business relationship that you have with the supplier.
The supplier address information is not maintained in this table and is maintained in TCA. The reference to the internal identifier of address in TCA will be stored in AP_SUPPLIER_SITES_ALL.LOCATION_ID, to link the address record in TCA.
Each row includes the supplier reference, purchasing, invoice, and general information.
AP_INVOICES_ALL:
It contains records for invoices you enter.
There is one row for each invoice you enter.
An invoice can have one or more invoice distribution lines and can have one or more scheduled payments. 
AP_INVOICE_LINES_ALL:
It contains records for invoice lines entered manually, generated automatically or imported from the Open Interface.
An invoice can have one or more invoice lines.
An invoice line represents goods (direct or indirect materials), service(s), and/or associated tax/freight/miscellaneous charges invoiced from a supplier.
An invoice line should contain all the attributes that are present on the physical or electronic invoice presented by the supplier.
AP_INVOICE_DISTRIBUTIONS_ALL:
It holds the distribution information that is manually entered or system-generated.
There is one row for each invoice distribution and a distribution must be associated with an invoice.
An invoice can have multiple distributions.
AP_INVOICE_PAYMENTS_ALL:
It contains records of invoice payments that you made to suppliers.
There is one row for each payment you make for each invoice and there is one payment and one invoice for each payment in this table.
Oracle Payables application updates this table when you confirm an automatic payment batch, enter a manual payment, or process a Quick payment.
When you void a payment, your Oracle Payables inserts an additional payment line that is the negative of the original payment line.
AP_PAYMENT_SCHEDULES_ALL:
This table stores information about scheduled payment information on invoices.
AP_PAYMENT_HISTORY_ALL:
It stores the clearing/unclearing history for payments.
It also stores the maturity history for future dated payments.
The table contains a row for each future dated payment, once the future dated payment matures, i.e. becomes negotiable.
Any time a payment is cleared or uncleared, a row is inserted into this table for the payment.
AP_BATCHES_ALL:
It contains summary information about invoices you enter in batches if you enable the Batch Control Payables option.
There is one row for each batch of invoices you enter.
If you enable Batch Control, each invoice must correspond to a record in this table.
Your Oracle Payables application uses this information to group together invoices that one person entered in a batch.
AP_CHECKS_ALL:
It stores information about payments issued to suppliers or refunds received from suppliers. 
There is one row for each payment you issue to a supplier or refund received from a supplier.
Oracle Payables application uses this information to record payments you make to suppliers or refunds you receive from suppliers.
Oracle Payables application stores the supplier name and bank account name for auditing purposes, in case either one is changed after you create the payment. Oracle Payables application also stores address information for all payments.
AP_HOLDS_ALL:
It contains information about holds that you or your Oracle Payables application place on an invoice.
For non-matching holds, there is one row for each hold placed on an invoice. For matching holds, there is one row for each hold placed on an invoice-shipment match.
An invoice may have one or more corresponding rows in this table.
Your Oracle Payables application does not pay invoices that have one or more unreleased holds recorded in this table.
AP_BANK_ACCOUNTS_ALL:
It contains information about your bank accounts.
There is one row for each bank account you define and each bank account must be affiliated with one bank branch.
AP_BANK_ACCOUNT_USES_ALL:
It stores information for the internal and external bank accounts you define in Oracle Payables and Oracle Receivables applications.
AP_CARDS_ALL:
It stores information about the corporate credit cards issued to your employees by your corporate credit card providers.
AP_TRIAL_BALANCE:
It contains denormalized information about invoices and payments posted to the accrual set of books.

Apps DBA Queries

Query to get Oracle Apps URL
SQL:
select home_url from icx_parameters;

select * from registry$history;

SELECT a.application_name,
DECODE (b.status, 'I', 'Installed', 'S', 'Shared', 'N/A') status,
patch_level
FROM apps.fnd_application_vl a, apps.fnd_product_installations b
WHERE a.application_id = b.application_id and a.application_id ='200';

SELECT patch_name, patch_type, maint_pack_level, creation_date
FROM applsys.ad_applied_patches
ORDER BY creation_date DESC

Contract Projects Lifce Cycle

Contract Projects

Oracle Projects comes with 3 basic type of projects namely Indirect, Capital and Contract Projects. Here we will look at the Contract Projects.

Contract Projects are typically used in the Professional Services industry wherein the Vendor provides services to the end clients. Vendor invoices the clients and recognizes the revenue.

Create a Contract Project in Oracle Projects for the Customer

Contract Projects are Client Facing Projects wherein the both the parties ( Vendor and the Client) agree on certain terms and sign the contract. This contract is the basis for the Project. In Projects Module we create a Project of the Contract Project type for a particular customer.

Create an Agreement for the Project Customer

After the Contract Project is created, we will need to create an Agreement for the customer with the agreed upon amount and terms.

Fund the Project using the Client Agreement

Once the agreement is created in the system, using the agreement we need to fund the Contract Project. Note that one agreement can fund multiple projects. Typically when a Client has multiple projects going on with the same vendor. The funding created is in draft mode and has to be baselined.

Revenue Recognition

Revenue First and Bill Next

In Some companies, the revenue is recognized as and when needed irrespective of whether the customer has been invoiced or not. In those cases, we generate revenue and interface it to GL ( this is what it means revenue recognition).

Process Flow:

Generate Revenue -> Review Revenue -> Release Revenue -> Interface Revenue to GL -> Generate Invoice -> Approve/Release Invoice -> Interface Invoice to AR -> In AR, run Auto Invoice Import -> In Projects, Run the Tieback Invoice Process.

 Bill First and Revenue Next

In some companies, the revenue is not recognized until the customer has been billed. In this case, the invoice will be generated first and send to AR. Then the revenue is generated. To achieve this we will need to create Automatic Revenue Events for the interfaced billed amount. This can be done using Projects Billing Extensions ( for more info, check out the Projects interface/Client Extensions Guide).

Process Flow:

Generate Invoice -> Approve/Release Invoice -> Interface Invoice to AR -> In AR, run Auto Invoice Import -> In Projects, Run the Tieback Invoice Process -> Generate Revenue -> Review and Release Revenue -> Interface Revenue to GL

Ok, now its quiz time!

What are contract projects?

Contract Projects are Client facing projects. These projects generate revenue and bill the customers.

How the projects invoices are sent to customers?

Invoices generated in Oracle projects are interfaced to AR. From AR it is sent to the customers.

What is revenue recognition?

It is generating revenue for a project and then interface the revenue to GL.

Create Accounting for a Payment generates errors 95333 and 95359

Create Accounting for a Payment generates errors 95333 and 95359

Error:
95333: A conversion rate does not exist to convert USD to AUD for the conversion type Corporate
and conversion date 20-MAR-09 for line -25. Please use the Daily Rates form in General Ledger to
enter a conversion rate for these currencies, conversion date and conversion type.

95359: There is no accounted amount for the subledger journal entry line. Please inform your
system administrator or support representative that: The source assigned to the accounting
attribute Accounted Amount has no value for extract line number 88547. Please make sure the source
assigned to the accounting attribute Accounted Amount has a valid value, or assign a different
source to this accounting attribute.
Solution:
1. Specify a conversion rate for the currencies and conversion date mentioned in the error message 95333
Navigation under the General Ledger responsibility: Setup > Currencies > Currency Rates Manager > Daily Rates > click on the Create Daily Rates button Enter the From Currency, To Currency, Rate Type, Start Date, End Date and Rate, then click Apply

2. Run the AutoRate concurrent program in Payables
Go to the Submit Request window in Payable and submit the AutoRate concurrent process
3.Re-run the Create Accounting process for the transactions that received errors 95333 and 95359

INTERCOMPANY BILLING ACCOUNTING ENTRY

INTERCOMPANY BILLING ACCOUNTING ENTRY
An intercompany cross charge transaction against an indirect project.
Entries for the provider operating unit.
CostLabor Expense  Dr
Labor Clearing       Cr

Intercompany Accounts Receivable -Invoice

Intercompany Accounts Receivable  Dr
Intercompany Revenue  Cr

The following table shows entries for the receiver operating unit.

Intercompany Accounts Payable -Invoice

Intercompany Cost  Dr.
Intercompany Accounts Payable  Cr.

An intercompany cross charge transaction against a contract project.

Entries for the provider operating unit.

CostLabor Expense  Dr
Labor Clearing       Cr

Intercompany Accounts Receivable -Invoice

Intercompany Accounts Receivable  Dr
Intercompany Revenue  Cr

The following table shows entries for the  receiver operating unit.

Intercompany Accounts Payable -Invoice

Intercompany Cost  Dr.
Intercompany Accounts Payable  Cr.

Client Revenue

UBR/UER  Dr
Revenue  Cr

Client Invoice

Accounts Receivable  Dr
UBR/UER Cr

Determining Accounts for Provider Cost Reclassification

Oracle Projects provides a pair of debit and credit AutoAccounting functions to support the reclassification of cost in the provider operating unit upon   generating intercompany invoices.

You may use these functions to reclassify cost if you were booking cost into work-in-process cost.

Provider Cost Reclass Dr.
Provider Cost Reclass Cr.

provider cost reclassification results in the intercompany billing accounting entries as shown below.

Entries for the provider operating unit.

Cost

Construction - In - Process Dr
Labor Clearing   Cr

Provider Cost Reclassification
Labor Expense Dr
Construction - In - Process Cr

Intercompany Accounts Receivable -Invoice 

Intercompany Accounts Receivable Dr.
Intercompany Revenue Cr.

Entries for the Receiver operating unit.

Intercompany Accounts Payable -Invoice

Intercompany Construction - In - Process Dr
Intercompany Accounts Payable    Cr

Client Revenue

UBR/UER Dr
Revenue    Cr

Cost Accrual

Cost Accrual Dr.
Construction - In - Process Contra Cr.

Client Invoice

Accounts Receivable Dr
UBR/UER   Cr

Close Project
Cost Accrual  Dr/Cr
Interrcompany Construction - In - Process Cr

Note: After you run the process PRC: Tieback Invoices from Receivables, you run the process PRC: Generate Cross Charge Accounting Events to generate accounting events for the provider cost reclassification journal entries.
r12-4c's-chart of accounts,currency,calender, convention (Subledger Accounting Convention (Cash / Accrual))

Seeded Conventions: 

•          Standard Accrual

•          Standard Cash

•          Accrual w/ Encumbrance

•          Cash w/ Encumbrance

•          US Federal Accounting

•          China Standard Accrual

New Intercompany features in R12

New Intercompany features in R12  

R12 introduces the new product Advanced Global Intercompany System (AGIS), which takes forward the features provided by GIS in 11i GL and adds a number of important new capabilities. The major new capabilities are:

• Creation of Documentation (ie. Payables and Receivables Invoices) for AGIS transactions
• Web ADI Integration to facilitate uploading transactions from Excel
• One Sender to many receivers in the same transaction batch (the receivers can be in different ledgers, with different chart of accounts, currencies, periods etc)
• Integration with Oracle Approvals Manager for fully flexible approval rules with no coding
• Introduction of Intercompany Periods, which can be opened and closed by AGIS transaction type
• New user grants based security so many subsidiaries can be accessed from the same responsibility
• Online Reconciliation reporting tool, allows drilldown from account balances to the transactions. Uses XML Publisher to provide export to Excel and customization of outputs

The Intercompany balancing feature in GL is now under the AGIS product and has some new features

• Define Intercompany Payables and receivabls accounts by Legal Entity
• Define separate Payables and Receivables accounts for each direction of Intercompany trading relationships
• Intercompany Balancing performed in the subledger when transactions are accounted by SLA

An important point to note is that although we add a lot of new features any GIS set up you have in 11i will be upgraded and you can keep running as in 11i and start taking advntage f the new features if and when you are ready and it makes sense to you.

In future posts I can get into the detail of how some of these new features work and are set up and who may want so use them and why.

R12 Intercompany Accounts Set Up

R12 Intercompany Accounts Set Up

In R12 the Intercompany Accounts setup is broken out from GL and included in the Advanced Global Intercompany System (AGIS) product (Don’t worry you don’t need any additional license for this product). There is a separate set up screen for Intercompany and Intracompany Accounts. The same set up pages are available through the Accounting Set Up Manager as well as AGIS so you can pick your navigation path.

The Intracompany accounts are defined for pairs of Balancing Segment Values (BSV) within the same ledger; this set up is similar to the 11i approach and we upgrade 11i Intercompany accounts to Intracompany accounts here. You don’t need to uptake the Legal Entity Configurator product(new in R12) to define these.

In order to enter Intercompany Accounts you need use Legal Entity Configurator to define your Legal Entities and map them to ledgers and/or BSV. You then define accounts to use when certain pairs of Legal Entities trade.

In R12 you can now define a separate payable and receivable account for each Inter/Intracompany trading relationship. In 11i you would just define the due to/due from account and that account was used for both the payables and receivables I had with the specified trading partner.

These will be used for any AGIS transactions you create and also by the automatic intercompany balancing in GL and SLA. Doing the Intercompany balancing at the transaction level in SLA is a big enhancement for R12 and one I will talk about and give examples of in another post.

Base Tables In AP

Base tables:
As told earlier once the data is validated will get updated in the base tables, and is considered as the data which is in the base table is accurate and used in many ways. (Reporting..etc..)
Base Tables in Ap and Po:
The base tables in AP are as follows:

1) AP_INVOICES_ALL 

2) AP_INVOICE_PAYMENTS_ALL 

3) AP_INVOICE_DISTRIBUTIONS_ALL 

4) AP_PAYMENT_SCHEDULES_ALL 

5)AP_PAYMENT_HISTORY_ALL
 
6)AP_CHECKS_ALL 

7) AP_HOLDS_ALL

 
8) AP_AE_LINES_ALL

 
9) AP_AE_HEADERS_ALL

 

1) AP_INVOICES_ALL:

 

AP_INVOICES_ALL contains records for invoices you enter. There is one row for each invoice you enter. An invoice can have one or more invoice distribution lines. An invoice can also have one or more scheduled payments.
An invoice of type EXPENSE REPORT must relate to a row in  AP_EXPENSE_REPORT_HEADERS_ALL unless the record has been purged from AP_EXPENSE_REPORT_HEADERS_ALL. Your Oracle Payables application uses the INTEREST type invoice for interest that it calculates on invoices that are overdue. Your Oracle Payables application links the interest invoice to the original invoice by inserting the INVOICE_ID in the AP_INVOICE_RELATIONSHIPS table.

2) AP_INVOICE_PAYMENTS_ALL

AP_INVOICE_PAYMENTS_ALL contains records of invoice payments that you made to suppliers. There is one row for each payment you make for each invoice. There is one payment and one invoice for each payment in this table. Your Oracle Payables application updates this table when you confirm an automatic payment batch, enter a manual payment, or process a Quick payment. When you void a payment, your Oracle Payables application inserts an additional payment line that is the negative of the original payment line. 
.
Values for POSTED_FLAG may be 'Y' for accounted payments or 'N' for unaccounted payments. Values for ACCRUAL_POSTED_FLAG may be 'Y' for accounted payments or 'N' for unaccounted payments under accrual basis accounting; values for CASH_POSTED_FLAG
may be 'Y' for accounted payments or 'N' for unaccounted payments under cash basis accounting.

For manual payments and Quick payments, this table corresponds to the Select Invoices window in the Payment workbench.


 3) AP_INVOICE_DISTRIBUTIONS_ALL:

AP_INVOICE_DISTRIBUTIONS_ALL holds the distribution information that is manually entered or system-generated. There is one row for each invoice distribution. A distribution must be associated with an invoice. An invoice can have multiple distributions. Examples of when your Oracle Payables application automatically creates rows in this table include the following:
You choose a distribution set at the invoice header level.
You match an invoice line to a purchase order or receipt. The system uses information from the matched purchase order or receipt to create the distributions.
You match a credit or debit memo to an invoice.
You generate charge distributions (tax, freight, misc.) from allocation rules.
You apply a prepayment or unapply a prepayment.
Payables automatically withholds tax.
Payables creates an interest invoice.
When you account for an invoice, the Payables Accounting Process creates accounting events, accounting entry headers and accounting entry lines for those distributions that have accounting dates included in the selected accounting date range. The Transfer to General Ledger process can then transfer the accounting entries to General Ledger as journal entries. Values
for POSTED_FLAG are Y for accounted distributions or N for unaccounted distributions. Invoice distributions can be interfaced over/from Oracle Assets or Oracle Projects. Your Oracle Payables application sets the ASSETS_ADDITION_FLAG to U for distributions not tested by Oracle Assets; Oracle Assets then adjusts this flag after it tests a distribution for assignment as an asset. To avoid the same invoice distribution being interfaced to Oracle Project and Oracle Assets, you must interface any project-related invoice distribution to Oracle projects before you can interface it to Oracle Assets. If a project-related invoice distribution is charged to a capital project in Oracle Projects, Oracle Projects sets the ASSETS_ADDITION_FLAG to P when the PA_ADDITION_FLAG is set to Y, Z, or T. Oracle Assets only picks up invoice distributions with the ASSET_ADDITION_FLAG set to U, and if project-related, with the PA_ADDITION_FLAG set to Y, Z, or T. PA_ADDITION_FLAG tracks the status of project-related supplier invoice distributions and expense report
distributions. For supplier invoice distributions entered via Oracle Payables, the PA_ADDITION_FLAG is set to N if the distribution is project-related, otherwise it is set to E, and it is updated by Oracle Projects when the distribution is processed by the Oracle Projects Interface Supplier Invoice process. Oracle Projects sets the PA_ADDITION_FLAG to Y or Z after the item is successfully processed, or may be set to a rejection code if the line is rejected during transfer to Oracle Projects. See Payables Lookup Listing for all the errors. You must correct the rejection reason and try to retransfer the line. For supplier invoice adjustment distributions interfaced from Oracle Projects to Oracle Payables (which must net to zero with another distribution), the value for the PA_ADDITION_FLAG is set to T.
This table corresponds to the Distributions window.

 

  
4)AP_PAYMENT_SCHEDULES_ALL

AP_PAYMENT_SCHEDULES_ALL contains information about scheduled payments for an invoice. You need one row for each time you intend to make a payment on an invoice. Your Oracle Payables application uses this information to determine when to make payments on an invoice and how much to pay in an automatic payment batch. Values for HOLD_FLAG may be ’Y’ to place a hold on the scheduled payment, or ’N’ not to do so. Values for PAYMENT_STATUS_FLAG may be ’Y’ for fully paid payment schedules, ’N’ for unpaid scheduled payments, or ’P’ for partially paid scheduled payments. For converted records, enter a value for AMOUNT_REMAINING.
.




5) AP_PAYMENT_HISTORY_ALL

AP_PAYMENT_HISTORY_ALL stores the clearing/unclearing history for payments. It also stores the maturity history for future dated payments. The table contains a row for each future dated payment, once the future dated payment matures, i.e. becomes negotiable. Any time a payment is cleared or uncleared, a row is inserted into this table for the payment. The values for TRANSACTION_TYPE can be PAYMENT MATURITY, PAYMENT CLEARING, or PAYMENT UNCLEARING. Each row in this table also has the accounting status for the maturity, clearing or unclearing event. 




6) AP_CHECKS_ALL

AP_CHECKS_ALL stores information about payments issued to suppliers or refunds received from suppliers. You need one row for each payment you issue to a supplier or refund received from a supplier. Your Oracle Payables application uses this information to record payments you make to suppliers or refunds you receive from suppliers. Your Oracle Payables application stores the supplier name and bank account name for auditing purposes, in case either one is changed after you create the payment. Your Oracle Payables application stores address information for all payments. If you allow changes to the supplier payment address on manual payments or Quick payments, your Oracle Payables application maintains the new address information in this table. Your Oracle Payables application uses BANK_ACCOUNT_NUM, BANK_NUM, and BANK_ACCOUNT_TYPE for the supplier's bank information when you use the Electronic payment method. Your Oracle Payables application stores a dummy value for CHECK_STOCK_ID for refunds, thus, CHECK_STOCK_ID should not be treated as a
foreign key to AP_CHECK_STOCKS_ALL in the case of refunds. 


7) AP_HOLDS_ALL

AP_HOLDS_ALL contains information about holds that you or your Oracle Payables application place on an invoice. For non–matching holds, there is one row for each hold placed on an invoice. For matching holds, there is one row for each hold placed on an invoice–shipment match. An invoice may have one or more corresponding rows in this table. Your Oracle Payables application does not pay invoices that have one or more unreleased holds recorded in this table. This table holds information referenced by the Invoice Holds window. In the strictest sense, AP_HOLDS_ALL has no primary key. It is possible for your Oracle Payables application to place a certain type of hold on an invoice, then release it, then place another hold of the same type (if data changes before each submission of Approval), which would result in a duplicate primary key. But for practical purposes, the primary key is a concatenation of INVOICE_ID, LINE_LOCATION_ID,and HOLD_LOOKUP_CODE.

  

8) AP_AE_LINES_ALL

An accounting entry line is an entity containing a proper accounting entry with debits or credits both in transaction currency as well as functional currency along with an account and other reference information pointing to the transaction data that originated the accounting entry line. An accounting entry line is grouped with other accounting entry lines for a specific accounting entry header. Any such group of accounting entry lines should result in balanced entries in the functional currency.

9)AP_AE_HEADERS_ALL

An accounting entry header is an entity grouping all accounting entry lines created for a given accounting event and a particular set of books. An accounting entry header can either be transferred over to GL or not at all. That is, either all its accounting entry lines are transferred or none at all. The transferred to GL status is marked in the GL_TRANSFER_FLAG. Possible values for GL_TRANSFER_FLAG are Y, N, or E. Y indicates that the accounting entry header has been transferred to GL. N indicates that the accounting entry header has not been transferred to GL due to 2 possible reasons: either the transfer process has not run or it has run but the accounting entry had an accounting error on it. E indicates that an error was encountered during the transfer to GL process.