Собственно суть вопроса в теме.

Платформа: 1С:Предприятие 8.3 (8.3.22.1603)

Создана таблица во внешнем источнике SQL, соединение настроено, работает. При записи объекта таблицы, в SQL информация обновляется.
Создан справочник, одному из реквизитов "Реквизит1" установлен тип "ВнешнийИсточникДанныхТаблицаСсылка.СправочнаяИнформация.Контрагенты", на форму выведено поле.

В режиме предприятия на форме справочника выбираю значение этого реквизита и записываю элемент.
Открываю эту же форму справочника, а поле "Реквизит1" - пустое!

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

Прошу помочь, указать какие-то материалы, где объяснено, как организовывать такую связку.
---
После экспериментов нашёл причину такого поведения платформы:
Колонка ID в SQL имеет тип uniqueidentifier, что является аналогом УникальногоИдентификатора в 1С.

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

Таким образом, в момент записи объекта ВИД происходит замена формата идентификатора!
Для примера:
a0e55759-35f1-400c-8169-e5edbc2486ba - значение поля в 1С;
ede56981-24bc-ba86-400c-35f1a0e55759 - значение поля в SQL.

Поэтому, при открытии формы 1С во внешнем источнике ищет по значению "a0e55759-..." и конечно же не находит его.

Не знаю, фитча ли это, или ошибка, но "При чтении уникального идентификатора данные переставляются обратно." - странно отрабатывает.
---
установлен тип "ВнешнийИсточникДанныхТаблицаСсылка.СправочнаяИнформация.Контрагенты" Чо за тип такой? Давай скрин с этим типом.
---
Ну тип, ссылка на объект внешнего источника данных.
---
Это не тип.
Это внешний источник. Его можно использовать только в запросах.

Ну или покажите мне какой-нибудь реквизит, где у вас получилось назначить ему тип "внешнего источника"...
---
У меня-то как раз не получилось, но я видел видео, где было показано, что этот реквизит можно заполнять и он сохраняется.
Вот тут есть кусок.
---
Мне в этой жизни многие говорили, что "они как-то раз видели"...
---
Ну, тогда рекомендую посмотреть мою ссылку из предыдущего сообщения.
---
Ну посмотрел. И чо? Какая ссылка, на что?
У меня несколько внешних источников из Акспаты и из Клюшек.
Там нет ссылок на данные.
---
По вашему автор ролика всем пудрит мозги?
Специально создал реквизит, вывел его на форму, заполнил значением?
Для чего?
---
Так может будет проще/быстрее связаться напрямую с автором видео и попросить помощи/объяснений у него?
---
Спасибо, просто я думал, что на этом форуме достаточно нормальных специалистов, способных помочь в моём вопросе.
---
Сообщение было скрыто модератором.
---
Сообщение было скрыто модератором.
---
Сообщение было скрыто модератором.
---
Сообщение было скрыто модератором.
---
Сообщение было скрыто модератором.
---
Сообщение было скрыто модератором.
---
Сообщение было скрыто модератором.
---
Сообщение было скрыто модератором.
---
Сообщение было скрыто модератором.
---
Сообщение было скрыто модератором.
---
Сообщение было скрыто модератором.
---
Сообщение было скрыто модератором.
---
Сообщение было скрыто модератором.
---
Сообщение было скрыто модератором.
---
Сообщение было скрыто модератором.
---
Вы картинки мои смотрели? Поле на форме напрямую связано с реквизитом объекта.
Что я должен из вашего пустого комментария понять?
---
Пардон не увидел
---
Справочник. На картинках очевидно же, на видео, кстати - тоже.
---
Нет там никакой связи, кроме одинакового имени Реквизита Формы и Элемента Формы.
Связь элемента формы с данными определяется свойством "ПутьКДанным". Ни на одном твоём скриншоте этой связи не обозначено.
---
Ну а это тогда что?
---
Сообщение было скрыто модератором.
---
Сообщение было скрыто модератором.
---
После экспериментов нашёл причину такого поведения платформы:
Колонка ID в SQL имеет тип uniqueidentifier, что является аналогом УникальногоИдентификатора в 1С.

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

