Scalability Options for XML Publisher Reports - Data Template case

hi All,

The following post is actually a nice solution I found on the web for the issue we were having with several XML publisher reports: Data Template concurrent programs were failing with errors like even before the OPP run:

****Warning!!! Due to high volume of data, got out of memory exception…*** 
****Please retry with scalable option or modify the Data template to run in scalable mode…***

Any changes that were done to the scalability property of the Data Template:

<properties>
    <property name="scalable_mode" value="on"/>
</properties>

 had no effect what so ever...

I saw several solutions for this issue - the only one that did the trick on R12 is as follows:

From System Administrator/Application Developer navigate to Concurrent Program definitions and insert the following string into the Option field: -Xss2048k -Xmx512m

This command allocates additional memory to the Java heap used by Data Template Run.

Link to the original post

Previous solution works well even on 11i, but in both cases, you are restricted by an amount of physical memory you could spend and in case you are creating BIG XML file program still crashes.

Another neat trick that I came across (it was successfully implemented in 11i for VERY big XML) is adding a Scalable Flag as one of the concurrent programs' parameters.

Directions are as follows:

•  Locate relevant Data Template concurrent program. 

At System Administrator/Application Developer responsibility access to Concurrent>Program>Define

•  After the last parameter add a new one named P_SCALABLE_FLAG. 

Description: ScalableFlag  
Prompt: P_SCALABLE_FLAG
Value Set: XLA_SRS_NO_VALIDATION
Default Type: Constant
Default Value: Y

Token: ScalableFlag - do not change the name of the token.

If you have default PL/SQL package defined for Data Template, make sure to declare P_SCALABLE_FLAG as a global type in package specifications.

enjoy,

Felix

Split Sales Order lines by using OE_ORDER_PUB API

hi All,
Been "meddling" with Order Management APIs on R12 lately a lot. I was tasked to create split of SO line that already has reservations assigned to it:
Consider following example:
One SO line with Qty of 10 has one Delivery Detail line with Qty of 10. Next thing, I am making reservation (with API) of two different Lots 5 and 5 for that lines' Item Qty - so far so good.
Now is where it gets tricky: these Lots has different Grades:  "A" & "B"
Logically, SO line has to be divided in two lines per Lot  for re-pricing purposes ( grade B costs less then A).

Unfortunately, OE_ORDER_PUB.Process_order() we are using for split, destroys the Reservation done for that line...
the only solution I was able to come up with to this issue is redundant custom table that helps me out to re-create the Lots reservations once split is completed.

