R12: Master Troubleshooting Guide for Payment Process Requests (PPRs) for Oracle Payables

Posted by Mohammed Nasiruddin

1. What is a Payment Process Request (PPR), and How Are PPRs Created and Managed?      

What is a PPR?

Ans) In R12, a Payment Process Request, or "PPR", is a payment batch. The Payment Batch entry form used in R11i has been replaced in R12 by a new module called the Payments Manager module (IBY), which offers a number of new features related to payment batch processing.

How is a new PPR submitted?

Ans) Using the Submit a Single Request link on the Payments Manager Dashboard (or the button on the Search PPRs window), users are taken to a PPR entry form made up of a header and several tabbed regions. Users can enter search criteria for the invoices they want to pay, and parameters surrounding the payment process itself using the fields on the tabbed regions.

Modifying Payment Process Requests

You can modify the batch of invoices that the system selected for you, and the proposed payments generated by the system, using "review" windows along the course of the PPR process. These review "stops" are optional. When creating a new PPR, you can set parameters on the Processing tab that will cause the PPR process to stop after: 1) the system initially selects the invoices to be paid by the batch, and/or 2) after the PPR process has compiled the "proposed payments". This gives you an opportunity to review (and if necessary, modify) the invoices and "proposed" payments before they are turned into formatted Payment Instructions.

Terminating Payment Instructions

You can terminate a set of Payment Instructions at any time prior to marking the payments "Complete" - even if they have been printed - by using the Terminate icon on the Payment Instructions tab on the Payments Manager Dashboard. When this action is taken, Oracle Payments sets the status of the payment instruction to "Terminated", and informs the source product of the terminated documents payable. Then for each payment in the payment instruction, Oracle Payments sets the status to "Canceled". The source product unlocks the documents and resets their status so they are ready for future selection.

Stopping & Voiding Completed Payments

You can record a "Stop Payment" action or a "Void" action on one or more completed payments using thePayments tab on the Payments Manager Dashboard.

PPR Templates

To make entry of a new single PPR faster and easier, you can create a PPR"Template" with the search criteria and parameters that you typically use on your PPRs. Then when creating a new PPR, simply enter the name of the template in the header, and the pre-defined settings on the template are automatically copied to the fields on the header of your new PPR for you! You can accept the defaulted values, or edit them for the new PPR.

Scheduling PPRs using PPR Templates

You can use the name of a PPR Template as the Request Name on the Schedule Payment Process Request form in the Payments Manager module, allowing users to schedule PPRs to run automatically on a periodic basis, such as once/multiple times a day, once/multiple times a week, once/multiple times a month, etc. The scheduling parameters are generally the same as for scheduling Oracle Reports or other processes.

Required Setups

To maximize all the features available in creating Payment Process Requests (and to minimize the possibility of issues), you will want to become familiar with both the required and recommended setups that are necessary before running your first PPR. Some setups in the Payments module (IBY) are common to both theFunds Capture (receipts) and the Funds Disbursement (payments) roles that the module provides. They include:

·         access control

·         APIs

·         servlets

·         transmission

·         security

Configurable setups include:

·         Payment Methods

·         Bank Instruction Codes

·         Delivery Channel Codes

·         Payment Reason Codes

·         Payment Process Profiles ("PPPs")

·         Disbursement System Options

·         Payment Formats

·         XML Publisher Payment Templates

·         Internal Banks, Branches, and Bank Accounts

·         Suppliers

·         External Bank Account

• "Skipped" and "Spoiled" Check Numbers 
• Skipped Check Numbers:  If you use pre-numbered paper check stock when running a Payment Process Request ("PPR") in R12, you may have experienced a common issue faced by most Payment Administrators -- skipped checks during the printing process (most often when the batch was printed using a laser printer).  That is, one or more unused checks get "stuck" to the check above it in the feeder bin, and slip through the printing process unprinted.  When that happens, the check numbers that were actually printed and the check numbers that appear on the related payment reports are no longer in-sync with one another.  It's important that the system is informed of these "skipped" check numbers as soon as possible so your reports will reflect appropriate check numbers, and the Last Issued Document Number field on the Define/Update Payment Documents window for the associated Bank Account is properly updated as well.  Use theSkipped Payment Documents region on the Record Print Status window to manually enter the skipped check numbers before you confirm the PPR.
  Spoiled Check Numbers:  Another common issue that Payment Administrators often face is the dreaded "spoiled" check during a printing process.  A "spoiled" check is when your printer "eats up" (physically destroys) a payment document as it goes through the printing process -- usually causing the printer to stop until you remove the mangled document, and re-start the printer.  "Spoiled" checks can actually be defined as ANY unuseable paper payment documents (checks) that have become unuseable for ANY reason (for instance, perhaps one of your boxes of unused checks was destroyed due to a flood or fire).   So printer jams aren't the only cause for "spoiled" checks -- but they are the most common.  It's important that the system is informed of these "spoiled" check numbers as soon as possible, so your reports will reflect appropriate check numbers, and the Last Issued Document Number field on the Define/Update Payment Documents is properly updated as well.  Spoiled checks can be marked as "spoiled" in Oracle by either: 1) reprinting a replacement check for the supplier/creditor in the same PPR before confirming the PPR, or 2) manually marking the check number as "spoiled" on the Spoiled Payment Documents region of the Record Print Status window, and then paying the supplier/creditor on a later PPR or Quick Payment.
   
