Query to get the Supplier/Vendor details from oracle E-Business Suite R12.X.X

This query will give you the vendor list by site wise in EBS R12

Pass the parameter as Vendor name or from number to number.

SELECT 
PO.SEGMENT1 VENDOR_NUMBER,
PO.VENDOR_NAME,
PO.VENDOR_NAME_ALT,
PO.VENDOR_TYPE_LOOKUP_CODE,
POS.VENDOR_SITE_CODE
,VENDOR_SITE_CODE_ALT
,POS.ADDRESS_LINE1
,POS.ADDRESS_LINE2
,POS.ADDRESS_LINE3
,POS.ADDRESS_LINE4
,POS.CITY
,POS.COUNTRY
,POS.ZIP
,POS.COUNTY
,POS.STATE
,POS.INVOICE_CURRENCY_CODE
,POS.PAYMENT_CURRENCY_CODE
,POS.PAYMENT_METHOD_LOOKUP_CODE
,POS.PAY_GROUP_LOOKUP_CODE
,HR.NAME
,INACTIVE_DATE
,GLCC.CONCATENATED_SEGMENTS LIABILITY_ACCOUNT
,GLCCP.CONCATENATED_SEGMENTS PREPAY_ACCOUNT
,POS.EMAIL_ADDRESS
FROM AP_SUPPLIERS PO,AP_SUPPLIER_SITES_ALL POS
,GL_CODE_COMBINATIONS_KFV GLCC,GL_CODE_COMBINATIONS_KFV GLCCP
, HR_OPERATING_UNITS HR
WHERE PO.VENDOR_ID=POS.VENDOR_ID
AND GLCC.CODE_COMBINATION_ID=POS.ACCTS_PAY_CODE_COMBINATION_ID
AND GLCCP.CODE_COMBINATION_ID=POS.PREPAY_CODE_COMBINATION_ID
AND HR.ORGANIZATION_ID=POS.ORG_ID
AND PO.SEGMENT1 BETWEEN NVL(:P_SUPPLIER_NUMBER_FROM,PO.SEGMENT1) AND NVL(:P_SUPPLIER_NUMBER_TO,PO.SEGMENT1)
AND PO.VENDOR_NAME=NVL(:P_VENDOR_NAME,PO.VENDOR_NAME)
ORDER BY 1;

How to Setup Oracle Payable Withholding Tax (AWT) in R12

Oracle Account Payable – Withholding Tax Setup & Flow - R12


1. Create Special Calendar for AWT

2. CIS Calendar Profile Option

3. Define Withholding Supplier (Tax Authority)

4. Create Withholding Code

5. Define Withholding Group

6. Configure Payable Options

7. Enable Withholding Tax applicability in the vendors

8. Perform AWT Transactions/Transaction flow

1. Create Special Calendar for WHT

Create Monthly Special Calendar

(N) Setup>Calendar>Special Calendar

2. Profile option for CIS calendar

Attach your SPL calendar in site level profile option

(N)System Admin>System Profile

3. Define withholding supplier (Tax Authority)

Create Tax Authority supplier to create withholding invoices

(N)Supplier > Entry

Select the supplier type as “Tax Authority”

4. Create withholding code

Create withholding tax code with attaching the tax authority, SPL calendar and withholding tax percentage.

(N) Setup>Tax>withholding>Code

5. Define withholding Group

Create withholding group and attach the withholding code to it.

(N) Setup>Tax>withholding>Group

6. Configure Payables Option

Setup payables option for withholding tax,

(N) Setup>Options>Payables Options

7. Enable withholding tax applicability in the vendors

Allow withholding tax in the supplier and supplier site level for withholding tax applicability

(N)Supplier > Entry

8. Perform withholding tax Transactions

Create AP invoice for withholding tax supplier to test your configuration.

Invoice deducted the withholding tax

Query the “Tax Authority” to find the withholding tax invoice

End the Process...

APP-SQLAP-10000: ORA-01403: no data found occurred in with parameters (Terms id = Seqiemce num =1)

Issue:

Unable to validate invoice where the item line has a withholding tax group due to:

APP-SQLAP-10000: ORA-01403: no data found occurred in
with parameters (Term id = Sequence num = 1) while performing the following operation: &DEBUG_INFO the following error occurs.

Solution:-

This error is caused because when the invoice is validated the system tries to create the automatic withholding invoice yet there is no Payment Term associated with the Supplier (Tax Authority) site. Since the invoice could not be created without this, the validation fails.

1. Navigate to Supplier form
Payables > Suppliers > Entry

2. Query the Supplier/Tax Authority linked to the withholding group on the problematic invoice
Click Update
Select the Key Payment Setup tab

3. Scroll to the Payment terms section and add a Payment Term to the Tax Authority for that Vendor Site.

4. Retest the issue

Why Zero Amount Shown for "Exchange Rate Variance" (ERV ) Distributions in Distribution Window of Invoice Workbench

The issue can be reproduced at will with the following steps:

1. Create a Purchase Order (PO) Matched invoice Foreign Currency invoice having difference Exchange rate for Invoice and PO.

2. Query the Invoice in Invoice Workbench

3. Click on All Distributions button

4. Check value for Amount field for Distribution type Exchange Rate Variance, its Zero

Solution:-


It is intended behaviour as per following generic business example:

If we assume that Functional Currency is USD

1) Create PO with currency CAD

PO Transaction

PO created for 1 CAD

Exchange rate:1.5 (CAD/USD)

Then:

Transaction Amount: 1 CAD
Functional Amount: 1.5 USD

2) Create AP Invoice matching to the PO Created

AP Invoice

Invoice created by matching to PO.

Exchange rate at the time of invoicing 2 (CAD/USD)

Then:


Transaction Amount: 1 CAD
Functional Amount: 2 USD

System will calculate Exchange Rate Variance with

Unable To Void Payment (prepayment) from Workbench or Payments Manager in r12

Issue:

Case 1: The check to be voided pays a standard invoice which was applied to a prepayment.
The prepayment application has not been fully unapplied and accounted.

Case 2: The check to be voided pays a prepayment invoice and there is a standard invoice that was applied to the prepayment invoice.
The prepayment application has not been fully unapplied and accounted on the standard invoice.



Solution for above case:-

Case 1:

1. In Invoice Workbench, verify that any prepayment application for the standard invoice has been fully unapplied.
2. If the invoice is in status Needs Revalidation, run validation for the invoice.
3. In Invoice Workbench, verify that the prepayment application has been accounted.  If not accounted, run accounting for the prepayment unapply event.
4. Retry Void of payment from Payments Workbench or Payments Manager

