Here I am trying to describe R12 SLA(Sub Ledger Accounting) Procedure.
1) All accounting performed before transfer to the GL. Accounting data generated and stored in “Accounting Events” tables prior to transfer to GL


2) Run “Create Accounting” to populate accounting events (SLA) tables. User can “View Accounting” only after “Create Accounting” is run. Create Accounting process


– Applies accounting rules

 Loads SLA tables, GL tables
 Creates detailed data per accounting rules, stores in SLA “distribution links” table

3) Below are the key tables for SLA in R12


XLA_AE_HEADERS xah

XLA_AE_LINES xal


XLA_TRANSACTION_ENTITIES xte


XLA_DISTRIBUTION_LINKS xdl


GL_IMPORT_REFERENCES gir


Below are the possible joins between these XLA Tables

xah.ae_header_id = xal.ae_header_id



xah.application_id = xal.application_id


xal.application_id = xte.application_id


xte.application_id = xdl.application_id


xah.entity_id = xte.entity_id


xah.ae_header_id = xdl.ae_header_id


xah.event_id = xdl.event_id


xal.gl_sl_link_id = gir.gl_sl_link_id


xal.gl_sl_link_table = gir.gl_sl_link_table


xah.application_id = (Different value based on Module)



xte.entity_code =

‘TRANSACTIONS’ or


‘RECEIPTS’ or


‘ADJUSTMENTS’ or


‘PURCHASE_ORDER’ or


‘AP_INVOICES’ or


‘AP_PAYMENTS’ or


‘MTL_ACCOUNTING_EVENTS’ or


‘WIP_ACCOUNTING_EVENTS’



xte.source_id_int_1 =


‘INVOICE_ID’ or


‘CHECK_ID’ or


‘TRX_NUMBER’


XLA_DISTRIBUTION_LINKS table join based on Source Distribution Types

xdl.source_distribution_type = ‘AP_PMT_DIST’


and xdl.source_distribution_id_num_1 = AP_PAYMENT_HIST_DISTS.payment_hist_dist_id


—————


xdl.source_distribution_type = ‘AP_INV_DIST’


and xdl.source_distribution_id_num_1 = AP_INVOICE_DISTRIBUTIONS_ALL.invoice_distribution_id


—————


xdl.source_distribution_type = ‘AR_DISTRIBUTIONS_ALL’


and xdl.source_distribution_id_num_1 = AR_DISTRIBUTIONS_ALL.line_id


and AR_DISTRIBUTIONS_ALL.source_id = AR_RECEIVABLE_APPLICATIONS_ALL.receivable_application_id


—————


xdl.source_distribution_type = ‘RA_CUST_TRX_LINE_GL_DIST_ALL’


and xdl.source_distribution_id_num_1 = RA_CUST_TRX_LINE_GL_DIST_ALL.cust_trx_line_gl_dist_id


—————


xdl.source_distribution_type = ‘MTL_TRANSACTION_ACCOUNTS’


and xdl.source_distribution_id_num_1 = MTL_TRANSACTION_ACCOUNTS.inv_sub_ledger_id


—————


xdl.source_distribution_type = ‘WIP_TRANSACTION_ACCOUNTS’


and xdl.source_distribution_id_num_1 = WIP_TRANSACTION_ACCOUNTS.wip_sub_ledger_id


—————


xdl.source_distribution_type = ‘RCV_RECEIVING_SUB_LEDGER’


and xdl.source_distribution_id_num_1 = RCV_RECEIVING_SUB_LEDGER.rcv_sub_ledger_id.

Hope this will help you.
Payables calculates payment Due Date using following values:

– Goods Received Date + Receipt Acceptance Days
– Invoice Date
– Terms Date

Payables populates the Payment Due Date with the most recent date among the above dates.

The logic is:
Most Recent( Goods Received Date + Receipt Acceptance Days, Invoice Date, Terms Date )

Goods Received Date:
            Goods Received Date gets populated on the invoice based on Terms Date Basis. We can find Terms Date Basis at following levels.
– Supplier Site Level
– Supplier level
– Payables Options

Payables first looks for Terms Date Basis at Supplier Site Level. If there is no value exist here, it will look at Supplier Level. If there is no value here as well, then Payables takes this value from Payables Options.

Receipt Acceptance Days:
         We can find Receipt Acceptance Days under Invoice Tab in Payables Options.

Invoice Date:
         We can find the Invoice Date in Invoice Date field on Payables Invoice.

Terms Date:
          Terms Date is the beginning date from which Payment Terms start when Payables calculates the scheduled payment(s) for an invoice. The invoice Terms Date defaults based on Terms Date Basis option you select:

System: System date on day of invoice entry.
Goods Received: The date you receive goods for invoices you match to purchase orders.
Invoice: Invoice date.
Invoice Received: Date you receive an invoice.


Payment Due Date calculation in case of a matched Invoice:

In case of a Matched invoice, Payables consider Receipt Transaction Date along with Goods Received Date + Receipt Acceptance Days, Invoice Date, and Terms Date.

The process includes two steps:

1. The system first checks for recent date of Goods Received Date+Receipt Acceptance Days and Receipt Transaction Date

The logic is:
Recent (GOODS RECEIVED DATE+RECEIPT ACCEPTANCE DAYS, RECEIPT TRANSACTION DATE)

2. After step1, the system uses the following logic again

Recent ( Recent Date from step1, Invoice Date, Terms Date)

Payables consider Receipt Date based on the “Recalculate Scheduled Payment” check box under Invoice Tab in Payables Options. If this check box is enabled, Payables consider the Receipt Date for the calculation of Payment Due Date. If you don’t want the system to use Receipt Date in the calculation of Payment Due Date, then disable “Recalculate Scheduled Payment”.

If you want recalculation, then system considers Receipt date for a matched invoice.

Navigation to enable/disable “Recalculate Scheduled Payment”:
Responsibility:    Payables Responsibility which has the access to setups

Navigation:        Setup > Options > Payables Options
Tab:                   Invoice
                                                                       
 Enable/Disable Recalculate Scheduled Payment based on business requirements.
Let’s say Invoices are imported from External Systems – irrespective of the transportation layer / method. Instead of viewing the Interface tables in the backend – say AP_INVOICES_INTERFACE , AP_INVOICE_LINES_INTERFACE, they can be viewed in the front-end.
Responsibility – Payables Manager
Navigation – Invoices – Entry – Open Interface Invoices

Clicking on the above link, opens the below form ..

Open the Query-mode to view the Invoice in the Interface table

Above is the header line. Click on Lines to view the lines information.

This would avoid looking for Invoices by querying in the back-end.
Oracle Approvals Management or AME, as it is called in general, is a module of Oracle Applications that contains the hierarchy list for all seeded/standard workflows. We can configure individual approval lists for each workflow in this module. To enable the workflows to use AME hierarchy list a profile option, AME: Installed, has to be set. Just like any profile option it can be set at any of the flowing levels,
  • Site
  • Responsibility
  • Application
  • User 

AME profile option
Demonstration of setup and usage of AME
We shall look at setting up the AP Invoice Approval hierarchy in AME. This hierarchy has not been used in the instance as the customer does not use AME for AP.
Responsibility: Approvals Management Business Analyst
Navigation: Business Analyst Dashboard
Enter %invoice% and press tab
Attributes 
Click on Attributes
We are selecting Attribute, SUPPLIER_INVOICE_AMOUNT. Click Next on the attributes are to find the this attribute
Clicking on this attribute gives the details of the attribute,
You can see how Oracle derives the value of the attribute. Let us go back to the Attributes screen by clicking Return to Attributes link at the bottom left of the screen.
If you want to modify the logic that Oracle uses on this attribute you can click on Update icon (the pencil icon) for this attribute.
Note the input parameter for the query. The condition, ai.invoice_id = :transactionId, means that the input to the AME rule will be validated against the invoice_id from the ap_invoices_all table. Thus the input into AME rule for this transaction will be invoice_id. We shall use this for testing AME later on. Make the change to the query and press Apply button.
ConditionsWe shall now add a condition. Click on Conditions.
Click on Create button and select,
Condition Type: Ordinary
Attribute: SUPPLIER_INVOICE_AMOUNT
Let’s add the condition that an invoice should be sent to 1 selected approver if the invoice amount is between AED 1000 and AED 5000.

