Заказы с сайта в 1С под одним контрагентом: как 1С узнаёт покупателя и что поменять в обмене

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

Это не сбой обмена, а его результат. Типовой обмен сайта с 1С сопоставляет покупателя из заказа с контрагентом по признакам, которые задаёт настройка в 1С, и по данным, которые передаёт сайт. Если настройка велит подставлять одну запись или сайт не передаёт того, по чему ищет 1С, все заказы сходятся в одного контрагента.

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

Кто участвует в обмене заказами и кто принимает решение о контрагенте

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

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

Файл заказа — это XML-документ. У каждого заказа в нём есть блок «Контрагенты», а внутри — покупатель: идентификатор, присвоенный сайтом (элемент Ид), наименование, роль «Покупатель» и реквизиты, которые сайт сумел заполнить: ИНН и КПП, фамилия и имя, адрес, контакты.

Контрагент в 1С — элемент справочника, к которому привязаны договоры, взаиморасчёты и история. Договор для загруженного заказа 1С ищет среди договоров с найденным контрагентом, а если подходящего нет, создаёт новый. Поэтому ошибка в контрагенте не ограничивается одной строкой: заказ уходит мимо договора клиента и мимо всего, что к этому договору привязано.

Решение, какому контрагенту достанется заказ, принимает 1С при загрузке файла. Сайт на него влияет только тем, какие данные о покупателе он кладёт в файл.

<Контрагенты>
  <Контрагент>
    <Ид>1#admin#Петров Петр</Ид>
    <Наименование>Петр Петров</Наименование>
    <Роль>Покупатель</Роль>
    <ПолноеНаименование>Петр Петров</ПолноеНаименование>
    <Фамилия>Петров</Фамилия>
    <Имя>Петр</Имя>
    <АдресРегистрации>
      …
    </АдресРегистрации>
  </Контрагент>
</Контрагенты>

Так выглядит покупатель в файле заказа: фрагмент примера из описания протокола обмена с сайтом на v8.1c.ru. ИНН в примере нет, а идентификатор собран сайтом из своих данных.

Как 1С ищет покупателя из заказа

Общее правило записано в самом протоколе: при загрузке заказа контрагент ищется по ИНН или по наименованию, в зависимости от настроек обмена. В примере файла из того же описания у покупателя есть идентификатор, наименование, фамилия, имя и адрес, а ИНН нет. Дальше каждая конфигурация и каждый модуль обмена развивают это правило по-своему.

1С:Управление нашей фирмой

В описании 1С-Софт 2012 года, то есть в ранней версии УНФ, способ сопоставления задавался полем «Способ загрузки контрагентов»: например, искать по наименованию или по ИНН + КПП, а ненайденного покупателя создать новым контрагентом. В версии 1.6.13 к признакам добавились телефон и e-mail: покупатель сопоставляется последовательно по ИНН, телефону или e-mail. В версии 1.6.15 поля поиска стали выбираться флажками, искать можно среди контрагентов и контактных лиц — до первого совпадения или по совпадению всех выбранных полей, а если никто не нашёлся, создаётся новый контрагент. Есть ли поле «Способ загрузки контрагентов» в текущей версии, открытые источники не подтверждают: сверьте настройку в своей базе.

1С:Управление торговлей, редакция 11

Сопоставление настраивается в форме узла обмена с сайтом, на закладке «Обмен заказами». Описание остальных настроек этой закладки на ИТС доступно только по подписке, поэтому дословных названий полей из документации 1С здесь нет. Инструкция CS-Cart по настройке УТ 11 называет поле «Способ поиска существующих элементов справочника Контрагенты» и советует выбирать поиск по наименованию, если в заказах из магазина нет ИНН и КПП. Откройте свою базу и сверьте название: в доработанной конфигурации оно может отличаться.

Модуль обмена 1С-Битрикс внутри 1С

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

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

Три причины, по которым все заказы оказываются под одним контрагентом

Первая: так настроено

Режим «один контрагент на все заказы с сайта» штатный, его включают осознанно. В описании УНФ 2012 года это значение «Не создавать» в поле «Способ загрузки контрагентов»: рядом появлялось поле, где выбирался контрагент, который подставлялся в загруженные заказы. Сохранилось ли это значение в текущей версии УНФ, открытые источники не подтверждают. В модуле 1С-Битрикс для УТ 11 то же делает настройка «Постоянные данные для физических лиц»: вместо создания нового контрагента в заказ физического лица подставляются заданные контрагент и соглашение.

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

Вторая: сайт не передаёт того, по чему ищет 1С

Поиск находит контрагента только по тому признаку, который пришёл в файле. Если 1С настроена искать по ИНН и КПП, а форма заказа их не спрашивает, искать нечем. Стандарт CommerceML этого не исправит: в схеме редакции 2.10 ИНН физического лица необязателен, как и сам идентификатор контрагента. В примере файла заказов из документации 1С-Битрикс поля ИНН и КПП покупателя переданы пустыми.

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

Третья: личный кабинет не связан с контрагентом

Идентификатор покупателя в файле выдаёт сайт. В примере 1С-Битрикс он собран из номера пользователя, e-mail и начала ФИО, в примере протокола — из номера, логина и имени. Схема CommerceML требует от него только глобальной уникальности и рекомендует GUID, но не говорит, какая из систем его выдаёт и где хранится соответствие идентификатора сайта карточке в 1С.

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

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

Что менять в обмене

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

Выберите признак, который сайт передаёт всегда. Для организации это ИНН и КПП: форма заказа должна их требовать при выборе «юридическое лицо», а сайт — класть их в блок покупателя, а не в комментарий. Для частного лица подходят телефон и e-mail, которые УНФ умеет использовать как признаки поиска.

Поставьте признаки по точности и почистите дубли. Первым идёт самый точный признак, наименование — последним. Дубли в справочнике проверяются до перенастройки: если по признаку нашлось несколько контрагентов, модуль 1С-Битрикс не подставляет ни одного, и заказ снова разбирают руками.

Свяжите личный кабинет с контрагентом. У зарегистрированного покупателя должен быть постоянный идентификатор, по которому 1С находит его каждый раз, а соответствие должно переживать перенос сайта и чистку базы. Это уже доработка обмена, а не переключатель в настройке, и её объём зависит от конфигурации и сайта. Для масштаба: подрядчик ИНТЕРВОЛГА в публикации 2021 года о сайтах на 1С-Битрикс пишет, что на доработку обмена с 1С можно потратить и 10, и 100 часов — это оценка подрядчика, а не норма.

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

Когда один контрагент на все заказы — нормально

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

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

И наконец, разбор описывает типовой обмен. Если конфигурация доработана, настройки узла могут называться иначе или не работать вовсе, потому что загрузку заказов переписали. Тогда источник правды — код обработки обмена в вашей базе, а не документация.

Вывод: одна запись вместо клиента — это решение настройки или нехватка данных

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

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