Concept: versionmonth() Formulas and Custom Calendars

If your organization wants to swap from a legacy calendar to a custom calendar you should check your formulas for the use of

versionmonth()

. Swapping from a legacy calendar to a custom one will yield a different result for

versionmonth()

in identical cells.

Legacy calendars are calendars created before Release 2017.2 that have not been changed within the Time Administration area. See Steps: Change Calendars.

The easiest way to determine if your calendar is legacy is to view the Time Administration's toolbar. Only legacy calendars have the extend backward and forward buttons.

Legacy Calendar Time Administration Toolbar	Custom Calendar Time Administration Toolbar

There are three criteria

versionmonth()

formulas must meet so that the numbers in your instance don't change when you shift to a custom calendar.

versionmonth()

formulas require a time strata called "Month" present in your defined calendar.

versionmonth()

formulas must only exist in accounts at the Month time strata.

versionmonth()

formulas must be used to compare a relative position. They will not yield correct results if used to compare an absolute position.

if(versionmonth(this)=versionmonth(ROW.Date), "value if true", "value if false")

will continue to work

if(versionmonth(this)>0

"value if true", "value if false")

, will yield a different result than it previously did, but not produce an error.

If those criteria are met, you can continue to use your

versionmonth()

formulas in your custom calendar.

How versionMonth() Functions Calculate

Custom Calendar: In general, in a custom calendar, the
versionmonth
function acts as if your version started in January 2001. In other words,
versionmonth(this)=0
is in January 2001.
Legacy Calendar: In a legacy calendar
versionmonth(this)
will return the number of months away from the first month of the version.