Есть РС: Предложения (подчинен регистратору), ПроработкаПозиций (независимый), СтатусыПозиций (переодический).
Суть такова.
1. Заполняется РС "Предложения".
   Измерения:
              СтрокаИД (УИ, связка1)
              НоменклатураЗапрос (строка)
   Ресурсы:
              КоличествоЗапрошено (число)
2. На основании Предложений несколько пользователей, обрабатывают строки предложений. Запись ведется в РС "ПроработкаПозиций"
   Измерения:
              СтрокаИД (УИ, связка1)
              Номенклатура (ссылка)
   Ресурсы:
              КоличествоПредложено (число)
   Реквизиты:
              СтрокаИДПроработки (УИ, связка2)
3. При изменении информации по проработанной позиции отразить информацию в переодический РС "СтатусыПозиций"
   Измерения:
              СтрокаИДПроработки (УИ, связка2)
   Реквизиты:
              СтатусПозиции (Перечисление)

Пока использую тип "Уникальный Идентификатор", но закрадываются сомнения правильности использования.

Реально никто не использовал такую связку?

(1) она не типична для 1С, где зачастую оперируют ссылочными типами данных

(0) А чем тебе не нравится ГУИД??

интересно было бы для начала узнать, как в БД хранится этот самый тип - "Уникальный Идентификатор"

(3) При переносе базы или разворачивании ГУИДы не полетят?

в ут используется код строки - число, чтоб можно было глазами проверить

(0) Предложения - справочник, Позиции - подчиненный ему справочник. Те же УИДы, только без онанизма.

Это же азбука 1С.

(7) Предложения - документ, который связан с РС "Предложения"
Ситуация:
Покупатель хочет заказать товар, не одну позицию, а хоть сто.
Мы ему обрабатываем позиции, и предлагаем. Может быть ситуация, когда предполагаемая позиция может биться, в зависимости от многих факторов (поставщик, аналоги.)
Покупатель хочет:
                "Резистор 0,5Ом" = 100 шт.
Мы ему можем привести:
                "Резистор 0,5Ом партномер 5234" = 50 шт.
                "Резистор 0,5Ом партномер 3265" = 50 шт.

(8) бить морду таким надо.
разные партнамберы должны быть разными позициями в прайсе.

(9) Они и будут разными позициями потом в Заказе, когда покупатель согласиться, а на этапе предложений это не нужно, это просто записки.

(8) OK, сделай иерархию: первый уровень - позиции заказанные, второй - позиции предложенные.

(11) Это Документ.

(12) Предложение пусть будет документом, а позиции - справочник.

Заодно можно будет использовать проработанные позиции в других заказах.

(13) не хочется плодить "чебурашек" если использовать  справочник.
На этапе Предложения это просто строки, на этапе обработки только появляются справочники.

(14) Не понял про чебурашек.

(1) используем УИ. удобно. не надо заморачиваться как с ИД типа Число. там каждый раз надо опредлить максимальное для области уникальности значение. с УникальныйИдентификатор просто генеришь новый.

(16) ну и небольшое неудобство таки есть - в запрос нельзя подсунуть параметр типа УникальныйИдентификатор )
платформа ругается, что не понимает такого типа ;)

(16) Вот что и хотел услышать, думал про свой генератор, но это утопия мне казалось.
В запросе вот уже опробовал, пока терпимо. Буду преобразовывать в строку для связей в запросе.
(15) Много предложений фейковых или дубли.

(18) "Буду преобразовывать в строку для связей в запросе"

Зачем? Разве и так не работает?

исходя из условий задачи УИД вообще не нужны

(19) Читал что во временной таблице нельзя использовать, но это не проверено пока.
(20) А как вы будете связывать таблицы то?
Поступил запрос:
1. "Резистор 0,5Ом" (строка) 100 шт. назначен на обработку Квотре1
2. "Резистор 0,6Ом" (строка) 50 шт. назначен на обработку Квотер2

Квотер1 и Квотер2 работают параллельно, т.е. в один момент могут обрабатывать запросы.

Квотер1 при обработке нашел 2х поставщиков, которые могут предоставить по 50шт. (ну нет больше у них)
Квотер2 при обработке нашел 10-ть поставщиков, которые могут поставить нужное количество.
При обработке они ставят статусы позиций (в проработке, проработана, отказ, закуплено у поставщика и т.д.) на каждую позицию в проработке.

Далее выставление коммерческого предложения.

Менеджеры, которые работают с этим контрагентом, смотрят проработаны все позиции запроса (статус "Проработана"). Проставляют цены и отправляют Заказчику.
Заказчик просмотрел, дал добро допустим.
Менеджер ставит добро на закупку. Менеджеры по закупкам, "дербанять" позиции и заказывают, ставят статусы и т.д.

Вот примерно так всё и выглядит.

(21) Если на позиции нельзя будет ссылаться, все это не взлетит.

(22) позиции заявок или проработанные позиции?
У Позиции заявки свой УИД. "СтрокаИД"
У проработанной позиции свой УИД. "СтрокаИДПроработки", есть "СтрокаИД"
Связь по "СтрокаИД".

"СтрокаИДПроработки" для связки Статусов.

Проработка идет номенклатуры. Следовательно, если и нужна связь, то ее можно и нужно делать по номенклатуре

(21) а почему не сделать как в 1С принято?
Поступившие запросы в документ "Заказ"-> движение по РН "Заказы". Далее какой-нибудь документ "ПроработкаЗаказа", где на основании данных остатков РН "Заказы" делаются движения в этом же РН "ЗАказы". Статусы проработана,отказ и т.п. ставить на документ "ПроработкаЗаказа".

(23) И то, и другое. См. (11)

(21) Джойнится по УИД-у нормально, без разницы ВТ или нет, проверено на 8.3.11.