Ozon Logistics

Version 4.5.0

Letters to the buyer about Ozon delivery progress. The module creates six email events with ready-made HTML templates: order transferred to Ozon, in transit, transferred to the courier, at the pickup point, received, delivery cancelled. The letter contains a link to the order in the personal account, tracking numbers with tracking links to the tracking.ozon.ru domain, order composition and amount, delivery service and address.

Letters are sent by the status synchronization agent, for standard Ozon delivery and for Business Delivery. Each stage letter is sent once; stages do not repeat backwards. There are no letters for orders created before the function was enabled.

New settings tab Buyer letters: enable, select stages, tracking link template and order link, send a test letter to yourself by order number.

Letter texts are edited in standard Bitrix email templates; module updates do not overwrite them.

Version 4.4.10

Orders in Ozon are no longer created without a portion of the goods. If Ozon cannot deliver part of the order items (for example, they are not in its warehouses) or the order composition was changed in the admin panel after the delivery calculation, the module does not send an incomplete order to Ozon, but marks the order as problematic and lists the items and the reason. Previously, such items silently disappeared from the Ozon order, although the buyer had paid for them.

If, before creating an Ozon order, the response indicated that delivery is not possible, the module no longer creates an order based on the calculation saved during checkout.

The Create order in Ozon button in the admin panel and the problematic order indicator show which items are missing in the delivery calculation and why, instead of the message Check the logs.

Version 4.4.9

An order in Ozon is created after payment and only when the order amount after a coupon or certificate discount results in fractions of a kopek (for example, 975.00000001). Previously, Bitrix considered such an order underpaid by 0.00000001 and did not send a payment event, so the order was not created in Ozon.

Ozon Logistics courier delivery: before placing an order, the module checks the delivery calculation for the selected address, just as for a pickup point. If Ozon does not deliver to this address, the buyer sees the reason and cannot place an order that would then fail to be created in Ozon.

The Create order in Ozon button in the admin panel shows the reason why Ozon cannot deliver the order, instead of the message Check logs.

The module is again removed from the Marketplace solutions list. Previously, the removal stopped with an error: Call to undefined method OzonBusinessPostingsTable::dropTable.

Version 4.4.8

Courier delivery: the courier's address (JSON) is now saved to the new order property Ozon Courier Delivery Address (JSON) (code IPAKOR_OZON_COURIER_DATA). The Ozon Pickup Point ID property (IPAKOR_MAP_POINT_ID_OZON) for courier orders remains empty; it stores only the pickup point number.

Attention: if your 1C or another system parses the courier JSON from the Ozon Pickup Point ID property: for new orders, take it from IPAKOR_OZON_COURIER_DATA. The address as a single line, as before, is in the Ozon Delivery Address property.

Orders placed before the update remain unchanged and are processed by the module as before

Version 4.4.7

Courier delivery: if Yandex does not know the postal code of the selected building (often the case with new constructions), the map takes the postal code of the nearest building within 150 meters. The postal code is immediately added to the order, and Ozon Delivery for Business creates the order without manual entry of the postal code

Version 4.4.6

Ozon Delivery for Business: courier orders to addresses without a postal code (Yandex does not know the code for all buildings) are no longer rejected by Ozon with the error 'The ZipCode field is required'. The code is taken from the order's index property or from the location if the settlement has only one index.

If the index cannot be determined, the 'Postal Code' field appears in the Ozon Delivery for Business order card: the manager enters it and creates the order manually. The index is saved in the order's delivery address.

Version 4.4.5

Hints for the Yandex Maps API key settings have been clarified: the key is recommended but not mandatory; without it, the module works using the built-in one; a typo has been fixed.

The term 'API' is used consistently in setting names instead of the Cyrillic spelling.

Version 4.4.4

Ozon Delivery for Business: courier orders to addresses without a street (village, settlement) are created; instead of a street, the name of the settlement is passed.

Version 4.4.3

