Pages

OracleEBSpro is purely for knowledge sharing and learning purpose, with the main focus on Oracle E-Business Suite Product and other related Oracle Technologies.

I'm NOT responsible for any damages in whatever form caused by the usage of the content of this blog.

I share my Oracle knowledge through this blog. All my posts in this blog are based on my experience, reading oracle websites, books, forums and other blogs. I invite people to read and suggest ways to improve this blog.


Showing posts with label R12 Articles. Show all posts
Showing posts with label R12 Articles. Show all posts

Monday, November 7, 2016

VSOE and Revenue Recognition

What is Vendor specific objective evidence(VSOE)==========================================Vendor Specific Objective Evidence, is Fair Value for Software. 
SOP 97-2 was designed for Software companies, and works fairly 
well for certain traditional business models.
The concept was introduced in 1997 by the AICPA in their Statement 
of Position (SOP) 97-2: It governs how any company that licenses, 
sells, leases or otherwise markets software (unless it’s incidental to 
the product or service as a whole) must recognize the revenue. 

In particular, it governs how companies must recognize revenue from
so-called “multiple-element arrangements” – bundles of software and
related products or services sold as a unit at a single price. 

Today, more and more companies find themselves dealing with 
VSOE as embedded software becomes an increasingly essential 
element in traditionally non-software sectors - consider cell 
phones, medical devices, computer networks, even cars with GPS
services, etc.

According to SOP 97-2: you allocate relatively, splitting the fee
amongst the products and related elements based upon VSOE – 
which is the price established by the vendor for the separate sale 
of each element. Each VSOE price is usually established through 
accumulation of a quantity of discrete sales “sufficient” to prove 
that the market, in it’s willingness to pay that price, thinks the 
price is fair. And here’s the big catch: 

You can not recognize revenue for any element either until VSOE 
exists for each and every element, or until all of the elements 
have been delivered. 

Sec's Statement of Postion (SOP) 97-2, Software Revenue 

Recognition and SOP 98-9, Software Revenue Recognition with 
respect to certain transactions, applied to all entities that license, 
sell, lease or market computer software. It specifies that revenue 
from an arrangement involving multiple elements should be 
allocated to the various elements based on VSOE fair values to 
the customer.

Sections of SOP 97-2 were amended with SOP 98-9, Software 

Revenue Recognition with respect to certain transactions, 
SOP 98-9 states that the residual method of revenue recognition is 
required when:
1. There is vendor specfic objective evidence of the fair values of all
undelivered elements in a multiple-element arrangment that is not
accounted for using long-term contract accounting.
2. VSOE of fair value does not exist for one or more of the delivered
elements in the arrangement and 3. All Revenue recognition criteria
in SOP 97-2 other than the requirment for VSOE of the fair value of
each delivered element of the arrangement are satisfied.

Elements of VSOE:
==================

-Software Licenses
- Warranty
- Installation
- Support and professional Services
- Training
Fair Market Value (FMV):
========================

The FASB defined 'fair value' in FAS 159 as "The price that 
would be received to sell an asset orpaid to transfer a liability
in an orderly transaction between market participants at the 
measurement date. " The key points in this definition are 
'orderly transaction' and 'market participants.' Thus fair value
can't be established by looking at an exchange of assets in a 
bankruptcy or between 'related parties' as defined by the SEC. 

Fair value is established by multiple, non- related market 
participants in 'normal, orderly transactions. ' VSOE, on the other
hand, is fair value as established by looking at the historical 
transactions of a specific vendor and does not consider what other
vendors are charging for similar products.

Revenue Recognition:

====================
Revenue recognition in today's regulatory and business 

environment involves sophisticated revenue scheduling and 
allocation, Vendor- specific Objective Evidence (VSOE) carve-outs
and Sarbanes-Oxley compliance. Thus having a common system 
for global compliance is key to reducing complexity.
Revenue recognition is a principle prescribing that revenue is 
recognized when earned. 

It has two considerations - when to recognize revenue, and how 
much to recognize. Revenue recognition is relevant for companies
to be able to adhere to legal compliance as per the US GAAP 
requirements.

Improper revenue recognition increases the risk of financial 
restatement, and financial restatements. Revenue for ISV's is 
typically divided into three categories: Software, Maintenance, and 
Services. Assuming that software customization is not required, 
revenue can be recognized when all of the following criteria are met: 

There are four basic criteria that must be met to recognize
revenue
- Evidence
- Delivery 
- Fixed or determinable fee
- Collectibility.

