Oracle Apps Basics and Realtime tutorials

Wednesday, November 2, 2016

Table
Name: AR_APPROVAL_USER_LIMITS

Use the Approval
Limits window to define approval limits for

·Adjustments created in Receivables,

·Requests for credit memos initiated from iReceivables and

·Write-offs for receipts.

Receivables uses
approval limits that have a document type of (Adjustment/credit
memo/Receipt write off) when you create an adjustment in the Adjustments,
Submit AutoAdjustments, and Approve Adjustments windows.

When you enter an adjustment that is outside your approval
limit range, Receivables assigns the adjustment a status of Pending
until someone with the appropriate approval limits either approves or rejects
it.

The Credit Memo Request Approval Workflow uses
approval limits that have a document type of Credit Memo when forwarding
credit memo requests from iReceivables. The workflow sends a
notification to an approver if the request is within the approval limit range
for the currency and reason code specified.

When you write off an unapplied receipt amount, Receivables
uses approval limits that have a document type of Receipt Write-off. You
cannot write off a receipt amount that is outside your approval limit range. You
can only write off positive amounts.

You define Adjustment approval limits by currency and
dollar amount. You define Credit Memo approval limits by reason type, currency,
and dollar amount. You define Receipt Write-off approval limits by currency and
dollar amount. The approval limits for write-offs are separate from, but cannot
exceed, the system level write-off maximum amount that you define in the System
Options window. You must specify both lower and upper approval limits for each
approver.

Attention: Be sure to update approval limits when personnel changes occur and
whenever you define new credit memo reasons in the Receivables Lookups window.

Prerequisites

Define
application users

Define
currencies

To define
approval limits:

1. Navigate to
the Approval Limits window.

2. Enter the
Username of the person for whom you are defining approval limits, or select
from the list of values. You define valid user names and descriptions in the
Users window. For more information, refer to the Oracle Applications System
Administrator's Guide.

3. Enter a
Currency code. You can define multiple user approval limits for each currency defined
in your system.

4. Enter a
minimum approval amount in this currency for this user. You can enter either a
positive or negative amount, but the From Amount must be less than or equal to
the To Amount.

5. Enter a
maximum approval amount in this currency for this user. You can enter either a
positive or negative amount, but the To Amount must be equal to or greater than
the From Amount.

Note: Credit memo approval ranges cannot overlap for limits with the same
reason type and currency. For example, the approval range for primary approver
JSMITH is from -200 USD to -100 USD and the reason code is Free Product.
Therefore, you cannot define a credit memo approval range for primary approver
AJONES from -250 USD to -150 USD and specify the same reason code.

6. If you
specified a Document Type of Credit Memo, indicate whether this approver is the
primary approver for this range by checking the Primary box.

Q1. What is the difference between
'Accrue On Receipt' and 'Accrue at Period End'?

A: Accrue On Receipt means that when a receipt
is saved, accrual transactions are immediately recorded and sent to the general
ledger interface. This is also known as "online" accruals. Accrue at
Period End means that when a receipt is saved, the accrual transactions are not
immediately recorded and sent to the general ledger; instead, the accounting
entries are generated and sent at the end of the month by running the Receipt
Accruals - Period-End Process.

All items with a destination type of either Inventory and Outside Processing
are accrued on receipt. For items with a destination type of Expense, you have
the option of accruing on receipt or at period end.

A: One should accrue on receipt if perpetual
inventory is adopted to facilitate reconciliation between inventory valuation
reports and accounting entries. Expense items typically are not accounted for
on a daily basis, and most companies find it easier to account for and
reconcile these expenses at month-end rather than at the time each individual
expense is incurred.

When both inventory and expense items are accrued on receipt, the following
problems may be encountered:
A) Receiving inspection balances will include both inventory assets and
expenses, so at the end of the month, they will need to be manually reclassified.
B) The number of entries needed to research and reconcile the perpetual A/P
Accrual Account(s) becomes significantly increased. Since the expense receipts
could double the number of accrual accounting entries to process, the Accrual
Reconciliation Report could take twice as long to run. The amount of time
required by your staff to research any discrepancies would also increase.

Q3. Which Purchasing report should
be used to review period-end accruals?

A: The Uninvoiced Receipts Report should be
used to view period-end accruals.

Q4. Which Purchasing report should
be used to review online accruals?

