AP Module

In this session you will find all the ready scripts avilable for the AP Module.

P2P Query based on the Purchase Order Number

Summary Hold information based on the Invoice Number

Detail Hold information of the Invoice

Detail Hold information of the Invoice

AP Detail Hold information of the Invoice:-
--------------------------------------------------

When we Purchase some material/Goods/Items from Vendor/Supplier, after receiving the material. Vendor would send the INVOICE (In other words we receive BILL for the Items you have received). And payment will be done automatically. If there is some Discrepancy in the Items received and in the BILL/INVOICE you received, for them to hold the payment we normally set the HOLD rules. From the following Query you can know the Hold reason at the detail level.

Note:- Normally this kind of Information will be required for the Top level management for the decision making.

select * from
(SELECT 'Holds - Source1' AS SOURCE,
api.invoice_date AS invoice_date,
api.invoice_num AS invoice_num,
pov.vendor_name AS supplier_name,
apd.distribution_line_number AS inv_line_num,
apd.amount AS invoice_line_amount,
DECODE (aph.hold_reason, NULL, 'N', 'Y') AS defect,
poh.segment1 AS po_number,
por.release_num AS po_release_num,
pol.line_num AS po_line_num,
aph.hold_date AS hold_date,
aph.hold_lookup_code AS hold_lookup_code,
aph.hold_reason AS hold_reason,
aph.last_update_date AS release_date,
(TRUNC (NVL (aph.last_update_date, SYSDATE)) - TRUNC (aph.hold_date)) AS days_os,
pod.quantity_ordered AS shipment_quantity_ordered,
pod.quantity_delivered AS shipment_quantity_delivered,
pod.quantity_billed AS shipment_quantity_billed,
api.invoice_received_date AS invoice_received_date,
pob.agent_name AS buyer,
povs.vendor_site_code AS supplier_site,
ppf.full_name AS requestor,
rcvh.receipt_num AS receipt_number,
rcv.quantity AS received_accepted_qty,
rcv.unit_of_measure AS uom,
rcv.creation_date AS receipt_transacted_date,
rcv.transaction_date AS receipt_date
FROM APPS.ap_invoices_all api,
APPS.ap_invoice_distributions_all apd,
APPS.po_distributions_all pod,
APPS.po_headers_all poh,
APPS.po_releases_all por,
APPS.po_lines_all pol,
APPS.ap_holds_all aph,
APPS.po_vendors pov,
APPS.po_agents_v pob,
APPS.po_vendor_sites_all povs,
APPS.rcv_transactions rcv,
APPS.rcv_shipment_headers rcvh,
APPS.po_line_locations_all pll,
APPS.hr_locations_all loc,
APPS.per_all_people_f ppf
WHERE 1 = 1
AND api.invoice_id = apd.invoice_id
AND aph.invoice_id(+) = api.invoice_id
AND api.vendor_id = pov.vendor_id(+)
AND api.cancelled_date IS NULL
AND apd.po_distribution_id = pod.po_distribution_id(+)
AND aph.line_location_id = pod.line_location_id
AND poh.po_header_id(+) = pod.po_header_id
AND por.po_release_id(+) = pod.po_release_id
AND pol.po_header_id (+) = pod.po_header_id --
AND pol.po_line_id (+) = pod.po_line_id
AND poh.agent_id = pob.agent_id(+)
AND povs.vendor_site_id(+) = poh.vendor_site_id
AND apd.po_distribution_id = rcv.po_distribution_id(+)
AND rcvh.shipment_header_id(+) = rcv.shipment_header_id
AND rcv.destination_type_code(+) = 'RECEIVING'
AND pll.line_location_id(+) = pod.line_location_id
AND pll.ship_to_location_id = loc.location_id(+)
AND pod.deliver_to_person_id = ppf.person_id (+)
AND NVL (ppf.effective_start_date, SYSDATE) <= SYSDATE
AND NVL (ppf.effective_end_date, SYSDATE + 1) > SYSDATE
UNION
SELECT 'Holds NotLinked To PO-Source2' AS SOURCE,
api.invoice_date AS invoice_date, api.invoice_num AS invoice_num,
pov.vendor_name AS supplier_name,
apd.distribution_line_number AS inv_line_num,
apd.amount AS invoice_line_amount,
DECODE (aph.hold_reason, NULL, 'N', 'Y') AS defect,
poh.segment1 AS po_number, por.release_num AS po_release_num,
pol.line_num AS po_line_num, aph.hold_date AS hold_date,
aph.hold_lookup_code AS hold_lookup_code,
aph.hold_reason AS hold_reason, aph.last_update_date AS release_date,
(TRUNC (NVL (aph.last_update_date, SYSDATE)) - TRUNC (aph.hold_date)
) AS days_os,
pod.quantity_ordered AS shipment_quantity_ordered,
pod.quantity_delivered AS shipment_quantity_delivered,
pod.quantity_billed AS shipment_quantity_billed,
api.invoice_received_date AS invoice_received_date,
pob.agent_name AS buyer, povs.vendor_site_code AS supplier_site,
ppf.full_name AS requestor, rcvh.receipt_num AS receipt_number,
rcv.quantity AS received_accepted_qty, rcv.unit_of_measure AS uom,
rcv.creation_date AS receipt_transacted_date,
rcv.transaction_date AS receipt_date
FROM APPS.ap_invoices_all api,
APPS.ap_invoice_distributions_all apd,
APPS.po_distributions_all pod,
APPS.po_headers_all poh,
APPS.po_releases_all por,
APPS.po_lines_all pol,
APPS.ap_holds_all aph,
APPS.po_vendors pov,
APPS.po_agents_v pob,
APPS.po_vendor_sites_all povs,
APPS.rcv_transactions rcv,
APPS.rcv_shipment_headers rcvh,
APPS.po_line_locations_all pll,
APPS.hr_locations_all loc,
APPS.per_all_people_f ppf
WHERE 1 = 1
AND api.invoice_id = apd.invoice_id
AND aph.invoice_id(+) = api.invoice_id
AND api.vendor_id = pov.vendor_id(+)
AND api.cancelled_date IS NULL
AND apd.po_distribution_id = pod.po_distribution_id(+)
AND aph.line_location_id = pod.line_location_id
AND aph.line_location_id IS NULL
AND poh.po_header_id(+) = pod.po_header_id
AND por.po_release_id(+) = pod.po_release_id
AND pol.po_header_id(+) = pod.po_header_id
AND pol.po_line_id(+) = pod.po_line_id
AND poh.agent_id = pob.agent_id(+)
AND povs.vendor_site_id(+) = poh.vendor_site_id
AND apd.po_distribution_id = rcv.po_distribution_id(+)
AND rcvh.shipment_header_id(+) = rcv.shipment_header_id
AND rcv.destination_type_code(+) = 'RECEIVING'
AND pll.line_location_id(+) = pod.line_location_id
AND pll.ship_to_location_id = loc.location_id(+)
AND pod.deliver_to_person_id = ppf.person_id(+)
AND NVL (ppf.effective_start_date, SYSDATE) <= SYSDATE
AND NVL (ppf.effective_end_date, SYSDATE + 1) > SYSDATE
UNION
SELECT 'NON Holds - Source 3' AS SOURCE, apii.invoice_date AS invoice_date,
apii.invoice_num AS invoice_num, pov.vendor_name AS supplier_name,
apd.distribution_line_number AS inv_line_num,
apd.amount AS invoice_line_amount, 'N' AS defect,
poh.segment1 AS po_number, por.release_num AS po_release_num,
pol.line_num AS po_line_num, NULL AS hold_date,
NULL AS hold_lookup_code, NULL AS hold_reason, NULL AS release_date,
0 AS days_os, pod.quantity_ordered AS shipment_quantity_ordered,
pod.quantity_delivered AS shipment_quantity_delivered,
pod.quantity_billed AS shipment_quantity_billed,
apii.invoice_received_date AS invoice_received_date,
pob.agent_name AS buyer, povs.vendor_site_code AS supplier_site,
ppf.full_name AS requestor, rcvh.receipt_num AS receipt_number,
rcv.quantity AS received_accepted_qty, rcv.unit_of_measure AS uom,
rcv.creation_date AS receipt_transacted_date,
rcv.transaction_date AS receipt_date
FROM APPS.ap_invoices_all apii,
APPS.ap_invoice_distributions_all apd,
APPS.po_distributions_all pod,
APPS.po_headers_all poh,
APPS.po_releases_all por,
APPS.po_lines_all pol,
APPS.po_vendors pov,
APPS.po_agents_v pob,
APPS.po_vendor_sites_all povs,
APPS.rcv_transactions rcv,
APPS.rcv_shipment_headers rcvh,
APPS.po_line_locations_all pll,
APPS.hr_locations_all loc,
APPS.per_all_people_f ppf
WHERE 1 = 1
AND apii.invoice_id = apd.invoice_id
AND apii.vendor_id = pov.vendor_id(+)
AND apii.cancelled_date IS NULL
AND apd.po_distribution_id = pod.po_distribution_id(+)
AND apd.distribution_line_number NOT IN (
SELECT apd.distribution_line_number
FROM APPS.ap_invoices_all api,
APPS.ap_invoice_distributions_all apd,
APPS.po_distributions_all pod,
APPS.ap_holds_all aph
WHERE 1 = 1
AND api.invoice_id = apd.invoice_id
AND aph.invoice_id(+) = api.invoice_id
AND api.cancelled_date IS NULL
AND apd.po_distribution_id = pod.po_distribution_id(+)
AND aph.line_location_id = pod.line_location_id
AND api.invoice_id = apii.invoice_id)
AND poh.po_header_id(+) = pod.po_header_id
AND por.po_release_id(+) = pod.po_release_id
AND pol.po_header_id(+) = pod.po_header_id
AND pol.po_line_id(+) = pod.po_line_id
AND poh.agent_id = pob.agent_id(+)
AND povs.vendor_site_id(+) = poh.vendor_site_id
AND apd.po_distribution_id = rcv.po_distribution_id(+)
AND rcvh.shipment_header_id(+) = rcv.shipment_header_id
AND rcv.destination_type_code(+) = 'RECEIVING'
AND pll.line_location_id(+) = pod.line_location_id
AND pll.ship_to_location_id = loc.location_id(+)
AND pod.deliver_to_person_id = ppf.person_id(+)
AND NVL (ppf.effective_start_date, SYSDATE) <= SYSDATE
AND NVL (ppf.effective_end_date, SYSDATE + 1) > SYSDATE)
where invoice_num='Your Invoice number'