Well, this is not the topic of this post but OE_ORDER_PUB.
There are several examples on the web for API call - mine works :-)

 declare
     l_header_rec                 oe_order_pub.header_rec_type;
     l_line_tbl                   oe_order_pub.line_tbl_type;     
     l_action_request_tbl         oe_order_pub.request_tbl_type;
     l_return_status              VARCHAR2(1000);
     l_msg_count                  NUMBER;
     l_msg_data                   VARCHAR2(1000);
     p_api_version_number         NUMBER := 1.0;
     p_init_msg_list              VARCHAR2(10) := fnd_api.g_false;
     p_return_values              VARCHAR2(10) := fnd_api.g_false;
     p_action_commit              VARCHAR2(10) := fnd_api.g_false;
     x_header_rec                 oe_order_pub.header_rec_type := oe_order_pub.g_miss_header_rec;
     x_line_tbl                   oe_order_pub.line_tbl_type := oe_order_pub.g_miss_line_tbl;
     x_header_val_rec             oe_order_pub.header_val_rec_type;
     x_header_adj_tbl             oe_order_pub.header_adj_tbl_type;
     x_header_adj_val_tbl         oe_order_pub.header_adj_val_tbl_type;
     x_header_price_att_tbl       oe_order_pub.header_price_att_tbl_type;
     x_header_adj_att_tbl         oe_order_pub.header_adj_att_tbl_type;
     x_header_adj_assoc_tbl       oe_order_pub.header_adj_assoc_tbl_type;
     x_header_scredit_tbl         oe_order_pub.header_scredit_tbl_type;
     x_header_scredit_val_tbl     oe_order_pub.header_scredit_val_tbl_type;
     x_line_val_tbl               oe_order_pub.line_val_tbl_type;
     x_line_adj_tbl               oe_order_pub.line_adj_tbl_type;
     x_line_adj_val_tbl           oe_order_pub.line_adj_val_tbl_type;
     x_line_price_att_tbl         oe_order_pub.line_price_att_tbl_type;
     x_line_adj_att_tbl           oe_order_pub.line_adj_att_tbl_type;
     x_line_adj_assoc_tbl         oe_order_pub.line_adj_assoc_tbl_type;
     x_line_scredit_tbl           oe_order_pub.line_scredit_tbl_type;
     x_line_scredit_val_tbl       oe_order_pub.line_scredit_val_tbl_type;
     x_lot_serial_tbl             oe_order_pub.lot_serial_tbl_type;
     x_lot_serial_val_tbl         oe_order_pub.lot_serial_val_tbl_type;
     x_action_request_tbl         oe_order_pub.request_tbl_type;
     l_line_tbl_index             NUMBER;
  begin
     p_message := '';
     dbms_output.ENABLE(1000000);
     oe_msg_pub.initialize;
     oe_debug_pub.initialize;
     mo_global.init('ONT'); -- Required for R12
     mo_global.set_org_context(fnd_global.ORG_ID, NULL, 'ONT');
     fnd_global.set_nls_context('AMERICAN');
     mo_global.set_policy_context('S', fnd_global.ORG_ID);

     --This is to UPDATE order line
     l_line_tbl_index := 1;
     -- Changed attributes
     l_header_rec := OE_ORDER_PUB.G_MISS_HEADER_REC;
     l_header_rec.header_id := p_header_id; -- header_id of the order
     l_header_rec.operation := OE_GLOBALS.G_OPR_UPDATE;
     l_line_tbl(l_line_tbl_index) := OE_ORDER_PUB.G_MISS_LINE_REC;
     l_line_tbl(l_line_tbl_index).operation := OE_GLOBALS.G_OPR_UPDATE;
     l_line_tbl(l_line_tbl_index).split_by := fnd_global.USER_ID; -- user_id
     l_line_tbl(l_line_tbl_index).split_action_code := 'SPLIT';
     l_line_tbl(l_line_tbl_index).header_id := p_header_id; -- header_id of the order
     l_line_tbl(l_line_tbl_index).line_id := p_order_line_id; -- line_id of the order line
     l_line_tbl(l_line_tbl_index).ordered_quantity := (p_so_line_qty - p_qty_to_split); -- new ordered quantity
     l_line_tbl(l_line_tbl_index).preferred_grade := p_lot_grade;
     l_line_tbl(l_line_tbl_index).change_reason := 'MISC'; -- change reason code
     l_line_tbl_index := 2;
     l_line_tbl(l_line_tbl_index) := OE_ORDER_PUB.G_MISS_LINE_REC;
     l_line_tbl(l_line_tbl_index).operation := OE_GLOBALS.G_OPR_CREATE;
     l_line_tbl(l_line_tbl_index).split_by := fnd_global.USER_ID; -- user_id
     l_line_tbl(l_line_tbl_index).split_action_code := 'SPLIT';
     l_line_tbl(l_line_tbl_index).header_id := p_header_id;
     l_line_tbl(l_line_tbl_index).split_from_line_id := p_order_line_id; -- line_id of  original line
     l_line_tbl(l_line_tbl_index).inventory_item_id := p_inventory_item_id; -- inventory item id
     l_line_tbl(l_line_tbl_index).ordered_quantity := p_qty_to_split; -- ordered quantity   
     fnd_file.PUT_LINE(fnd_file.log,'    Split_Qty_from_Line() for: '||p_order_line_id); 
     fnd_file.PUT_LINE(fnd_file.log,'    Calling the API to split: '||l_line_tbl(2).ordered_quantity); 
     FND_MSG_PUB.INITIALIZE; 
     oe_order_pub.Process_order (  p_api_version_number   => 1.0                 ,
                                   p_init_msg_list        => fnd_api.g_true     ,
                                   p_return_values        => fnd_api.g_false     ,
                                   p_action_commit        => fnd_api.g_true     ,
                                   x_return_status        => l_return_status     ,
                                   x_msg_count            => l_msg_count         ,
                                   x_msg_data             => l_msg_data          ,
                                   p_header_rec           => l_header_rec        ,
                                   p_line_tbl             => l_line_tbl          ,
                                   p_action_request_tbl   => l_action_request_tbl
                                   -- OUT PARAMETERS  
                                   , x_header_rec             => x_header_rec
                                   , x_header_val_rec         => x_header_val_rec
                                   , x_header_adj_tbl         => x_header_adj_tbl
                                   , x_header_adj_val_tbl     => x_header_adj_val_tbl
                                   , x_header_price_att_tbl   => x_header_price_att_tbl
                                   , x_header_adj_att_tbl     => x_header_adj_att_tbl
                                   , x_header_adj_assoc_tbl   => x_header_adj_assoc_tbl
                                   , x_header_scredit_tbl     => x_header_scredit_tbl
                                   , x_header_scredit_val_tbl => x_header_scredit_val_tbl
                                   , x_line_tbl               => x_line_tbl
                                   , x_line_val_tbl           => x_line_val_tbl
                                   , x_line_adj_tbl           => x_line_adj_tbl
                                   , x_line_adj_val_tbl       => x_line_adj_val_tbl
                                   , x_line_price_att_tbl     => x_line_price_att_tbl
                                   , x_line_adj_att_tbl       => x_line_adj_att_tbl
                                   , x_line_adj_assoc_tbl     => x_line_adj_assoc_tbl
                                   , x_line_scredit_tbl       => x_line_scredit_tbl
                                   , x_line_scredit_val_tbl   => x_line_scredit_val_tbl
                                   , x_lot_serial_tbl         => x_lot_serial_tbl
                                   , x_lot_serial_val_tbl     => x_lot_serial_val_tbl
                                   , x_action_request_tbl     => x_action_request_tbl
                                );
     fnd_file.PUT_LINE(fnd_file.log,'    done with status: '||l_return_status);    
     if l_return_status = fnd_api.G_RET_STS_SUCCESS then
        commit;
        fnd_file.PUT_LINE(fnd_file.log,'    Line Split successfull');
        --l_new_so_line_id := x_line_tbl(2).line_id;
     else
        if l_msg_count > 0 then
           for i in 1 .. l_msg_count loop
    --fnd_file.put_line (fnd_file.log,  fnd_msg_pub.get (i, 'f') );
              fnd_file.PUT_LINE(fnd_file.log,'    ERROR'||fnd_msg_pub.get (i, fnd_api.G_FALSE));
              p_message := p_message ||' ERROR'||fnd_msg_pub.get (i, fnd_api.G_FALSE);
           end loop;
        end if;
        return;
     end if;
     fnd_file.PUT_LINE(fnd_file.log,'    Original Line Id: ' ||x_line_tbl(1).line_id);
     fnd_file.PUT_LINE(fnd_file.log,'    Splitted Line Id: ' ||x_line_tbl(2).line_id);
 end;

