Automated bulk price update for 1C-Bitrix catalogs

A supplier sends a price list with 3000 new purchase prices. Your retail markup is fixed at 40%. You need to update retail prices by morning. Manual update is unrealistic: 8–10 hours of tedious work with rounding errors. Import via 1C is not always available. Bulk price update via Bitrix API is the solution we set up in hours. A PHP script using D7 ORM processes 3000 records in 2–3 minutes. Price types, infoblock bindings, quantity dependencies, tagged cache clearing—all require precise code. Our team has 10+ years of experience with such tasks and delivers stable results. Certified 1C-Bitrix developers offer a turnkey solution. Contact us to discuss your catalog.

Problems mass price update solves

Manual editing of thousands of products takes days; a script handles it in minutes. Rounding errors when calculating markup manually—automation eliminates typos. Dependency on 1C—when CommerceML exchange is not configured or temporarily unavailable, the API saves the day. Catalogs up to 100,000 products are processed without downtime.

How mass update works via D7 ORM

Prices are stored in b_catalog_price. Key fields: PRODUCT_ID, CATALOG_GROUP_ID (price type), PRICE, CURRENCY, QUANTITY_FROM, QUANTITY_TO (for price ranges). Price types are in b_catalog_group: BASE is the base, others are additional (retail, wholesale, purchase). CATALOG_GROUP_ID = 1 usually means base price, but it depends on the specific setup.

Comparison of update methods

Direct API update is 50 times faster than CommerceML for one-off updates—key advantage for urgent tasks.

Working with PriceTable API

Get price type ID by name:

$priceType = \Bitrix\Catalog\GroupTable::getList([ 'filter' => ['NAME' => 'Retail'], 'select' => ['ID'], ])->fetch(); $priceTypeId = $priceType['ID']; 

For more details, see the official documentation.

Implementation: from loading price list to cache clearing

Loading from Excel/CSV and markup calculation

Supplier price lists usually come in Excel or CSV. For parsing Excel, we use PhpSpreadsheet:

$spreadsheet = \PhpOffice\PhpSpreadsheet\IOFactory::load('/path/to/price.xlsx'); $sheet = $spreadsheet->getActiveSheet(); foreach ($sheet->getRowIterator(2) as $row) { // from second row (skip header) $cells = $row->getCellIterator(); $cells->setIterateOnlyExistingCells(false); $rowData = []; foreach ($cells as $cell) { $rowData[] = $cell->getValue(); } $articul = $rowData[0]; // A: SKU $newPurchase = (float)$rowData[3]; // D: purchase price // Find product by SKU $productId = findProductByArticul($articul); if ($productId) { updatePrice($productId, PURCHASE_PRICE_TYPE_ID, $newPurchase); updatePrice($productId, RETAIL_PRICE_TYPE_ID, calcRetailPrice($newPurchase, 40.0)); } } 

Retail price calculation based on markup:

function calcRetailPrice(float $purchasePrice, float $markup): float { return round($purchasePrice * (1 + $markup / 100), 2); } 

Cache clearing and change log

After a mass price update, catalog pages show old cached prices. Clear cache for the entire catalog:

\Bitrix\Main\Application::getInstance()->getTaggedCache()->clearByTag('catalog'); // or clear by infoblock \Bitrix\Main\Application::getInstance()->getTaggedCache()->clearByTag('iblock_id_' . $iblockId); 

Alternatively, don't clear cache globally and wait for natural TTL expiry. But if prices changed for a time-limited promotion, clearing is mandatory.

For audit purposes, we recommend saving old prices before the update in a custom table catalog_price_history with fields (product_id, price_type_id, old_price, new_price, changed_by, changed_at). This allows rolling back erroneous updates and analyzing price dynamics.

Step-by-step update process

1. Prepare the price list in Excel or CSV format.
2. Parse the file with PhpSpreadsheet, extract SKUs and prices.
3. Validate and map SKUs to product IDs in the infoblock.
4. Run a batch loop of 100 records with a 50ms pause to update prices via PriceTable API.
5. Calculate retail price based on markup and write both price types.
6. Clear the tagged cache of the catalog.
7. Write change log to the catalog_price_history table.

How to avoid errors during mass update

Test the script on a copy of the catalog before production. Enable error logging in PHP and use MySQL transactions for atomicity. We include all these elements in the standard scope of work.

Typical errors

• Wrong price type identifier—prices go to the wrong place.
• No batching—MySQL crashes on 10,000 products.
• Missing cache clearing—old prices remain on the storefront.
• No transaction—partial update on failure.

If the update fails, restart the script—it skips already updated records if there is an updated flag. Or roll back using the catalog_price_history table if created.

What's included in mass update setup and what guarantees we provide

• Analysis of the current catalog structure and price types.
• Development of an import script from Excel/CSV with automatic markup calculation.
• Implementation of batching for large volumes (up to 100,000 products).
• Configuration of tagged cache clearing.
• Creation of a change log table.
• Testing on a copy of the catalog.
• Script documentation and run instructions.
• 30-day stable operation guarantee.

Contact us for a project assessment. On average, we reduce update time from hours to minutes for catalogs of 10,000+ items.