Summary Hold information based on the Invoice Number

AP Summary Hold information based on the Invoice Number:-
------------------------------------------------------------------------

When we Purchase some material/Goods/Items from Vendor/Supplier, after receiving the material. Vendor would send the INVOICE (In other words we receive BILL for the Items you have received). And payment will be done automatically. If there is some Discrepancy in the Items received and in the BILL/INVOICE you received, for them to hold the payment we normally set the HOLD rules. From the following Query you can know the Hold reason at the Summary level.

select * from
(SELECT api.invoice_id, api.invoice_date AS invoice_date,
api.invoice_num AS invoice_num, pov.vendor_id AS vendor_id,
pov.vendor_name AS supplier_name, apd.inv_lines AS total_inv_lines,
NVL (hold_tab_info.hold_inv_lines, 0) AS total_line_holds,
NVL (CEIL ((hold_tab_info.hold_inv_lines * 100) / DECODE(apd.inv_lines,0,1,apd.inv_lines)),
0
) AS percentage_line_hold,
DECODE (hold_tab_info.hold_inv_lines,
NULL, 'N',
0, 'N',
'Y'
) AS defect,
DECODE (hold_tab_info.hold_inv_lines,
NULL, 0,
0, 0,
1
) AS defect_count, 1 inv_count,
NVL (hold_count.hold_cnt, 0) AS total_inv_holds,
NVL (c.hold_os, 0) AS days_outstanding,
NVL (api.invoice_amount, 0) AS total_invoice_amount,
NVL (hold_tab_info.hold_amount, 0) AS total_hold_amount,
NVL (CEIL ((hold_tab_info.hold_amount * 100) / DECODE(api.invoice_amount,0,1,api.invoice_amount)),
0
) AS percentage_amount_hold
FROM APPS.ap_invoices_all api,
(SELECT invoice_id, COUNT (invoice_id) inv_lines
FROM APPS.ap_invoice_distributions_all
GROUP BY invoice_id) apd,
(SELECT invoice_id, COUNT (hold_lookup_code) hold_cnt
FROM APPS.ap_holds_all
WHERE 1 = 1 AND line_location_id IS NOT NULL
GROUP BY invoice_id) hold_count,
(SELECT invoice_id, COUNT (hold_tab.line_num) hold_inv_lines,
SUM (hold_tab.hold_amount) hold_amount
FROM (SELECT DISTINCT api.invoice_id invoice_id,
apd.distribution_line_number line_num,
apd.amount hold_amount
FROM APPS.ap_invoices_all api,
APPS.ap_invoice_distributions_all apd,
APPS.po_distributions_all pod,
APPS.ap_holds_all aph
WHERE 1 = 1
AND api.invoice_id = apd.invoice_id
AND aph.invoice_id(+) = api.invoice_id
AND api.cancelled_date IS NULL
AND apd.po_distribution_id = pod.po_distribution_id(+)
AND aph.line_location_id = pod.line_location_id
AND aph.line_location_id IS NOT NULL) hold_tab
GROUP BY invoice_id) hold_tab_info,
(SELECT invoice_id, MAX (b.hold_os) hold_os
FROM (SELECT invoice_id,
DECODE (status_flag,
'R', ( TRUNC (NVL (last_update_date,
SYSDATE)
)
- TRUNC (hold_date)
),
(TRUNC (SYSDATE) - TRUNC (hold_date))
) hold_os
FROM APPS.ap_holds_all
WHERE line_location_id IS NOT NULL) b
GROUP BY invoice_id) c,
APPS.po_vendors pov
WHERE 1 = 1
AND hold_tab_info.invoice_id(+) = api.invoice_id
AND c.invoice_id(+) = api.invoice_id
AND api.invoice_id = apd.invoice_id
AND api.vendor_id = pov.vendor_id(+)
AND api.cancelled_date IS NULL
AND api.invoice_id = hold_count.invoice_id(+))
where invoice_num='Your Invoice number';

