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.

Intercompany Setups

Intercompany Transactions are the transactions between two legal entities related to same Organization. Following are the setups need to be defined for Intercompany Transactions.

Selling Operating Unit: Vision Japan

Shipping Operating Unit: Vision Operations

Step1: Define Transaction Type

Responsibility: Receivables Manager, Vision Operations

Navigation: Setup → Transactions → Transaction Type

Define New transaction type as shown below.

 

Step2: Assign Document Sequence to new Transaction Type (Defined in Step1) 

Responsibility: General Ledger Manager, Vision Operations

Navigation: Setup : Financials → Sequences → Document → Assign

Assign a document sequence to the transaction type 'Intercompany' as shown below.

 

Step3: Define Intercompany Transaction Flow and Intercompany Relations

Responsibility: Inventory Manager, Vision operations

Navigation: Setup → Organizations → Intercompany Transaction Flows

Define Intercompany Transaction flow and Intercompany Relations as shown below.

Mandatory Setups to Check:
1. Make Sure there are no security rules defined when shipping the item from other Operating unit and Auto Accounting rules are defined(for Selling OU) to default the balancing segment values with Table Name as Standard Lines(Which will get the values from Standard line item or Inventory Item used)

Path for Security Rules:

Responsibility: General Ledger Responsibility

Navigation: Setup → Financials → Flexfields → Validation → Security → Define

Path for Auto Accounting:

Responsibility: Receivables Responsibility

Navigation:  Setup → Transactions → Auto Accounting

2. Make Sure Shipping parameters are defined for both Shipping and Selling operating units.
 

Responsibility: Order Management Responsibility

Navigation: Shipping → Setup → Shipping Parameters

3. Make Sure that the COGS account is assigned to the Transaction Type used for SO in Selling Organization.

Responsibility: Order Management Responsibility

Navigation: Setup-> Transaction Type 

4. Make sure that a value is assigned for System parameter 'Inventory Item For Freight'

Responsibility: Order Management Responsibility

Navigation: Setup → System Parameters → Values

Intercompany Transaction Process:

1. Create and Book Sales Order:

Responsibility: Vision Japan Order Management Responsibility

Navigation: Orders, Returns → Sales Orders

Create a Sales Order with Vision Operations Shipping Warehouse and book the order as shown below.

 

2. Release the Order and Ship the Item

Responsibility: Vision Operations Order Management Responsibility

Navigation: Shipping → Release Sales Orders → Release Sales Orders

Release and ship the order. Then notice the transaction status as 'Shipped' or 'Interfaced' on Shipping Transactions form as shown below.

Navigation: Shipping → Transactions

 

3. Run Workflow Background process

Responsibility: Vision Japan Inventory Responsibility

Navigation: Workflow Background Engine

Run Workflow Background Process.

4. Run Auto Invoice Master Program to create Customer Invoice

Responsibility: Vision Japan Receivables Responsibility

Navigation: View → Requests → Auto Invoice Master Program

The invoice created is shown below.

Navigation: Transactions → Transactions

5. Create Intercompany AR Invoice

Responsibility: Vision Operations Inventory Responsibility

Navigation: Reports → Intercompany Invoicing

Run the Program 'Create Intercompany AR Invoices' to create Intercompany AR invoice.

6. Import Intercompany AR invoice

Responsibility: Vision Operations Receivables Responsibility

Run Auto Invoice Master Program with parameter Source as 'Intercompany'. The Intercompany invoice created is shown below.

Navigation: Transactions → Transactions

7. Create Intercompany AP Invoice

Responsibility: Vision Japan Inventory Responsibility

Navigation: Reports → Intercompany Invoicing

Run the Program 'Create Intercompany AP Invoices' to create Intercompany AP invoice.

8. Import Intercompany AP invoice

Responsibility: Vision Japan Payables Responsibility

Run Payables Open Interface Program with parameter Source as 'Intercompany'. The Intercompany AP invoice created is shown below.

