Configure Demand Forecasting in 1C-Bitrix
A warehouse orders goods based on manager intuition: if last month sold 100 units, they order 120. The result: seasonal items run out at peak, while non-seasonal ones freeze working capital. Stockouts lead to up to 30% revenue loss, excess inventory incurs additional storage costs. Losses from poor purchase planning can reach 30% of turnover. We solve this by setting up demand forecasting based on historical sales data already stored in b_sale_order_basket. No ML magic — only statistics proven on dozens of projects. Using moving average algorithms and seasonal coefficients, we reduce stockouts by 30% and decrease average inventory levels by 15%. Forecasting implementation pays off in 2–3 months by reducing overstocking and accelerating turnover.
Data Source: Sales History in Bitrix
All sales are stored in b_sale_order_basket (order items) and b_sale_order (order headers). For forecasting, we need completed orders where b_sale_order.STATUS_ID corresponds to final statuses (typically F — fulfilled, D — delivered).
Basic query to get sales history by product:
SELECT
DATE_TRUNC('month', o.DATE_INSERT) AS sale_month,
ob.PRODUCT_ID,
SUM(ob.QUANTITY) AS qty_sold
FROM b_sale_order_basket ob
JOIN b_sale_order o ON o.ID = ob.ORDER_ID
WHERE o.STATUS_ID IN ('F', 'D') -- completed and delivered
AND o.CANCELED = 'N'
AND ob.PRODUCT_ID = :product_id
AND o.DATE_INSERT >= NOW() - INTERVAL '24 months'
GROUP BY 1, 2
ORDER BY 1;
24 months is the minimum horizon to identify annual seasonality. Data must be cleaned of anomalies: returns, test orders, mass sales. We use an additional filter by order type and exclude items with quantity > 3 standard deviations.
How to Prepare Sales History for Forecasting?
- Collect all completed orders from the last 24 months from
b_sale_order_basketandb_sale_order. - Filter out canceled, returned, and test orders (
CANCELED = 'N', statusesF,D). - Aggregate data by product and month — get monthly sales.
- Remove outliers (sales more than 3 sigma from the mean) — they distort the forecast.
- Save the result in a separate table or Highload-block for further analysis.
Simple Forecasting Methods
For most online stores, three methods without ML are sufficient:
| Method | When to Apply | Accuracy | Implementation Complexity |
|---|---|---|---|
| Simple Moving Average (SMA) | Stable demand, no seasonality | Medium | Low |
| Weighted Moving Average (WMA) | Trend present, fast response | Higher than SMA | Low |
| Holt-Winters | Pronounced seasonality | High | Medium |
SMA — forecast for next month = average of last N months. N = 3–6 for stable demand, N = 2 for volatile. For example, products with uniform demand (household chemicals) SMA with period 6 gives error around 10%.
WMA — last month weight 3, previous month 2, third month 1. Reacts faster to trends. Suitable for products with growing or falling demand, e.g., seasonal novelties.
Holt-Winters accounts for trend and seasonality. More complex but significantly more accurate for products with pronounced seasonality: Christmas decorations, garden swings, school backpacks. Forecast error reduces to 5–7%. When combined with seasonal coefficients, SMA can be 2x more accurate than standalone SMA for seasonal products.
function forecastSimpleMA(array $monthlySales, int $periods = 3): float
{
$recent = array_slice($monthlySales, -$periods);
return array_sum($recent) / count($recent);
}
function forecastWMA(array $monthlySales, int $periods = 3): float
{
$recent = array_slice($monthlySales, -$periods);
$weights = range(1, $periods);
$total = array_sum($weights);
$sum = 0;
foreach ($recent as $i => $qty) {
$sum += $qty * $weights[$i];
}
return $sum / $total;
}
Seasonality Coefficient
For products with seasonality (winter clothing, garden equipment, school supplies), moving average will systematically err. The seasonality coefficient is calculated based on 2+ years of data:
// Average monthly sales volume over 2 years
$annualAvg = array_sum($monthlySales) / count($monthlySales);
// Seasonality coefficient for each month
$seasonalIndex = [];
for ($month = 1; $month <= 12; $month++) {
$monthData = array_filter(
$monthlySales,
fn($m) => (int)date('m', strtotime($m['date'])) === $month
);
$monthAvg = array_sum(array_column($monthData, 'qty')) / max(count($monthData), 1);
$seasonalIndex[$month] = $annualAvg > 0 ? $monthAvg / $annualAvg : 1.0;
}
// Forecast with seasonality adjustment
$baseForecast = forecastSimpleMA($rawSales, 3);
$targetMonth = (int)date('m', strtotime('+1 month'));
$adjustedForecast = $baseForecast * $seasonalIndex[$targetMonth];
Storing Forecasts and Reorder Point
Forecast results are stored in a custom table or Highload-block in Bitrix:
CREATE TABLE bl_demand_forecast (
id SERIAL PRIMARY KEY,
product_id INT NOT NULL,
forecast_month DATE NOT NULL,
forecast_qty NUMERIC(10,2),
method VARCHAR(50),
created_at TIMESTAMP DEFAULT NOW(),
UNIQUE (product_id, forecast_month)
);
Based on the forecast, we calculate the recommended purchase quantity: forecast_qty * safety_factor - current_stock. safety_factor = 1.2–1.5 (buffer for forecast inaccuracy and lead time). For products with long lead times (30+ days), the factor increases to 1.8.
A Bitrix agent recalculates forecasts once a week and writes to bl_demand_forecast. The administrative interface shows products whose current stock is below the recommended reorder level.
What We Configure
- Extraction of sales history from
b_sale_order_basketwith filter by final statuses - SMA/WMA algorithm for products with stable demand
- Calculation of seasonality coefficients over 24-month history
-
bl_demand_forecasttable (or HL-block) and a weekly recalculation agent - Administrative report: products below the reorder threshold
- Export recommendations to Excel or output to 1C via CommerceML for automatic order generation
How to Choose the Optimal Forecasting Method?
Method selection depends on demand nature. For products with uniform demand — SMA. If there is a trend — WMA. For seasonality — Holt-Winters or seasonal coefficient. We perform a preliminary analysis: plot sales over 24 months, assess variance and seasonal component. Based on this, we select an algorithm with minimal MAPE error. In 70% of cases, a combination of SMA + seasonal coefficients suffices.
Why Entrust Setup to Professionals?
We have been working with Bitrix for over 5 years (certified partners) and have implemented over 30 demand forecasting projects for online stores. Our experience ensures algorithms correctly account for your catalog's specifics, and integration with 1C and OFD runs smoothly. We guarantee forecast accuracy within 90% MAPE after the first month. We provide documentation, train managers, and offer post-project support. Get a consultation — we will analyze your order structure for free and propose an optimal solution.
What’s Included in the Work
| Stage | What We Do | Result |
|---|---|---|
| Analytics | Study order structure, check data for 24 months | Setup plan with method selection |
| Development | Write SQL queries, agent code, admin report | Working forecast with MAPE < 15% |
| Testing | Compare forecast with historical sales | Accuracy report and adjustment recommendations |
| Implementation | Configure agent, export to 1C via CommerceML | Ready functionality without downtime |
| Training | Conduct a webinar for managers | Confident use of the report and data interpretation |
Deliverables: SQL scripts for data extraction, agent code, HL-block structure, admin report template, export module to 1C, user manual.
Our projects demonstrate a 30% reduction in stockouts and 15% lower inventory levels on average. With 5+ years of Bitrix development experience and 30+ completed forecasting implementations, we deliver reliable results.
Estimated timeline: from 5 to 10 business days. Turnkey setup starts at $1,500 (for up to 1,000 SKUs) and pays for itself within 2–3 months. Cost is calculated individually after an audit. Contact us to get a consultation and estimate — we will prepare a commercial proposal within a day.
Source: official 1C-Bitrix API documentation — <https://dev.1c-bitrix.ru/api_help/sale/classes/ csalebasket/>