Introduction of DYNAMIC SQL

Introduction of DYNAMIC SQL:-
------------------------------------

If we have to create some PROCEDURE, FUNCTION or PACKAGE and run them, then we have to do two steps.

1) Compile the code.
2) Execute the code which you have compiled.

Errors can occur at any above steps.

At the compile Time (Step 1), system will check for the syntax of the code and also if all the objects used in the code are exisiting in database or not.

If you want to hide the objects at the compile time so that you do not get the error message at the compile time (step 1) then use DYNAMIC SQL.

Difference between DBMS_SQL and EXECUTE IMMEDIATE
-----------------------------------------------------------------------

EXECUTE IMMEDIATE type of Dynamic SQL would not work in the old versions of Oracle Database like 10.7 or older then this version.

DBMS_SQL type of Dynamic SQL would work in all the version of Oracle Database.

                                             DYNAMIC SQL HOME

DBMS_SQL

DBMS_SQL:-
--------------

For the Select statement

Note:- I have created the sample Examples code based on the EMP and DEPT table in the scott schema.

Example:-

DECLARE
L_DEPTNO NUMBER DEFAULT 10;
L_SAL NUMBER;
L_SQL VARCHAR2( 3000 );
L_CUR NUMBER;
L_RC NUMBER;
BEGIN
--- Code converted in dynamic SQL start(phani).
L_SQL := 'select max(sal) from emp where deptno = :l_deptno';
L_CUR := dbms_sql.OPEN_CURSOR;
dbms_sql.PARSE( L_CUR, L_SQL, dbms_sql.NATIVE );
dbms_sql.BIND_VARIABLE( L_CUR, ':l_deptno', L_DEPTNO );
-- describe defines
dbms_sql.DEFINE_COLUMN( L_CUR, 1, L_SAL );
-- execute
L_RC := dbms_sql.EXECUTE( L_CUR );
LOOP
-- fetch a row
IF dbms_sql.FETCH_ROWS( L_CUR ) > 0 THEN
-- fetch columns from the row
dbms_sql.COLUMN_VALUE( L_CUR, 1, L_SAL );
ELSE
EXIT;
END IF;
END LOOP;
dbms_sql.CLOSE_CURSOR( L_CUR );
dbms_output.PUT_LINE( L_SAL );
--- Code converted in dynamic SQL end (phani).
END;

For the Insert statement

Note:- I have created the sample Examples code based on the EMP and DEPT table in the scott schema.

Example:-

DECLARE
L_SQL VARCHAR2( 3000 );
L_CUR NUMBER;
L_RC NUMBER;
g_empno NUMBER := 1;
g_ename VARCHAR2(30) := 'REDDY';
g_deptno NUMBER := 10;
BEGIN
--- Code converted in dynamic SQL start.
l_sql:= 'insert into emp
(EMPNO,
ENAME,
DEPTNO)
VALUES
( :p_empno,
:p_ename,
:p_deptno)';

l_cur := dbms_sql.open_cursor;
dbms_sql.parse(l_cur, l_sql, dbms_sql.native);
dbms_sql.bind_variable(l_cur, ':p_empno', g_empno);
dbms_sql.bind_variable(l_cur, ':p_ename', g_ename);
dbms_sql.bind_variable(l_cur, ':p_deptno',g_deptno);
-- execute
l_rc := dbms_sql.execute(l_cur);
DBMS_SQL.CLOSE_CURSOR (l_cur);
END;

For the Update Statement

Note:- I have created the sample Examples code based on the EMP and DEPT table in the scott schema.

Example:-

DECLARE
L_SQL VARCHAR2( 3000 );
L_CUR NUMBER;
L_RC NUMBER;
g_new_ename VARCHAR2(20) := 'REDDY01';
g_old_ename VARCHAR2(20) := 'REDDY';
BEGIN
--- Code converted in dynamic SQL start.

l_sql:= 'update emp
set ename = :p_new_ename
where ename = :p_old_ename';

l_cur := dbms_sql.open_cursor;
dbms_sql.parse(l_cur, l_sql, dbms_sql.native);

dbms_sql.bind_variable(l_cur, ':p_new_ename',g_new_ename);
dbms_sql.bind_variable(l_cur, ':p_old_ename',g_old_ename);

--- execute
l_rc := dbms_sql.execute(l_cur);
DBMS_SQL.CLOSE_CURSOR (l_cur);

--- Code converted in dynamic SQL end.
END;


                                             DYMANIC SQL-HOME

EXECUTE IMMEDIATE

EXECUTE IMMEDIATE:-
---------------------------

Note:- This type of Dynamic SQL would not work in the 10.7 version Database.

For the Select statement

Note:- I have created the sample Examples code based on the EMP and DEPT table in the scott schema.

Example:-
----------

DECLARE
L_DEPTNO NUMBER DEFAULT 10;
L_SAL NUMBER;
BEGIN
EXECUTE IMMEDIATE 'select max(sal) from emp
where deptno = :l_deptno'
INTO L_SAL
USING L_DEPTNO;
DBMS_OUTPUT.PUT_LINE(L_SAL);
END;

For the Insert statement

Note:- I have created the sample Examples code based on the EMP and DEPT table in the scott schema.

Example:-
-----------

DECLARE
L_ENAME VARCHAR2(20) DEFAULT 'PHANI';
L_EMPNO NUMBER DEFAULT 2;
L_DEPTNO NUMBER DEFAULT 10;
BEGIN
EXECUTE IMMEDIATE 'INSERT INTO EMP(ENAME,EMPNO,DEPTNO) VALUES
(:L_ENAME,:L_EMPNO,:L_DEPTNO)'
USING L_ENAME,
L_EMPNO,
L_DEPTNO;
END;

For the Update Statement

Note:- I have created the sample Examples code based on the EMP and DEPT table in the scott schema.

Example:-
-----------

DECLARE
L_ENAME VARCHAR2(20) DEFAULT 'PHANI';
L_EMPNO NUMBER DEFAULT 2;
L_DEPTNO NUMBER DEFAULT 10;
BEGIN
EXECUTE IMMEDIATE 'UPDATE EMP
SET ENAME = ''RAHUL''
WHERE ENAME = :l_ENAME'
USING L_ENAME;
END;

DYMANIC SQL-HOME

Dynamic SQL

Dynamic SQL:-
----------------

INTRODUCTION

We got two ways for the Dynamic SQL.

1) EXECUTE IMMEDIATE

2) DBMS_SQL

Note:- Click on "EXECUTE IMMEDIATE or DBMS_SQL to check the sample Examples.

AP Module 12 Release New Features

This section is design to give all the information about the changes in the AP Module from 11i to Release 12.

Introduction

Suppliers Added to Trading Community Architecture

Invoice Lines

Centralized Banks and Bank Account Definitions in Oracle Cash Management

Document Sequencing of Payments

Integration with Oracle Payments for Funds Disbursement

Payment Configuration Controlled by Global Descriptive Flexfields

Integration with Oracle Subledger Accounting

Integration with Oracle E-Business Tax

Multiple Organizations Access Control

Multiple Organizations Access Control

Multiple Organizations Access Control:-
----------------------------------------------

Multiple Organizations Access Control is an enhancement to the Multiple
Organizations feature of Oracle Applications. Multiple Organizations Access Control
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.

