Today Pankaj Juneja a reader of unleashed is sharing a case study where a Picklist on a calculated field helped him solve a problem.
Many of us know that a calculated field can be made editable by putting a pick list and a pick map to it. I always use to think that what’s the use of Calculated Field by making it editable by showing a pick list when a user really can’t do anything much with it.
Recently I came across a problem in which I used it to save myself from a tricky situation. I was using S_ORG_EXT_ XM table to build a new entity which is having 1: M relationship with Account. We used most of the ATTRIB columns rather extending table. There was one field where we used LOVs to display Data to user. As per client coding standards, we were supposed to store LIC value in tables and show display values since the Application was supposed to go Multilingual in coming years. Since I was not aware of this standard and I placed an LOV on field based on ATTRIB and stored display value in column.
I was using the below config , which is straightforward :
Picklist config –
When we realized this problem, I was suggested to make it Multilingual by giving Translation Table Name at column level but I realized that since it’s a reusable table (S_ORG_EXT_XM). Tomorrow someone else can use it for some other entity and if I give Translation table, then that column will be useless for that developer since it won’t accept values other than those LOVs. More over its OOB table so doesn’t wanted to touch it as it might hamper Application upgrade.
I just quickly analyzed that now calculated field can be used here. Here is how it worked for me.
Remove pick list from existing field, place it on calculated field.
A Calculated Field Looking up LIC and having Pick list with 2 Pick Maps.
Now expose the above Calculated Field in Applet rather Actual Field. This will always show Display Value to User and behind the scenes store LIC in table via Pick map. Even Query, Sorting worked fine.