Revenue Accounting:
===================
Use the Revenue Accounting feature to quickly and easily adjust

revenue and sales credits at the transaction or line level. You can 
make manual adjustments using the Revenue Accounting and 
Sales Credits window. Alternatively, use the Revenue Adjustment
API to automatically perform these adjustments. Revenue 
Accounting uses the Actions Wizard to guide you through the process
of makingand modifying revenue adjustments.
You can also use the wizard to record early acceptance for an 

invoice line, if the line is associated with a contract that offers an 
acceptance clause.
Invoicing Rules:
===============
Use Invoicing Rules to specify whetherto record receivables 
amounts in the first (Bill in Advance) or Last (Bill in Arrear) 
Period. 
Invoicing rules determine when to bill the customer inrelation to
the accounting rule Periods. Accounting rules determine the 

accounting periods for revenue recognition and Billing.
Two invoicing rules are available: 




Bill in Advance: Use this rule to recognize receivables immediately.

Bill in Arrears: Use this rule to recognize the receivable at the end of 

the revenue recognition schedule.


•Invoicing rules determine whether to recognize receivables in the first or in the last accounting period.
•Once the invoice is saved, you cannot update an invoicing rule.
•If Bill in Arrears is the invoicing rule, Oracle Receivables updates the GL Date and invoice date of the invoice to the last accounting period for the accounting rule.
Accounting Rules: 
=================
Use Accounting Rules to determine when to record revenues.
Accounting Rule determine the number of periods and percentage 
of total revenue to record in each accounting period.

Each invoice can have different accounting rule.
Use the Accounting, Fixed Duration type to recognize revenue evenly 
over a specific number of periods. Revenue can be spread evenly or a 
percentage can be specified for each period. 

Variable Duration type to recognize revenue by a percentage for 
the first period. The remaining revenue is spread evenly across 
the number of periods you specify during transaction entry.

Accounting rules determine when to recognize revenue
amounts. Each invoice line can have different accounting rule. 


Oracle Receivables uses the First GL Date field in the Transactions 
window to determine when to start recognizing revenue. The number
of periods in which revenue is recognized is determined by the 
value in the Number of Accounting Periods field in the Transactions
window.Value defaults from fixed ruleValue must be entered for 
variable rule. Accounting distributions are created only after you run
the Revenue Recognition program. 

•Accounting distributions are created only after the Revenue 

Recognition program is run.
•For Bill in Advance, the offset account to accounts receivable 

is Unearned Revenue.
•For Bill in Arrears, the offset account to accounts receivable i

s Unbilled Receivables.
•Accounting distributions are created for all periods when 

Revenue Recognition is run.

Revenue Recognition Program Execution Report :
=======================================
Use the Revenue Recognition Execution report to review all 

revenuedistributions created for invoices that use invoice and 
accounting rules. 

This report displays the account class, GL Date, Accounting 
Flex field, the currency, amount, and accounted amount for 
the revenue distributions Revenue Recognition creates for 
each transaction.

Receivables automatically creates the Revenue Recognition 
Execution report whenever you run the Revenue Recognition
program, the Revenue Recognition Master program, or the 
General Ledger Interfaceprogram.

When the Revenue Recognition program encounters transactions 
with problems that prevent the creation of distributions, the 
program completes with a status of Warning, and Receivables 
includes these transactions at the bottom of this report.

•The Revenue Recognition program gives control over the creation
of accounting entries.
•Submit the Revenue Recognition program manually through the 

Run Revenue Recognition window.
•The Revenue Recognition program will also be submitted when 

posting to Oracle General Ledger.
•The program processes revenue by transaction, rather than by 

accounting period.
•Only new transactions are selected each time the process is run.


References:
https://oracleappsebsyashrajvarsity.blogspot.com/2009/05/vsoe-and-revenue-recognition.html
https://blogs.oracle.com/FinancialsMkting/entry/new_revenue_recognition_rules

Tuesday, October 11, 2016

Multi-Org or Multiple Organization Access (MOAC) in R12

What is MOAC?
Multi-Org or multiple organization access (MOAC) is basically an ability to access multiple operating units from a single application responsibility.

Why it has been created?
Prior to R12, end users use to toggle / switch / change responsibilities in order to do transactions (like invoice / payment processing in AP) in different operating units. This is a very time consuming and inefficient way of recording transactions when you have 100s of operating units specially Internet based organizations who have worldwide operations in almost all the countries. To address this, a new feature in R12 has been introduced in which user can switch between operating units within a responsibility something similar to “Change Organization” feature in inventory. Prior to R12, user would have to switch responsibilities in order to enter transactions in respective operating units (tagged to the responsibility).

