Parent Asset functionality in Oracle Assets

Parent asset functionality is used, to group all the subcomponent assets of a major (parent) asset for ease of processing and reporting.

At the time of entering a sub-component of a parent asset, enter the number of parent asset to which the new asset belongs to.

Based on the rule provided in Asset category and parent asset life, Oracle Assets defaults the life for a subcomponent asset. User can select either of;

·         Same End Date (Without specifying a minimum life): Subcomponent asset’s life is remaining life period of the parent asset

·         Same End Date (Specifying a minimum life): Subcomponent asset’s life is remaining life period of the parent asset or the minimum life provided, whichever is more

·         Same Life: Subcomponent asset’s life is actual life period of parent asset. In this scenario, subcomponent asset will continue the depreciation, even after the parent asset is fully depreciated

·         None: There is no connection between the life of the subcomponent asset and the parent asset life. Oracle Assets defaults the subcomponent asset life from the asset category.

As per the life of the subcomponent assets as defaulted above, depreciation rates need to be defined in the system.

When a transaction has been performed on parent asset, the transaction will not be performed automatically on the subcomponent asset, except mass retirements where in user can select automatically retire subcomponents along with the parent asset.

User has to manually do the same transactions on the subcomponent asset, if they are applicable to subcomponent asset as well.

 

Reports available:

Parent Asset Transactions Report: Lists all the transactions performed on parent assets in a particular asset book

Parent Asset Report: Extracts all the parent assets along with its subcomponent assets

 

Uses of parent assets

·         Defaulting the subcomponent asset’s life

·         Reporting purpose

·         Retiring subcomponent assets at the parent asset retiring through mass retirement

FA Account Generation when using SLA

In R12, We have an option to select whether to use FA Account Generator Workflow or not. In case, we wish not to use FA Account Generator workflow, Sub Ledger Accounting (SLA) will generate FA accounts.

The profile option to control this is:
FA: Use Workflow Account Generation. This should be 'Yes' (By Default 'No' if it is null) to use workflow Account Generator.

Based on this profile option, the FA Account Generator Workflow is conditional, while SLA is always used.

This post explains how SLA works in case of the profile option FA: Use Workflow Account Generation is set to No, which means FA Account Generator is not being used.

Note: This view is in context when Payables Code Combination is also null along with code combination generated by FA Account Generator workflow.

Oracle provides default SLA Application Accounting Definition setup. If this meets the requirements, SLA customization is not required and we can use the seeded AAD.

SLA Application Accounting Definition looks like following.

AAD is setup for different Event Classes and Event Types which has Journal Line Definition Assignments. To see the sla rules for particular event class, for example: 'Additions', place the cursor on desired event class and click on Journal Line Definition Tab.

JLD has different Journal Line Assignments, For Example: 'Assets Addition Cost' which has Account Derivation Rules. ADRs can be for all segments or we can create rules for individual segments based on the requirements. Here, the Rule Name and Description shows which is the source to derive account segments.

If you see, for Natural Account segment, rule name and description says, the source is Asset Categories window and for Balancing Segment, Asset Assignments window and for all other segments, source is Book Controls window.

To see the rule in detail, place the cursor on desired ADR rule(For Example: Natural Account Segment field), and click on Account Derivation Rule tab.

Here, we can create the conditions for ADR, where the ADR works only if the conditions are met.  In this case, the ADR derives the Account segment from Asset Categories window to build account code combination when the code combination generated by FA Account Generator workflow is null.

We can also map the segment values by using the value type as Mapping Type, where we can provide constant values or Input-Output segments mapping according to the requirements.


Default Sources when using Oracle Seeded AAD:
---------------------------------------------------------------------------------

Following image represents the default sources when we are using the default SLA setup provided by Oracle.

This shows different Event classes/types in first level, account types/journal line types in second level and default sources to derive segment values for generating the Account code combinations in third level.

Purpose and usage of Tax Rate Variance Account

Tax Rate Variance reflects the tax variance between the invoice and the PO distributions due to difference in tax applicability.

Tax Rate Variance is normally computed for the Non recoverable portion of the Tax. It is computed in two cases:

a) When there is a difference in the Tax amount of the PO and Invoice.
For Example: PO# 122046
Lines Amount: 14.49
Tax Amount: 1.16
Total Amount: 15.65

-----------------------------------


AP invoice# 135324
Item Amount: 14.49
Freight Amount: 14.62
Tax Amount: 0
Total Amount: 29.11
Tax Rate Variance: 1.16

In this case, Tax is calculated on PO# 122046 which is 1.16. But, on invoice there is no tax calculated. Hence, the Tax Rate Variance account recorded the difference in tax amount 1.16.

b) When there is a difference in the Taxes computed (for instance an extra tax calculated on Invoice and the same did not exist in PO).

For Example: On PO# 121985
Lines Amount: 57.62
Tax Amount: 4.60 (State Level Tax: 2.30 + County level Tax: 2.30)
Total amount: 62.22

----------------------------------------

On AP Invoice# FJ17597
Item Amount: 57.62
Freight Amount: 13.71
Tax Amount: 5.70 (State Level Tax: 2.85 + County Level Tax: 2.85)
Total Amount: 77.03

Here the applicable tax rate is 4 and State Level and County level tax is calculated in following way.

Tax for Items+Freight (57.62+13.71) = 71.33 * 0.04 = 2.85
If tax is calculated only for Freight: 13.71 * 0.04 = 0.54
Difference of Total tax and Freight Tax (2.85 - 0.54) = 2.31 which has 0.01 difference from the tax on PO.

Hence, Tax Rate Variance account has recorded the tax variance amount on Invoice Distributions as 0.01

PPR Document Validation error

This post explains the reason for following PPR Document validation error:

PPR Status: Failed Document Validation
Validation Error: Payment Profile on document is not compatible with payment format on document.

Cause of the error: This error occurs when the Payment Format assigned to the Payment Process Request  is different from the Payment Format assigned to Supplier Site.

How to fix the issue:
1. Make sure to use Payment Process Profile which has same Payment Format  as Supplier Site.
(Or)
2. Change the Payment Format on supplier site same as Payment Process Profile being used.

 

Process to update Payment Format for a Supplier Site:

Responsibility: Payables Super User

Navigation: Suppliers → Entry

Query the form with Supplier Name/Number.

1.  Click on Payment Details

2.  Click on Update Payment Details under Supplier Site

3.  Click on Payment Specifications Tab

4.  Update Payee Specified Payment Format

Payment Terms Defaulting Order

According to Order Management Defaulting Rules, system uses following hierarchy to default the Payment terms on Sales Order.

1. Sales Agreement Header
2. Customer Bill To (Invoice To)
3. Customer Shp To
4. Customer

This order can be changed by using following navigation.

1. Order Management responsibility->Setup->Rules->Defaulting
2. Query for Application : Order Management & Entity : Order Header
3. Select Attribute : Payment Term
4. Click on 'Defaulting Rules' button
5. Click on the Defaulting Condition which is Enabled
6. Under Default Sourcing Rules, you can find/change the hierarchy



Receivables uses the following hierarchy to determine the default payment terms, stopping when one is found:

customer Bill-To site level
customer address level
customer level
Transaction Type

Payment Term on AR Transactions

This post explains how AutoInvoice populates Payment Term on AR transaction when you are using a Payment Term on Sales Order which is different from the Default Payment Term assigned to Customer. For Example: The Payment Term populated on Sales Order is '30 NET' and  you have changed it to 'CREDIT'.
In this kind of scenario, AutoInvoice program checks following conditions to populate the Payment Term on Transaction as on Sales Order.

1. 'Override Terms' check box should be enabled at Customer account and site levels.

Navigation to check this option at Customer Account Level:
Customers -- Customers -- Search for the customer
Click on Account Details.

'Override Terms' check box should be enabled Under 'Account Profile' Tab.


Navigation to check this option at Customer Address Level:
Customers -- Customers -- Search for the customer
Click on Account Details.
Under Sites Tab, Click on Details for 'Bill To' customer site.

'Override Terms' check box should be enabled Under 'Profile' Tab.By checking the Override Terms check box, you are saying that when a user creates an invoice for this customer, he is allowed to change the Payment Term that defaults in. This feature allows you to create
non-balance forward transactions within a BFB-enabled site.

So, the purpose of Override Terms option is to create non-balance forward transactions for a BFB-enabled site. For BFB enabled customer, override functionality work only with NON-BFB payment Terms .

2. If you have Override Terms check box checked, you still cannot override the payment term if the following conditions are true:

-- The customer you are interfacing data for is a Balance Forward Billing (BFB) enabled customer
-- The payment term you are providing in the interface tables is a BFB term that is different from the default payment term you have set up at the Account or Site profile
That means for a BFB enabled customer, we can not override the Default Payment Term with BFB enabled Payment Term.

If you try to override the default payment term with Non-BFB Payment Term, it will work.

For example:

1.Customer - BFB Enabled
Default Payment Term - 30 NET
Override Payment Term - CREDIT (BFB Enabled)

Payment Term on AR Transaction - 30 NET

2. Customer - BFB Enabled
Default Payment Term - 30 NET
Override Payment Term - IMMEDIATE ( NON-BFB Payment Term)

Payment Term on AR Transaction - IMMEDIATE  Note: Receivables uses the following hierarchy to determine the default payment terms, stopping when one is found:

customer Bill-To site level customer address level
customer level
Transaction Type 

Error while creating a Project - 'This Customer does not exist'

This post explains how to debug the error 'This customer does not exist' while creating a project.

Problem Description:

=================
In the project creation screen, the customer field's list of values shows and allows to select a particular customer. But when we hit FINISH to create the project, it gives the error message "This customer does not exists". 

Responsibility: Project Super User (or) Project Manager

Navigation: Projects : Delivery → Create Project

1. Select Create Project from Template.

2. Enter template name and click on continue.

3. Enter required fields and select the customer.

4. Click on Finish button to create the project.

Error appears as 'This Customer does not exist'.

How to Debug the issue:

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

Run Customer Data Collection Test to check if the customer has been defined properly.

Responsibility: Application Diagnostics

Navigation: Diagnose

Select the Application Short Name: AR

select Customer data collection test and click on Execute.

Provide the required parameters Responsibility ID and customer account number then submit the request.

View report output for any issues with customer data.

Cause of the problem:

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

The Party Name in  HZ_PARTIES (Customer Account) has the character '~'. This can be verified in Customer Data collection Diagnostics report.

The reason for the ~ character is stated in the diagnostic -
ATTENTION - The above data contains leading or trailing spaces. Values with spaces are shown between tilde (~). Search for tilde (~) in this report to find the values with spaces.

In order for PA to have a row returned to its select on the customer name, the trailing space will need to be removed.

AR data will need to be cleaned.

Solution:

========

Update the Party Name or the field with tilde (~) in HZ_PARTIES table.