Oracle Applications will not automatically create security profiles during the Release 12
upgrade. If you want to use Multiple Organizations Access Control, you will first need
to define security profiles, then link them to responsibilities or users.

Integration with Oracle E-Business Tax

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. This method of managing tax is
still available to you in Release 12. During the upgrade, E-Business Tax migrates the tax
codes and their rates to corresponding tax rules so that your tax processing can get the
same results after the upgrade as it did before. If you choose to use the features of
E-Business Tax, you can make the transition at your own pace, incrementally adding
E-Business Tax rules to meet your requirements.

In Release 12, there are new fields added to the supplier, invoice, and related entities
that track tax attributes used by E-Business Tax. Many of these attributes were
implemented with Global Descriptive Flexfields in prior releases and are upgraded to
regular fields on these entities.

Also during the upgrade, E-Business Tax takes information from the AP invoice lines
and creates summary and detail tax lines in the E-Business Tax repository. The tax lines
are upgraded based on the time period you specify during the submission of the
upgrade. During the upgrade, Payables creates payment distributions and prepayment
application distributions for existing transactions and creates links between these new
distributions and the original invoice distributions. After the upgrade, if you adjust a
historical transaction that was not upgraded, E-Business Tax automatically upgrades
the transaction to the Release 12 entities.

Tax Attributes Controlled by Global Descriptive Flexfields Migrated to Core Payables and E-Business Tax Entities

The following tax attributes were implemented using descriptive flexfields on the
invoice entities in Release 11i and are now implemented using named columns. The
Invoice Lines upgrade will upgrade the values from the descriptive flexfields segments
to the new columns.

The following are new fields on the invoice header and in the invoice interface:
• Business Category
• Fiscal Classification
• Invoice Sub-type
• Port of Entry
• Supplier Exchange Rate
• Supplier Tax Invoice Date
• Supplier Tax Invoice Number
• Tax Date
• Tax Reference Number

The following are new fields on the invoice line and in the invoice lines interface:

• Assessable Value
• Business Category
• Deferred Option, Distribution Account
• Fiscal Classification
• Intended Use
• Product Category
• Ship-To Location
• Supplier Exchange Rate
• User Defined Fiscal Classification

The following are new fields on the invoice distribution:

• Fiscal Classification
• Distribution Account
• Intended Use

Integration with Oracle Subledger Accounting

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. During the upgrade, accounting options and their settings, and the existing
accounting entries in the Payables data model are moved to the new SLA accounting
data model. Also during the upgrade, Payables sets up SLA to replicate the accounting
created by Payables in Release 11i.

The new SLA architecture requires Payables to maintain specific data relating to
transactions. SLA uses this data to generate accounting entries. In order to achieve this
it was determined that both payment distributions and prepayment application
distributions would be introduced into the Payables data model. Unlike invoice
distributions that can be entered by the user, payment distributions will be generated
automatically and will be associated with each accounted payment.

During the upgrade, all accounting events, headers and lines from the 11i data model
are upgraded to the new Subledger Accounting events, headers and lines data model,
regardless of the number of periods you specify when submitting the upgrade. If the
Global Accounting Engine (AX) is enabled for the set of books associated with a given
Operating Unit, then the upgrade migrates the AX accounting events, headers and lines
to SLA instead of those in Payables. The payment distributions and prepayment
application distributions are upgraded based on time periods you specify during the
submission of the upgrade. During the upgrade, Payables creates payment distributions
and prepayment application distributions for existing transactions in the periods you
specify for upgrade and creates links between these new distributions and the original
invoice distributions.

If you have customizations based on the 11i AP accounting tables, you need to
transition them to use the SLA data model. Also note, if you use Oracle Projects,
Projects uses SLA in Release 12 and creates accounting entries for adjustments rather
than using Payables to create those entries as in prior releases. If you have any
customizations based on Project adjustments, you will need to transition them to the
SLA data model.

The Deferred Expenses feature, supported with Global Descriptive Flexfields at the
invoice distribution level in Release 11i, has been replaced by the Multi-Period
Accounting feature in SLA.

Upgrading Payables Accounting Entries to Subledger Accounting

The following table displays the mapping from 11i entities to new Release 12 entities.

Source 11i Entity	Release 12 Entity
AP/AX Accounting Events, Headers, Lines	SLA Accounting Events, Headers, Lines
AP Payment History, Invoice Payments and Invoice Distributions	AP Payment History and AP Payment Distributions
AP Prepayment History and Invoice Distributions	AP Prepayment Application Distributions
AP Accounting Lines and Invoice Distributions	AP Distribution Links

Upgrading Payables System Options to SLA

The following table displays the mapping from 11i system option settings to the new
accounting setup entities and settings.

Source 11i Window and Field	Release 12 Window and Field
Payables Options: Primary Accounting Method	GL Accounting Setup: Sub-ledger Accounting Method
Payables Options: Secondary Accounting Method	GL Accounting Setup: Sub-ledger Accounting Method
Payables Options: Primary Set of Books	GL Accounting Setup: Primary Ledger
Payables Options: Secondary Set of Books	GL Accounting Setup: Secondary Ledger
Payables Options: Prevent Prepayment Application Across Balancing Segment	Obsolete. Supported by SLA inter-company Balancing.
Payables Options: Relieve Future Dated Payment Liability When: • Payment is Issued • Payment Matures • Payment Clears	Obsolete. Supported by Payments bills payable feature.

Creating Payment Distributions and Prepayment Application Distributions

During the upgrade, Payables creates payment distributions for existing payments,
links those distributions with the original invoice distributions and adds payment,
payment adjustment and payment cancellation information to the payment history
records. Since you control the periods that are upgraded (by setting them during the
SLA upgrade), Payables also adds an indicator to mark which historical data has been
upgraded.

Also during the upgrade, Payables creates prepayment application distributions for
existing prepayment invoices, links those distributions with the original prepayment
distributions and adds a prepayment history entity to track historical prepayment
application and non-application entries. Since you control the periods that are
upgraded (by setting them during the SLA upgrade), Payables also adds an indicator to
mark which historical data has been upgraded.

After the upgrade, if you find that you need to adjust a historical payment or need to
unapply a prepayment application that did not have its data upgraded, you can run the
SLA postupgrade process to upgrade the entries for that record.

Creating Distribution Links

During the upgrade, Payables migrates invoice distribution links, prepayment
application distribution links and payment distribution links into the SLA distribution
links entity for the data that has been populated in the payment distributions and
prepayment application distributions table for the periods you selected to upgrade.

Populating the Initial Balances for the Open Account Balances Listing Report

As part of the Subledger Accounting introduction, a new report, the Open Account
Balances Listing, replaces the 11i Payables Trial Balance. During the upgrade, Payables
and SLA populate the initial liability balances by ledger, formerly "set of books," based
on Payables transactions as of the periods you selected to upgrade.

The following table displays the mapping from 11i standard reports to the new
SLA-based reports.

Obsolete 11i Standard Reports	Release 12 SLA Report
Accounts Payable Trial Balance	Accounts Payable Trial Balance
Payables Accounting Entries Report	Journal Entries Report (SLA)
Payables Account Analysis Report	Account Analysis Report (SLA)

