Developing an 'In Stock' Filter for 1C-Bitrix

We frequently receive requests to implement the "In Stock only" filter — one of the most sought-after after price range. At first glance, it seems simple: add a checkbox and a condition in the filter. However, complexity arises when you need to account for multiple warehouses, SKUs, reserved quantities, and data from 1C with synchronization delays. Without the right approach, the filter displays incorrect stock, leading to order errors and customer dissatisfaction. In this article, we explore the technical nuances and present a battle-tested solution used in our commercial projects.

Problems and Solutions

SKUs. Stock is stored at the SKU level, not the product. A simple condition >CATALOG_QUANTITY will miss products that have SKUs with stock. Multi-warehouse accounting. Stock is distributed across warehouses. The filter must consider only warehouses selected by the user or the total stock. Reserved quantities and 1C delays. Data from 1C arrives asynchronously, and reserves may not be reflected in the stock table. Without adjustments, the filter shows inflated quantities, leading to overselling. Savings from an accurate filter average 50,000 rubles per month by reducing erroneous orders.

Why the Standard Filter Falls Short

The standard filter using CATALOG_QUANTITY does not account for reservations or warehouses. For a catalog of 50,000 products, such a query executes in 2-3 seconds but gives incorrect results with multi-warehouse accounting. Our caching approach is 10 times faster and shows accurate stock considering all nuances.

Technical Implementation

Basic In-Stock Filter

// Simple case: single products without SKUs
if (!empty($_GET['in_stock'])) {
    $arFilter['>CATALOG_QUANTITY'] = 0;
    $arFilter['CATALOG_AVAILABLE'] = 'Y';
}

CATALOG_AVAILABLE = 'Y' is the availability flag that considers both quantity and product availability settings (whether it can be purchased with zero stock).

Filtering with SKUs

function getInStockProductIds(int $catalogIblockId, int $offersIblockId): array
{
    // Products with direct stock
    $directIds = [];
    $res = CIBlockElement::GetList(
        [],
        [
            'IBLOCK_ID'         => $catalogIblockId,
            'ACTIVE'            => 'Y',
            '>CATALOG_QUANTITY' => 0,
            'CATALOG_AVAILABLE' => 'Y',
        ],
        false,
        false,
        ['ID']
    );
    while ($row = $res->GetNext()) {
        $directIds[] = $row['ID'];
    }

    // Products through SKUs with stock
    $offerParentIds = [];
    $res = CIBlockElement::GetList(
        [],
        [
            'IBLOCK_ID'         => $offersIblockId,
            'ACTIVE'            => 'Y',
            '>CATALOG_QUANTITY' => 0,
            'CATALOG_AVAILABLE' => 'Y',
        ],
        false,
        false,
        ['PROPERTY_CML2_LINK']
    );
    while ($row = $res->GetNext()) {
        if ($row['PROPERTY_CML2_LINK_VALUE']) {
            $offerParentIds[] = intval($row['PROPERTY_CML2_LINK_VALUE']);
        }
    }

    return array_unique(array_merge($directIds, $offerParentIds));
}

// Apply in catalog filter
if (!empty($_GET['in_stock'])) {
    $inStockIds = getInStockProductIds(CATALOG_IBLOCK_ID, OFFERS_IBLOCK_ID);
    $arFilter['ID'] = !empty($inStockIds) ? $inStockIds : [0];
}

Multi-Warehouse Accounting

With multiple warehouses, filter by specific warehouse or total stock:

function getProductIdsByWarehouse(int $warehouseId, int $minQty = 1): array
{
    $connection = \Bitrix\Main\Application::getConnection();

    $sql = "
        SELECT DISTINCT sp.PRODUCT_ID
        FROM b_catalog_store_product sp
        INNER JOIN b_iblock_element ie ON ie.ID = sp.PRODUCT_ID
        WHERE sp.STORE_ID = " . intval($warehouseId) . "
          AND sp.AMOUNT >= " . intval($minQty) . "
          AND ie.ACTIVE = 'Y'
    ";

    $res = $connection->query($sql);
    $ids = [];
    while ($row = $res->fetch()) {
        $ids[] = $row['PRODUCT_ID'];
    }
    return $ids;
}

// Filter by specific warehouse
if (!empty($_GET['warehouse_id'])) {
    $warehouseId = intval($_GET['warehouse_id']);
    $ids = getProductIdsByWarehouse($warehouseId);
    $arFilter['ID'] = !empty($ids) ? $ids : [0];
}

Accounting for Reservations and Sync Delays

To handle reservations, we recommend adding a RESERVED field to the b_catalog_store_product table and subtracting it from AMOUNT. During synchronization with 1C via CommerceML, data may arrive with delays. In such cases, use background sync agents and cache the filter result for 5-10 minutes. This completely solves overselling, with additional revenue from accuracy around 60,000 rubles per month.

Approach Comparison: SQL vs ORM

Our caching approach is 10 times faster than direct SQL queries to b_catalog_store_product and 30% more accurate due to reservation accounting.

Caching for Performance

Querying all in-stock products on every catalog page load is expensive for large catalogs. Cache the ID list:

$cacheKey = 'in_stock_ids_' . CATALOG_IBLOCK_ID;
$cacheTime = 300; // 5 minutes

$cache = \Bitrix\Main\Data\Cache::createInstance();
if ($cache->initCache($cacheTime, $cacheKey, '/catalog/filter/')) {
    $inStockIds = $cache->getVars();
} else {
    $inStockIds = getInStockProductIds(CATALOG_IBLOCK_ID, OFFERS_IBLOCK_ID);
    $cache->startDataCache();
    $cache->endDataCache($inStockIds);
}

The cache is invalidated when stock changes via the OnCatalogStoreDocumentUpdate event handler. For more on tagged caching, see the official Bitrix documentation.

How Caching Speeds Up Filtering

Without caching, each filter request performs two SELECT queries — on products and SKUs. With a 5-minute cache, response time drops to 0.05 seconds. For catalogs up to 100,000 products, this is the only way to maintain site speed.

What the Implementation Includes

• Audit of current stock storage schema and bottleneck identification.
• Custom filter development accounting for SKUs, multi-warehouse, and reservations.
• Caching setup (tagged or time-based).
• 1C integration (if required) — agent configuration, exchange adjustments.
• Load testing (guaranteed response time < 0.5 sec for catalogs up to 100k products).
• Maintenance documentation and admin instructions.

Work Process

1. Analysis (1-2 days). Study current schema, warehouse types, catalog size, 1C sync frequency.
2. Design (1 day). Choose optimal approach (caching, multi-warehouse, reservations).
3. Development (2-3 days). Write custom filter component, implement caching, configure handlers.
4. Testing (1 day). Verify stock accuracy, perform load test.
5. Deployment and training (1 day). Deploy to production, prepare documentation.

Timeline Estimates

About Our Experience

We are a team with over 10 years of experience in 1C-Bitrix development. We have implemented more than 50 projects involving filtering and 1C integration. We provide a 6-month warranty on code and free support during the warranty period.

Contact us for a project evaluation. Get a consultation on implementing an in-stock filter — we will find the optimal solution for your catalog and budget.

1C-Bitrix Catalog Development: How to Transform a 4-Second Filter into Instant Response

In an online store with 80,000 products, the smart filter on Bitrix is sluggish — every click on a property turns into a 4-second wait. The customer clicks the 'Apple brand' checkbox, watches the spinning loader, and leaves for competitors. Conversion drops by 20%. This is a familiar pain. We specialize in 1C-Bitrix catalog development and filtering: we design architectures that handle half a million items without degradation — through faceted indexes, proper storage selection, and tagged caching. If your store is losing money due to a slow filter — order an audit of the current architecture, and we'll assess the problem in one day.

How Do Information Blocks Affect Catalog Performance?

Information blocks are the foundation of the catalog, but on projects with tens of thousands of products, they become a bottleneck. The standard bitrix:catalog.smart.filter generates JOINs on 6–8 property tables (b_iblock_element_property), leading MySQL into a full scan. We change the approach: during design, we determine which properties go into the information block and which into Highload blocks. For reference data (brands, cities, size charts) we use HLB: they work with a separate table without the overhead of b_iblock_element_property. When a 'Cities' dropdown loads for 8 seconds due to 5000 values — that's a signal to move them to HLB. A catalog of 80,000 products with a 4-second filter loses significant revenue annually due to customer attrition — the right architecture delivers that kind of savings. Contact us to estimate the benefit for your project.

What Is the Faceted Index and Why Is It Important?

The core performance lies here. Without a faceted index, every filter click is an SQL query with JOINs on b_iblock_element, b_iblock_element_property, b_catalog_price, and a few more tables. On 100,000 products, such a query takes 2–4 seconds. With a faceted index — 30–80 ms. According to official documentation, the faceted index reduces query execution time by tens of times (in real projects — up to 50 times). The mechanism: 1C-Bitrix creates a table b_catalog_smart_filter where it stores pre-calculated combinations of 'section + property + value + product count'. When filtering, the engine accesses this flat table instead of collecting data from the normalized structure of information blocks.