• 2. How does the PPR Process work?  Once the user has entered their desired parameters on the header of the PPR, and clicks on the Submit button, the PPR process follows the following four (4) program steps:
    DOCUMENT SELECTION ("AUTOSELECT")
  (Code: AP_AUTOSELECT_PKG): The Selection process is handled by Payables (AP), the calling product.
  When a PPR is submitted, a record is created in AP_INV_SELECTION_CRITERIA_ALL with a checkrun_name, which is the same as the PPR Name.
  
  • Selection: Invoices are then selected based on Due Date, Discount Date, Pay Group, and other criteria provided by the user while completing the PPR header.
  • The table AP_SELECTED_INVOICES_ALL is populated with selected invoices.
  • The table AP_UNSELECTED_INVOICES_ALL is populated with the invoices that were not selected.
  
  
  • Locking:After selecting the documents, the invoices are locked to prevent other check runs from selecting the same invoices.
  • AP_PAYMENT_SCHEDULES_ALL.checkrun_id is populated on the selected documents (invoices).
  
  
  • Review:If the PPR has been setup to Stop Process for Review After Schedule Payment Selection (option available on the header of the PPR), the process stops for user review after the initial selection of payables documents has been completed. The status of the PPR is set to "Invoices Pending Review". After the user reviews and/or modifies the selected documents, and clicks on the Submit button, AP calls the IBYBUILD program.
  • If the Stop Process for Review After Schedule Payment Selection parameter was not enabled, then at the end of invoice selection, the Build program is submitted automatically.
  • If no invoices met the selection criteria, the PPR is canceled automatically and the status of the PPR is set to "Canceled - No Invoices Selected".

        BUILD PAYMENTS

• (Code: IBY_DISBURSE_SUBMIT_PUB_PKG): The Build Payments process is handled by Oracle Payments (IBY).
  The Build Payments program first creates a record in IBY_PAY_SERVICE_REQUESTS with call_app_pay_service_req_code = checkrun_name.
  The Build Payments program goes on to populate the IBY_DOCS_PAYABLE_ALL table with the proposed payments.
  The link to the payment service request table is through the PAYMENT_SERVICE_REQUEST_ID.
  ·          
  • Internal Bank Account / Payment Process Profile Assignment(Code: IBY_ASSIGN_PUB): If the PPR has a default internal bank account and Payment Process Profile (PPP) assigned to it on the header of the PPR, the values are assigned to all of the selected documents in the PPR.
  • If a default internal bank account and PPP were not provided by the user on the header of the PPR, Oracle Payments attempts to default the values. If it cannot find a default value for all of the selected documents, the PPR status is set to "INFORMATION REQUIRED". The user display shows it as "Information Required - Pending Action". The user will need to use the Information Required window to provide the missing internal bank account(s) and PPP(s) for each selected document.
  
  
  • Document Validation (Code: IBY_VALIDATIONSETS_PUB): During this step, Oracle Payments validates all the documents (selected invoices & memos) using Pre-Defined and User-Defined Validations assigned to Payment Methods assigned to the selected documents. Afterward, the program validates all the documents again, using the Pre-Defined and User-Defined Validations assigned to Payment Formats associated with the PPPs specified on the PPR.
    
    If all the documents pass validation, all the documents are set to a status of VALIDATED in the tables and the request status is displayed as "Documents Validated".
    
    If there any document validation failures, Oracle Payments uses the parameter setting for "Documents" on the Validation Failure Results tab on the PPR header (the DOCUMENT_REJECTION_LEVEL_CODE) to determine the next action.
  • REQUEST: Reject all documents in this PPR
  • DOCUMENT: Reject only the document in error
  • PAYEE: Reject all the documents related to the supplier
  • NONE: Stop the PPR for review

Create Payments
(Code: IBY_PAYGROUP_PUB): The validated documents are then grouped into "proposed" payments based on the grouping rules - both User-Defined and hard-coded. It then numbers the proposed payments with an internal identifier (not "the" check number) and validates the payments.

