Author: David Edwards is a Certified Master Anaplanner and Associate Partner at Columbus Consulting.
For retail and consumer goods companies, a common issue occurs when different departments (typically supply chain and finance) utilize different calendar structures.
Supply Chain teams often rely on a fiscal calendar (such as 4-5-4 weeks) for planning. This structure is ideal for organizing their work around natural business cycles, aligning with vendor shipments, and evaluating weekly performance consistently.
Finance teams typically use a Gregorian calendar for planning. This is due to the need to align against external reporting, tax compliance, and overall corporate financial strategy, which are often tied to industry-standard calendar months and quarters.
Reconciling this difference in calendar perspective is an important functionality requirement for retail and consumer goods companies when evaluating a planning software. The inability to translate data between these two calendars can present a major roadblock when communicating budgets and plans between teams. Moreover, many retail-focused software solutions have specific functionality to accommodate this requirement, and the need is now being uncovered in Anaplan with the rollout of the Merchandise Financial Planning application, and the soon-to-be-released Assortment Planning and Allocation applications.
Proposed solution for converting fiscal to Gregorian
The key to overcoming this challenge is a centralized, automated conversion process that converts the fiscal calendar into Gregorian. When supply chain teams are planning at a weekly level but finance requires monthly consolidation, this presents the obvious question of how to successfully allocate weekly values that may span across two months. In general, the most effective approach is to allocate weekly forecasts down to a daily level, then roll those daily values into their corresponding Gregorian months.
For example, a supply chain team creates a forecast for a fiscal week. To make this forecast useful for finance, it needs to be broken down and assigned to the individual days of the Gregorian month. This conversion can be accomplished using multiple methods, but two common options are described below:
- Even split: The total weekly value is divided equally among 7 days. While simple to design, this option is often inaccurate for a retailer, as it ignores sales volume trends that may occur during the week.
- Historical drivers: A more accurate method is to use historical values as a driver (i.e. using the historical percentage of the week’s sales that occurred on each day). If historically, 20% of sales for a given week occur on Saturday, then 20% of the forecasted weekly value is allocated to the Saturday in question by using that week’s history as the basis of the daily allocation. Notably, this method requires daily history to be available at the necessary dimension granularity.
By converting the weekly or monthly fiscal forecast to a daily level, data can then be re-aggregated into the Gregorian calendar month using the overview outlined in the next section.
How to design the solution with Polaris
With Anaplan’s Polaris calculation engine, aggregating daily values into a Gregorian month can be achieved without the need for the complex, resource-intensive custom time lists that a model builder would encounter in the Classic calculation engine. Traditionally, users would need to build and maintain separate, custom time hierarchies to work around Classic’s inability to SUM values from a time-dimensioned module. With Polaris, the platform’s native capabilities now allow builders to model this conversion process efficiently.
By implementing this daily allocation and conversion strategy within Anaplan, retail and consumer goods companies can adequately reconcile the different calendar perspectives of their Supply Chain and Finance teams, ensuring greater accuracy, efficiency, and alignment across the entire organization.
Module Blueprint
Within a model that is using some form of fiscal calendar under Time settings, create a System module at the Day level and add the following line items:
The Fiscal Month represents the native time period for the day, but Gregorian Month is derived from the Year and Month of the Day Time member. Combine this with a generic “15” for the day (this ensures that the Gregorian Month will always calculate based on a date in the middle of a month that wouldn’t possibly cross the Fiscal Month divide). The image below confirms that Anaplan is successfully calculating the accurate Gregorian Month where the Fiscal Month is otherwise different (only mismatched dates are shown in this screenshot):
Shown below are the total number of days that roll into the fiscal and Gregorian months by using the line items above. In Polaris, model builders can SUM off the Gregorian Month line item, which is not an available feature in Classic:
While this example references a simple Count line item to pull in the number of days in a given month, model builders could replace the Count with any Day-dimensioned line item if they needed to report up to a Gregorian month level.
As Anaplan continues to expand into the retail and consumer goods industries, this approach will enhance the model building and planning experience for clients that are choosing Anaplan as their strategic enterprise planning system.
Questions? Leave a comment!
