Tuesday Oct 30, 2012

See the exciting new features available for iProcurement and Sourcing with 12.1.3 Rollup Patch 14254641:R12.PRC_PF.B!

See the exciting new features available for iProcurement and Sourcing with 12.1.3 Rollup Patch 14254641:R12.PRC_PF.B!

Functional Area

New Feature

Note Reference


Suppliers can now accept Terms and Conditions to comply with the buyer's Non-Disclosure Agreements (NDA). The PDF generation process has been enhanced to provide faster generation of negotiation PDFs containing large amounts of data.

Note 1499944.1 Sourcing New features From Procurement RUP Family R12.1.3 September Update 2012: Accept Terms and Conditions to Comply With NDA


Users can now do the following:

  • Requesters can specify the GL date (encumbrance date) for each distribution against a line at the time of creating requisitions.
  • Enter an Accounting Date on and Procurement Requisition, if Dual Budgetary Control is enabled for Purchasing.
  • Choose a Favorite Charge Account to override your default charge account, using the Preferences page.
  • Buyers can update the unit price, suggested supplier, and site details while requesting a catalog item (inventory item) that is not linked to a blanket purchase agreement.


Note 1499911.1 iProcurement New Features From RUP Family R12.1.3 September Update 2012: GL/Accouting Date,PO_CUSTOM_FUNDS_PKG.plb,Price and Supplier Update

For new features across all the Procurement product groups and information about applying Patch 14254641 see Note 1468883.1.

Monday Oct 15, 2012

FRM-40654 Error on Purchase Order Lines?? Stop Them Now by Applying Patch 14204845

Procurement Development has just released a new patch for Release 12 that will stop those annoying FRM-40654 errors on Purchase Order lines, before they occur.

When a Purchase Order (PO) is created through autocreate from a requisition line that accidently has blank spaces, this triggers a row lock and when the user tries to update the created PO the FRM-40654 error message ‘Record has been updated. Requery block to see the change’ occurs.

Development has added code to remove these leading or trailing spaces, thus avoiding the issue in the first place.  This patch has been added to the recommend patch list in Doc ID 1358356.1 'Recommended Patches for Purchase Order and Requisition Processing'.

 Be proactive and apply Patch 14204845:R12.PO.B now!

Tuesday Oct 09, 2012

Don’t Delay - Apply the New 12.1.3 Procurement Rollup Patch NOW!

A new critical rollup patch (RUP) has just been released by Development for our 12.1.3 Procurement customers.  This new Patch 14254641:R12.PRC_PF.B contains important fixes for Purchasing, Internet Supplier Portal (iSupplier), Sourcing  and iProcurement (Web). 

Go to My Oracle Support and enter Document ID 1468883.1 in the Knowledge Base search. This note contains information on who should apply the patch, how to apply the patch, critical fixes and important new features.

Thursday Oct 04, 2012

Understanding the Customer Form in Release 12 from an AR Perspective!!

Confused by the Customer Form in Release 12??  Read on, to get some insight into the evolution of this screen, and how it links in with Trading Community Architecture.

Historically, the customer data model was owned by Oracle Receivables (AR).  However, as the data model changed and more complex relationships and attributes had to be tracked and monitored, the Trading Community Architecture (TCA) product was created.  All applications within the E-Business suite that require interaction with a customer integrate with TCA.

Customer information is no longer stored in the individual applications but rather in a central repository/registry maintained within TCA.  It is important to understand the following entities/concepts stored in TCA:

  • Party: A party is an entity with whom you can have a potential business relationship.  A party can be either a Person or an Organization.  The Party entity is completely independent of any business relationship; this means that a Party can exist even if you have no transactions with it.   The Party is the "umbrella" entity under which you capture all other attributes listed below.
  • Customer: A customer is a party with whom you have an existing business relationship.  From an AR perspective, you can simplify the concepts by thinking of a Customer as a Party. This definition however does not apply to all other applications. In the Oracle Receivables Customer form, the information displayed at the Customer level is from TCA's Party information record.
  • Customer Account (also called Account): An account contains information about how you transact business with a particular customer.  You can create multiple accounts for a customer.  When you create invoices and receipts you associate it to a particular Account of a Customer.
  • Location: A Location is an address.  It is a point in space, typically identified by a street number, a street name, a city, a state or province, a country.  A location is independent of what it is used for - you do not associate a purpose to a location.
  • Party Site: A Party Site is associated to a Party.  It is the location where a party is physically located.  When defining sites for a Party, only one can be an identifying address.  However, you can define other party sites associated to a party. You can define purposes/usage for Party Sites.
  • Account Site: An Account Site is associated to a Customer Account. It is the location associated to the account you are transacting business with. You can define business purposes (also called site uses) for an Account site.

