Introduction: Customers will often ask purely functional questions on the phone support line. These questions are usually on the order of "How do I ...”. Most times the analyst will explain how to perform the procedure, then point to the passage in the manual that describes this functionality in depth. Sometimes even the most careful reading of the Topical Essays does not provide an answer. In these cases the analyst may just have to say: "Payables does not have this functionality now, but I can log an enhancement request." If the desired functionality is critical, you could customize an existing form or create a whole new form or process to accomplish your needs. This opens up a number of possible complications. Customizations require careful design and coding, and you would have to re-implement any customizations to a standard process when you apply a patch from Support to update that process. You can explore another avenue when trying to implement a process that is not explicitly defined in the manuals. With sufficient knowledge of how the system works, you can create a workaround that will implement the functionality required, without actually writing any custom code. This paper will examine a workaround for five such processes: third party payments, internal bank transfers, manual journal entries made in Payables, supplier refunds, and 1099 invoice adjustments after payment. You implement third party payments and internal bank transfers by manipulating how Oracle Payables posts invoice and payment information to the General Ledger. You implement manual journal entries and supplier refunds by manipulating how Oracle Payables posts zero amount invoices and Standard Invoice/Debit Memo pairs. These four procedures are based on the following assumption: the ultimate purpose of the Payables system is to post journals to the General Ledger system that accurately reflect the Payables activity. If the Payables system makes correct net accounting entries, then the process is valid. The 1099 processing workaround also uses Standard Invoice/Debit Memo pairs, but does not rely directly on GL Posting.

 

Third Party Payments: A third party payment is when you create an invoice to one supplier, but ultimately send a payment on this invoice to another supplier. One of the most common examples of this functionality would be the use of procurement cards to handle some purchasing, such as using a company credit card to purchase office supplies. An invoice with a distribution to the office supplies account is created for the office supply vendor, but the payment made by check is to the credit card company. This is troublesome in Oracle Payables because in order to cut a check to the credit card company an invoice must be created. The supplier invoice is not being paid, at least not by reducing the cash in a bank account. It would be possible to zero out the supplier invoice and create an invoice directly to the credit provider, but 1099 processing makes this non-viable. In order for Payables to include a 1099 invoice in the 1099 form for a supplier, you must make a payment on that invoice to that supplier.

 

Overview: You implement third party payments using the following procedure. Create an invoice (the original invoice) to the supplier from which the purchase was made. Pay the original invoice using a special "dummy” bank account that has as its cash account an account of type Liability (the third party payee liability account). Later you create an invoice to a supplier that represents the third party payee. This invoice’s distributions will have the third party payee liability account as the expense account. Pay this invoice in a regular payment batch.

 

Setup

GL Responsibility, Segment Values form

[N] > Setup > Financials > FlexFields > Key > Values

 

In the Find Key Flexfield Segment window, enter "Oracle General Ledger” in the Application field, "Accounting” in the Title field, the name of the account structure you are using in Payables in the Structure field, and "Account” in the Segment field. Click the [Find] button. The system displays a list of valid account values. Create a new account segment value for each third party payee you want to track separately. If purchasing is done using one of three credit card accounts, then you should create three new account values. The exact value used will be dependent on the numbering scheme at your site. Each new account value created must have the qualifiers Allow Posting = "Yes” and Account type = "Liability”.

 

GL Responsibility, GL Accounts form

[N] > Setup > Accounts > Combinations

Enter the full code combination for each third party payee you want to track to separately. Use a value created above in the account segment. The values for the other segments should be entered according the account numbering scheme at your site. Accept all the defaults the system offers for the other fields in this form.

 

Create "Dummy” Bank Account (Required)

AP Responsibility, Bank form

[N] > Setup > Payments > Banks