A: The Accrual Rebuild Reconciliation Report
should be used to view accrual transactions for inventory items and expense
items which are set to accrue on receipt (online accruals). These transactions
can also be included on the Uninvoiced Receipts Report by setting the parameter
'Include Online Accruals' to Yes when submitting the report.

Q5. After entering receipts and
running the Receipt Accruals - Period-End Process, the new journals do not
appear in the General Ledger. Should the transactions automatically appear in
GL after performing these steps?

A: The transactions from Oracle Purchasing are
only sent to the GL_INTERFACE table; in order to create the journals and see
them in General Ledger, the Journal Import concurrent program must be run from
a General Ledger responsibility. Be sure to review the output file from the
Journal Import request to ensure that the records imported successfully.

Q6. How can one tell whether each
journal in the general ledger is for period- end or on receipt (online)
accruals?

Q7. Does the process of reversing
journals for period-end accruals occur automatically in GL?

A: The process of reversing the accrual
journals does not occur automatically; they must be manually reversed in the
general ledger.

Q8. For the Uninvoiced Receipts
Report, what is the purpose of the parameter 'Accrued Receipts'?

A: This parameter should be set to 'No' to see
only the uninvoiced receipts which have not yet been accrued by running the
Receipt Accruals - Period-End process. This parameter should be set to 'Yes' to
see all uninvoiced receipts, including those which have been accrued by running
the Receipt Accruals - Period-End Process.

Q9. Records are appearing on the
Uninvoiced Receipts report for expense items which have been received but not
invoiced. How can these records be removed from the report and kept from
accruing each month?

A: There are a couple of methods that can be
used to remove records from the report and to keep them from accruing each
month: A) Close the purchase order shipment line. Closing the purchase order at
the Header or Line level will also have the same effect. On the Purchase Order
Summary form, select Special -> Control, then 'Close'. NOTE: Selecting
'Cancel' will not keep receipts from accruing each month. Refer to
question/answer #10 below for an explanation of this. B) Create an invoice in
AP and match it to the purchase order for the entire received quantity. Some
users choose to create a 'dummy' invoice for $0.00 in this case.

Q10. A purchase order shipment was
received against, then canceled. It now appears on the Uninvoiced Receipts
report and accrues each month when running the Receipt Accruals - Period-End
process. Why is this happening?

A: When a purchase order is canceled (whether
at the header, line, or shipment level), only the unreceived quantity is
actually canceled. Cancellation does not effect quantities already received, as
an obligation still remains for these receipts. If the quantity received is equal
to the quantity invoiced (billed), or if no receipts have been entered against
the purchase order shipment, then cancellation sets the Canceled flag of the
shipment to 'Yes' and the Closure Status to 'Closed'. In this case, no accrual
transaction will be generated. If the quantity received is not equal to the
quantity invoiced, then cancellation sets the Canceled flag of the shipment to
'Yes' and the Closure Status remains in its current status (i.e., not
'Closed'). The difference between quantity received and quantity invoiced will
appear on the Uninvoiced Receipts report, and will continue to accrue each
month until an invoice is matched for the entire received quantity, or until
the received items are returned to the Supplier.

Q11. What is the difference
between the Accrual Reconciliation Report and the Accrual Rebuild
Reconciliation Report?

A: The report is available as two (2) separate
concurrent programs: the Accrual Reconciliation Report and the Accrual Rebuild
Reconciliation Report. Both reports run using the same report definition file:
POXACREC.rdf. When the Accrual Rebuild Reconciliation Report is selected, the
following events occur: - The program will delete all records currently stored
in the PO_ACCRUAL_RECONCILE_TEMP_ALL table - Accounting entries are selected
from the appropriate sources (sub ledgers) based on the parameters entered at
the time of report submission - The temporary table
PO_ACCRUAL_RECONCILE_TEMP_ALL is repopulated with these accounting entries -
Report output is generated based on this information When the Accrual
Reconciliation Report is run, the report does not reselect the information from
the sub ledgers; instead, it reports only on the data currently stored in the
PO_ACCRUAL_RECONCILE_TEMP_ALL table. This feature saves time and decreases the
performance impact on the system, because the accrual information does not have
to be regenerated from the original sources every time the report is submitted.
Typically, the Accrual Rebuild Reconciliation Report is run at the end of the
period, and the Accrual Reconciliation Report is used for interim reporting.
Note that the title showing on the report output remains the Accrual
Reconciliation Report regardless of which process is actually submitted.

