Общий план интеграционного теста с партнёрами

Общая информация

Цели тестирования на демо-стенде:

Проверить механизм аутентификации и безопасности.
Проверить основной сценарий передачи заказа из ЗЯ в ВКС.
Проверить жизненный цикл заказа через обмен статусами.
Проверить сценарии переноса сроков доставки.
Проверить сценарии отмены заказа обеими сторонами.
Проверить синхронизацию данных о пунктах выдачи (если они имеются у ВКС).

Как читать сценарии

Каждый кейс описан тремя блоками: предусловия → шаги → ожидаемый результат. В заголовке кейса указаны направление запроса и проверяемая роль системы ВКС.

Обозначение	Описание
ЗЯ → ВКС	Запрос выполняет ИС Золотого Яблока, ответ предоставляет ИС ВКС. Авторизация — токеном, выданным ВКС.
ВКС → ЗЯ	Запрос выполняет ИС ВКС, ответ предоставляет ИС ЗЯ. Авторизация — токеном, выданным ЗЯ.
[S]	Проверяется система ВКС как сервер: реализация эндпоинта, коды ответов, валидация.
[C]	Проверяется система ВКС как клиент: корректность исходящих запросов, их порядок, обработка ошибок.

Общие правила взаимодействия

Правила из спецификации, действующие во всех кейсах:

кодировка UTF-8, обмен с типом содержимого "application/json";
даты и временные штампы — ISO 8601, UTC с нулевым смещением (например 2025-08-05T23:36:00Z); даты — YYYY-MM-DD, интервалы — HH:mm;
отслеживание ведётся по orderNumber — он же трек-номер;
любой необязательный параметр может быть пустым или нулевым, но должен быть передан;
любой обязательный параметр заполняется в соответствии со своим типом данных;
если услуги оказываются в нескольких странах, экземпляры сервиса и эндпоинты различаются доменной зоной; правило действует в обе стороны.

Единые коды ответов защищённых методов

Код	Статус	Сообщение	Причина
400	Bad Request	Missing or inappropriate required parameters	Не переданы или некорректно заполнены обязательные поля
401	Unauthorized	Token is invalid	Ошибка аутентификации
403	Forbidden	Has no permission	Запрещено в текущем контексте
404	Not Found	Resource not found	Только для метода истории статусов
500	Internal Server Error	Server unavailable	Сервер недоступен

1. Механизм аутентификации и безопасности

auth-1 · Успешная авторизация ВКС в сервисе ЕАПИ ЗЯ · ВКС → ЗЯ · [C]

Предусловия	ЗЯ выдал ВКС валидные `username` и `password`; согласован код курьерской службы (`deliveryServiceCode`).
Шаги	ВКС отправляет `POST /api/v1/auth/login` в ЕАПИ ЗЯ с заголовками `Host` и `Content-Type: application/json` и учётными данными в теле.
Ожидаемый результат	`200 Success response`; в ответе непустой `access_token` и `expires_in`. Токен сохраняется и переиспользуется до истечения срока, а не запрашивается на каждый вызов.

auth-2 · Успешная авторизация ЕАПИ ЗЯ в сервисе ВКС · ЗЯ → ВКС · [S]

Предусловия	На стороне ВКС реализован `POST /api/v1/auth/login`; ВКС выдал ЗЯ логин и пароль (буквы обоих регистров, цифры, спецсимволы, длина > 12 символов).
Шаги	ЗЯ отправляет запрос авторизации с валидными `username` и `password`.
Ожидаемый результат	`200 Success response`; в ответе `access_token` и `expires_in`. Токен — JWT, подпись SHA256 ключом от 32 символов; на стороне ВКС валидируется время жизни.

auth-3 · Неуспешная авторизация в сервисе ВКС с неверными учётными данными · ЗЯ → ВКС · [S]

Шаги	ЗЯ отправляет запрос авторизации с неверным `username` или `password`.
Ожидаемый результат	`400 Bad Request`, в теле поле `error`. Внутренние детали и подсказки о существовании учётной записи не раскрываются, ответ не 500.

auth-4 · Неуспешная авторизация с отсутствующим обязательным полем · ЗЯ → ВКС · [S]

Шаги	ЗЯ отправляет запрос авторизации без поля `password`.
Ожидаемый результат	`400 Bad Request` с сообщением о недостающих обязательных параметрах.

Пример ответа:

{ "error": "Missing or inappropriate required parameters" }

auth-5 · Вызов защищённого метода с невалидным токеном · ЗЯ → ВКС · [S]

Предусловия	Реализован любой метод, требующий авторизации (например, создание заказа).
Шаги	ЗЯ вызывает такой метод с заголовком `Authorization: Bearer invalid_token`.
Ожидаемый результат	`401 Token is invalid`. Запрос не выполняется, побочных эффектов нет.

auth-6 · Вызов метода с истёкшим токеном · ЗЯ → ВКС · [S]

Предусловия	Имитировано истечение срока жизни с момента выдачи токена.
Шаги	ЗЯ выполняет запрос с просроченным токеном.
Ожидаемый результат	`401 Token is invalid` — валидация времени жизни срабатывает.

auth-7 · Вызов метода без заголовка Authorization · ЗЯ → ВКС · [S]

Шаги	ЗЯ вызывает защищённый метод без заголовка `Authorization`.
Ожидаемый результат	`401`. Метод недоступен без авторизации.

auth-8 · Перевыпуск токена после 401 · ВКС → ЗЯ · [C]

Предусловия	Токен ЗЯ у ВКС просрочен или отозван.
Шаги	ВКС отправляет запрос в ЕАПИ ЗЯ и получает `401`.
Ожидаемый результат	ВКС перевыпускает токен через `/api/v1/auth/login` и повторяет запрос. Повторов с заведомо невалидным токеном нет.

auth-9 · Разделение экземпляров по странам · ЗЯ → ВКС · [S]

Предусловия	ВКС работает более чем в одной стране.
Шаги	ЗЯ выполняет авторизацию и создание заказа на эндпоинтах каждой доменной зоны ВКС.
Ожидаемый результат	Для каждой страны предоставлен свой набор эндпоинтов; токен и данные одной зоны не применяются к другой.

2. Основной сценарий передачи заказа из ЗЯ в ВКС

Все кейсы блока: ЗЯ → ВКС, POST /api/v1/orders, авторизация токеном ВКС, проверяется система ВКС как сервер [S]. Успешный ответ: 200 Order has been created с полями ecsOrderNumber, orderNumber, createdAt. Ошибки: 400, 401, 403, 500; тело ошибки — errorMessage и, при ошибках адресов, errorCode.

