Валидация и обязательные поля в заказе

Валидация заказа в 1С-Битрикс держится на двух уровнях: настройках свойства в админке и серверной проверке в коде. Разберём, как флаг «Обязательное», паттерн и события помогают собрать корректные данные покупателя и не пропустить мусор в CRM.

Два уровня проверки: клиент и сервер

В магазине на 1С-Битрикс данные заказа проверяются в двух местах, и путать их нельзя. Клиентская валидация — это JavaScript в компоненте sale.order.ajax: она подсвечивает поля прямо в форме, пока покупатель не ушёл со страницы. Серверная валидация срабатывает при сохранении заказа в ядре модуля sale и является последней линией обороны.

• Клиентская — удобство: мгновенная подсветка, подсказки, маски ввода.
• Серверная — надёжность: её нельзя обойти через отключённый JS, прямой POST или мобильное приложение.

Обязательные поля: флаг IS_REQUIRED

Каждое свойство заказа настраивается в Магазин → Настройки → Свойства заказа. Ключевой чекбокс — «Обязательное», в базе он хранится в поле IS_REQUIRED таблицы b_sale_order_props. Если поле обязательное, но покупатель его не заполнил, ядро не даст сохранить заказ и вернёт ошибку в результат метода save().

Важные смежные настройки того же свойства:

• Активность (ACTIVE) — выключенное свойство вообще не показывается и не проверяется.
• Показывать в профиле покупателя — влияет на автоподстановку сохранённых данных.
• Тип плательщика / служба доставки — свойство можно сделать обязательным только для отдельного профиля, тогда телефон спрашивается для курьера, но не для самовывоза.

Маски и регулярные выражения (PATTERN)

Для строковых свойств Битрикс поддерживает два поля настройки формата. Шаблон значения (PATTERN) — регулярное выражение, которому должно соответствовать введённое значение. Маска ввода помогает пользователю набирать данные в нужном виде на клиенте.

PATTERN хранится как регулярка в формате PHP-совместимого PCRE. Ядро проверяет значение методом Property::checkValue(), который вызывает preg_match по вашему шаблону. Несколько практичных примеров:

Проверка телефона и email

Телефон и email — самые ответственные поля: по ним уходят SMS, письма и звонит менеджер. Для них в Битриксе есть готовые типы свойств. При создании свойства выберите тип «E-Mail» или «Телефон» — тогда ядро само подключит соответствующую проверку и нормализацию.

• Email. Тип свойства проверяет формат адреса; дополнительно включите PATTERN, если нужна строгая маска домена.
• Телефон. Свойство типа «Телефон» приводит номер к формату E.164 через класс \Bitrix\Main\PhoneNumber\Parser. Это критично для интеграции с SMS-сервисами и CRM.

Если поле осталось обычной строкой, задайте PATTERN вручную, например для номера из 11 цифр: ^[78][0-9]{10}$. На клиенте добавьте маску, чтобы покупатель не вводил скобки и дефисы вразнобой.

Кастомная проверка на onSaleOrderBeforeSaved

Штатных настроек хватает не всегда: нужно сверить сумму с балансом, запретить доставку в регион без нужного товара или проверить ИНН по контрольной сумме. Такую логику вешают на событие onSaleOrderBeforeSaved модуля sale. Оно вызывается перед записью заказа, и через объект результата можно прервать сохранение.

Регистрируем обработчик в /local/php_interface/init.php:

use Bitrix\Main\EventManager;
EventManager::getInstance()->addEventHandler('sale', 'OnSaleOrderBeforeSaved', 'checkOrderProps');

function checkOrderProps(\Bitrix\Main\Event $event) {
  $order = $event->getParameter('ENTITY');
  $props = $order->getPropertyCollection();
  $phone = $props->getPhone();
  if ($phone && strlen(preg_replace('/\D/', '', $phone->getValue())) < 11) {
    $result = new \Bitrix\Main\Entity\EventResult();
    $result->addError(new \Bitrix\Main\Entity\EntityError('Некорректный телефон'));
    $event->addResult($result);
  }
}

Ошибка, добавленная через EventResult, останавливает $order->save() и возвращается в компонент оформления, где выводится покупателю.

Практика и типичные ошибки

Несколько рекомендаций из реальных внедрений, которые экономят часы отладки:

1. Не полагайтесь только на PATTERN. Регулярка отсекает формат, но не логику — контрольную сумму ИНН или существование региона проверяйте кодом на событии.
2. Проверяйте результат save(). Метод возвращает объект Result; всегда смотрите $result->isSuccess() и getErrorMessages(), иначе «молчаливые» ошибки уйдут в лог.
3. Синхронизируйте клиент и сервер. Если PATTERN на сервере строже, чем маска на форме, покупатель увидит непонятный отказ уже после кнопки «Оформить».
4. Тестируйте быстрый заказ. Форма «Купить в 1 клик» часто идёт мимо стандартного компонента — обязательные свойства там нужно проверять отдельно.

Итог

Надёжная валидация заказа в 1С-Битрикс — это связка настроек и кода: флаг IS_REQUIRED и PATTERN закрывают формат, специальные типы «Телефон» и «E-Mail» нормализуют данные, а событие onSaleOrderBeforeSaved добавляет бизнес-логику, которую нельзя обойти. Клиентская проверка отвечает за удобство, серверная — за чистоту данных в базе и CRM.

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