EDI Setups for 820 Outbound

Bank Accounts Tab	(At Supplier Site)
	Supplier Name	APPLIED INDUSTRIAL FLOORING
	Site Name	MISSISSAUGA
	Payment Method	Electronic
	Bank Account Name	APPLIED INDUSTRIAL FLOORING
	Number	1
	Bank Name	DUMMY-CAD
	Number	9999
	Branch Name	DUMMY BANK-C

EDI Tab	(At Supplier Site)
	EDI ID Number	99999
	Payment Method	ZZZ
	Remittance Method	EDI to payee
	Remittance Instruction	EDI Remittance Instructions
	Transaction Handling	C

Payment Formats

Document Name	HSBC - CAD CNR
Disbursement Type	Combined
Payment Format	EDI Outbound Program - CAD
Payment Method	Electronic

Define Trading Partners How to you setup EDI Payment Outbound 820? EDI Payment Outbound 820 (ECEPYO)  1 Profile Options Setup  Using the System Administrator Responsibility navigate to Profile -> System Set the following:        Profile = 'ECE: Output file path'      Site = ... (Path for output file directory)             Example: Site = /sqlcom/outbound     2 init.ora setup Add an environment vialable "utl_file_dir" in $ORACLE_HOME/dbs/init.ora  Example:  utl_file_dir = /sqlcom/outbound   This path needs to be exactly same as the path you have defined in Profile  Option.      3 Format Program Setup  Using the Payables Responsibility, navigate to Setup->Payment->Format Set the following:      Payment Format = EDI Outbound Program      Payment Method = Electronic Payments     Currency = USD     Build Payments = Build Payments Program     Format Payments = EDI Outbound Program    4 Internal Bank Account Setup  Using the Payables Responsibility, navigate to Setup->Payment->Banks  setup a Bank Account as follows:        Bank Branch Type = (Select from LOV)      Account Use = Internal     Account Type = EDI     EDI Location = ...(Path for output file directory)   Create a new Payment Document to use  Payment Format = EDI Outbound Program     5 Supplier Bank Account Setup  Using the Payables Responsibility, navigate to Setup->Payment->Banks   Create a new Bank Account, set:        Bank Branch Type = (Select from LOV)     Account Use = Supplier     Account Type = EDI    6 Supplier Site Setup  Using the Payables Responsibility, navigate to Supplier->Entry   Query the supplier, then choose the Site.    Bank Account Region:     Fill in the supplier bank account,     Set Primary to 'Yes'.    Electronic Payment Region: set the following (Contact with your internal bank branch to set them up):      Payment Method     Payment Format     Remittance Method      Remittance Instruction     Transaction Handling   7 Trading Partner Setup Using the EDI Manager Responsibility, navigate to Trading Partners. Define a trading partner for the internal bank branch. Assignment Region:      Bank Branch = the internal bank branch. Contact Region:      Set the contact information. Detail Region:      Document = Payment/Remittance Outbound, EDI = Yes. 8 Invoice for EDI 820  Set "Payment Method = Electronic Payments" for the invoices which you'd like  the payment batch to select. 9 Preliminary Payment Regiter Create a payment batch for using Payment Format = EDI Outbound Program.  View  the Preliminary Payment Register to make sure there is at least one document  going to be paid before you run the Format Payment Program. 10 Format Payment Program and ECEPYO output file If the Format Payment Program completes successfully, view the output, it will  give you a number, for example, the number is 123.  The output file ECEPYO.123 will be in /sqlcom/outbound directory.

hr_locations.location_id = financials_system_parameters.bill_to_location_id	AP Financial Options
Set  Bank Branch = the internal bank branch	EDI Trading Partners	Go to the Trading Partner Setup Assignment Region

Subledger Data Conversion - When two different Calendar is used in Primary and Secondary Ledgers

When Primary and Secondary Ledgers use Different Calendars, It is possible to create a Secondary Ledger with a Subledger Data Conversion.

(i) Secondary ledgers can have a different calendar than the primary ledger.

Secondary ledgers represent the primary ledger's accounting data in another accounting representation that might differs in one or more of the following ways:

• Chart of accounts
• Accounting calendar/period type combination
• Currency
• Subledger accounting method
• Ledger processing options

(ii) Subledger Data Conversion Level

This data conversion level uses both Subledger Accounting and the General Ledger Posting program to create the necessary journals in both the primary and secondary ledgers simultaneously. Subledger Accounting creates the journal entries from subledger transactions if the subledger integrates with Subledger Accounting.
General Ledger Posting creates the journal entries for all other transactions that do not integrate with Subledger Accounting, including manual journal entries

(iii) How data is converted if the calendar is different:

The following conversion rules are used to convert data from the primary ledger to the secondary ledger:

• Calendar Conversion: If the secondary ledger uses a different accounting calendar from the primary ledger, the journal effective date determines the corresponding non-adjusting period in the secondary ledger.