• 
  
  Records are inserted into IBY_PAYMENTS_ALL that holds the payment information for the selected documents (invoices). The Build Payments program then updates the IBY_DOCS_PAYABLE_ALL table with the payment_id and formatting_payment_id values of the payment associated with each document.
  
  If there any payment validation failures, Oracle Payments uses the parameter setting for "Payments" on the Validation Failure Results tab on the PPR header (the PAYMENT_REJECTION_LEVEL_CODE) to determine the next action.
  ·          
  • REQUEST: Reject all documents in this PPR
  • DOCUMENT: Reject only the document in error
  • PAYEE: Reject all the documents related to the supplier
  • NONE: Stop the PPR for review
  If the PPR setup Stop Process for Review After Creation of Proposed Payments is enabled on the Process tab of the PPR header, the displayed PPR status is set to "Pending Proposed Payment Review". This status prevents further processing until user takes action.
  
  If this option to stop for a review is not enabled, the displayed status of the PPR is set to "Payments Created". In this status, payment instructions can be created for the PPR.
  

  FORMAT PAYMENTS

• (Codes: IBY_PAYINTSR_PUB, IBY_CHECKNUMBER_PUB): The Format Payments process is handled by Oracle Payments (IBY).
  When a PPR is submitted, the program checks the setting for the Create Payment Instructions parameter on the Process tab of the PPR header to determine if the associated payment instruction(s) (PI) should be created automatically after the payments are created (the CREATE_PMT_INSTRUCTIONS_FLAG = Y), or if the program is to wait for a manual kick-off of the Format Payment Instructions program through the Standard Request Submission form (SRS) (the CREATE_PMT_INSTRUCTIONS_FLAG = N).
  
  • If the PPR is set up to automatically submit instruction(s), 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(s) can be linked to the PPR using PAYMENT_SERVICE_REQUEST_ID.
  • If the PPR is set up for the user to submit the instruction program manually on the SRS form, then when the instruction(s) is submitted, the instruction(s) is linked to the PPR through the payments selected by the instruction(s). The link in this case will be through the payment_instruction_id in IBY_PAYMENTS_ALL.
  In addition, the following processing occurs during the Format Payments step (see The Extract and Format Operation Flow section in Note 1348102.1 "R12: Master Troubleshooting Guide for Oracle Payables Payment Formats & associated XML Publisher Templates"):
  • Number the payments (paper checks and possibly, electronic payments)
  • Create XML extracted message
  • Pass the extract to Oracle XML Publisher (also known as "BI Publisher")
  • XML Publisher applies the formatted template to the payments
  • XML Publisher formats and stores the output
  • Oracle Payments then updates the status of the Payment Instruction(s) and the PPR. If successful, the displayed status of the PPR is "Formatted", and the status of the Payment Instruction(s) will be "Formatted" for electronic payments and "Formatted - Ready for Printing" for check payments
  • Print checks:
  • Users can load stationery into the printer and print checks at this stage by clicking on the Take Action icon for the related Payment Instruction on the Search PPRs window.
  • Determine if the checks printed OK, and if so, click on the Take Action icon again to be taken to the "Record Print Status" window, and click on the Record Print Status button. If there were problems with the printing process (paper jams, skipped checks, etc.) -- especially if you are using pre-numbered check stock -- use the Reprint button to reprint the batch and record any spoiled (ruined) and/or skipped check numbers.
  • Transmit electronic payments:
  • Electronic payments can be transmitted at this point.

       CONFIRM PAYMENTS

• (Code: AP_PMT_CALLOUT_PKG): The Selection process is handled by Payables (AP).
  In order to confirm the printing of paper checks, the user needs to use the Record Print Status window to confirm which pre-numbered paper stock printed OK, and which (if any) were skipped or were damaged beyond repair ("spoiled").
  Oracle Payments calls ap_pmt_callout_pkg.payment_completed to confirm the payments. During this step, the program does the following:
  • Assigns sequence values for Document Sequencing (Vouchering).
  • Creates data in the AP_CHECKS_ALL table with the appropriate data from the IBY tables.
  • Inserts data into the AP_INVOICE_PAYMENTS_ALL table for the corresponding checks.
  • The documents (invoices) are updated in the AP_PAYMENT_SCHEDULES_ALL table to indicate in the Invoices Workbench the payment details and status.
  • The documents not paid in this PPR are released by setting the checkrun_id on the Payment Schedules to NULL.
  • The AP_INVOICES_ALL table is updated to show the payment status in the Invoices Workbench for those documents that were paid by the PPR.
  • Data for this PPR is deleted from the AP_SELECTED_INVOICES_ALL table.
  • Data for this PPR is deleted from the AP_UNSELECTED_INVOICES_ALL table.
  "Completing" Electronic Payments: Electronic payments are not "confirmed" in the same way that paper documents are handled. The system will automatically mark electronic payments as "completed" based on the setting you chose for the "Completion Point" field on the header of the associated Payment Process Profile (PPP):
  • "Built" = the payments will be marked as "complete" when the Build process completes
  • "Payment Instruction is Created" = the payments will be marked as "complete" when the PI is created
  • Payment Instruction is Formatted" = the payments will be marked as "complete" when the PI has successfully completed the Formatting process
  • "Payment Instruction is Transmitted" = the payments will be marked as "complete" when they are transmitted"

