APP-SQLAP-10199

Setup an Invoice Batch

Advantages of Invoices Batches

1. Enter invoice defaults at the batch level that override system or supplier site defaults for all invoices in the batch.

2. Maximize accuracy by tracking variances between the control invoice count and total and the actual invoice count and total resulting from your invoice entry.

3. Easily locate a batch online and review the name of the person who created the batch and the date it was created.

Responsibility: Payables, Vision Operations (USA)
Navigation: Invoices > Entry > Invoice Batches

APP-SQLAP-10199: You cannot navigate to the Invoice Batches window because batch control is not enabled for your system.

If you want to enable invoice batch control for your system, then ask your system administrator to enable the profile option AP: Use Invoice Batch Controls in the System Profile Options window.

Profile Option

AP: Use Invoice Batch Controls

YES -> Create the Invoice with batch
NO  -> Create the Invoice without batch.

To enter an Invoice Batch

1. In the Invoice Batches window enter a unique value in the Invoice Batch Name field. This name will appear on your reports and will help you locate the batch online.

2. Enter the number of invoices in the batch in the Control Count field.

Enter the sum of invoice amounts in the batch in the Control Total field. Payables tracks variances between the Control Count and Total and the Actual Count and Total as you enter invoices.

Note: If there is a discrepancy between the invoice amount and batch amount, Payables warns you when you exit a batch but it does not prevent Invoice Validation and payment of the individual invoices within a batch. You can make a correction immediately, or you can adjust the invoice batch later.

3. Enter any Invoice Defaults you want for the invoices. Defaults include: Currency, Type, Document Category, Hold Name, Liability Account, Payment Terms, Pay Group, GL Date, and Hold Reason.

These values you enter for defaults override any system and supplier site defaults for the invoices. For example, if you want the purchase order to provide the default value for Payment Terms on the invoice, then leave the Payment Terms field here blank. When you enter individual invoices you can override any values that default from the batch.

4. Choose the Invoices button and enter the invoices.

 
Responsibility: Payables, Vision Operations (USA)
Navigation: Invoices > Entry > Invoice Batches
 
Batch Name: ABC Batch

Oracle AP to GL Reconciliation Process

Month End reconciliation between GL and AP is highly recommended. If AP is interfaced to GL, verifying the balance between the two applications is usually

done through comparing account balances of the liability (A/P) account.

To reconcile your accounts payable activity for April, make the following calculation:

"Accounts Payable Trial Balance" as of March 31 +

"Posted Invoice Register" for the period between April 1 and April 30 -

"Posted Payment Register" for the period between April 1 and April 30 =

"Accounts Payable Trial Balance" as of April 30

> If total is not matching you will need to find out the root casue of difference:

Eg. Invalidated Invoice for the period

> For the PTD activity check the "period Close Exception" if there are any invoices and payments which are not transferred to GL.

> If the current period does not reconcile, please complete the reconciliation process for all prior periodsfrom the most recent to the earliest until you

get to one that reconciles.

Common Reasons for balance mismatch between AP & GL

1) Manual journal entries in the general ledger that involve an AP liability account will cause the AP Trial balance not to reconcile to the GL. These entries

are not included in the AP subledger so they will not be reflected on the AP Trial Balance Report.

Run the "GL Account Analysis" report for the liability account and for the date range in question. Look for transactions with a source other than Payables.

This can quickly pinpoint any transactions incorrectly charged to the account.

2) You performed a data fix in the past where you used the undo accounting script and swept a transaction forward from a closed period to re-account it, this

will cause an imbalance between AP and GL. The imbalance will be corrected in the period in which you made a GL adjustment to account for the fix.

3) Any correction you make during the journal import process will result in the line being changed in the general ledger, but not in AP

4) If you have deleted any AP batches or lines from AP batches out of the GL Interface, this will cause AP and GL to be out of balance

5) If the AP batch is still in the GL Interface, it will not be reflected in the GL reports and this will cause a difference between AP and GL.

6) Any AP batches that are un-posted in GL will cause a difference between AP and GL