order-1 · Успешное создание нового заказа (первая отправка) · ЗЯ → ВКС · [S]

Предусловия	Получен валидный `access_token` от ВКС; согласованы `deliveryServiceCode` и `courierTariffCode`.
Шаги	ЗЯ отправляет `POST /api/v1/orders` с заголовками `Authorization` и `content-type`, передавая обязательные поля: `orderNumber`, `deliveryServiceCode`, `courierTariffCode`, `isOrderFirstSend: true`, `needCustomerNotification`, `senderName`, `shippingWarehouse.code`, `locationFrom` (адресный объект), `recipient` (`name`, `phone`), `locationTo` или `pickpointId`, массив `package` (`barcode`, `weight`, `length`, `width`, `height`, `isPartialBuy`, `isTryOnAllowed`, `totalAmount`, `declaredAmount`, `items[]` с `name`, `warekey`, `quantity`, `weight`, `isPartialBuy`, `isTryOnAllowed`, `priceAmount`, `declaredAmount`, `vatRate`, `vatSum`), `shipmentDate`, `deliveryDate`, `deliveryTimeIntervalFrom`, `deliveryTimeIntervalTo`, `deliveryPaymentAmount`, `orderPaymentAmount` (`declaredAmount`, `totalAmount`, `amountToCollect`, `vatSum`, `currency`).
Ожидаемый результат	`200 Order has been created`; ответ содержит `ecsOrderNumber` (идентификатор заказа в ВКС), переданный `orderNumber` и `createdAt` в формате `YYYY-MM-DDThh:mm:ssZ`. Заказ виден в системе ВКС со всеми переданными данными.

Пример ответа:

{
  "ecsOrderNumber": "f91ae5a4-3b1c-4e7a-8c29-72b1db2025a1",
  "orderNumber": "qwe-126543",
  "createdAt": "2025-05-10T10:41:22Z"
}

order-2 · Успешное создание заказа с доставкой в ПВЗ (если имеется) · ЗЯ → ВКС · [S]

Предусловия	`pickpointId` известного ПВЗ существует в справочнике ВКС и передан в ЕАПИ ЗЯ.
Шаги	Выполняются шаги order-1, но вместо адреса доставки передаётся `pickpointId` (`locationTo` при этом не заполняется адресом клиента).
Ожидаемый результат	`200`, заказ создан и привязан именно к указанному ПВЗ; в карточке заказа на стороне ВКС виден нужный пункт выдачи.

order-3 · Создание заказа с ошибкой в адресе отправителя (Addr_01) и получателя (Addr_02) · ЗЯ → ВКС · [S]

Шаги	ЗЯ отправляет запрос с некорректными данными в `locationFrom` (например, несуществующий ФИАС-код), затем — с некорректными данными в `locationTo` или `pickpointId`.
Ожидаемый результат	`400` в обоих случаях; тело содержит `errorMessage` и `errorCode`: `Addr_01` — ошибка в адресе отправителя, `Addr_02` — ошибка в адресе получателя. Заказ не создан.

Пример ответа:

{ "errorMessage": "Missing or inappropriate required parameters", "errorCode": "Addr_01" }

order-4 · Попытка создания заказа без обязательного поля · ЗЯ → ВКС · [S]

Шаги	ЗЯ отправляет запрос без обязательного поля (например, без `orderNumber`).
Ожидаемый результат	`400 Missing or inappropriate required parameters` с указанием проблемного поля в `errorMessage`. Не 500.

order-5 · Создание заказа с разными типами адресов (gar, coord, custom), с которыми работает ВКС · ЗЯ → ВКС · [S]

Шаги	ЗЯ создаёт несколько заказов, используя в `locationFrom` и `locationTo` поочерёдно `addressType: "gar"`, `"coord"`, `"custom"` с соответствующими наборами полей (ФИАС-коды; широта и долгота; части адреса со строковым адресом и координатами).
Ожидаемый результат	`200` по каждому; во всех трёх случаях адрес корректно распознан и отображается в системе ВКС.

order-6 · Создание заказа с разными видами оплат · ЗЯ → ВКС · [S]

Шаги	ЗЯ выполняет два запроса с `orderPaymentAmount.amountToCollect = 0` (заказ оплачен) и `= 500` (оплата с клиента 500) при заполненном `currency` по ISO 4217.
Ожидаемый результат	`200` по обоим; сумма к получению с клиента в ВКС соответствует переданной, для предоплаченного заказа курьеру не выставляется сумма к сбору.

order-7 · Некорректный deliveryServiceCode или courierTariffCode · ЗЯ → ВКС · [S]

Шаги	ЗЯ передаёт несогласованный код службы или несуществующий код тарифа.
Ожидаемый результат	`400` с внятным `errorMessage`. Заказ не создан.

order-8 · Повторная отправка того же orderNumber (идемпотентность) · ЗЯ → ВКС · [S]

Предусловия	Выполнен order-1.
Шаги	ЗЯ повторно отправляет заказ с тем же `orderNumber` и `isOrderFirstSend: true`.
Ожидаемый результат	Дубль не создаётся: либо `200` с тем же `ecsOrderNumber`, либо `400` / `403` с явной ошибкой о существующем заказе. Поведение предсказуемое и одинаковое при каждом повторе.

order-9 · Необязательные поля переданы пустыми · ЗЯ → ВКС · [S]

Шаги	ЗЯ создаёт заказ, передавая необязательные поля (`shippingWarehouse.manager`, `shippingWarehouse.phone`, `recipient.email`, `shipmentTimeIntervalFrom`, `shipmentTimeIntervalTo`, `courierComment`, `returnWarehouse`) со значениями `null` или пустыми, но передавая сами поля.
Ожидаемый результат	`200`; ВКС корректно принимает пустые необязательные параметры, не отвечает 400 и не падает в 500.

3. Жизненный цикл заказа через обмен статусами

status-1 · Успешное обновление статуса заказа ВКС → ЗЯ · [C]

Предусловия	Заказ создан в ВКС (есть `orderNumber`); получен валидный `access_token` от ЗЯ; на стороне ВКС реализована подписка (webhook) на изменения статусов.
Шаги	ВКС отправляет `PUT /api/v1/orders/{orderNumber}` с заголовками `Authorization: Bearer <token>` и `content-type`, передавая объект статуса: `deliveryServiceCode`, `actualStatus`, `statusComment`, `statusAssignmentDate`, `hasBeenDelivered`, `actualDeliveryDate`.
Ожидаемый результат	`200 Status has been updated`; статус принят ИС ЗЯ и виден в карточке заказа. `statusAssignmentDate` — реальное время присвоения статуса в ИС КС, а не время отправки запроса.

Пример ответа:

{
  "deliveryServiceCode": "delivery_code",
  "actualStatus": "ECS_ORDER_TAKEN_BY_COURIER",
  "statusComment": "Заказ выдан на доставку, курьер в пути",
  "statusAssignmentDate": "2025-04-05T10:15:30Z",
  "hasBeenDelivered": false,
  "actualDeliveryDate": null
}

status-2 · Успешное обновление финального статуса (доставлен) · ВКС → ЗЯ · [C]

Предусловия	Заказ находится в пути.
Шаги	ВКС отправляет `ECS_ORDER_DELIVERED` с `hasBeenDelivered: true` и заполненным `actualDeliveryDate`.
Ожидаемый результат	`200`; в ИС ЗЯ заказ переходит в статус «Доставлен». Признак `hasBeenDelivered` поднимается и при частичной доставке (`ECS_ORDER_DELIVERED_PARTIALLY`), `actualDeliveryDate` при этом обязателен. После финального статуса новые статусы по заказу не отправляются.

status-3 · Запрос истории статусов по заказу · ЗЯ → ВКС · [S]

Предусловия	Заказу присвоено несколько статусов в ВКС; получен валидный `access_token` от ВКС.
Шаги	ЗЯ отправляет `GET /api/v1/orders/{orderNumber}/history` с заголовками `Authorization` и `content-type`.
Ожидаемый результат	`200 Status history has been sent`; в ответе массив `statusHistory` со всеми присвоенными статусами в хронологическом порядке от нового к старому; каждый элемент — объект статуса с полями `deliveryServiceCode`, `actualStatus`, `statusComment`, `statusAssignmentDate`, `hasBeenDelivered`, `actualDeliveryDate`.

status-4 · История по несуществующему заказу и статус с невалидным кодом · ЗЯ ⇄ ВКС · [S+C]

Шаги	ЗЯ выполняет метод истории с несуществующим `orderNumber`; затем ВКС отправляет статус с `actualStatus: "INVALID_STATUS"`, отсутствующим в справочнике статусов заказа.
Ожидаемый результат	На первый метод — `404 Resource not found` (не 200 с пустым массивом и не 500); на второй — `400 Missing or inappropriate required parameters`. ВКС корректно обрабатывает отказ: логирует, не зацикливает повторы, не считает статус применённым.

status-5 · Связка: создание → статус → история · ЗЯ ⇄ ВКС · [S+C]

Предусловия	Выполнен order-1; выполнен status-1 (один или несколько раз); выполнен status-2.
Шаги	ЗЯ запрашивает историю статусов по заказу.
Ожидаемый результат	`200`; история содержит `ECS_ORDER_CREATED` / `ECS_ORDER_ACCEPTED`, промежуточные статусы и финальный; порядок корректен, временные метки согласованы, расхождений между данными ВКС и ЗЯ нет. Прогнать на нескольких статусных моделях: курьерская доставка, доставка до ПВЗ, отменённый заказ.

status-6 · Полная статусная модель прямого процесса · ВКС → ЗЯ · [C]

Предусловия	Согласован маппинг внутренних статусов ВКС на коды справочника.
Шаги	ВКС прогоняет по одному заказу цепочку статусов курьерской доставки: `ECS_ORDER_ACCEPTED / ECS_ORDER_CREATED` `ECS_ORDER_TAKEN_FROM_SHIPMENT_WAREHOUSE` `ECS_ORDER_FIRST_ACCEPTANCE` `ECS_ORDER_SENT_TO_TRANSIT_CITY` `ECS_ORDER_ACCEPTED_IN_TRANSIT_CITY_HUB` `ECS_ORDER_READY_FOR_APPOINTMENT` `ECS_COURIER_APPOINTED` `ECS_ORDER_TAKEN_BY_COURIER` `(ECS_DELIVERY_ATTEMPT — если была неуспешная попытка вручения)` `ECS_ORDER_DELIVERED`
Ожидаемый результат	`200` по каждому; статусы приходят в хронологическом порядке, `statusComment` соответствует коду, повторов и пропусков ключевых этапов нет. Транзитные статусы отправляются, если ВКС фактически использует консолидацию и транзит.

status-7 · Статусная модель доставки до ПВЗ · ВКС → ЗЯ · [C]

Предусловия	Заказ создан с `pickpointId` (order-2).
Шаги	ВКС прогоняет цепочку до ПВЗ: приёмка и транзит `ECS_ORDER_READY_FOR_APPOINTMENT` (заказ прибыл на ПВЗ) `ECS_ORDER_READY_TO_PICK_UP` `ECS_ORDER_DELIVERED`
Ожидаемый результат	`200` по каждому; в ИС ЗЯ виден факт прибытия заказа на ПВЗ и готовности к выдаче; выдача фиксируется с `hasBeenDelivered: true` и `actualDeliveryDate`.

status-8 · Статусы возвратного процесса · ВКС → ЗЯ · [C]

Предусловия	Заказ не вручён и уходит на возврат.
Шаги	ВКС отправляет метод отмены, а далее цепочку статусов возврата: `ECS_RETURN_FIRST_ACCEPTANCE` `ECS_RETURN_SENT_TO_TRANSIT_CITY` `ECS_RETURN_ACCEPTED_IN_TRANSIT_CITY_HUB` `ECS_RETURN_ON_THE_WAY_TO_WAREHOUSE` `ECS_RETURN_DELIVERED_TO_WAREHOUSE`
Ожидаемый результат	`200` по каждому; в ИС ЗЯ виден весь путь возврата вплоть до приёмки на складе возврата; при заполненном `returnWarehouse` возврат идёт на переданный адрес.

status-9 · Статус по несуществующему заказу · ВКС → ЗЯ · [C]

Шаги	ВКС отправляет статус на `orderNumber`, которого нет в ИС ЗЯ.
Ожидаемый результат	`404 Resource not found`; ВКС обрабатывает ответ и не повторяет запрос бесконечно.

status-10 · Скорость доставки статусов · ВКС → ЗЯ · [C]

Шаги	Фиксируется время между фактическим изменением статуса в ИС ВКС и его получением в ЕАПИ ЗЯ.
Ожидаемый результат	Статус доставлен в пределах согласованного SLA (по умолчанию не более 15 минут, финальные статусы — приоритетно). При временной недоступности ЕАПИ ВКС повторяет отправку и не теряет статус.

status-11 · Попытка доставки · ВКС → ЗЯ · [C]

Предусловия	Заказ выдан курьеру (`ECS_ORDER_TAKEN_BY_COURIER`), вручить с первого раза не удалось (клиента нет на месте, недоступен).
Шаги	ВКС отправляет `ECS_DELIVERY_ATTEMPT` с `hasBeenDelivered: false`, пустым `actualDeliveryDate` и `statusComment` с причиной; при повторных выездах статус отправляется повторно, затем следует финальный исход — вручение или отмена.
Ожидаемый результат	`200`; в ИС ЗЯ видна каждая попытка доставки с корректным `statusAssignmentDate`, попытки не схлопываются в одну. После запроса от ВКС заказ уходит в отмену либо в возвратный процесс.

4. Сценарии переноса сроков доставки

Метод переноса даты — PATCH /api/v1/orders/{orderNumber}, успешный ответ 200 Delivery date has been updated.

data-1 · Успешный перенос даты по инициативе ЗЯ · ЗЯ → ВКС · [S]

Предусловия	Заказ создан, статус позволяет перенос.
Шаги	ЗЯ отправляет `PATCH /api/v1/orders/{orderNumber}` с `Authorization` от ВКС и телом `deliveryDate`, `deliveryTimeIntervalFrom`, `deliveryTimeIntervalTo`.
Ожидаемый результат	`200 Delivery date has been updated`; дата и интервал доставки обновлены в ИС ВКС, изменение доводится до курьера или ПВЗ.

Пример ответа:

{ "deliveryDate": "2025-05-10", "deliveryTimeIntervalFrom": "10:00", "deliveryTimeIntervalTo": "12:00" }

data-2 · Успешный перенос даты по инициативе ВКС · ВКС → ЗЯ · [C]

Предусловия	Заказ создан, статус позволяет перенос.
Шаги	ВКС отправляет `PATCH /api/v1/orders/{orderNumber}` с `Authorization` от ЗЯ и телом `deliveryServiceCode`, `deliveryDate`, `deliveryTimeIntervalFrom`, `deliveryTimeIntervalTo`, `dateChangeReason`.
Ожидаемый результат	`200`; дата доставки обновлена в ИС ЗЯ, причина переноса сохранена. Перенос даты отправляется именно этим методом, а не через изменение статуса.

data-3 · Неуспешный перенос даты по инициативе ЗЯ · ЗЯ → ВКС · [S]

Предусловия	Заказ создан, статус позволяет перенос.
Шаги	ЗЯ передаёт `deliveryDate` в прошлом, либо дату, на которую перенос невозможен (нет слотов, вне графика ПВЗ), либо интервал с `deliveryTimeIntervalTo` раньше `deliveryTimeIntervalFrom`.
Ожидаемый результат	`403 Has no permission` — на эту дату смена невозможна (либо `400`, если дата не проходит формальную валидацию). Дата в ИС ВКС не изменена.

data-4 · Отказ в переносе даты (некорректный статус заказа) · ЗЯ ⇄ ВКС · [S+C]

Предусловия	Заказ в финальном статусе (`ECS_ORDER_DELIVERED`) или отменён.
Шаги	Выполняются data-1 и data-2.
Ожидаемый результат	`400` в обоих случаях. Обе стороны корректно обрабатывают отказ, дата не меняется.

data-5 · Перенос даты ВКС без указания причины · ВКС → ЗЯ · [C]

Шаги	ВКС отправляет запрос data-2 без обязательного поля `dateChangeReason`.
Ожидаемый результат	`400 Missing or inappropriate required parameters`. Проверяется, что в штатном режиме ВКС всегда заполняет `dateChangeReason`.

data-6 · Согласованность данных после переноса · ЗЯ ⇄ ВКС · [S+C]

Предусловия	Выполнен data-1 или data-2.
Шаги	Данные заказа запрашиваются с обеих сторон.
Ожидаемый результат	`deliveryDate` и интервалы совпадают в ИС ЗЯ и ИС ВКС; перенос не порождает лишних статусов в истории.

5. Сценарии отмены заказа обеими сторонами

Методы: POST /api/v1/orders/{orderNumber}/cancel (в обе стороны) и POST /api/v1/orders/{orderNumber}/reopen (ВКС → ЗЯ). Срок на отказ от отмены — 24 часа, если иное не установлено договором; на демо-стенде таймер сокращён до 2 часов.

cancel-1 · Успешная отмена заказа по инициативе ЗЯ · ЗЯ → ВКС · [S]

Предусловия	Заказ создан, статус позволяет отмену.
Шаги	ЗЯ отправляет `POST /api/v1/orders/{orderNumber}/cancel` с `Authorization` от ВКС; тело запроса не требуется.
Ожидаемый результат	`200 Order has been canceled`; заказ отменён в ИС ВКС, факт принятия запроса залогирован. После получения отмены ВКС отправляет методом изменения статуса статус `GA_CANCEL_REQUEST`. Доставка фактически останавливается.

cancel-2 · Успешная отмена заказа по инициативе ВКС · ВКС → ЗЯ · [C]

Предусловия	Заказ создан.
Шаги	ВКС отправляет `POST /api/v1/orders/{orderNumber}/cancel` с `Authorization` от ЗЯ и телом `dateTime` (ISO 8601, UTC) и `comment`.
Ожидаемый результат	`200 Order has been marked for cancellation`; заказ помечен на отмену в ИС ЗЯ, запущен таймер 2 часов (на демо-стенде). Причина отмены передаётся отдельным статусом из справочника статусов отмен (например `CUSTOMER_DECLINED`, `CUSTOMER_UNAVAILABLE`, `CUSTOMER_EXPIRED_ON_HOLD`, `ECS_ORDER_NOT_DELIVERED`, `ECS_LOGISTIC_ERROR`, `ECS_WAREHOUSE_DAMAGED`, `PAYMENT_UNAVAILABLE_DUE_TO_ECS`, `UNTRANSPORTABLE_WEATHER`). Прогнать не менее трёх разных причин отмены, включая внутреннюю причину ВКС, отказ клиента и проблему с оплатой.

cancel-3 · Отказ от отмены заказа (reopen) · ВКС → ЗЯ · [C]

Предусловия	Выполнен cancel-2, прошло менее 2 часов (на демо-стенде).
Шаги	ВКС отправляет `POST /api/v1/orders/{orderNumber}/reopen` с телом `comment`.
Ожидаемый результат	`200 Order has been reopened`; пометка на отмену снята, доставка продолжается, последующие статусы принимаются. Ранее переданный статус отмены исключён из истории статусов, логических разрывов в истории нет.

cancel-4 · Автоматическая отмена после таймаута · ВКС → ЗЯ · [C]

Предусловия	Выполнен cancel-2, прошло более 2 часов (на демо-стенде), reopen не вызывался.
Шаги	Проверяется состояние заказа в ИС ЗЯ.
Ожидаемый результат	Заказ переведён в «Отменён»; ВКС отправляет статусы возвратного потока. Проверяется, что система ВКС корректно завершает работу с таким заказом.

cancel-5 · Отмена уже доставленного заказа · ЗЯ ⇄ ВКС · [S+C]

Предусловия	Заказ в статусе `ECS_ORDER_DELIVERED`.
Шаги	Выполняются попытки cancel-1 и cancel-2.
Ожидаемый результат	`403 Has no permission` — отмена в текущем контексте запрещена. Состояние заказа не меняется.

cancel-6 · Статус отмены без вызова метода отмены · ВКС → ЗЯ · [C]

Предусловия	Заказ создан.
Шаги	ВКС отправляет статус отмены, не вызвав предварительно метод `/cancel`.
Ожидаемый результат	`403 Has no permission`. Проверяется, что в штатном сценарии ВКС соблюдает порядок: `/cancel` → статус отмены.

cancel-7 · Повторная отмена уже отменённого заказа · ЗЯ → ВКС · [S]

Предусловия	Заказ уже отменён.
Шаги	ЗЯ повторно вызывает `/cancel`.
Ожидаемый результат	`400 Bad Request`. Не 500, дублирующих событий не создаётся.

cancel-8 · Reopen после отмены по инициативе ЗЯ · ВКС → ЗЯ · [C]

Предусловия	Выполнен cancel-1, прошло менее 2 часов (на демо-стенде), ВКС готова возобновить доставку.
Шаги	ВКС отправляет `POST /api/v1/orders/{orderNumber}/reopen` с `comment`.
Ожидаемый результат	`200`; пометка на отмену снята, доставка возобновляется, статусы принимаются в штатном режиме.

cancel-9 · Reopen после истечения 2 часов · ВКС → ЗЯ · [C]

Предусловия	Выполнен cancel-2, прошло более 2 часов, заказ уже отменён.
Шаги	ВКС отправляет reopen.
Ожидаемый результат	`400 Bad Request`; отменённый заказ к доставке не возвращается, ВКС корректно обрабатывает отказ.

6. Синхронизация данных о пунктах выдачи (если они имеются у ВКС)

PVZ-1 · Успешное получение полного справочника ПВЗ · ЗЯ → ВКС · [S]

Предусловия	Получен `access_token` от ВКС.
Шаги	ЗЯ отправляет `GET /api/v1/pickpoints` с заголовками `Authorization` и `content-type`.
Ожидаемый результат	`200 Success`; в ответе `countryISOCode` (ISO 3166-1 alpha-2), `deliveryServiceCode` и массив `pickpointsList`. Каждый ПВЗ содержит `id`, `type`, `address` (адресный объект), `openingHours` (`dayOfWeek`, `workingDay`, `opens`, `closes`), `phoneNumber`, `isAvailable`, `orderStoragePeriod`, `options` (`orderIssuing`, `orderReturning`, `haveTryOn`, `havePartialBuy`, весогабаритные ограничения) и `paymentOptions` (`haveCashPayment`, `haveCardPayment`, `haveQrCodePayment`).

PVZ-2 · Успешное добавление нового ПВЗ в справочник · ВКС → ЗЯ · [C]

Шаги	ВКС отправляет `POST /api/v1/pickpoints/add` с `Authorization` от ЗЯ, передавая данные одного ПВЗ: `id`, `type`, адресный объект, `openingHours`, `isAvailable`, `orderStoragePeriod`, `options`, `paymentOptions`.
Ожидаемый результат	`200 A new pickpoint has been created`; в ответе подтверждающий `id`, новый ПВЗ появляется в справочнике ЗЯ. Один запрос — один ПВЗ.

Пример ответа:

{ "id": "PVZ-SPB-001" }

PVZ-3 · Успешное изменение данных существующего ПВЗ · ВКС → ЗЯ · [C]

Предусловия	ПВЗ с этим `id` существует в справочнике ЗЯ.
Шаги	ВКС отправляет `PUT /api/v1/pickpoints/{pickpointId}/update`, изменяя, например, `isAvailable: false` (закрытие на ремонт), график работы или весогабаритные ограничения.
Ожидаемый результат	`200 Pickpoint has been updated`; данные ПВЗ обновлены в справочнике ЗЯ, недоступный ПВЗ перестаёт предлагаться клиенту.

PVZ-4 · Попытка добавить ПВЗ с уже существующим id · ВКС → ЗЯ · [C]

Предусловия	ПВЗ с таким `id` уже есть в справочнике ЗЯ.
Шаги	ВКС выполняет PVZ-2 с `id` существующего ПВЗ.
Ожидаемый результат	`400` с сообщением в поле `error`; дубликат в справочнике не создаётся, ВКС корректно обрабатывает отказ.

PVZ-5 · Изменение несуществующего ПВЗ · ВКС → ЗЯ · [C]

Шаги	ВКС выполняет PVZ-3 с несуществующим `pickpointId`.
Ожидаемый результат	`400` с сообщением в поле `error` (код 404 для этого метода спецификацией не предусмотрен — фактическое поведение фиксируется и согласуется). Изменения не применяются.

PVZ-6 · Заказ в закрытый или недоступный ПВЗ · ЗЯ → ВКС · [S]

Предусловия	Выполнен PVZ-3 с `isAvailable: false`.
Шаги	ЗЯ пытается создать заказ на этот ПВЗ.
Ожидаемый результат	`400` с `errorCode: "Addr_02"` либо иной явной ошибкой о недоступности ПВЗ. Заказ не создан.

PVZ-7 · Соответствие ограничений ПВЗ параметрам заказа · ЗЯ → ВКС · [S]

Предусловия	У ПВЗ заданы `packageMinWeight`, `packageMaxWeight` и предельные габариты.
Шаги	ЗЯ создаёт заказ на этот ПВЗ с посылкой, выходящей за ограничения по весу или габаритам.
Ожидаемый результат	`400` с внятным сообщением. Заказ не создан, ограничения справочника реально применяются.

Приложение А: Что должно быть готово до старта