3. PPR Reports: There are several reports related to PPR processing

• • • Payment Process Request Status Report: The Payment Process Request Status Report is a report that you can run that displays proposed payment information. You can request the report to run automatically after proposed payments have been created and validated or run the report by standard report submission. The report provides parameters, such as the Payment Process Request name/identifier and runs if the Payment Process Request status is "Payments Created".
    • Payment Instruction Register: Once a payment instruction has been formatted, payments within that payment instruction can be reviewed in report format. The Payment Instruction Register can be run at any time after payment instruction creation. The report lists the various statuses of payments within the payment instructions, such as Formatted or Transmitted.
    • Separate Remittance Advice:The Separate Remittance Advice is a report sent to a payee that lists the documents payable paid as part of each payment. You can specify the format for the remittance advice document and the delivery method.
    • Positive Pay: A positive pay file is a security measure in the form of a document that the deploying company sends to its payment system or bank to inform it of payments made by check. When you print checks, then you can electronically transmit a list of payments to the bank or payment system that indicates the checks you printed, so the bank or payment system knows what checks to pay. This list prevents the payment system or bank from paying fraudulent checks, since such checks are not listed on the positive pay file.
      
      R12 Oracle Payments offers two versions of the Positive Pay report:
    ·         the Positive Pay File program, and
    ·         the Positive Pay File with Additional Parameters program.These programs replace the R11i report called the Positive Pay Report.
    
    

5. Alternatives to using Payment Process Requests

• • Creating PPRs is the only method of creating payments in the Oracle Payments module (IBY), but you can still create single payments using the Payments Workbench form in Oracle Payables (AP). There are three types of single payments that you can create using the AP Payments Workbench form:
    
    • Quick Payment = a single computer-generated payment to be generated and printed or transmitted using Oracle
    • Manual Payment = a single payment already generated outside of Oracle (such as bank wires, hand-written checks, etc.)
    • Refund = a single payment to a supplier, usually to repay one or more overpayments received in Oracle Receivables, or to refund a credit account balance in Oracle Payables.
    Remember that the Payments Workbench is limited to creating only single payments, and requires that the user manually select the desired invoices and/or memos to pay.
    Payment Process Requests (PPRs), on the other hand, are by far the most popular and heavily used payment programs for Oracle users because the Oracle Payments disbursement engine enables you to greatly simplify your procedures for managing complex payment processes that span multiple payment methods, formats, check stocks, transmission protocols, currencies, organizations, and bank accounts.
  
  

Receivables Setups in R12

Posted by Mohammed Nasiruddin

Receivables overview:


Accounts receivable is an asset account in the general ledger that documents money owed to a business by customers who have purchases goods or services on credit.
Accounts receivable can be contrasted with accounts payable, a liability account in the GL that documents money the business owes for the purchase of goods or services.
Accounts receivable, accounts payable and payroll are usually listed as the top three mission-critical business processes in a disaster recovery plan .


Receivables Workbenches:

Oracle Receivables provides four integrated workbenches that you can use to perform most of your day–to–day Accounts Receivable operations. You can use the Receipts Workbench to perform most of
your receipt–related tasks and the Transactions Workbench to process your invoices, debit memos, credit memos, on–account credits, chargebacks, and adjustments. The Collections Workbench lets you review customer accounts and perform collection activities such as recording customer calls and printing dunning letters. The Bills Receivable Workbench lets you create, update, remit, and manage your bills receivable.

Each workbench lets you find critical information in a flexible way, see the results in your defined format, and selectively take appropriate action. For example, in the Transactions Workbench, you can query transactions based on the bill–to or ship–to customer, currency, transaction number, or General Ledger date. You can then review financial, application, and installment information, perform adjustments, create a credit memo, or complete the transaction. All of the windows you need are accessible from just one window, so you can
query a transaction once, then perform several operations without having to find it again.


Receivables Setups in R12:

Overview of Setting Up:

During setup, you define business fundamentals such as the activities you process and their accounting distributions, your accounting structure, and various control features. Setup is also the time to define
comprehensive defaults that Receivables uses to make data entry more efficient and accurate. In addition, setup lets you customize Receivables to employ the policies and procedures that you use in your business.
You can set up Receivables a number of different ways. The following graphic shows the most complete setup scenario. If you use the Oracle Applications Multiple Organization Support feature to use multiple sets of books for one Receivables installation, please refer to the Multiple Organizations in Oracle Applications manual before proceeding. If you plan to use Oracle Cash Management with Oracle Receivables, additional setup steps are required.

Note: If you plan to use Multiple Reporting Currencies (MRC) with Receivables, additional setup steps are required. For more information, refer to the Multiple Reporting Currencies in Oracle Applications manual.

Related Product Setup Steps:

The following steps may need to be performed to implement Oracle Receivables. These steps are discussed in detail in the Setting Up sections of other Oracle product user guides.

Set Up Underlying Oracle Applications Technology 

The Implementation Wizard guides you through the entire Oracle Applications setup, including system administration. However, if you do not use the Wizard, you need to complete several other setup steps, including:

• performing system–wide setup tasks such as configuring concurrent managers and printers
• managing data security, which includes setting up responsibilities to allow access to a specific set of business data and complete a specific set of transactions, and assigning individual users to one or more of these responsibilities.
• setting up Oracle Workflow

General Ledger Setup Steps:

The following table lists steps and a reference to their location within the Applications Implementation Wizard (AIW).

• Define Chart of Accounts 
• Define Currencies 
• Define Calendars 
• Define Calendar Period Types 
• Define Ledger
• Assign Ledger to a Responsibility 

Define Chart of Accounts:

Define Segments: 

Navigation: General Ledger --> Setups --> Flexfields --> Key --> Segments.

Query With Accounting Flexfield and click on New.

Give your coa name and save.

Click on Segments.

Enter your segments names.

and save your work.

Assign Flexfield Qualifiers to Company and Accounting segments.

Select Company segment and then Click on Flexfield Qualifiers.

Select Balancing segment qualifiers and save.

 Select Accounting segment and then click on flexfield qualifiers.

Select Natural Account Segment and save.

Define Value sets:

Click on Value set.

Enter the value set Name and Size.

Save your work.

Like wise define value set for all reaming segments.

Assign Value sets to respective segments.

Save your Work.

Select Allow Dynamic inserts and Freeze Flexfield Defination and then click on Compile.

Wait untill the following program are successfully completed.

Define Values:

Navigation: General Ledger --> Setups --> Flexfields --> Key -->Values.

Enter the below information and click on find button.

Enter the company values names and save your work.

Like wish define values for all reaming segments.


Define Currencies:

Navigation: General Ledger --> Setup --> Currencies --> Define.

Enter information and save.

Define Calendar Period Types:

Navigation: Setup --> Financials --> Calendars --> Types.

Enter the information and save.

Define Calendar:

Navigation: Setup --> Financials --> Calendars --> Accounting.

Save.

Define Ledger  :

See My Blog how to define Ledger in R12.


Assign Ledger to a Responsibility:


Navigation: System Administrator --> Profile --> Systems.

Click on find.

Assign Ledger to GL Responsibility.

Save.

Oracle Inventory Setup Steps:

• Define Operating Unit.
• Define Inventory Organizations
• Define Items 

Define Operating Unit:

See my blog how to define Operating unit in R12.


Define Inventory Organization:


Navigation: Inventory --> Setup --> Organizations --> Organizations.

Click on New.

Enter information in the required fields.

Save your work and click on othres.

click on Accounting information.

Enter the required information and save.

Click on Others and select the inventory information.

Under Inventory Parameters tab enter the following information.

Under Costing Information tab enter the following information.

Under Revision and Lot Serial And LPN enter the required information.

Under the other accounts tab enter the required information.

Save your work.

Define Items:

Navigation: Inventory --> Items --> Master items.

Enter the name and description.

Go to Tolls and click on copy from.

Enter Finished good and then click on Apply and done button.

Receivable Setups:

• Define System Options
• Define Transaction Flexfield Structure
• Define Sales Tax Location Flexfield Structure
• Define AutoCash Rule Sets
• Define Receivables Lookups
• Define Invoice Line Ordering Rules
• Define Grouping Rules
• Define Application Rule Sets
• Define Payment Terms
• Define AutoAccounting
• Open or Close Accounting Periods
• Define Transaction Types
• Define Transaction Sources
• Define Collectors
• Define Approval Limits
• Define Remittance Banks
• Define Receivables Activities
• Define Receipt Classes
• Define Receipt Sources
• Define Payment Methods
•  Define Statement Cycles
• Define System Profile Options
• Define Salespersons
• Define Customer Profile Classes
• Define Customers
• Define Remit–To Addresses

Define System Options: 