Period End Close- Oracle Financials

Payables

1) Ensure all invoices are Validated

2) Ensure all invoices are Accounted

3) Payables will transfer only those invoices which are in the status of Validated.

4) Run the following reports:

Unaccounted Transactions Report- Gives you the details of Unaccounted transactions for the period

Payable Accounting Process Report- For Invoices pending to be accounted

Payables Transfer to General Ledger - Transfer the invoices and payment details to General Ledger

Mass Additions Report- Transfer the asset related invoices into Oracle Fixed Assets module

5) Close the Period

Receivables

1) Ensure all transactions are completed

2) Ensure all Receipts are entered and status changed to Cleared

3) Once everything is completed, Click on Navigation Control>General Ledger and run the report. This will transfer the details to General Ledger

4) Close the Period

Assets

1) Ensure additions, adjustments, retirements and others details are completed for all the assets in a particular period

2) Ensure current period additions are transferred from Accounts payable thru Post Mass Additions

3) Run Depreciation Projection report to see the depreciation for the current period. Randomly check the depreciation amount for different categories

4) Run the report Create Journal Entries process which will transfer entries to General Ledger

Cash Management

1) Enter the Bank statement details for each bank in Oracel Cash Management module

2) Reconcile the Payments and Receipts details manually

3) Then Run below reports

Bank Statement Detail Report- This report will show transactions for each bank

GL Reconciliation Report

General Ledger

1) Make sure all the journals are transferrred to General Ledger. Check whether all the details transferred from sub-ledger

2) Review the Journals and Post the details once all the details are correct

3) Run the Trial Balance Report

AP/AR Netting for different currencies

We are aware of AP/AR Netting for common currency means where invoices in AP and Transactions in AR booked in same currencies. But here i am discussing about AP invoices are booked in KES (Currency) because we pay in our functional currency to the supplier and AR Transactions are booked in USD or KES (Currency) where we receive from customer functional currency. For this scenario we have to perform AP/AR Netting.

Pre-Requisites Steps for performing AP/AR Netting

1. Netting Bank to be defined

2. Document sequence to be defined for Netting Payments, Payment Request, AP/AR Netting categories.

3. Supplier to be defined and some Open AP Invoices 

4. Customer to be defined with some open AR Transactions

Defining Netting Agreement

While Defining Netting Agreement, Select Netting Currency Rule as "Convert to Accounting Currency".  By selecting this option multi currency netting is enabled.

After defining the Netting Agreement. Define Netting batch using Netting Agreement. By executing the Netting Batch. Netting Batch picks open invoices and transactions of all currencies available.Please find the below screen shot of AR Transaction picked for Netting where Transaction currencies are USD & KES.

Below are Payable Invoices selected for Netting where currency is KES.

By clicking on submit. Netting batch is submitted and Multi - Currency netting is performed.

Oracle Payment Processing Request (PPR) in AP – R12

PAYMENT PROCESSING REQUEST FUNCTIONALITY-
In 11i we used Payment batches to pay for multiple invoices same time. In R12, PPR is the replacement of Payment batches. R12 PPR process enables payment Administrator to select multiple invoices for payment by selection criteria and he can pause the invoice selection and payment build process. During the invoice selection review, payment manager can review the invoice selected; if the invoices were validated or approved and hence did not get included in the payment process request. He can add or remove the invoices in the Payment process and also can check the cash requirements for the full payment. Payment manager can also dismiss the individual documents or payments if necessary, and restart the payment build process.
Steps in Pay run Process-
Managing a Pay run involves 3 main processes

• Selection of the invoices for payment
• Grouping the invoices into payments
• Building the payment instruction files to either print checks or send instructions to bank.

There are four steps in the processing of PPR:-

• Document selection – Handled by Payables(AP)
• Build Payments – Handled by Payments(IBY)
• Format Payments – Handled by Payments(IBY)
• Confirm Payments – Handled by Payables(AP)