Доступен демо-стенд, известен базовый URL по каждой стране присутствия, наши IP разрешены.
Реализован POST /api/v1/auth/login, выданы логин и пароль для ЗЯ (пароль: буквы обоих регистров, цифры, спецсимволы, > 12 символов).
Получены от нас учётные данные для доступа к ЕАПИ ЗЯ.
Согласован код курьерской службы deliveryServiceCode (короткая регистрозависимая строка) и коды тарифов courierTariffCode.
Реализованы методы на стороне ВКС: POST /api/v1/orders, GET /api/v1/orders/{orderNumber}/history, PATCH /api/v1/orders/{orderNumber} (перенос даты), POST /api/v1/orders/{orderNumber}/cancel, GET /api/v1/pickpoints.
Настроена отправка в ЕАПИ ЗЯ: PUT /api/v1/orders/{orderNumber} (статусы), PATCH /api/v1/orders/{orderNumber} (перенос даты), POST /api/v1/orders/{orderNumber}/cancel и /reopen, POST /api/v1/pickpoints/add, PUT /api/v1/pickpoints/{pickpointId}/update.
Согласован маппинг внутренних статусов ВКС на коды справочника статусов заказа и справочника статусов отмен, включая транзитные и возвратные.
Подготовлены тестовые данные: 2 адреса отправителя, 1–3 адреса получателя (gar, coord, custom — в зависимости от того, какие реализует ВКС), минимум 2 действующих ПВЗ.
Назначен ответственный инженер на стороне ВКС и канал оперативной связи на период прогона.

Приложение Б: Общие требования к интеграции

Коды и формат ошибок	400 — не переданы или некорректно заполнены обязательные поля; 401 — Token is invalid; 403 — Has no permission; 404 — Resource not found (метод истории статусов); 500 — только реальные сбои. Тело ошибки при создании заказа — `errorMessage` (+ `errorCode` для адресных ошибок), в остальных методах — `error`.
Время ответа	Синхронные методы (авторизация, создание заказа, справочник ПВЗ) — в пределах согласованного SLA.
Устойчивость к повторам	Повторная отправка одного запроса не приводит к дублям заказов, статусов или ПВЗ; при 5xx и таймаутах повтор выполняется с задержкой.
Недоступность партнёра	При недоступности ЕАПИ ЗЯ статусы и события ставятся в очередь и досылаются после восстановления, без потерь и нарушения хронологии.
Часовые пояса	Все временные штампы — UTC с нулевым смещением; сдвигов дат на границе суток нет.

Приложение В: Порядок проведения и критерии завершения

Порядок

входной чек-лист (Приложение А);
auth-1 … auth-9;
order-1 … order-9;
status-1 … status-11;
data-1 … data-6 и cancel-1 … cancel-9;
PVZ-1 … PVZ-7;
сквозные прогоны status-5 на трёх моделях (курьер, ПВЗ, отмена);
разбор дефектов и повторный прогон затронутых кейсов.

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

все кейсы разделов 1–6 выполнены, результат зафиксирован;
100% пройденных кейсов по блокам auth, order, status;
блокирующие и критичные дефекты закрыты и перепроверены;
расхождений в данных заказа между ИС ЗЯ и ИС ВКС по сквозным прогонам нет;
согласован и подтверждён маппинг статусов и кодов ошибок.

Приложение Г: Справочник статусов заказа

Таблица ниже содержит допустимые (обрабатываемые ИС Золотого Яблока) статусы заказов курьерской службы, v1.9.

Описание статуса	Код статуса
Общие статусы доставки и оформления
Заказ создан в ИС ВКС, требует дополнительной валидации	ECS_ORDER_CREATED
Заказ принят к исполнению, валидации пройдены	ECS_ORDER_ACCEPTED
Заказ прибыл в город назначения (или на ПВЗ), ожидает назначения курьера	ECS_ORDER_READY_FOR_APPOINTMENT
Курьер назначен на заказ	ECS_COURIER_APPOINTED
Заказ выдан на доставку, курьер в пути	ECS_ORDER_TAKEN_BY_COURIER
Зафиксирована попытка доставки заказа (новое в v1.9)	ECS_DELIVERY_ATTEMPT
Заказ выдан курьером на примерку	ECS_ORDER_GIVEN_TO_TRY_ON
Заказ готов к выдаче клиенту на ПВЗ	ECS_ORDER_READY_TO_PICK_UP
Заказ доставлен клиенту полностью	ECS_ORDER_DELIVERED
Заказ доставлен клиенту частично	ECS_ORDER_DELIVERED_PARTIALLY
Консолидация и транзит (прямой процесс)
Сдан перевозчику ВКС на складе отгрузки	ECS_ORDER_TAKEN_FROM_SHIPMENT_WAREHOUSE
Первая фактическая приёмка на складе ВКС	ECS_ORDER_FIRST_ACCEPTANCE
Отправлен на транзитный хаб ВКС	ECS_ORDER_SENT_TO_TRANSIT_CITY
Зарегистрирован в транзитном хабе ВКС	ECS_ORDER_ACCEPTED_IN_TRANSIT_CITY_HUB
Возвратный процесс
Заказ возвращён на склад ВКС	ECS_RETURN_FIRST_ACCEPTANCE
Отправлен на транзитный хаб ВКС	ECS_RETURN_SENT_TO_TRANSIT_CITY
Зарегистрирован в транзитном хабе ВКС	ECS_RETURN_ACCEPTED_IN_TRANSIT_CITY_HUB
Направляется на склад возврата	ECS_RETURN_ON_THE_WAY_TO_WAREHOUSE
Доставлен на склад возврата	ECS_RETURN_DELIVERED_TO_WAREHOUSE

Приложение Д: Справочник статусов отмен

Таблица ниже содержит допустимые статусы отмен заказов для курьерской службы, v1.9.

Причина отмены	Сообщение об отмене
Повреждение товара или посылки на складе оператора	ECS_WAREHOUSE_DAMAGED
Ошибка при доставке: неверный адрес или получатель	ECS_LOGISTIC_ERROR
Невозможность доставки в срок	ECS_FAILED_FORWARDING
Проблема с курьером (болезнь, забастовка и т.д.). Только для экспресс-заказов.	ECS_COURIER_UNAVAILABLE
Отказ по инициативе Золотого Яблока через АПИ	GA_CANCEL_REQUEST
Клиент отменил заказ явно или неявно (перенесён из статусов заказа в v1.9)	ECS_ORDER_NOT_DELIVERED
Клиент отказался до отгрузки в КС	CUSTOMER_CANCELED
Клиент отказался от получения во время доставки	CUSTOMER_DECLINED
Превышено количество попыток доставки	CUSTOMER_UNAVAILABLE
Просрочен срок хранения у оператора	CUSTOMER_EXPIRED_ON_HOLD
ВКС не смогла провести платёж (терминал)	PAYMENT_UNAVAILABLE_DUE_TO_ECS
Клиент отозвал платёж	PAYMENT_CANCELED_BY_CUSTOMER
Невозможность доставки из-за погоды	UNTRANSPORTABLE_WEATHER
Авария или ЧП на транспортной точке	TRANSPORT_EMERGENCY_STOP