Payment Configuration Controlled by Global Descriptive Flexfields

Payment Configuration Controlled by Global Descriptive Flexfields:-
-------------------------------------------------------------------------------

Various aspects of payment configuration were controlled by Global Descriptive
Flexfields (GDF) in Release 11i and are now implemented in an integrated fashion
across core Oracle Payables, Oracle Payments and Oracle Cash Management. This
section is organized by functional area and discusses the upgrade impact on Oracle
Payables:

• Bank Charge Bearer Controls
• Bank Information and Instructions
• Regulatory Reporting Controls
• Regulatory Reporting, Payment Reasons
• Settlement and File Directory Controls
• Payment File Information
• Payment File Formatting
• Payment Text Messaging
• Unique Remittance Identifiers
• Remittance Advice Controls
• Settlement Controls
• Danish Payment Categories
• Settlement Priority
• Miscellaneous Obsolete GDFs

Bank Charge Bearer Controls

In Release 11i, there are a number of GDFs that support the entry of information in the
payment file about who should bear the cost of bank fees for a payment. Presently, this
feature is used by the following countries: Austria, Belgium, Denmark, Finland,
Germany, Netherlands, Norway, and Sweden. If you are not operating in these
countries, you can disregard this section. The Japan Bank Charge feature implemented
in Oracle Payables did not change in Release 12.

In Release 11i, GDFs that hold bank-charge-bearer information are held at the supplier
site. Denmark is the only country that has GDFs at the bank account level, which then
defaults to invoices in both the invoice interface and the invoices tables.

In Release 12, the following Global Descriptive Flexfields are obsolete. During the
upgrade, Oracle Payments will migrate the bank-charge-bearer information from the
GDFs to bank charge bearer information stored on the payer and payee entities and
optionally, the AP invoice:

• Austria: Bank Charge Code
• Belgium: Foreign Payment Cost Code
• Germany: Charge Code
• Finland: Bank Expense Code
• Netherlands: Domestic Costs Code, Correspondent's Costs Code
• Norway: Norwegian Cost, Foreign Cost
• Sweden: Payment Expense Code
• Denmark: Settlement Code

Bank Information and Instructions

In Release 11i, there are a number of GDFs that support the entry of information about
the bank where the disbursement bank account is held as well as payment instruction
information specifying when and how the bank should transfer money to the supplier.
Presently, this feature is used by the following countries: Finland, Germany,
Netherlands, Sweden. If you are not operating in these countries, you can disregard this
section.

In Release 11i, GDFs that hold bank information are held at the supplier site and global
payment format levels. In Release 12, the following GDFs are obsolete. The bank
information is migrated to the central Cash Management bank data model and the bank
instructions are migrated to Oracle Payments and stored at the payment process profile
and payee setup levels:

• Netherlands: DNB Registration Num, Authorized Bank
• Denmark: Bank Code, Country Code
• Finland: Processing Type
• Germany: Bank Instruction, Bank Instruction Details
• Netherlands: Cross Check, Check Forwarding Code
• Sweden: UTLI Header Code, OCR Customer Reference

Regulatory Reporting Controls

In Release 11i, some GDFs support the reporting of certain information to country
governments or central banks. Presently, this feature is used by the following countries:
Germany and Netherlands. If you are not operating in these countries, you can
disregard this section.

In Release 11i, GDFs that hold central bank reporting information and control fields,
like thresholds, are held at the following levels: system payment format, supplier site,
bank account, invoices (including invoice interface) and scheduled payments. The
Netherlands also used two profile options, JENL: Reporting Threshold and JENL:
Validate All Invoices. In Release 12, the following GDFs and profiles are obsolete and
regulatory reporting is setup at the payment process profile level in Oracle Payments.
Since this feature was redesigned with a fresh perspective based on requirements from
all countries, no data will be upgraded from the GDFs.

• Germany: Declaration Flag, Declaration Limit
• Netherlands: EFT Rate Type and profiles Reporting Threshold and Validate All
Invoices

Regulatory Reporting, Payment Reasons

In Release 11i, there are a number of GDFs that support collecting of information
pertaining to why a supplier or invoice is being paid. This information is required by
government or central bank reporting. This feature is used by the following countries:
Belgium, Denmark, Netherlands, Norway, Poland, and Sweden. If you are not
operating in these countries, you can disregard this section.

In Release 11i, GDFs that hold payment reason information are held at the following
levels: system payment format, supplier site, bank account, and invoices (including
invoice interface). In Release 12, the following GDFs are obsolete and payment reasons
are collected at the payee level and defaulted to the invoice. Oracle Payments will not
support a system level payment reason in Release 12. During the upgrade, existing
values in the country-specific lookups for payment reasons will be migrated to Oracle
Payments payment reasons and data in invoice GDFs will be migrated to the new
columns on the invoice entities.

• Belgium: IBLC, IBLC Code
• Denmark: Import Code, Import Code Specification
• Netherlands: Payment Category Code, Payment Nature, Goods Code
• Norway: Declaration Code, Declaration Desc
• Poland: Insurance Premium Type
• Sweden: Federal Reserve Code

Settlement and File Directory Controls

In Release 11i, there are a number of GDFs and profile options that control settlement
and various aspects of payment formatting, including file directories. In Release 12, the
following GDFs and profiles are obsolete and the features are handled as indicated:

• Austria, Denmark, and all countries that use Oracle e-Commerce Gateway for
electronic file delivery: Input File Path, Output File Path (upgraded to Oracle
Payments payment process profiles)

• Finland: Illegal Characters, Legal Replacement Characters (migrated to Oracle
Payments payment formatting)

• Netherlands: EFT Directory, Payment Separation, and Invoice Compression profiles
(upgraded to Oracle Payments payment process profiles, payment formatting and
payment building; no data upgraded for the grouping feature, however
compression logic is upgraded)

• Norway: Path for payment file, Last Sequence Number, Last Num Sent to BBS,
Trans Seq Num, Seq Control and profile SigNet config fil (upgraded to Oracle
Payments payment process profiles and payment formatting)

• Norway: SIGILL Identifier, SIGILL Format (Oracle Payments' transmission and
security feature allows integration with third party utilities, like the SigNet sealing
operation. The Release 12 upgrade will not migrate the SIGILL setup data. Oracle
Payments provides a standard configuration and you can re-configure to meet
specific requirements for Norway.)

• Sweden: Receiver Name (migrated to Oracle Cash Management bank account setup
for factor bank accounts; no data will be migrated. You should set up parties for the
factor companies, create their bank accounts, and link them to the supplier/payee
model.)

• Sweden: EFT File Directory, Date + Sequence (upgraded to Oracle Payments
payment process profiles and payment formatting)

Payment File Information

In Release 11i, there are a number of Global Descriptive Flexfields (GDFs) that support
entry of information assigned by a bank or third-party, payment system to the
deploying company, also referred to as the first-party payer. The Global Descriptive
Flexfields are used to capture this kind of information for implementations in the
following countries: Finland, Germany, Netherlands, Norway, Sweden, Switzerland,
and Denmark. If you are not operating in these countries, you can disregard this
section.

