Продажи физлицам и компаниям на Битрикс: как разделить данные и документы заказа

Один магазин, два покупателя

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

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

В уроке 1С-Битрикс описаны два исходных типа — физическое и юридическое лицо. Список находится в разделе «Магазин → Настройки → Типы плательщиков», где можно редактировать существующие записи и добавлять свои.

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

Общий набор полей или разные формы

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

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

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

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

Устройство полей подробнее разобрано в материале «Свойства заказа в Битрикс». Здесь существенна развилка между покупателями, а не описание каждого элемента формы.

Чем ограничивать оплату и доставку

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

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

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

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

Получатель и плательщик

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

Названия ролей лучше развести. Плательщик нужен для сведений о покупке, контактное лицо — для связи, получатель — для передачи товара, хотя в конкретном заказе эти роли могут принадлежать одному человеку.

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

Профиль покупателя и конкретный заказ тоже требуют разграничения. Сохранённые сведения ускоряют повторную покупку, однако заказчик принимает результат по самому заказу: название, контакт и реквизиты видны менеджеру там, где он готовит отгрузку. Если пользователь меняет данные в профиле, нужно выяснить судьбу уже оформленных заказов и выданных документов. Исполнитель показывает, останутся ли прежние сведения в уже оформленном заказе или изменятся вслед за профилем; компания выбирает поведение с учётом своего документооборота.

Для магазина с несколькими сайтами появляется ещё один вопрос. Битрикс позволяет привязать один тип плательщика к нескольким сайтам, поэтому одинаковое название в списке не подтверждает, что его поля и доступность подходят каждой витрине.

Документ с данными заказа

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

Нужна карта соответствий. В ней напротив реквизита в документе стоит поле заказа и сотрудник, который подтверждает смысл переноса.

При заказе от организации лучше сопоставить счёт с утверждённым образцом и проследить происхождение каждого изменяемого значения. Привычное оформление способно скрыть реквизиты из другого профиля. Содержание документа согласует профильный специалист; здесь речь о том, правильно ли сайт подставляет уже утверждённые сведения. Исполнитель показывает, откуда пришло значение, как оно исправляется и как повторно получается документ. Заказчик сверяет результат с утверждённым набором сведений.

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

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

Испытание переключения и обмена

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

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

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

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

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

Описание двух путей покупки

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

Начните с образцов результата. По документу и карточке заказа быстрее видно, каких данных не хватает, чем по отвлечённому перечню всех полей, доступных в системе.

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

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