Once API run completes two lines created - first the "original" line is going to hold "B" grade lot splited from total "A" qty. API created Delivery Detail Split as well, BUT: grades in Delivery Details Lines have to be updated manually by using WSH_DELIVERY_DETAILS_PUB.update_shipping_attributes():

 declare
     l_changed_attributes wsh_delivery_details_pub.changedattributetabtype;
     l_source_code                varchar2(30) := 'OE';
     l_return_status              VARCHAR2(1000);
     l_msg_count                  NUMBER;
     l_msg_data                   VARCHAR2(1000);
  begin
     dbms_output.ENABLE(1000000);
     oe_msg_pub.initialize;
     oe_debug_pub.initialize;
     mo_global.init('ONT'); -- Required for R12
     mo_global.set_org_context(fnd_global.ORG_ID, NULL, 'ONT');
     fnd_global.set_nls_context('AMERICAN');
     mo_global.set_policy_context('S', fnd_global.ORG_ID);
     
     l_return_status  :='';
     l_msg_count      := 0;
     l_msg_data       := '';
     fnd_file.PUT_LINE(fnd_file.log,'         Calling WSH_DELIVERY_DETAILS_PUB API to Update Grade');
     l_changed_attributes (1).delivery_detail_id := p_delivery_detail_id;
     l_changed_attributes (1).preferred_grade := p_lot_grade;
     FND_MSG_PUB.INITIALIZE; 
     wsh_delivery_details_pub.update_shipping_attributes(
                        p_api_version_number => 1.0,
                        p_init_msg_list => fnd_api.g_true,
                        p_commit => p_action_commit,
                        x_return_status => l_return_status,
                        x_msg_count => l_msg_count,
                        x_msg_data => l_msg_data,
                        p_changed_attributes => l_changed_attributes,
                        p_source_code => l_source_code);     
     if (l_return_status <> wsh_util_core.g_ret_sts_success)   then
        fnd_file.PUT_LINE(fnd_file.log,'         Failed to Update WSH_DELIVERY_DETAIL for: '||p_delivery_detail_id);
        if l_msg_count > 0 then
           for i in 1 .. l_msg_count loop
              fnd_file.PUT_LINE(fnd_file.log,'         ERROR'||fnd_msg_pub.get (i, fnd_api.G_FALSE));
              p_message := p_message ||' ERROR '||fnd_msg_pub.get (i, fnd_api.G_FALSE);
           end loop;
        end if;
        return;
     else
        fnd_file.PUT_LINE(fnd_file.log,'         Successfully Updated Grade in WSH_DELIVERY_DETAIL for: '||p_delivery_detail_id);
        commit;

    end;