Read more about the Customer Workbench in these notes:

Doc ID 1436547.1 Oracle Receivables: Understanding the Customer Form in Release 12

Doc ID  1437866.1 Customer Form - Address: Troubleshooting, Known Issues and Patches

Doc ID  1448442.1 Oracle Receivables (AR): Customer Workbench Information Center

Do you find this type of blog entry useful?  Please add comments to let us know how we can help you more effectively.  Thank you!

Wednesday Oct 03, 2012

Announcing Oracle Receivables Generic Data Fix (GDF) for Refunds

Here's the first of what will be a series of Generic Data Fixes (GDF) to be released by Receivables Development.

Generic Data Fix (GDF) are created by development to fix data issues caused by bugs/issues in the application code.  Other Generic Data Fix benefits/features include:

  • Developed for bugs that can cause data issues.
  • Provides a SELECT script that uses an identification/signature query to identify and report all data affected by issue/condition caused by a bug.
  • Allow customers to view and modify what will be fixed.
  • Provides a separate FIX script to fix the data reported by the SELECT script.
  • The FIX script creates backup tables for the data that is fixed/updated.
  • Available on My Oracle Support for download

In Release 12, when creating a refund by either of the following methods:

  • Applied a receipt to the Refund activity - which creates an Invoice in Payables
  • Or you went directly into Payables to create a refund for an open Credit Memo in Receivables

The Invoice in Payables that is associated to the refund is cancelled, the corresponding refund application or credit memo in Receivables is not properly re-instated. For the receipt application, it still remains applied to the Refund whereas this should be automatically unapplied. For the credit memo, it stays closed instead of getting re-opened.

Doc ID 761993.1 includes the patch to make sure this doesn’t happen in the future as well as a GDF script to fix the current data (Script name: ar_std_refund_unapp.sql).  Download the script and run in READ_ONLY_MODE to identify 'refund' applications with this problem.

Stay tuned for more GDF scripts coming soon...

Tuesday Oct 02, 2012

Have You Used The Payables Master GDF Diagnostic Before? Well It Just Got Even Better!

The Master GDF Diagnostic has been around for a while and is used to detect and provide solutions for common data integrity issues in Oracle Payables.  It is updated regularly as new data corruption patterns are discovered so it’s always important to remember to check the version you have is the latest, each time you run it.  In fact just a few days ago the diagnostic was updated to include EBTax common corruption signatures so you can now scan your data for Invoices, Accounting, Payments, Suppliers and now EBTax corruption!

The current version of ap_gdf_detect_pkg.sql is 120.80 so check you have it downloaded!  You can even install it as a concurrent program and schedule it periodically!  

There’s a reason this note is the #1 Payables document used by support and customers to resolve SR’s – because it works - and it helps you resolve issues before you even know you have them.  Don’t delay - give it a try today and see what issues you can avoid by applying the datafix and code fix patches it suggests.  

R12: Master GDF Diagnostic to Validate Data Related to Invoices, Payments, Accounting and Suppliers [VIDEO] (Doc ID 1360390.1)

For more information on Generic Data Fix patches, including a complete list of GDF patches available, please see Doc ID: 874903.1


Welcome to the EBS Support Blog where Oracle insiders share news and information about EBS products including new releases, tips and tricks, troubleshooting guides, upcoming webcasts and links to EBS Communities.

Stay Connected



« October 2012 »