Как получить и проверить пустое значение уникального идентификатора в 1С

При разработке прикладных решений на платформе 1С:Предприятие разработчики часто сталкиваются с типом данных УникальныйИдентификатор. Возникает закономерный вопрос: что является значением по умолчанию (пустым значением) для данного типа, как его правильно инициализировать, проверить на заполненность и почему использование идентификаторов для связи объектов не всегда является оптимальным решением. Разберем эти вопросы подробно.

Что представляет собой пустой уникальный идентификатор

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

Его строковое представление имеет строго фиксированный вид: 00000000-0000-0000-0000-000000000000.

Конструктор Новый УникальныйИдентификатор() без переданных параметров генерирует совершенно новый псевдослучайный GUID (версии 4), поэтому использовать его для получения пустого значения нельзя.

Способы получения пустого уникального идентификатора

Рассмотрим основные способы программного получения нулевого идентификатора в коде 1С:

1. Явная инициализация через конструктор со строкой:

   Передаем в конструктор строку из 32 нулей в стандартном формате 8-4-4-4-12:

   Скопировать код

   
   ПустойИдентификатор = Новый УникальныйИдентификатор("00000000-0000-0000-0000-000000000000");
   

   Важно помнить, что конструктор крайне чувствителен к формату. Если передать строку неверной длины или с нарушением расстановки дефисов, платформа вызовет исключение «Неверный формат строки для УникальногоИдентификатора».

2. Получение через пустую ссылку любого ссылочного типа:

   У любого ссылочного метаданного пустая ссылка возвращает нулевой GUID:

   Скопировать код

   
   ПустойИдентификатор = Документы.РеализацияТоваровУслуг.ПустаяСсылка().УникальныйИдентификатор();
   

3. Десериализация через XML:

   Для универсальных механизмов сериализации и обмена данными можно использовать функцию XMLЗначение:

   Скопировать код

   
   ПустойИдентификатор = XMLЗначение(Тип("УникальныйИдентификатор"), "00000000-0000-0000-0000-000000000000");
   

Проверка уникального идентификатора на пустоту

Выясним, как наиболее надежно проверить, заполнен ли реквизит типа УникальныйИдентификатор. На практике встречаются различные подходы, но платформенный метод является самым быстрым и безопасным.

Штатная функция платформы ЗначениеЗаполнено() полностью поддерживает тип УникальныйИдентификатор. Если идентификатор равен 00000000-0000-0000-0000-000000000000, функция вернет Ложь, а для любого другого значения — Истина:

Если Не ЗначениеЗаполнено(ТекущийУИД) Тогда
    // Идентификатор не заполнен (пустой)
    Сообщить("Уникальный идентификатор пуст");
КонецЕсли;

Сравнение строкового представления идентификатора с нулевой строкой через Строка(ТекущийУИД) = "00000000-0000-0000-0000-000000000000" избыточно и работает медленнее, чем вызов ЗначениеЗаполнено().

Отображение пустого идентификатора в интерфейсе

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

1. Откроем форму документа и перейдем на вкладку Условное оформление.
2. Добавим новый элемент оформления и зададим условие: поле Объект.ЭтапыГрафикаОплаты.ИдентификаторРеализации — Не Заполнено.
3. В списке оформляемых полей укажем соответствующую колонку таблицы.
4. В параметрах оформления установим свойство Текст равным пустой строке "".

Архитектурные риски хранения GUID для связывания данных

Проанализируем типовую задачу: попытку связать строку табличной части одного документа (например, ЗаказКлиента) с другим документом (например, РеализацияТоваровУслуг) путем записи GUID реализации в реквизит строки заказа.

Такой подход несет серьезные архитектурные риски:

1. Потеря ссылочной целостности: Платформа 1С не контролирует связи по типу УникальныйИдентификатор. При поиске ссылок на удаляемый объект (через штатное удаление помеченных объектов) система не найдет использование GUID в строках табличных частей, что приведет к появлению «битых» связей.
2. Блокировки и конфликты версий: Если при проведении каждого подчиненного документа перезаписывать родительский заказ, пользователи будут постоянно сталкиваться с ошибкой «Данные были изменены или удалены другим пользователем». Кроме того, для перезаписи закрытого или проведенного заказа потребуются избыточные права доступа.
3. Сложности в запросах: В языке запросов 1С невозможно выполнить соединение или разыменование полей через реквизит типа УникальныйИдентификатор. Чтобы получить данные связанного документа, придется выполнять сложные обходные манипуляции.

Рекомендуемые альтернативы для связи данных

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

1. Прямой ссылочный реквизит: Создаем реквизит с типом ДокументСсылка.РеализацияТоваровУслуг. Это обеспечивает автоматический контроль ссылочной целостности, корректное отображение в отчете «Структура подчиненности» и возможность легкого разыменования полей в запросах.
2. Движения по регистрам (накопления или сведений): В типовых решениях (ERP, КА, УТ) связь графика оплаты и фактических отгрузок никогда не записывается в сам заказ. Связь фиксируется движениями в регистрах расчетов или выполнения заказов, где измерениями выступают Заказ, РасчетныйДокумент и КлючСтроки (или КлючСвязи). Это исключает блокировки исходного документа и обеспечивает высокую масштабируемость системы.