Case 2:

1. Identify the associated Standard Invoice.
2. In Invoice Workbench, verify that any prepayment application for the standard invoice has been fully unapplied.
3. If the invoice is in status Needs Revalidation, run validation for the invoice.
4. In Invoice Workbench, verify that the prepayment application has been accounted.  If not accounted, run accounting for the prepayment unapply event.
5. Retry Void of payment from Payments Workbench or Payments Manager

R12 Payables - Void Payment Restrictions

VOID PAYMENT RESTRICTIONS:

INVOICES PAID BY ANOTHER PAYMENT: When you void a payment, you cannot cancel a
related invoice if it was partially paid by a second payment.
Instead, when you choose Cancel Invoice, the system applies an "Invoice Cancel"
hold to the invoice for your reference. You can release the hold manually in
the Invoice Holds window.

CANCELLING ASSOCIATED INVOICES. If you attempt to cancel an invoice that has
been partially paid by another payment by using the Cancel Invoice
Action, instead of cancelling the invoice, Payables applies an Invoice Cancel
hold to the invoice. This hold is manually releasable.

CLEARED PAYMENTS: You cannot void a payment that the bank has already cleared.

PREPAYMENTS: You cannot void payment on a payment document that pays a
prepayment that you have applied to an invoice. You must first unapply any
prepayments, and then you can void the payment.

APP-FND-01702: An assignment does not exist for these parameters and one is mandatory Cause: The profile option Sequential Numbering is defined to have sequential numbering always used. the current set of parameter does not have a sequence assigned Action: Go to the Assign Sequences screen and assign sequence to the current set of parameters

Error:

This error will occur even document sequence assignment fall in active date.

APP-FND-01702: An assignment does not exist for these parameters and one is mandatory
Cause: The profile option Sequential Numbering is defined to have sequential numbering always used. the current set of parameter does not have a sequence assigned
Action: Go to the Assign Sequences screen and assign sequence to the current set of parameters

Solution:

The issue is caused by the following setup: PAyment Document Category was not assigned at Bank Account> Account Access> Options level

The setup causes the issue because IBY_FD_PAYMENT_FORMAT_TEXT module: Format Payment Instructions with Text Output errors and payments are not complete

Bank account setup  shows
Document Sequence is defined and assigned at bank account level.
Bank Account > Manage Payment Documents > Document Category
However Document Category has not defaulted at Bank account level using Account access > Payables options or Bank account level using Account access > Payables options

So ensure to do the following:
1. In the Payment Document Categories by Payment Method tab ,Add Payment Method Code >enter the one used in the PPR and Payment Document Category used in the PPR

OR

2. Instead of adding Payment Document Categories by Payment Method use the Payables Options tab and just add the Payment Document Category you want to use to this bank account. By doing so, for this bank account you will use the Payment Document Category defined, regardless of Payment Method.

Go to Setup : Banks > Bank accounts > Fill out account name > Go
> Select the bank account > click "update account" > Go to Account Access > Click "Options"
> Go to "Payment Document Categories by Payment Method" and click "+" sign
> Add another row > fill out Payment method code and Payment document category fields
Apply

After adding the "Payment document category" in bank screen, issue will get resolved.

You can see the screen below the document number is used.

Invoice Matching - Frequently Asked Questions

How Can I Find Out Which Invoices Are Matched To A Purchase Order?

A: In Payables, run the Matching Detail Report from Other > Request > Run.
This report will show you detail of how an invoice, purchase order, or receipt was matched. This report is especially helpful when an invoice is on hold and you are trying determine why the hold was placed.

What Reports Are Available To Check If A Credit Memo Is Matched To An Invoice?

A: In Payables, run the Credit Memo Matching Report from Other > Request > Run

Why does the Error App-Sqlap-10715 Appear when Attempting to Match an Invoice to a PO?

A: Matching an invoice to a PO for the entire quantity closes the PO for invoicing. If the invoice line is discarded (using the Discard button), reversing the PO match the Match button is again available, so the invoice is matched again to the same PO for a different quantity. At that time, the following message occurs: APP-SQLAP-10715: This purchase order line is closed for invoicing. You may want to review the purchase order before continuing with this match.
In R12, when we discard the line, the status is updated only at validation time. Similarly, we update the quantity billed and amount billed for PO's when we match or reverse, but the status is affected ONLY when we validate the invoice. So, after pressing the Discard button, validate the invoice before proceeding with any other actions on the invoice.  See Doc ID 456370.1 and Bug 5927520 for more information.

Why Can An Invoice Be Matched To A PO Without A Receipt Being Needed?

A: If the match option on PO shipment is set to Purchase Order then the invoice can be matched directly to the PO. However, if the PO is setup with 3-way matching, then after invoice validation, if a tolerance is defined then a QTY REC hold will be placed on the invoice which will need a receipt to be entered in order for the hold to be released. See Doc ID 433545.1 for more information.

Is there a maximum number of receipts that should be matched to one invoice?

A: There is no restriction about the receipt match to invoice, however, if you match to too many receipts, there will be performance issue when you matching or invalidating so this is not encouraged.

Why Does The PO Number Disappear From The Invoice Header After Matching To A PO?

A: When you are using the match button you never know how many times to how many PO's or receipts users are going to match the invoice to, hence, we do not store the PO number at the header level. See Doc ID 738788.1 for more information.

When Entering An Invoice, The Match Button Becomes Disabled When The Line Item Is Selected. Users Are Unable To Match An Invoice To A Purchase Order Or Receipt Without This Option Enabled. Is This correct?

A: This is standard functionality but once users are done adding/updating in the Lines tab, if the General Tab is selected again, the Match button will be available.

When Matching A PO To An Invoice, The Match Basis Is Not As Expected. How Does This Field Relate To The PO Line Type?

A: Match Basis will be either Quantity or Amount. The value of this field is based on the value basis of the purchase order line's type. See Doc ID 428303.1 for more information.

How Do You Match An Invoice To A PO With Two Lines, One With Match Level Receipt (3-Way), And One With Match Level PO (2-Way)?

A: First match the invoice to the PO setup with match level receipt. Then requery the invoice and match the second line to the PO. See Doc ID 181736.1 for more information.

Why does PO Match Comes Over as Exclusive Tax Lines?

A: In PO, taxes are always exclusive as per the PO application/product design. So in AP, an invoice matched to a PO would also calculate taxes as exclusive taxes. Please see Bug 6748767 R12: APXINWKB - JAPAN INCLUSIVE TAX, PO MATCH COMES OVER AS EXCLUSIVE TAX LINES for details. See Doc ID 549988.1 for more information.