What are its advantages?
Multi-Org Access Control (MOAC) enables companies that have implemented a Shared Services operating model to efficiently process business transactions by allowing them to access, process and report on data for an unlimited number of operating units within a single applications responsibility.
This increases the productivity of Shared Service Centers, as users no longer have to switch application responsibilities when processing transactions for multiple operating units at a time.
Ability to view data from multiple operating units from a single responsibility, gives users more information. This enables them to make better decisions.
The following SQL will dump out the Security Profiles and Operating Unit Names assigned to them.

SELECT   psp.SECURITY_PROFILE_NAME,
         psp.SECURITY_PROFILE_ID,
         hou.NAME,
         hou.ORGANIZATION_ID
FROM     PER_SECURITY_PROFILES psp,
         PER_SECURITY_ORGANIZATIONS pso,
         HR_OPERATING_UNITS hou
WHERE    pso.SECURITY_PROFILE_ID = psp.SECURITY_PROFILE_ID
         AND pso.ORGANIZATION_ID = hou.ORGANIZATION_ID;
There are three Profile Options you need to be aware of related to Multi-Org that should be set at the Responsibility Level.
MO: Security Profile- Always evaluated first.
MO: Operating Unit- Secondary priority being evaluated after ‘MO: Security Profile’
MO: Default Operating Unit- Sets the default Operating Unit for transactions when running under a Security Profile.

How it is done in R12?
In Release 12, one creates a Security Profile and assigns as many operating units as you required. One can tie that security profile to a single responsibility using a profile option called MO: Security Profile. For example, you could assign the security profile to the EMEA Payables responsibility to allow that responsibility to process invoices across all operating units.
In Release 12, define a security profile in HR using the Security profile form or the Global Security profile form, and assign all of the operating units that one would want a responsibility to access. The one needs to run a concurrent request called “Run Security List Maintenance” from HR which will make those security profile available and allow one to assign them to a responsibility via a profile option called MO: Security Profile.
One can define another profile option called MO: Default Operating Unit which is optional and allows one to specify a default operating unit that will be the default when you open different subledger application forms.

References:
http://amaralam.blogspot.com/2013/04/what-is-moac-multi-org-or-multiple.html

Friday, September 2, 2016

R12 - Item Category Create/Update/Delete using API's

There are few APIs in INV_ITEM_CATEGORY_PUB package related to item category. This article will follow a category flexfield structure. Please refer the below post for more detail.
 
1. INV_ITEM_CATEGORY_PUB.Create_Category:
DECLARE
l_category_rec    INV_ITEM_CATEGORY_PUB.CATEGORY_REC_TYPE;
l_return_status   VARCHAR2(80);
l_error_code      NUMBER;
l_msg_count       NUMBER;
l_msg_data        VARCHAR2(80);
l_out_category_id NUMBER;
BEGIN
  l_category_rec.segment1 := 'RED';

  SELECT f.ID_FLEX_NUM
    INTO l_category_rec.structure_id
    FROM FND_ID_FLEX_STRUCTURES f
   WHERE f.ID_FLEX_STRUCTURE_CODE = 'INV_COLORS';

  l_category_rec.description := 'Red';

  INV_ITEM_CATEGORY_PUB.Create_Category
          (
          p_api_version   => 1.0,
          p_init_msg_list => FND_API.G_FALSE,
          p_commit        => FND_API.G_TRUE,
          x_return_status => l_return_status,
          x_errorcode     => l_error_code,
          x_msg_count     => l_msg_count,
          x_msg_data      => l_msg_data,
          p_category_rec  => l_category_rec,
          x_category_id   => l_out_category_id
          );
  IF l_return_status = fnd_api.g_ret_sts_success THEN
    COMMIT;
    DBMS_OUTPUT.put_line ('Creation of Item Category is Successful : '||l_out_category_id);
  ELSE
    DBMS_OUTPUT.put_line ('Creation of Item Category Failed with the error :'||l_error_code);
    ROLLBACK;
  END IF;
END ;
 
2. INV_ITEM_CATEGORY_PUB. Delete_Category:
 
