A problem with context sensitive DFFs
One of the problems with context sensitive descriptive flexfields (DFFs) is that according to the Oracle documentation, the field that is used for the context must be in the same block. I ran in to this problem when my client wanted to setup the Approved Supplier List (ASL) and they wanted to have different additional fields in the Supplier block for the COMMODITY type and the ITEM type, where the context sensive field is in the Items block:
There shouldn’t really be a problem with the context itself, as it is effectively a header field (ASL_ITEMS.<field>) which would be the same for all fields on the lines block (ASL_SUPPLIERS.<field>) allowing the context to be consistent and reliable.
So we need to be able to access the constant header value in the DFF setup to set the context. For this we will need to use a forms GLOBAL variable to hold the value; this is accessible from the DFF setup, and can be set via forms personalization.
First we need a forms personalization that will save the value to a global variable when the user enters the supplier block.
This will trigger the saving of the context when the user enters the ASL_SUPPLIERS block
This will save the value into the global variable GV_ITEM_COMMODITY, which is created at runtime.
Now we need to setup the DFF to use the newly created global variable GLOBAL.GV_ITEM_COMMODITY:
Note that to make it work we need to Synchronize the context field with the reference field, also note that the reference field does NOT have the normal colon preceding the name.
Next Freeze the flexfield definition, and compile it.
Now to test the COMMODITY type:
And the Item Type:
