, , , , , , , , ,

Allocating Move Order INV_REPLENISH_DETAIL_PUB

DECLARE

l_api_version NUMBER := 1.0;
l_init_msg_list VARCHAR2 (2) := fnd_api.g_true;
l_return_values VARCHAR2 (2) := fnd_api.g_false;
l_commit VARCHAR2 (2) := fnd_api.g_false;
x_return_status VARCHAR2 (2);
x_msg_count NUMBER := 0;
x_msg_data VARCHAR2 (255);
l_user_id NUMBER ;
l_resp_id NUMBER ;
l_appl_id NUMBER ;
l_row_cnt NUMBER := 1;
l_trohdr_rec inv_move_order_pub.trohdr_rec_type;
l_trohdr_val_rec inv_move_order_pub.trohdr_val_rec_type;
x_trohdr_rec inv_move_order_pub.trohdr_rec_type;
x_trohdr_val_rec inv_move_order_pub.trohdr_val_rec_type;
l_validation_flag VARCHAR2 (2) := inv_move_order_pub.g_validation_yes;
l_trolin_tbl inv_move_order_pub.trolin_tbl_type;
l_trolin_val_tbl inv_move_order_pub.trolin_val_tbl_type;
x_trolin_tbl inv_move_order_pub.trolin_tbl_type;
x_trolin_val_tbl inv_move_order_pub.trolin_val_tbl_type;
x_number_of_rows NUMBER ;
x_transfer_to_location NUMBER ;
x_expiration_date DATE;
x_transaction_temp_id NUMBER ;

CURSOR c_mo_details IS

SELECT mtrh.header_id, mtrh.request_number, mtrh.move_order_type,
mtrh.organization_id, mtrl.line_id, mtrl.line_number,
mtrl.inventory_item_id, mtrl.lot_number, mtrl.quantity,
revision,mtrl.from_locator_id,
(select distinct operating_unit from org_organization_definitions
where organization_id = mtrh.organization_id) org_id
FROM mtl_txn_request_headers mtrh, mtl_txn_request_lines mtrl
WHERE mtrh.header_id = mtrl.header_id
AND mtrh.request_number = ‘332557’
AND mtrh.organization_id = 381;

BEGIN

SELECT user_id
INTO l_user_id
FROM fnd_user
WHERE user_name = ‘A42485’;

SELECT responsibility_id, application_id
INTO l_resp_id, l_appl_id
FROM fnd_responsibility_vl
WHERE responsibility_name = ‘Inventory’;

fnd_global.apps_initialize (l_user_id, l_resp_id, l_appl_id);

FOR i IN c_mo_details

LOOP

mo_global.set_policy_context (‘S’, i.org_id);
inv_globals.set_org_id (i.organization_id);
mo_global.init (‘INV’);

SELECT COUNT (*)
INTO x_number_of_rows
FROM mtl_txn_request_lines
WHERE header_id = i.header_id;

DBMS_OUTPUT.put_line (‘Calling INV_REPLENISH_DETAIL_PUB to Allocate MO’);
— Allocate each line of the Move Order

inv_replenish_detail_pub.line_details_pub
(p_line_id => i.line_id,
x_number_of_rows => x_number_of_rows,
x_detailed_qty => i.quantity,
x_return_status => x_return_status,
x_msg_count => x_msg_count,
x_msg_data => x_msg_data,
x_revision => i.revision,
x_locator_id => i.from_locator_id,
x_transfer_to_location => x_transfer_to_location,
x_lot_number => i.lot_number,
x_expiration_date => x_expiration_date,
x_transaction_temp_id => x_transaction_temp_id,
p_transaction_header_id => NULL,
p_transaction_mode => NULL,
p_move_order_type => i.move_order_type,
p_serial_flag => fnd_api.g_false,
p_plan_tasks => FALSE,
p_auto_pick_confirm => FALSE,
p_commit => FALSE
);

DBMS_OUTPUT.put_line
(‘==========================================================’);
DBMS_OUTPUT.put_line (x_return_status);
DBMS_OUTPUT.put_line (x_msg_data);
DBMS_OUTPUT.put_line (x_msg_count);

IF (x_return_status <> fnd_api.g_ret_sts_success)
THEN
DBMS_OUTPUT.put_line (x_msg_data);
END IF;

IF (x_return_status = fnd_api.g_ret_sts_success)
THEN
DBMS_OUTPUT.put_line (‘Trx temp ID: ‘);
DBMS_OUTPUT.put_line (x_transaction_temp_id);
END IF;
DBMS_OUTPUT.put_line
(‘==========================================================’);
END LOOP;

EXCEPTION
WHEN OTHERS
THEN
DBMS_OUTPUT.put_line (‘Exception Occured :’);
DBMS_OUTPUT.put_line (SQLCODE ‘:’ SQLERRM);
DBMS_OUTPUT.put_line
(‘=======================================================’);
END;

DBMS Output: –

Calling INV_REPLENISH_DETAIL_PUB to Allocate MO
==========================================================
S
Trx temp ID: 1094230
==========================================================

select * from mtl_material_transactions_temp
where transaction_temp_id = 1094230

1 Row Returned

/by
, , , , , , , , ,

Transact Move Order Using INV_PICK_WAVE_PICK_CONFIRM_PUB

DECLARE
l_api_version NUMBER := 1.0;
l_init_msg_list VARCHAR2 (2) := fnd_api.g_true;
l_commit VARCHAR2 (2) := fnd_api.g_false;
x_return_status VARCHAR2 (2);
x_msg_count NUMBER := 0;
x_msg_data VARCHAR2 (255);
l_move_order_type NUMBER := 1;
l_transaction_mode NUMBER := 1;
l_trolin_tbl inv_move_order_pub.trolin_tbl_type;
l_mold_tbl inv_mo_line_detail_util.g_mmtt_tbl_type;
x_mmtt_tbl inv_mo_line_detail_util.g_mmtt_tbl_type;
x_trolin_tbl inv_move_order_pub.trolin_tbl_type;
l_transaction_date DATE := SYSDATE;
l_user_id NUMBER;
l_resp_id NUMBER;
l_appl_id NUMBER;
CURSOR c_mo_details IS
SELECT mtrh.header_id, mtrh.request_number, mtrh.move_order_type,
mtrh.organization_id, mtrl.line_id, mtrl.line_number,
mtrl.inventory_item_id, mtrl.lot_number, mtrl.quantity,
revision, mtrl.from_locator_id,
(SELECT DISTINCT operating_unit
FROM org_organization_definitions
WHERE organization_id = mtrh.organization_id) org_id
FROM mtl_txn_request_headers mtrh, mtl_txn_request_lines mtrl
WHERE mtrh.header_id = mtrl.header_id
AND mtrh.request_number = ‘332557’
AND mtrh.organization_id = 381;
BEGIN
SELECT user_id
INTO l_user_id
FROM fnd_user
WHERE user_name = ‘A42485’;
SELECT responsibility_id, application_id
INTO l_resp_id, l_appl_id
FROM fnd_responsibility_vl
WHERE responsibility_name = ‘Inventory’;
fnd_global.apps_initialize (l_user_id, l_resp_id, l_appl_id);
FOR i IN c_mo_details
LOOP
mo_global.set_policy_context (‘S’, i.org_id);
inv_globals.set_org_id (i.organization_id);
mo_global.init (‘INV’);
l_trolin_tbl (1).line_id := i.line_id;
— call API to create move order header
DBMS_OUTPUT.put_line
(‘=======================================================’);
DBMS_OUTPUT.put_line
(‘Calling INV_Pick_Wave_Pick_Confirm_PUB.Pick_Confirm API’);
inv_pick_wave_pick_confirm_pub.pick_confirm
(p_api_version_number => l_api_version,
p_init_msg_list => l_init_msg_list,
p_commit => l_commit,
x_return_status => x_return_status,
x_msg_count => x_msg_count,
x_msg_data => x_msg_data,
p_move_order_type => i.move_order_type,
p_transaction_mode => l_transaction_mode,
p_trolin_tbl => l_trolin_tbl,
p_mold_tbl => l_mold_tbl,
x_mmtt_tbl => x_mmtt_tbl,
x_trolin_tbl => x_trolin_tbl,
p_transaction_date => l_transaction_date
);
DBMS_OUTPUT.put_line
(‘=======================================================’);
DBMS_OUTPUT.put_line (x_return_status);
DBMS_OUTPUT.put_line (x_msg_data);
DBMS_OUTPUT.put_line (x_msg_count);