DECLARE
l_return_status VARCHAR2(80);
l_error_code    NUMBER;
l_msg_count     NUMBER;
l_msg_data      VARCHAR2(80);
l_category_id   NUMBER;
BEGIN
  SELECT mcb.CATEGORY_ID
    INTO l_category_id
    FROM mtl_categories_b mcb
   WHERE mcb.SEGMENT1='RED'
     AND mcb.STRUCTURE_ID =
        (SELECT mcs_b.STRUCTURE_ID
           FROM mtl_category_sets_b mcs_b
          WHERE mcs_b.CATEGORY_SET_ID =
               (SELECT mcs_tl.CATEGORY_SET_ID
                  FROM mtl_category_sets_tl mcs_tl
                 WHERE CATEGORY_SET_NAME ='INV_COLORS_SET'
                 )
        );

    INV_ITEM_CATEGORY_PUB.Delete_Category
          (
          p_api_version     => 1.0,
          p_init_msg_list   => FND_API.G_FALSE,
          p_commit          => FND_API.G_TRUE,
          x_return_status   => l_return_status,
          x_errorcode       => l_error_code,
          x_msg_count       => l_msg_count,
          x_msg_data        => l_msg_data,
          p_category_id     => l_category_id);

  IF l_return_status = fnd_api.g_ret_sts_success THEN
    COMMIT;
    DBMS_OUTPUT.put_line ('Deletion of Item Category is Successful : '||l_category_id);
  ELSE
    DBMS_OUTPUT.put_line ('Deletion of Item Category Failed with the error :'||l_error_code);
    ROLLBACK;
  END IF;
END ;
 
3. INV_ITEM_CATEGORY_PUB.Update_Category_Description
Updates the category description.
DECLARE
         l_return_status VARCHAR2(80);
         l_error_code    NUMBER;
         l_msg_count     NUMBER;
         l_msg_data      VARCHAR2(80);
         l_category_id   NUMBER;
         l_description   VARCHAR2(80);
BEGIN
      select mcb.CATEGORY_ID into l_category_id
        from mtl_categories_b mcb
       where mcb.SEGMENT1='BLACK'
         and mcb.STRUCTURE_ID = (select mcs_b.STRUCTURE_ID
             from mtl_category_sets_b mcs_b
             where mcs_b.CATEGORY_SET_ID = (select mcs_tl.CATEGORY_SET_ID
                 from mtl_category_sets_tl mcs_tl
                 where CATEGORY_SET_NAME ='INV_COLORS_SET'));

      l_description := 'new black color';

     INV_ITEM_CATEGORY_PUB.Update_Category_Description (
       p_api_version     => 1.0,
       p_init_msg_list   => FND_API.G_FALSE,
       p_commit          => FND_API.G_TRUE,
       x_return_status   => l_return_status,
       x_errorcode       => l_error_code,
       x_msg_count       => l_msg_count,
       x_msg_data        => l_msg_data,
       p_category_id     => l_category_id,
       p_description     => l_description);

  IF l_return_status = fnd_api.g_ret_sts_success THEN
    COMMIT;
    DBMS_OUTPUT.put_line ('Update of Item Category Description is Successful : '||l_category_id);
  ELSE
    DBMS_OUTPUT.put_line ('Update of Item Category Description Failed with the error :'||l_error_code);
    ROLLBACK;
  END IF;
END ;
 
Use following API for assigning a category to a category set. A category will be available in the list of valid categoies for a category set only if it is assigned to the category set. This is a required step if for categories enforce list is checked on.
4. INV_ITEM_CATEGORY_PUB.Create_Valid_Category
Create a record in mtl_category_set_valid_cats.
DECLARE
        l_return_status   VARCHAR2(80);
        l_error_code      NUMBER;
        l_msg_count       NUMBER;
        l_msg_data        VARCHAR2(80);
        l_category_set_id NUMBER;
        l_category_id     NUMBER;
BEGIN
       select mcs_tl.CATEGORY_SET_ID into l_category_set_id
         from mtl_category_sets_tl mcs_tl
        where mcs_tl.CATEGORY_SET_NAME ='INV_COLORS_SET';

       select mcb.CATEGORY_ID into l_category_id
         from mtl_categories_b mcb
        where mcb.SEGMENT1='RED'
          and mcb.STRUCTURE_ID = (select mcs_b.STRUCTURE_ID
              from mtl_category_sets_b mcs_b
              where mcs_b.CATEGORY_SET_ID = (select mcs_tl.CATEGORY_SET_ID
                    from mtl_category_sets_tl mcs_tl
                    where CATEGORY_SET_NAME ='INV_COLORS_SET'));

       INV_ITEM_CATEGORY_PUB.Create_Valid_Category (
             p_api_version        => 1.0,
             p_init_msg_list      => FND_API.G_FALSE,
             p_commit             => FND_API.G_TRUE,
             x_return_status      => l_return_status,
             x_errorcode          => l_error_code,
             x_msg_count          => l_msg_count,
             x_msg_data           => l_msg_data,
             p_category_set_id    => l_category_set_id,
             p_category_id        => l_category_id,
             p_parent_category_id => NULL );

  IF l_return_status = fnd_api.g_ret_sts_success THEN
    COMMIT;
    DBMS_OUTPUT.put_line ('Create Valid Category is Successful : '||l_category_id);
  ELSE
    DBMS_OUTPUT.put_line ('Create Valid Category Failed with the error :'||l_error_code);
    ROLLBACK;
  END IF;