Приложение Е: Коды ошибок адресов

Коды ошибок, передаваемые курьерской службой при проблемах с созданием заказа на их стороне, v1.9.

Код ошибки	Тип данных	Обязательность	Описание	Пример
Addr_01	string	при наступлении события	Ошибка в адресе отправителя, переданном в ВКС	"errorCode": "Addr_01"
Addr_02	string	при наступлении события	Ошибка в адресе получателя, переданном в ВКС	"errorCode": "Addr_02"

Общая информация​

Как читать сценарии​

Общие правила взаимодействия​

Единые коды ответов защищённых методов​

1. Механизм аутентификации и безопасности​

auth-1 · Успешная авторизация ВКС в сервисе ЕАПИ ЗЯ · ВКС → ЗЯ · [C]​

auth-2 · Успешная авторизация ЕАПИ ЗЯ в сервисе ВКС · ЗЯ → ВКС · [S]​

auth-3 · Неуспешная авторизация в сервисе ВКС с неверными учётными данными · ЗЯ → ВКС · [S]​

auth-4 · Неуспешная авторизация с отсутствующим обязательным полем · ЗЯ → ВКС · [S]​

auth-5 · Вызов защищённого метода с невалидным токеном · ЗЯ → ВКС · [S]​

auth-6 · Вызов метода с истёкшим токеном · ЗЯ → ВКС · [S]​

auth-7 · Вызов метода без заголовка Authorization · ЗЯ → ВКС · [S]​

auth-8 · Перевыпуск токена после 401 · ВКС → ЗЯ · [C]​

auth-9 · Разделение экземпляров по странам · ЗЯ → ВКС · [S]​

2. Основной сценарий передачи заказа из ЗЯ в ВКС​

order-1 · Успешное создание нового заказа (первая отправка) · ЗЯ → ВКС · [S]​

order-2 · Успешное создание заказа с доставкой в ПВЗ (если имеется) · ЗЯ → ВКС · [S]​

order-3 · Создание заказа с ошибкой в адресе отправителя (Addr_01) и получателя (Addr_02) · ЗЯ → ВКС · [S]​

order-4 · Попытка создания заказа без обязательного поля · ЗЯ → ВКС · [S]​

order-5 · Создание заказа с разными типами адресов (gar, coord, custom), с которыми работает ВКС · ЗЯ → ВКС · [S]​

order-6 · Создание заказа с разными видами оплат · ЗЯ → ВКС · [S]​

order-7 · Некорректный deliveryServiceCode или courierTariffCode · ЗЯ → ВКС · [S]​

order-8 · Повторная отправка того же orderNumber (идемпотентность) · ЗЯ → ВКС · [S]​

order-9 · Необязательные поля переданы пустыми · ЗЯ → ВКС · [S]​

3. Жизненный цикл заказа через обмен статусами​

status-1 · Успешное обновление статуса заказа ВКС → ЗЯ · [C]​

status-2 · Успешное обновление финального статуса (доставлен) · ВКС → ЗЯ · [C]​

status-3 · Запрос истории статусов по заказу · ЗЯ → ВКС · [S]​

status-4 · История по несуществующему заказу и статус с невалидным кодом · ЗЯ ⇄ ВКС · [S+C]​

status-5 · Связка: создание → статус → история · ЗЯ ⇄ ВКС · [S+C]​

status-6 · Полная статусная модель прямого процесса · ВКС → ЗЯ · [C]​

status-7 · Статусная модель доставки до ПВЗ · ВКС → ЗЯ · [C]​

status-8 · Статусы возвратного процесса · ВКС → ЗЯ · [C]​

status-9 · Статус по несуществующему заказу · ВКС → ЗЯ · [C]​

status-10 · Скорость доставки статусов · ВКС → ЗЯ · [C]​

status-11 · Попытка доставки · ВКС → ЗЯ · [C]​

4. Сценарии переноса сроков доставки​

data-1 · Успешный перенос даты по инициативе ЗЯ · ЗЯ → ВКС · [S]​

data-2 · Успешный перенос даты по инициативе ВКС · ВКС → ЗЯ · [C]​

data-3 · Неуспешный перенос даты по инициативе ЗЯ · ЗЯ → ВКС · [S]​

data-4 · Отказ в переносе даты (некорректный статус заказа) · ЗЯ ⇄ ВКС · [S+C]​

data-5 · Перенос даты ВКС без указания причины · ВКС → ЗЯ · [C]​

data-6 · Согласованность данных после переноса · ЗЯ ⇄ ВКС · [S+C]​

5. Сценарии отмены заказа обеими сторонами​

cancel-1 · Успешная отмена заказа по инициативе ЗЯ · ЗЯ → ВКС · [S]​

cancel-2 · Успешная отмена заказа по инициативе ВКС · ВКС → ЗЯ · [C]​

cancel-3 · Отказ от отмены заказа (reopen) · ВКС → ЗЯ · [C]​

cancel-4 · Автоматическая отмена после таймаута · ВКС → ЗЯ · [C]​

cancel-5 · Отмена уже доставленного заказа · ЗЯ ⇄ ВКС · [S+C]​

cancel-6 · Статус отмены без вызова метода отмены · ВКС → ЗЯ · [C]​

cancel-7 · Повторная отмена уже отменённого заказа · ЗЯ → ВКС · [S]​

cancel-8 · Reopen после отмены по инициативе ЗЯ · ВКС → ЗЯ · [C]​

cancel-9 · Reopen после истечения 2 часов · ВКС → ЗЯ · [C]​

6. Синхронизация данных о пунктах выдачи (если они имеются у ВКС)​

PVZ-1 · Успешное получение полного справочника ПВЗ · ЗЯ → ВКС · [S]​

PVZ-2 · Успешное добавление нового ПВЗ в справочник · ВКС → ЗЯ · [C]​

PVZ-3 · Успешное изменение данных существующего ПВЗ · ВКС → ЗЯ · [C]​

PVZ-4 · Попытка добавить ПВЗ с уже существующим id · ВКС → ЗЯ · [C]​

PVZ-5 · Изменение несуществующего ПВЗ · ВКС → ЗЯ · [C]​