Why Can Users Not Drilldown To A PO From The Invoice During Matching Without Encountering A 'Function Not Available For This Responsibility' Message?

A: This is due to incorrect menu setup. The submenu AP_PO_VIEW_PURCHASE_ORDERS_GUI needs to be added to the menu for the responsibility used to perform the match. See Doc ID 1350427.1 for more information.

Does The Purchase Order Number Get Populated On Freight, Miscellaneous And Tax Lines When Using The Allocations Window?

A: The purchase order number will not get populated on freight, miscellaneous and nonrecoverable tax lines. PO information is populated for recoverable tax lines.

Why Does Matching An Invoice To PO Default The Accrual Account To The Invoice Distributions?

A: If Accrue on Receipt is selected (checked) on the shipment line to which the invoice is matched, then the functionality is to default the PO accrual account on the invoice distributions. The PO Charge Account will default to the invoice distributions only if Accrue on Receipt is not checked. This is intended functionality.

After Matching An Invoice To A PO, The Distribution Shows As The PO Charge Account But We Were Expecting To See The Accrual Account Displayed. What Happened?

A: If the Accrue on Receipt option is set to Yes for the shipment, then the Accrual Account will be used on the Invoice Distribution. Shipments for inventory items will always be set to Accrue on Receipt. There is no way to change that. In other words the PO matched distributions for inventory items will always have the PO Accrual account as the Distribution account. Shipments for Expense items can be set to Accrue at Period End. In that case the Charge account defined on the PO distribution will be used as the distribution account. The system works as designed.

How Do I Remove A Final Matching Hold, So I Can Pay The Invoice?

A: This hold is in effect because the invoice was matched to a PO shipment that has a status of Final Closed. In 11.5.10 and above, there is no way to manually remove the hold, reverse distributions or cancel the invoice. Please see Doc ID 1447955.1 for more details.

What Do The Codes For The Final Match Flag Mean?

A: After you match an invoice to a purchase order, you can look at the AP_INVOICE_DISTRIBUTIONS_ALL table and observe different codes in the FINAL_MATCH_FLAG column. The FINAL_MATCH_FLAG has the following quickcodes:

1. N - No. The PO shipment line has not been matched.
2. Y - Yes. The PO shipment line has been matched, and one of the invoices for this PO has been final matched. When a PO is final matched to an invoice, all other invoices matched to that PO are updated, too. So, you cannot tell from this flag, which invoice was final matched.
3. D - Done. The PO shipment line is closed. You cannot invoice this distribution line.

What Does Final Match Do?

A: When you final match an invoice to a PO, you can never match another invoice to that PO. The PO lines that have been final matched are permanently closed. In 11.5.10 and above, invoices matched to a Finally Closed PO cannot be updated or canceled. Please see Doc ID 1447955.1 for help processing invoices with final match holds.

Why are Matched, Project Related Invoice Incorrectly Placed on Dist Variance Hold?

A: This was addressed via Bug 6682104 UNABLE TO VALIDATE PROJECT RELATED INVOICES BECAUSE OF UNCLEAR and fixed in the following versions:

apiindib.pls 120.59.12000000.5
apinlinb.pls 120.56.12000000.6
APXINWKB.fmb 120.496.12000000.113
The fix is included in Patch 6887291:R12.AP.A. Alternately apply the latest RUP patch identified in Doc ID 423541.1. See Doc ID 556663.1 for more information and the recommended solution.

How Does Descriptive Flexfield Information From The PO Line Get To AP During Invoice Matching?

A: Enable the Transfer PO Descriptive Flexfield Information Payables Option. With this enabled, descriptive flexfield information will automatically transfer from the purchase order distribution to the invoice distribution when match an invoice to a purchase order is done. The flexfield structure for purchase order distributions and invoice distributions should be same. Note, for ERS invoices, PO will always populate the flexfield information in the AP Invoice Interface tables, so AP will always import these value irrespective of this setup.

How Does The RCV_TRANSACTION_ID Column Get Populated In The AP_INVOICE_DISTRIBUTIONS_ALL Table?

A: The RCV_TRANSACTION_ID column is only populated when the Invoice Match Option is set to Receipt on the PO Shipment line.

It Is Possible To Match A Purchase Order To An Invoice Even If Receiving Date Is Earlier Than Invoicing Date. In Practice, It Is Illogical That You Pay Before Receiving. Does Oracle Allow Us To HOLD Invoices In Which 'INVOICING DATE' Is Earlier Than 'RECEIVING DATE'?

A: There is no such Standard seeded hold for this. If you want to make a hold on this case, you have to create and apply manual holds. See Doc ID 1427975.1 for more information.

Why Do I Get An Invoice Price Variance (IPV) Line When I Match An Invoice To A PO With Nonrecoverable Tax?

A: Nonrecoverable taxes are considered part of the "landed" cost of the items purchased when the non recoverable tax is not already included in the purchase order. See Doc ID 281505.1 for more information.

Unable To Match To A Specific Distribution On A Release. How Can This Be Fixed?

A: Enable the Allow Distribution Level Matching Payables Option, if you want to allow matching to purchase order distributions. If you enable this option, you can match an invoice to one or more purchase order distributions. If you do not enable this option, Payables only allows you to match an invoice to a purchase order shipment.

Why does Invoice Match to PO Error with ORA-24347 WARNING OF A NULL COLUMN IN AN AGGREGATE FUNCTION?

A: The application is trying to covert quick_po_number to a number. Bug 6637551 was logged for this issue and it has been confirmed fixed in patch 6641690. The readme for this patch will not mention this issue directly. However, this is the patch that Development indicated will fix this bug. Apply the latest Rup patch identified in Doc ID 423541.1. See Doc ID 473239.1 for more information.

Why does a PO Matched Invoice Status Change to 'Needs Revalidation'?

A: This issue was reported as Bug 6874994 R12 DISCARD NEVER VALIDATED INVOICE LINE - INV STATUS SHOWS NEEDS and fixed in 12.0 patch/115/sql/apinvutb.pls 120.44.12000000.7 or higher. Apply the latest Rup patch identified in Doc ID 423541.1. See Doc ID 557694.1 for more information.

Why does a PO Matched Invoice w/Invalid CCID Error with ORA-1400 in DIST_CODE_COMBINATION_ID?