However, when running create accounting from the subledger, user gets the following error message:  "The access set  XXXX Primary Ledger assigned to the system profile option GL: Data Access Set does not include read and write privileges for the ledger Vision operations Secondary Ledger and the balancing or management segment value.

Please use the Data Access Sets window in General Ledger to include read and write privileges for the ledger and segment values or assign a different ledger access set to the system profile option."

Per the Oracle Financials Implementation Guide for Release 12, when creating a data access set, all ledgers and ledger sets assigned to a data access set must share the same chart of accounts and accounting calendar/period type combination.

The way to provide the subledger access to both the primary ledger and secondary ledger, while running create accounting, is to set the following system profile options:

• GL: Data Access Set -- to point to the primary ledger
• SLA: Additional Data Access Set -- to point to the secondary ledger

Solutions Used in Previous Projects - R12 AP

1. Requirement
Do we need Cash Clearing Account At each payment Document?

Details
How do you set up different GL account at the payment document level ?

Description of Solution:
n R12, there is no field to set Cash Clearing for the payment document in the Payment document setup user interface.
There was an intentional decision to move the GL accounts up to the bank account use level and remove them from the check stock level.  This was largely motivated by the fact that check stocks can be used only in the case of printed checks – not electronic payments. (Prior to R12, check stocks needed to be created even in the case of electronic payments. This is no longer the case in R12.) In order to have consistent accounting setup between check printing and electronic payments, it was decided to keep the GL accounts at the bank account use level.
The user could use the flexibility of SLA if they desire to set up their bank GL accounts at a level lower than the bank account use (e.g., they could setup an account derivation rule that takes the check stock as an input).
This was validated with the field before the change was made. Note that the input from some of the countries indicated that companies may require cash clearing/bank fee GL accounts to be set up at a level more granular than bank account use (e.g., one GL account for each payment format or payment method used for a certain bank account). However, as noted above,it was agreed that SLA should be able to deal with these requirements. This is possible since all of these attributes are made available through the AP SLA extract. "

2. Requirement:
How to divide the payment responsibility into operating units specific so that each responsibility show in the home page and in the payment process request tab only the payment processes made for that specific operating unit?

Detail:
In R12 there is NO concept of PPR ownership. It is not owned by an Organization nor a Legal Entity.A PPR can legitimately pay the Documents Payable from more than one Organization or Legal Entity.
PPR restricts the Selection of Invoices according to Security profile for User.
A Payment Process Request is NOT owned by a Legal Entity. When user submits a PPR; he/she can choose to include the Documents Payable from any Pay Groups, Legal Entities, Payment Currencies or Operating Units.

Description of Solution:
A possible workaround may be:
1) Setup different Security Profile option for each Payment manager Responsibility which has access to list of Orgs.
2) While creating a Payment Process Request, in the "Scheduled Payment Selection Criteria", if you specify Operating Units as "All" invoice selection is restricted to the operating units which the user/responsibility has access to and PPR will select invoices for payment which belong to other OUs as well.
This will help to achieve the cleaner separation of PPR

3. Requirement:
Can a user create a Payment Process Request that will pay 2 invoices that are assigned to 2 different operating units that are linked to 2 different ledgers?

Details:
The answer is "No".
Generally speaking, the accounting structure in Oracle E-Business Suite starts with a Ledger and its functional currency.
For each ledger, you have one or more Legal Entities (LE) attached.
For each Legal Entity, you have one or more Operating Units (OU) attached.
Internal bank accounts are entered at the Legal Entity level (see the Bank Account Owner field on the "Account Owner and Use" page of the Manage Bank Accounts window), and by this association, are also linked to the same Ledger that the Legal Entity is attached to.

Description of the Solution:
Each internal bank account can be accessed by one or more specified Operating Units that are attached to its associated Legal Entity (see the Account Access page of the Manage Bank Accounts window > Add Organization Access button).
Through these associations, when you create a Payment Process Request (PPR), and specify an internal bank account, you are telling the system which Legal Entity and Ledger these payments are for. Therefore, all payments in a single PPR can be generated for only one Ledger.

Oracle Payables R12 Overview

Suppliers Added to Trading Community Architecture
The Oracle eBusiness Suite has a single repository called the Trading Community Architecture (TCA) to store information about your trading partners. TCA provides a single common definition that can be used to identify customers, suppliers, and organizations that provide you with goods or services, and are in turn, a customer of your own products or services. The TCA repository stores the key elements that define an organization, identity, business locations, and key contacts, so that different Oracle products use a common trading partner definition.

Various applications in the Oracle E-Business Suite can view, create, and update the TCA Registry data. Because this information is shared, any change made in one application is reflected in all applications. A range of information that can be viewed through the Suppliers pages is also available through the Customers Online pages.


