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