Use the drop down lists to create the condition. Click Apply.
You can see the confirmation message on top that the condition has been added to the list.
Action Types
Now we have created a condition, we have to create an Action Type. Click on Action Types link on the top menu.
We will select an existing Action Type. Click Use Existing Action Type button.
Click on the Next button until you see “Supervisory level“. Select this Action Type
Click on Continue button.
Click Finish button.
Rules
The Action Type is now created. We now need to create a Rule. Click on the Rules tab to the top right menu.
Click on Create button to create a new rule.
Enter a new name,
Name: Invoice test rule
Rule Type: List Creation is defaulted
Start Date: today’s date is defaulted
End Date: Defaulted as 31-Dec-4712
Click on Next
Click on Add Conditions button. Now we get to select which conditions are to be added to this rule.
Let us select the condition we created named, “SUPPLIER_INVOICE_AMOUNT is greater than 1000 and less than or equal to 5000,AED“. Select this condition and click Continue button.
Check the details and click on Next
Action Type is populated automatically as this is the Action Type that was selected earlier for this transaction type. Select an Action from the list of values. Select the Action from the List of Values.
We select “Requires approvals up to the first two superiors
Click Next
Review and click Finish
Now the rule is ready to be tested and deployed.
Test the AME setup
Let us test the rule before we start using it in the transaction.
First we shall create a test invoice for testing the AME rule.
Navigation: Payables Administrator
Navigation: Invoices > Entry > Invoices
We have put a condition in AME for currency, AED, and amount between 1000 and 5000. Hence we have created an invoice with the following details,
Invoice number: TEST-AME
Invoice currency: AED
Invoice amount: 1500
Go to back to Business Analyst Dashboard in Approvals Management Business Analyst responsibility.
Click on Test icon corresponding to Payables Invoice Approval transaction type.
Click on Run Real Transaction Test.
Enter the transaction id 720374. This is the invoice_id from the ap_invoices_all table (explained in Attributes section above). The invoice amount is between AED 1000 and AED 5000, (AED1500 for the invoice we have created) i.e. as per the condition we have set in AME.
Click Go
Now the AME transaction data is shown on this page. We also have a warning message from Oracle. The message is “The Line Item attribute SUPPLIER_INVOICE_DISTRIBUTION_ASSETS_TRACKING_FLAG has invalid usage for item 278866“. Approver listmay not be generated if this attribute used in conditions”.
We need to look into the attribute SUPPLIER_INVOICE_DISTRIBUTION_ASSETS_TRACKING_FLAG.
Let us check this attribute.
Click on Setup tab on the top menu. Then click on Attributes underneath the top menu. Select the attribute by entering the name in Search form in the middle of the form.

Click Update

Select the query from the Value field and paste it in SQL.
1
2
3
4
5
6
SELECT   assets_tracking_flag
    FROM ap_invoice_distributions_all
   WHERE invoice_id = :transactionid AND invoice_distribution_id IN (SELECT invoice_distribution_id
                                                                       FROM ap_invoice_distributions_all
                                                                      WHERE invoice_id = :transactionid)
ORDER BY invoice_distribution_id
Execute the sql and pass the invoice_id, 130384 (that was being used for the AME test).
The output is ‘Y’. If you notice the Attribute Data Type in the Attribute screen in AME, it is Number. Hence there is a mismatch.
Let us change this query to return only 1. Change the query to the following and paste it on the Value field in the Attribute form in AME.
1
2
3
4
5
6
SELECT   1
    FROM ap_invoice_distributions_all
   WHERE invoice_id = :transactionId AND invoice_distribution_id IN (SELECT invoice_distribution_id
                                                                       FROM ap_invoice_distributions_all
                                                                      WHERE invoice_id = :transactionId)