Таким образом, в момент записи объекта ВИД происходит замена формата идентификатора!
Для примера:
a0e55759-35f1-400c-8169-e5edbc2486ba - значение поля в 1С;
ede56981-24bc-ba86-400c-35f1a0e55759 - значение поля в SQL.

Поэтому, при открытии формы 1С во внешнем источнике ищет по значению "a0e55759-..." и конечно же не находит его.

Не знаю, фитча ли это, или ошибка, но "При чтении уникального идентификатора данные переставляются обратно." - странно отрабатывает.
---
a0e55759-35f1-400c-8169-e5edbc2486ba - значение поля в 1С;
ede56981-24bc-ba86-400c-35f1a0e55759 - значение поля в SQL.
Тоже заметил, что 1С по-своему конвертирует SQL-ные binary(16), в которых хранится ссылка, в 1Сный УникальныйИдентификатор. Если сделать конвертацию binary(16) в UNIQUEIDENTIFIER в запросе SQL - то получатся те самые перестановки, которые описаны в ИТС.
Для эксперимента взял Ваш же пример ГУИДов

```1c
    ТестЭлемент = Справочники.Делми.СоздатьЭлемент();
    ГУИД = Новый УникальныйИдентификатор("a0e55759-35f1-400c-8169-e5edbc2486ba");
    Ссылка = Справочники.Делми.ПолучитьСсылку(ГУИД);
    ТестЭлемент.УстановитьСсылкуНового(Ссылка);
    ТестЭлемент.Наименование = "Принудительный ГУИД";
    ТестЭлемент.Записать();
```

На стороне SQL это создало запись в таблице справочника _Reference47 (_IDRRef - это Ссылка binary(16), а в последней колонке запроса я сделал конвертацию binary(16) в uniqueidentifier)

```1c
    SEL ECT [_IDRRef]
    ,[_Description]
    ,CONVERT(UNIQUEIDENTIFIER,[_IDRRef]) as UU
    FR OM [dbo].[_Reference47]
```

Запрос вернул

```1c
    _IDRRef _Description UU
    0x8169E5EDBC2486BA400C35F1A0E55759 Принудительный ГУИД EDE56981-24BC-BA86-400C-35F1A0E55759
```

Т.е. УникальныйИдентификатор("a0e55759-35f1-400c-8169-e5edbc2486ba") в базе SQL хранится в форме binary(16) 0x8169E5EDBC2486BA400C35F1A0E55759, а при конвертации в SQL-запросе в uniqueidentifier выдает EDE56981-24BC-BA86-400C-35F1A0E55759. Иначе говоря, 1С-овский a0e55759-35f1-400c-8169-e5edbc2486ba стал SQL-ным EDE56981-24BC-BA86-400C-35F1A0E55759
---
И вдогонку, может кому пригодится. Исходные данные с принудительным УникальнымИдентификатором те же.

```1c
    SEL ECT [_IDRRef]
    ,CAST([_IDRRef] as uniqueidentifier) GUID_SQL
    ,CAST(CAST(REVERSE(SUBSTRING( [_IDRRef], 9, 8)) AS binary(8))+ SUBSTRING([_IDRRef], 1, 8) as uniqueidentifier) GUID_1C
    FR OM [dbo].[_Reference47]
```

Этот запрос вернет из хранимой в БД Ссылки-binary(16) оба представления ГУИДа: и SQL-ный, и 1С-овский:

```1c
    _IDRRef GUID_SQL GUID_1C
    0x8169E5EDBC2486BA400C35F1A0E55759 EDE56981-24BC-BA86-400C-35F1A0E55759 A0E55759-35F1-400C-8169-E5EDBC2486BA
```