In Release 11i, GDFs that hold this payment file information are held at payment format
level and at internal bank account level. You could enter payment format information in
two places. The first, used for Germany, Netherlands, Norway, Sweden, and
Switzerland, is the EFT System Information window, accessed from the main menu.
The second, used by Finland, is a window accessed from the AP Payment Formats
window, the Payment Format EFT Details window. Denmark is the only country that
has GDFs at the bank account level.

In Release 12, the following Global Descriptive Flexfields are obsolete:

• Denmark: Sender Identification, Communication Agreement, User Name,
Password, UBT-Number

• Finland: EDI Identifier, EFT User Number, Exchange Rate Contract Number

• Germany: LZB Area Number, Company Number

• Netherlands: Trader Number, Business Sector

• Norway: Customer ID, Agreement ID, NIF Value, Division, Operator Number,
Password

• Sweden: Customer Number

• Switzerland: Company TELEKURS ID, Department TELEKURS ID, Company PTT
File ID During the upgrade, Oracle Payments will create one Payment System record for each
bank and a corresponding Payment System Account and its attributes for values
formerly supported by the GDFs.

Payment File Formatting

In Release 11i, some GDFs and profile options for Netherlands and Sweden set a value
at implementation time, then include that value in each formatted payment file to the
bank. The values are not migrated during the upgrade. There are two options that users
have in Release 12:

• Populate the desired value in the Oracle Payments EFT payment format template

• Create the value as a bank instruction on the payment process profile in Oracle
Payments.

The following GDFs and profiles are obsolete in Release 12:

• Netherlands: EFT Rate Tye and profiles EFT Reference Text, Carriage Return

• Sweden: Sender Code, Credit Days, Payment Date, Accounting Code, Sort Option,
Credit Code, Report code, Invoice Option, Days Credit Memo Valid

Payment Text Messaging

In Release 11i, there are several GDFs that support the entry of text messages to be sent
to payees in a payment format. In Release 12, the following GDFs and profiles are
obsolete and text message fields are available at Oracle Payments payment process
profile and payee setup levels as well as at the invoice level in Oracle Payables:

• Sweden: Invoice Information, Invoice End Date, Invoice Title, Amount Header,
Message Row 1, Message Row 2

• Finland: Short Message Line, Long Message Line 1, Long Message Line 2, Tax
Message, Reference Text

• Denmark: Short Notice, Bank Notice, Supplier Message

• Norway: Message to Supplier

• Germany: Explanation

Not all GDFs will migrate to the new functionality in Oracle Payments. Invoice End
Date will be obsolete in Release 12. Users can remove any message text once they do not
want it included in the payment file. Amount Header will also become obsolete. The
requirement for this field can be met using the EFT format template in Oracle Payments.

Unique Remittance Identifiers

In Release 11i, there are several GDFs that support the entry of reference information
that gets passed along with a payment in the payment file to assist in reconciling the
payment to its invoices. In Release 12, the following GDFs are obsolete and the unique
remittance identifiers, like reference number and check digit, can be entered on the
invoice in Oracle Payables:

• Denmark: Party ID

• Finland: Reference Number, Check Digit, Tax Reference

• Norway: KID, Invoice Number

• Switzerland: ESR Number

Data will be migrated from the GDFs to the new fields on the invoice. Country-specific
validation for the reference numbers will be migrated into the validation module of
Oracle Payments.

Remittance Advice Controls

In Release 11i, there are country-specific tables and profile options that control the
frequency and method of creating a remittance advice. In Release 12, the following
tables and profiles are obsolete and the remittance advice creation is managed by the
payment process profile and its remittance controls:

• Germany: JE_DE_AR_BATCHES.REMIT_BATCH_ID and REMIT_BATCH_NAME

• Germany: JE_DE_AP_BATCHES.CHECKRUN_NAME

• Netherlands: JE_NL_EFT_SPECS.CHECKRUN_NAME and CHECK_NUMBER

• Italy: "AP Payment: Company Details Printed" profile option.

• Netherlands: "JENL: Payment Specification" profile option.

Oracle Payments provides an XML Publisher template for creating a remittance advice.
You can modify this template to meet the requirements of your country.

Settlement Control

In Release 11i, there are several fields that specify the way an invoice should be settled.
The fields used for this purpose come in three categories: payment methods, delivery
channels (which specify how a bank provides a payment to the payee), and payment
formats. These fields include both Oracle Payables functionality and GDFs. In Release
12, the following GDFs, and other entities, are obsolete and the settlement information
is handled by Oracle Payments:

• Denmark: JE_DK_PAY_CATEGORIES (Note: payment means and channel will not
be upgraded. The mapping will happen in the Danish payment format template
provided by Oracle Payments.)

• Denmark: Payment Means, Payment Channel, Payment Category, Payment
Category ID

• Finland: Payment Type, Payment Format

• Germany: Payment Method

• Netherlands: Urgency Code

• Sweden: Payment Type

• Switzerland: Payment Type

During the upgrade, Oracle Payments will migrate payment methods from the Oracle
Payables entity to the new Oracle Payments payment methods entity and will upgrade
all invoice data. Payments will also migrate default values for payment method,
delivery channels and payment formats from the Global/Payables system, supplier,
supplier sites and payee setups to the new Oracle Payments solution.

Danish Payment Categories

The form that supports the specification of payment categories is obsolete in Release 12.
The functionality that this form supported is partially migrated to new entities in Release 12. Part of the upgrade verification testing for electronic payment processing in
Denmark should be to review the migrated data and configure new setup as needed.

Each payment category is upgraded to a payment method in Oracle Payments. As
noted in the previous section, the payment means and payment channel associated with
the payment category are not upgraded. In Release 12, values for these should be set in
the XML Publisher format template associated with the specific payment format. The
seeded Danish format templates contain example mappings to help guide you in setting
this information.

The payment category setup allows implementers to define the validation of certain
invoice fields based on the payment category (for example, a field is required). The
upgrade does not automatically migrate these settings to the new Oracle Payments
validation model. After the upgrade, the payment methods should be reviewed, and the
validations should be configured as user-defined validations set as needed on each
payment method.

Settlement Priority

In Release 11i, there are GDFs that control how urgently the bank should handle the
fund disbursement. In Release 12, the following GDFs are obsolete and the settlement
priority is entered on the invoice and managed by Oracle Payments:

• Norway: Urgency Called

• Sweden: Express Invoice, Express Payment (Note: In 11i, Sweden stores the

payment format in a GDF context field. During the upgrade, the payment format is
migrated to the payment format column on the invoice entity.)
During the upgrade information is migrated from the GDFs into the new columns.

Miscellaneous Obsolete GDFs

The following GDFs are not used in payment formats, and are obsolete:

• Denmark: Dummy

• Finland: Check A/B-form info?, Exchange Rate Contract Number, Dependence
Code

• Norway: Last Date File Created, Sigil ID, Sum

• Sweden: Account Code, Clearing Number, Envelope, Future Contract Postgiro,
Future Contract, BGC, Invoice charge Code

• Switzerland: Company ID

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. The benefit of these changes is to
help ensure an implementation that best supports a controlled and efficient
disbursement flow, and provide enhancements over the way payment processing was
set up in different products.

