Posted on December 29th, 2011 by Sanjit Anand |
Print This Post
|
Email This Post
In previous Post you have seen the functional overview for Refund Functionality in R12. This post will give more insight.
WHAT IS REFUND
Refund is kind of a single payment to a supplier or customer, usually to reimburse them for:
- one or more credit/debit memos on their supplier account in Oracle Payables
- one or more credit/debit memos on their customer account in Oracle Receivables
SENARIOS ...
In order to understand, presume you want to stop doing Business with a supplier
- You have an overall $100 credit balance with the supplier,which consists of a Credit Memo of $250 and an unpaid Invoice of $150
- The supplier sends you a $100 refund for the credit balance.
- You enter a $100 Refund Payment (a $100 negative payment), and on the Select Invoices window, you select the outstanding invoice and credit memo.
Once you save the Refund Payment, the invoice and credit memo are marked as paid, and you have no outstanding documents for the supplier
WHAT YOU NEED FOR THIS REFUND
- You need to do a set up the bank account in which you will deposit the refund. This can be the same bank account you use to make payments.
- Set up the appropriate cash account and, make sure cash clearing account is setup correctly
- The Payables documents you select must be in the same currency as the refund currency, and the sum of the documents you select must
equal the amount of the refund.
TAKE AWAY
When you have debit/credit memo on a supplier or employee account (generally due to over payments or returns) which cannot be
matched directly to any existing open invoices, the supplier or employee may send you a refund for the memos. In that case, you can record the "refund" against those memo(s) by recording a "refund" type of payment in the Payment Workbench.
- A Refund payment is a "negative" dollar amount payment issued to record the reimbursement received, and to clear the specified memo(s)
(and possibly, invoices) from the Aging Report.
- A Refund Payment can also be used to clear a credit balance on a supplier's or employee's account, and can consist of any combination of
the following documents, as long as the sum is negative and equals the refund amount:
- Invoices and/or Expense Reports
- Debit and/or Credit Memos
- Refund Payments can also be used to reimburse you for a Prepayment you paid to a supplier or employee that was later determined to be
unwarranted.
- If you receive a refund of a Prepayment, enter an invoice and apply the prepayment (if the Prepayment has not already been applied to an invoice),then enter a Debit Memo for the invoice.
- You can then pay the Debit Memo with the Refund Payment.
- Paying documents with a Refund Payment marks each selected document as paid, clears them from the Aging Report, and gives you a
complete supplier/employee transaction history.
- When you record a refund, Payables debits either your cash or cash clearing account, and credits either your expense or liability account,
depending on whether you use cash or accrual accounting.
- You can take discounts on payable documents (invoices/memos) that you mark as paid with a refund.
VOIDING REFUND
You can void a recorded Refund just as you would any other payment.
- Query up, then select the Refund in the Payments Workbench window.
- Choose the Actions button, and use the Void option in the Payment Actions window. You can then re-enter the refund and pay any open
and applicable invoices/memos or prepayments for the supplier/employee.
Hope this helps you to understand the refund functionlity.
Suggesting Reading
Posted in Oracle Payable | No Comments »
Posted on December 28th, 2011 by Sanjit Anand |
Print This Post
|
Email This Post
In response to a reader's query here is small note on EBS refund functionality.
Refund processing for the Supplier and Employee
When a supplier or employee sends a refund for an invoice payment that have made, record the refund can be recorded in Payables. A refund closes out an outstanding credit balance, so you are actually making a negative payment for a credit balance. The credit balance can consist of the outstanding balance of any combination of the following documents, as long as the sum is negative and equals the refund amount:
- Invoices
- Debit memos
- Credit memos
- Expense report
Paying these documents with a refund records each document as paid, and gives you a complete supplier transaction history.
Refund processing for the Customer
R12 There are two refund Options Available
- Initiation of a customer refund by application of a credit or unapplied cash to a refund receivables activity
- Automated refund generation based on credit memos generated by Auto invoice
- Check refunds
- Credit card refunds
In R12, the refund process has been automated for non-credit card transactions from Oracle AR module. For credit card transactions, refunds are applied to the same credit cards used on the transactions in Account Receivables. For non-credit card transactions, refunds are processed via AP. Receivables submit the refund request to AP, and in turn AP transacts refunds via Oracle Payments after gong through the approval process. To view the status of the refund, one can select the button "Refund Status" off the Receipt Application window which brings to the AP workbench. Following are the Refund process generated at receivable and then pass to payable to further processing and payment