Submitting a Single Payment Process Request
Mandatory fields – Payment Process Request name, pay through date, Payment date, and Exchange rate type.
Under Processing tab, options are available to stop the process after document selection/payment and also how to create the payment instructions:

1. Maximize Credits.
2. Stop Process for review after scheduled payment selection.
3. Calculate payment withholding and interest during scheduled payment selection.
4. Stop process for review after creation of proposed payments.

Click on submit to submit the Payment process request.
Document Selection – Payables
This process calls AP_AUTOSELECT_PKG.
When a payment process request is submitted, a record is inserted in AP_INV_SELECTION_CRITERIA_ALL with a checkrun_name i.e payment process request name. Invoices are then selected based on the due date, discount date, paygroup, and other criteria provided by the user while submitting the PPR.
The AP_SELECTED_INVOICES_ALL table is populated with the selected invoices and AP_UNSELECTED_INVOICES_ALL table by the unselected invoices.
Note: After selecting the documents, the invoices are locked to prevent other check runs from selecting the same invoices.
If the PPR has been setup to ‘Stop Process for Review after Scheduled Payment Selection’, the process stops for user review.
Then the status of the PPR is set to Invoices Pending Review.
If the ‘Stop Process for Review after Scheduled Payment Selection’ was not enabled, at the end of invoice selection, build program is submitted automatically.
If no invoices met the selection criteria and no payment schedules selected for payment, the PPR is cancelled automatically and the status of the PPR is set to “Cancelled – No Invoices Selected”. Then void all invoices
For others, the actions available are
a) Terminate the PPR
b) Modify / proceed to submit the PPR and start the build process.
Build Payments – Payments
Call IBY_DISBURSE_SUBMIT_PUB_PKG
Build payment creates records in IBY_PAY_SERVICE_REQUESTS with call_app_pay_service_req_code = checkrun_name.
A payment process request is a group of documents payable that a source product submits to Oracle Payments for payment service processing. This table contains the parameters like Calling application identifier, Internal bank account, Allow zero payments flag, etc. selected in the Payment Process Request.

PAYMENT_SERVICE_REQUEST_ID	NUMBER	System generated primary key
CALLING_APP_ID	NUMBER	Source product Identifier
CALL_APP_PAY_SERVICE_REQ_CODE	VARCHAR2	Source product’s payment process request Identifier. Since the source product’s Identifiers may be alphanumeric, even numeric document Identifiers are stored as VARCHAR2.
PAYMENT_SERVICE_REQUEST_STATUS	VARCHAR2	Payment process request status. Values from the lookup IBY_REQUEST_STATUSES include PAYMENTS_CREATED.
PROCESS_TYPE	VARCHAR2	Specifies the process by which documents payable are built into payments and payments into payment instructions. Values from the lookup IBY_PROCESS_TYPES include STANDARD, IMMEDIATE, and MANUAL.
ALLOW_ZERO_PAYMENTS_FLAG	VARCHAR2	Y or N flag that indicates whether zero payments are allowed for this payment request. If set to N, any zero value payments created for this payment request is failed.
INTERNAL_BANK_ACCOUNT_ID	NUMBER	Internal bank account identifier
MAXIMUM_PAYMENT_AMOUNT	NUMBER	Maximum payment amount used to override default maximum payment amount
MINIMUM_PAYMENT_AMOUNT	NUMBER	Minimum payment amount used to override default minimum payment amount

Note: The displayed status of the PPR is generated by ibyvutlb.pls
Following are the possible values of PAYMENT_SERVICE_REQUEST_STATUS column-

• DOCUMENTS_VALIDATED
• INFORMATION_REQUIRED
• INSERTED
• PAYMENTS_CREATED
• PENDING_REVIEW
• TERMINATED
• VALIDATION_FAILED
• COMPLETED

 In 11i AP_SELECTED_INVOICE_CHECKS_ALL table is populated by the Build Payment process.
The Build Program also populates IBY_DOCS_PAYABLE_ALL table
IBY_DOCS_PAYABLE_ALL– This table contains the documents payable which are updated by system while processing “Build Payments” program. A document payable is a supplier invoice or similar document that needs to be paid.  In addition, this table contains whatever document information is necessary for payment processing.
This table contains transaction details, document details, payer, payee, etc.”