Define your accounting, discount, tax, and invoice system options to control how Receivables works. System options determine your accounting method, set of books, accounting flexfields, whether you use header or line–level rounding, and control the default operation of the AutoInvoice and Automatic Receipt programs.
System options also control how Receivables calculates tax on your transactions. You must specify a tax method, choose a Location Flexfield Structure, indicate whether to compound tax, select the address validation to use, and define tax defaults and rounding options. As you can set up your system to calculate Sales Tax, Value Added Tax, or Canadian Tax, we recommend that you carefully review the appropriate implementing tax essay before defining your system options.

Navigation: Receivables --> Setups --> System --> System Options.

Enter the required information in respective fields.

Define Transaction Flexfield Structure:

Transaction flexfields are descriptive flexfields that AutoInvoice uses to identify transactions and transaction lines. Receivables lets you determine how you want to build your transaction flexfield structure and what information you want to capture.

There are four types of transaction flexfields:

• Line Transaction Flexfield
• Reference Transaction Flexfield
• Link–To Transaction Flexfield
• Invoice Transaction Flexfield

You must define the Line Transaction Flexfield if you use AutoInvoice. You can use the Line Transaction Flexfield to reference and link to other lines because the Line Transaction Flexfield is unique for each
transaction line. AutoInvoice always uses the Line Transaction Flexfield structure for both the Link–to and Reference information when importing invoices. You must explicitly define the Link–to, Reference,
and Invoice Transaction Flexfield structures only if this information is to be displayed on a custom window.
Receivables gives you the option of displaying Invoice Transaction Flexfield information in the reference column of invoice lists of values.

Use the System Profile Option AR: Transaction Flexfield QuickPick Attribute to select the Invoice Transaction Flexfield segment that you want to display. For example, if you want to be able to reference the
order number for imported invoices when using an invoice list of values, you must assign the transaction flexfield segment that holds the order number to the AR: Transaction Flexfield QuickPick Attribute
profile option. The order number will now display in the reference column of invoice lists of values.

Line Transaction Flexfield:

Use columns INTERFACE_LINE_ATTRIBUTE1–15 and INTERFACE_LINE_CONTEXT to define the Line Transaction Flexfield. Line Transaction Flexfields are unique for each record in the interface table and therefore can be used as record identifiers.

Reference Transaction Flexfield:
Reference Transaction Flexfields have the same structure as the Line Transaction Flexfields.
Transactions 4 – 235 Reference Transaction Flexfields are used to apply a credit memo to an invoice or associate an invoice to a specific commitment. 

For example, to refer a credit memo to a specific invoice, use the REFERENCE_LINE_ATTRIBUTE1–15 and REFERENCE_LINE_CONTEXT columns of the credit memo to enter the Line Transaction Flexfield of the invoice. To refer an invoice to a specific commitment, use the REFERENCE_LINE_ATTRIBUTE1–15 and REFERENCE_LINE_CONTEXT columns of the invoice to enter the Line Transaction Flexfield of the commitment.

Link–To Transaction Flexfield:

Link–To Transaction Flexfields also have the same structure as the Line Transaction Flexfield. Use Link–To Transaction Flexfields to link transaction lines together in the interface table. For example, you might want to import tax and freight charges that are associated with specific transaction lines. If you want to associate a specific tax line with a specific transaction line, use the LINK_TO_LINE_ATTRIBUTE1–15 and LINK_TO_LINE_CONTEXT columns of the tax line to enter the Line Transaction Flexfield of the invoice.

Invoice Transaction Flexfields:
Create a new flexfield with a similar structure as the Line Transaction Flexfield, but only include header level segments. For example, if the Line Transaction Flexfield structure has four segments and the last two segments contain line level information, define your Invoice Transaction Flexfield using the first two segments only. Segments included in the Invoice Transaction Flexfield should be included in the AutoInvoice grouping rules.

Define Sales Tax Location Flexfield:

Receivables uses the customer shipping address to determine the sales tax rate on transactions for all customers in the country that you define in the Systems Option window as your home country. Proceed to the next step if you are not charging your customers tax based on their shipping address.

Following are the seeded Sales Tax Location Flexfield structures:
• Country
• State and City
• Province and City
• City
• Province
• State, County and City

Use the Key Flexfield Segments window to select the seeded Sales Tax Location Flexfield structure, or to set up a new structure, that you want Receivables to use to determine your sales tax rates and to validate
your customer addresses.
You can confirm that the required segments are enabled by navigating to the Segments Summary window. Navigate back to the Key Flexfield Segments window to freeze your flexfield structure by checking the
Freeze Flexfield Definition check box and then compiling the flexfield.

Note: When you define tax system options in the System Options window, use the list of values in the Location Flexfield Structure field to select the same Sales Tax Location Flexfield structure that you selected in the Key Flexfield Segments window.

