Automated Exchange Rate Updates for 1C-Bitrix Pricing

B2B portal with 15,000 products: prices in euros, counterparties pay in dollars. The exchange rate changes daily. Manual update of 15,000 items takes 8 hours with a 30% error probability. We automate this process — the automated agent handles it in 2 minutes, 12 times faster than manual entry. Manual price updates cost approximately $500/month in staff time; automation reduces that to $10. The solution starts at $500 and pays for itself within a month. Typical annual savings range from $5,000 to $12,000. Order a free audit of your current system — it takes no more than an hour.

Why ordinary conversion is not suitable for B2B?

On-the-fly conversion via CCurrencyRates::ConvertCurrency() creates uncertainty: the price changes with each request. For B2B with fixed price lists, stored price recalculation via an agent is needed. This gives a stable daily price and 70% fewer database queries.

How to protect data from rate anomalies?

Rates from public APIs are not perfect: zeros, outdated values, or temporary spikes can occur. The recalculation agent has built-in anomaly protection: if the new rate differs from the previous one by more than 5%, the update is blocked. The administrator receives a notification via \Bitrix\Main\Mail\Event::send(), and the event is logged with both the original and rejected values. This prevents losses from erroneous pricing — in our practice, it saved a client from losing $10,000 in a single day.

How to set up automatic price recalculation by exchange rate in 1C-Bitrix?

Setting up automatic price recalculation by exchange rate in 1C-Bitrix includes three stages: selecting a rate provider, automatic rate updates, and the recalculation agent. Compared to manual updating, automation reduces time by a factor of 4 and eliminates error probability. A typical project saves significant manager salary costs.

Selecting a rate provider

For BYN we use the NBRB API, for EUR/GBP — the ECB. Provider comparison:

For standard currencies we use built-in providers, for non-standard ones we write a class based on \Bitrix\Currency\RateProvider.

Recalculation agent

The agent is split into batches of 500 items to fit within max_execution_time. Example code using \Bitrix\Main\ORM\Data\DataManager:

\Bitrix\Main\Loader::includeModule('catalog'); $factor = CCurrencyRates::GetConvertFactor('EUR', 'BYN'); $prices = \Bitrix\Catalog\PriceTable::getList([ 'filter' => ['=CATALOG_GROUP_ID' => 1, '=CURRENCY' => 'EUR'], 'limit' => 500 ])->fetchAll(); foreach ($prices as $price) { $newPrice = round($price['PRICE'] * $factor, 2); \Bitrix\Catalog\PriceTable::update($price['ID'], ['PRICE' => $newPrice, 'CURRENCY' => 'BYN']); } 

Rounding is configured in the currency settings. For BYN — to kopecks, for wholesale prices — to whole dollars.

The agent log is maintained using FileLogger. The entry contains: price ID, old and new values, factor, time. The file rotates at 10 MB size. This implementation leverages D7 ORM caching and transactional integrity for optimal performance.

Official 1C-Bitrix documentation: "Agents are functions that execute on a schedule."

Agent parameters: what we configure

How we implement the recalculation: components and code

Our team configures the full cycle: from the rate provider to the agent with logging.

1. Rate provider. If a non-standard source is needed (e.g., NBRB), we write a class implementing \Bitrix\Currency\RateProvider. For standard ones (Central Bank of Russia, ECB) — ready-made solution.
2. Automatic rate update. We configure a cron job cron_events.php with a call to \Bitrix\Currency\CurrencyManager::updateCurrencyRates(). Without cron, updates are only performed on hits — on a portal with 10,000+ items, the rate may not update until noon.
3. Recalculation agent. The code is split into batches of 500 items to stay within max_execution_time. More about agents.

Process: from analysis to support

1. Analysis. We study the catalog structure: what price types, in which currencies, and which user groups. We determine the rate provider and rounding rules.
2. Design. We develop a technical specification for the agent: execution interval, batch processing, anomaly handling (deviation >5% — block and notify).
3. Implementation. We write the provider code (if needed), the agent, and the logger. We use transactions for atomicity.
4. Testing. We test on a portal copy: simulate rate spikes, check logs. We guarantee the agent runs without failures.
5. Deployment and training. We deploy on the production server, document the work, and train the administrator.

Typical setup mistakes

• No cron: updates only on hits, delay of several hours.
• Incorrect rounding: prices with too many decimal places.
• Agent without batch processing: timeout on catalogs over 10,000 items.

What's included in the service

• Development of a custom rate provider (NBRB, Central Bank, etc.).
• Recalculation agent with batch processing and anomaly protection.
• Configuration of cron jobs and logging (FileLogger).
• Integration documentation and administrator instructions.
• 30-day guarantee on agent uptime.