What are all obligation status values available in PSRM v2.5

The below are obligation status values are available by default in PSRM system:-

05 Incomplete - This status does not have any meaning in PSRM. It is an inherited status that is not used.

10 Pending Start - Obligations are typically created in this status however, the status itself does not have meaning in PSRM. The recommendation is to include an Obligation Creation algorithm to transition the obligation to Active.

20 Active - Obligations are in this state if they do not have an end date. Most obligations in PSRM have a start and end date covering the revenue period so obligations typically do not remain in this status but rather transition to Pending Stopped right away. Obligations that do not have an end date remain active, however the end date must be populated for the obligation to transition through the subsequent states.

30 Pending Stop - Obligations transition to this status when the end date is populated however the state doesn't have any meaning in PSRM. The recommendation is to include an Obligation Stop Initiation algorithm to automatically transition the obligation to Stopped.

40 Stopped - This state represents Obligations whose end date is populated and are waiting for the balance to be paid off so that it can be closed. (Note that algorithms can check that other conditions are met - like a valid tax form has been filed - before allowing an obligation to be closed.)

50 Reactivated - This state is used for obligations that were closed but where additional FTs were posted, causing it to reopen.

60 Closed - This state is used for obligations that were valid and where all the appropriate financial liabilities were posted and the obligation no longer has a balance. (As already mentioned, algorithms can check that other conditions are met before allowing an obligation to be closed.)

70 Canceled - This state is used to "logically delete" obligations that were created in error.


To summarize, in general most obligations will be created in Pending Start but immediately transition through Active > Pending Stop > Stopped right away assuming that the start and end date are populated at creation time and that the appropriate algorithms are plugged in to Obligation Creation and Obligation Stop Initiation as described above.


Obligations will typically be instantiated in one of the following the states:

> Stopped / Reactivated (Current outstanding obligations will be in one of these states)

> Closed

> Canceled


Most system logic that is checking for a 'current' obligation checks for obligations where the status is not Closed or Canceled.

How the GL Account Mapped in PSRM Financial Transaction

Accounting entries for financial transactions,

- Bill

- Payment

- Adjustment


Bill:- If a bill segment has a financial effect, the distribution code to debit comes from the distribution code on the obligation type; the distribution codes to credit come from the calculation lines used to calculate the bill segment. Calculation rules define the distribution codes to be used when creating bill calculation lines.

Payment:- Payment segments always have a financial effect; the distribution code to debit comes from the bank account on the tender source of the tender control of the tender, the distribution code to credit comes from the obligation type.

Note: The information in this topic refers to bills created using calculation rule based functionality. For details of the source of FTs for rate-based bills

How the adjustments affect the general ledger (GL) :-


• For many adjustments there is a single accounting entry generated:

• One side of the accounting entry is taken from the distribution code on the obligation type of the obligation affected by the adjustment. For example, if you are adjusting the payoff balance on a normal obligation, the A/R account is constructed from the distribution code on the obligation's obligation type.

• The other side of the accounting entry is taken from the distribution code on the adjustment's adjustment type.

• For transfer adjustments (i.e., adjustments used to transfer moneys between two obligations), there are two accounting entries generated - one for the "from" side and one for the "to" side. Each adjustment carries its own set of balanced GL accounting details.

• For each adjustment, one side of the entry is taken from the distribution code on the obligation type of the obligation affected by the adjustment

• The other sides of both accounting entries have the same GL account. This account should be the intermediate clearing GL account that is to be used for the transfer. The source of this clearing GL account is the distribution code on the adjustment type used to transfer the funds.

• For generated adjustments, the accounting entry may include several GL details:

• One side of the entry is taken from the distribution code on the obligation type of the obligation affected by the adjustment.

• The other side of the entry depends on configuration on the adjustment financial transaction algorithm. If it is configured to use the Calculation Lines as the source, the distribution codes are taken from the calculation lines. If it is configured to use the adjustment type as the distribution code source, the other side of the accounting entry is taken from the distribution code on the adjustment type.

PSRM basic accounting Entries:-

The table explained the basic PSRM accounting entries

Financial Transaction Example screen for Payment event:- 