A: This was reported as Bug 6887089 ORA-1400 VALIDATING PO MATCHED INVOICE W/INVAILID CCID and deemed to be a code bug which was fixed in zxmwrecdmsrvpubb.pls 120.117.12000000.14 or higher.   The fix is included in Patch 6887089. With this fix, a message indicating the account is invalid will appear. See Doc ID 560763.1 for more information.

Purchasing Encumbrances Are Not Reversed By Invoice Matching. Why Is This?

A: If PO Encumbrance Type and Invoice Encumbrance Type are the same, AP will encumber only for variances. Only when the Accounting Entries have been created for AP, would the encumbrance be relieved. Once the 'Create Accounting Entries' process is run, encumbrance is relieved. This is the standard functionality and as per design.

Why is Encumbrance Wrong after Matching, Reversing and Matching to PO again?

A: This is due to Bug 6009101 ENCUMBERED AMOUNT ON PO DISTRIBUTIONS IS INCORRECT. Code changes needed to be made to disallow the cancellation or discard of line or reversal of distribution of the invoice, if the purchase order is in an unapproved or unreserved state. This bug is fixed in the following versions:

APXINWKB.fmb 120.496.12000000.26
apicancb.pls-120.28.12000000.5
apilnutb.pls-120.28.12000000.2
ap12amg.ldt120.38.12000000.3
Apply the latest Rup patch identified in Doc ID 423541.1. See Doc ID 467436.1 for more information.

There Are Differences Between The PO And Invoice Billed/Received/Invoiced Quantities. They Should Have The Same Values If Viewed In Payables Or Purchasing. What Could Be The Problem?

A: This is a classic data corruption issue. Run the MasterGDF diagnostic Doc ID 1360390.1 for your invoice to determine if you are experiencing any corruption for that invoice and find the solution for your specific situation.

User Discards Invoice Lines On PO Matched Invoice And Cancels The Invoice, However, The PO Still Shows An Amount Billed. This Means The PO Cannot Be Cancelled Due To Mismatch Between The AP And PO Tables. Why Is This Happening?

A: This is a data corruption issue. Run the MasterGDF diagnostic Doc ID 1360390.1 for your invoice to determine if you are experiencing any corruption for that invoice and find the solution for your specific situation.

Unable To Validate Matched Invoice And Unable To Cancel Invoice. How Can This Invoice Be Processed?

A: The chances are high that this specific invoice has some data corruption. Run the MasterGDF diagnostic Doc ID 1360390.1 for your invoice to determine if you are experiencing any corruption for that invoice and find the solution for your specific situation.

Invoice That Was Matched To Receipt, Discarded And Rematched Has Doubled Matching Amounts. Unable To Cancel The Invoice And Line Cannot Be Discarded As This Would Result In Negative Quantities On The PO. What Is The Problem?

A: This is a data corruption issue. Run the MasterGDF diagnostic Doc ID 1360390.1 for your invoice to determine if you are experiencing any corruption for that invoice and find the solution for your specific situation.

Why does the Quickmatch of Invoice to Receipt Error with APP-SQLAP-10000 ORA-6502 PL/SQL Numeric or Value?

A: Lines and Distributions are not created. This was reported as Bug 5929800 ADS120.GA:FIN:QUICK MATCH BY RECEIPT FAILS AND CAUSES FORMS ERROR and was fixed in 12.0 patch/115/sql/apmatchb.pls-120.54.12000000.2 or higher. Apply the latest Rup patch identified in Doc ID 423541.1. See Doc ID 467106.1 for more information.

Attempting To Match To A PO That Was Previously Matched And Unmatched, Incorrectly Shows Negative Value For Billed Quantity. What Is The Problem?

A: This is a data corruption issue. Run the MasterGDF diagnostic Doc ID 1360390.1 for your invoice to determine if you are experiencing any corruption for that invoice and find the solution for your specific situation.

Why does the Asset_Tracking_Flag Remain 'N' for PO Matched Invoice Lines?

A: For a PO matched invoice, if the PO has the accrue on receipt checked and the PO charge account is asset type, then after matching, the distribution line created has assets_tracking_flag set to 'N' (instead of assets_tracking_flag set to 'Y').

This was logged as Bug 6014884 ASSET_TRACKING_FLAG NOT SET IN INVOICE DISTRIBUTION LINES AS EXPECTED and fixed in 12.0 patch/115/sql/apmatchb.pls-120.54.12000000.3 or higher.
Apply the latest Rup patch identified in Doc ID 423541.1. See Doc ID 467442.1 for more information.

Why does Receipt Matched or ERS Invoices have the assets_tracking_flag Set to N?

A: Receipt matched invoices and ERS created invoices do not have the assets_tracking_flag populated to Yes, when accrue on receipt and charge account is set up as an asset account. This was reported as Bug 6683010 ASSET_TRACKING_FLAG NOT SET FOR RECEIPT MATCH AND ERS INVOICES and was fixed in 12.0 patch/115/sql/aprcvmtb.pls 120.59.12000000.2 or higher.  Development has created one-off patch 6683010 for this bug. Please see Doc ID 548975.1 for more information.

Create Adjusting Documents (APXCADIP) Program Is Not Creating PPA Invoices When The PO# Parameter Is Not Provided. There Are Four Parameters: PO#, Supplier, Supplier Site And Resubmit Interface Import And None Of These Are Mandatory Yet The Program Does Not Create The Invoice For The Standard PO That References The Global Blanket Purchase Agreements (GBPA) That Got Updated If The PO# Is Not Entered. Why Is This?

A: The Purchase Order for which the price is to be adjusted must be specified so that the application knows which PO should be adjusted. An ER was logged to allow a global Blanket PO agreement number to be entered as a parameter so that all POs linked to this would be updated. See Doc ID 1378388.1 for more information.

Why does Matching a Credit Memo to a PO Matched Invoice Error with FRM-40212?

A: An incorrect match option is used.  Bug 6674082 R12 CAN'T MATCH CREDIT MEMO TO PO MATCHED INVOICE USING CORRECTION BUTTON.  To correct a PO Matched Invoice Line, use the Match Option 'PO' and hit 'Correct' button. To correct an unmatched Invoice Line, use the Match Option 'Invoice' and hit the 'Correct' button. See Note.471725.1 for more information.

Is It Possible To Enter A Different Tax Classification Code For The Return Tax Code During A Price Correction?

A: No different taxes in the original transaction and price correction is not feasible because a price correction will alter the item price on the original invoice, without changing the total quantity billed. Accordingly, the matching portion of tax (either positive or negative) needs to be the same tax as on the original invoice. If you want to rematch the item with different price and tax, you will need to discard the originally matched item line, so its tax will be reversed, and rematch the shipment, this time with the correct price and tax.


