Покупатель дошёл до последнего шага, ввёл телефон как «8 900 123 4567», нажал «Оформить» — и получил красную ошибку «Неверный формат номера». Он раздражённо стирает, вводит заново, снова ошибка. Часть таких людей просто закрывает вкладку. На последнем шаге оформления заказа каждая мелочь стоит денег, и небрежный ввод контактов — одна из самых обидных причин потерять уже почти оформленный заказ.
Эта статья — о том, как настроить маски ввода для телефона, ИНН, индекса и других полей формы заказа в 1С-Битрикс так, чтобы покупателю было легко, а данные приходили чистыми. Разберём, где живут поля заказа, чем клиентская маска отличается от серверной валидации, как не сломать мобильный ввод и автозаполнение. Если форма заказа у вас перегружена и «тормозит» продажи, поможет аудит и оптимизация 1С и связанных с ней процессов оформления.
Коротко
- Маска — это удобство ввода и подсказка формата; хранить телефон нужно нормализованным (только цифры).
- Клиентская маска на JS не заменяет серверную проверку — их всегда используют в паре.
- На мобильных задавайте inputmode/type, чтобы сразу открывалась цифровая клавиатура.
- Маски для ИНН, КПП, индекса и дат снижают число ошибок и заказов «на уточнение».
Зачем нужны маски ввода
Маска ввода — это шаблон, который подсказывает и ограничивает формат данных прямо в поле. Для телефона это «+7 (___) ___-__-__»: пользователь видит скелет номера, вводит только цифры, а скобки и дефисы подставляются сами. Маска решает сразу несколько задач: убирает разночтения формата, отсекает опечатки и лишние символы, снимает у человека вопрос «а как тут писать».
Для формы заказа это особенно важно, потому что данные оттуда идут дальше — в 1С, в CRM, в SMS-уведомления и в звонок менеджера. Грязный телефон вроде «позвоните после 18» в поле номера означает, что заказ не дозвонится автоматически, а менеджер потратит время. Маска не даёт ввести в поле телефона ничего, кроме телефона.
Где живут поля формы заказа в Битрикс
В 1С-Битрикс поля, которые заполняет покупатель на оформлении, — это свойства заказа модуля «Интернет-магазин». Настраиваются они в разделе Магазин → Настройки → Свойства заказа: там задаётся название, тип (строка, число, местоположение, файл), обязательность, группа и порядок. Именно здесь вы решаете, какие поля вообще увидит клиент.
Сам ввод рисует компонент оформления заказа — как правило, sale.order.ajax в шаблоне вашего решения. Он выводит свойства заказа по их настройкам. Маску подключают уже в шаблоне компонента: к нужным полям добавляют атрибуты и инициализируют JavaScript-библиотеку маски. То есть логика полей — в свойствах заказа, а поведение ввода — в шаблоне компонента.
- Свойства заказа — какие поля есть и обязательны ли они.
- Компонент оформления — как поля выводятся и ведут себя.
- Шаблон компонента — где подключается маска и клиентская валидация.
Телефон: формат, +7 и хранение
Телефон — главное поле, из-за которого чаще всего спорят. Ключевое правило: отображение и хранение — это разные вещи. Покупателю показывайте удобную маску «+7 (900) 123-45-67», а в заказе храните нормализованное значение — только цифры, например 79001234567. Тогда номер из формы, из 1С и из CRM всегда сопоставим, и клиент не задваивается из-за разного написания.
Отдельно решите вопрос международных номеров. Жёсткая российская маска мешает ввести иностранный телефон. Если такие заказы — редкость, оставьте российскую маску и предусмотрите режим «другой формат». Если их много, добавьте выбор кода страны с разными масками или мягкую проверку по числу цифр.
Клиентская маска против серверной валидации
Маска на JavaScript — это про удобство, а не про безопасность данных. Её можно обойти: отключить JS, отправить запрос напрямую, вставить значение программно. Поэтому корректность обязательно проверяют ещё раз на сервере, перед сохранением заказа. Клиентская маска и серверная валидация закрывают разные риски и работают вместе.
| Аспект | Клиентская маска (JS) | Серверная валидация (PHP) |
|---|---|---|
| Задача | Удобство и подсказка формата | Гарантия корректности данных |
| Когда срабатывает | При вводе, мгновенно | При сохранении заказа |
| Можно обойти | Да (отключить JS) | Нет |
| Что проверяет | Формат и допустимые символы | Формат, длину, контрольные суммы |
| Где живёт | Шаблон компонента | Обработчик события sale |
Практический вывод: никогда не полагайтесь только на маску. Даже идеально настроенная маска не защитит заказ от невалидного телефона или ИНН, если кто-то отправит форму в обход. Серверная проверка — обязательный второй рубеж.
inputmode и удобство на мобильных
Больше половины заказов сегодня оформляют с телефона, и здесь маска — только половина дела. Вторая половина — правильная клавиатура. Если у поля телефона не задан тип или inputmode, смартфон открывает обычную буквенную клавиатуру, и пользователь ищет цифры. Это лишнее трение ровно там, где его быть не должно.
- Телефон —
type="tel"илиinputmode="tel": открывается цифровая клавиатура с решёткой и звёздочкой. - Индекс, номер дома —
inputmode="numeric": только цифры. - Email —
type="email": клавиатура с «@» и «.». - ИНН, КПП —
inputmode="numeric": числовой ввод без букв.
Эти атрибуты почти ничего не стоят по трудозатратам, но заметно ускоряют заполнение формы на мобильном. В связке с маской они дают тот самый эффект «форма заполняется сама».
ИНН, КПП, индекс, дата и другие поля
Телефон — не единственное поле, где маска экономит нервы. В B2B-заказах и доставке масок заслуживают ещё несколько полей:
- ИНН. 10 цифр у юрлица, 12 у ИП. Маска отсекает лишнее, а серверная проверка контрольных цифр не пускает синтаксически неверный номер.
- КПП. Ровно 9 знаков по своему формату — маска не даёт ошибиться в длине.
- Почтовый индекс. 6 цифр; маска и
inputmode="numeric"убирают буквы. - Дата доставки. Маска «__.__.____» плюс проверка, что дата не в прошлом.
- Номер карты лояльности. Фиксированная длина с разбивкой по группам для читаемости.
Для оптовых форм это особенно ценно: реквизиты юрлица, введённые чисто, сразу уходят в 1С без ручной правки. Если реквизиты и договоры вы уже автоматизируете, логично довести до автомата и их проверку — это часть автоматизации продаж и склада на 1С.
Автозаполнение и вставка из буфера
Частая беда неаккуратной маски — конфликт с автозаполнением браузера и вставкой из буфера. Пользователь нажимает «подставить номер», а маска перекраивает вставленное значение или обрезает его до неузнаваемости. То же с копипастом реквизитов из письма. В итоге удобная, казалось бы, маска начинает мешать.
Хорошая маска обрабатывает не только посимвольный ввод, но и события вставки и программного заполнения поля: принимает готовое значение целиком и приводит его к нужному виду. Проверяйте это отдельно — вставьте номер из буфера, воспользуйтесь автозаполнением, заполните форму менеджером через админку. Если хоть где-то значение ломается, маску нужно доработать, а не оставлять «как есть».
Как подключить маску в свойстве заказа
Сборка масок в оформлении заказа 1С-Битрикс — понятная последовательность. Названия пунктов зависят от редакции, но логика такая:
- Проверьте свойства заказа. В Магазин → Настройки → Свойства заказа задайте типы полей (телефон, ИНН, индекс) и обязательность.
- Подключите библиотеку маски. В шаблоне компонента оформления добавьте JS-библиотеку масок (лёгкую, без тяжёлых зависимостей).
- Разметьте поля. К нужным полям добавьте атрибуты с шаблоном маски и корректные
type/inputmode. - Инициализируйте после AJAX. Оформление перерисовывается через AJAX, поэтому маску переинициализируйте после каждого обновления шага.
- Нормализуйте перед отправкой. Перед сохранением приведите телефон и реквизиты к чистому виду.
- Проверьте на всех сценариях. Ввод вручную, вставка, автозаполнение, мобильная клавиатура, отключённый JS.
Инициализация после AJAX — самый частый источник багов: маска работает на первом рендере и «отваливается» после смены шага доставки или оплаты. Об архитектуре современного кода под такие доработки мы писали в материале про D7 и ORM в 1С-Битрикс.
Серверная валидация через события D7
Серверная проверка полей заказа вешается на события модуля продаж. Перед сохранением заказа обработчик получает данные, проверяет телефон, ИНН и другие поля и при ошибке не даёт оформить заказ, вернув понятное сообщение. Здесь же удобно нормализовать телефон и реквизиты — привести к единому виду до того, как они уйдут в базу и в 1С.
Такой обработчик — это небольшой кастомный код, аккуратно подключённый к событиям, а не правки ядра. Если проверок много (контрольные суммы ИНН, форматы, справочники), их логично оформить как отдельный модуль или сервис — тогда код тестируем и переносим между проектами. Подходы к структуре такого кода мы разбирали в статье про разработку своего модуля для 1С-Битрикс.
Влияние на конверсию корзины
Маски и валидация — это не косметика, а работа над конверсией последнего шага. Эффект складывается из нескольких вещей:
- Меньше ошибок ввода — меньше раздражающих красных сообщений и брошенных на них корзин.
- Меньше «мёртвых» контактов — телефон дозванивается, SMS доходит, заказ не теряется.
- Быстрее на мобильном — правильная клавиатура и подсказка формата экономят секунды на каждом поле.
- Меньше ручной работы — менеджеру не приходится чистить и уточнять реквизиты после оформления.
Отдельные проценты конверсии тут складываются в заметную сумму на потоке заказов. Маску стоит внедрять не изолированно, а в рамках общей ревизии оформления: сокращения полей, автоподстановок и упрощения шагов.
Частые ошибки
- Только маска, без серверной проверки. Форму отправляют в обход JS — и в заказ попадает мусор.
- Хранение телефона в «красивом» виде. Скобки и дефисы в базе ломают поиск клиента и обмен с 1С.
- Маска не переинициализируется после AJAX. На втором шаге оформления она перестаёт работать.
- Жёсткая маска для всех стран. Иностранный номер ввести невозможно, заказ срывается.
- Нет inputmode на мобильных. Открывается буквенная клавиатура, ввод цифр мучителен.
- Конфликт с автозаполнением. Подставленный браузером номер маска ломает.
- Непонятные сообщения об ошибке. Пользователь не понимает, что именно исправить.
Чек-лист внедрения
- Свойства заказа выверены. Поля телефона, ИНН, индекса имеют правильные типы и обязательность.
- Маски подключены. Телефон, ИНН, КПП, индекс, дата — с корректными шаблонами.
- inputmode задан. На мобильных открывается нужная клавиатура для каждого поля.
- Нормализация настроена. Телефон и реквизиты приводятся к единому виду перед сохранением.
- Серверная валидация работает. Событие sale проверяет формат и контрольные суммы, сообщения конкретны.
- AJAX-переинициализация есть. Маски живут после смены шага доставки и оплаты.
- Автозаполнение и вставка проверены. Значение из буфера и браузера не ломается.
- Протестировано на реальных устройствах. Разные браузеры, мобильные, отключённый JS.
Вывод
Маски ввода — недорогой, но заметный рычаг конверсии на самом дорогом шаге, оформлении заказа. Правильная маска подсказывает формат, отсекает опечатки и делает форму дружелюбной, а нормализация и серверная валидация гарантируют, что в заказ и в 1С придут чистые данные. Главное — не путать удобство с безопасностью: клиентская маска и серверная проверка работают только в паре.
Соберите маски для телефона, ИНН, индекса и дат, добавьте правильный inputmode для мобильных, переинициализируйте маску после AJAX и подключите серверную проверку через события. Тогда меньше заказов будет теряться на ошибках ввода, а менеджеры перестанут вручную чистить контакты и реквизиты после каждого оформления.