A significant change for Payables users is that Payments uses XML Publisher for
payment formatting. During the upgrade, Payments will upgrade the seeded Payables
payment formats to Payments formats that can be used with configurable XML
Publisher templates. If you have custom payment formats, you need to migrate them to
XML Publisher in order to use them in Release 12. Payments continues to use the
concept of Payment Methods, as they worked in Payables, however there are some
minor enhancements, which are noted below. The Future Dated Payments feature has
been renamed to Bills Payable in Release 12 and setup has moved from the payment
document on an internal bank account to the payment method in Oracle Payments.

In Release 12, the process of making EDI payments using Oracle e-Commerce Gateway
has changed, details are noted below.

In Release 12, the Automatic Bank Transmission and XML Payments features are
obsolete, as Oracle Payments provides enhanced features that meet the same
requirements.

During the upgrade, payment batches in Payables are upgraded to payment
instructions in Oracle Payments. Payments created in those payment batches, however,
are not upgraded. Payments remain in Oracle Payables for review and reporting. In
Release 12, new payments can be viewed in both Payments and Payables.

Payment Formats

During the Release 12 Oracle Payments upgrade, one Oracle XML Publisher template is
created and linked to one Oracle Payments format for each Oracle Payables (AP)
payment program that is linked to a format definition. In Payables, you can create
different format definitions linked to the same payment program. So for each AP format
definition, the upgrade creates one Payment Process Profile linked to the Oracle Payments format.

The payment programs that controlled the building and formatting of payments and
the programs that created the separate remittance advice documents are obsolete with
Release 12 and the integration with Oracle Payments.

The following tables display the mapping from seeded 11i AP Payment Formats to the new Release 12 Oracle Payments XML Publisher Formats. Obsolete formats are so noted.

Source 11i Payment Format (Program) Oracle Payables	Release 12 Oracle Payments Format Name (Code)
Long Check Format (APXPBFEG)	External Check Format (IBY_PAY_CHK_STANDARD_2)
Long Check Format; stub after payment (APXPBFEG)	External Check Format (IBY_PAY_CHK_STANDARD_2A)
Long Laser Format (APXPBFEL)	Laser Check Format (IBY_PAY_CHK_LASER)
Long Laser Format; stub after payment (APXPBFEL)	Laser Check Format (Stub After Payment) (IBY_PAY_CHK_LASER_A)
Short Check Format (APXPBFEG)	External Check Format (IBY_PAY_CHK_STANDARD_2A)
Short Form Feed Format (APXPBFEF)	External Form Feed Check Format (IBY_PAY_CHK_FORM_FEED_2)
Short Form Feed Format; stub after payment (APXPBFEF)	External Form Feed Check Format (Stub After Payment) (IBY_PAY_CHK_FORM_FEED_2A)
Standard Check Format (APXPBFOR)	Standard Check Format (IBY_PAY_CHK_STANDARD_1)
Standard Check Format; stub after payment (APXPBFOR)	Standard Check Format (Stub After Payment) (IBY_PAY_CHK_STANDARD_1A)
US Treasury Check (APXPBFUS)	US Treasury Format (IBY_PAY_CHK_TREASURY)
BACS 1/2 Inch Tape (APXPBFBC)	UK BACS 1/2 Inch Tape Format (IBY_PAY_EFT_BACS_UK)
EDI Outbound Program (APECEPYO)	Obsolete
NACHA Payment Format (APXNACHA)	US NACHA CCD Format (IBY_PAY_EFT_NACHA_CCD_US)
XML Payment Format (APXMLPMT)	XML Payment Format (APXMLPMT) Obsolete

Source 11i Payment Format (Program) Oracle Federal Payables	Release 12 Oracle Payments Format Name (Code)
BD CCDP format (FVBLCCDP)	US Bulk CCDP Format (IBY_PAY_EFT_FED_BULK_CCDP)
BD NCR Format (FVBLNCR)	US Bulk NCR Format (IBY_PAY_EFT_FED_BULK_NCR_1)
Bulk PPDP format (FVBLPPDP)	US Bulk PPDP Format (IBY_PAY_EFT_FED_BULK_PPDP)
BD Sal/Trv NCR Format (FVBLSLTR)	US Bulk Salary and Travel NCR Format (IBY_PAY_EFT_FED_BULK_NCR_2)
Bulk Data CCD+ Consolidated Payment File Program (FVCOCCDP)	US CCDP Consolidated Format (IBY_PAY_EFT_FED_CCDP_CONSOL)
CTX Consolidated File Payment Program (FVCONCTX)	US PPDP Consolidated Format (IBY_PAY_EFT_FED_PPDP_CONSOL)
Bulk Data PPD+ Consolidated Payment File Program (FVCOPPDP)	US CTX Consolidated Format (IBY_PAY_EFT_FED_CTX_CONSOL)
SPS CCD Format (FVSPCCD)	US SPS CCD Format (IBY_PAY_EFT_FED_SPS_CCD)
SPS CCDP Format (FVSPCCDP)	US SPS CCDP Format (IBY_PAY_EFT_FED_SPS_CCDP)
SPS Check NCR Format (FVSPNCR)	US SPS NCR Format (IBY_PAY_EFT_FED_SPS_NCR)
SPS PPD Format (FVSPPPD)	US SPS PPD Format (IBY_PAY_EFT_FED_SPS_PPD)
SPS PPDP Format (FVSPPPDP)	US SPS PPDP Format (IBY_PAY_EFT_FED_SPS_PPDP)
ECS Check NCR Format (FVTIACHB)	US ECS NCR Check Format (IBY_PAY_EFT_FED_ECS_NCR)
ECS CCDP Format (FVTIACHP)	US ECS CCDP Format (IBY_PAY_EFT_FED_ECS_CCDP)
CTX Vendor Format (FVTICTX)	US CTX Format (IBY_PAY_EFT_FED_CTX)
ECS CCD Format (FVTPCCD)	US ECS CCD Format (IBY_PAY_EFT_FED_ECS_CCD)
ECS PPD Format (FVTPPPD)	US ECS PPD Format (IBY_PAY_EFT_FED_ECS_PPD)
ECS PPDP Format (FVTPPPDP)	US ECS PPDP Format (IBY_PAY_EFT_FED_ECS_PPDP)
Summary Schedules (FVSUMSCH)	Obsolete
ECS and SPS Summary Schedules	IBY_PAY_EFT_FED_ECS_SUM_SCHED and IBY_PAY_EFT_FED_SPS_SUM_SCHED

Source 11i Payment Format (Program) Argentina	Release 12 Oracle Payments Format Name (Code)
Argentine Check Format (JLARPCFP)	Argentine Check Format (IBY_PAY_CHK_AR)

Source 11i Payment Format (Program) Austria	Release 12 Oracle Payments Format Name (Code)
Austrian Foreign EFT (JEATIEFT)	Obsolete
Austrian Domestic (JEATREFD)	Obsolete
Austrian Transferral 1 (JEATPPF1)	Obsolete
Austrian Transferral 2 (JEATPPF2)	Obsolete
Austrian Check with Remittance Advice (JEATPPF3)	Obsolete
Austrian Check with Remittance Advice FWG (JEATPPF4)	Obsolete
Austrian Foreign Transfer Order (JEATPPF5)	Obsolete