enjoy,


Felix

Reservations Processing in R12.1.3 from OAF by using INV_RESERVATION_PUB API

hi All,

Lately I been tasked by our client to develop OAF page to manage Inventory Reservations from Delivery Details screen. Delivery Detail Id is passed as parameter to all regions displayed one OAF page.

I made a simple Form Personalization to have the custom page opened from Action Menu:

The only thing worth mentioning regarding the personalization is the syntax for Form Function submit:

















Following OAF form displays various unique information to support reservations processing that is relevant only for this particular client:

Back to our topic: by manipulating values in Qty column on any line at Lots Available for Reservation table user would be able to Create, Update or Delete reservations of the corresponding Lot for Delivery Detail Line passed to this page as a parameter.

I decided to make this post for two reasons:

First: Most of the similar post tend to mention only Reservation creation from Inventory source and rarely from Order Management.

Second: It took me a while to have a CORRECT minimum number of  the parameters in place to them running successfully. (none of the posts I encountered had it right!) 

Bellow are the short scripts for every one of the main operations from INV_RESERVATION_PUB API.

* make sure to provide mtl_sales_orders.sales_order_id as demand_source_header_id to "glue" the reservation to corresponding Sales Order:

select mso.sales_order_id 

into l_order_header_id       

from mtl_sales_orders mso

     ,oe_order_headers_all ooha

     ,oe_transaction_types_tl ttl

where ooha.order_number      = <corresponding sales order number>

and   mso.segment1           = ooha.order_number

and   mso.segment2           = ttl.name

and   ttl.language           = 'US'

and   ooha.order_type_id     = ttl.transaction_type_id;     

1. CREATE_RESERVATION