Automatic Debit Memo Creation Failed When Creating a RTS Transaction. What Could Be Wrong?

A: For an Automatic Debit Memo to be created in AP, the following must be true:

The supplier site has to be marked to allow RTS transactions.
There must be an original invoice already in AP for the item being returned.
The PO and the original Invoice must be to the same Supplier Site.
The Supplier Site must be marked as both a Pay Site and a Purchasing Site.
The return quantity cannot cause the quantity invoiced to go negative.
The return quantity must be equal to or less than the quantity invoiced.
The Create Debit Memo checkbox must also be turned on in the Receipt form.
The return must be to the Supplier, and not to Receiving.

If the debit memo is not created automatically, you should create the debit memo manually in the Payables application.

Debit Memo Created For A RTS Transaction Has Terms From The Supplier Site. Is This Correct?

A: The payment terms for a supplier site default to the invoices you enter for the site except in the following circumstances:

You enter a PO Default or QuickMatch invoice in the Invoice Workbench, in which case the terms default from the purchase order.
You import an invoice record that has payment terms specified on the record, or the import process can derive terms from purchase order matching. You can override the default payment terms on any invoice.
So, the debit memo is correctly picking up payment term from the supplier site.

Create Debit Memo From RTS Transaction Is Not Created When The RCV: Processing Mode Profile Option Is Set To Online. Why?

A: When the system profile option, RCV: Processing Mode is set to Online, no Debit Memo is created in Payables. Set the option to Immediate so the debit memo will be generated in Payables.

Create Debit Memo From RTS Errors AP_CANNOT_ASSIGN_DOC_SEQ. What Is The Problem?

A: Ensure that the seeded Document Category is the one assigned to the set of books for successful creation of automatic / RTS Debit memos

Price Hold Not Released When Entering Credit Memo. How Can This Be Released?

A: Use one of the following methods to resolve this issue:

Match the credit memo to the PO with price correction enabled and the related invoice selected.
Match the credit memo to the invoice which is matched to the PO in question and validate both the invoice and the credit memo.

Why Are Users Unable to Pay RTS Debit Memo?

A: Bug 5583430 RTS DEBIT MEMO BEEN CREATED WITH PAY ALONE FLAG. The bug is fixed in apcrtdmb.pls version 120.14.12000000.3 or higher. Apply the latest Rup patch identified in Doc ID 423541.1. See Doc ID 466707.1 for more information.

Why does the Invoice Validation Process Error ORA-1403 in Procedure ZX_TRD_INTERNAL_SERVICES_PVT.get_variance_related_columns for Some Operating Units?

A: Bug 6967515 INV VALIDATION FOR APA RUNS IN ERROR ORA-1403.  A root cause has not been identified. The problem invoices were successfully validated online. See Doc ID 565877.1 for more information and the recommended solution.

Why does a User-Defined Exception Error Occur when Attempting to Run Invoice Validation?

A: On PO matched invoices, if recoverability is 100% then zero (0) amount Non recoverable distribution does not get copied to invoice distributions. This causes the invoice validation to fail. Specifically, because of condition "zd.rec_nrec_rate = 100" in CURSOR insert_tax_dist of function Return_Tax_Distributions of package body AP_ETAX_UTILITY_PKG. This occurred after upgrading from 11i to R12. This was logged as Bug 6906867 INVOICE VALIDATION FOR APA AND FINOTECH RUNNING IN ERROR. See Doc ID 561418.1 for more information and the recommended solution.



Knowledge source: Oralce Metalink.

APP-SQLAP-10715 This purchase order closed for invoice. You may want to review purchase order before continuing with this match.

Matching an invoice to a PO for the entire quantity closes the PO for invoicing.

When the matched invoice line is discarded (using the Discard button), this reverses the PO match. 

The Match button is again available, so the invoice is matched again to the same PO for a different quantity. 

At that time, the following message occurs: 

APP-SQLAP-10715: This purchase order line is closed for invoicing. You may want to review the purchase order before continuing with this match.

Solution: 

In R12, when we discard the line, the status is updated only at validation time. 

Similarly, we update the quantity billed and amount billed for PO's when we match or reverse, but the status is affected ONLY when we validate the invoice. 

So, after pressing the Discard button, validate the invoice before proceeding with any other actions on the invoice.

Fully paid prepayment showing "Unpaid" Status

Issue:

Fix:

Invalid data in AP_INVOICES_ALL

select * from AP_INVOICES_ALL where invoice_id =&invoice_id find the wrong data

PAYMENT_STATUS_FLAG P

if the invoice is fully paid, the status PAYMENT_STATUS_FLAG should be Y.

To implement the solution, please execute the following steps:

1. Ensure that you have taken a backup of your system before applying the recommended solution.

2. Run the following scripts in a TEST environment first:
.
create table SR_XXX_aia as
select *
from ap_invoices_all
where invoice_id =&invoice_id;
.
update ap_invoices_all
set payment_status_flag = 'Y'
where invoice_id =&invoice_id;

commit;

-- one row updated

3. If you are satisfied with the results, issue a commit.

4. Confirm that the data is corrected when viewed in the Oracle Applications.

Cannot Add or Update AP Invoice Distribution of PO Matched Invoices

Cannot change the charge account if PO has a destination type = Inventory or shop floor. This means that AP must use the accrual account

If user were allowed to change the account on the invoice, this would cause the accrual account to be out of balance. As a result the application restricts the user from changing the account at this point in time.

The user would need to discard the invoice line - which would reverse the invoice distribution in question. Then the user would need to correct the PO so the destination item was not inventory or shop floor. Then re-match the invoice.

This is intended functionality

Common Payable Invoice Issues with Fixes

INVOICES

INV.1 : Amount is null for reversed distribution. In this case, invoice cannot be accounted. Accounting fails with error There is no entered amount for the subledger journal entry line."

Resolution :Fix script will update the amount on the original and reversed distribution with 0.

INV.2: Payables Posted Invoice Register errors out due to invoice description containing Junk characters cause

Resolution :Fix script will remove the junk characters from the description.


INV.3: The default CCID on invoice line is -1. When this invoice line is queried on invoice workbench, the following error is displayed:
" APP-FND-00756: Cannot find combination CCID=-1.."

Resolution :Fix script will null out the default CCID.

RCA Bug: Preventive fix 11716947


INV.4: Mismatching operating unit on batches and its invoices.

Resolution :Fix script will null out org_id from batch.


