Setting Up Price Rounding in 1C-Bitrix: Accuracy and Marketing

We often encounter this situation: a client updates 1C, and the site shows a price of 324.57 rubles for an item that costs 349 rubles with a 7% discount. Managers complain about "ugly" prices, the accounting department about discrepancies with 1C. Price rounding in Bitrix is the point where a mathematically correct result turns into an artifact if the rules are not set correctly. Our experience shows: properly configured rounding rules save hours of approvals and increase customer trust. In one project with a catalog of 50,000 items and three price types, manual correction took up to 3 hours a day — after automating rounding, the problem was solved in 4 hours. Our approach reduces the time to set up rules by 3 times compared to typical solutions.

With 10+ years of experience, we have completed over 200 Bitrix projects and are certified as "1C-Bitrix: Developer". Every solution is tested on a copy of the site before deployment.

More about the psychology of pricing — on Wikipedia

Where Is Rounding Configured?

Settings → Product Settings → Catalog → Price rounding. In earlier versions, it was in the component settings of bitrix:catalog.element and bitrix:catalog.section with parameters PRICE_VAT_INCLUDE and separate roundings.

Global rounding rules — CCatalogProduct::getRoundRules() reads from b_catalog_rounding_rule. The table is simple: price type ID, range, type, and precision. But in projects with dozens of price types and complex discount logic, manual configuration via the admin becomes a nightmare. We write migration scripts using \Bitrix\Catalog\RoundingTable.

What Rounding Rule Types Does Bitrix Support?

Mathematical rounding — the basic choice for accounting, but it doesn't give "beautiful" prices for the storefront. Rounding down is often used in marketing: price 324 instead of 324.57 looks more attractive. Rounding up is rare, when you need to avoid losing on kopecks.

How We Configure Rounding: A Real Case

In one project with a catalog of 50,000 items and three price types (retail, wholesale, small wholesale), the task was: for retail, round down to integers; for wholesale, round up to tens; for small wholesale, mathematically to 0.1. Plus for prices over 10,000 rubles — a separate rule. We wrote a script in PHP 8.1 using \Bitrix\Catalog\RoundingTable::add() and a migration via Yurii\BitrixModels\Migration. The whole process took 4 hours, including testing on a copy. After deployment, discrepancies with 1C disappeared, managers stopped manually correcting prices.

// Adding a rounding rule \Bitrix\Catalog\RoundingTable::add([ 'CATALOG_GROUP_ID' => $priceTypeId, // 0 = all price types 'PRICE_FROM' => 0, 'PRICE_TO' => 999.99, 'ROUND_TYPE' => \Bitrix\Catalog\RoundingTable::ROUND_MATH, 'ROUND_PRECISION' => 0, // to integers ]); // For prices from 1000 — another rule \Bitrix\Catalog\RoundingTable::add([ 'CATALOG_GROUP_ID' => $priceTypeId, 'PRICE_FROM' => 1000, 'PRICE_TO' => null, 'ROUND_TYPE' => \Bitrix\Catalog\RoundingTable::ROUND_MATH, 'ROUND_PRECISION' => -1, // to tens ]); 

ROUND_PRECISION — number of decimal places (negative values round to tens, hundreds). Important: if you have price types with VAT, rounding is applied before adding tax. This is standard behavior but often raises questions.

Why Does Rounding in the Cart Differ from the Storefront?

Rounding rules are applied when calculating the final price via CCatalogProduct::GetOptimalPrice(). In the cart component, it's when recalculating the line total. But discounts, coupons, and VAT can distort the result. For example: on the storefront, price with VAT is 1200 rubles, without VAT — 1000 rubles. In the cart, when applying a 10% discount, the base price rounds to 1080 (with VAT) or 900 (without). If VAT is added after rounding, the total may differ by kopecks. This is normal and regulated by the complex component settings.

Psychological Pricing

For prices like ".99", rounding rules are not suitable — this is a marketing task solved by a postfix handler. For example, an event handler for OnSaleOrderBeforeSaved or a custom price recalculation method. We implement such scenarios turnkey: configure the logic "price always ends in 9", "rounding to 49 or 99 kopecks", etc.

What Is Included in the Work

• Audit of current rounding rules: analysis of the b_catalog_rounding_rule table, identifying duplication and conflicts.
• Development of custom rules: writing migration scripts, custom handlers for psychological prices.
• Testing on a copy of the site: checking all price types, discounts, cart, export to 1C.
• Documentation: description of created rules, instructions for managers.
• Training: how to add new rules via the API, not the admin.

Deadlines and Guarantees

Basic setup of rounding rules for all price types — from 1 to 3 hours. Non-standard logic (psychological prices, different rules for categories, integration with 1C) — from 4 to 8 hours. We guarantee that after setup, prices on the storefront and in the cart will display correctly, and discrepancies with 1C will be eliminated. We will evaluate your project for free — get a consultation by contacting us via chat or email. Our team's experience: 10+ years of Bitrix development, over 200 completed projects, certification "1C-Bitrix: Developer".

Comparison of Rounding Approaches

Let's compare approaches. Mathematical rounding (ROUND_MATH) gives accounting accuracy but looks ugly on the storefront. Rounding down (ROUND_DOWN) is attractive to customers but slightly reduces margin. Rounding up (ROUND_UP) protects against loss, but customers may notice overpricing. A psychological handler provides a marketing effect but requires development. For most projects, we recommend a combination: for retail — rounding down to integers, for wholesale — mathematical to tens, and for promotional prices — a custom handler.

Contact us to discuss your project. We will analyze your current rules for free and suggest the optimal solution.