IF (x_return_status <> fnd_api.g_ret_sts_success)
THEN
DBMS_OUTPUT.put_line (x_msg_data);
END IF;
DBMS_OUTPUT.put_line
(‘=======================================================’);
END LOOP;
EXCEPTION
WHEN OTHERS
THEN
DBMS_OUTPUT.put_line (‘Exception Occured :’);
DBMS_OUTPUT.put_line (SQLCODE ‘:’ SQLERRM);
DBMS_OUTPUT.put_line
(‘=======================================================’);
END;
DBMS Output:
=======================================================
Calling INV_Pick_Wave_Pick_Confirm_PUB.Pick_Confirm API
=======================================================
S
=======================================================
Verification:
select * from mtl_material_transactions_temp
where transaction_temp_id = 1094230
No Rows Returned
— Link the Move Order with the Material Transcations Table

SELECT
mmt.transaction_id,
mtrl.organization_id,
mtrh.request_number,
mtrh.header_id,
mtrl.line_number,
mtrl.line_id,
mtrl.inventory_item_id,
mtrh.description,
mtrh.move_order_type,
mtrl.line_status,
(select meaning from mfg_lookups
where lookup_type = ‘MTL_TXN_REQUEST_STATUS’
and lookup_code = mtrl.line_status) Line_status_meaning,
mtrl.quantity,
mtrl.quantity_delivered,
mmt.transaction_type_id,
mmt.transaction_date
FROM mtl_txn_request_headers mtrh,
mtl_txn_request_lines mtrl,
mtl_material_transactions mmt
WHERE mtrh.header_id = mtrl.header_id
AND mtrh.organization_id = mtrl.organization_id
AND mtrl.line_id = mmt.move_order_line_id
AND mtrh.request_number = 332557
AND mtrh.organization_id = 381

/by
, , , ,

R12 Upgrade Vs Re-implement

When a company is planning to adopt R12 from previous versions, the first question arises is whether to Upgrade or Re-implement?

First let us see what is the difference between an upgrade and re-implement.

An R12 upgrade involves running the scripts on a database to transform it into R12 structure. During the upgrade all the data will be moved to the respective  tables in R12.

A re-implementation involves creating a completely new oracle applications installation, doing all the set-ups from scratch and moving the data using data conversions to the new R12 database.

Let us see the advantages and disadvantages of an upgrade and re-implement

Upgrade:

The major advantages of an upgrade process are:

1. The upgrade process has become easy as the technology, tools and the upgrade scripts are significantly improved
2. There will be no effort of data conversions and testing, as the data will be moved during the upgrade process
3. Not many customizations are needed
4. No changes in the functional setups
5. Upgrade is often cheaper as it involves significantly less work for setting up the applications

But an upgrade process requires very significant effort technically and is more challenging. In comparison with re-implementation process an upgrade is risky in technical perspective.

Re-implement:

The main advantage with Re-implementation process is that the technical risk is low when compared with an upgrade.

Disadvantages:

1. Re-implementation process is very extensive as the data conversions and testing is involved.
2. Lot of effort is needed for application configuration.

Organizations generally go for following considerations before going for the re-implementation.

1. There are major changes in the Organization structure or business processes, and the existing application configuration doesn’t fit for the business
2. There are lot of customizations that can be avoided with the new features and functionality
3. The original implementation has disturbed and unusable.
4. There is lot of bad data exists.

/by
, , , , , , ,

Accounting entries in Purchasing, Payables and Receivables

When we enter transactions in Purchasing, the accounting entries will get generated with respect to the following accounts.

1. When Creating a receipt:
Inventory Receiving A/C DR
Accrual Account CR

2. At the time of Receiving transactions:
Asset clearing A/c or Inventory valuation a/c DR
Inventory Receiving A/c CR

3. When a Payables invoice matched with PO:
Accrual A/C DR
Liability A/c

4. when asset addition done:
Asset A/c DR
Asset Clearing A/c CR(Asset item)
           (OR)
expense a/c DR
inventory Valuation A/C(Inventory item)

When we enter transactions in Payables, the accounting entries will get generated with respect to the following accounts.

1. Invoice: When we create accounting for an invoice, the accounting will be generated with respect to the following accounts.

Item Expense A/C      DR
Liability  A/C             CR

2. Payment: There are two stages in which the accounting may generate, based on the accounting option that we setup in Payables.
  
> Direct Pay-No Clearance: In this stage, there will be no clearance process separately and the cash account will get credited directly.

Liability  A/C    DR
Cash  A/C         CR

> Pay and Clear: In this stage, the payment and clearance process will have separate accounting entries.

At the time of Payment:

Liability A/C               DR
Cash Clearing A/C      CR

At the time of Clearance:

Cash Clearing A/C    DR
Cash A/C                  CR

 When we enter transactions in Receivables, the accounting entries will get generated with respect to the following accounts.