ORDER BY invoice_distribution_id
Click on Validate button to validate the query
The message on top shows that the query is valid. Click on Apply. Go back to the Test Workbench page by clicking on Test Workbench tab on the top right menu. Click on Run Real Transaction Test (1) button.
Enter the same transaction Id, 130384, and click on Go.
Click on Run Test Case (2) button.
Oracle throws an error, “This transaction’s requestor lacks a person ID, so AME cannot locate the requestor’s supervisor to begin the chain of authority“. This means the requester_id field has to be populated in the table.
Let us populate the requester_id field for this invoice. For demonstration we shall perform this action using an update statement. Go back to the AP invoices form and query for the invoice. Click on Folder > Show field. Query for Re%
Select Requester from the value set.
Set the value for Requester. This can be any active employee. The hierarchy of this employee will be used up to 2 levels.
Save the form. Go back to Test Workbench in AME. Enter Transaction Id: 720374. Click on Run Test Case (1) button.
Now click on Run Test Case (2) button
Now the approver list comes up for AME as the requester has been set for the invoice.
We can get AME rule details by clicking on the + or Show buttons.
We get to see the AME rule information. Now by clicking Show button for the 2nd approver, i.e. the approver on top.
Now check the 1st approver
The AME rule is now setup. Once the Invoice is sent for approval after setting the requester name the flow will be similar to what we tested now. The same logic applies to all AME approval rules.
We have used a very simple example to illustrate setting up AME rules. The same method is used to create AME rules for all transactions. Certain setup options have not been used, like Approval Groups, etc. Once AME setup is clear using the extra options will be very easy.
We have tested the approval list for the AP invoice workflow through AME. Once we send the invoice for approval, the workflow will be executed and the approval notifications will be sent in the same hierarchy.
load data infile ‘AP_INV.TXT’
append into table    AP_INVOICES_INTERFACE
fields terminated by ‘^’ optionally enclosed by ‘”‘
trailing nullcols
    (INVOICE_NUM              CHAR “RTRIM(:INVOICE_NUM)”,
     INVOICE_TYPE_LOOKUP_CODE   CHAR “RTRIM(:INVOICE_TYPE_LOOKUP_CODE)”,
     INVOICE_DATE               DATE “DD-MON-RRRR”,
     VENDOR_NUM                 CHAR “RTRIM(:VENDOR_NUM)”,
     VENDOR_SITE_CODE           FILLER,
     INVOICE_AMOUNT             CHAR “RTRIM(:INVOICE_AMOUNT)”,
     TERMS_NAME                 CHAR “RTRIM(:TERMS_NAME)”,
     DESCRIPTION                CHAR “RTRIM(:DESCRIPTION)”,
     DUMMY1 FILLER,
     DUMMY2 FILLER,
     DUMMY3 FILLER,
     DUMMY4 FILLER,
     GL_DATE  DATE “TO_DATE((TO_CHAR(:GL_DATE,’DD-‘)||DECODE(TO_CHAR(:GL_DATE,’MON’),’AUG’,’SEP’,’SEP’,’SEP’,’OCT’,’OCT’,TO_CHAR(:GL_DATE,’MON’))||TO_CHAR(:GL_DATE,’-YYYY’)))”,
     VOUCHER_NUM                CHAR “RTRIM(:VOUCHER_NUM)”,
     INVOICE_RECEIVED_DATE      DATE,
     AMOUNT_APPLICABLE_TO_DISCOUNT,
     TERMS_DATE                 DATE,
     SOURCE                     CONSTANT ‘MAXCIM INVOICE’,
     PAYMENT_CURRENCY_CODE      CONSTANT ‘USD’,
     PAYMENT_METHOD_LOOKUP_CODE CONSTANT ‘CHECK’,
     CALC_TAX_DURING_IMPORT_FLAG CONSTANT ‘N’,
     ORG_ID                     CONSTANT ‘166’,
     SHIP_TO_LOCATION           CONSTANT ‘Materials Warehouse’,
     INVOICE_CURRENCY_CODE      CONSTANT ‘USD’,
     creation_date              SYSDATE,
     last_updated_by            CONSTANT 1093,
     last_update_date           SYSDATE,
     created_by                 CONSTANT 1093,
     INVOICE_ID “AP_INVOICES_INTERFACE_S.NEXTVAL”)

load data infile ‘AP_LINE_TEST.TXT’
append into table    AP_INVOICE_LINES_INTERFACE
fields terminated by ‘^’ optionally enclosed by ‘”‘
trailing nullcols
    (REFERENCE_2              CHAR “RTRIM(:REFERENCE_2)”,
     TYPE              FILLER,
     ACCOUNTING_DATE         DATE “DD-MON-RRRR”,
     DESCRIPTION          CHAR “RTRIM(:DESCRIPTION)”,
     DIST_CODE_COMBINATION_ID          CHAR “RTRIM(:DIST_CODE_COMBINATION_ID)”,
     LAST_UPDATED_BY          CHAR “RTRIM(:LAST_UPDATED_BY)”,
     AMOUNT                  CHAR “RTRIM(:AMOUNT)”,
     CREATED_BY          CHAR “RTRIM(:CREATED_BY)”,
     CREATION_DATE          DATE “DD-MON-RRRR”,
     ATTRIBUTE1          CHAR “RTRIM(:ATTRIBUTE1)”,
     ATTRIBUTE2          CHAR “RTRIM(:ATTRIBUTE2)”,
     ATTRIBUTE3          CHAR “RTRIM(:ATTRIBUTE3)”,
     TYPE_1099          CHAR “RTRIM(:TYPE_1099)”,
     UNIT_OF_MEAS_LOOKUP_CODE      CHAR “RTRIM(:UNIT_OF_MEAS_LOOKUP_CODE)”,
     TAX_RATE              CHAR “RTRIM(:TAX_RATE)”,
     QUANTITY_INVOICED      CHAR “RTRIM(:QUANTITY_INVOICED)”,
     UNIT_PRICE          CHAR “RTRIM(:UNIT_PRICE)”,
     INVOICE_ID “AP_INVOICE_LINES_INTERFACE_S.NEXTVAL”)