Name	Datatype	Comments
PAY_PROC_TRXN_TYPE_CODE	VARCHAR2	Type of payment processing transaction or document
CALLING_APP_ID	NUMBER	Calling product Identifier
CALLING_APP_DOC_REF_NUMBER	VARCHAR2	Reference number entered by user of the source product. Need not be unique
DOCUMENT_PAYABLE_ID	NUMBER	Oracle Payments’ unique internal document payable Identifier
PAYMENT_FUNCTION	VARCHAR2	Function or purpose of the payment. Values from the lookup IBY_PAYMENT_FUNCTIONS include SUPPLIER_PAYMENT, CUSTOMER_REFUNDS, and others.
PAYMENT_DATE	DATE	Payment date
DOCUMENT_DATE	DATE	Date of document
DOCUMENT_TYPE	VARCHAR2	Type of document payable. Values from the IBY_DOCUMENT_TYPES lookup include INVOICE.
DOCUMENT_STATUS	VARCHAR2	Document status. Values from the lookup IBY_DOCS_PAYABLE_STATUSES include PAYMENT CREATED.
DOCUMENT_CURRENCY_CODE	VARCHAR2	Document currency code
DOCUMENT_AMOUNT	NUMBER	Total amount in document currency
PAYMENT_CURRENCY_CODE	VARCHAR2	Payment currency code
PAYMENT_AMOUNT	NUMBER	Amount to be paid in payment currency
PAYMENT_SERVICE_REQUEST_ID	NUMBER	Identifier of the payment process request in which this document was submitted
PAYMENT_METHOD_CODE	VARCHAR2	Payment method Identifier
EXCLUSIVE_PAYMENT_FLAG	VARCHAR2	Y or N flag indicating whether this document payable should not be grouped with any other documents payable.
CALLING_APP_DOC_UNIQUE_REF1	VARCHAR2	Source product’s first unique document payable Identifier
CALLING_APP_DOC_UNIQUE_REF2	VARCHAR2	Source product’s second unique document payable Identifier (Invoice_id)
CALLING_APP_DOC_UNIQUE_REF3	VARCHAR2	Source product’s third unique document payable Identifier(Payment_number)
CALLING_APP_DOC_UNIQUE_REF4	VARCHAR2	Source product’s fourth unique document payable Identifier
CALLING_APP_DOC_UNIQUE_REF5	VARCHAR2	Source product’s fifth unique document payable Identifier

A.  Internal Bank Account/Payment Process Profile Assignment:
Call IBY_ASSIGN_PUB
If the payment process request has the internal bank account and payment profile assigned to it, the same is assigned to all the documents in the PPR.If a default internal bank account and PPP were not provided when submitting the PPR, Oracle Payments attempts to default the values. If it cannot find a default value for all the documents, the PPR is set to INFORMATION REQUIRED status. The display status of the PPR is “Information Required – Pending Action”
User should complete the missing information and Run Payment Process to continue.
B.    Document Validation
Call IBY_VALIDATIONSETS_PUB