Q12. How do transactions which
have subtotals of $0.00 get removed from the Accrual Reconciliation Report?

A: When submitting the report, setting the
following parameters as shown will allow for these transactions to not show on
the report output: Include All Transactions = No Transaction Amount Tolerance =
0 (or higher)

Q13. Several transactions appear on the Accrual
Reconciliation Report which were charged to the accrual account in error. Manual
journal entries have already been created in GL to correct these transactions.
How do these transactions now get removed from the report?

A: In Oracle Purchasing, go to the Accrual
Write-Offs form. Responsibility: Purchasing Super User Navigation: Accounting/Accrual
Write Offs Select the lines that need to be removed from the report and save
Then, run the Accrual Reconciliation Report again, setting the parameter
'Include Written-Off Transactions' to No. The written-off transactions will no
longer be included in the report. NOTE: You can run the Accrual Write-Off
Report to review the transactions that were written off; this can be used to
support the manual journal entry created in the general ledger.

A: The Account Generator process builds charge, budget, accrual, and
variance accounts for each purchase order, release, and requisition
distribution based on the distribution’s destination type. It is a synchronous
Workflow process.

Q2. What are the Pre-requisites
to use Account Generator?

A: Before using the Account Generator you must:
- Define your Accounting flexfield structure for each set of books.
- Define flexfield segment values and validation rules.
- Set up Oracle Workflow.
- Decide whether you want to use the Account Generator processes as seeded in
Oracle Purchasing, or you need to customize them to meet your accounting needs.

Q3. What are the workflow item
types used in Account Generator?

A: For Purchase Orders: POWFPOAG
For Requisitions: POWFRQAG
Each Account Generator item type contains the following top-level workflow
processes:
Generate Default Account
Generate Account Using Flex Builder Rules
If you are upgrading from 10.7, and you have been using the flex builder to
generate the accounts, you have an option of upgrading your existing flex
builder rules to Account Generator. In which case, you should use the “Generate
Account Using Flex Builder Rules” process.

Q4. I have been using the Flex
builder rules in Release 10.7 to build the accounts. Can I continue using the
same setup in account generator in 11.x also?

A: Yes. The same setup can be used with account generator also. To
achieve this, the following actions should be performed on up gradation to
account generator.
- Run the program in $FND_TOP/bin/FNDFBPLS. This will create a PL/SQL package
that will contain all the flex builder rules.
- Apply the newly created PL/SQL file to the database. This will create a
package called PO_PO_CHARGE_ACCOUNT /
PO_REQ_CHARGE_ACCOUNT
- Verify that the package is created successfully and that it is valid in
database.
- Choose the Account Generator Top level process as Generate Account Using Flex
Builder.
- Test the account generator.

Q5. The flex builder rules
package PO_PO_CHARGE_ACCOUNT is being overwritten whenever I apply a family
pack. Why?

A: The family pack will contain POXWFB1S.pls and POXWFB1B.pls, which
contains a blank definition of the PO_PO_CHARGE_ACCOUNT for compilation
purpose. This will override the already existing PO_PO_CHARGE_ACCOUNT
package created from flex builder rules. So the Client must take a backup of
the Flex builder rules package before applying the patch, and revert back the
package PO_PO_CHARGE_ACCOUNT using that file.

Q6. What are the steps to
generate the WFSTAT output for Account Generator?

A: 1. Set the following profiles:
- Account Generator: Run in Debug Mode=> Yes
- Account Generator: Purge Runtime Data=> No
PO: Set Debug Workflow On => Yes
2. Make sure that the concurrent program "Purge Workflow Obsolete Runtime
Data" is NOT running.
3. Open Purchase Order/Requisitions form, go to the distributions window, enter
necessary fields and click on charge account field to start generating the
charge account. After the account generator has done building the account, or
errors out, do the following from the toolbar (DO NOT exit the form or navigate
to any other block or record, otherwise this information would be lost):
Help=> Diagnostics => Examine
Enter in 1st field => parameter
Enter in 2nd field => charge_acc_wf_itemkey
Then tab out. The Item key will appear in the third field.
4. Now save the purchase order/requisition. If you are not able to save, then
clear the distribution record and navigate back to the shipment window and save
the form. Saving the form is must, because a commit is required to save the
workflow information in tables, for generating the wfstat output.
5. If step#3 could not give you an item key, then use the following query to
identify the relevant item key:
Select item_key, item_type, begin_date
from wf_items
where item_type = '&item_type'
order by begin_date desc;
For PO, use 'POWFPOAG' item type in above query, and for requisition, use
'POWFRQAG'.
6. To generate the WFSTAT output,
Run the sql in $FND_TOP/sql/wfstat.sql with above item_type and item_key. Spool
the output.
7. To get the wf debug information, run the following query:
SELECT item_key, item_type, debug_message
FROM po_wf_debug
WHERE item_key = '&Item_key'
ORDER BY execution sequence;

