What is Data Refresh?
Toolio works by aggregating your raw data (sales, inventory, and purchase orders) into different planning views, also called Plan Types. Most workflows in Toolio rely on these aggregations to power metrics, reports, and planning logic.
In most cases, Toolio automatically refreshes and re-aggregates data when changes are detected. However, there are some situations where you’ll need to manually trigger a Data Refresh to make sure everything updates correctly.
You should run a Data Refresh when:
You’ve changed a metric definition
For example, updating how a KPI is calculated.You’ve re-attributed products
For example, adding new product attributes or changing existing ones, and your plans or reports rely on those attributes.
What happens during a Data Refresh?
When you run a Data Refresh, Toolio:
Re-aggregates raw data based on the latest product attributes and definitions
Updates metrics across the selected Plan Types and contexts
Ensures planning views reflect the most up-to-date data
Note: The more data and time periods you select, the longer the refresh may take.
How to trigger a Data Refresh
Please see below for a step by step walkthrough:
1. Navigate to the Settings page by clicking on your initials in the top right hand side:
2. Select the Data Refresh tab, under the Imports section:
3. There are two ways to refresh data on this page:
Option A: The Refresh Wizard:
Select the three dots in the top right corner of the grid
Using the UI, select the Plan Type(s), Context(s), and and timeframe you are trying to refresh
Please note, the more data you are selecting the longer the refresh will take
Select Refresh
Here is a video on using the Refresh Wizard:
Option B: Using the Data Refresh Grid
You can also refresh data using the grid itself. Please see below video for a walkthrough on the process:
Below we cover the different types of Data Aggregations (i.e. Plan Type) and Metric Contexts in Toolio. This is a more technical overview.
Plan Types
In Toolio, each Plan Type (for example, Choice Plan, SKU x Location, or Merchandise Plan) represents a different way your data is aggregated.
Different Plan Types, different grains
Each Plan Type is built at a specific data grain, depending on how it’s used. For example:
SKU x Location is typically aggregated at the Variant x Location level
Choice Plan is typically aggregated at the Cluster x Choice level
Plan Types may also use different calendar configurations, such as:
Retail Calendar
Gregorian Calendar
Merchandise Plans and Plan Types
Every time you create a new Merchandise Plan, Toolio automatically creates a Plan Type with the same name. This is required so Toolio can aggregate sales, inventory, and purchase order data specifically for that Merchandise Plan’s structure and logic.
Default Plan Types in Toolio
Below are the default Plan Types available in Toolio and the data grain associated with each:
Plan Type | Grain | Notes |
Merchandise Plan | Time Dimension: Based on Calendar Product Dimension: Based on Merchandise Plan Attribute Location Dimension: Based on whether it's a Location enabled plan | Used for MP module |
SKU x Location Plan | Time Dimension: Week | Used for Allocation |
SKU x Location Data (Daily) | Time Dimension: Day | Used for Allocation, if Day Level allocation enabled |
Choice Plan | Time Dimension: Week | Used on Assortment Plan |
Item Metric | Time Dimension: Based on Calendar | Used on Item Plan |
Contexts
Below contexts are not definitive and Toolio can add additional Data Aggregation contexts. If you have questions on these, please reach out to your customer success manager
inTransit
This leverages data from Transfer Order and Transfer Receipts feeds.
Metric Aggregations & DSLs
transfer_order__inTransitCost|Retail|Units
In-transit cost (and retail/ticket) represents the value of inventory currently in transit between locations. It is computed by subtracting received units from ordered units, then multiplying by the unit price.
The calculation starts with transfer orders: for each active transfer order with a due date in the time period, the system captures the ordered units and unit price (cost, retail, or ticket). It then looks up all active transfer receipts linked to those transfer orders (matched by toLineId) and sums the received units. The in-transit units equal the ordered units minus the received units, but only if ordered units exceed received units; otherwise it is zero. The in-transit cost (or retail/ticket) is the in-transit units multiplied by the unit price.
The exact method depends on the plan type. In Item Plan and MFP Plan (transferOrder context), transfer receipts are filtered by delivery date, so only receipts delivered on or before the period end date are subtracted.
In Choice Plan (inTransit context), all active transfer receipts are included regardless of delivery date, which can reduce in-transit values if future receipts are already recorded. The result is stored as in_transit_cost__act (or in_transit_retail__act, in_transit_ticket__act) in the actual metrics, representing the value of inventory still in transit at the destination location.
FAQs
Why is there no context of Transfer Receipt in Data Refresh? Does the TO refresh also refresh transfer receipts?
Yes, transfer orders and transfer receipts are controlled by the Transfer Orders context, so refreshing transfer orders will refresh transfer receipts as well.