During this step, Oracle Payments validates all the documents using Payment Method based validations and then payment format based validations.b.1 – If all the documents pass validation, all the documents are set to a status of VALIDATED and the request status is set to ‘Documents Validated’.b.2 – If there are any validation failures, Oracle Payments uses the system option used while submitting the PPR to determine the next action.The DOCUMENT_REJECTION_LEVEL_CODE of the PPR can have the following values which determine how the document processing will continue when there is a validation failureb.2.1 – REQUEST
The status of the payment process request is updated to ‘Failed Document Validation’. Oracle Payments calls the calling application and AP releases the rejected documents so they can be paid through another Payment process request.
b.2.2 – DOCUMENT
Oracle Payments rejects all documents that failed validation. Oracle Payments then calls the calling application and AP releases the rejected documents so they can be paid through another Payment process request. The rest of the documents are set to VALIDATED status and the ppr is set to ‘Documents Validated’ status.
b.2.3 – PAYEE
Oracle Payments rejects all documents for the supplier that had one or more documents that failed validation. Oracle Payments calls the calling application and AP releases the rejected documents so they can be paid through another Payment process request. The rest of the documents are set to VALIDATED status and the ppr is set to ‘Documents Validated’ status.
c.     Create Payments
Call IBY_PAYGROUP_PUBThe validated documents are then grouped into proposed payments based on the grouping rules, both users defined and hard coded.
Example: If exclusive_payment_flag = Y on a document, it is paid on a separate payment.
It then numbers the payments (internal identifier not the check numbering) and validates the created payments.Records are inserted into IBY_PAYMENTS_ALL that holds the payment information for the selected documents.The build program then updates the IBY_DOCS_PAYABLE_ALL table with the payment_id and formatting_payment_id values that corresponding to the payment that pays the document.

IBY_PAYMENTS_ALL
This table contains all the payments created by system while processing “Build Payments”. A Payment can be single check or an electronic fund transfer between first party payer and third party payee. A row in this table corresponds to one or more documents payable. Payments are built by grouping documents payable according to Oracle Payments’ grouping rules.
This table also stores information of payments at grouping level. The groups can be Single, Mixed and grouped as defined in Payment Process Profile for the purpose of SEPA.
The payment details are displayed on the Payments tab of the Funds Disbursement Process Home page.

Name	Datatype	Comments
PAYMENT_ID	NUMBER	Unique internal Identifier for this record. Generated using a database sequence.
PAYMENT_METHOD_CODE	VARCHAR2	Payment method used for making the payments.
PAYMENT_SERVICE_REQUEST_ID	NUMBER	Payment service request Id and it is the foreign key to the table iby_pay_service_requests.
PROCESS_TYPE	VARCHAR2	Specifies the process by which the payment is built into a payment instruction. Values, from the lookup IBY_PROCESS_TYPES, include STANDARD, IMMEDIATE, and MANUAL.
PAYMENT_STATUS	VARCHAR2	The status of the Payment. Values are derived from the lookup IBY_PAYMENT_STATUSES. The possible values are CREATED, FORMATTED, TRANSMITTED, VOID_BY_OVERFLOW, REJECTED, FORMATTED, VOID, etc.
PAYMENTS_COMPLETE_FLAG	VARCHAR2	Y or N flag that indicates if the payment is complete
PAYMENT_FUNCTION	VARCHAR2	Function or purpose of the payment. Values from the lookup IBY_PAYMENT_FUNCTIONS include SUPPLIER_PAYMENT, CUSTOMER_REFUNDS, and others.
PAYMENT_AMOUNT	NUMBER	Amount of the payment
PAYMENT_CURRENCY_CODE	VARCHAR2	Currency of the payment
BILL_PAYABLE_FLAG	VARCHAR2	Y or N flag indicating whether a payment is a bill payable, that is, a future dated payment
EXCLUSIVE_PAYMENT_FLAG	VARCHAR2	Y or N flag indicating whether this payment is made up of a single document payable that was meant to be paid alone
SEPARATE_REMIT_ADVICE_REQ_FLAG	VARCHAR2	Y or N flag indicating whether a separate remittance advice needs to be generated for a payment.
INTERNAL_BANK_ACCOUNT_ID	NUMBER	Internal bank account id used for making the payment.
ORG_ID	NUMBER	Unique internal identifier of the Operating Unit. Validated against HR_OPERATING_UNITS.ORGANIZATION_ID.
ORG_TYPE	VARCHAR2	Organization type. Values, from the lookup IBY_ORGANIZATION_TYPES Include Operating Unit, Business Group, and Legal Entity
LEGAL_ENTITY_ID	NUMBER	Legal entity identifier