Enter the bank and bank branch Name in such a way as to identify it as a non-standard bank and bank branch. The description should explain the exact nature of the bank. You need to define at least one bank and bank branch. You should relate all of the various bank accounts used for your third party payees to one bank and bank branch. Click the [Accounts] button. The Accounts window will display. In the Name field, enter something that will describe the third party payee. If the third party payee is a credit card company you could enter the name and possibly the account number. Leave the other fields in this region to the default values. You need to create one account for each third party payee. Choose GL Accounts in the alternate region drop down field. In the Cash Account field enter the code combination created for this third party payee. If you are using reconciliation accounting, also enter this code combination as the cash clearing account. Click the [Payables Documents] button. The Payment Documents window will display. Enter the Payment Document Name. This is a free form character field. You should enter "Combined” as the Disbursement Type. You can use any Payment Format in the LOV, since you will not be printing the payments. Choose Additional Information in the alternate region drop down field. Enter 0 as Last Used and some very high number (999999) as the Last Available document number. You should leave the number of setup documents and the clearing days blank.

 

AP Responsibility, QuickCodes form

[N] > Setup > Quickcodes > Payables

Enter "Pay Group” in the Type field, something descriptive, such as "CitiBank Credit Card Invoices” in the Name field, and a meaningful description for Description field. Let all other fields keep the defaulted value. You should create one Pay Group One for each third party payee.

 

Create Distribution Set (Optional)

AP Responsibility, Distributions Sets form

[N] > Setup > Invoices > Distribution Sets If the invoice to the third party payee will only have one distribution for the full amount of the invoice, then a distribution set should be assigned to the supplier site to speed up data entry. In the top portion of the Distribution Sets form enter something descriptive in the Name and Description field. These are free form character fields. Leave the other fields as defaulted. In the lower portion, enter "1” in the Num field and "100” in the Percent field. Enter the third party payee liability code combination for the third party payee in the Account field. Leave the other fields as the defaults.

 

Create New Supplier and Supplier Site (Required)

AP Responsibility, Suppliers form

[N] > Suppliers > Entry

Enter the Supplier and Supplier Site records for the third party payee as any other supplier. The actual values for the various fields are dependent on the policies at your site. Ordinarily there would be one Supplier and Supplier site per third party payee, but there could be situations where you would have more than one supplier site to a supplier. You could have several credit card accounts with the same credit card provider. In that case you could create Supplier record (CitiBank Visa), and multiple Supplier Site records (Account #1, Account #2, Account #3, etc.). Unfortunately the Supplier site name only allows for 15 characters and most credit card account numbers are 16 digits. If you are using a distribution set, you assign it in the Accounting alternate region of the Supplier Site window. Processing I will use the following business scenario to illustrate third party payment processing.

 

You have made a $100.00 credit card purchase, on a CitiBank Visa Card, for office supplies. You have already done all required setup.

 

Create Original Invoice

AP Responsibility, Invoice WorkBench

[N] > Invoices > Entry > Invoices

Processing of third party payments begins with the Invoice to the original supplier. You should enter this invoice according to your ordinary procedures with two exceptions. The Pay Group for the invoice should be the Pay Group that you created for CitiBank Visa (as the third party payee). You should enter "Immediate” for the terms. This assures that AutoSelect will pick up the invoice in the correct payment batch. Approve this invoice using normal procedures. The $100.00 invoice will generate the following

 

journals in the General ledger:

Account                Debit              Credit

Office Supplies      100.00

AP Liability                                 100.00

 

Pay Original Invoice on "Dummy” Bank Account

AP Responsibility, Payments WorkBench

[N] > Payments > Entry > Payments or Payment Batches

Now pay the original invoice on the bank account created for CitiBank Visa. If you are only paying one supplier, you should use a manual payment. This is one place where you must be careful. The system has no way to validate that the invoice being paid is actually for the third party payee associated with the bank account. Since you are not actually sending this payment to the vendor, you do not want to include any invoices that are not being paid by the third party payee. If you are paying more than one supplier at a time, you should use a payment batch. Start the Payment WorkBench as usual and begin to enter a payment batch. Enter the bank account and pay group that you set up for CitiBank Visa. You should enter all other options in the Payment Batches form as usual. Process the payment batch as usual with the following exception. You should not print the file created by this