INV.5: Invoice_type_lookup_code NULL for upgraded invoices

Resolution :Fix script will set the invoice type to 'STANDARD'


INV.6: Party_id or Party_site_id mismatch between invoices and ap_suppliers. Such invoices cannot be queried on Invoice workbench when searching on Supplier details.

Resolution :Fix script will set the party_id/party_site_id from Supplier records.


INV.7: Generate_dists flag incorrect for Expense report invoice. For such invoice, on clicking Distribution button, error "APP-SQLAP-10000: ORA-00001: unique
constraint (AP.AP_INVOICE_DISTRIBUTIONS_U1) violated Gen_Dists_From_Registration..." is thrown.

Resolution :Fix script will correct the generate_dists flag.


INV.8: Accrual/cash_posted_flag null for unaccounted distributions

Resolution :Fix script will update the accrual_posted_flag and cash_posted_flag to N.


INV.9: Discarded line has active distributions. In this case, invoice cannot be cancelled.

Resolution :Fix script will mark the discarded line as active.

User Action:User needs to re-discard the line.

RCA: 10226172

INVOICE CANCEL

CAN.1: Included tax amount is non-zero for cancelled invoice.

Resolution :Included_tax_amount is set to zero by the fix script.


CAN.2: Approval status for cancelled invoice is incorrect.

Resolution :Fix script will update the correct approval status.

INVOICE MATCHING


MAT.1: PO is not matched, but quantities/amounts are stamped on them.

Resolution :Fix script will clear out the quantity/amount columns on the PO.


MAT.2: UOM code mismatches between PO and AP.

Resolution :Fix script will sync up UOM codes between PO and AP.


MAT.3: Quantity_invoiced mismatches between invoice line and distribution.

Resolution :Fix script will sync the quantity_invoiced on invoice distributions with invoice line.

User Action:No Action required

RCA Bug    :13691308, 9651195, 19314744


MAT.4: Rcv_transaction_id is null for Invoice distributions matched to receipts.

Resolution :Fix script will stamp rcv_transaction on the invoice distributions.

RCA Bug: 10287715

TAX_AWT


TAX.1: AWT distributions of functional currency invoice have mismatching amount and base_amounts. Such an invoice cannot be accounted.

Resolution :Fix script will correct the base_amount column with the for the identified distributions.


TAX.2: 1099 Payment Report shows double amounts due to inactive supplier site, that is still marked as reportable.

Resolution :Fix script will clear the tax_reporting_site_flag for the inactive supplier sites identified.

RCA Bug: 9115178:R12.POS.A

PREPAYMENT


PRE.1: Operating unit/ Currency mismatches between the Prepayment applied and the standard invoice. Such an invoice cannot be accounted.

Resolution :Fix script will clear the prepayment applied details from the standard invoice.

User Action:Re-apply correct prepayment invoice.

RCA: 6394865


PRE.2: Prepayment unapplication date is before the prepayment application event date. The standard invoice cannotbe accounted.

Resolution :Fix script will update the prepayment events with correct dates.

RCA Bug: 12615938


PRE.3: Validated prepayment invoice has no data in ZX_DET_LINE_FACTORS.

Resolution :Fix script will mark the invoice for force re-validation.

User Action:

1. Validate the invoice.

2. Create and backup:

AP_TEMP_DATA_DRIVER_13579759 data driver table.

AP_DATA_DRIVER_13579759_BKP - Temporary data driver backup

AP_INV_DISTS_13579759_BKP - For below corruptions:

INV.1, INV.2, INV.8, MAT.2, MAT.3, MAT.4, TAX.1, PRE.1

AP_INV_LINES_13579759_BKP - For below corruptions:

INV.2, INV.3, INV.7, INV.9, CAN.1, MAT.2, PRE.1

AP_INVOICES_13579759_BKP - For below corruptions:

INV.5, INV.6, CAN.2, PRE.3

AP_BATCHES_13579759_BKP - For corruption : INV.4

AP_PREP_HIST_13579759_BKP - For corruptions: PRE.1,PRE.2

AP_XLA_EVENTS_13579759_BKP  - For corruptions: PRE.1,PRE.2

AP_XLA_HEADERS_13579759_BKP - For corruptions: PRE.1,INV.2

AP_XLA_LINES_13579759_BKP - For corruptions: PRE.1,INV.2

AP_SITES_13579759_BKP - For corruption : TAX.2

3.  Correct the identified transactions.

Note: The patch referenced in this article is the data fix portion.  It does not eliminate the root cause, therefore the issue could recur.  Please refer to the Root Cause table below and ensure the Root Cause patches are applied as soon a possible to eliminate future recurrences of the problem.


Why it is needed?

Various invoice corruptions can occur due to various invoice bugs. The GDF will correct the above corruptions and create appropriate backup tables.
Script: selection script : ap_one_off_scripts_sel.sql
fix script       : ap_one_off_scripts_fix.sql
The above mentioned issues are identified and corrected once the selection and fix scripts are executed.

When to use it?

This Generic Data Fix patch may have one or more root causes that may cause the condition that this patch corrects. This patch should only be applied when:

Referenced in a published Note as the data fix solution for the issue in that note,
When you are instructed to run it by Support or Development through a Service Request, or,
When it is referenced as a solution in a Diagnostic Script featured in a published Note (e.g: Note 1360390.1).
If you have applied the code fix patches and the data fix patch per instructions from this Note and the issue continues to recur please log an SR with support.

How to use it?

Warning: Run the scripts in test instance, verify the results and only then apply to the production instance.

1. Download and apply patch, it will not run any script.

  AP.A Customers:
  Download and apply Patch 21497508:R12.AP.A  for R12.0.x

  AP.B Customers:
  Download and apply Patch 21497508:R12.AP.B for R12.1.x      

  AP.C Customers:  
  Download Patch 21497508:R12.AP.C and follow note 1582525.1 for ADOP enabled R12.2.x instances.

Note: If a password is required to download the patch, please open a service request to get the proper password.

2. The patch delivers 2 scripts and the latest datafix package code:

ap_one_off_scripts_sel.sql - Select script used to find and report the problem data.
ap_one_off_scripts_fix.sql - Fix script used to fix the problem data.
apgdfalb.pls and apgdfals.pls - Code that delivers the latest datafix package code, package name = AP_Acctg_Data_Fix_PKG. This package provides procedures and functions used by the GDF e.g. backing up the data, displaying the data, etc..

Note: This patch does NOT alter ANY Financials application code.

3. Apply the patch. Run script ap_one_off_scripts_sel.sql.