DECLARE

   p_rsv                     inv_reservation_global.mtl_reservation_rec_type;

   p_dummy_sn                inv_reservation_global.serial_number_tbl_type;

   x_msg_count               NUMBER;

   x_msg_data                VARCHAR2(240);

   x_rsv_id                  NUMBER;

   x_dummy_sn                inv_reservation_global.serial_number_tbl_type;

   x_status                  VARCHAR2(1);

   x_qty                     NUMBER;

BEGIN

   fnd_global.apps_initialize(2116,50641,660);

   p_rsv.requirement_date            := Sysdate;

   p_rsv.organization_id             := 101; --mtl_parameters.organization id

   p_rsv.inventory_item_id           := 258;--mtl_system_items.Inventory_item_id;

   p_rsv.demand_source_type_id       := inv_reservation_global.g_source_type_oe; -- which is 2

   p_rsv.demand_source_name          := NULL;

   p_rsv.demand_source_header_id     := l_order_header_id;--1334166 ; --mtl_sales_orders.sales_order_id

   p_rsv.demand_source_line_id       := 48067;--4912468 ; -- oe_order_lines.line_id

   p_rsv.primary_uom_code            := 'SLB';

   p_rsv.primary_uom_id              := NULL;

   p_rsv.reservation_uom_code        := 'SLB';

   p_rsv.reservation_uom_id          := NULL;

   p_rsv.reservation_quantity        := 1;

   p_rsv.primary_reservation_quantity := 1;

   p_rsv.lot_number                  := '1187341A';--p_lot_number;

   p_rsv.locator_id                  :=   null;

   p_rsv.supply_source_type_id       := inv_reservation_global.g_source_type_inv;

   p_rsv.ship_ready_flag             := NULL;

   p_rsv.primary_uom_id              := NULL;

   p_rsv.reservation_uom_id          := NULL;

   p_rsv.subinventory_code           :=  '102';

   p_rsv.subinventory_id             :=  NULL;

   p_rsv.attribute15                 :=   NULL ;

   p_rsv.attribute14                 :=   NULL ;       

   p_rsv.attribute13                 :=   NULL ;

   p_rsv.attribute12                 :=   NULL ;

   p_rsv.attribute11                 :=   NULL ; 

   p_rsv.attribute10                 :=   NULL ;

   p_rsv.attribute9                  :=   NULL ;     

   p_rsv.attribute8                  :=   NULL ; 

   p_rsv.attribute7                  :=   NULL ;

   p_rsv.attribute6                  :=   NULL ; 

   p_rsv.attribute5                  :=   NULL ;      

   p_rsv.attribute4                  :=   NULL ;  

   p_rsv.attribute3                  :=   NULL ;

   p_rsv.attribute2                  :=   NULL ;  

   p_rsv.attribute1                  :=   NULL ;  

   p_rsv.attribute_category          :=   NULL ;

   p_rsv.lpn_id                      :=   NULL ;

   p_rsv.pick_slip_number            :=   NULL ;

   p_rsv.lot_number_id               :=   NULL ;

   p_rsv.revision                    :=   NULL ;

   p_rsv.external_source_line_id     :=   NULL ;     

   p_rsv.external_source_code        :=   NULL ;     

   p_rsv.autodetail_group_id         :=   NULL ;    

   p_rsv.reservation_uom_id          :=   NULL ;    

   p_rsv.primary_uom_id              :=   NULL ;   

   p_rsv.demand_source_delivery      :=   NULL ;

   p_rsv.supply_source_line_detail   :=   NULL;

   p_rsv.supply_source_name          :=   NULL;

   p_rsv.supply_source_header_id     :=   NULL; 

   p_rsv.supply_source_line_id       :=   NULL;   

     

   inv_reservation_pub.create_reservation

   (

        p_api_version_number       =>       1.0

      , x_return_status            =>       x_status

      , x_msg_count                =>       x_msg_count

      , x_msg_data                 =>       x_msg_data

      , p_rsv_rec                  =>       p_rsv

      , p_serial_number            =>       p_dummy_sn

      , x_serial_number            =>       x_dummy_sn

      , x_quantity_reserved        =>       x_qty

      , x_reservation_id           =>       x_rsv_id

      

   );

   dbms_output.put_line('Return status    = '||x_status);

   dbms_output.put_line('msg count        = '||to_char(x_msg_count));

   dbms_output.put_line('msg data         = '||x_msg_data);

   dbms_output.put_line('Quantity reserved = '||to_char(x_qty));

   dbms_output.put_line('Reservation id   = '||to_char(x_rsv_id));

   IF x_msg_count >=1 THEN

     FOR I IN 1..x_msg_count

     LOOP

       dbms_output.put_line(I||'. '||SUBSTR(FND_MSG_PUB.Get(p_encoded => FND_API.G_FALSE ),1, 255));

       fnd_file.put_line(fnd_file.log,I||'. '||SUBSTR(FND_MSG_PUB.Get(p_encoded => FND_API.G_FALSE ),1, 255));

     END LOOP;

     

   END IF;