Navigation: Invoices → Inquiry → Invoices

Possible Errors while making Intercompany Transactions:

1. Please correct the revenue account assignment 

2. INCIAP - Create Intercompany AP Invoices Terminated By Signal 11 Error

3. Can not retrieve payment term from bill-to site information

4. Returned warning from extra function

Solution: Check Mandatory Setups Section.

GL Accounting Cycle and Integration

General Ledger Accounting Cycle:
1. Open Period
2. Create/Reverse journal entries
3. Post Journals
4. Review
5. Revaluate/Translate
6. Consolidate
7. Review/correct balances
8. Run reports
9. Close the periods

Integration of General Ledger with other modules:

Oracle General Ledger integrates with other modules. Following is the list of modules along with the details that flow to the General Ledger.
1. Payables sends Invoices, payments, adjustments, realized gain/loss on foreign currency and invoice price variance to GL.

2. Receivables sends invoices, payments, adjustments, debit memos, credit memos, cash, charge backs and realized gain and loss on foreign currency to GL.

3. Assets sends capital and construction in process asset additions, cost adjustments, transfers, retirements, depreciation and reclassifications.

4. Purchasing sends accruals or receipts not invoiced, purchase orders, final closes and cancellations.

5. HRMS sends employee details.

6. Payroll sends salary, deductions and tax information.

7. Inventory sends cycle counts, physical inventory adjustments, receiving transactions, delivery transactions, delivery transactions, intercompany transfers, sales order issue, internal requisitions, sub-inventory transfers and Cost of Goods Sold.

Transaction Dates for Auto Invoices in Receivables:

If there is no value provided for Transaction Date, the Autoinvoice program populates the Transaction date for Auto Invoices based several facors such as Derive Date option enabled or Disabled for Transaction Source, few colums from RA_INTERFACE_LINES_ALL, Invoice rules and Accounting Rules defind or not, and the default value provided in the parameters of Autoinvoice program.

Let us see how Autoinvoice program derives Transaction date based on Derive Date option for Transaction source and populted columns from RA_INTERFACE_LINES_ALL such as GL_DATE, SHIP_DATE_ACTUAL and SALES_ORDER_DATE.

Case 1: If the Derive Date option is enabled for Transaction Source, Autoinvoice program uses the following order to create Transaction Date.
1. GL_DATE
2. SHIP_DATE_ACTUAL
3. SALES_ORDER_DATE
4. DEFAULT_DATE (Provided in parameters of Autoinvoice program, which is mandatory)

Case2: If the Derive Date check box is disabled for Transaction Source, Autoinvoice program uses following order to populated Transaction Date.
1. GL_DATE
2. DEFAULT_DATE (Provided in parameters of Autoinvoice program, which is mandatory)

Invoice Grouping Rules in Receivables R12

Grouping Rules group Revenue and Credit transactions into  Invoices, Credit memos and Debit Memos. Autoinvoice program uses the Grouping Rules to group similar sales orders into a single invoice. We need to assign matching attributes while defining the Grouping Rules. These attributes include mandatory and optional parameters. Mandatory parameters are pre-defined by Oracle, where as optional attributes are optional and can be assigned based on the business requirements. Following is the list of all Mandatory and Optional attributes which can be assigned to the Grouping Rules.