It expects several parameters to be passed:

1. Start_Date for selection of invoices from a given date format (dd/mm/yyyy) (Eg 01/11/2012)
2. End_Date for selection of invoices to a given date     format (dd/mm/yyyy) (Eg 22/12/2013)
3. Component value :Please enter any one of the values 'INVOICES' ,'CANCEL','MATCHING', 'TAX', 'PREPAY'
4. Email ID as an optional parameter if, user wants to receive generated log file on their email id.
It will create the following:

a) Driver table AP_TEMP_DATA_DRIVER_13579759

b) log file 13579759-diag-<DD_MI_SS>.html which displays the affected transactions.

Note: The instance does not need to be brought down to apply this patch, you can apply it in hotpatch mode e.g. adpatch option=hotpatch.

4.  For the component entered, the corresponding transactions are identified.

5.  Check the report 13579759-diag-<DD_MI_SS>.html to identify/review the affected transactions.

6.  Update process_flag in each driver table AP_TEMP_DATA_DRIVER_13579759 to Y for all the transactions that should be operated on.

7.  To correct the identified records in Step 3 have to be corrected, then run ap_one_off_scripts_fix.sql

    Example:  sqlplus apps/apps@finpqe10
    @$AP_TOP/patch/115/sql/ap_one_off_scripts_fix.sql

Following parameters are required to execute this script

1. User Name  Format Eg.CBROWN
2. Responsibility Format Eg. Payables Manager
3. Email ID as an optional parameter if, user wants to receive generated log file on their email id.

    This script will generate log file 13579759-fix-<DD_MI_SS>.html.
    This log will also list the backup table names

8.  Please note, for corruptions across different components, the selection script should be run each time with the correct component parameter value.
    Run the fix script to fix the transactions in the driver table. Re-run the selection script for each component.

9.  Check the results. Ensure all the 'User Action' listed under the corruptions in 'Description' are carried out.

10.  To verify if fix script corrected mismatch, run the  selection script ap_one_off_scripts_sel.sql for the same component. The script will not pick up transactions that were corrected by the fix script.

11. For any issues with the script/results please contact Oracle support and supply files 13579759-diag-<DD_MI_SS>.html and 13579759-fix-<DD_MI_SS>.html.
    Log files will be created in the following directory:

    SELECT decode(instr(value,','),0,value,
           SUBSTR (value,1,instr(value,',') - 1))
    FROM   v$parameter
    WHERE  name = 'utl_file_dir';

12. Please apply the listed RCA patches for each corruption type

Note:  GDF#17558081 is must post request patch for MAT1.1, MAT1.2,MAT1.3 corruption types.

Knowledge sources from Oracle support.

How To upload Default Payment Method for Supplier Sites

There is no process to assign default payment methods to Supplier Sites in bulk.

The Payment Method isn't even an attribute of the Supplier or Supplier Site, but an indirect attribute of the IBY Payee record associated with the Supplier or Supplier Site.

The default Payment Method for a Supplier Site is the row in the table IBY_EXT_PARTY_PMT_MTHDS linked to the Payee of the Supplier site that has Primary_Flag = "Y".

The reason why the form does not give a warning that a Supplier Site has no default payment method is that this is not a required field.

The following setup can be done on payments side so that if there is no payment method defined at supplier or supplier site, a system level default is used instead.

See Payment Method Defaulting Rules in the Payment Administrator form.

Payment Administrator form->Oracle Payments Setup > Payment Methods >Payment Method Defaulting Rules

Workflow error in AP payments (ap_payment_event_wf_pkg.rule_function' for event 'oracle.apps.ap.payment

Issue:

To SYSADMIN
Sent 18-Jun-2015 12:44:57
ID 1191209

An Error occurred in the following Event Subscription: Event Subscription

Event Error Name: WFE_DISPATCH_RULE_ERR
Event Error Message: 3825: Error '100 - ORA-01403: no data found
ORA-01403: no data found' encountered during execution of Rule function 'ap_payment_event_wf_pkg.rule_function' for event 'oracle.apps.ap.payment' with key '58478'.
Event Error Stack:
Wf_Event.dispatch_internal()

Cause:
AP_PAYMENT_EVENT_WF_PKG.RULE_FUNCTION has errors

When attempting to do remittance note test in vendor site set to email address then it errored out.

Technical Description:

When attempting to do remittance note test in vendorsite set to email address the following error occurs. Event Error Name: WFE_DISPATCH_RULE_ERR Event Error Message: 3825: Error 100 - ORA -01403:no data found ORA -01403:no data found encountered during execution of
Rule function 'ap_payment_event_wf_pkg.rule_function' for event 'oracle.apps.ap.payment'
with key '10040'.

Event Error Stack: Wf_Event.dispatch_internal()

Resolution:

The error occurs because there was some coding error in the package AP_PAYMENT_EVENT_WF_PKG, where the org context was not set properly for R12. So changed the code for proper setting of org context by the following code:
mo_global.set_policy_context('S',l_org_id);

And after the org context is set , still the work flow was not getting set and the reason was that procedure get_remit_email_address didn't fetch any data with respect to the email address as the query written to fetch the query was wrong for R12 as in R12 the data stored for payment details tab in the supplier window id stored in IBY_EXTERNAL_PAYEES_ALL instead of po_vendor_sites.

So changed the query from

SELECT remittance_email
INTO p_email_address
FROM po_vendor_sites
WHERE vendor_id = l_vendor_id
AND vendor_site_id = l_vendor_site_id;
to
SELECT remit_advice_email
INTO p_email_address
FROM IBY_EXTERNAL_PAYEES_ALL
WHERE supplier_site_id = l_vendor_site_id;


Solutions.:-


1) Please download and review the readme for patch 6119080:R12.AP.A.
6119080:R12.AP.A - brings appewfpb.pls 120.2.12000000.2 which just fixes the bug 6119080 (AP_PAYMENT_EVENT_WF_PKG.RULE_FUNCTION).
2) In a test environment, please apply Patch.6119080:R12.AP.A
3) Please confirm the following file versions:
$AP_TOP/patch/115/sql/appewfpb.pls 120.2.12000000.2
You can use the commands like the following:
strings -a ffffffff |grep '$Header'
4) Bounce all application services (adstpall.sh apps/<apps> & adstrtal.sh apps/<apps>).
5) Please retest the issue.
6) If the issue is resolved, please migrate the solution as appropriate to other environments.

How To Create a Customer That is Also a Supplier

Step to create customer as a supplier:

1. Enable the profile option at site level : POS:SM: Supplier Data Hub Configuration

