Поля заказа в Битрикс: что запрашивать у покупателя и какие поля убрать

Кому и зачем нужны данные покупателя

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

Назначение важнее привычного набора полей

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

• Указан получатель данных. Рядом с каждым полем в рабочем списке стоит роль: менеджер, бухгалтерия, служба доставки. Название отдела без описания действия мало помогает: уточните, кто звонит, печатает документ или передаёт адрес перевозчику.
• Есть момент использования. Значение требуется до создания заказа, до отправки счёта либо перед отгрузкой. Эти моменты различаются. Сведения, которые появятся только после разговора с менеджером, разумнее собирать во время обработки заказа.
• Обязательность объяснима. Для пустого поля указан конкретный отказ: нельзя рассчитать доставку, связаться с получателем или оформить выбранный документ. Желание заполнить клиентскую карточку полностью не делает каждое свойство обязательным.
• Согласованы исполнители. Маркетолог отвечает за понятность названия, сотрудник магазина подтверждает пользу данных, специалист по Битриксу связывает поле с нужным процессом. Удаление строки с экрана обсуждают с тем, кто получает её в учётной системе.

В документации Битрикса прямо указано, что универсального заранее заданного набора обязательных полей нет. Требования определяет магазин.

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

Какие свойства относятся к выбранному плательщику

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

Различия между физлицом и организацией

• Нет чужих реквизитов. Покупатель для личных нужд не заполняет организационные сведения только потому, что они нужны бухгалтерии для другой группы заказов. При переключении типа плательщика ненужный блок исчезает и больше не мешает оформить заказ.
• Названия понятны покупателю. Внутренний код свойства и его подпись на форме выполняют разные задачи. В подписи лучше назвать ожидаемые сведения обычными словами. Отдельно договоритесь, как обозначать контактное лицо и получателя, если это разные люди.
• Наборы можно сопоставить. Для каждого типа плательщика описаны поля, обязательность и получатель данных. Одинаковая подпись в двух наборах ещё не доказывает, что значения уйдут в одно и то же поле CRM или 1С.
• Переключение сохраняет разумный минимум. Контактный телефон не приходится набирать заново без причины. Реквизиты прежнего плательщика не попадают в документы нового. Ожидаемое поведение запишите заранее, поскольку нестандартная форма может потребовать доработки.

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

Настройки, которые стоит увидеть вместе с подрядчиком

Список расположен в разделе «Магазин → Настройки → Свойства заказа → Список свойств». Для создания служит кнопка «Новое свойство». Эти названия помогают найти предмет обсуждения, но заказчику полезнее получить снимок перечня и соответствие полей, чем самостоятельно менять рабочие настройки.

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

Поля доставки и оплаты появляются вовремя

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

Связи работают по правилу «хотя бы одно»

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

• Самовывоз без адреса квартиры. В тестовом заказе выбрана точка выдачи. Поля, которые относятся исключительно к доставке до двери, не блокируют продолжение. При этом сведения о получателе остаются там, где они нужны для выдачи.
• Смена доставки меняет требования. После перехода от самовывоза к курьеру появляются нужные адресные строки. Обратное переключение убирает их обязательность. Сообщение об ошибке относится к текущему выбору, а не к уже скрытому полю.
• Способ оплаты не открывает лишнее. Прогоните сочетания оплаты и доставки, особенно если свойство привязано сразу к двум спискам. Так обнаруживается ситуация, когда поле показывается для всех доставок из-за совпавшего способа оплаты.
• Расчёт доставки получает местоположение. Отдельно согласованы город или регион, по которым магазин рассчитывает доступные службы и стоимость. Их нельзя бездумно объединять со свободной строкой полного адреса.

Для свойства типа LOCATION с включённым флагом «Использовать как местоположение» документация оговаривает особое поведение: ограничения вкладки привязок не выполняются, если поле используется для расчёта доставки. Это повод разобрать расчёт с разработчиком до удаления города из формы. Город участвует в выборе услуги, а адрес квартиры может понадобиться позже. Разделение этих сведений помогает сократить ввод без потери расчёта. Скрытие строки только внешним оформлением здесь хуже настройки: покупатель её не видит, а сервер продолжает ожидать значение.

Сохранённые значения не мешают новому заказу

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

Профиль, подсказка и значение по умолчанию

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

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

Что происходит за пределами формы

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

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

Самостоятельная приёмка короткой формы

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

Результаты, которые можно зафиксировать

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

Замечание описывают через действие. Вместо «неудобные поля» в протоколе появляется запись о том, что после выбора самовывоза форма требует квартиру и не позволяет продолжить. К записи прикладывают выбранные варианты, снимок экрана и ожидаемый результат. Такой материал можно передать специалисту по доработке магазина без долгого пересказа. Если все пункты проходят, у команды остаётся не только короткая форма, но и понятная причина существования каждого её поля.

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