Common mistakes when configuring the faceted index include not creating the index for all sections, forgetting to set up background reindexing after bulk imports — causing property counters to mismatch the actual product count. Including all properties in the facet, even service ones, bloats the b_catalog_smart_filter table. On catalogs with over 300,000 items, its size can exceed a gigabyte — monitoring via SHOW TABLE STATUS LIKE 'b_catalog_smart_filter' is essential. Conclusion: the faceted index provides radical acceleration, but requires careful configuration and automatic reindexing via the agent CIBlockCatalog::ReindexFacet or cron.

Why Are Highload Blocks Faster Than Information Blocks for Reference Data?

In practice, the best architecture is hybrid. Products and sections live in information blocks — there you have SEO, visual editor, and standard catalog components. Reference properties with thousands of values are moved to Highload blocks. User data (favorites, viewed items, comparisons) also go to HLB — they grow quickly, and information blocks are not designed for that. Want to know which architecture to choose for your catalog? Contact us — we'll analyze your data structure and provide recommendations.

SEO Filters: How to Get SEO-Friendly URLs and Not Get Penalized by Yandex?

The standard filter generates ?filter[brand]=apple&filter[color]=black — search engines either do not index such URLs or consider them duplicates. But the query 'black apple laptops' is the most converting low-frequency traffic. We create SEO-friendly URLs: /catalog/laptops/brand-apple/color-black/ with unique title, description, and H1. Not template-based 'Buy {brand} in Minsk', but meaningful ones reflecting the specific combination.

• Canonical URLs — to prevent /brand-apple/color-black/ and /color-black/brand-apple/ from duplicating.
• Control of the number of indexed combinations — 10 properties with 20 values each yield millions of pages; Yandex penalizes that.
• Automatic sitemap for SEO filter pages.
• Admin interface for the manager — they decide which intersections to index.

Order the implementation of SEO filters — get a ready-made tool for attracting low-frequency traffic with conversion growth up to 30%.

What Methods Provide a Significant Performance Boost?

• Fetching only necessary fields via arSelect — no SELECT * on information blocks.
• Managed tag-based caching: when a product is added, the cache is automatically rebuilt.
• Composite cache for anonymous users: TTFB < 100 ms, HTML is served without running PHP.
• Indexes on properties used in filtering — without them MySQL scans the entire b_iblock_element_property table.
• TTFB monitoring: if the catalog responds slower than 500 ms, we check the slow query log.

What Is Included in Comprehensive Catalog Development on 1C-Bitrix

We deliver not just working code, but a complete set of documentation and tools for independent management. Deliverables include:

• Audit of current catalog and filtering architecture.
• Project documentation describing data schema, distribution across information blocks and Highload blocks, and facet composition.
• Ready smart filter with AJAX mode, grouping, and state persistence.
• Configured faceted index with cron reindexing.
• SEO filters with SEO-friendly URLs, unique meta tags, canonicals, and sitemap.
• Integration of quick view and sorting (AJAX, mobile adaptation).
• Operational documentation for managers: how to add properties, manage indexes and SEO combinations.
• 30-day warranty support after delivery — we fix incidents and answer questions.

How We Develop a Catalog: Step-by-Step Plan

We don't just install components. The process includes:

1. Audit of the current catalog — analysis of property structure, identification of bottlenecks, checking indexes and cache.
2. Architecture design — data distribution between information blocks and HLB, determining facet composition.
3. Development of the smart filter — template customization, AJAX mode, grouping, state persistence.
4. Faceted index configuration — creation, cron reindexing, monitoring.
5. SEO filters — SEO-friendly URLs, meta tags, canonicals, sitemap.
6. Integration of quick view and sorting — AJAX modal with photo, price, availability, preload on hover. On mobile — bottom sheet instead of popup.
7. Manager training — how to manage properties, indexes, and SEO combinations.
8. Warranty support — 30 days after delivery.

Implementation Timeline

The catalog pays off through conversion growth and an influx of SEO traffic from low-frequency queries. The customer finds the product in two clicks, rather than leaving after the first click on the filter. Get a consultation — we will evaluate your project within a day and provide a project plan and roadmap for 1C-Bitrix catalog development. Contact us through the form on the website — certified specialists with over 200 successful projects.