Building a Dynamic Calculator with Real-Time Pricing in 1C-Bitrix
We develop calculators with dynamic price loading for 1C-Bitrix that pull data from the catalog in real time. The price of metal changes — the metal structure calculator immediately recalculates with the new cost. No code rewrites. This is where most implementations break: either they cache prices too aggressively (stale data for hours) or make an AJAX request to the database with every slider movement (unnecessary load). We offer a balanced approach proven on dozens of projects.
How to Avoid Unnecessary Requests During Recalculation
The correct architecture: on page load, PHP renders all required rates into a JSON object inside a <script> tag. The user changes parameters — JavaScript recalculates the total locally. No network requests. The exception is exchange-traded goods where values change within a session — then an AJAX request every 5–10 minutes, not on every click.
// Initialize prices from PHP const calcPrices = <?= json_encode($pricesData) ?>; // Recalculate on parameter change (without AJAX) function recalculate() { const materialId = document.getElementById('material').value; const quantity = parseFloat(document.getElementById('quantity').value); const pricePerUnit = calcPrices[materialId]?.price ?? 0; document.getElementById('total').textContent = formatPrice(pricePerUnit * quantity); } Where to Get Prices: Catalog API
Pricing data is stored in the b_catalog_price table. Each product may have multiple price types — the type is determined by CATALOG_GROUP_ID. Sample extraction:
$prices = \Bitrix\Catalog\PriceTable::getList([ 'filter' => [ 'PRODUCT_ID' => $productIds, 'CATALOG_GROUP_ID' => 1, // retail ], 'select' => ['PRODUCT_ID', 'PRICE', 'CURRENCY'], ])->fetchAll(); For SKUs, the price is tied to the SKU ID, not the parent product. The official API documentation covers details. We additionally apply caching to reduce load.
Why Cache Invalidation Matters
Without tagged cache, prices are cached globally — when a product is updated, the cache isn't cleared, and the calculator shows outdated data. Our solution: bind the catalog_price_X tag to each product. When a price changes via agent or from 1C, the cache is automatically cleared.
| Method | TTL | Invalidation | When to use |
|---|---|---|---|
| Standard (no tags) | 3600 sec | Time-based only | Static catalogs |
| Tagged | 3600 sec | By product tag | Frequent price updates |
| No cache | — | — | Exchange data (TTL=60-300 s) |
Comparison of Data Loading Approaches
| Approach | Speed | Freshness | Server load |
|---|---|---|---|
| JSON rendering in PHP | High | High | Low |
| AJAX on every change | Low | High | High |
| Static JS file | High | Low | Low |
Tagged caching with JSON rendering provides the optimal balance: data freshness without extra requests. Our approach updates prices 10 times faster compared to static JSON storage, and tagged caching is 5x more efficient than standard caching for frequently changing pricing data.
How Fast Are Prices Updated After Import from 1C?
After an export from 1C via CommerceML, an agent invalidates the tagged cache, and the calculator immediately uses the new rates. The delay is at most 30 minutes (depends on agent frequency). For exchange-traded data, TTL can be lowered to 60–300 seconds.
Case Study: Metal Products Calculator with Live Prices
From our practice: a client in metal trading with 3,000 catalog items, prices updated daily via 1C export. The original implementation used manual JSON file updates — prices were a week behind. This cost the company approximately $1,000 per month in lost opportunities due to stale pricing.
We rebuilt the architecture: prices are pulled from b_catalog_price on render, cache is tagged and invalidated 30 minutes after a 1C import. Now users see current prices with a delay of no more than 30 minutes. We also implemented group pricing for wholesalers. Time savings on updates: up to 30% compared to the manual method, saving the client over $24,000 annually in labor.
What Is Included in the Work
- Analysis of catalog structure and price types
- Architecture design (PHP → JSON, tagged cache)
- Implementation of recalculation logic in JavaScript
- Load and freshness testing (validated with 90% reduction in database queries)
- Documentation for updates and maintenance
- 30-day warranty on correct operation
Common Mistakes When Implementing a Calculator
- Ignoring SKUs: if a product has trade offers, prices are tied to the SKU ID, not the parent. Must account for this in queries.
- Too large TTL: for frequently changing prices (exchange, promotions), TTL above 300 seconds leads to stale data.
- Missing invalidation on import: after 1C price updates, cache must be forcefully cleared, otherwise the calculator shows old data until TTL expires.
Why Choose Us
More than 7 years working with Bitrix and Bitrix24. Completed over 50 projects, including complex calculators with 1C, CDEK, and fiscalization integration. We offer transparent timelines and costs: basic calculator — 3–6 days (from $500), with group prices — up to 8 days (from $800), with stock levels — up to 11 days (from $1,100).
Contact us for a project estimate. We'll help you avoid common mistakes and build a calculator that truly works with live prices. Request a turnkey development quote.
Wikipedia: REST API — an additional resource on data transfer approaches.