, , , , ,

How to delete a DFF Context

Sometime I’m quite annoyed by the typo mistake when creating a DFF context. The DFF segment screen doesn’t allow deletion of context. Fortunately, Oracle has internal API to do such thing. Following is a sample.
–*******************************************
–* Delete a descriptive flexfield
–*******************************************
SET ECHO OFF
SET FEEDBACK OFF
SET SERVEROUTPUT ON SIZE 1000000
DECLARE
l_application_id                NUMBER := 0;
l_descriptive_flexfield_name    VARCHAR2(100) :=  ‘FND_COMMON_LOOKUPS’ ;
l_descriptive_flex_context_cod  VARCHAR2(100) :=  ‘XFND_CLWW_PURGE_FOLDER’;
BEGIN
–FND_DESCRIPTIVE_FLEXS_PKG –this package is for DFF
–FND_DESCR_FLEX_CONTEXTS_PKG –this package is for DFF Context
–FND_DESCR_FLEX_COL_USAGE_PKG –this package is for DFF Column useage
–When creating a new DFF Context, it will check the DFF Column usage if the context is already used.
–so when deleting a DFF Context, both the context and column usage should be deleted.
FOR c IN (SELECT application_column_name
FROM fnd_descr_flex_column_usages
WHERE application_id = l_application_id
AND descriptive_flexfield_name = l_descriptive_flexfield_name
AND descriptive_flex_context_code = l_descriptive_flex_context_cod)
LOOP

fnd_descr_flex_col_usage_pkg.delete_row(
x_application_id                => l_application_id
,x_descriptive_flexfield_name    => l_descriptive_flexfield_name
,x_descriptive_flex_context_cod  => l_descriptive_flex_context_cod
,x_application_column_name       => c.application_column_name
);
END LOOP;
fnd_descr_flex_contexts_pkg.delete_row(
x_application_id                => l_application_id,
,x_descriptive_flexfield_name    => l_descriptive_flexfield_name
,x_descriptive_flex_context_cod  => l_descriptive_flex_context_cod
);

–commit;
end;

/by
, , , ,

Bug 1930586: MATCH_OPTION COLUMN/METHOD MISSING IN Purchase Document Open Interface

Bug 1930586: MATCH_OPTION COLUMN/METHOD MISSING IN PDOI

=========================================================================== 
                             PROBLEM DESCRIPTION 
=========================================================================== 
  ** DESCRIPTION OF PROBLEM, INCLUDING ALL ERRORS: 
     There is no column that accepts the value for match_option (invoice
    matching 'P'or'R') in PO_LINES_INTERFACE. (The enhanced PDOI now supports
   standard PO import.) If there is a method to populate the matching
   option value via the PDOI, it should be documented in the PDOI update
    release note. "matching option" is stored in the following table in EBS.    
 PO_LINE_LOCATIONS_ALL.MATCH_OPTION 
 
=========================================================================== 
                            ADDITIONAL DETAILS 
 =========================================================================== 
  ** TAR NUMBER (ALSO ENSURE BUG NUMBER FIELD IS UPDATED IN TAR): 
  ** LIST ADDITIONAL DOCUMENTATION AVAILABLE (LOG FILE, REPORT, TRACE, ETC.): 
 N/A     
  ** HOW WILL DEVELOPMENT RECEIVE THE ADDITIONAL DOCUMENTATION?: 
Via Email or ess30 upon request. 
  ** DESCRIBE ANY WORKAROUND(S) AVAILABLE TO THE CUSTOMER: 
Open POXPOEPO and update the option for all imported POs, which is rediculous. 
 
  ** LIST NAME & VERSION OF ALL MODULES INVOLVED (FORM,REPORT,PACKAGE,ETC.): 
EBS 11.5.3
Please ask if you need specific file versions. 
  ** IS THE PROBLEM OCCURRING IN TEST OR PRODUCTION? 
Production. 
   ** DOES THE CUSTOMER HAVE ANY CUSTOMIZATIONS OR 3RD PARTY PRODUCTS? 
No. 

=========================================================================== 
                                 HISTORY 
=========================================================================== 
   ** WAS THE CUSTOMER ABLE TO COMPLETE THE SAME PROCESS PREVIOUSLY?: 
No. 
  ** LIST PATCHES APPLIED RECENTLY WHICH COULD AFFECT THIS PROBLEM: 
N/A 
Defaulting of match_option is as follows
 1. From Supplier Site
2. From Supplier
3. From Financials System Parameters
The HLD for STD PO do not mention anything about this column.
Will be an ER to create the column in CASE and to add the necessary 
 validations.


PREMCOR REFINING GROUP is requesting this ER be changed to a priority 3 bug so 
a fix can be included in a future PO Family Pack.   They have 100's of PO's 
 that they import from a 3rd party system (Maximo) using the PDOI.  These 
multi-line POs are primarily Service Type POs and whether the line can either
be Invoice Match Option to Receipt or Invoice Match Option to Purchase Order 
 needs to be controlled at the Line level when inserting into the PO Interface 
tables.





Here is the solution for the invoice matching, someone needs to update the 
bug to include this solution:
 
Invoice matching, populate the following columns in PO_LINES_INTERFACE table:
'2WAY'  inspection_required_flag = 'N'
         receipt_required_flag    = 'N'

'3WAY'  inspection_required_flag = 'N'
          receipt_required_flag    = 'Y'

'4WAY'  inspection_required_flag = 'Y'
         receipt_required_flag    = 'Y'
/by