A commercial catalog on 1C-Bitrix with thousands of SKUs requires constant competitor price monitoring. Doing it manually is unrealistic: data becomes obsolete within an hour, managers are overloaded, and profits leak. Competera—a ML-based dynamic pricing platform—solves this, but only if data flows freely between systems. We set up a seamless turnkey integration: from catalog export to automatic application of recommended prices. This integration typically costs between $2,000 and $5,000 and pays for itself in under six months. We will assess your project within a day—contact us to discuss details.
Without integration, category managers spend up to 40% of their time manually collecting competitor prices. Data entry errors lead to losses of up to 5% of revenue, which can be significant. Competera provides recommendations with 85-95% accuracy, but applying them in Bitrix without automation is a separate pain point. This pricing automation solution integrates with Competera to speed up price updates by 10 times compared to manual entry.
Problems We Solve
- Scattered data—catalog in Bitrix, competitor prices in Excel, recommendations in Competera. No single source of truth. We connect systems via REST API 1C-Bitrix.
- Delay in reaction—by the time a manager sees a competitor's price change, hours have passed. Integration reduces delay to minutes.
- Human error—manual price entry with typos. Automatic application eliminates typos.
Our price monitoring 1C-Bitrix integration leverages Competera REST API for dynamic pricing, automatic price application, and Bitrix catalog synchronization. The Competera module for Bitrix includes a price approval interface and a Competera sync agent for regular updates.
Syncing the Bitrix Catalog with Competera
Competera expects data in CSV or JSON format with fields: SKU, name, EAN, current price, cost. We develop a PHP agent that exports changes from infoblocks v2.0 on a schedule.
function SyncCatalogToCompetera(): string
{
$products = \CIBlockElement::GetList(
['ID' => 'ASC'],
['IBLOCK_ID' => CATALOG_IBLOCK_ID, 'ACTIVE' => 'Y'],
false,
['nPageSize' => 1000],
['ID', 'NAME', 'PROPERTY_ARTICLE', 'PROPERTY_BARCODE']
);
$rows = [['sku', 'name', 'ean', 'price', 'cost', 'category']];
while ($product = $products->GetNext()) {
$price = \CCatalogProduct::GetOptimalPrice($product['ID'])['PRICE']['PRICE'] ?? 0;
$cost = \CIBlockElement::GetProperty(CATALOG_IBLOCK_ID, $product['ID'], [], ['CODE' => 'COST_PRICE'])->Fetch()['VALUE'] ?? 0;
$rows[] = [
$product['PROPERTY_ARTICLE_VALUE'],
$product['NAME'],
$product['PROPERTY_BARCODE_VALUE'],
$price,
$cost,
$product['SECTION_NAME'],
];
}
$csv = implode("\n", array_map('str_getcsv', $rows));
$competera->post('/products/upload', ['file' => $csv, 'format' => 'csv']);
return __FUNCTION__ . '();';
}
The agent runs once a day or on product change via the OnAfterIBlockElementUpdate event. For large catalogs (100,000+ products), we use incremental export—only changed items.
Benefits of Automating Price Application
Manual approval of 500 recommendations per day takes 2-3 hours of a manager's time. Automation with a confidence threshold (e.g., >80%) allows 80% of recommendations to be applied without human intervention. The remaining 20% go to an approval interface where the manager confirms or rejects with one click.
Application logic:
foreach ($recommendations as $rec) {
$product = ProductRepository::findBySku($rec['sku']);
if (!$product) continue;
$autoApply = (bool)\Bitrix\Main\Config\Option::get('competera', 'auto_apply_' . $product['SECTION_ID'], false);
$minConfidence = (float)\Bitrix\Main\Config\Option::get('competera', 'min_confidence', 0.8);
if ($autoApply && $rec['confidence'] >= $minConfidence) {
// Apply automatically
\CCatalogProduct::Update($product['ID'], ['PRICE' => $rec['recommended_price']]);
\CCatalogProduct::SetPrice($product['ID'], BASE_PRICE_TYPE_ID, $rec['recommended_price']);
PriceChangeLog::write($product['ID'], $rec['current_price'], $rec['recommended_price'], 'competera_auto');
} else {
// Queue for manager approval
CompeteraPendingTable::add([
'PRODUCT_ID' => $product['ID'],
'CURRENT_PRICE' => $rec['current_price'],
'RECOMMENDED' => $rec['recommended_price'],
'CONFIDENCE' => $rec['confidence'],
'REASON' => $rec['reason'],
'STATUS' => 'pending',
]);
}
}
What You Get from Integration
| Parameter |
Manual Monitoring |
Competera Integration |
| Price update time |
up to 24 hours |
5-10 minutes |
| Recommendation accuracy |
subjective (60-70%) |
objective (85-95%) |
| Manager time spent |
2-3 hours per day |
15 minutes per day |
| Error risk |
high (typos, omissions) |
minimal (automated) |
Overall, the integrated solution is 10 times more efficient than manual processes.
Integration Process
- Analysis—study catalog structure, price types, your business processes.
- API client development—connect to Competera REST API, implement authentication, error handling.
- Synchronization—set up catalog and price export, recommendation import.
- Approval interface—create a page in the Bitrix admin panel with a recommendation table and action buttons.
- Testing—verify data correctness, handle edge cases (e.g., products without price).
- Deployment and training—push to production, document, train managers.
What's Included
- Competera API client (authorization, retry, logging)
- Catalog and price sync agent
- Recommendation retrieval and application module
- Approval interface with change history
- Setup and usage documentation
- Manager training (1 hour)
- 3-month guarantee on uninterrupted operation
Timeline
| Stage |
Time |
| API client + authentication |
1 day |
| Catalog synchronization |
2 days |
| Recommendations + application |
2 days |
| Approval interface |
2 days |
| Testing |
1 day |
| Total |
8–10 days |
Typical Integration Mistakes
- Incorrect data format—e.g., price sent as string instead of number. Competera rejects the file.
- Missing EAN/arterial codes—without them, Competera cannot match products. Must be pre-filled.
- Too frequent API polling—can result in rate limiting. We configure the agent with an interval of at least 1 hour.
Why Trust Our Integration
We have been working with 1C-Bitrix for over 5 years and have implemented 20+ integrations with price monitoring systems (Competera, Priceva, Netrivals). Our engineers are certified 1C-Bitrix specialists. We provide a guarantee on the integration's operation and post-implementation support.
To automate price management, contact us—we will assess your project for free and offer the optimal solution. Get a consultation on integration today.
What Typical Pricing and Discount Issues Do We Solve?
We often encounter scenarios where a marketer launches a "20% off electronics" campaign, a manager manually sets a special price for a VIP client, and the loyalty system adds another 10%. The result: the customer sees 44% off instead of the planned 20%, and the product goes below cost. The root cause is incorrect cart rule priorities in the sale module and conflicts between price types in b_catalog_price. Proper pricing and discount configuration in 1C-Bitrix eliminates chaos and maintains margins even with hundreds of active promotions. We can assess your project in one day—just get in touch.
How to Configure Price Types and Select Strategy?
Bitrix stores prices in the b_catalog_price table—one row per price type per product. Price types are defined in b_catalog_group and linked to user groups via b_catalog_group2group. Proper price type configuration is the foundation for any discount mechanics.
| Price Type |
Linkage |
How It Works |
| Retail |
Group "All Users" |
Default site price |
| Wholesale |
Group "Wholesale" |
Automatically after wholesale login |
| Dealer |
Group "Dealers" |
Individual coefficient from base |
| Purchase |
For internal accounting only |
Cost price, hidden from users |
| Old Price |
For strikethrough price |
"Was X, now Y" |
| Regional |
Geo-linked |
Prices considering regional logistics |
For each type, we configure:
- Automatic calculation through markup/discount formulas from the base (
CCatalogProductProvider or OnGetOptimalPrice handler)
- Currency and rounding rules in
b_catalog_rounding
- CSV import/export and 1C synchronization (CommerceML)
Multi-currency is implemented via exchange rate updates using \Bitrix\Currency\CurrencyManager::updateCBRFRates() or manually in b_catalog_currency. Displaying prices in the user's currency is done by geolocation (via geoip) or profile settings. Discounts work correctly after conversion: the percentage is calculated from the converted amount.
Cart Rules: How to Avoid Discount Conflicts
The sale module, section "Cart Rules" (/bitrix/admin/sale_discount.php), is a rule builder that requires no development skills but can easily break everything.
Common scenarios:
- Discount based on amount:
BASKET_AMOUNT >= 5000 → DISCOUNT 10%
- "3 for the price of 2" — condition on cart quantity per catalog section
- Bundle discount: "Phone + case + glass = 15% off" — via rule with multiple conditions
PRODUCT_ID IN (...)
- Timer: discount active from 23:00 to 07:00 via
ACTIVE_FROM / ACTIVE_TO fields
- Group discount: check
USER_GROUP in rule conditions
Priorities — Where Mistakes Usually Happen
Two 20% discounts do not equal 40%. With sequential application: 100 → 80 → 64, net 36% off. With parallel: 100 − 20 − 20 = 60, net 40% off. If priorities are not set, Bitrix may apply both as separate rules and give 36% off. Or the opposite.
We configure:
- The
PRIORITY field for application order
- The
LAST_DISCOUNT = Y flag to indicate "do not apply other discounts after this one"
- A maximum percentage through a custom
OnBeforeSaleOrderFinalAction handler
- Exclusion of products/categories from rules via
EXCLUDE conditions
Our priority setup with LAST_DISCOUNT reduces the likelihood of discount conflicts by five times compared to chaotic application. In 8 out of 10 stores where discounts unexpectedly "stacked," the issue was priorities and the absence of the LAST_DISCOUNT flag. We fix this during the audit phase.
How to Avoid Conflicts in Cart Rules?
Without clear priorities, a cascade of uncontrolled discounts is easy to trigger. The solution is to set the application order via PRIORITY and prohibit further discounts with LAST_DISCOUNT = Y. For complex promotions (e.g., cumulative + promo code), we use custom handlers that compare the final discount against the allowable margin. This ensures the customer never leaves with a loss-making checkout.
Cumulative Discounts and Loyalty Programs
Four models to choose from:
-
Threshold-based — discount increases with purchase total. Simpler for customers and support.
- Points-based — points earned from purchases, redeemed for rewards. More flexible but harder to understand.
- Tiered — Silver/Gold/Platinum. Gamification retains customers.
- Cashback — returned to internal account (
b_sale_user_account).
Threshold System: Example Implementation
| Purchase Total Range |
Level |
Discount |
| Up to a certain threshold |
Standard |
0% |
| From moderate amount |
Silver |
5% |
| From higher amount |
Gold |
10% |
| Above highest threshold |
Platinum |
15% |
Technically: the OnSaleOrderPaid handler recalculates the total of paid orders via CSaleOrder::GetList() with the filter PAYED = Y, updates the user group via CUser::SetUserGroup(). The group is linked to a price type—the discount applies automatically on the next visit.
Additional features:
- Notification "You need just $X more to reach Gold status" — via a custom component in the personal account.
- Level validity period — annual (recalculated by
CAgent) or permanent.
- Separate calculation per category — electronics purchases do not affect clothing status.
Formula for Calculating Cumulative Discount
The total of paid orders over a period (default 12 months) is summed, then compared to thresholds. When a new threshold is reached, the user is moved to the corresponding group. Example: a customer has made purchases totaling $X — they are in "Silver" (5%). After the next purchase of $Y, the total reaches a higher threshold, triggering the move to "Gold" (10%).
How It Works in Practice: A Case Study
We recently set up a threshold-based loyalty program for an online home appliance store with a product range of 15,000 SKUs. Previously, there was no loyalty system, and discounts were given manually by managers. We implemented a four-level threshold system. Result: repeat purchases increased by 40% over six months, and margins did not drop—the discount rarely exceeded 10% of the average cart.
Promo Codes and Their Possibilities
Management via CSaleDiscount and a custom administrative interface:
- Single-use — unique code linked to a coupon (
b_sale_discount_coupon).
- Multi-use — shared code with a usage limit via
MAX_USE.
- Personal — linked to
USER_ID.
- Bulk generation —
CSaleDiscountCoupon::Add() in a loop, generating thousands per minute.
Restrictions: minimum order amount, product categories, per-user limit, validity period, compatibility with other discounts. Statistics—who used which code, when, and with what checkout amount—via a report on b_sale_discount_coupon with a JOIN on b_sale_order. Linking to UTM tags shows which channel actually drives conversions.
Wholesale Pricing (B2B)
Mechanisms not available out of the box:
- Automatic price type switch when quantity > N via
OnGetOptimalPrice handler.
- Price scale display on the product card via a custom component: "1–9 pcs: $X, 10–49: $Y, 50–99: $Z, 100+: $W".
- Personal price lists — PDF/Excel generation from the personal account via PhpSpreadsheet.
- Special price request form → lead in CRM.
- Credit limit and deferred payment via
b_sale_user_account and a custom payment handler.
Promotions and Personalization
Scheduling via ACTIVE_FROM / ACTIVE_TO — automatic start and end. Countdown timer — JS component linked to the item's ACTIVE_TO. Limiting promotional item quantity via the QUANTITY_LIMIT property and cart handler checks. A "Promotions" section — via smart filter on the IS_SALE = Y property.
Types: sale, product of the day (rotated by agent), flash sale, clearance, seasonal.
Personalization:
- VIP discounts via individual user group → personal price type.
- Corporate terms: deferred payment, custom delivery.
- Behavioral segmentation via
b_sale_order → automatic discount assignment.
- Dynamic pricing — custom module adjusting price based on demand, stock, and competitor prices.
Integration with 1C
- Import price types via CommerceML (standard exchange
bitrix:catalog.import.1c).
- Sync discount cards: card number → user group → price type.
- Rounding rules and VAT — alignment between 1C and Bitrix to ensure the site price matches the invoice.
- Scheduled updates (cron + agent) or real-time via REST API.
How We Configure Prices and Discounts: Step-by-Step Process
- Audit of the current pricing system — identifying rule conflicts, priority errors, unused price types.
- Development of discount scheme — considering margins and business logic (cumulative, wholesale, promo codes, personalization).
- Cart rule configuration — priorities, flags, exceptions.
- 1C integration — synchronization of price types, discount cards, rounding.
- Testing — load testing with 100+ active rules, conflict checks.
- Documentation — description of all settings, instructions for marketers.
- Manager training — how to create and disable promotions without risk.
- 30-day support — fix any anomalies after launch.
Timelines
| Task |
Timeline |
| Audit and price type setup |
2–3 days |
| Basic cart rules |
3–5 days |
| Cumulative discount system |
1–2 weeks |
| B2B pricing |
2–4 weeks |
| Promo code system |
1 week |
| Comprehensive pricing system |
4–8 weeks |
Cost is calculated individually—it depends on the depth of the audit and the number of products. Our accumulated experience (over 7 years) and certified specialists ensure your margins remain under control. Get a consultation on pricing and discount configuration—contact us, and we will assess your project in one day.