COMMIT;

END;

/

2. UPDATE_RESERVATION

DECLARE

     l_rsv_old   inv_reservation_global.mtl_reservation_rec_type;

     l_rsv_new   inv_reservation_global.mtl_reservation_rec_type;

      l_msg_count NUMBER;

      l_msg_data  VARCHAR2(240);

      l_rsv_id    NUMBER;

     l_dummy_sn  inv_reservation_global.serial_number_tbl_type;

     l_status    VARCHAR2(1);

      l_quantity_reserved NUMBER;

   BEGIN

      fnd_global.apps_initialize(2116,50641,660);

 -- could be "located" by order_header_id, order_line_id, item and warehouse - in that case several reservations could be updated

      l_rsv_old.reservation_id               := 69956;

      -- specify the new values

      l_rsv_new.reservation_id               := 69956;

      l_rsv_new.primary_reservation_quantity := 10;

      l_rsv_new.requirement_date             := Sysdate+2;

      

      inv_reservation_pub.update_reservation(      

          p_api_version_number        => 1.0

         , p_init_msg_lst              => fnd_api.g_true

         , x_return_status             => l_status

         , x_msg_count                 => l_msg_count

         , x_msg_data                  => l_msg_data

         , p_original_rsv_rec          => l_rsv_old

         , p_to_rsv_rec                => l_rsv_new

         , p_original_serial_number    => l_dummy_sn -- no serial contorl

         , p_to_serial_number         => l_dummy_sn -- no serial control

         , p_validation_flag           => fnd_api.g_true

         , p_check_availability        => fnd_api.g_false

         , p_over_reservation_flag     => 0

         );

      IF l_status = fnd_api.g_ret_sts_success THEN

         dbms_output.put_line('reservation updated');

     ELSE

        IF l_msg_count >=1 THEN

           FOR I IN 1..l_msg_count    LOOP

             dbms_output.put_line(I||'. '||SUBSTR(FND_MSG_PUB.Get(p_encoded => FND_API.G_FALSE ),1, 255));

             --fnd_file.put_line(fnd_file.log,I||'. '||SUBSTR(FND_MSG_PUB.Get(p_encoded => FND_API.G_FALSE ),1, 255));

           END LOOP; 

        END IF;

     END IF;

COMMIT;

END;

/

3. DELETE_RESERVATION (decided not to use relieve_reservation since secondary quantity is not used )

DECLARE

      l_rsv       inv_reservation_global.mtl_reservation_rec_type;

      l_msg_count NUMBER;

      l_msg_data  VARCHAR2(240);

      l_rsv_id    NUMBER;

      l_dummy_sn  inv_reservation_global.serial_number_tbl_type;

      l_status    VARCHAR2(1);