PVZ-6 · Заказ в закрытый или недоступный ПВЗ · ЗЯ → ВКС · [S]​

PVZ-7 · Соответствие ограничений ПВЗ параметрам заказа · ЗЯ → ВКС · [S]​

Приложение А: Что должно быть готово до старта​

Приложение Б: Общие требования к интеграции​

Приложение В: Порядок проведения и критерии завершения​

Порядок​

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

Приложение Г: Справочник статусов заказа​

Приложение Д: Справочник статусов отмен​

Приложение Е: Коды ошибок адресов​

Общая информация

Как читать сценарии

Общие правила взаимодействия

Единые коды ответов защищённых методов

1. Механизм аутентификации и безопасности

auth-1 · Успешная авторизация ВКС в сервисе ЕАПИ ЗЯ · ВКС → ЗЯ · [C]

auth-2 · Успешная авторизация ЕАПИ ЗЯ в сервисе ВКС · ЗЯ → ВКС · [S]

auth-3 · Неуспешная авторизация в сервисе ВКС с неверными учётными данными · ЗЯ → ВКС · [S]

auth-4 · Неуспешная авторизация с отсутствующим обязательным полем · ЗЯ → ВКС · [S]

auth-5 · Вызов защищённого метода с невалидным токеном · ЗЯ → ВКС · [S]

auth-6 · Вызов метода с истёкшим токеном · ЗЯ → ВКС · [S]

auth-7 · Вызов метода без заголовка Authorization · ЗЯ → ВКС · [S]

auth-8 · Перевыпуск токена после 401 · ВКС → ЗЯ · [C]

auth-9 · Разделение экземпляров по странам · ЗЯ → ВКС · [S]

2. Основной сценарий передачи заказа из ЗЯ в ВКС

order-1 · Успешное создание нового заказа (первая отправка) · ЗЯ → ВКС · [S]

order-2 · Успешное создание заказа с доставкой в ПВЗ (если имеется) · ЗЯ → ВКС · [S]

order-3 · Создание заказа с ошибкой в адресе отправителя (Addr_01) и получателя (Addr_02) · ЗЯ → ВКС · [S]

order-4 · Попытка создания заказа без обязательного поля · ЗЯ → ВКС · [S]

order-5 · Создание заказа с разными типами адресов (gar, coord, custom), с которыми работает ВКС · ЗЯ → ВКС · [S]

order-6 · Создание заказа с разными видами оплат · ЗЯ → ВКС · [S]

order-7 · Некорректный deliveryServiceCode или courierTariffCode · ЗЯ → ВКС · [S]

order-8 · Повторная отправка того же orderNumber (идемпотентность) · ЗЯ → ВКС · [S]

order-9 · Необязательные поля переданы пустыми · ЗЯ → ВКС · [S]

3. Жизненный цикл заказа через обмен статусами

status-1 · Успешное обновление статуса заказа ВКС → ЗЯ · [C]

status-2 · Успешное обновление финального статуса (доставлен) · ВКС → ЗЯ · [C]

status-3 · Запрос истории статусов по заказу · ЗЯ → ВКС · [S]

status-4 · История по несуществующему заказу и статус с невалидным кодом · ЗЯ ⇄ ВКС · [S+C]

status-5 · Связка: создание → статус → история · ЗЯ ⇄ ВКС · [S+C]

status-6 · Полная статусная модель прямого процесса · ВКС → ЗЯ · [C]

status-7 · Статусная модель доставки до ПВЗ · ВКС → ЗЯ · [C]

status-8 · Статусы возвратного процесса · ВКС → ЗЯ · [C]

status-9 · Статус по несуществующему заказу · ВКС → ЗЯ · [C]

status-10 · Скорость доставки статусов · ВКС → ЗЯ · [C]

status-11 · Попытка доставки · ВКС → ЗЯ · [C]

4. Сценарии переноса сроков доставки

data-1 · Успешный перенос даты по инициативе ЗЯ · ЗЯ → ВКС · [S]

data-2 · Успешный перенос даты по инициативе ВКС · ВКС → ЗЯ · [C]

data-3 · Неуспешный перенос даты по инициативе ЗЯ · ЗЯ → ВКС · [S]

data-4 · Отказ в переносе даты (некорректный статус заказа) · ЗЯ ⇄ ВКС · [S+C]

data-5 · Перенос даты ВКС без указания причины · ВКС → ЗЯ · [C]

data-6 · Согласованность данных после переноса · ЗЯ ⇄ ВКС · [S+C]

5. Сценарии отмены заказа обеими сторонами

cancel-1 · Успешная отмена заказа по инициативе ЗЯ · ЗЯ → ВКС · [S]

cancel-2 · Успешная отмена заказа по инициативе ВКС · ВКС → ЗЯ · [C]

cancel-3 · Отказ от отмены заказа (reopen) · ВКС → ЗЯ · [C]

cancel-4 · Автоматическая отмена после таймаута · ВКС → ЗЯ · [C]

cancel-5 · Отмена уже доставленного заказа · ЗЯ ⇄ ВКС · [S+C]

cancel-6 · Статус отмены без вызова метода отмены · ВКС → ЗЯ · [C]

cancel-7 · Повторная отмена уже отменённого заказа · ЗЯ → ВКС · [S]

cancel-8 · Reopen после отмены по инициативе ЗЯ · ВКС → ЗЯ · [C]

cancel-9 · Reopen после истечения 2 часов · ВКС → ЗЯ · [C]

6. Синхронизация данных о пунктах выдачи (если они имеются у ВКС)

PVZ-1 · Успешное получение полного справочника ПВЗ · ЗЯ → ВКС · [S]

PVZ-2 · Успешное добавление нового ПВЗ в справочник · ВКС → ЗЯ · [C]

PVZ-3 · Успешное изменение данных существующего ПВЗ · ВКС → ЗЯ · [C]

PVZ-4 · Попытка добавить ПВЗ с уже существующим id · ВКС → ЗЯ · [C]

PVZ-5 · Изменение несуществующего ПВЗ · ВКС → ЗЯ · [C]

PVZ-6 · Заказ в закрытый или недоступный ПВЗ · ЗЯ → ВКС · [S]

PVZ-7 · Соответствие ограничений ПВЗ параметрам заказа · ЗЯ → ВКС · [S]

Приложение А: Что должно быть готово до старта

Приложение Б: Общие требования к интеграции

Приложение В: Порядок проведения и критерии завершения

Порядок

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

Приложение Г: Справочник статусов заказа

Приложение Д: Справочник статусов отмен

Приложение Е: Коды ошибок адресов