Ways to submit batch processes in PSRM/ETPM

There are a number of ways of submitting batch processes within the Oracle Utilities Application Framework. The various ways reflect the different uses for the product at a site. The figure below summarizes the various submission methods:






• It is possible to submit the batch process in a basic interactive mode where the batch object executed in a single JVM. This mode is known as THIN mode and is primarily designed for developers to test their code in isolation from the rest of the system. The mode is not efficient enough to be recommended for any activity other than developer testing. Refer to Interactive Submission section for details on how to use this method.

• The product browser user interface allows the registration and execution of batch processes within the JVM used online. This mode allows part of the resources of online be devoted to registering and executing of batch processes. This method is primarily designed for use for testing purposes. Refer to the Online Submission section for details on how to use this method.

• Typically at a site, a batch scheduling tool is used to schedule and manage all of the background tasks required at a site. This can include running product batch processes and any related maintenance process such as transferring interface files to and from other systems, backup and other maintenance activities. This method is designed for production use and has a number of variations to support flexible scheduling options. Refer to the External Scheduler Submission section for details on how to use this method.

Tax Forms Common Lifecycle Statuses - Public Sector Revenue Management (PSRM)

Common Lifecycle of Tax Forms 

The base product supplies a parent business object for tax forms that defines the following lifecycle:

Pending
 
 The tax form is created in an initial state where processing rules are not yet executed. This allows the form to be saved as work-in-progress.

Validated
    A validation step verifies the information on the tax form. Validation form rules specific for the form type are executed to check the validity of the form data. Any issues detected at this step usually causes form processing to stop.

Suspended
    A tax form goes into this state when the validation step detects errors on the form that a user may be able to investigate and resolve. Exceptions are stored in the system so that a user can resolve the issues accordingly. The form needs to be re-validated after the issues are resolved.

Waiting for Information
    A tax form goes into this state when the validation step detects missing information, thus preventing the system from further proceeding with form processing. Exceptions are stored in the system so that a user can track the issues accordingly. In addition, this state usually triggers correspondence to the taxpayer, requesting for the missing information. The form is usually re-validated after the missing information is received.

Ready for Posting
    When a tax form passes validation, it transitions to Ready for Posting. From here a user may choose to make further changes by re-editing the form. Or the form can transition to Posted.
    Note: For implementations that use form control functionality, the tax form is only progressed to Posted by linking it to a form control that gets approved. Refer to The Big Picture of Form Control for more information.

Re-edited
    When a user is creating or correcting a form and it passes validation, there may still be a need to review and correct the data further. A form in the Ready for Posting state may be updated by transitioning it to Re-edited. The form needs to be re-validated once it is re-edited.

Posted
    When a tax form passes validation, it can be posted in the system. The posting of a form typically causes other data in the system to be added or updated. For example, adjustments are created for the assessments. Taxpayer data may also get updated based on newer information from the form. Posting form rules specific to the form type are responsible for the posting logic.

Adjusted
    A posted tax form can be adjusted for any of the following common reasons:

        Correcting data capture errors or data entry errors

        Line item adjustments initiated by the taxpayer

        Adjustments initiated from an audit

    When a tax form is adjusted, the financial effect of the existing tax form is canceled and new financial transactions are created for the updated line items. Note that the effects of adjusting a form are controlled by form rules.

Transferred
    A tax form can be transferred to a different taxpayer/obligation if it previously posted to the incorrect taxpayer/obligation.

    When a tax form is transferred, the current tax form transitions to Transferred and a new tax form is created, allowing a user to indicate the correct taxpayer / obligation. The financial effect of the existing tax form is removed from the current obligation using form rules. The new form goes through the same lifecycle of validation and posting and new financial transactions are created for the 'transfer to' obligation via the new form's posting rules.

Reversed
    Some exceptional cases may require that the financial effect of a tax form be canceled, without necessarily creating new financial transactions. A tax form reversal is a way of voiding a tax form that has already posted.

Canceled
    Forms that are not yet posted may be canceled if a user determines that the form was created incorrectly.