Invoice lines
Invoice Lines are introduced as an entity between the invoice header and invoice distributions in order to better match the structure of real world invoice documents and improve the flow of information in the Oracle E-Business Suite. With the new model, the invoice header remains unchanged, and continues to store information about the supplier who sent the invoice, the invoice attributes and remittance information. Invoice lines represent the goods (direct or indirect materials), service(s) and/or associated tax/freight/miscellaneous charges invoiced. Invoice distributions store the accounting, allocation and other detail information that makes up the invoice line.


Centralized banks and bank account definitions in oracle cash management
In Release 12, the ownership of internal banks and bank accounts will move to Oracle Cash Management for all products in the E-Business Suite. A Legal Entity now owns the bank accounts and their payment documents, rather than being owned by an Operating Unit, as in prior releases.

The Bank Account model allows users to define and keep track of all bank accounts in the e-Business Suite in one place and explicitly grant account access to multiple operating units/functions and users.

The Bank Account model reduces the number of access points to manage bank accounts by providing a centralized user interface where all internal bank accounts can be set up.

Bank account access in this model can be granted to multiple operating units, thus eliminating the redundant duplicate bank account setup under different operating units in case these operating units share the same bank account. This will also simplify the reconciliation process since now one bank account is the system corresponds to one bank account at the bank.


Document Sequencing of PaymentsIf you used document sequencing for payment documents in Release 11i, your document sequence category is migrated from the payment document, which is associated with a bank account and, hence a legal entity, to the bank account uses entity. This change preserves the option of having document sequence categories vary across operating units.


Integration with Oracle payments for funds disbursement
The process to issue payments from Oracle Payables (AP) changes in Release 12 to use the new Oracle Payments funds disbursement process.

Oracle Payments is a product in the Oracle E-Business Suite of applications, which serves as a funds capture and funds disbursement engine for other Oracle applications. As the central payment engine, Oracle Payments processes transactions, such as invoice payments from Oracle Payables, bank account transfers from Oracle Cash Management, and settlements against credit cards and bank accounts from Oracle Receivables.

Oracle Payments' funds disbursement features support the process to pay funds owed to creditors, such as suppliers. Oracle Payments supports functionality to achieve straight through processing of electronic funds transfers and the ability to format and manage check or other payment document printing.


Integration with oracle subledger accounting
Release 12 introduces a new module, Subledger Accounting (SLA), for managing accounting across subledger transactions. With the introduction of SLA, Payables will no longer create accounting entries, but will instead rely on the central SLA engine to do so.

Oracle Subledger Accounting gives users the ability to create the accounting definitions to address their specific accounting requirements. Users that do not have specific requirements can use the seeded accounting definitions that are provided out of the box.


Integration with Oracle E-Business Tax
In Release 12, Oracle E-Business Tax, a new product, will manage transaction tax across the E-Business Suite. In prior releases, the setup, defaulting and calculation of transaction tax for Payables was managed within Payables using tax codes, their associated rates and a hierarchy of defaulting options. The new module will cover standard procure-to-pay and order-to-cash transaction taxes, with the exception of withholding taxes.


Multiple Organizations Access Control

Multiple Organizations Access Control is an enhancement to the Multiple Organizations feature of Oracle Applications. Multiple Organizations Access Control (MOAC) allows a user to access data from one or many Operating Units while within a given responsibility. Data security is maintained using the Multiple Organizations Security Profile, defined in Oracle HRMS, which specifies a list of operating units and determines the data access privileges for a user.

In Release 12, several controls are moved from the Payables Options or Financials Options forms to a new setup form that is common for Oracle Payables across all operating units, the Payables System Setup form. If the upgrade finds conflicts in the settings across multiple operating units, it will choose the most frequently occurring setting.


Payables and Receivables NETTING
The Payables and Receivables Netting feature enables the automatic netting of Payable and Receivable transactions within a business enterprise. You can predefine a netting agreement that incorporates the netting business rules and transaction criteria needed to run your tailored netting process.
Oracle Payments - Enhanced Disbursement Process
The new Oracle Payments disbursement engine allows businesses to greatly simplify their user procedures around managing complex payment processes that span multiple payment methods, formats, check stocks, transmission protocols, currencies, organizations, and bank accounts. Oracle Payments has redesigned the payment build process that Oracle Payables used in previous releases. The Oracle Payables payment batch process required the submission of the invoice selection process to be segregated according to the way the invoices needed to be paid (printed checks, electronic funds transfer, different formats, and so on).

The new Oracle Payments funds disbursement process allows the invoice selection process in Oracle Payables and other products to be neutral to the way documents will be paid. This is achieved by effectively splitting the payment build process into two separate processes. The first process creates payments by grouping documents according to various rules such as the payment method and currency. Accounts Payable managers are able to simplify their processes by submitting fewer invoice selection batches, each one spanning multiple payment methods, formats, bank accounts, and payment currencies. Invoices can be selected for payment based on business reasons such as maximizing discounts. The second process then aggregates payments into formatted payment instruction files, and handles any additional processing. The cost of the disbursement process is lowered by creating fewer check runs and EFT payment files by grouping payments across the criteria of the first process.