Those who does not use Oracle AR as receivable, the refund data with customer basic information are fed into the Payable invoice where Customer will be created as one time supplier with minimum setup and check will be generated against the invoices created from refund data.
In case if you need some more thoughts on setup and steps , drop me offline
Posted in Oracle Payable, Oracle Receivable | No Comments »
Posted on August 30th, 2011 by Sanjit Anand |
Print This Post
|
Email This Post
The procurement card, or P-card, is a form of company credit card that is issued to employees who can then purchase goods and services without having to process the purchase through a traditional purchasing procedure, such as using purchasing requisitions and purchase orders.
Types of Commercial Cards
P-Cards are just one type of Commercial Card. Other Commercial Card comes with different name include the following. Each is intended to address different types of purchases and/or spend categories.
- Corporate Card – commonly used by organizations for employee travel and entertainment (T&E) expenses; also referred to as a Travel Card
- One Card – a single charge card that combines procurement with T&E and, in some cases, fleet and phone charges
- Fleet Card – a card product used by organizations to pay for fuel, maintenance, repair and related expenses on company vehicles
- Prepaid Card – debit-based card, allowing the user to pay now versus later, as the card transaction amounts are deducted from a funded account; for example, a Payroll Card "loaded" with an employee's earned wages
- Business Card – a credit card targeted for smaller businesses (in lieu of a P-Card), commonly used for a variety of expense types (e.g., goods, services, travel, etc.)
- Supplier P-cards: Supplier P-cards (or Ghost Cards) are another way for companies to incorporate electronic payment and settlement procedures in order to streamline their procure-to-pay processes. Instead of having to maintain a separate employee p-card for each requester in the company and each requester having to use his/her own employee p-card to make purchases, companies can maintain a single supplier p-card for each supplier/supplier site in the system, and consolidate all purchases from that supplier/supplier site on the single supplier p-card.
Procurement Card Pros & Cons
Advantages/Pros:
- Procurement cards reduce the cycle time of purchasing transactions
- Procurement cards can improve supplier relations as suppliers receive payment within 2-5 days
- Procurement cards can reduce the number of supplier invoices, which could lead to a reduction in expenses on accounts payable personnel
- With proper controls, procurement cards can restrict maverick buying as well as buying non-authorized categories of goods and services
- Procurement card programs foster a feeling of empowerment among employees
Disadvantages/Cons:
- Procurement card use exposes the organization to the potential for undetected credit card fraud and identity theft, which can result in lost money
- Procurement cards generally don’t provide the same level of budget visibility as an ERP system does
- Multiple ways of placing orders (e.g., Pcard, eProcurement, ERP, requisitions, etc.) can confuse requisitioners who may not know the proper method for each type of purchase
- Procurement card spend data may not be integrated with other purchase data, resulting in incomplete information when conducting spend analysis
P-Card in EBS
Within Oracle Applications, the Procurement Card Process to pay the supplier without compromising data security. This functionality can be used by any organization willing to pay the expenses of purchased goods from suppliers as well as service used by the individuals for company purpose.
Apart from that, the usage of P-card can be extended to pay suppliers that are currently in the process of self-billing. This process is new to oracle iExpense module but have great creditability and performance to its usage.
The card transaction files are received from the card issuer and then uploading into specified location of oracle server. Next upload these data into oracle interface table AP_EXPNESE_FEED_LINES_ALL. Then run the following oracle program from payables responsibility to generate the invoice. Once loaded, Oracle standard program will validate the transactions and generate distribution lines. Depending on the setup, users can verify the transactions as well as approve and invoice will be imported into AP through standard process which will execute sequentially as below:
- Procurement card Transaction Validation Program
- Procurement card Transaction Verification Program
- Procurement Card Transactions Approval Process
- Create Procurement card Issuer Invoice
- Payables Open Interface Import

