[QUOTE]
wainer написал:
как запретить пользователю менять email при оформления покупки[/QUOTE]
Программирование + настройки. Есть пользователь сайта, есть профиль покупателя. Вот с этим и нужно разбираться. И решение будет зависеть от версии компоненты оформления заказа и факта конвертации магазина. Сходу не скажешь, нужно просто сесть и сделать.
[QUOTE]
wainer написал:
Вся проблема в том что на синхронизации с 1с я поставил определения физ лиц по emailу)[/QUOTE]
Наверняка Вы не одиноки во вселенной. Правда, вот что интересно - генерация ИД покупателя не зависит от того, что оный вколотил в профиле покупателя (в форме заказа):[CODE]if (IntVal($arOrder["USER_ID"]) > 0)
{
$dbUser = CUser::GetByID($arOrder["USER_ID"]);
if ($arUser = $dbUser->Fetch())
$arProp["USER"] = $arUser;
}
[/CODE][CODE]<<?=GetMessage("SALE_EXPORT_ID")?>><?=htmlspecialcharsbx(substr($arOrder["USER_ID"]."#".$arProp["USER"]["LOGIN"]."#".$arProp["USER"]["LAST_NAME"]." ".$arProp["USER"]["NAME"]." ".$arProp["USER"]["SECOND_NAME"], 0, 80))?></<?=GetMessage("SALE_EXPORT_ID")?>>[/CODE]
Вот и пример со "служебным пользователем" (используется на сильно кастомизированном сайте для заказов неавторизованных пользователей):[QUOTE]<Ид>100#serviceuser#Пользователь Служебный</Ид>
[/QUOTE]
Вот такой ИД контрагента используется ...
Вы сначала по email сопоставляете, а потом по ИД? Ну так и пусть. Есть примеры, когда сопоставляют по номеру телефона (надежнее, говорят).
В Битрикс на каждого пользователя сайта может приходиться с десяток профилей покупателя (это штатный функционал). Более того, он может делать заказы от имени физлица и юрлица. И даже больше - разных физлиц и юрлиц. Стоит ли с этим бороться? Почему внуку Васе нельзя сделать заказ от имени бабушки Марьи Петровны с ее домашним адресом, ее телефоном и липовым email (потому что сайт просит)? Бабушка получит и оплатит, это она клиент.