Mandatory Attributes:
AGREEMENT_ID
COMMENTS
CONS_BILLING_NUMBER
CONVERSION_DATE
CONVERSION_RATE
CONVERSION_TYPE
CREDIT_METHOD_FOR_ACCT_RULE
CREDIT_METHOD_FOR_INSTALLMENTS
CURRENCY_CODE
CUSTOMER_BANK_ACCOUNT_ID
CUST_TRX_TYPE_ID
DOCUMENT_NUMBER
DOCUMENT_NUMBER_SEQUENCE_ID
GL_DATE
HEADER_ATTRIBUTE1-15
HEADER_ATTRIBUTE_CATEGORY
HEADER_GDF_ATTRIBUTE1-30
INITIAL_CUSTOMER_TRX_ID
INTERNAL_NOTES
INVOICING_RULE_ID
ORIG_SYSTEM_BILL_ADDRESS_ID
ORIG_SYSTEM_BILL_CONTACT_ID
ORIG_SYSTEM_BILL_CUSTOMER_ID
ORIG_SYSTEM_SOLD_CUSTOMER_ID
ORIG_SYSTEM_BATCH_NAME
PAYMENT_SERVER_ORDER_ID
PAYMENT_SET_ID
PREVIOUS_CUSTOMER_TRX_ID
PRIMARY_SALESREP_ID
PRINTING_OPTION
PURCHASE_ORDER
PURCHASE_ORDER_DATE
PURCHASE_ORDER_REVISION
REASON_CODE
RECEIPT_METHOD_ID
RELATED_CUSTOMER_TRX_ID
SET_OF_BOOKS_ID
TERM_ID
TERRITORY_ID
TRX_DATE
TRX_NUMBER

Optional Attributes:
ACCOUNTING_RULE_DURATION
ACCOUNTING_RULE_ID
ATTRIBUTE1-15
ATTRIBUTE_CATEGORY
INTERFACE_LINE_ATTRIBUTE1-15
INTERFACE_LINE_CONTEXT
INVENTORY_ITEM_ID
REFERENCE_LINE_ID
RULE_START_DATE
SALES_ORDER
SALES_ORDER_DATE
SALES_ORDER_LINE
SALES_ORDER_REVISION
SALES_ORDER_SOURCE
TAX_CODE
TAX_RATE

The following Ship-To fields were mandatory grouping attributes in release 11i, but are optional in release 12 ORIG_SYSTEM_SHIP_CUSTOMER_ID
ORIG_SYSTEM_SHIP_ADDRESS_ID
ORIG_SYSTEM_SHIP_CONTACT_IDThis is because ship to information is now stored at the line level in R12. Therefore a single invoice could have different ship to information for each line.
Autoinvoice program matches all the mandatory parameters and group the transactions into invoices. If all the mandatory parameters are matched for two or more similar transactions, they will fall in a same invoice. If we define any optional attribute, Autoinvoice program matches optional attributes in addition to the mandatory attributes to group the transactions.

For Example: SALES_ORDER is the optional attribute assigned to a grouping rule, there Autoinvoice program matches all mandatory attributes + Sales Order for the transactions. For any two or more transactions, if all the mandatory attributes and Sales Order(optional attribute) are matching, only one invoice will be created for those transactions.

If your Grouping rule doesn't include Sales Order and Ship To fields in Optional attributes, similar sales orders with different ship-to addresses but same bill to will be grouped into one invoice and AR transaction form will not show any value in Ship-To address as it can not determine which ship-to value to be picked from multiple sales orders.

Steps to create a Grouping Rule:

Responsibility: Receivables Manager
Navigation: Setup -> Transactions -> Auto Invoice -> Grouping Rules

Select Line Ordering Rules if you are using any. Optional grouping characteristics are optional. If we are not giving any optional Grouping Characteristics, Autoinvoice will only matches mandatory characteristics. We can assign Optional characteristics for Invoices, Credit Memos and Debit Memos.
 

If  we want to assign optional attributes for all invoices, credit memos and debit memos, First assign optional characteristics for invoice class and the place the cursor on Class Invoices ad use Down Arrow to define  attributes for other classes(Credit Memo and Debit Memo) as well.

Purchasing Overview

Purchasing refers to a business or Organization acquiring goods or services to accomplish the goals of the Organization. The objectives of Purchasing are:

1. Maintain the quality of goods

2. Maintain continuity of supply

3. Maintain the flow of inputs and outputs