The reason why Ozon Delivery for Business cannot deliver an order is displayed in red text in the delivery service block, without HTML tags.

The phone number verified on the map is linked to the customer: after logging out or logging in as a different user, the number is requested again.

Version 4.4.2

The pickup point, address, and phone number are saved with the order and included in the first export to 1C, including during real-time exchange.

After recording Ozon order numbers and linking to accounts, the order is placed back in the 1C export queue only if the values have changed.

The map loads its own copy of the Yandex Maps API: on the Courier tab, the address is determined even if other modules connect the API with a key without a geocoder (from version 4.4.1).

Version 4.4.0

Fixing vulnerabilities after security check

Version 4.3.2

Fixed error "Select a pickup point or delivery address for Ozon on the map" when placing an order with Ozon Delivery for Business, if the pickup point is already selected.

Version 4.3.1

In the order card of the Ozon Logistics section, the buyer's phone number used to create the order in Ozon is displayed. If the order does not contain a phone number (because it was placed before version 4.2.0), the number from the buyer's profile is shown with a note indicating that this is the number that will be sent to Ozon.

Version 4.3.0

A new property IPAKOR_OZON_DELIVERY_ADDRESS has been added to the order: a single-line delivery address containing the pickup point address with its name and number, or a courier address with apartment, entrance, and floor details. Previously, only the point number was stored in the order, and the address had to be looked up manually.

The address is displayed in the orders list and in the order card of the Ozon Logistics section.

For orders placed before the update, the address is restored from the point number upon the first opening of the order card.

Module service properties (point, calculation, Ozon order number, phone, and delivery address) are no longer saved to the buyer's profile and are not pre-filled for the next order. Their values are removed from profiles during the update.

