[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f3j5g1swn2h6q9":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},"razrabotka-internet-magazina-s-dostavkoy-korzina-raschet-i-uvedomleniya","Разработка интернет-магазина с доставкой: корзина и уведомления",true,"2024-06-11T10:00:00+03:00","2026-09-06T16:09:16.256Z","Статьи","Материал посвящён сценариям корзины, оформления заказа и доставки в интернет-магазине. Описаны вопросы для требований и проверки работы сайта.","\u002Fcontent-media\u002Farticles\u002Frazrabotka-internet-magazina-s-dostavkoy-korzina-raschet-i-uvedomleniya\u002Fassets\u002F12cca3c41f27.webp",[],"lc_60ec44dafbc5a4716d8acaf87f2697cb","Покупатель добавляет товар в корзину, видит одну сумму, а при оформлении заказа — другую. Нужный способ доставки может оказаться недоступным, адрес — не пройти проверку, а после оплаты может не появиться понятного подтверждения. В таких ситуациях покупатель может не завершить заказ, а сотрудникам придётся уточнять данные вручную.\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Если сайт создаётся на «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Проверяют передачу нового заказа, изменение состава, отмену, повторную отправку после ошибки и обновление статуса. Для каждого случая заранее определяют, где должна появиться информация и кто разбирает расхождения.","\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\u003C\u002Ful>\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>Если сайт создаётся на «1С-Битрикс: Управление сайтом», требования относятся к каталогу, корзине, оформлению и обработке заказа на сайте. Процессы работы сотрудников и системы работы с клиентами описывают отдельным документом, не смешивая их с логикой системы управления сайтом.\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\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\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"]