4. Avoide duplication and waste

3. Strengthen the competitive position of an Organization.

The Purchasing Process is as follows:

1. The employees raise Requisitions, requesting for required goods or material

2. Concerned authorities Request for Quotations from suppliers

3. Suppliers come with Quotations

4. Analysing the quotations from suppliers and select best quotation

5. Create Purchase Orders, mentioning all the details related to the goods or material and send to the supplier

6. Receiving the goods from suppliers

7. Storage of goods

Oracle Purchasing automates purchasing to make buyers more productive, improves management of your supply base, and adapts to virtually any procurement process. The main functionalities provided by Oracle Purchasing are as follows:

1. Requisitions: Requisition refers to Request for the material. This is the first step in the purchasing process. Requesitions are of two types:

     - Internal :  Internal Requisitions are to be created when you want to source the items internally.  Internal requisitions provide the mechanism for requesting and transferring material from inventory to other inventory or expense locations.This will be converted as Internal Sales Order.

     - Purchase: Purchase requisitions are used when you want to by the items from  a supplier. This will be converted as Purchase Order.


2. Document Approval Process:


Oracle Purchasing uses Workflows to handle requisition and Purchase Order approvals, automatic creation of Purchase Orders and releases, Purchase order changes, notifications and receipt confirmation. The different workflows that Purchasing uses are:


- PO Requisition Approval workflow: This work flow is used for approving requisitions.


- PO Approval workflow: This workflow is used for approving purchase orders.


- Change Order workflow: This workflow is used for controlling which changes to purchase orders require a manual reapproval and which are automatically reapproved; the change order workflow is really a group of workflow processes contained in the PO Approval workflow.


- PO Create Documents workflow: This workflow is used for automatically creating purchase orders and releases.


- PO Account Generator Workflow:  This workflow automatically generates accrual, budget, charge, and variance accounts on purchase orders and releases.


- PO Requisition Account Generator workflow: This workflow automatically generates accrual, budget, charge, and variance accounts on requisitions.


3. RFQ's:
A request for quotation (RFQ) is sent to a supplier to request pricing and other information for an item or items.There are three types of RFQ's that come with Purchasing by default: They are Standard, Bid and Catalog.  


 -Standard RFQ:  Standard RFQ is Used for items you'll need only once or not very often, but not necessarily for a specific, fixed quantity, location, and date. For example, An organization can use Standard RFQ for a special type of equipment, which they need only once or which they don't order very often. A standard quotation includes price breaks at different levels of quantity.


-Bid:  Bid RFQ is Used for a specific, fixed quantity, location, and date. For example, an organization can use a Bid RFQ to order expensive or very large equipment with specific quantity, which has never ordered in the past and may incurs special costs like transportation. Price breaks can not be specified for a Bid RFQ


-Catalog:  Catalog is Used for high-volume items or items for which your supplier sends you information regularly. For example, an organization can use Catalog quotation for office supplies.  Price breaks can be specified for a Catalog quotation at different levels of quantity ordered.


4. Quotations:
A quotation is the supplier's response to the RFQ. Quotations are also 3 types as RFQ's. Standard, Bid and Catalog. Standard, Bid, and Catalog quotations are same as Standard, Bid, and Catalog RFQ's.


5. Quotation Analysis:
Quotation Analysis is used to review and approve general or specific quotation information for an item or a purchasing category. After the Quotation analysis, the best quotation will be selected based on different parameters like Price, quality, delivery time etc.


6. Purchase Orders:
A purchase order (PO) is a commercial document issued by a buyer to a seller, indicating types, quantity, and agreed prices for products or services the seller will provide to the buyer.


Purchase Orders are issued when we request delivery of Goods or Services for specific dates or locations .
Purchasing provides the following purchase order types: Standard Purchase Order, Planned Purchase Order, Blanket Purchase Agreement, and Contract Purchase Agreement.


 - Standard Purchase Order:  Standard purchase orders are generally created for one-time purchase of items. To create standard purchase orders, users should know the details of the goods or services you require, estimated costs, quantities, delivery schedules, and accounting distributions. If you use encumbrance accounting, the purchase order may be encumbered since the required information is known.


