Замена службы доставки в магазине: что перепроверить помимо названия интеграции

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

Сначала перечислите существующие точки интеграции

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

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

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

Проверьте поддерживаемые способы получения

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

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

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

Адресные поля должны соответствовать выбранному способу

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

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

Проверьте ручной ввод, выбор из подсказки и возврат к предыдущему адресу. Формат местоположения в CMS и в модуле может различаться. Сопоставление должно быть документировано и не опираться на совпадение одного короткого названия города.

Расчёт стоимости и итог заказа

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

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

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

Оплата может зависеть от доставки

Некоторые способы оплаты доступны не со всеми вариантами получения. Документация 1С-Битрикс описывает ограничения и связи доставки с параметрами заказа. При замене проверьте фактическую матрицу магазина. Ранее выбранный платёжный способ не должен оставаться активным, если новая доставка его не допускает.

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

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

Сохраните выбранные данные в заказе

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

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

Если заказ передаётся в 1С или CRM, обновите согласованное сопоставление службы. Не переносите внутренний ID старого обработчика под новый текст. Название и код должны описывать одну сущность. Проверка обмена проводится на ограниченном учебном заказе.

Создание отправления и повтор

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

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

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

Письма, кабинет и административный экран

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

Проверьте кабинет покупателя: понятны ли способ получения, адрес и статус. Внутренний статус коннектора не всегда подходит для публичной подписи. Сотрудник должен видеть диагностические сведения отдельно, не раскрывая технические ошибки или служебные коды посетителю.

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

План возврата и старые заказы

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

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

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

Критерии завершения

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

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

Учебная матрица смены службы

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

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

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

Как проверить новый модуль без реального отправления

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

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

Для скриншота достаточно учебного адреса и нейтральной корзины. Рабочие данные получателя, накладные и закрытые условия договора не нужны. Если требуется показать реальный экран модуля, сначала проверяют его версию и возможность открыть учебное состояние.

Возврат после неудачного выпуска

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

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

Связанные разборы

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

Вопросы по теме

Достаточно ли поменять название службы?

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

Нужно ли переносить старые заказы на новую службу?

Не автоматически. История и незавершённые отправления требуют отдельного согласованного порядка.

Документация и источники

• 1С-Битрикс: службы доставки: Условия, местоположения и ограничения доставки связаны с параметрами заказа.
• 1С-Битрикс: объекты интернет-магазина: Заказ, оплата и отгрузка имеют отдельные роли; бонусный договор статьи не объявлен штатной функцией.