1. Accounting for invoice:
Receivables A/C DR
Revenue Account Cr

2. Credit memo:
Revenue Dr
Receivables A/C CR

3. Receipts:
Cash A/C DR
Receivables A/c CR

/by
, , , , ,

Major changes in AP – R12

1. Supplier Creation and Maintenance:

In Oracle R12, Suppliers are now part of TCA(Trading Community Architecture), where suppliers are defined as parties and supplier sites as party sites. Each supplier, supplier sites and contact details can be defined globally in TCA level. It means, any changes to supplier/supplier sites/address reflects across Operating Units with out really updating every OU and all the supplier information can be leveraged by multiple Operating Units. Supplier bank information can also be handled at TCA level.

In Release 12, there is a new user interface for suppliers entry and maintenance. When user opens Supplier entry form, Oracle automatically redirects the page to TCA with a jsp form.

Impact of Upgrade:

1. During the upgrade from 11i to R12, TCA party and party sites records are created and updated in TCA for all the existing suppliers and supplier sites.             
2. TCA data model requires country and address information for suppliers, which will be used by E-Business Tax. If there is no country or address information specified to a supplier site, Oracle automatically infer the data based on most frequently used site from the supplier’s historical transactions.
3.Oracle Payables reviews the supplier sites and determines duplicates, based on         supplier,address,city,province, state, country, zip and language and creates only one party site for each distinct supplier site address.
4. In 11i the employees are associated with Payables as internal suppliers to create the payments for their expense reports. During migration of data, for internal suppliers, only party will be created in TCA and employee address will not not be migrated to party site and the data remains in HRMS records for data security.
5. As the supplier objects are moved from AP to TCA, the tables related to supplier, supplier site, and supplier address are obsolete in R12 and views are created with the obsoleted table names to link the information from old tables with information in TCA.

Table Changes:

AP_SUPPLIERS, AP_SUPPLIER_SITES_ALL, AP_SUPPLIER_CONTACTS, AP_SUPPLIER_INT_REJECTIONS are the new tables introduced to replace obsoleted tables PO_VENDORS, PO_VENDOR_SITES_ALL, PO_VENDOR_CONTACTS

2. Invoice Entry & Cancellation:

In Oracle R12, there is an additional level of detail called Invoice lines between Invoice Header and invoice distribution to capture the data related to Items, freight, miscellaneous, Tax, Prepayment or withholding tax. An invoice line can have one or more invoice distributions.
                                                                                                                                                               With the introduction of invoice lines, there is lot of significant improvement in the data flow to other modules which are integrated with Payables.
For example: 1. Fixed Assets use the data stored in the Invoice lines fields such as Manufacturer, Model,  Serial Number, Warranty Number, Asset Book and Asset Category to track the assets.
                     2. E-Business tax takes information from the AP invoice lines and creates summary and detail  tax lines in E-Business tax repository.
                     3. Sub ledger Accounting require the invoice distributions should be stored at the maximum level of detail. With additional level in the invoice hierarchy, data flow will be improved to the Sub ledger accounting.

Impact of Upgrade:

During a upgrade one invoice line will be created for every distribution for existing data in 11i.

Cancellation of Invoices:

An invoice line may be discarded on its own or as a part of invoice cancellation. A discarded invoice line will have an amount as 0, marked as discarded and creates a negative respective transaction in the distributions. If a line is discarded as a part of invoice cancellation it will be marked as cancelled.

Recurring Invoice:

In Oracle R12,For Recurring invoices,  invoice definition and line definition are introduced in place of template definition.  In line definition additional information such as Item description, Manufacturer and Model number are included. This will be helpful in smooth data flow to the integrated modules. In addition to Invoice definition and line definition few more tabs are introduced namely Tax, Control and Payment. E-business tax uses the data in Tax ad Payment module uses the data from payment tab on recurring invoices window.

Table Changes:

AP_INVOICE_LINES_ALL              New table introduced to represent the data stored in invoice lines
AP_CHRG_ALLOCATIONS_ALL    Obsolete and now distributions itself represent the allocation of charges

3. Payment Process:

In R12, Oracle Payments is a new module introduced to centralize the payment process into one payment engine, so that multiple applications can leverage the same functionality. In R12 Payables, user can find Payments manager under payment entry, which will re-direct the page to a OAF page. So unlike in 11i, user need to use Payables Payments dashboard to begin the payment process.

Build Payment Batch:

The first step in the payment process is to submit a Payment Process Request(PPR), which replaces Build payment Batch in Release 11i. The Payments Process Request form enable users to set invoice selection criteria. This form consists of various tabs such as Scheduled payment Selection Criteria, Payment Attributes, User Rates, Processing, Validation failure result and additional Information to specify the required criteria for payment processing.

Format Payment Batch:

Payment Process Request will be formatted automatically after submitting the Payment Process Request form. Users can check the status of PPR under Payment Process Request status.

Confirm Payment Batch:

When users click on start action icon, the form takes user to Payment Process Instructions tab, where users can confirm the batch if it is printed correctly, by clicking on ‘Record Print Status’ button. Here the module name changes from Payables to Payments.

>  There are no different processes  for payment and payment batch in R12. Same screen and process can be used for both .
> If user selects Payee under Scheduled payment Selection Criteria tab in the Payment Process Request  then  single payment will be done for a selected payee. If user leaves it blank, payment will be done to all suppliers.
> All Payment related setups are now moved to Oracle Payments.

4. Create Payment Instructions:

In R12 there are two programs to create payment instructions:

Create Electronic Payment Instructions    for Electronic Payments
Create Printed Payment Instructions        for Check payments

We can run these programs automatically or manually by selecting an option in the Build Payment process.

5. Transmit Payment File to Banks:

As part of R12 , there is a check box in the “Payment System” set up . When enabled the check box ” Automatic Transmit of File” – This would transfer the file to bank automatically.

There are few new set ups that needs to be done in the R12.
1. Payment System – External organization ( Internal bank) needs to be set up.
2. Transmission Configuration – This includes the ftp details and how to pull the flat file from a particular location.

6. Banks:

> Bank accounts are moved into TCA architecture which needs to be defined in R12
> Cash Management now owns Banks Set up Definition.
> All the internal bank accounts of 11.5.10, will be migrated into Centralized Bank model automatically during the upgrade.


7. Transfer journal entries to General Ledger:

Users can transfer journal entries to General Ledger in two ways.                                       
1. Run Create Accounting Program with Transfer to GL option as Yes.                          
2. Run Transfer Journal Entries to GL after running Create Accounting Program with Transfer to GL parameter set to NO or after create accounting online in Final mode.

Create Accounting Program:

Payables Accounting Process is obsolete in R12 and is replaced with Create Accounting program. The create accounting program creates sub ledger journal entries by processing eligible accounting events. The Create Accounting program uses application accounting definitions, which are created in Accounting Method Builder(AMB) to create sub ledger journal entries.

The Create Accounting program
1. Creates and validates sub ledger journal entries.
2. Transfers the final journal entries in the current batch run to General Ledger and starts General Ledger Posting Process.
3. Generates Sub ledger Accounting Program Report.

The create Accounting program creates journal entries in three modes.

Draft: Users can create the journal entries in SLA in draft mode and can review and make changes again.

Final: With this option users can create journal entries in SLA which can not be modified again. Here users need to run Transfer Journal Entries to GL to post the subledger journal entries to GL.

Final Post: With this options users can create the journal entries and post to GL with out using Transfer Journal Entries to GL program.

Transfer Journal Entries to GL:

Payables Transfer to General Ledger program is obsolete in R12 and is replaced with Transfer Journal Entries to GL. The Transfer Journal entries to GL program enables users to transfer eligible journal entries to GL, including those from the previous run that have not yet been transferred to GL.

This program is used when the Create Accounting program is run with Transfer to GL parameter set to NO or after create accounting online in Final mode.
                                                                                                                                                                      
8. Invoice Approval Workflow:

Invoice work flow has been enhanced to include line level invoice approval. Based on rules setup for Payables Invoice Approval Transaction Type in AME, the work flow determines if the invoice Header (invoice document) needs approval or invoice lines needs approval or both. If both invoice lines and document need approval, all the lines of the invoice requiring approval must be approved before the invoice document can be approved.                                                                  
                                                                              
The approval  status both at header level as well as line level shows whether the invoice document or invoice lines need approval or not.     

Setup:

> The item class provided in defining rule in AME determines whether this rule effects the invoice document approval or invoice line approval.
> If item class is given as Header, this rule govern the invoice document approval and if given as line item, would govern the invoice line approval. Remaining all setups in AME are same as in 11i.

Changes in Tables: 

In R12, there are 2 history tables for invoice approval.                                                                                               
   1.     AP_APINV_APPROVERS                Stores the line level approval history            
   2.     AP_INV_APRVL_HIST_ALL              Stores both Header and line level history.

/by