In After successful execution of Procurement card Transaction Verification Program user can only change the distribution account and can validate the specific transactions. System have the provision to send notification for verification of transaction to the respective employee-manager hierarchy. The invoices are generated in payables with source as Procurement card .The payment can be made through Oracle standard payment process either with check or electronic payment.
Within Oracle ERP technology the functionality to store the sensitive information in system is compliant to PCI-DSS. This process is technically known as Encryption Process. Oracle standard single key encryption algorithm is used to store the sensitive data like credit card number, bank account number.
Posted in Oracle Payable | No Comments »
Posted on August 18th, 2011 by Sanjit Anand |
Print This Post
|
Email This Post
In the UK, Spain, France, Australia, Singapore, and many other countries, when an invoice is paid, a certain part of the payment is deducted and paid to the tax authorities as a withholding tax.
The global withholding architecture in any accounting appliction should provides functionality to meet the majority of processing and reporting requirements worldwide.
It Required various methods of calculating and reporting like :
- Statement of basis amount subject to Withholding by vendor/class – No Withholding per say and no accounting (Belgium, France).
- Percentage calculation, accounting and reporting (UK, Spain).
- Mixed mode of the two previous methods (Canada).
- Tier-based withholding percentage (Argentina, Japan)
- Additional withholding surcharges (India)
- Period-based withholding calculation with recalculation when it exceeds the threshold limit.
- Jurisdiction-dependent withholding percentage
- Withholding calculation based on relationship between business unit and vendor
- Ability to exonerate a vendor from withholding on a percentage basis.
Posted in Oracle Payable | No Comments »
Posted on August 11th, 2011 by Sanjit Anand |
Print This Post
|
Email This Post
This is another set of question asked by one of the reader in response of my previous post. For those companies using Oracle Internet Expense or similar application and enabled corporate card then might have to address PCI concerns, probably this post will be great help.
Does PCI DSS applicable to my client?
- If using corporate credit cards used by employees for company purchases like travel or office supplies
- The expense management is been used by iexpense or similar application.
The PCI DSS standard applies to all entities that store, process or transmit cardholder data. You can understood as these standard does equally apply to manual processing and storage of cardholder information as well as to electronic methods of storage. If you revisit the points mention in last post you can find with comments in blue.
According to the PCI DSS has six control objectives that are broken up into 12 high-level requirements:
- Build and Maintain a Secure Network.
- Requirement 1: Install and maintain a firewall configuration to protect cardholder data.
- You can just have a internal control in order to manage this.
- Requirement 2: Do not use vendor-supplied defaults for system passwords and other security Parameter
- Oracle locks and expires default accounts and passwords during installation.Passwords for administration accounts are prompted for during installation .
- Protect Cardholder Data.
- Requirement 3: Protect stored cardholder data.
- Data stored in Oracle Applications is encrypted for protection .
- Requirement 4: Encrypt transmission of cardholder data across open, public networks.
- You work with your development or DBA team , probably they confirm that the Credit Card provider’s FTP site is secure and transmissions from that site remain encrypted in transit.
- Maintain a Vulnerability Management Program.
- Requirement 5: Use and regularly update anti-virus software.
- You can have a internal control in order to manage this.
- Requirement 6: Develop and maintain secure systems and applications.
- Oracle Applications is PCI-DSS compliant
- Implement Strong Access Control Measures.
- Requirement 7: Restrict access to cardholder data by business need-to-know.
- You can just have a internal control in order to manage this.Oracle Applications standard security functions provide unique individual user accounts with specific responsibilities and accesses to control access to sensitive data
- Requirement 8: Assign a unique ID to each person with computer access.
- You can just have a internal control in order to manage this
- Requirement 9: Restrict physical access to cardholder data.
- You can just have a internal control in order to manage this.
- Regularly Monitor and Test Networks.
- Requirement 10: Track and monitor all access to network resources and cardholder data.
- You can just have a internal control in order to manage this.Oracle Applications provide standard functionality to monitor users and review their activity history.
- Requirement 11: Regularly test security systems and processes.
- You can just have a internal control in order to manage this.
- Maintain an Information Security Policy.
- Requirement 12: Maintain a policy that addresses information security.
- You can just have a internal control in order to manage this.
Similar Post
Posted in Oracle Payable | No Comments »
Posted on April 13th, 2011 by Sanjit Anand |
Print This Post
|
Email This Post
Oracle provides a complete enterprise imaging solution that can be deployed to eliminate paper and automate a variety of business processes. The main components in the imaging solution for invoice processing with E-Business Suite are:
- Oracle Document Capture
- Oracle Forms Recognition
- Oracle Imaging and Process Management
- Oracle E-Business Suite Adapter for Enterprise Content Management
With these four component you can turn your customers imaging solutions if you are using R12 with fusion middleware.
.... you are planning to implement , know high level flow ..
- Invoices scanned centrally or remotely (Oracle Document Capture)
- Data extracted and sent to Oracle (Oracle Forms Recognition)
- Invoices stored in central repository [(Oracle I/PM ) -Oracle UCM | Oracle I/PM | Oracle BPM Suite ECM Adapter]
- Invoice images & data accessed via Oracle [(Oracle I/PM ) -Oracle UCM | Oracle I/PM | Oracle BPM Suite ECM Adapter]
- Exception Handling Workflows & Real-time Monitoring [(Oracle I/PM ) -Oracle UCM | Oracle I/PM | Oracle BPM Suite ECM Adapter]
- Automated Approvals (Oracle ERP)
Will share some more insights on Oracle I/PM in next post.
Posted in Oracle Payable | No Comments »
Posted on February 27th, 2011 by Sanjit Anand |
Print This Post
|
Email This Post
Thanks to reader Ganesh, you pointing this functionality availability in EBS.Last time I observed this lacking functionality while one client migrated from SAP to oracle.
Good news for those having Oracle R12.1.1 , they can utilize this new functionality where a new attribute in the supplier form enabled them link the payee of supplier A to the payee for supplier B(alternate payee). Then after Payable department can enter an invoice you go to the Remit-To columns and set them to the alternate payee.
You need to update the supplier and create a relationship with the alternate supplier in the suppliers form. When new invoices are entered these remit to supplier fields at the invoice header default if just one relationship exists or can be selected from LOV if multiple exist. It appears that if there were multiple relationships this can be changed after validation but prior to accounting.
Check it out for more details at metalink #949183.1
Reference Post
Posted in Oracle Payable, R12 | No Comments »
Posted on December 18th, 2010 by Sanjit Anand |
Print This Post
|
Email This Post
When you are attempting to run Payables Open Interface Import and populated AWT related information, you might get the following error occurs.
"Line type cannot be AWT"
If you get this , donot get panic, this is intended functionality i.e Open Interface Import will not import invoices with an invoice type (INVOICE_TYPE_LOOKUP_CODE) of AWT (automatic withholding tax).
you can refer AP user guide(Part No. B25454-01) pg no 3-152
However you can have the Import process to calculate the withholding tax for the ITEM lines you are importing.
If you want to import invoices that include withholding information, you have these options:
- You can enter an INVOICE with the AWT_GROUP_ID or AWT_GROUP_NAME populated in AP_INVOICES_INTERFACE table, The withholding tax group you identify in this table (AWT_GROUP_ID or AWT_GROUP_NAME) is used to assign a withholding tax group to a line only if you do not identify one for the invoice in one of the following columns: AP_INVOICE_LINES_INTERFACE.AWT_GROUP_ID or
AP_INVOICE_LINES_INTERFACE.AWT_GROUP_NAME.
- Or you can just populate directly the AP_INVOICE_LINES_INTERFACE.AWT_GROUP_ID or AP_INVOICE_LINES_INTERFACE.AWT_GROUP_NAME for the ITEM line that you are importing.
- Or, if you setup the supplier site with Withholding information, then the Import process will inherit that information and create the invoices with the corresponding withholding lines.
You can refer back to old post for technical details. you can check some of old post on the subject.
PS: to make your legacy & AP tax calculation in sync please have AP & legacy tax structure same & for concern wrt decimal point you can set required Precision in Tax Financial option.
Posted in Oracle Payable | No Comments »
Posted on August 18th, 2010 by Sanjit Anand |
Print This Post
|
Email This Post
WHT functionality is offered in Oracle under AP module.
Similar to Automatic VAT processing, Oracle provides the feature for automatic WHT processing. To perform automatic withholding, assign a WHT group (not WHT) to an invoice or invoice lines. WHT group defaults from supplier site. If required, the user can override the default and select a different WHT group.
Typical configuration for Withholding Tax in AP broadly consist of the following four steps
- Payables Option: Withholding Tax Tab: Allow WHT in Payables Option window for the operating unit
To allow Automatic Withholding Tax for your invoices and expense reports, enable the Use Withholding Tax Payables option.
Navigation: Payables > Setup > Options > Payables > Withholding Tax tab
- Define your Withholding Tax Authority as Supplier with Venfor Type as ‘Tax Authority’
Define withholding tax authority supplier. Define this supplier as a Standard Supplier with Supplier
Type as ‘Tax Authority’. WHT invoices are created against these suppliers.
Navigation: Payables > Supplier > Entry
Define WHT codes with tax type as ‘Withholding Tax’ and enter the GL Accounts for the WHT accounting.
Navigation: Payables > Setup > Tax > Withholding > Codes
- Enable WHT on Supplier / Supplier Site for standard suppliers
You need to enable WHT on Supplier and Supplier site. Optionally you can also enter default WHT group for the supplier site.
Accept the default withholding tax group from the supplier site or select another from a list of values while raising the invoice.
Navigation: Payables > Supplier > Enter > Tax Details
Posted in Oracle Payable | No Comments »
Posted on June 18th, 2010 by Sanjit Anand |
Print This Post
|
Email This Post
This post is more for BSA's , IT Analyst and developer for more technical insights.
WHT Codes and Groups
- AP_TAX_CODES_ALL - this Hold WHT code name and description
- AP_AWT_TAX_RATES_ALL- This hold WHT rate
- AP_AWT_GROUPS WHT - This hold group name and description
- AP_AWT_GROUP_TAXES_ALL WHT - This hold group associated with WHT code
Here are the details for WHT related columns in the important tables:
- AP_INVOICES_ALL
- AWT_FLAG
- AWT_GROUP_ID
- PAY_AWT_GROUP_ID
- AP_INVOICE_LINES_ALL
- LINE_TYPE_LOOKUP_CODE (=AWT)
- LINE_SOURCE (=AUTO WITHHOLDING)
- AWT_GROUP_ID
- PAY_AWT_GROUP_ID
- AP_INVOICE_DISTRIBUTIONS_ALL
- AWT_FLAG
- AWT_GROUP_ID
- AWT_TAX_RATE_ID
- AWT_GROSS_AMOUNT
- AWT_INVOICE_ID (invoice id of WHT invoice)
- AWT_ORIGIN_GROUP_ID
- AWT_INVOICE_PAYMENT_ID
- AWT_WITHHELD_AMT
- WITHHOLDING_TAX_CODE_ID
- AWT_RELATED_ID
- PAY_AWT_GROUP_ID
- AP_INVOICES_INTERFACE
- AWT_GROUP_ID
- AWT_GROUP_NAME
- PAY_AWT_GROUP_ID
- PAY_AWT_GROUP_NAME
- AP_INVOICE_LINES_INTERFACE
- AWT_GROUP_ID
- AWT_GROUP_NAME
- PAY_AWT_GROUP_ID
- PAY_AWT_GROUP_NAME
- AP_EXPENSE_REPORT_HEADERS_ALL
- AP_EXPENSE_REPORT_LINES_ALL
Hope this helps.
Posted in Oracle Payable | No Comments »