# Year format calculation seems wrong

Hi,

I came upon a strange outcome of a (very simple) calculation. For my model I need to know in which Year a certain calculation should give out put. (Current year, current year +1 etc.) So I tried to create a boolean which specifies in which year a certain period is. It however gave strange out come, as it seems to wrongfully calculate some of the years.

There are probably better ways of creating the boolean (I would like to hear suggestions), but the calculation should work. Or am I missing something?

Thanks.

Kind regards

Pim

Tagged:

To convert the FY ITEM into a number try the following;

•

Very interesting, may I ask which model calendar you are using: Monthly, 454,445, or 544?  And when is the first day of the calendar period?

one idea for testing purposes, create two line items, one with the formula start() and the other end(), both formatted as date.  I am betting that will give a clue as to why those results look odd.

Rob

•

Thanks for your quick reply, you are right, the start dates are in the previous year (calender is week 4-4-5).

Is there an elegant way of solving this, so that the booleans reflect the correct time period?

Kind regards,

Pim

•

There can be many ways of doing so

1. As @ChrisAHeathcote  mentioned & demonstrated you can define a logic and get it working

2. Set it up one time manually in SYS time module and use that mapping in the model

Although all this can be done in Anaplan, what it can't do is to convert the Anaplan Planning Calendar to Gregorian Calendar as far the calculation is concerned. Anaplan will still calculate the numbers based on those many number of days within Anaplan calendar (364 or 366 days) and never 365 if your timescale is weekly. Hence the need of converting the 445 calendar into Gregorian calendar. Here is the link if there is a need

Convert Values from a 445 Calendar to a Normal, Mo... - Anaplan Community

Misbah

• @ChrisAHeathcote, thanks, this code will work for the next 80 years ;-), so I will apply this, much apreciated.
• @Misbah, great thanks, not needed for now,, but will be helpful in my next module. Kind regards, Pim