Why the religious holiday calendar breaks retail planning
Retail planning is largely done by looking at the same period last year. The method rests on the assumption that the periods are comparable. In Turkey that assumption breaks at least twice a year: Ramadan Bayram and Kurban Bayram are not fixed to the calendar year and move back about eleven days annually. The shift looks small; its effect is not.
The scale of the shift
Ramadan Bayram began on 30 March in 2025 and on 20 March in 2026. Kurban Bayram was in early June in 2025 and moved to late May in 2026. A ten-day shift moves the pre-holiday peak week entirely into the previous month in some years.
One month is enough to see the effect. In a supermarket chain, March 2026 revenue looks 19 per cent up on March 2025. In the same chain, April 2026 looks 12 per cent down on April 2025. In reality the two months together grew by 4 per cent. All the noise in between comes from the calendar.
That noise does not only distort the report. In a company setting monthly targets, the March manager takes their bonus and the April manager goes on the defensive, producing an outcome unrelated to what either of them did. The forecast built for the following year then uses that distorted series as input, and the error carries forward, growing.
The pattern inside the holiday
A bayram is not one day, it is a pattern. Its shape varies by category but stays remarkably stable within a company across years.
In a food retailer the typical pattern is: activity begins seven days before the holiday, peaks the day before the eve, runs very heavy until midday on the eve and collapses in the afternoon, most stores are closed on the first day, the second and third days run clearly below a baseline day, and the first working day after the holiday does not return to normal but stays low for two or three days.
Put in numbers: the day before the eve sells 2.4 times a normal day that week. The second day of the holiday is 38 per cent below a baseline day. The first working day after is 15 per cent down. These coefficients vary by store type and region but hold from year to year for the same store.
Once the pattern is known, the holiday stops being an uncertainty and becomes a plannable event. While it is unknown, it is a surprise every year.
Building a separate calendar dimension
A standard date dimension does not solve this. Year, month, day and day-of-week columns are fixed to the calendar month and cannot represent a moving event. The fix is to extend the date dimension and add an event-based calendar dimension.
The event calendar dimension holds each event's name, type, start and end date, and which year's instance it is. The date dimension gains fields relative to the event: which event this date is closest to, how many days until the event, which day of the event it is, whether it is the eve, whether it is a bridge holiday, whether it clashes with a public holiday.
The most valuable column in this structure is the event-relative day counter. It lets you compare the seventh day before the holiday with the seventh day before last year's holiday. The calendar dates differ but operationally it is the same day.
The second valuable column is the comparable equivalent day. For each date, which date it corresponds to in the previous year is calculated in advance and stored in the dimension. In normal periods that mapping preserves the day of week; in holiday periods it preserves the position relative to the event. The report author does not build this mapping — they read it from the dimension.
- DimDate — calendar fields, fiscal week, day of week
- DimEventCalendar — event name, type, start, end, year instance
- EventRelativeDay — negative values indicate the pre-holiday period
- ComparableEquivalentDay — the matching date from last year
- IsEve, IsBridgeHoliday, PublicHolidayClash flags
Separating baseline from event in demand forecasting
The problem a moving calendar creates in forecasting models is subtler. A model that captures seasonality mistakes the holiday effect for seasonality and places it in the wrong month every year.
The fix is to decompose the series. Observed demand is modelled as baseline demand multiplied by an event coefficient. Event coefficients are extracted from history first, the remaining series is modelled as baseline demand, and when producing a forecast the coefficient is reapplied according to the future event calendar.
The practical benefit of that decomposition is measurable. Once the baseline series is cleaned, trend and seasonality come out far more stable; the holiday coefficients sit in a separate table and can be examined by category. The eve coefficient for confectionery is not the same as the one for detergent, and making that difference visible does direct work for the planner.
The coefficients are not fixed; they are updated each year. But the update should not be a blind recalculation. Whether the holiday falls midweek or at the weekend, whether it coincides with school holidays and whether a bridge holiday forms all change the coefficient noticeably. That is why the attributes of the event instance have to be stored too.
Capacity, staffing and supply
The calendar shift does not only affect sales. Its effect lasts longer on the supply and delivery side, because lead times are longer.
Factories stop during the holiday, suppliers do not ship, customs and logistics slow down. A nine-day holiday pulls the reorder point forward by two weeks. When that calculation is not done, shelves run empty in the first week after the holiday and the lost sale appears in no report.
Staff planning has to hang off the same calendar. If the day before the eve will do 2.4 times the revenue, the till opening plan and shift distribution are built around it. Leave requests, meanwhile, pile up in the opposite direction. Having both read the same calendar dimension stops planning and reality drifting apart.
Branch-specific closing hours also need to live in the calendar. On the first day of the holiday some branches are closed and some open half day. If that information is not in the calendar, a closed branch's zero revenue reads as a performance drop.
What to do
Make year-on-year comparisons on the comparable equivalent day, not the calendar date. Build that mapping in the date dimension, not inside the report.
Hold holiday, eve, bridge holiday and public holiday information in a separate event calendar dimension and fill at least three years forward. Fill at least five years backwards too, so coefficients can be calculated.
Separate baseline demand from event effect in forecasting. Store event coefficients by category and branch, and review them every year.
For monthly targets, define a correction rule for years in which the holiday shifts. Write the rule when the target is set, not when the result is being explained.
In Mindpera, demand planning and Mind Space read the same event calendar dimension. The holiday pattern is applied from the same source as a coefficient on the sales side and as a reorder point shift on the supply side; the two sides cannot assume different calendars.