END ;


5. INV_ITEM_CATEGORY_PUB.Delete_Valid_Category
Delete the record from mtl_category_set_valid_cats.
DECLARE
           l_return_status    VARCHAR2(80);
           l_error_code       NUMBER;
           l_msg_count        NUMBER;
           l_msg_data         VARCHAR2(80);
           l_category_set_id  NUMBER;
           l_category_id      NUMBER;
BEGIN
         select mcs_tl.CATEGORY_SET_ID into l_category_set_id
           from mtl_category_sets_tl mcs_tl
          where mcs_tl.CATEGORY_SET_NAME ='INV_COLORS_SET';

         select mcb.CATEGORY_ID into l_category_id
           from mtl_categories_b mcb
          where mcb.SEGMENT1='RED'
            and mcb.STRUCTURE_ID = (select mcs_b.STRUCTURE_ID
                from mtl_category_sets_b mcs_b
                where mcs_b.CATEGORY_SET_ID = (select mcs_tl.CATEGORY_SET_ID
                  from mtl_category_sets_tl mcs_tl
                  where CATEGORY_SET_NAME ='INV_COLORS_SET'));

      INV_ITEM_CATEGORY_PUB.Delete_Valid_Category (
            p_api_version      => 1.0,
            p_init_msg_list    => FND_API.G_FALSE,
            p_commit           => FND_API.G_TRUE,
            x_return_status    => l_return_status,
            x_errorcode        => l_error_code,
            x_msg_count        => l_msg_count,
            x_msg_data         => l_msg_data,
            p_category_set_id  => l_category_set_id,
            p_category_id      => l_category_id);

  IF l_return_status = fnd_api.g_ret_sts_success THEN
    COMMIT;
    DBMS_OUTPUT.put_line ('Delete Valid Category is Successful : '||l_category_id);
  ELSE
    DBMS_OUTPUT.put_line ('Delete Valid Category Failed with the error :'||l_error_code);
    ROLLBACK;
  END IF;
END ;
References:
http://www.oracleerpappsguide.com/2013/09/r12-item-category-create-update-delete-using-api.html

R12 - Ship Confirm using API

Use this script to create a procedure in Database and call the procedure by passing the delivery number as a parameter to ship confirm it.
You can set the options for
1. Back ordering unspecified quantities
2. Closing the delivery automatically by submitting the Trip stop program after ship confirm is successful
SHIP CONFIRMATION THROUGH API

CREATE OR REPLACE PROCEDURE erps_ship_confirm_delivery (
   v_delivery_name      IN     VARCHAR2,                   --  delivery number
   v_action             IN     VARCHAR2, -- Pass 'B' to backorder the unspecified quantity
   p_ship_conf_status      OUT VARCHAR2,
   x_msg_data              OUT VARCHAR2)