Source 11i Payment Format (Program) Belgium	Release 12 Oracle Payments Format Name (Code)
Belgian Format 1 (JEBEEF01)	Belgian EFT Format (IBY_PAY_EFT_DOMESTIC_BE)
Belgian Format 2 (JEBEEF02)	Belgian EFT Format (IBY_PAY_EFT_DOMESTIC_BE)

Source 11i Payment Format (Program) Brazil	Release 12 Oracle Payments Format Name (Code)
Brazilian Check Format (JLBRPCFP)	Brazilian Check Format (IBY_PAY_CHK_BR)
Brazilian Bordero (JLBRPBOR)	Brazilian Bordero Format (IBY_PAY_CHK_OBRDERO_BR)

Source 11i Payment Format (Program) Chile	Release 12 Oracle Payments Format Name (Code)
Chilean Check Format (JLCLPCFP)	Chilean Check Format (IBY_PAY_CHK_CL)

Source 11i Payment Format (Program) Colombia	Release 12 Oracle Payments Format Name (Code)
Colombian Check 1 (JLCOPCF1)	Colombian Check 1 Format (IBY_PAY_CHK_1_CO)
Colombian Check 2 (JLCOPCF2)	Colombian Check 2 Format (IBY_PAY_CHK_2_CO)

Source 11i Payment Format (Program) Denmark	Release 12 Oracle Payments Format Name (Code)
Danish GiroBank Domestic (JEDKEIGO)	Obsolete
Danish GiroBank Foreign (JEDKEUGO)	Obsolete
Danish Unitel (JEDKEUNI)	Obsolete

Source 11i Payment Format (Program) Finland	Release 12 Oracle Payments Format Name (Code)
Finnish LMP2 Payment Format (JEFILLMP)	Finnish LMP2 EFT Format (IBY_PAY_EFT_LMP2_FI)
Finnish LUM Payment Format (JEFILLUM)	Finnish LUM EFT Format (IBY_PAY_EFT_LUM_FI)
Finnish LMP3 Payment Format (JEFILLMP3)	Finnish LMP3 EFT Format (IBY_PAY_EFT_LMP3_FI)
Finnish ULMP Payment Format (JEFILULM)	Obsolete

Source 11i Payment Format (Program) France	Release 12 Oracle Payments Format Name (Code)
Billet a Ordre France (JEFRAP02) (Also referred to as: French PRMSRY Note EUR, French Bill Of Exchange, French Bill of EXCH EUR)	French Promissory Note Format (IBY_PAY_PROMISSORY_NOTE_FR)
Cheque Francais (JEFRAP01)	French Check Format (IBY_PAY_CHK_FR)
Cheque Francais; stub after payment (JEFRAP01)	French Check Format (Stub After Payment) (IBY_PAY_CHK_FR_A)
Virement Francais (AFB) (JEFRAP03)	French EFT Format (IBY_PAY_EFT_FR)

Source 11i Payment Format (Program) Norway	Release 12 Oracle Payments Format Name (Code)
Norwegian BBS (JENOPBDR)	Norwegian BBS Format (IBY_PAY_EFT_BBS_NO)
Norwegian Telepay (JENOPTGN)	Forwegian Telepay EFT Format (IBY_PAY_EFT_TELPAY_NO)
Norwegian Datadialog Payment Format (JENOPDDG)	Obsolete

Source 11i Payment Format (Program) Poland	Release 12 Oracle Payments Format Name (Code)
Polish Pekao Credit Transfers Format (JEPLEFT1)	Polish Pekao Credit Transfers Format (IBY_PAY_EFT_CREDIT_TRANS_PL)
Polish Pekao Payments (JEPLEFT2)	Polish Pekao Payment Order Format (IBY_PAY_EFT_PAY_ORDER_PL)
Polish Citibank MTMS EFT Format (JEPLEFT3)	Polish Citibank MTMS EFT Format (IBY_PAY_EFT_CITI_MTMS_PL)

Source 11i Payment Format (Program) Portugal	Release 12 Oracle Payments Format Name (Code)
Portuguese Check (JEPTBFOR)	Portuguese Check Format (IBY_PAY_CHK_PT)
Portuguese EFT (JEPTPEFT)	Portuguese EFT Format (IBY_PAY_EFT_PT)

Source 11i Payment Format (Program) Spain	Release 12 Oracle Payments Format Name (Code)
Spanish EFT (JEESPEFT)	Spanish Magnetic Format (IBY_PAY_EFT_ES)
Spanish Cheque (JEESAPCP)	Spanish Check Format (IBY_PAY_CHK_ES)
Spanish PRMSRY Note EUR (JEESAPLC)	Spanish Bill of Exchange Format (IBY_PAY_CHK_BOE_ES)

Source 11i Payment Format (Program) Sweden	Release 12 Oracle Payments Format Name (Code)
Swedish Bankgiro Inland (JESEPBAI)	Swedish Domestic Bankgiro Format (IBY_PAY_EFT_BANKGIRO_SE)
Swedish Bankgiro SISU (JESEPBSI)	Swedish SISU Bankgiro Format (IBY_PAY_EFT_SISU_BANKGIRO_SE)
Swedish Bankgiro UTLI (JESEPBUT)	Swedish UTLI Bankgiro Format (IBY_PAY_EFT_UTLI_BANKGIRO_SE)
Swedish Postgiro Inland (JESEPPOI)	Swedish Domestic Postgiro Format (IBY_PAY_EFT_POSTGIRO_SE)
Swedish Postgiro Utland (JESEPPOU)	Swedish Foreign Postgiro Format (IBY_PAY_EFT_FOR_POSTGIRO_SE)

Payment Methods

The upgrade migrates the seeded payment methods of check, electronic, wire, and
clearing from Payables to the new, extensible Oracle Payments payment method entity.
Note the following changes:

• Wire - No longer restricted to payments made outside Oracle Applications. You can
link this payment method to a payment process profile for actual wire transfers.

• Clearing - Seeded as inactive in Payments since users have enhanced options for
handling intercompany processing in Release 12. It is recommended that you no
longer use this payment method, but rather use the new Intercompany-processing
feature.

EDI Payments using Oracle e-Commerce Gateway

The process to create EDI payments using Oracle e-Commerce Gateway has changed in
Release 12. The EDI Outbound Program (APECEPYO) is obsolete. Setting the value for
the Electronic Processing Channel in the Payment Process Profile setup page controls
integration with Oracle e-Commerce Gateway. Release 11i format definitions are
upgraded into payment process profiles with the electronic processing channel set
appropriately. The format information on the process profile is populated with a seeded
format. Actual formatting and transmission is performed by Oracle e-Commerce
Gateway.

Certain fields were set in the Suppliers form for EDI payment information. In Release
12, these fields have been consolidated with standard payment details fields entered for
a supplier, and the data values are migrated during the upgrade. The following table
provides a mapping between the field names for the releases.

Source 11i Entity	Release 12 Entity
Suppliers, EDI tab: Payment Method	Suppliers, Payment Details: Payment Method
Suppliers, EDI tab: Payment Format	Suppliers, Payment Details: Bank Instruction 1
Suppliers, EDI tab: Remittance Method	Suppliers, Payment Details: Delivery Channel
Suppliers, EDI tab: Remittance Instruction	Suppliers, Payment Details: Payment Text Message 1
Suppliers, EDI tab: Transaction Handling	Suppliers, Payment Details: Bank Instruction 2