Efficient and User Friendly Concurrent Request Form


Make Concurrent Request Form more Efficient.


 

The Concurrent Request form is possibly the most used form in Oracle E Business Suite and probably the most unpleasant one. Throughout my implementations every business user (from a clerk to C Level managers) gives a black look when the report submission process is presented.

In order to enhance user experience and to reduce multiple steps we have developed and deployed following enhancements to the Concurrent Request Form.

 

CRF

 

 

 

Enhancement

Steps Reduced/eliminated

  1. Auto Refresh functionality tops the list of the enhancement.

When the check box is selected the form/data is Refreshed after specified timer (2 seconds is suggested). The user deselect the check box as and when required.

Reduces 8 to 9 Clicks or [Alt + r] on each request.

Approximately 400+ unnecessary clicks per day.

  1. Rerun Selected Request

uses the cursor placement and rerun the request with same parameters, new request id and refreshes the form

Reduces/Skips 8 Clicks and 5 Form Navigations on each run

Submit a new Request>>Single Request>>Copy>>Select Prior Request>>Submit>>Submit another Request(NO)>>Refresh Data

  1. Copy Request

although this functionality currently exists but if this is made available on the concurrent request form it eliminates few unnecessary steps. When used it takes user directly recent ran request LOV for selection

Reduces/Skips 4 Clicks and 3 Form Navigations on each run

Submit a new Request>>Single Request>>Copy>>Select Prior Request

  1. Submit a New Request and Submit a New Request Set Buttons

Most of the Users use Single Request Submission, they rarely use Request Sets. Therefore users suggested having separate buttons for both of them.

If user Clicks on “Submit a New Request” Button it will directly open the new request form.

Reduces/Skips 2 Clicks and 1 forms on each run

Submit a new Request>>Single Request

Mutli-Currency Receipts for landed cost invoices

We are implementing Landed Cost Management Module (LCM) at one of our client in Kingdom of Saudi Arabia. Now Landed Cost Management is recently released and still pre-mature although it is very useful and effective addition to Oracle EBS but it lacks one of the basic requirements.

I don’t know why Oracle Development didn’t catered this first hand. I am sure around the world whenever anything is Imported landed cost invoice is always different than PO currency.

PO is always raised in Foreign currency and Landed cost (Freight, Insurance, Duty, and local transport) in local currency.

In our case PO is raised in USD, EURO, JPY and landed cost invoices are always in SAR and while matching the landed cost invoices to the item receipt, it does not shows that receipt.

Now as per Oracle this is the intended functionality. PO currency and Invoice Currency Should be same.
This is a enhancement request and under development review.

Well we all know client doesn’t cares about Oracle Enhancement request and Developement review. This is a logical requirement and a basic one also.

Here on this project we are going with customization and recommend the same till oracle releases and standard functionality.

(Be advised this should be tested thoroughly before migrating it to your live environment)

  • Customize ‘Find Receipts for Matching’ Payables form ($AU_TOP/forms/US/ APXRMTCH.fmb) using following steps :
    • Comment out or remove following code fromOTHR_CHRG_MATCH_EVENT.CONSTRUCT_WHERE_CLAUSE program unit==
      — and this clause by default
      app_query.append (‘OTHR_CHRG_MATCH’,
      ‘CURRENCY_CODE = :INVOICE.INV_CURR_CODE’);
      ==
    • Replace ‘poh.currency_code = :invoice.inv_curr_code’ with ‘((:match_qf.match_type = ‘ITEM’ AND poh.currency_code = :invoice.inv_curr_code) OR (:match_qf.match_type <> ‘ITEM’))’ in PO_NUMBER record group
    • Replace ‘RTXN.currency_code = :invoice.inv_curr_code’ with ‘((:match_qf.match_type = ‘ITEM’ AND RTXN.currency_code = :invoice.inv_curr_code) OR (:match_qf.match_type <> ‘ITEM’))’ in RECEIPT_NUMBER record group (at 4 places)
  • Save the changes and Compile the form to generate APXRMTCH.fmx.
  • Go to $AP_TOP/forms/US and take a backup of APXRMTCH.fmx (i.e copy APXRMTCH.fmx to APXRMTCH.fmx.bak)
  • Copy APXRMTCH.fmx (from step b) to $AP_TOP/forms/US

Wollaaa!!

Do share your feedback.

Solution for Bug 13412084: RESTRICT PAYMENT: IT SHOULD NOT ALLOW PAYMENT BEFORE INVOICE ACCRUAL

We had this issue @ our client where user accidentally  made payment on 21-Jan-11 instead of 21-Jan-12. These kind of mistakes are very frequent. The only Solution you have is to Void that payment and recreate a new one. But the problem doesnt ends there. To clear that you have to open that particular period. Transfer the accounting of payment and reversal and create a new payment.

This practise annoys the data entry user the payable key user and the General Ledger owner because they have to do that same practise all over again.

I Don’t know why we don’t have any profile option to control this. I have already raised an ER for this which might take a couple of more years. As we all know it will might come in future releases. (Please add your vote for this ER by raising an SR)

The only option we were left with was to create a custom.pll and use that. Below you have the step by step procedure to achieve this goal.

(courtesy of Mr Abid Hussain).

1)      Open terminal.

2)    Issue command Xhost + , this command will enable you to make your connection to the server from any host.

3)    Connect to the user by issuing command su – appltest (In case of Al-Abbas clone instance)

4)      cd /u02/test/apps/apps_st/appl/au/12.0.0/resource (Path where custom.pll reside check it at your instance).

5)      frmbld

6)      Select library Custom.pll (you will have to select manually)

7)      Include Library APPCORE2

8)      Now open the Package body of Custom.pll

9)      Now add the fallowing code in procedure “Event”

10)   Form_Name Varchar2(30)  := name_in(‘system.current_form’);

Block_Name Varchar2(30) := name_in(‘system.cursor_block’);

L_Gl_Date_scs Date;

L_invoice_id_scs Number;

11)  Now add the fallowing code in Begin.

If form_name = ‘APXPAWKB’ Then

If event_name = ‘WHEN-VALIDATE-RECORD’ Then

If block_name = ‘ADJ_INV_PAY’ Then

L_invoice_id_scs := name_in(‘ADJ_INV_PAY.INVOICE_ID’);

Select Gl_Date Into L_Gl_Date_scs From ap_invoices_all

Where Invoice_id = L_invoice_id_scs;

If name_in(‘PAY_SUM_FOLDER.CHECK_DATE’) <  L_Gl_Date_scs Then

fnd_message.set_string(‘Payment Date Should Not less Then Invoice GL Date’);

fnd_message.show( );

Raise Form_Trigger_Failure;

End If;

Else

Null;

End If;

Else

Null;

End If;

Else

Null;

End If;

Now you can call this custom.pll in personalization on Payment Workbench Form.

Cheers!!