[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f1nol2rpwipd61":3},{"slug":4,"title":5,"published":6,"publishedAt":7,"createdAt":8,"section":9,"preview":10,"heroImage":11,"previewImage":11,"headMarkup":12,"lifecycleId":13,"bodyMd":14,"bodyHtml":15},"integratsiya-internet-magazina-so-sluzhbami-dostavki-statusy-tarify-i-tochki-vydachi","Интеграция интернет-магазина со службами доставки",true,"2024-05-06T10:00:00+03:00","2026-09-06T16:09:04.398Z","Статьи","Материал о настройке обмена между интернет-магазином и службами доставки. Рассмотрены данные заказа, статусы, расчёт доставки и обработка ошибок.","\u002Fcontent-media\u002Farticles\u002Fintegratsiya-internet-magazina-so-sluzhbami-dostavki-statusy-tarify-i-tochki-vydachi\u002Fassets\u002Fcb8a85cb8280.webp",[],"lc_c45da4cd1b0f3b711bd0eeed2585c082","Покупатель оформляет заказ, выбирает пункт выдачи и ждёт уведомления. Если сайт показывает только «заказ передан в доставку», оператору трудно понять, где находится отправление: на сортировке, в пути или уже доступно к получению.\n\nИнтеграция интернет-магазина со службами доставки связывает сайт с внешней системой обмена. Сайт передаёт сведения о заказе и получателе, получает условия доставки, статусы и данные пунктов выдачи. До разработки заказчик описывает путь заказа: от выбора способа получения до вручения, отмены или возврата.\n\n## Какие данные передаёт интернет-магазин службе доставки\n\nНабор данных зависит от сценария. Для курьерской доставки могут потребоваться контакты получателя, адрес, состав заказа и параметры отправления. Для пункта выдачи добавляется идентификатор выбранной точки. Если в проекте предусмотрена оплата при получении, правила её обработки согласуют отдельно.\n\nПоля с похожими названиями не всегда совпадают по структуре. Адрес на сайте может храниться одной строкой, а внешняя система ожидать город, улицу, дом, корпус и квартиру по отдельности. Такая же проверка нужна для телефона, комментария к доставке, веса, габаритов и состава вложения.\n\nЗаказчик фиксирует в требованиях:\n\n- какие поля сайт отправляет при создании отправления;\n- на каком этапе заказ передают в доставку;\n- какие данные внешний сервис возвращает на сайт;\n- может ли сотрудник изменить адрес или способ получения после оформления;\n- как обрабатываются отмена заказа, частичная отмена и возврат;\n- кто разбирает ошибку, если внешняя система не приняла заявку.\n\nЕсли магазин работает на «1С-Битрикс: Управление сайтом», интеграция затрагивает заказ, каталог и интерфейс сайта. Внутренний порядок работы сотрудников описывают отдельным документом, чтобы не смешивать его с обменом между сайтом и службой доставки.\n\n## Расчёт доставки в корзине и при оформлении заказа\n\nДо оформления заказа сайт может запросить доступные варианты доставки для текущей корзины. На ответ влияют город, адрес или пункт выдачи, состав заказа, вес, габариты, объявленная ценность и другие параметры, предусмотренные проектом.\n\nПока покупатель не указал адрес или не выбрал пункт выдачи, данных для запроса может не хватать. Заказчик и разработчик заранее согласуют поведение интерфейса: показывать предварительный вариант, предложить выбрать город или не выводить результат до заполнения нужных полей.\n\nРасчёт при выборе доставки и создание отправления могут дать разные результаты. В требованиях нужно определить, какой ответ сайт считает актуальным и что происходит, если после изменения корзины выбранный способ перестал быть доступен.\n\nПеред разработкой подрядчик уточняет обязательные параметры расчёта, обработку товаров без веса или габаритов, использование данных упаковки и порядок записи ошибок внешнего ответа. Это помогает избежать ситуации, когда сайт показывает вариант доставки, который не удаётся подтвердить при создании отправления.\n\n## Статусы заказа и отслеживание отправления\n\nСтатус заказа на сайте и статус перевозки описывают разные события. Заказ может быть подтверждён, но ещё не передан службе доставки. Отправление может находиться в пути, ожидать получения, быть вручённым, отменённым или возвращаться отправителю.\n\nДля обмена составляют таблицу соответствий: внешнее событие, статус на сайте, текст для покупателя и действие сотрудника. Технические обозначения сохраняют для диагностики, а в личном кабинете выводят понятное описание состояния отправления.\n\nОбновления можно получать регулярными запросами к внешней системе или через её уведомления. Разработчик обрабатывает задержки, повторную доставку одного события и временную недоступность сервиса. Запоздалый ответ не должен менять статус назад, если такой переход не предусмотрен сценарием.\n\nВ интерфейсе обычно достаточно состояний: отправление создано, передано перевозчику, находится в пути, доступно к получению, вручено, возникла проблема. Формулировки и переходы зависят от данных подключаемой службы доставки.\n\n## Пункты выдачи заказов на карте и в списке\n\nВыбор пункта выдачи требует не только карты с метками. Покупателю нужны сведения о расположении точки и её доступности для выбранного заказа. Данные могут меняться: пункт закрывается, временно не принимает отправления или меняет график.\n\nЗаказчик определяет сценарий выбора: карта, поиск по адресу, список или их сочетание. Для мобильной версии особенно полезен поиск, когда рядом много точек.\n\nРазработчик проверяет, какие сведения возвращает внешняя система и какие данные нужно сохранить на сайте. Если при создании отправления требуется точный идентификатор пункта, одного адреса недостаточно: похожие адреса могут относиться к разным точкам.\n\nОтдельно согласуют ситуацию, когда выбранный пункт стал недоступен до передачи заказа. Покупателю можно предложить выбрать другую точку, а заказ передать оператору для обработки. Автоматическая замена допустима только при заранее заданном и понятном условии.\n\n## Ошибки обмена со службой доставки\n\nОшибка может появиться из-за неполного адреса, отсутствующего параметра товара, повторной передачи заказа, изменения формата ответа или временной недоступности внешней системы.\n\nОшибка расчёта при оформлении заказа и ошибка создания отправления после оплаты требуют разных действий. В первом случае сайт показывает покупателю доступный способ продолжить оформление. Во втором оператор видит, что заказ не передан, а повторный запуск не создаёт дубликат.\n\nВ проектной документации фиксируют:\n\n- где хранятся технические ответы и идентификаторы отправлений;\n- как система отличает повторный запрос от нового;\n- какие ошибки разработчик обрабатывает повторной попыткой, а какие передаёт сотруднику;\n- где оператор видит причину сбоя;\n- что происходит с заказом, пока передача не подтверждена;\n- как проверяют отмену, возврат и недоступность внешней системы.\n\nЗаказчик и разработчик согласуют тестовые сценарии в требованиях, затем проверяют их перед запуском интеграции. В набор входят заказ с несколькими позициями, доставка по адресу, получение в пункте выдачи, изменение заказа до отправки и ошибка внешнего ответа. Формулировка «интеграция работает» не заменяет результаты таких проверок.\n\n## Как выбрать способ интеграции со службой доставки\n\nСпособ подключения зависит от доступных методов обмена и задач интернет-магазина. Одному проекту достаточно передавать оформленные заказы и получать статусы. Другому требуется расчёт на сайте, выбор пункта выдачи, отмена отправления, обработка возврата или работа с документами в отдельном контуре.\n\nПеред выбором решения заказчик отвечает на практические вопросы: какие способы получения доступны покупателю, нужен ли расчёт до оформления, кто создаёт отправление, где оператор разбирает ошибки, нужно ли показывать статусы в личном кабинете и какой источник данных использовать при расхождениях.\n\nГотовый модуль проверяют по полям, статусам, правилам оформления и ограничениям конкретного проекта. Индивидуальная разработка рассматривается, если типовой вариант не передаёт нужные данные, не поддерживает согласованную последовательность действий или оставляет сотрудникам постоянную ручную работу.\n\n## Часто задаваемые вопросы\n### Что подготовить до интеграции интернет-магазина со службой доставки?\n\nЗаказчик описывает способы получения заказа, поля адреса, правила передачи заказа, отмены и возвраты. Для проверки обмена пригодятся примеры товаров с разными параметрами и несколько типовых заказов.\n\n### Почему доставка исчезает после изменения корзины?\n\nПосле изменения количества товаров, состава заказа, адреса или пункта выдачи внешний сервис может вернуть другой набор вариантов. В требованиях фиксируют момент повторного запроса и сообщение, которое увидит покупатель при недоступности прежнего выбора.\n\n### Нужно ли показывать в личном кабинете все статусы перевозчика?\n\nНет. В личном кабинете оставляют статусы, которые помогают покупателю понять состояние отправления. Технические сведения сохраняют для сотрудников, разбирающих ошибки и спорные ситуации.\n\n### Как избежать повторного создания отправления?\n\nРазработчик сохраняет внешний идентификатор отправления и реализует правила повторной отправки запроса. При сбое система сначала проверяет результат предыдущей попытки, а затем решает, создавать ли новое отправление.\n\n### Что делать, если внешний сервис не принимает выбранный пункт выдачи?\n\nСайт выводит понятное сообщение и запускает согласованный сценарий: покупатель выбирает другую точку, уточняет данные или заказ передают оператору. Условия замены пункта и порядок уведомления определяют до запуска интеграции.","\u003Cp>Покупатель оформляет заказ, выбирает пункт выдачи и ждёт уведомления. Если сайт показывает только «заказ передан в доставку», оператору трудно понять, где находится отправление: на сортировке, в пути или уже доступно к получению.\u003C\u002Fp>\n\u003Cp>Интеграция интернет-магазина со службами доставки связывает сайт с внешней системой обмена. Сайт передаёт сведения о заказе и получателе, получает условия доставки, статусы и данные пунктов выдачи. До разработки заказчик описывает путь заказа: от выбора способа получения до вручения, отмены или возврата.\u003C\u002Fp>\n\u003Ch2>Какие данные передаёт интернет-магазин службе доставки\u003C\u002Fh2>\n\u003Cp>Набор данных зависит от сценария. Для курьерской доставки могут потребоваться контакты получателя, адрес, состав заказа и параметры отправления. Для пункта выдачи добавляется идентификатор выбранной точки. Если в проекте предусмотрена оплата при получении, правила её обработки согласуют отдельно.\u003C\u002Fp>\n\u003Cp>Поля с похожими названиями не всегда совпадают по структуре. Адрес на сайте может храниться одной строкой, а внешняя система ожидать город, улицу, дом, корпус и квартиру по отдельности. Такая же проверка нужна для телефона, комментария к доставке, веса, габаритов и состава вложения.\u003C\u002Fp>\n\u003Cp>Заказчик фиксирует в требованиях:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>какие поля сайт отправляет при создании отправления;\u003C\u002Fli>\n\u003Cli>на каком этапе заказ передают в доставку;\u003C\u002Fli>\n\u003Cli>какие данные внешний сервис возвращает на сайт;\u003C\u002Fli>\n\u003Cli>может ли сотрудник изменить адрес или способ получения после оформления;\u003C\u002Fli>\n\u003Cli>как обрабатываются отмена заказа, частичная отмена и возврат;\u003C\u002Fli>\n\u003Cli>кто разбирает ошибку, если внешняя система не приняла заявку.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Если магазин работает на «1С-Битрикс: Управление сайтом», интеграция затрагивает заказ, каталог и интерфейс сайта. Внутренний порядок работы сотрудников описывают отдельным документом, чтобы не смешивать его с обменом между сайтом и службой доставки.\u003C\u002Fp>\n\u003Ch2>Расчёт доставки в корзине и при оформлении заказа\u003C\u002Fh2>\n\u003Cp>До оформления заказа сайт может запросить доступные варианты доставки для текущей корзины. На ответ влияют город, адрес или пункт выдачи, состав заказа, вес, габариты, объявленная ценность и другие параметры, предусмотренные проектом.\u003C\u002Fp>\n\u003Cp>Пока покупатель не указал адрес или не выбрал пункт выдачи, данных для запроса может не хватать. Заказчик и разработчик заранее согласуют поведение интерфейса: показывать предварительный вариант, предложить выбрать город или не выводить результат до заполнения нужных полей.\u003C\u002Fp>\n\u003Cp>Расчёт при выборе доставки и создание отправления могут дать разные результаты. В требованиях нужно определить, какой ответ сайт считает актуальным и что происходит, если после изменения корзины выбранный способ перестал быть доступен.\u003C\u002Fp>\n\u003Cp>Перед разработкой подрядчик уточняет обязательные параметры расчёта, обработку товаров без веса или габаритов, использование данных упаковки и порядок записи ошибок внешнего ответа. Это помогает избежать ситуации, когда сайт показывает вариант доставки, который не удаётся подтвердить при создании отправления.\u003C\u002Fp>\n\u003Ch2>Статусы заказа и отслеживание отправления\u003C\u002Fh2>\n\u003Cp>Статус заказа на сайте и статус перевозки описывают разные события. Заказ может быть подтверждён, но ещё не передан службе доставки. Отправление может находиться в пути, ожидать получения, быть вручённым, отменённым или возвращаться отправителю.\u003C\u002Fp>\n\u003Cp>Для обмена составляют таблицу соответствий: внешнее событие, статус на сайте, текст для покупателя и действие сотрудника. Технические обозначения сохраняют для диагностики, а в личном кабинете выводят понятное описание состояния отправления.\u003C\u002Fp>\n\u003Cp>Обновления можно получать регулярными запросами к внешней системе или через её уведомления. Разработчик обрабатывает задержки, повторную доставку одного события и временную недоступность сервиса. Запоздалый ответ не должен менять статус назад, если такой переход не предусмотрен сценарием.\u003C\u002Fp>\n\u003Cp>В интерфейсе обычно достаточно состояний: отправление создано, передано перевозчику, находится в пути, доступно к получению, вручено, возникла проблема. Формулировки и переходы зависят от данных подключаемой службы доставки.\u003C\u002Fp>\n\u003Ch2>Пункты выдачи заказов на карте и в списке\u003C\u002Fh2>\n\u003Cp>Выбор пункта выдачи требует не только карты с метками. Покупателю нужны сведения о расположении точки и её доступности для выбранного заказа. Данные могут меняться: пункт закрывается, временно не принимает отправления или меняет график.\u003C\u002Fp>\n\u003Cp>Заказчик определяет сценарий выбора: карта, поиск по адресу, список или их сочетание. Для мобильной версии особенно полезен поиск, когда рядом много точек.\u003C\u002Fp>\n\u003Cp>Разработчик проверяет, какие сведения возвращает внешняя система и какие данные нужно сохранить на сайте. Если при создании отправления требуется точный идентификатор пункта, одного адреса недостаточно: похожие адреса могут относиться к разным точкам.\u003C\u002Fp>\n\u003Cp>Отдельно согласуют ситуацию, когда выбранный пункт стал недоступен до передачи заказа. Покупателю можно предложить выбрать другую точку, а заказ передать оператору для обработки. Автоматическая замена допустима только при заранее заданном и понятном условии.\u003C\u002Fp>\n\u003Ch2>Ошибки обмена со службой доставки\u003C\u002Fh2>\n\u003Cp>Ошибка может появиться из-за неполного адреса, отсутствующего параметра товара, повторной передачи заказа, изменения формата ответа или временной недоступности внешней системы.\u003C\u002Fp>\n\u003Cp>Ошибка расчёта при оформлении заказа и ошибка создания отправления после оплаты требуют разных действий. В первом случае сайт показывает покупателю доступный способ продолжить оформление. Во втором оператор видит, что заказ не передан, а повторный запуск не создаёт дубликат.\u003C\u002Fp>\n\u003Cp>В проектной документации фиксируют:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>где хранятся технические ответы и идентификаторы отправлений;\u003C\u002Fli>\n\u003Cli>как система отличает повторный запрос от нового;\u003C\u002Fli>\n\u003Cli>какие ошибки разработчик обрабатывает повторной попыткой, а какие передаёт сотруднику;\u003C\u002Fli>\n\u003Cli>где оператор видит причину сбоя;\u003C\u002Fli>\n\u003Cli>что происходит с заказом, пока передача не подтверждена;\u003C\u002Fli>\n\u003Cli>как проверяют отмену, возврат и недоступность внешней системы.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Заказчик и разработчик согласуют тестовые сценарии в требованиях, затем проверяют их перед запуском интеграции. В набор входят заказ с несколькими позициями, доставка по адресу, получение в пункте выдачи, изменение заказа до отправки и ошибка внешнего ответа. Формулировка «интеграция работает» не заменяет результаты таких проверок.\u003C\u002Fp>\n\u003Ch2>Как выбрать способ интеграции со службой доставки\u003C\u002Fh2>\n\u003Cp>Способ подключения зависит от доступных методов обмена и задач интернет-магазина. Одному проекту достаточно передавать оформленные заказы и получать статусы. Другому требуется расчёт на сайте, выбор пункта выдачи, отмена отправления, обработка возврата или работа с документами в отдельном контуре.\u003C\u002Fp>\n\u003Cp>Перед выбором решения заказчик отвечает на практические вопросы: какие способы получения доступны покупателю, нужен ли расчёт до оформления, кто создаёт отправление, где оператор разбирает ошибки, нужно ли показывать статусы в личном кабинете и какой источник данных использовать при расхождениях.\u003C\u002Fp>\n\u003Cp>Готовый модуль проверяют по полям, статусам, правилам оформления и ограничениям конкретного проекта. Индивидуальная разработка рассматривается, если типовой вариант не передаёт нужные данные, не поддерживает согласованную последовательность действий или оставляет сотрудникам постоянную ручную работу.\u003C\u002Fp>\n\u003Ch2>Часто задаваемые вопросы\u003C\u002Fh2>\n\u003Ch3>Что подготовить до интеграции интернет-магазина со службой доставки?\u003C\u002Fh3>\n\u003Cp>Заказчик описывает способы получения заказа, поля адреса, правила передачи заказа, отмены и возвраты. Для проверки обмена пригодятся примеры товаров с разными параметрами и несколько типовых заказов.\u003C\u002Fp>\n\u003Ch3>Почему доставка исчезает после изменения корзины?\u003C\u002Fh3>\n\u003Cp>После изменения количества товаров, состава заказа, адреса или пункта выдачи внешний сервис может вернуть другой набор вариантов. В требованиях фиксируют момент повторного запроса и сообщение, которое увидит покупатель при недоступности прежнего выбора.\u003C\u002Fp>\n\u003Ch3>Нужно ли показывать в личном кабинете все статусы перевозчика?\u003C\u002Fh3>\n\u003Cp>Нет. В личном кабинете оставляют статусы, которые помогают покупателю понять состояние отправления. Технические сведения сохраняют для сотрудников, разбирающих ошибки и спорные ситуации.\u003C\u002Fp>\n\u003Ch3>Как избежать повторного создания отправления?\u003C\u002Fh3>\n\u003Cp>Разработчик сохраняет внешний идентификатор отправления и реализует правила повторной отправки запроса. При сбое система сначала проверяет результат предыдущей попытки, а затем решает, создавать ли новое отправление.\u003C\u002Fp>\n\u003Ch3>Что делать, если внешний сервис не принимает выбранный пункт выдачи?\u003C\u002Fh3>\n\u003Cp>Сайт выводит понятное сообщение и запускает согласованный сценарий: покупатель выбирает другую точку, уточняет данные или заказ передают оператору. Условия замены пункта и порядок уведомления определяют до запуска интеграции.\u003C\u002Fp>\n"]