Q7. What exactly does profile
option "Account Generator: Run in Debug Mode" do?

A: This profile option controls whether the account generator workflow
process runs in synchronous mode (workflow-on-a-fly) or asynchronous/persistent
mode (save the runtime data).
When this profile is NULL or "No", the workflow runs in synchronous
mode and it will NOT store any runtime data in database. So you cannot generate
the wfstat etc for debug purposes. However once you set this profile option to
"Yes", then the process would run in persistent mode, thereby the
runtime data would be stored in database. Now you can generate the wfstat etc.

Q8. Will the account generator
build the charge account based on project information?

A: No. By default, the Account Generator process as seeded in Oracle
Purchasing would not consider the project information to build the account. To
achieve this functionality, you should customize the Account Generator to
consider the project details. There is a dummy sub process 'Build Project
Related Account' seeded in the Account Generator workflow, available for
customization. You would also have to modify function
PO_WF_PO_CHARGE_ACC.IS_PO_PROJECT_RELATED to return a value of
"True".
For more information on how to customize the Account Generator, please refer to
the manual Oracle Purchasing Account Generator Workflow Customization Example.

Q9. Will the account be generated
for amount based/one time item lines?

A: No the Account will not be generated if you are using the Account
Generator as seeded in Oracle Purchasing. Either the account should be manually
entered or the account generator should be customized.

Q10. When the charge account
field is non updateable?(If it Service Item – Updatable)

A: In the following cases the charge account field is not updateable:
1. If the destination type code is INVENTORY or SHOP FLOOR.
2. If the distribution is already encumbered.
3. If the PO is created from a encumbered Requisition
4. If the destination type code is Expense and
If the project is entered and the profile option PA_ALLOW_FLEXBUILDER_OVERRIDES
is set to NO
If the expense accrual code= RECEIPT

Q11. If the account generator
process raises a blank error message, what does it mean?

A: Check the invalid objects in the database. Recompile the invalid
objects.

Q12. Where do the various
accounts come from?

A: Here is a list of all possible places from where account will be
picked:

The following
accounts play a vital role in Purchase Order Processing:

1) Expense
Account

2) Encumbrance
Account

3) Expense AP
accrual account

4) Inventory AP Accrual account

5) Receiving
Inspection account

6) Purchase Price
Variance Account

7) Invoice Price
Variance Account

8) Material

1)Expense Account

=================

The Expense
account is has an GL account type of an EXPENSE and is defined

in 3 areas:

a)Subinventory

b)Item

c)Organization

a) Subinventory -
This is the GL account used to accumulate expenses for this subinventory.
The EXPENSE account of an EXPENSE subinventory is charged when you receive any item (A, B, C) into it.
The Expense account of an ASSET
subinventory is charged ONLY when you receive an expense item (A).

b)Item - This
account is REQUIRED if Inventory Asset Value is set to No and Inventory Item is set to Yes. This attribute
is controlled at the Organization level
only. This is the default inventory
account for Inventory Expense items (B).
Oracle Purchasing debits this account when you receive an item

into
inventory. only if the item is being
expensed and received into the expense
subinventory. If the Purchase Order for an Inventory Expense Item

(B) has a
destination of Inventory AND the expense subinventory is entered on the Purchase Order itself, then Oracle Purchasing uses THIS (Items ?
Expense account) FIRST; if NOT, Oracle
Purchasing uses the expense account you
assigned to the subinventory.
Navigation: Items > Choose an org > Purchasing Attribute.

c) Organization:

When any item is
received into an Organization?s Expense Subinventory, this account (Organizations-Expense account) is
charged against. When an EXPENSE item is
received into an Organizations Asset Subinventory this ( Organizations-Expense
account) is charged against.

This account
accumulates Encumbrance for this organization. This account is used if the Organization uses AVERAGE
costing.