The PAYMENT_REJECTION_LEVEL_CODE can have the following values which determine how the payment processing will continue when there is a validation failure
Request – Entire PPR is rejected. Oracle Payments raises a business event that calls AP to release the documents. The status of the payment process request and proposed payments is updated to ‘REJECTED’.
Payment – Payments that failed validation are rejected and AP releases the documents that belong to the payment that failed validation. The other payments are accepted. The accepted payments get a status of ‘CREATED’.
None – Payments that failed Validation are set to ‘Failed Validation’ and allows for user intervention. Status of the PPR is set to ‘PENDING REVIEW’
If in the PPR setup, ‘Stop Process for Review After Creation of Proposed Payments’ is enabled, the PPR status is set to ‘Pending Proposed Payment Review’. This status prevents further processing until user takes action. If this option to stop for review is not enabled, the status of the PPR is set to ‘Payments Created’. In this status, payment instruction can be created for the PPR.

Format Payments – Payments

Call IBY_PAYINTSR_PUB, IBY_CHECKNUMBER_PUB

When a PPR is submitted, there are two options
The CREATE_PMT_INSTRUCTIONS_FLAG can be a Y or N
Y – Payment Instruction will be automatically created after payments are created.
N – Application waits for standard request submission for Payment Instruction.
The table IBY_PAYMENT_INSTRUCTIONS_ALL stores the payment instruction information.
If the PPR is setup to automatically submit instruction, the payment_service_request_id will be populated in iby_payment_instructions_all because the instruction will be specific to the PPR In this case, the instruction can be linked to the PPR using PAYMENT_SERVICE_REQUEST_ID
If the PPR processing is setup for the user to submit the instruction as a standard request, then when the instruction is submitted, then the instruction is linked to the PPR through the payments selected by the instruction.
The link in this case will be through iby_payments_all.payment_instruction_id
Key Columns of IBY_PAYMENT_INSTRUCTIONS_ALL table
Payment_instruction_id
Payment_profile_id
Payment_instruction_status
Payments_complete_code
Payment_count
Print_instruction_immed_flag
Transmit_instr_immed_flag
Internal_bank_account_id
Payment_document_id
Payment_date
Payment_reason_code
Payment_currency_code
Format:
The following processing occurs during the format step.
a) Number the payments – Check Numbering
b) Create XML Extract message
c) Pass the extract to XML publisher
d) Oracle XML Publisher (BI publisher) applies the format template
e) BI publisher formats and stores the output
f) Oracle Payments then updates the status of the Payment Instruction and the Payments. If successful, the status of Payments and Instruction is ‘Formatted’.
Print Checks:
a) Users can load stationery into the printer and print checks at this stage.
b) Determine if the checks printed ok. If not reprint
Confirm Payments – Payables
Call AP_PMT_CALLOUT_PKG

Record Print Status of the checks to confirm the payments. Oracle Payments calls ap_pmt_callout_pkg.payment_completed to confirm the payments.
This does the following:
a) Assigns sequence/values – Document sequencing.
b) Creates data in AP_CHECKS_ALL with appropriate data from IBY tables.
Checkrun_name = ppr name and checkrun_id = checkrun_id from IBY table.
c) Data inserted into AP_INVOICE_PAYMENTS_ALL for the corresponding checks.
d) AP_PAYMENT_SCHEDULES_ALL for the invoices are updated to indicate the payment details and status.
e) The documents paid in this PPR are released by setting the checkrun_id on the payment schedules to null.
f) AP_INVOICES_ALL is updated to show payment status
g) Data is deleted from the AP_SELECTED_INVOICES_ALL
h) Data is deleted from AP_UNSELECTED_INVOICES_ALL

Payment Due Calculation on AP invoice in oracle apps

Payables calculates payment Due Date using following values:

- Goods Received Date + Receipt Acceptance Days
- Invoice Date
- Terms Date

Payables populates the Payment Due Date with the most recent date among the above dates.

The logic is:
Most Recent( Goods Received Date + Receipt Acceptance Days, Invoice Date, Terms Date )

Goods Received Date:
            Goods Received Date gets populated on the invoice based on Terms Date Basis. We can find Terms Date Basis at following levels.
- Supplier Site Level
- Supplier level
- Payables Options