Navigation: Receivables --> Setup --> Financials --> Flexfield --> Key --> Segments.

Query with Sales Tax Location Flexfield

 Enter the required information in respective filelds.

Save your work.

Like wise we can define other sales tax location flexfields,

Define AutoCash Rule Sets:

If you are using AutoCash, define your AutoCash rule sets before defining system parameters or customer profiles classes. AutoCash rules determine the sequence of application methods Receivables uses when applying receipts imported using AutoLockbox to open debit items.

Navigation: Receivables --> Setup --> Receipts --> Autocash rule sets.

Define Receivables Lookups:

Receivables provides several default lookups which are used throughout the application to provide validated default values and list of values choices. You can add or update these to customize your list of values and speed data entry. For example, you can define additional reasons for creating credit memos or enter the names of each freight carrier used by your business.

Navigation: Receivables --> Setup --> System --> Quickcodes --> Receivables.

Define lookups as you like.

Define Invoice Line Ordering Rules:

If you are using AutoInvoice, define invoice line ordering rules to specify how you want to order and number transaction lines after AutoInvoice groups them into invoices, debit memos, and credit memos. Receivables provides many attributes that you can use to define your line ordering rules.

Navigation: Receivables --> Setup --> Transactions --> Autoinvoice --> Line Ordering rule.

Define Grouping Rules:

If you are using AutoInvoice, define grouping rules to indicate how you want to group transaction lines imported by AutoInvoice. For example, to include specific transaction lines on a single transaction, certain attributes must be identical. Receivables provides many attributes that you can use to define your grouping rules.

Navigation: Receivables --> Setup --> Transactions --> Autoinvoice --> Grouping Rule.

Define Application Rule Sets:

Define Application Rule Sets to control how Receivables reduces the balance due for your open debit items when you apply payments using either the Applications window or Post QuickCash. You can define your own application rule sets, assign them to transaction types, and specify a default rule set in the System Options window.

Navigation: Receivables --> Setup --> Receipts --> Application Rule sets.

Define Payment Terms:

Define payment terms to determine the payment schedule and discount information for customer invoices, debit memos, and deposits. You can also define proxima payment terms to pay regular expenses such as telephone bills and credit card bills that occur on the same day each month and create split payment terms for invoice installments that have different due dates.

Navigation: Receivables --> Setup --> Transactions --> Payment terms.

Define AutoAccounting:

Define AutoAccounting to specify the general ledger accounts for transactions that you enter manually or import using AutoInvoice. AutoAccounting uses this information to create the default revenue, receivable, freight, tax, unearned revenue, unbilled receivable, finance charges, bills receivable accounts, and AutoInvoice clearing (suspense) accounts.

Navigation: Receivable --> Setup --> Transactions --> Auto Accounting.

Like wise we should also define reaming auto accounting types.

Open or Close Accounting Periods:

Navigation: Receivables --> Control --> Accounting --> Open/Close Periods.

Define Transaction Types:

Define the transaction types that you assign to invoices, debit memos, commitments, chargebacks, credit memos, on–account credits, and bills receivable. Receivables uses transaction types to default payment term,
account, tax, freight, creation sign, posting, and receivables information. Receivables provides two predefined transaction types: Invoice and Credit Memo.

Navigation: Receivables --> Setup --> Transaction --> Transaction Types.

Define Transaction Sources:

Define the transaction sources that you assign to invoices, debit memos, commitments, credit memos, on–account credits, and bills receivable. Receivables uses transaction sources to control your transaction and transaction batch numbering, provide default transaction types for transactions in batch, and to select validation options for imported transactions. Receivables provides the following predefined transaction sources: MANUAL–OTHER, DM Reversal, and Chargeback.

Navigation: Receivables --> Setup --> Transaction --> Sources.

 Define Collectors:

Define collectors to assign to your customers through credit profile class assignments. Collectors can use the Collections windows and Receivables collection reports to keep apprised of a customer’s past due items. Receivables provides a predefined collector called DEFAULT.

Navigation: Receivables --> Setup --> Collections --> Collectors.

 Define Approval Limits:

Define approval limits to determine whether a Receivables user can approve adjustments or credit memo requests. You define approval limits by document type, dollar amount, reason code, and currency.
Approval limits affect the Adjustments, Submit AutoAdjustments, and Approve Adjustments windows as well as the Credit Memo Request Workflow.

Navigation: Receivables --> Setup --> Transactions --> Approval Limits.

Define Remittance Banks:

Proceed to the next step if you already defined your remittance banks in Oracle Payables. Define all of the banks and bank accounts you use to remit your payments. You can define as many banks and bank accounts as you need and define multiple currency bank accounts to accept payments in more than one currency.