IS
   p_api_version_number     NUMBER;

   init_msg_list            VARCHAR2 (30);

   x_msg_count              NUMBER;

   x_msg_details            VARCHAR2 (32000);

   x_msg_summary            VARCHAR2 (32000);

   p_validation_level       NUMBER;

   p_commit                 VARCHAR2 (30);

   x_return_status          VARCHAR2 (15);

   source_code              VARCHAR2 (15);

   changed_attributes       wsh_delivery_details_pub.changedattributetabtype;

   p_action_code            VARCHAR2 (15);

   p_delivery_id            NUMBER;

   p_delivery_name          VARCHAR2 (30);

   p_asg_trip_id            NUMBER;

   p_asg_trip_name          VARCHAR2 (30);

   p_asg_pickup_stop_id     NUMBER;

   p_asg_pickup_loc_id      NUMBER;

   p_asg_pickup_loc_code    VARCHAR2 (30);

   p_asg_pickup_arr_date    DATE;

   p_asg_pickup_dep_date    DATE;

   p_asg_dropoff_stop_id    NUMBER;

   p_asg_dropoff_loc_id     NUMBER;

   p_asg_dropoff_loc_code   VARCHAR2 (30);

   p_asg_dropoff_arr_date   DATE;

   p_asg_dropoff_dep_date   DATE;

   p_sc_action_flag         VARCHAR2 (10);

   p_sc_close_trip_flag     VARCHAR2 (10);

   p_defer_iface            VARCHAR2 (10);

   p_sc_create_bol_flag     VARCHAR2 (10);

   p_sc_stage_del_flag      VARCHAR2 (10);

   p_sc_trip_ship_method    VARCHAR2 (30);

   p_sc_actual_dep_date     VARCHAR2 (30);

   p_sc_report_set_id       NUMBER;

   p_sc_report_set_name     VARCHAR2 (60);

   p_wv_override_flag       VARCHAR2 (10);

   x_trip_id                VARCHAR2 (30);

   x_trip_name              VARCHAR2 (30);

   p_msg_data               VARCHAR2 (32000);

   fail_api                 EXCEPTION;
BEGIN
   x_return_status := wsh_util_core.g_ret_sts_success;

   p_action_code := 'CONFIRM';

   p_delivery_name := v_delivery_name;

   p_sc_action_flag := v_action;

   p_sc_close_trip_flag := 'Y'; -- Trip stop concurrent program will be submitted automatically

   p_defer_iface := 'N';

   wsh_deliveries_pub.
    delivery_action (p_api_version_number        => 1.0,
                     p_init_msg_list             => init_msg_list,
                     x_return_status             => x_return_status,
                     x_msg_count                 => x_msg_count,
                     x_msg_data                  => p_msg_data,
                     p_action_code               => p_action_code,
                     p_delivery_id               => p_delivery_id,
                     p_delivery_name             => p_delivery_name,
                     p_asg_trip_id               => p_asg_trip_id,
                     p_asg_trip_name             => p_asg_trip_name,
                     p_asg_pickup_stop_id        => p_asg_pickup_stop_id,
                     p_asg_pickup_loc_id         => p_asg_pickup_loc_id,
                     p_asg_pickup_loc_code       => p_asg_pickup_loc_code,
                     p_asg_pickup_arr_date       => p_asg_pickup_arr_date,
                     p_asg_pickup_dep_date       => p_asg_pickup_dep_date,
                     p_asg_dropoff_stop_id       => p_asg_dropoff_stop_id,
                     p_asg_dropoff_loc_id        => p_asg_dropoff_loc_id,
                     p_asg_dropoff_loc_code      => p_asg_dropoff_loc_code,
                     p_asg_dropoff_arr_date      => p_asg_dropoff_arr_date,
                     p_asg_dropoff_dep_date      => p_asg_dropoff_dep_date,
                     p_sc_action_flag            => p_sc_action_flag,
                     p_sc_close_trip_flag        => p_sc_close_trip_flag,
                     p_sc_create_bol_flag        => p_sc_create_bol_flag,
                     p_sc_stage_del_flag         => p_sc_stage_del_flag,
                     p_sc_trip_ship_method       => p_sc_trip_ship_method,
                     p_sc_actual_dep_date        => p_sc_actual_dep_date,
                     p_sc_report_set_id          => p_sc_report_set_id,
                     p_sc_report_set_name        => p_sc_report_set_name,
                     p_sc_defer_interface_flag   => p_defer_iface,
                     p_wv_override_flag          => p_wv_override_flag,
                     x_trip_id                   => x_trip_id,
                     x_trip_name                 => x_trip_name);

   IF (x_return_status != wsh_util_core.g_ret_sts_success)
   THEN
      wsh_util_core.get_messages ('Y',
                                  x_msg_summary,
                                  x_msg_details,
                                  x_msg_count);

      IF x_msg_count > 1
      THEN
         x_msg_data := x_msg_summary || x_msg_details;
      ELSE
         x_msg_data := x_msg_summary;
      END IF;

      p_ship_conf_status := 'E';
   ELSE
      p_ship_conf_status := 'S';
   END IF;

END erps_ship_confirm_delivery;

SHIP CONFIRMATION THROUGH FORMS
Navigate to Shipping responsibility >> Shipping >> Transactions
Query the delivery that need to be ship confirmed
click ship confirm button.
Refernces:
http://www.oracleerpappsguide.com/2013/09/r12-ship-confirm-using-api.html