Payables first looks for Terms Date Basis at Supplier Site Level. If there is no value exist here, it will look at Supplier Level. If there is no value here as well, then Payables takes this value from Payables Options.

Receipt Acceptance Days:
         We can find Receipt Acceptance Days under Invoice Tab in Payables Options.

Invoice Date:
         We can find the Invoice Date in Invoice Date field on Payables Invoice.

Terms Date:
          Terms Date is the beginning date from which Payment Terms start when Payables calculates the scheduled payment(s) for an invoice. The invoice Terms Date defaults based on Terms Date Basis option you select:

• System: System date on day of invoice entry.
• Goods Received: The date you receive goods for invoices you match to purchase orders.
• Invoice: Invoice date.
• Invoice Received: Date you receive an invoice.


Payment Due Date calculation in case of a matched Invoice:

In case of a Matched invoice, Payables consider Receipt Transaction Date along with Goods Received Date + Receipt Acceptance Days, Invoice Date, and Terms Date.

The process includes two steps:

1. The system first checks for recent date of Goods Received Date+Receipt Acceptance Days and Receipt Transaction Date

The logic is:
Recent (GOODS RECEIVED DATE+RECEIPT ACCEPTANCE DAYS, RECEIPT TRANSACTION DATE)

2. After step1, the system uses the following logic again

Recent ( Recent Date from step1, Invoice Date, Terms Date)

Payables consider Receipt Date based on the “Recalculate Scheduled Payment” check box under Invoice Tab in Payables Options. If this check box is enabled, Payables consider the Receipt Date for the calculation of Payment Due Date. If you don't want the system to use Receipt Date in the calculation of Payment Due Date, then disable “Recalculate Scheduled Payment”.

If you want recalculation, then system considers Receipt date for a matched invoice.


Navigation to enable/disable “Recalculate Scheduled Payment”:
Responsibility:    Payables Responsibility which has the access to setups

Navigation:        Setup > Options > Payables Options
Tab:                   Invoice
                                                                       

 Enable/Disable Recalculate Scheduled Payment based on business requirements.

Payment Method In Oralce Apps

Payment Method:

A funds disbursement payment method is a medium by which the first party payer, or deploying company, makes a payment to a third party payee, such as a supplier. You can use a payment method to pay one or more suppliers. Oracle Payments supports several payment methods for funds disbursement, including the following:

• Check
• Electronic
• wire
• Clearing

Check:

You can pay with a manual payment, a Quick payment, or in a payment batch.


Electornic:

Electronic An electronic funds transfer to the bank of a supplier.You create electronic payments either through the e- Commerce Gateway, or by delivering a payment batch file to your bank. For both methods, Payables creates a file during payment batch creation. If you are using the e-Commerce Gateway to create the file of payments, an EDI translator is required to create the EDI Formatted file prior to delivering it to your bank.For electronic funds transfers, the file is formatted and delivered to your ap.out directory for delivery to your bank.

Wire:

Wire Funds transfer initiated be contacting the bank and requesting wire payment to the bank of a suplier.A payment method where you pay invoices outside of Payables by notifying your bank that you want to debit your account and credit your supplier’s account with appropriate funds. You provide your bank with your supplier’s bank information, and your bank sends you confirmation of your transaction. Your supplier’s bank sends your supplier confirmation of the payment. You then record the transaction manually.

Clearing:

Clearing Payment for invoices transferred from another entity within the company without creating a payment document.Payment method you use to account for intercompany expenses when you do not actually disburse funds through banks. You do not generate a payment document with the Clearing payment method. When you enter the invoice, you enter Clearing for the payment method.You can record a Clearing payment using a Manual type payment only.


Navigation: Payable Manager --> Setup --> Payment --> Payment Administrator.

Click on Go To Task.

 Click on Create button.

Enter the Payment Method name and code and then click on Next.

 
 Select the respective responsibilities which we want shown this payment method in these responsibilities.

Click on Next, Next, Finsh.

 

 

Table Detail:-

 

select distinct payment_method_lookup_code from ap_checks_all