Discount Changed the Total — and Delivery Broke: What Ozon Updates for 1C-Bitrix Teach Us

23 сентября в истории обновлений Маркетплейса 1С-Битрикс появилось исправление для модуля доставки Ozon: ошибка plan_bound_missing могла возникать после применения бонусов, скидок или финального округления. В описании изменения есть важная деталь — цена больше не используется как идентификатор физической упаковки, а стоимость каждого места пересчитывается из окончательных цен уже сохранённого заказа без потери копеек.

На следующий день другой модуль интеграции с Ozon уточнил вывод причины, по которой заказ нельзя доставить, и изменил работу с подтверждённым телефоном: номер привязывается к конкретному покупателю и должен запрашиваться заново после смены пользователя. Это не одна общая ошибка и не обновление самой платформы 1С-Битрикс. Но два соседних изменения хорошо показывают, насколько чувствительной становится доставка к данным заказа и состоянию пользовательской сессии.

Почему скидка способна сломать доставку

В простом магазине стоимость позиции кажется одним числом. В рабочем интернет-магазине у неё несколько состояний: базовая цена, цена типа плательщика, скидка каталога, купон, бонусы, округление, распределение стоимости по комплектам и окончательная сумма в заказе. Служба доставки получает данные уже после части этих преобразований.

Проблема начинается, когда интеграция использует денежное значение не только как сумму, но и как технический признак. До скидки две сущности совпадают, после скидки — уже нет. Если цена служила косвенным идентификатором упаковки, изменение на несколько рублей или даже копеек может разрушить связь между товарами, местами и расчётом доставки.

Надёжнее считать сохранённый заказ источником истины. Сначала магазин должен окончательно применить скидки, бонусы и округление, затем распределить стоимость между местами и только после этого отправлять данные внешнему сервису. Повторный расчёт на стороне интеграции не должен создавать новую версию заказа, отличающуюся от той, которую видят покупатель и менеджер.

Что проверить владельцу магазина

Одного заказа без скидки для проверки недостаточно. Минимальный набор сценариев должен включать обычную скидку каталога, промокод, списание бонусов, сочетание скидки с платной доставкой и заказ с несколькими упаковками. Отдельно нужен случай, где после распределения возникает дробная сумма и требуется округление до копеек.

Полезно сравнить четыре значения: сумму в корзине перед оформлением, итог сохранённого заказа, сумму переданных в доставку товаров и сумму мест в ответе службы доставки. Они должны сходиться по заранее определённому правилу. Если одна система округляет каждую позицию, а другая — только общий итог, расхождение следует учитывать явно, а не скрывать случайной корректировкой последнего товара.

Нужно проверить и повторные действия. Заказ может быть пересчитан после смены адреса, способа доставки, состава корзины или профиля покупателя. Интеграция обязана либо заново сформировать корректные места, либо показать понятную причину отказа. Старая заявка на доставку не должна незаметно оставаться привязанной к новой версии заказа.

Телефон и пользовательская сессия — часть той же цепочки

Изменение с повторной проверкой телефона после входа другого пользователя выглядит небольшим, но закрывает неприятный класс ошибок. На общем компьютере, в пункте оформления менеджером или после смены аккаунта номер предыдущего покупателя не должен автоматически становиться контактом нового заказа.

Для магазина это означает, что тестировать следует не только поля формы, но и переходы между состояниями: выйти из одного аккаунта, войти в другой, выбрать сохранённый адрес, вернуться в корзину и оформить заказ. Данные, подтверждённые в одной сессии, нельзя считать подходящими для другого пользователя без проверки принадлежности.

Как обновляться без новых сбоев

Перед установкой новой версии модуля нужна резервная копия базы и файлов, но этого мало. Обновление стоит сначала поставить на копию сайта и прогнать контрольные заказы с реальными правилами скидок. В тесте важно дойти до создания заявки у перевозчика, а не остановиться на странице «Заказ оформлен».