BEGIN

      fnd_global.apps_initialize(2116,50641,660);

      l_rsv.reservation_id               := 95377;

      /*l_rsv.organization_id            := 101;

      l_rsv.inventory_item_id            := 258;

      l_rsv.demand_source_type_id        := inv_reservation_global.g_source_type_oe; -- order entry

      l_rsv.demand_source_header_id      := 76069; --oe_order_headers.header_id

      l_rsv.demand_source_line_id        := 48067; --oe_order_lines.line_id

      l_rsv.supply_source_type_id        := inv_reservation_global.g_source_type_inv;

      l_rsv.subinventory_code            := '102';*/

     inv_reservation_pub.delete_reservation

       (

          p_api_version_number        => 1.0

         , p_init_msg_lst              => fnd_api.g_true

         , x_return_status             => l_status

         , x_msg_count                 => l_msg_count

         , x_msg_data                  => l_msg_data

         , p_rsv_rec                   => l_rsv

         , p_serial_number => l_dummy_sn

         );

     IF l_status = fnd_api.g_ret_sts_success THEN

         dbms_output.put_line('reservation deleted');

     ELSE

        IF l_msg_count >=1 THEN

           FOR I IN 1..l_msg_count    LOOP

             dbms_output.put_line(I||'. '||SUBSTR(FND_MSG_PUB.Get(p_encoded => FND_API.G_FALSE ),1, 255));

             --fnd_file.put_line(fnd_file.log,I||'. '||SUBSTR(FND_MSG_PUB.Get(p_encoded => FND_API.G_FALSE ),1, 255));

           END LOOP; 

        END IF;

     END IF;

     COMMIT;

END;

/

enjoy,
Felix

Failing to Submit Custom Programs in Oracle

hi,
Following the solution for the issue we been bumping in every new environment we create lately:
every single Concurrent Program created under Custom Application (XX...something) been failing to submit:

Oracle actually has a detailed solution for this issue, so I decided to re-post for all the unfortunate souls that does not have an access for Metalink:

Add the custom application to a data group.

1.  Under the System Administrator responsibility navigate to 

Security -->Oracle --> DataGroup.

2.  Query up a data group (Standard Data Group is appropriate).

3.  A list of applications associated with the standard data group will appear.

4.  Click on FILE in the toolbar menu then click on NEW.

5.  In the Application column select the custom application from the LOV.

6.  Add an Oracle ID to the ORACLE ID column (APPS is appropriate)

7.  Save the changes.

8.  Resubmit the concurrent request.

enjoy

How to set Default Output Type for Reports Submitted Using XML Publisher

hi All,

Its been a while since I had any new posts. Be assured its not due the lack of the issues ;-)

Today I want to address an issue that "hit close to home" and it remains a complete mystery how we even found our self with such a problem.

Lately I been heavily involved in Oracle EBS 11i upgrade to R12 project as Development, Integration and Deployment Lead. For User Acceptance Test phase we migrated all the custom developments to the freshly cloned EBS R12 environment (all data, setups, patches etc done as well) . Several of the customization developed for the client are custom XML Publisher reports.
The most important thing to mention about those reports - most of  them are developed using Data Template methodology and have XML Publisher Template for layout. MS Word RTF file attached to each template and its Preview Format is set to PDF (see bellow):

According to Oracle Note: 401328.1 output type for XML Publisher reports is defaulted to PDF.
However, to my great surprise, when we tried to run those reports, inside the output options of corresponding concurrent request we saw the default output format changed to RTF?!?

So basically every time users were trying to run one of the reports he (she) was prompted to open/save the RTF file.

Till now its a mystery how default format of 'PDF' was changed of 'RTF'.
After extensive search of how to get back on track, cause user won't change format manually for every request submitted, I came upon Note: 888972.1.

Generally, it explains how Patch 5612820 and Patch 7627832 provides you with solutions to setting and updating default Output Formats for XML Publisher Template.
Most relevant info in our case is profile option: FND: Default Template Output Type could be set to override the original format type.

Once the profile is set to PDF, default Output Format in concurrent request form is PDF as well and outputs are being viewed correctly by the browser.