Fiscal Calendar Configurable

[simeonwillbanks]

Problem

The MerchCalendar gem uses the National Retail Federation (NRF) fiscal calendar which runs from February to January. If a MerchCalendar user has a different fiscal calendar, they must change year values before sending those values to methods such as MerchCalendar.weeks_for_month.

# Our companies' fiscal calendar runs April to March        
START_MONTH_OF_FINANCIAL_YEAR = 4       
# NRF is the National Retail Federation whose fiscal calendar runs February to January      
# The MerchCalendar gem uses the NRF fiscal calendar        
START_MONTH_OF_NRF_YEAR = 2

# gives NRF year for self.year in a given month     
 def nrf_year(month)        
  if month >= START_MONTH_OF_FINANCIAL_YEAR || month < START_MONTH_OF_NRF_YEAR      
    year.to_i - 1       
  else      
    year.to_i       
  end       
end

MerchCalendar.weeks_for_month(nrf_year(2014), 1)

Solution

Allow the fiscal year to be configurable.

Options:

• Offset the National Retail Federation fiscal calendar
• Add option for START_MONTH_OF_FINANCIAL_YEAR

[davetron5000]

Can you add an example of the problem this causes? I can't tell why the fiscal year should matter.

[davidamcclain]

January 2017 for us is FY17, but to the NRF and the gem it's (the end of) FY16. So when we ask the gem for the merch weeks of January 2017 we get back an unexpected value (since it was taking our input of 2017 and converting it to FY16) since January could have 4 weeks or 5 weeks depending on the year. If we could tell the gem to start the fiscal year in August we wouldn't have to do weird workarounds converting one FY to another.

[davetron5000]

Sorry to be still confused. I guess this is like the merch-specific version of timezones and DST all wrapped up into one, but isn't the API of this gem based on calendar dates and not fiscal years? In other words, why would we give this a fiscal calendar and expect it to work? Sorry if this is remedial—I haven't had to deal with this pain in a long time :(

Also note that @simeonwillbanks's proposed solution won't work for the Stitch Fix fiscal year, since ours begins on the first Monday after the last Sunday in July (or something like that—it's not a fixed day of a month each year).

[davidamcclain]

I guess this is like the merch-specific version of timezones and DST all wrapped up into one

Yeah, we're like that one sliver of west Texas that's in its own time zone. The issue is just that we, Stitch Fix, use a Fiscal calendar which is different from the NRF calendar and the gem doesn't allow us to account for that.

In other words, why would we give this a fiscal calendar and expect it to work?

January FY17 (for Stitch Fix) is calendar year 2017. But to NRF and the gem, January calendar year 2017 is their 2016. January "2016" and January "2017" have a different number of merch weeks. So for us, in this "bug", there isn't a different year to give the gem (FY and Julian year are the same), but the gem will answer with what it thinks are the weeks in calendar year 2017, which to it is still 2016.

Maybe "fiscal" year is a loaded term that doesn't properly apply, but the merch calendar year doesn't start in January, or August. And since our business doesn't align with either the calendar year or the merch calendar and likely other companies have similar needs, it would be nice to have the gem calculate the merch weeks based on a year that matches our own.

[jeffreyhunter77]

but isn't the API of this gem based on calendar dates and not fiscal years? In other words, why would we give this a fiscal calendar and expect it to work?

No. The API (or at least the part where this is an issue) is based on a fiscal year running from February to January. That works really well if you only feed in fiscal years, and your fiscal year exactly matches the one baked in to the gem.

Specifically, we've had issues with MerchCalendar.weeks_for_month(1, 2017) (i.e. give me the merch weeks for January 2017). Internally the gem assumes the year input is a fiscal year and converts it to a calendar year. So, it actually returns results for January of calendar year 2018.

Even if the gem isn't changed to support an arbitrary fiscal year, it would be way less confusing if operated based on wall calendar years.

[davetron5000]

Ugh, my comment was not meant for posting as I didn't think it was constructive. Somehow, my brain decided that meant "click "Close and Comment"". Anywho, I think you all know better than me how to fix this since you are the ones using it.