В корзине доставка стоит одну сумму, после выбора пункта выдачи — другую, а менеджер видит третью. Сначала сопоставьте один и тот же маршрут, состав отправления и тариф на трёх этапах: запрос магазина, ответ службы доставки, сумма для покупателя. Затем меняйте по одному параметру: так можно отделить ошибку данных от надбавки магазина или устаревшего расчёта.
Кому это актуально и какие риски закрывает проверка
Разбор предназначен руководителю интернет-магазина и разработчику, если неверная стоимость появляется ещё до оплаты. Он помогает подготовить проверяемую задачу: какой набор входных данных даёт расхождение и на каком шаге оно возникает. Заниженная стоимость может оставить расходы магазину, завышенная — помешать покупке.
Если сумма на сайте верна, но меняется после передачи заказа в учётную систему, нужен другой маршрут — проверка обмена 1С и Битрикс. Если заказ вообще исчезает, полезнее начать с локализации ошибок OpenCart. Ни один из этих симптомов сам по себе не доказывает неисправность тарифа.
Где именно расходится стоимость
Для одного контрольного сценария заведите три строки протокола:
- Запрос: откуда и куда везём, способ доставки, тариф, количество мест, вес и размеры упаковок, дополнительные услуги.
- Ответ: время расчёта, возвращённая стоимость и ошибка, если она есть.
- Витрина: надбавка или скидка магазина, округление и конечная сумма после выбора доставки.
Для исходного сравнения используйте одинаковые условия и согласованный источник тарифа: например, расчёт по тому же договору перевозчика. Розничный калькулятор и договорная цена могут отвечать на разные вопросы. Число на скриншоте без параметров не годится как эталон.
Если запрос уже содержит неверный вес, проверяйте путь данных из каталога. Если ответ корректен, а витрина показывает другое, исследуйте правила магазина и обработку результата. Если различаются тарифы или дополнительные услуги, сначала устраните несопоставимость условий.
Проверяйте на тестовой копии с отключёнными отправками писем, оплатами и созданием накладных. Для сверки стоимости не требуется настоящий платёж или вызов курьера. В протоколе не нужны имя, телефон и домашний адрес покупателя: используйте согласованные тестовые данные.
Пять гипотез, которые можно проверить отдельно
1. Выбран другой населённый пункт или пункт выдачи
Сверьте не только видимый текст адреса, но и идентификатор города или пункта выдачи, отправленный модулем. Проверьте город отправления и склад. Затем на копии смените населённый пункт и вернитесь к исходному: параметры запроса должны вернуться вместе с ним.
Гипотеза подтверждается, если при одинаковом видимом выборе в запрос уходит другой идентификатор либо прежний адрес. Исправление принимают по совпадению выбора пользователя и фактических параметров расчёта.
2. Подставляется вес по умолчанию
Сравните свойства конкретного торгового предложения, единицы измерения и количество товара с запросом доставки. Значение в карточке ещё не доказывает, что модуль получил его без преобразований.
Например, в официальном описании интеграции СДЭК с InSales предусмотрена подстановка настроек по умолчанию, когда у товара нет веса или габаритов. Это особенность описанного приложения; для другого модуля поведение нужно подтвердить в его документации.
Если товары с пустыми свойствами дают одинаковые входные параметры, проверьте такую подстановку. Критерий исправления — согласованные значения каждого контрольного отправления, а не просто изменившаяся цена.
3. Размеры товара приняты за размеры отправления
Попросите показать, как из состава корзины получаются упаковки: одно место или несколько, какие размеры и масса передаются. Не переносите формулу объёмного веса или способ укладки из чужой инструкции: правила зависят от перевозчика, тарифа и модуля.
Сравните компактный товар и лёгкий объёмный товар. Если в запросе у обоих одна упаковка из настроек, это проверяемый след. Подтверждением станет корректное описание мест по согласованному правилу упаковки, а не произвольное увеличение массы до «правильной цены».
4. Смешаны тариф перевозчика и правила магазина
Разложите итог на отдельные составляющие: ответ перевозчика, сбор магазина, субсидия или бесплатная доставка, округление. Сверьте выбранный режим: до двери и до пункта выдачи должны сравниваться каждый со своим эталоном.
У интеграции СДЭК с InSales, например, описаны отдельные настройки бесплатной доставки, увеличения стоимости и округления. Наличие подобных функций у вашего модуля устанавливают отдельно. Если расхождение исчезло после исключения надбавки на стенде, это ещё не повод убрать её в рабочем магазине: правило могло быть согласовано бизнесом.
5. После изменения корзины остаётся прежний результат
На копии по очереди меняйте количество, адрес, пункт выдачи и способ доставки. Запишите, был ли новый запрос и какой ответ отображён. Отдельно проверьте быстрые изменения адреса: поздний ответ для старого выбора не должен подменять актуальный.
Цена не обязана меняться при каждом действии: несколько вариантов могут попадать в один тарифный диапазон. Проверяйте обновление входных данных и соответствие показанного результата текущему выбору. При недоступном расчёте интерфейс должен отличать отсутствие цены от бесплатной доставки.
Контрольные корзины для приёмки
Ниже учебная матрица, а не реальные заказы или тарифы. Все сравнения проводят в одном согласованном тестовом окружении.
| Проверка | Что изменяем | Какой результат принимаем |
|---|---|---|
| Базовый расчёт | Один товар с заполненными свойствами | Запрос, ответ и итог объясняются одним набором правил |
| Количество | Одну единицу заменяем двумя | Количество и параметры мест пересчитаны по правилу упаковки |
| Габариты | Компактный товар заменяем объёмным | В запрос переданы свойства нового отправления |
| Зона и доставка | Меняем город и отдельно пункт выдачи | Расчёт соответствует выбранным идентификаторам и тарифу |
| Пустые свойства | Убираем вес у тестового товара | Срабатывает согласованная подстановка или понятная ошибка |
| Бесплатная доставка | Проверяем ниже, на границе и выше порога | Условие работает по согласованной сумме с учётом скидок |
| Недоступный сервис | На стенде моделируем отсутствие ответа | Нет ложного нуля или молчаливого показа устаревшей цены |
В отдельном учебном сценарии товар имеет массу 1 кг, а две единицы весят 2 кг без упаковки. Эти числа проверяют количество и единицы измерения; они не задают массу готового отправления и не предсказывают цену. Если ответ перевозчика изменился, а витрина сохранила старый итог, локализован участок после ответа — конкретную причину устанавливают дальше.
После исправления повторите исходный сбой и соседние строки матрицы. В разрешённом тестовом сценарии проверьте также сохранённую сумму заказа: она должна соответствовать принятому расчёту. Заранее определите, когда цена предварительная, когда окончательная и что происходит при изменении корзины.
Что запросить у подрядчика и где заканчивается самостоятельная проверка
Попросите результат, который можно перепроверить:
- Обезличенный пример расхождения с исходными параметрами и временем.
- Первую границу, где данные становятся неверными.
- Объяснение правила упаковки, источника тарифа и модификации цены.
- Список затрагиваемых настроек и кода, способ возврата изменения.
- Протокол контрольных корзин до и после исправления.
Владелец может сверить карточки товаров, доступные настройки и согласованное правило бесплатной доставки. Если настройка понятна и команда умеет проверить её на копии, отдельная разработка может не понадобиться.
Изменения обработки ответов, кеширования и упаковки лучше поручить разработчику, особенно когда несколько модулей меняют итог заказа. Не маскируйте расхождение постоянной ручной скидкой: она не объясняет причину и может испортить другие направления. Ручная оценка уместна как явно обозначенный предварительный расчёт с подтверждением до оплаты, если магазин действительно поддерживает такой процесс.
Как это решает OpenStart
Для нестандартного расчёта или ошибки интеграции у OpenStart есть услуга доработки сайта. Первый этап разумно ограничить одним воспроизводимым сценарием и согласованным результатом: локализовать расхождение, определить объём исправления и критерии проверки. Это предложение формата задачи, а не обещание заранее известной причины, цены или срока.
Если своей команде не удаётся найти границу ошибки, опишите задачу на доработку: приложите обезличенные параметры одной корзины, ожидаемый итог и фактический результат. Следующий шаг — уточнить задачу и согласовать состав и стоимость первого этапа; пароли и данные покупателей в описание не включайте.
Частые вопросы
Почему калькулятор перевозчика показывает другую сумму?
Сначала сравните договор, тариф, направление, места и дополнительные услуги. При разных условиях суммы нельзя использовать для доказательства ошибки. Если условия совпадают, сопоставьте ответ перевозчика с дальнейшими правилами магазина.
Можно ли поставить фиксированную доставку до исправления?
Только как согласованное правило с понятными ограничениями по зоне и отправлению. Оно меняет предложение магазина и не подтверждает исправность интеграции. Условия и итог должны быть понятны покупателю до оплаты.
Достаточно ли проверить один успешный заказ?
Он подтверждает лишь одно сочетание параметров. Для приёмки нужны исходный сбой, соседние граничные условия и сценарий недоступного расчёта. Матрицу сокращают под реально используемые тарифы, сохраняя проблемный вариант.
Как передать пример без данных покупателя?
Воспроизведите его с тестовой корзиной и согласованными адресными идентификаторами. Передавайте только необходимые параметры расчёта и обезличенный результат; удалите из журналов контакты, токены и cookies.
Описание возможностей конкретного приложения сверено по официальной документации интеграции СДЭК с InSales 16 октября 2026 года. Правила и названия настроек других модулей могут отличаться.