Define Receivables Activities

Define Receivables Activities to provide default accounting information when you create adjustments, discounts, finance charges, miscellaneous cash transactions, and bills receivable. Receivables also uses Receivables Activities to account for tax if you calculate tax on these activities.

Navigation: Receivables --> Setup --> Receipts --> Receivable Activities.

Like wise we should define reaming receivable actives also.

Define Receipt Classes:

Define receipt classes to specify whether receipts are created manually or automatically. For manual receipts, you can specify whether to automatically remit it to the bank and/or clear your accounts. For automatic receipts, you can specify a remittance and clearance method, and whether receipts using this class require confirmation.

Navigation: Receivables --> Setup --> Receipts --> Receipts Class.

Click on Bank accounts.


Enter information in respective fields.

Save your work.


Define Payment Method:

Define the payment methods to account for your receipt entries and applications and to determine a customer’s remittance bank information. When defining payment methods, you must enter a receipt class, remittance bank information, and the accounts associated with your payment receivables type. You can also specify accounts for confirmation, remittance, factoring, bank charges, and short–term debt.

Navigation: Receivables --> Setup --> Receipts --> Receipts Class.

Define Statement Cycles:

Define statement cycles to control when you create customer statements. You assign statement cycles to customers in the Customer Profile Classes window.

Navigation: Receivables --> Setup --> Print --> Statement Cycle.

Define profile options:

Define profile options to provide default values for some Receivables operations, specify how Receivables processes data, and control which actions users can perform.

Navigation: Administrator --> Profile --> Systems.

During your implementation, you set a value for each Receivables user profile option to specify how Receivables controls access to and processes data. Receivables lets you govern the behavior of many of
the windows that use profile options.

Profile options can be set at the following levels:
• Site: This is the lowest profile level. Site level profile option values affect the way all applications run at a given site.
• Application: These profile option values affect the way a given application runs.
• Responsibility: These profile option values affect the way applications run for all users of a given responsibility.
• User: These profile option values affect the way applications run for a specific application user. The values you enter for options at the User level supersede the values that your system administrator has entered for you for these options.

Each of these user profile options affect the behavior of Receivables in different contexts. In Receivables, operations that profile options can affect include receipt application, the entry of adjustments, the creation
and remittance of automatic receipts and taxes, and posting to your general ledger.
You may also have additional user profile options on your system that are specific to applications other than Receivables.

To change profile options at the Site, Application, or Responsibility level, choose the System Administrator responsibility, then navigate to the Personal Profile Values window. Query the Profile Name field to
display the profile options with their current settings, make your changes, then save your work. You can change profile options at the user level in the Personal Profile Values window. To do this, navigate to the Personal Profile Values window, query the profile option to change, enter a new User Value, then save your work. Generally, your system administrator sets and updates profile values at each level.

Attention: For any changes that you make to profile options to take effect, you must either exit, and then reenter Receivables, or switch responsibilities.

  
Define Salespersons:

Define salespersons to allocate sales credits to invoices, debit memos, and commitments. If you do not want to assign sales credits for a transaction, you can enter No Sales Credit. If AutoAccounting depends on salesperson, Receivables uses the general ledger accounts that you enter for each salesperson along with your AutoAccounting rules to determine the default revenue, freight, and receivable accounts for transactions.

Define Customer Profile Classes:

Define customer profile classes to categorize customers based on credit, payment terms, statement cycle, automatic receipt, finance charge, dunning, and invoicing information. When you initially set up your customers, you assign each customer to a profile class. To customize the profile class for a specific customer, use the Customer Profile Classes window.

Navigation: Receivables --> Customers --> Profile Classes.

In Profile Class window enter the following information.

In Profile class Amount tab enter the following information.

Save your work.

Define Customers:


Define customers and customer site uses to enter transactions and receipts in Receivables. When you enter a new customer, you must enter the customer’s name, profile class and number (if automatic customer numbering is set to No). You can optionally enter customer addresses, contacts, site uses and telephone numbers. You must enter all the components of your chosen Sales Tax Location Flexfield when entering customer addresses in your home country.

Navigation: Receivables --> Customers --> Standard.

Define Remit–To Addresses:

Define remit–to addresses to inform your customers where to send payments. Associate each remit–to address with one or more state, country, and postal code combinations.
For example, if you want your customers in California and Nevada to send their payments to a specific address, enter the remit–to address and associate the states CA and NV with this address. Remit–to addresses are assigned based on the bill–to address on the transaction.

Navigation: Setup --> Print --> Remit-to-addresses.

Click on Create Remit to addresses.

Enter the required information

Click on Apply.

Enter the country name in the same page and then click on the GO.

Click on the Receipts form Create button.

Enter the following information and click on Apply button.