As of right now there is no way to change the standard date format display. However, a workaround would be to use a formula that reformats based on the result in the timescale column. Unfortunately that wouldn't replace the standard timescale column, feel free to let me know if you'd like more details on this workaround approach.
Where we have a line item that reformats a date or time period value
For item 1, the only way to change the format of the native timescale column header is to use a false time dimension (for the related reports and map Anaplan time periods into the false time periods). In this case, it might be addressed as follows:
Create a list named TimeList (or something)
Call the items in the list whatever you need. For example
For each item in the list, we will either map the item to an explicit period, or calculate the mapping if the list is used in conjunction with another dimension (such as native Anaplan time in years)
If explicit reference, just create a property and map the period. this implies that the list items are named to specific month/year combinations.
If relative to years (which allows for a clean month header, like the list item examples above), Add a module with Time in Years and your TIMElist. Then add a line item to calculate the period based on the intersections between anaplan time in years and the TIMElist items.
Note, you will need to map each month in your TIME list to a numeric month value. For example, Jan=1.
The intersection of Jan and FY 2018, therefore, should calculate to Jan 2018... the formula will look something like Period( Date( Year(Item(Time)) , TimeList.MonthNumber, 1) )
The result can be used as a lookup reference from a source data module.
I typically avoid adding this extra layer of configuration, unless there is a strong motivation. It happens most frequently where there is a need to format things as simply as possible for executive types.
I'm a little short on time today, but let me know if you want an example, I can dig one up.
@PaulRitner, thanks a lot for sharing that approach. I still need to review the attachment 🙂 My first impression is that I might be able to use it in the future but I need to fully understand it and run some tests. If I understand it correctly you have re-engineered the aggregation on a false time dimension.
On the specific use case I'm working on I decided to use the time dimension because there were too many time-specific functions I wanted to make sure I could use eg cumulative, previous, next and others....
I therefore thought the easiest approach was to "plug in" reporting modules at the end and relabel the time accordingly using a list/property.
However 🙂 I've got one last specific example I'm struggling with : this time the relabelled time is on an Input module and the fake time dimension is on the "across", not on the "down" dimension....
Attached picture should give a feeling of what I've got...I was planning to create a module dimensioned by the fake year dimension and then amend the current one to lookup the value typed in by the user. However, it seems I'm failing miserably on the lookup. It seems I'm missing something obvious. Any clues or hints&tips ?