- Planned Purchase Orders:  A planned purchase order is a long-term agreement committing to buy items or services from a single source. You must specify tentative delivery schedules and all details for goods or services that you want to buy, including charge account, quantities, and estimated cost.


- Blanket Purchase Agreements: Blanket purchase agreements are to be created when you know the detail of the goods or services you plan to buy from a specific supplier in a period, but you do not yet know the detail of your delivery schedules. You can use blanket purchase agreements to specify negotiated prices for your items before actually purchasing them. Blanket purchase agreements can be created for a single organization or to be shared by different business units of your organization (global agreements). You can encumber funds for a blanket purchase agreement.


- Contract Purchase Agreements:  You create contract purchase agreements with your suppliers to agree on specific terms and conditions without indicating the goods and services that you will be purchasing. You can later issue standard purchase orders referencing your contracts, and you can encumber these purchase orders if you use encumbrance accounting.

<><><><><><>

	Standard PO	Planned PO	Blanket Purchase Agreement	Contract Purchase Agreement
Business Purpose	For one time purchase items eg. Capital equip , Generators etc	For items whose supply date is tentative. The PO is released when material is required by us / sent by supplier against the release.	For Items needed in huge quantity at a discounted price over a period ( eg. components for an Automobile manf co) . The BPA is released when material is required and the supplier sends material against the Release	Purchasing diverse items from a single supplier. A Standard PO is created against a CPA
Goods or Services known	Yes	Yes	Yes	No
Price known	Yes	Yes	Yes	No
Quantity known	Yes	Yes	No	No
Delivery Schedule known	Yes	Tentative	No	No
Terms and Conditions known	Yes	Yes	Yes	Yes

7. AutoCreate:
Purchasing provides automatic creation capabilities for documents. Buyers can quickly create standard purchase orders, planned purchase orders, blanket releases, RFQs, and Oracle Sourcing negotiations from any available standard (not internal) purchase requisition lines.


8. PO Communication:
Purchasing allows you to communicate with concerned people regarding the purchase orders by using notifications, reports, alerts and FYI notifications.


Oracle R12 supports FYI(For Your Information) notifications. So, FYI notifications can be enabled for the viewers to avoid reports and alerts.
When someone gets FYI notification, their approval response is not required.


This feature is available only at the Rule level. So to have FYI notifications and regular response required Approval Notifications send to other approvers, multiple AME Rules have to be created.


9. Change Orders:
Purchasing allows you to modify the existing purchase orders or requistions. For Internal Requisition Oracle supports changes to the following attributes:
1. Quantity
2. Need By Date
If preparer updates any of these values, the changes will be reflected in Internal Sales Order.


10. Receiving:
Receiving allows you to receive the goods or material from suppliers. Receipts are of four types:


- Direct Receipt:
Direct receipt limits receipt of items directly to the final destination; also known as dock to stock receipt. The final destination includes the requester, or the inventory.


In Direct Receipt Goods are received and delivered in one transaction


 - Standard Receipt:
A receipt routing in which shipments are received into a receiving location and then delivered to an interim or final destination in a separate transaction. Standard receipts can be inspected or transferred before delivery.


In Standard Receipt Goods must be received and delivered in separate transactions.


- Inspection Required:
A receipt routing in which shipments are received into a receiving location and then the items should go for inspection before accepting or rejecting the items.




 - Express Receipt:
The express function is a quick method of entering receipts and receiving transactions.


Returns:
Purchasing allows you to perform returns to suppliers or to customers in the Receiving Returns window.


11. Releases:
Purchasing allows you to enter, edit, and approve releases against blanket purchase agreements or planned purchase orders.