Dynamic renaming of line items
Consider the following situation:
As part of a planning process, a planning user requires the following items to be presented in the module:
- Current year revenue actuals - year to date, needed to plan for the next year around the third-quarter quarter mark of the year
- Current year revenue projection, based on the run rate
- Current year revenue override
- Current year revenue final
- Next year revenue change, as a percentage of current year revenue final
- Next year projected revenue
- Next year + 1 projected revenue, as an input
Therefore, a simple planning module may look like:
This will become a scalable solution where a system module can define the current year value in order to lookup the actuals for the current revenue line item.
However, from a planning user's point of view this would not be a very user friendly presentation. One will need the definition of the current year presented on the dashboard and, for a majority of planning users, this can become less intuitive.
Instead the module can be updated as:
This is more intuitive for the end user, but requires maintenance at financial year rollover. If the number of such modules are vast, then a manual update of the line items become less feasible.
One possible solution is to use a process that can dynamically update the line Items, which can be run as part of financial year rollover. The following steps can be used to achieve this:
Define codes for the line items in the planning module. This can be defined as:
Create a list with the codes defined in the planning module as:
Define a module with the above list and a number of line items as:
The planning assumptions module can be updated as:
Define an import action from this line items module as source to the planning module's blueprint as:
Run the import, and the line items will be renamed as:
Setting different planning year values in the planning assumptions module and running import action will rename the planning module's line items as:
Note: The order of line items presented in the source view will define the order in which the line items will be renamed. Therefore, it would be best to first rename the current year +2 values and then current year +1 and current year entries; otherwise, some line items may end up looking like "FY24 Revenue~1", which is done automatically to ensure the line items are unique.
One important aspect to consider is the usability of this planning module as an export module. As the line items have an opportunity to be renamed, using the module as is in a saved view for model-to-model import or file export would not be ideal. Therefore, it would be beneficial to use the data from this planning module into another module where the line items do not change for export purposes. One suggestion would be that the export module use the defined line item codes as the line item name.
This approach can be extended to rename all modules that have such behaviors, using one common line items list and using separate views per destination module. This method of line item renaming will also employ a uniform naming convention across all the planning views, and the same line item code can be used across different modules because the line item code uniqueness is limited to the scope of that module.