For the accounting system, a new order property IPAKOR_OZON_ACCOUNTS has been added: a JSON object mapping each Ozon order to a specific account (seller's Client-Id).

Version 4.2.0

The availability of delivery by the buyer's phone number is checked when opening the card, not when entering the checkout page. If the phone number is missing or Ozon delivery is unavailable for that number, the buyer enters their number in the card window and clicks Check — the card opens only after successful verification. Previously, such buyers simply did not see the delivery service in the list.

When entering the checkout page, only the availability of cart items for Ozon delivery is checked.

The phone number used to arrange delivery is saved in the new order property IPAKOR_OZON_BUYER_PHONE. The order is created in Ozon using this number, so changing the phone number in the buyer's profile does not affect an already placed order.

Phone number verification also works for Ozon Delivery for Business.

Version 4.1.2

Ozon order numbers are recorded in the 'Shipment tracking number' order field.

Orders created earlier will receive a tracking number during the next status check.

Version 4.1.1

Fixed map functionality when the Yandex Maps API on the checkout page loads another module (e.g., CDEK delivery service) or template. Previously, the module reloaded the API every time the map was opened, causing pickup points on the map to become unclickable. Now, the module uses the already loaded API and loads its own only once if it is not present on the page.

If the Yandex Maps API is not loaded on the page and the 'Do not load Yandex Maps API script' option is enabled, the pickup points map would not open. This has been fixed.

Errors loading the Yandex map and geocoder are now displayed in the browser console with a hint to check the API key. If the map fails to load, the buyer sees a message instead of an empty window.

A solution for 'Search error' and 'Address determination error' on the Courier tab has been added to the Help and Support section: the Yandex Maps key must be issued for the JavaScript API and HTTP Geocoder services.

Version 4.1.0

Cancelled and unreceived items are moved to a separate shipment for the order, labeled "Ozon Refusal".

Unreceived items are defined as those from cancelled shipments, as well as for seller cabinets and partial refusals.

If the entire Ozon order is cancelled, the shipment is not split. If Ozon stops considering items as unreceived (for example, if the Ozon order is created anew), they are returned to the main shipment.

The module does not modify a processed shipment: if the refusal becomes known after processing, the order is marked as problematic with a list of unreceived items and shipment numbers; the manager performs the correction.

A new setting on the Order Statuses tab — "Move unreceived items to the Ozon Refusal shipment" — is enabled by default. When this setting is enabled, orders in the final status are checked until the end of the tracking period.

Version 4.0.0

Support for Ozon Delivery for Business — logistics delivery via Ozon without placing goods on the marketplace (Ozon Delivery API). Works independently of seller accounts: a store can have both connected.

Connecting the Ozon Delivery for Business account: simply insert the Client-Id and Client-Secret of a private application from the delivery account — unlike the seller account, there is no need to go to Ozon to confirm access; the module obtains and refreshes the token itself. The delivery method (pickup point) is automatically selected during connection testing.

Pickup points from the business account are stored in the module and updated in parts: synchronization via the Data Synchronization tab and via an agent; the map on the checkout page uses these points.

New delivery service Ozon Delivery for Business: the same pickup point map and courier delivery; cost and delivery time are calculated by Ozon based on order weight and dimensions; delivery availability for the buyer is verified by phone; settings for preliminary pricing, insurance, markups, and default dimensions.

Orders in Ozon are created after payment and are cancelled together with the website order; such orders are moved to a separate menu item Ozon Logistics → Orders (for Business) with their own card: confirmation for shipment, PDF label, status history, cancellation, returns, and return pickup barcode. Orders from seller accounts are in the Orders (for Sellers) item.

The buyer may refuse part of the order; calculation, order creation, statuses, and cancellation are handled per shipment.

Orders Status tab: separate mapping of Ozon Delivery for Business shipment statuses to order statuses and actions on the shipment.

Status tracking: if one of the accounts does not respond, the order with Ozon orders in multiple accounts is skipped until the next check — previously, the status could be calculated based on only some shipments, causing the order to be marked as Delivered prematurely.

Version 3.5.1

Ozon Logistics section, order card: the handover date to the buyer is displayed separately from the delivery date to the pickup point — typically several days pass between them when delivering to a pickup point.

The handover date is taken from the financial operation 'Delivery to buyer': Ozon does not provide it in the shipment itself.

Ozon Logistics section, order card: the date of the Bitrix order status change has been added — automatic actions on the order are calculated from this date.

Update is file-based only: delivery service settings, markups, connected accounts, and warehouse mappings are preserved; no database migrations are performed.

Version 3.5.0

Synchronization of Bitrix warehouse stock levels with Ozon FBS warehouses.

Stock deduction from the warehouse from which the product will actually be shipped.

Marking codes according to the FBS scheme.

Ozon Logistics section, order card: actual handover date has been added.

Ozon Logistics section, order card: return retrieval has been fixed.

Returns are displayed in full: return type is shown in Russian ('Cancellation (not picked up)', 'Partial refusal during handover', 'Return by buyer').

A 'Reason' column has been added: the return reason text in Ozon's wording — for example, 'Buyer refused during handover: product did not fit'.

PHP 8.2 support: module operation has been tested on PHP 8.2, 8.3, and 8.4; warnings during module file inclusion have been eliminated.

Update is compatible with existing installations: delivery service settings, markups, and connected accounts are preserved. For warehouse mappings, a table and a background agent for stock transfer are added — they are created automatically during the update; module reinstallation is not required.

Version 3.4.0

Delivery cost is now taken from the Ozon response. The delivery calculation method now returns the cost for each shipment, and the module displays this exact cost to the buyer instead of its own estimate based on universal tariffs. The calculation takes into account everything Ozon has calculated for the specific order: the selected pickup point or courier address, the cart composition, the FBO or FBS shipping scheme, and the distribution of goods across warehouses.

The previous tariff-based calculation is retained as a fallback and is automatically activated if no cost is provided by Ozon: the pickup point or address has not yet been selected, Ozon has not sent a shipment cost, the delivery option is unavailable, or the buyer has modified the cart after selecting a pickup point, making the saved calculation invalid for the new composition. In these cases, delivery is calculated and displayed as in previous versions.

Delivery service markups continue to work as before and are applied on top of the received cost: a fixed or percentage markup, plus a separate markup for courier delivery. Note: percentage markup is now calculated based on the actual Ozon delivery cost, so its value should be rechecked if it was previously tuned to the old tariff-based calculation.

Fixed: zero delivery cost. If the calculation results in free delivery, the price is no longer lost; the buyer sees zero or only the markup amount, not an empty field.

Only the Ozon response saved by the module on the website side is used for calculation, and its composition is verified against the buyer's cart; delivery cost cannot be altered from the checkout form.

The update is compatible with existing installations: the database structure remains unchanged, delivery service settings, markups, and connected accounts are preserved. The delivery service handler in /bitrix/php_interface/include/sale_delivery/ozon/ is automatically updated upon installation of the update.

Version 3.3.0

Fixed: API access extension for Ozon. Ozon sends a new refresh_token not with every token update, but the module was always writing it — an empty value overwrote the working refresh_token, and after some time the account had to be re-authorized. Now the refresh_token is overwritten only if Ozon returns it, and the lifetime and scope of the new token are taken correctly from the response.

Fixed: a stuck "token update in progress" flag. This flag protects against simultaneous token updates by multiple processes, but no one could remove it if the process was interrupted — PHP crash, worker restart, process termination due to timeout — or if the account token string disappeared during the update. After that, every request to Ozon waited ten seconds for another update and failed until the flag was manually removed from the database. Now the flag is removed in any outcome of the update, and a definitely abandoned lock (older than two minutes — four times longer than the longest live update) is taken by the next process, which updates the token itself.

Additionally, a race condition when acquiring this lock was fixed: the check and setting of the flag are performed in a single conditional query, so two processes that started updating simultaneously no longer both go to Ozon — the second waits for the result of the first.

Fixed: failed account authorization by code (incorrect client_secret, expired authorization code, error on Ozon's side) was displayed as successful, although the token was not saved. Now the module reports an error, and the details of Ozon's response are written to the log.

"Ozon Logistics" section, order card: the button to create an order in Ozon is shown as long as the order has not been created in all accounts involved in the calculation. Previously, it disappeared as soon as at least one Ozon order appeared — if there was a failure in one account and after canceling the order in that account, re-creating it from the admin panel was impossible. Accounts with an already created and not canceled order are skipped, and duplicates do not occur.

The update is compatible with existing installations: the database structure remains unchanged, settings and connected accounts are preserved. Sellers with a single Ozon account will experience the same behavior as before.

Version 3.2.0

New: "Chestny ZNAK" (Honest Sign) marking codes from Ozon. For marked goods, Ozon provides the codes of the specific instances it selected at the warehouse and issued to the buyer; the module records them in the standard Bitrix field "Marking Code" for the order shipment items. Subsequently, Bitrix automatically inserts the code into the fiscal receipt, and the fiscal data operator removes it from circulation.

Codes are requested by the same agent that retrieves order statuses. On the "Order Statuses" tab, a checkbox "Receive marking codes from Ozon" has been added, along with a "Marking" column in the mapping table: this column indicates the shipment statuses in which codes should be requested. Codes are written before any action on the shipment; otherwise, Bitrix will not allow the shipment to be processed.

In the order card of the "Ozon Logistics" section, a "Write Marking Codes" button has been added for one-time requests for a specific order, and a column with received codes has been added to the shipments list.

The request for codes for FBS shipments has been moved to a separate setting and is disabled by default: with FBS, the seller selects and transfers the instances to Ozon themselves, so there are no codes to return from Ozon.

Also in this update (changes from version 3.1.0):

Fixed: An order was not created in Ozon if several hours passed between order placement and payment. The delivery calculation obtained at the time of order placement is valid for a limited period in Ozon; its time intervals stopped being accepted, causing order creation to fail with a "bad request" error without details. Now, before creating an order, the module automatically requests a new calculation using the same pickup point or address and the same order composition, and creates the order based on the current data. Orders paid the next day, or after cancellation and re-payment, or with payment system delays, are now created normally. If the recalculation fails, the reason is logged, and the module attempts to create the order using the calculation saved at the time of order placement.

Fixed: If the buyer's full name (First Name, Last Name, Patronymic) was received from a single order property, the first and last names were swapped when sent to Ozon. The value is now parsed in the order 'Last Name First Name Patronymic'; the variant with separate properties for first name, last name, and patronymic continues to work as before.

Fixed: Kopecks in the product price were incorrectly transmitted to Ozon. In the price parameter, the 'nanos' field represents billionths of a ruble, but the module was sending kopecks in it, causing the product price in the Ozon order to be rounded to the nearest ruble. This error did not manifest for products with whole-number prices.

The update is compatible with existing installations: the database structure remains unchanged, and current settings are preserved. The default retrieval of marking codes is disabled; to use it, enable it on the 'Order Statuses' tab and ensure that the marking code group is filled for products on the website.

If you are updating from version 2.2.3, changes from version 3.0.x are also applied with this update: support for multiple Ozon seller accounts, the 'Ozon Logistics' section accounting for the account, and actions on shipments on the 'Order Statuses' tab.

Version 3.0.1

Added support for multiple Ozon seller accounts. Accounts are added on the "Ozon API Main Settings" tab; each has its own Client-Id, Client-Secret, scopes, authorization, and token. For each account, you can specify a name, whether it is the primary account, activity status, delivery scheme (FBO/FBS/MIX), and processing order.

Catalog synchronization is performed separately for each account, both via the agent and during manual import on the "Data Synchronization" tab. The "Product Visibility" section now includes a column and filter for the account.

Orders on the site are distributed across accounts: delivery calculation is performed in each account containing items in the cart, and after payment, a separate Ozon order is created in each of them. If a product exists in multiple accounts, the one capable of shipping it is selected; in case of a tie, the account with the lower sort order is chosen.

The Ozon order numbers created are recorded in the IPAKOR_OZON_ORDER_NUMBER order property, separated by commas. Cancelling an order on the site cancels the corresponding Ozon order in each account where it was created, and re-creation after a failure does not generate duplicates.

Status synchronization and the "Ozon Logistics" section account for the account: shipments are requested in each account of the order using its own token; the order list and card display Ozon order numbers along with the account name and separate cancellation buttons.

If at least one cart item is not sold in any connected account, Ozon delivery is not shown to the buyer; partial shipment is not supported.

On the "Order Statuses" tab, for each Ozon status, you can define an action for the shipment: "Allow Delivery", "Ship (deduct from stock)", or "Cancel Shipment (return to stock)". The action applies only to the Ozon delivery service shipment and is configured independently of the order status.

Changed: shipment is no longer automatically set to "allowed and shipped" upon Ozon order creation; shipment status is now managed via settings on the "Order Statuses" tab.

The FAQ tab has been supplemented with sections on multiple accounts and Ozon orders.

Fixed: the update to version 3.0.0 was interrupted with the error «Class ... MultiAccountMigration not found» — the update script attempted to access module classes before the version files were copied to the site. As a result, the module files were not replaced, leaving the site on the previous version.

The update is compatible with existing installations: parameters for a single account are automatically migrated, and while only one account is connected, the module continues to function as before.

Version 2.2.3

Fixed: on some installations the module failed to connect with the error 'syntax error, unexpected token opening angle bracket' in include.php. The module entry point is now closed with a PHP tag again, and comments within it are block-style, so the file remains valid after processing during solution assembly. Affected installations are versions 2.2.0 through 2.2.2.

Version 2.2.2

Fixed: status synchronization could stop order export to 1C. Changing a status marks the order as modified, and it enters the next export batch — as with any order change. The agent converted up to 200 orders per run to the new status, including long-closed ones, and such a batch caused the order export step (type=sale, mode=query) to exceed the web server timeout, while the incomplete exchange rebuilt the same selection on each attempt.

Added the setting "Maximum status changes per run" on the "Order statuses" tab, defaulting to 30 orders. The remainder is processed in subsequent agent runs, so orders go to 1C export evenly. Statuses still reach 1C in full volume.

The default order check depth was reduced from 90 to 30 days; the first agent run after installation is delayed by one interval. For sites where the depth is already set in settings, the value remains unchanged.

Migration of integration secrets when connecting the module can no longer interrupt another request: an error is written to the log, and the attempt is retried on the next module connection.

Version 2.2.1

Fixed an error during module installation

Version 2.2.0

Added mapping between Ozon order statuses and Bitrix order statuses: a new settings tab "Order statuses" where for each Ozon delivery state, the corresponding order status on the site is selected. Empty rows are skipped — the order remains in its current status.

Added the SyncOrderStatusesAgent agent: it periodically requests shipments of orders in Ozon (FBO and FBS), aggregates them into a final state, and updates the order on the site to the mapped status. The launch interval and the depth of order checking in days are configurable; there is a one-time launch button "Synchronize now".

Orders with multiple shipments in different states receive composite statuses: "Partially at pickup point", "Partially being delivered", "Partially delivered".

Ozon shipment status names have been moved to a single module reference book and are used on the order list and detailed view pages.

Security: all module service AJAX actions (data synchronization, product visibility, API check, authorization link retrieval) and administrative section pages now require module permissions — previously, any site authorization was sufficient. Module permissions can be assigned to user groups.

Security: client-secret and Ozon access tokens are encrypted before being saved to the database; values saved by previous versions are automatically re-encrypted upon the module's first connection.

Security: data of the selected pickup point is escaped before being displayed on the checkout page, and the delivery calculation response received from the form is verified against the cart contents before creating an order in Ozon.

Security: the size of the pickup point (PVZ) selection sample has been limited, and pickup point data caching has been added — anonymous requests are no longer proxied to the Ozon API one-to-one.

Fixed a typo in the logger factory that caused a fatal error when selecting a custom PSR-3 logger without specifying a class.

Version 2.1.0

Added product visibility management on the Ozon showcase: a new administration page "Product Visibility" (module menu item) with mass application of visibility (OZON / SELECT / OZON_SELECT / NONE) via the /v1/product/visibility/set API.

The page displays the actual product sales status in Ozon (from /v3/product/info/list, including reasons for hiding) and the last placement applied via the admin panel with the application date.

Fixed an error in install/index.php that caused module updates to loop: the version.php file was duplicated in the module root, and the class constructor connected to it instead of install/version.php. Now there is only one version.php file in the install folder; the duplicate in the module root is automatically deleted during updates.

Version 2.0.0

Ozon courier delivery has been added: a new delivery type with its own cost calculation and separate markup settings (fixed amount or percentage).

The "Ozon Logistics" section has been added to the administrative panel menu, featuring a list of orders and a detailed page for each order (status, shipments, tracking).

Ozon order cancellation and cancellation of individual shipments have been added from the administrative panel.

Recreation of an Ozon order from the administrative panel has been added.

The setting to allow changing the buyer's full name in Ozon orders has been moved to a separate module parameters block.

Version 1.2.0

The delivery cost calculation has been fixed to account for the delivery scheme: FBO — each item unit is a separate shipment; FBS — all units of one item form a single shipment; MIX — the scheme is determined by the availability of FBS/FBO stock for each item (FBS takes priority).

Previously unaccounted Ozon Delivery expense items have been added: delivery to partner pickup points (up to 25 ₽) and item pickup at a partner pickup point (30 ₽ per unit, tariff effective from 04.06.2026).

Universal logistics tariffs have been updated (the table is current as of 01.06.2026); overlapping range boundaries in the volume table from the previous version have been corrected.