Почему у справочников в 1С отсутствует реквизит Код и как идентифицировать элементы

При переходе на современные прикладные решения линейки 1С (1С:Комплексная автоматизация 2, 1С:ERP, 1С:Управление торговлей 11) разработчики и аналитики часто сталкиваются с ситуацией, когда у ключевых справочников (например, Контрагенты, ДоговорыКонтрагентов) длина стандартного реквизита Код установлена равной 0. Разберем причины такого архитектурного решения, ограничения платформы и практические способы поиска и идентификации элементов в коде и отчетах.

Архитектурные причины отказа от автокодирования

Установка длины кода равной нулю в прикладных решениях нового поколения обусловлена тремя ключевыми факторами:

1. Разделение управленческого и регламентированного контуров. В системе реализовано четкое разграничение понятий. Справочник Партнеры отражает управленческий контур (холдинг, группа компаний, торговая сеть) — для него кодирование сохранено. Справочник Контрагенты используется строго для регламентированного учета и представляет собой конкретное юридическое или физическое лицо, для которого естественными идентификаторами служат государственные реквизиты: ИНН, КПП, ОГРН. Договоры, в свою очередь, естественным образом идентифицируются связкой реквизитов Номер и Дата.
2. Повышение производительности и масштабируемости. Стандартный механизм платформы при генерации очередного кода элемента накладывает транзакционную блокировку на таблицу нумератора. В высоконагруженных системах с интенсивным созданием контрагентов и договоров (например, при массовой загрузке данных или одновременной работе сотен пользователей) отказ от числового кодирования устраняет конфликты блокировок.
3. Снижение риска коллизий при обмене данными. При использовании распределенных информационных баз (РИБ) и гетерогенных интеграций автонумерация кодов нередко приводила к наложению префиксов и задвоению кодов при слиянии информации из разных узлов.

Ограничения платформы при нулевой длине кода

Проанализируем технические нюансы работы с такими объектами метаданных:

1. Ошибки проверки метаданных. Если в конфигураторе для справочника задана длина кода 0, необходимо убедиться, что стандартный реквизит Код исключен из свойства Способы поиска / Ввод по строке. В противном случае платформа выдаст критическую ошибку при обновлении конфигурации базы данных.
2. Недоступность стандартного метода. Вызов метода платформы НайтиПоКоду() для справочников с нулевой длиной кода становится невозможным и вызывает исключительную ситуацию.

Программный поиск и сопоставление данных

Рассмотрим, как правильно организовать программный поиск элементов без использования метода НайтиПоКоду().

Для поиска контрагентов в коде модулей используем поиск по реквизитам ИНН и КПП через запрос либо метод НайтиПоРеквизиту():

// Поиск контрагента по ИНН и КПП с помощью запроса
Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |	Контрагенты.Ссылка КАК Контрагент
    |ИЗ
    |	Справочник.Контрагенты КАК Контрагенты
    |ГДЕ
    |	Контрагенты.ИНН = &ИНН
    |	И (&КПП = """" ИЛИ Контрагенты.КПП = &КПП)";

Запрос.УстановитьПараметр("ИНН", ИскомыйИНН);
Запрос.УстановитьПараметр("КПП", ИскомыйКПП);

Выборка = Запрос.Выполнить().Выбрать();
Если Выборка.Следующий() Тогда
    НайденныйКонтрагент = Выборка.Контрагент;
КонецЕсли;

Для договоров контрагентов поиск выполняется с учетом владельца и основных реквизитов документа:

// Поиск договора по номеру, дате и контрагенту
Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |	ДоговорыКонтрагентов.Ссылка КАК Договор
    |ИЗ
    |	Справочник.ДоговорыКонтрагентов КАК ДоговорыКонтрагентов
    |ГДЕ
    |	ДоговорыКонтрагентов.Владелец = &Владелец
    |	И ДоговорыКонтрагентов.Организация = &Организация
    |	И ДоговорыКонтрагентов.Номер = &Номер
    |	И ДоговорыКонтрагентов.Дата = &Дата";

Запрос.УстановитьПараметр("Владелец", КонтрагентСсылка);
Запрос.УстановитьПараметр("Организация", ОрганизацияСсылка);
Запрос.УстановитьПараметр("Номер", НомерДоговора);
Запрос.УстановитьПараметр("Дата", ДатаДоговора);

Результат = Запрос.Выполнить();

Идентификация в интеграциях и обменах

При передаче данных между базами 1С и внешними системами сопоставление объектов выполняется следующими способами:

1. Уникальный идентификатор (UUID / GUID). В механизмах EnterpriseData и планах обмена ключевой сущностью является неизменный системный идентификатор ссылки.
2. Служебные поля идентификации. В рамках типовых подсистем БСП сопоставление выполняется по комбинациям бизнес-полей: ИНН + КПП + Наименование.

Идентификация элементов и борьба с дублями в отчетах

Если в системе заведены одноименные элементы и требуется однозначно разделить их при формировании отчетов, используем следующие приемы:

1. Настройка группировок схемы компоновки данных (СКД). Чтобы строки с одинаковыми наименованиями не схлопывались в одну запись, в группировку отчета необходимо выводить системное поле Ссылка, а не только строковое наименование.
2. Добавление естественных идентификаторов. В состав выводимых колонок отчета добавляем поля ИНН, КПП, код связанного партнера (Партнер.Код), либо Номер и Дата для договоров.
3. Инструменты контроля качества. Для выявления и слияния ошибочно созданных записей применяем типовую обработку Поиск и удаление дублей, настроив правила поиска совпадений по ИНН и КПП.