The Inventory Forecasting module helps you look ahead and estimate future inventory needs. While the main forecasting screen is designed for day-to-day planning, this article focuses specifically on the logic behind the forecasting algorithm.

If you want to understand how Megaventory arrives at values such as Forecast Demand, Demand to Cover, Projected Quantity, and Planned Purchase Quantity Needed, this guide explains the process in simple terms.

The goal of the forecasting algorithm is to answer a practical question:

Given historical demand, current stock, incoming supply, committed demand, and stock alert levels, how much inventory may need to be purchased in each future period?

To do this, the algorithm works period by period and product by product.

It combines:

• historical demand patterns

• seasonality

• approved purchase orders

• approved sales orders

• production order demand and supply, when applicable

• current stock

• stock alert levels

The result is a forward inventory projection and a suggested replenishment quantity for each forecast period.

The first step is to create the future periods that will be analysed. These periods depend on two user choices:

• Number of Forecasting Periods

• Forecasting Period Length

For example, if you choose:

• 6 periods

• 1 month per period

the algorithm creates 6 consecutive monthly buckets. If you choose:

• 12 periods

• 1 week per period

the algorithm creates 12 weekly buckets instead.

For each selected product and inventory location, the algorithm starts from:

• the current stock level

• the stock alert level

• the selected warehouse scope

This forms the inventory base that the forecast will project forward.

The system also respects the filters selected by the user, such as:

• company (if multiple companies are enabled)

• warehouse

• supplier

This means the forecast only uses the relevant product-location combinations.

The algorithm then analyses historical demand using the selected Forecast History Range. Historical demand is derived from past inventory movements that represent actual consumption patterns (shipments and production order allocations). This historical activity is grouped into monthly demand values and used as the basis for the forecast.

However, the forecast does not simply use a plain historical average. It also applies a Demand Decay Factor. The decay factor gives more importance to recent demand and less importance to older demand.

This helps the forecast adapt better when demand patterns have changed over time.

In practice:

• a higher decay factor keeps more influence from older history

• a lower decay factor makes the forecast more responsive to recent activity

After the weighted historical demand is calculated, the algorithm adjusts it for seasonality. This is especially important for products whose demand changes depending on the time of year. Instead of treating all months the same, the system looks at the historical demand pattern of the same calendar months that overlap the future forecast period. In simple terms, the algorithm asks:

How did this product usually perform in similar months in the past?

It then compares:

• the product’s overall average monthly demand

• the seasonal average monthly demand for the relevant months

From that comparison, it derives a Seasonality Factor.

That factor is then applied to the weighted historical demand, so the forecast becomes more realistic for seasonal products.

Once the weighted demand and seasonality adjustment are available, the algorithm calculates:

• Forecast Demand Before Seasonality

• Forecast Demand After Seasonality Before Rounding

• final Forecast Demand

The final demand is rounded and stored as the demand expected in that period.

This becomes the core demand component of the forecast.

The forecasting algorithm does not rely only on historical demand. It also includes quantities that are already known from existing business documents. Depending on enabled modules, it adds:

Demand components

• approved Sales Orders not yet shipped (non-shipped quantity in Sales Orders)

• non-allocated raw material quantities in Production Orders

Supply components

• approved Purchase Orders not yet received (non-received quantity in Purchase Orders)

• approved finished-good quantities from Production Orders not yet received (non-received quantity in Production Orders)

How can one set a committed demand component or a committed supply component to be calculated in a future period? In practice, how can I tell the algorithm that a current approved Purchase Order will be received in the future, in one of the forecasting periods?

The user may choose to use the expected dates of the PO (latest expected receipt date) for this information. The expected dates can be enabled per Document Template for Purchase and Sales Order templates.

The next step is to compute Demand to Cover. This is calculated as:

• Forecast Demand

• plus Non-shipped Sales Order Quantity

• plus Non-Allocated Work Order Quantity

So, Demand to Cover represents the total demand that the product should satisfy during that period. This is one of the most important numbers in the forecast because it is used directly in the stock projection.

The algorithm now aggregates the relevant values to the product level before performing the inventory projection. This means that the replenishment logic is now calculated on the total product position rather than summing shortages independently by warehouse. This ensures that values such as Projected Quantity and Planned Purchase Quantity Needed reflect the overall selected inventory scope for the product. In other words, the algorithm first totals the product’s:

• current stock

• stock alert level

• demand to cover

• incoming purchase quantities

• incoming production quantities

and then performs the replenishment calculation on those totals. This produces more consistent purchasing recommendations.

With product-level inputs ready, the algorithm projects inventory sequentially.

For the first period:

Starting Quantity is the current stock level.

Then it calculates:

Projected Quantity Before Planned Purchase = Starting Quantity + Incoming PO Quantity + Incoming WO Quantity - Demand to Cover

For each next period:

The Starting Quantity becomes the Projected Quantity End After Planned Purchase of the previous period.

This means the algorithm rolls inventory forward across periods instead of treating each period independently. That is why later periods can show very different replenishment needs depending on what happened earlier in the forecast horizon.

Once the projected stock before purchase is known, the algorithm compares it to the Stock Alert Level. The calculation is:

Planned Purchase Quantity Needed = MAX(0, Stock Alert Quantity - Projected Quantity Before Planned Purchase)

This means:

• if projected stock is above the alert threshold, no planned purchase is needed

• if projected stock falls below the alert threshold, the algorithm suggests the quantity required to bring stock back up to the desired level

This value is the recommended replenishment quantity for the selected period.

For example, with these forecasting settings:

and these results:

When the user clicks on the (i) icon, next to the forecast demand figure, a pop-up emerges with detailed explanation of the Forecast Demand calculation:

For each product and period, the algorithm ultimately provides a structured planning view per period:

• how much demand is expected

• how much demand is already committed

• how much supply is already expected

• how stock will evolve if nothing new is purchased

• how much should be purchased to remain above the stock alert threshold

This makes the forecast useful for both strategic planning and day-to-day purchasing.

The easiest way to think about the forecasting logic is:

1. estimate future demand from history

2. adjust for seasonality

3. add already committed demand

4. add already expected supply

5. project stock forward

6. compare the result to the stock alert level

7. calculate the replenishment quantity if needed

The Inventory Forecasting algorithm is designed to do exactly that. It transforms historical activity and current commitments into a period-by-period projection that can support purchasing, production planning, and stock control. Instead of reacting only when stock becomes low, users can review expected future shortages in advance and take action earlier.