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.

How to Debug the error 'Please complete your tax accounting flexfield'

This post explains the process to debug the error 'Please complete your tax accounting flexfield' which appears in Auto Invoicing process.This approach helps you when the Receivables Auto Accounting rules derive the Tax account segments from E Business Tax setups and you have not much idea on EB Tax setups.

Step1: Get the Customer details from Auto Invoice Import program output or from Sales Order.

Step 2: Check the Auto Accounting setup for Tax Account
Responsibility: Any Receivables responsibility
Navigation: Setup > Transactions > Auto Accounting

Notice that the Account segment which is missing in the error has source as 'Taxes'. It means this segment gets derived from EB Tax.Generally Receivables uses Tax accounts which can be defined at any of the 3 levels shown below.
 1. Tax
2. Tax Jurisdiction
3. Tax Rate

Refer to Metalink Note ID 885225.1 for detailed explanation.


Step3: Create a manual AR invoice for same customer in test instances to know the Tax account details.

Responsibility: Any Receivables responsibility
Navigation: Transactions > Transactions

Enter a manual invoice and open Invoice Distributions Window.

 

 Note the distribution amount. Close this window and click on Tax button to open Tax window.

Based on the Distribution amount noted from Invoice Distributions window, find out the tax details in Tax window.

Step 4: Check whether the tax accounts are defined and/or active currently in EB Tax.

(i) Check at Tax Jurisdiction level:

Responsibility: Tax Manager or any Tax responsibility which has access to setups.

Navigation: Tax Configuration > Tax Jurisdictions

Query the form with Tax Jurisdiction code noted from step 3.

Click on update button to open Tax Jurisdiction window.

Click on Tax Accounts button which is on top right. Check whether Tax accounts are defined and/or active.

(ii) Check at Tax Rate level:
Navigation: Tax Configuration > Tax Rates

Query the form with required details noted from step 3.

Click on update button to open Tax Rates window.

Click on Tax Accounts button and check whether Tax accounts are defined and/or active.

(iii) Check at Tax level:

Navigation: Tax Configuration > Taxes

 Click on update button to open Tax window.

Click on Tax Accounts button which is on top right. Check whether Tax accounts are defined and/or active.

Make sure the tax accounts are defined and are active, then re run Auto Invoice program to process errored records.

Payment Due Calculation on AP invoice

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.