После обновления следует посмотреть журнал интеграции и убедиться, что там можно связать заказ, попытку расчёта, сформированные места и ответ внешнего сервиса. Покупателю полезно показывать понятное сообщение, а техническую причину сохранять для администратора. Выводить необработанный ответ API в публичную часть нельзя: он может содержать лишние данные или фрагменты разметки.

Связка скидок, бонусов и доставки проверяется как единый процесс. Если каждый модуль тестировать отдельно, магазин может успешно посчитать скидку и отдельно успешно получить тариф, но всё равно потерять заказ в момент передачи окончательных сумм. Именно такие стыки требуют больше внимания, чем перечень функций в карточке решения.

On September 23, the 1C-Bitrix Marketplace update history recorded a fix for the Ozon delivery module: the plan_bound_missing error could occur after applying bonuses, discounts, or final rounding. A key detail in the change description is that price is no longer used as an identifier for physical packaging; instead, the cost of each unit is recalculated from the final prices of the already saved order without losing kopecks.

The next day, another Ozon integration module clarified the reason why an order cannot be delivered and changed how confirmed phone numbers are handled: the number is tied to a specific buyer and must be requested again after a user switch. This is not a single general error, nor is it an update to the 1C-Bitrix platform itself. However, these two adjacent changes clearly demonstrate how sensitive delivery has become to order data and the state of the user session.

Why a Discount Can Break Delivery

In a simple store, an item's cost appears as a single number. In a working online store, it has multiple states: base price, payer-type price, catalog discount, coupon, bonuses, rounding, cost allocation across sets, and the final order total. The delivery service receives data after some of these transformations have already occurred.

The problem arises when an integration uses a monetary value not only as a sum but also as a technical flag. Before the discount, two entities match; after the discount, they no longer do. If the price served as an indirect identifier for packaging, a change of a few rubles or even kopecks can break the link between products, locations, and delivery calculations.

It is more reliable to treat the saved order as the source of truth. First, the store must fully apply discounts, bonuses, and rounding, then allocate the cost across locations, and only then send the data to an external service. A recalculation on the integration side must not create a new version of the order that differs from what the buyer and manager see.

What the store owner should check

A single order without a discount is insufficient for testing. The minimum set of scenarios must include a standard catalog discount, a promo code, bonus deduction, a combination of discount with paid delivery, and an order with multiple packages. A separate case is needed where distribution results in a fractional amount requiring rounding to kopecks.

It is useful to compare four values: the cart total before checkout, the saved order total, the sum of items sent for delivery, and the number of units in the delivery service response. These must align according to a predefined rule. If one system rounds each line item while another rounds only the grand total, the discrepancy must be handled explicitly rather than hidden by arbitrarily adjusting the last item.

You must also verify repeat actions. An order may be recalculated after a change in address, delivery method, cart contents, or buyer profile. The integration must either regenerate valid units or display a clear reason for rejection. An old delivery request must not silently remain linked to the new version of the order.

Phone number and user session are part of the same chain

Changing the phone number and revalidating it after another user logs in may seem minor, but it closes a class of unpleasant errors. On a shared computer, at a checkout counter managed by staff, or after an account switch, the previous buyer's number must not automatically become the contact for the new order.

For the store, this means testing not only form fields but also transitions between states: logging out of one account, logging into another, selecting a saved address, returning to the cart, and completing the order. Data confirmed in one session cannot be considered valid for another user without verifying ownership.

How to update without new failures

Before installing a new version of the module, you need a backup of the database and files, but that is not enough. First, apply the update to a site copy and run test orders with real discount rules. In testing, it is critical to reach the stage of creating a shipment request with the carrier, not stopping at the 'Order Completed' page.

After the update, review the integration log to ensure it can link the order, the calculation attempt, the generated shipment slots, and the external service response. It is helpful to show the customer a clear message while saving the technical reason for the administrator. Never display an unprocessed API response in the public area: it may contain extraneous data or markup fragments.

The combination of discounts, bonuses, and delivery must be tested as a single process. If each module is tested separately, the store might successfully calculate a discount and separately obtain a rate, yet still lose the order during the transfer of final totals. Such integration points require more attention than the list of features in the solution card.