2. Set this profile option to "Standalone" if you are implementing Supplier Hub as a Standalone MDM instance.


3. Steps below to reproduce the same:

a. Create Customer Party
b. Login to Supplier Data Librarian Super User responsibility
c. Click "Select" and click the "Enable As Supplier" button & Save
d. Search for the customer created.
e. Navigate to Payables --- Supplier page and see "Enable As Supplier" option available
f. The customer that was enabled as a supplier is now available for further action.

Error: This transaction type does not have any action types for the rule type selected. Ensure you add the selected rule type's action types to this transaction type to use in a rule.

Issue:

Error: This transaction type does not have any action types for the rule type selected. Ensure you add the selected rule type's action types to this transaction type to use in a rule.

Fix:

1. Navigate to Approvals Management Business Analyst Responsibility > Business Analyst Dashboard

2. Payables Invoice Approval> Setup

3. Action types tab > Select Use Existing Action Type

4. Select Name = Pre-chain of authority approvals having Rule type = Pre List approval Group.

5. Now Create Rule > Enter Details > Click next > no error received. > AME setup done without error

Can Payment Currency be Different than Invoice Currency in Release 12?

Payment Currenncy:


The default for payment currency in the suppliers window is the value you enter for supplier Invoice Currency. You can change the Payment Currency value only if the Invoice Currency has associated fixed-rate currencies (for example, euro). If the Invoice Currency is a fixed-rate currency, you can change the Payment Currency value to an associated fixed-rate currency. The supplier Payment Currency is used as a default for all new supplier sites you enter. The supplier site Payment Currency is the default for the Payment Currency field in theInvoices window. It is also the default currency for invoices you create for this supplier site by using Payment on Receipt, Payables Open Interface Import, and Recurring Invoices.


Invoices:

Payment Curr. (LOV) :
If the Invoice Currency is not a fixed-rate currency, then the Payment Currency will be the same as the Invoice Currency and you cannot enter a value in this field.
If the payment currency is a fixed-rate currency, such as euro or another EMU currency, you can change it to an associated currency. For fixed-rate currencies, the payment
currency value defaults from the supplier site. If the supplier site has no default payment currency, the value defaults from the Invoice Currency. If you change the Invoice Currency then the value for Payment Currency will change to the value for Invoice Currency.

APP-SQLAP-10771: Could not reserve record.

 

Error:

APP-SQLAP-10771: Could not reserve record.

Unable to pay the AP invoice in full, Got above error while performing the action –> pay in full

Solution:

Database lock from another session is present on the table AP_INVOICES_ALL, AP_INVOICE_LINES_ALL, AP_INVOICE_DISTRIBUTIONS_ALL for the same record that user was trying to modify from application.

1) To determine what session has a lock on this record, please execute the following steps:
         a) Run the following to determine what tables are locked:
                --- --- ---
                SELECT a.object_id, a.session_id, substr(b.object_name, 1, 40)
                FROM v$locked_object a, dba_objects b
                WHERE a.object_id = b.object_id
                AND b.object_name like 'AP_%'
                ORDER BY b.object_name;
                --- --- ---
         b) Look at the results and insert whatever AP_% tables are returned from a) into the script below:
                --- --- ---
                SELECT l.*, o.owner object_owner, o.object_name
                FROM SYS.all_objects o, v$lock l
                WHERE l.TYPE = 'TM'
                AND o.object_id = l.id1
                AND o.object_name in ('AP_INVOICES_ALL', 'AP_INVOICE_LINES_ALL', 'AP_INVOICE_DISTRIBUTIONS_ALL');
                --- ---
                SELECT SID, SERIAL#
                FROM v$session
                WHERE SID = <SID from b)>;
                --- --- ---
  2) Once the locking sessions have been identified, please use the below command to kill such sessions.
            --- --- ---
            ALTER SYSTEM KILL SESSION 'sid,serial#' IMMEDIATE;
            ---
            Note: SID and serial# to be taken from the output from 1c).
            --- --- ---

Alternative Solution
==============
If there are many items locked you may find it easier to follow this alternative solution:
   a) Ensure no-one is working and no processes are running in the system.
   b) Bounce the database.
   c) Retest the issue.

The Reconciled and Reconciled but Unaccounted Status Mean For Payments

Account for Payment When Payment Clears Payables option is enabled.

Created invoice and accounted.
Created payment and accounted (status of payment is Negotiable).
Cleared payment - Status on payments form is Cleared but Unaccounted.
Accounted - status went to Cleared.
Reconciled - status went to Reconciled.



Cleared:- The bank has disbursed funds for the payment, and the payment has been cleared, but not matched to a bank statement within Oracle Cash Management. Payables uses this status when the Account for Payment When Payment Clears Payables option
is enabled.

Cleared But Unaccounted:- The bank has disbursed funds for the payment and the payment has been cleared but not matched to a bank statement within Oracle Cash Management. Payables uses this status when the Account for Payment When Payment Clears Payables option is disabled.

Reconciled:- The bank has disbursed funds for the payment, and the payment has been reconciled and matched to a bank statement in Oracle Cash Management. Payables uses this status when the Account for Payment When Payment Clears Payables option is enabled.

Reconciled But Unaccounted:- The bank has disbursed funds for the payment, and the payment has been reconciled and matched to a bank statement in Oracle Cash Management. Payables uses this status when the Account for Payment When Payment Clears Payables option is disabled.

Create Accounting for a Payment generates errors 95333 and 95359

 

Error:

95333: A conversion rate does not exist to convert USD to AUD for the conversion type Corporate
and conversion date 20-MAR-09 for line -25. Please use the Daily Rates form in General Ledger to
enter a conversion rate for these currencies, conversion date and conversion type.

95359: There is no accounted amount for the subledger journal entry line. Please inform your
system administrator or support representative that: The source assigned to the accounting
attribute Accounted Amount has no value for extract line number 88547. Please make sure the source
assigned to the accounting attribute Accounted Amount has a valid value, or assign a different
source to this accounting attribute.

Solution:

1. Specify a conversion rate for the currencies and conversion date mentioned in the error message 95333

Navigation under the General Ledger responsibility: Setup > Currencies > Currency Rates Manager > Daily Rates > click on the Create Daily Rates button Enter the From Currency, To Currency, Rate Type, Start Date, End Date and Rate, then click Apply

2. Run the AutoRate concurrent program in Payables

Go to the Submit Request window in Payable and submit the AutoRate concurrent process

3.Re-run the Create Accounting process for the transactions that received errors 95333 and 95359