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

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

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

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

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

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

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

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

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

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

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

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

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

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

On September 23, the update history for the 1C-Bitrix Marketplace added a fix for the Ozon delivery module: the plan_bound_missing error could occur after applying bonuses, discounts, or final rounding. The change description includes a critical detail: price is no longer used as an identifier for physical packaging; instead, the cost of each package 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.

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 bundles, 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 a shipping unit, a change of a few rubles or even kopecks can break the link between products, packaging, 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 packaging units, and only then send the data to an external service. Recalculation on the integration side must not create a new version of the order that differs from what the buyer and manager see.

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 a discount with paid delivery, and an order with multiple packages. A separate case is needed where a fractional amount arises after distribution, requiring rounding to kopecks.

It is useful to compare four values: the cart total before checkout, the saved order total, the sum of goods transferred to delivery, and the total monetary value of shipping units in the delivery service response. They must align according to a pre-defined rule. If one system rounds each item while another rounds only the total, the discrepancy must be accounted for explicitly, not hidden by randomly adjusting the last item.

Repeated actions must also be tested. An order may be recalculated after a change in address, delivery method, cart composition, or buyer profile. The integration must either regenerate valid shipping units—packages for shipment—or display a clear reason for refusal. An old delivery request must not silently remain attached to the new version of the order.

Re-verifying a phone number after another user logs in prevents a critical class of errors. On a shared computer, at a manager's checkout, or after an account switch, the previous customer'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 placing an order. Data confirmed in one session cannot be assumed valid for another user without verifying ownership.

Before installing a new module version, 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. The test must proceed to creating a shipment request with the carrier, not stop at the 'Order Placed' page.

After updating, review the integration log to ensure it can link the order, calculation attempt, generated packages, 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 is tested as a single process. If each module is tested separately, the store might successfully calculate a discount and independently obtain a shipping rate, yet still lose the order during the transfer of final totals. Such integration points require more attention than the list of features in a solution card.