Oracle Financials descriptive flex-fields reasons why and reasons why not.
I have not seen or heard much about descriptive flex-fields in a while so here is a quickie about the use of custom fields in Oracle Financials.
As a pre-cursor to this quickie I will mention that the same functionality is available in fusion financials but in fusion, there are some other aspects to consider for example ADF which I will not cover in this article.
All ERP systems have the facility to enhance the user experience and deliver a solution using a custom field. In Oracle, this is no different and the use of custom fields is common.
In my experience, we talk about custom fields often at the beginning of an implementation and this conversation is often left as with the “Oh well if we cannot find a solution then we can always use a DFF” answer.
I guess is true but not always the case so unless you do some research you may well find that a DFF is not the answer.
In addition to implantation scenarios an existing user of Oracle may want to enhance the current system to provide for a new requirement or for an interim workaround or just to enhance the current ERP system. In all these cases, a DFF may provide an excellent solution.
Existing Oracle users will be aware of key-flex fields for example the general ledger account flex or fixed asset category flex but may have forgotten about the ability to build a custom field called descriptive flex-field to hold additional data in your application.
The question about whether to use a DFF or not can be a tricky one and often there is already existing fields or functionality that will provide the solution so this needs to be established before requesting a DFF to be created.
There are many other questions to be asked for example what are the amount of system changes that may affect the DFF and not just the patches that are released to resolve issues but the organisation led changes to your systems. Question Your reporting requirements before creating and please look at the ETRL for your release of Oracle which will help you to understand the module integrations. Understand what might require regression testing after the DFF is live.
Question the effect on the database will the DFF require use of custom tables or affect processing or user access?
Now to a brief recap about the basics about DFF’s in case you have forgotten about them.
The custom field “DFF” is configured in the application set up and registered in the database. I will not go into detail as many good examples of the steps required to complete this exists out there on the internet and in the Oracle documentation.
The custom field is placed in a form in the application and is used to provide additional data you require for example identify a transaction and/or report on specific data either external data or data held somewhere else in the application.
The DFF is used where a form in the application does not contain the information that your organisation requires in that view.
The following characterises apply to DFF’s
· You can set it to be context sensitive i.e. a list of values or so data appears when certain information is entered but not on other occasions.
· Existing value sets may be used, those value sets may be securitized, those value sets may have cross-validation rules already applied to them.
· New value sets can be created for use with your DFF be careful when doing this.
· Use of the DFF could be mandatory or optional.
· Access can be set at a responsibility level so use could be restricted to an individual user, to a specific role or for all users.
· You may need to use with a custom code that you develop for the solution to work in a specific way.
· You may want to use it in some of the reports that your business intelligence tools produce.
Research. Some questions you may want to ask?
Do you know how many DFFs your application holds are any of these in custom tables?
Which modules make the most use of DFFs in your organisation?
Who will need access to the DFF to update, report or view?
Have you the resources to test a new DFF and train your users?
Who will maintain the DFF?
In my experience do DFF but think carefully about whether it is really needed, document the DFF, Understand the DFFs and always test the DFF.
Involve your team, ask your DBA for help and advice, speak to your support people and enjoy your DFF.