The base package provides a tax form business object C1-ParentTaxForm that has the lifecycle described above. Specific form business objects created using form generation are child forms for a common parent form BO so that the lifecycle is consistent for all forms. The base parent BO may be used or an implementation may create a custom business object. Refer to the business object meta-data for more details on the lifecycle, including the allowed transitions and the algorithms provided.

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

Check the opening and closing balances in the control totals

Issue: 

Check the opening and closing balances in the control totals.

Solution:


The Bank Statement Import program checks if the Control end balance matches:
(Control begin balance) + (Control cr amount) - (Control dr amount)

If not, it shows the warning, "Check the opening and closing balances in the control totals."

Here's the steps to address the warning:

Case 1:
Bank statement file does not provide the opening and closing balances and these optional fields are not populated.
So CONTROL_TOTAL_DR and CONTROL_TOTAL_CR are populated but not the begin and end balance.

Workaround:
Either null out the CONTROL TOTAL DR and CONTROL TOTAL CR, or populate begin and end balance for the Bank Statement Import Parameters.

Case 2:
CONTROL_BEGIN_BALANCE and CONTROL_END_BALANCE is populated but not CONTROL_TOTAL_DR and CONTROL_TOTAL_CR

The issue can occurr when there is a missing transaction code setup.

1 - With the Bank Statement in the Interface tables , navigate to the Bank Statement Interface form.

2 - Check the Bank Transaction Codes assigned to the Bank Statement Lines.

3 - Ensure Bank Transaction Codes identified on the Bank Statement are correctly setup in the system prior to importing the bank statement.

Please check the information from bank statement loader TDD:
-----------------------------------------------------------
After you load SWIFT940 bank statement files into the open interface tables,
you may need to define new bank transaction codes in Cash Management.
SWIFT940 transaction codes represent the type of transaction. For example,
TRF represents transfers. SWIFT940 transaction codes do not, however, contain
information about the debit or credit nature of the transaction. Instead,
the Debit/Credit Mark field is used to differentiate debit and credit
entries, where D means debit and C means credit. When the Bank Statement
Loader program populates the TRX_CODE column in the Bank Statement Lines
Interface table, it appends the Debit/Credit Mark to the transaction code to
form a new code. For example, debit transfers are identified as TRFD and
credit transfers as TRFC. You must set up these new transaction codes before
you can import the bank statement information.


4 - Once this is checked and corrected ( if required ), make a change to the Bank Statement in the Interface form and save.

5 - Now, try to import the Bank Statement.

Errors countered while attempting accounting. Engine encountered an nonrecoverable error during online accounting request 83. Details: see log file for more information

Error while doing the create accounting in fusion AP invoice cloud environment.

Error on screen:

Errors countered while attempting accounting. Engine encountered an nonrecoverable error during online accounting request 83. Details: see log file for more information

Error on Create accounting log file:

The accounting engine has encountered an irrecoverable error. (MODULE=xlaccoa_cache_coa) (PROBLEM=Error: accounting is not allowed for the Chart of Account: xxx COA Instance as it has one or more optional segments.)

Solution:

1. Navigate Setup and Maintenance
2. Implementation Project
3. Select the task Manage Chart of Accounts Structures and Manage Chart of Accounts Structure Instances tasks for Accounting Flexfield.
4. Make sure all segments are required, displayed and enabled.

Edit and enable the "Required" check box for all the segment.

save and close 

Deploy the chart of account to take effect the changes 

You can now try the created accounting, 

KFF has hit errors during validation phase: JBO-FND:::FND_KF_STR_NO_REQUIRED_LABEL: FND-2742You must assign a required label GL_ACCOUNT to at least one segment.In application 101, key flexfield GL#, and structure ..., you need to assign required segment label GL_ACCOUNT to at least one segment.

Issue:

KFF has hit errors during validation phase: JBO-FND:::FND_KF_STR_NO_REQUIRED_LABEL: <MESSAGE><NUMBER>FND-2742</NUMBER><TEXT>You must assign a required label GL_ACCOUNT to at least one segment.</TEXT><CAUSE></CAUSE><ACTION></ACTION><DETAILS>In application 101, key flexfield GL#, and structure ..., you need to assign required segment label GL_ACCOUNT to at least one segment.</DETAILS><INCIDENT></INCIDENT></MESSAGE>

Resolution:

In the Functional Setpup Manager (FSM) search for the task name Define Chart of Accounts
Click on Define Chart of Accounts - Manage Chart of Accounts
Search for your Chart of Accounts via the Module General Ledger

Click on Manage Structure Button
Search for your Chart of Accounts using the Name
Click the pencil icon to edit.

In the Segment Labels section shuttle Natural Account Segment and Primary Balancing Segment across to Selected Labels.
Save an close and deploy the flexfield again.

Please refer below steps screenshots 

Labels not selected.

Please select the required label

 

Deploy the flexfield once finish above step

Deployment in porcess

 

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.

How To Change GL Date or Receipt Date for a Receipt That Is Not Applied Or Posted to General Ledger

Once the receipt record is saved, the Receipt date and GL date can no longer be updated.

To change these dates, you would have to delete (or reverse) the receipt and re-create it with the correct dates.

Note: This is intended standard functionality

Unable to Delete Asset Categories from a Secured Responsibility in r12 Fixed Assets

When attempting to delete a category, which is not in use, from the Asset Category form
the following error occurs:

APP-OFA-48723 You cannot delete setup data from a secured responsibility.
The data may already be in use by assets or books that you do not have access to.
To delete setup data please use a non-secured responsibility.

Steps To Reproduce:

The issue can be reproduced at will with the following steps:
1. Connect to an FA secured responsibility
2. Navigate to the Asset category form
3. Try to delete a category which is not in use
The issue is caused by the secured responsibility :
When you try to delete an asset category , the application checks if it is already in use , meaning whether an asset or a mass addition exist with this category attached.
From a secured responsibility , you could only verify for the assets/books you have access to therefore this functionality is not allowed .

This is intended behavior.

Solution:-

1. Go into an FA non-secured responsibility to delete any Asset Category which is not in use.

You can verify if  a responsibility is not secured with following steps:
Connect to System Administrator responsibility
Navigate to Profile > System
For the FA responsibility , query Profile FA:Security Profile
No value should be assigned.

As a workaround , you could momentarily remove the profile value in order to delete the wrong Asset category and then reset the profile back.

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.

How to Change Payment Term For Invoices Which Are Posted Into GL

As per user guide, it is not allowed to change the Payment Term after a transaction has been posted.

Also, there is no API that allows update to existing transactions.

Note:  Setting profile option "AR: Update Due Date"  to 'Yes', allows you to change the Due Date of the invoice via the Account Details form

For further information please See section: Maintaining Transactions Field Reference

AR Payment term field mandatory Personalization..

We can use the below personalization to make the Payment Terms field as mandatory.

Please use the following steps in TEST before production:

Responsibility: Receivables, Vision Operations (USA)
Navigation: Transactions > Transactions
Go To: Help > Diagnostics > Custom Code > Personalize

1. Create a function with the following values:
Seq: 1
Description: Payment Term Name Mandatory
Level: Function

a. Under 'Condition' Tab
Trigger Event: WHEN-NEW-ITEM-INSTANCE
Trigger Object: TGW_HEADER.CT_REFERENCE_MIR
Condition: Processing Mode = Not in Enter Query Mode

b. Under 'Actions' Tab add the following sequences:
Seq: 1
Type: Property
Object Type: Item
Target Object: TGW_HEADER.RAT_TERM_NAME_MIR
Property Value: REQUIRED
Value: TRUE

2. Create another function with the following values:

Seq: 2
Description: Payment Term Name Mandatory 1
Level: Function

a. Under 'Condition' Tab
Trigger Event: WHEN-NEW-ITEM-INSTANCE
Trigger Object: TGW_HEADER.CTT_TYPE_NAME_MIR
Condition: Processing Mode = Not in Enter Query Mode

b. Under 'Actions' Tab add the following sequences:

Seq: 1
Type: Property
Object Type: Item
Target Object: TGW_HEADER.RAT_TERM_NAME_MIR
Property Value: REQUIRED
Value: TRUE



3. Save the changes.

4. Close all the forms.

5. Open Transactions > Transactions

6. Test the scenario.

7. Perform in other environments with business need.