Подскажите, в РН нельзя сделать измерение с типом УникальныйИндентификатор, только реквизит. В ТЧ документа есть УникальныйИдентификатор.
Как в запросе связать их в условии ГДЕ, что-то ВЫРАЗИТЬ КАК Строка у меня ругается

(0) Потому что нельзя называть системными именами что либо, к примеру "УникальныйИндентификатор"

(1) не, названы они иначе

ПОЛНОЕ СОЕДИНЕНИЕ РегистрНакопления.Продажи.Обороты КАК ПродажиОбороты
ПО ВЫРАЗИТЬ(ДанныеДокумента.УникальныйИдентификаторУслуги КАК Строка(36)) = ПродажиОбороты.УникальныйИдентификаторУслуги

Несовместимые типы Выразить
Как правильно такое сравнение выполнить

Логично же что никак.

(0) пока не поздно переделайте реквизиты ТЧ на строки

(0) уже поздно, всё сделано, регистр новый и его надо соединять с документом
чет не думал что никак..

(0) Сделай Справочник под это дело и не получи в будущем архитектурного геммороя.

(7) + 100500
Если эту хрень в измерения пихать понадобилось, то стопудово это объектная сущность и лучше ее выразить явно. Ну либо в консерватории еще раньше ошибка.

Делай как в (7) иначе потом только хуже будет.

(6) Хранить УИД в виде строки это значит занимать в 2 раза больше места
а если еще и в условии соединения использовать выражения то и принудительно не использовать индекс, если он есть

(8) Есть услуга, у неё есть уникальный идентификатор в РС и ТЧ документов, для того чтобы конкретная Номенклатура была уникальной. Этот идентификатор проходит через документы, и его я пишу в новом РН. Поэтому мне и надо сравнить ТЧ документа и измерение регистра, ну так уже было, я не с нуля делаю..

(0) что у тебя там хранится в УИДе?

Короче эти два типа несравнимы и привести их к строке в запросе нельзя, верно

(12) уид и хранится, сгенерированый при первом предоставлении конкретной услуги

(6) В запросах 1С вообще нельзя приводить типы. Никак. Это делает больно уже очень давно.
ВЫРАЗИТЬ используется только для конкретизации типов.
(11) Жесть какая. Лучше переделай, пока не поздно. Что делает номенклатуру уникальной? В жизни, а не в кривом архитектурном решении?

(13) а для чего запрос? какую задачу решаешь?

Или перефразируя - в какой момент генерится уникальный идентификатор и в каком документе?

(16) так как именно услуга уникальна, смотрю по РН продажи по ней, дабы вывести разницу
(15) ну каждая услуга уникальна на протяжении своей жизни дабы иметь в итоге статус и прочие атрибуты в РС

(18) разницу для чего, в отчет?

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

(20) Как я и ожидал, прозвучало слово "заказ".

(19) для корректирующего движения, если оно необходимо

(21) лучший коммент пока что

(23) + помогает решить вопрос)

(20) дык делай новую номенклатуру с уникальными характеристиками каждый раз, нафига извраты с УИНами??

Гм. Исторически сложилось? Или сам писал? :-)

выгружай в ТЗ приводи к нужному типу помещай в ВТ и т.д.

(27) жуткий костыль, но это следствие архитектуры

(0) Ну добавь в новый регистр еще и реквизит с типом УникальныйИндентификатор, У тебя в этом регистре будет измерение строкой и реквизит уином.

не писал я это
(29) я так и сделал а толку, соединение то возможно только с измерением, поэтому за сравнение и спросил

(27) хм.. ну костылем больше, костылем меньше, возможно..

(30) Используй РегистрСведений.СоответствиеОбъектов...

(20) То есть вы таким хитрым образом избегаете персонификации заказов? А когда понадобится персонификация? Или хранение и анализ дополнительных атрибутов неперсонифицированных заказов? Ты понимаешь, что такое архитектурное решение будет провоцировать рождение новых костылей и очень быстро захлебнется в этих костылях? А в итоге у вас все равно появится документ "Заказ", сопоставленный с идентификатором?

херня какая-то, может просто воткнуть в документ дублирующий УИД/строку и сравниваться с ним

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

(35) рекомендую дать выбор заказчику, предложить и вариант переделки

(35) Мне просто интересно, почему в измерении не ссылка на заказ, а какой-то безликий идентификатор. Какая-то мысль у кого-то в голове была же? Хочется ее понять.

Мысль была простая. Насяльник сказал уникально идентифицировать услугу, добавили УИД. Уникально? Уникально! :)

(38) А документ "Заказ" у вас есть?

(39) Я хз) я их не знаю)

(40) Не, не съезжай. Мне же интересно :)
Ты в (20) сказал ключевую фразу - "при первом ее заказе".
Отсюда сразу два вопроса:
1) можно ли повторно заказать эту же самую услугу по тому же идентификатору (вероятно нет, иначе я вообще ничего не понимаю)
2) как в системе отражается факт заказа. Каким документом. Как называется вид документа, в котором генерится идентификатор услуги.

(41) Это был не я) у нас ники похожие, но не настолько)

(42) Блин. Ты меня сбил своим ответом на мой вопрос ТС. Я на ник даже не глянул :)

(41) ну делается Заказ с какой-то там услугой, в ТЧ есть УИД, который в момент проведения ей и присваивается. Далее этот УИД сопровождает услугу на протяжении её жизни.

(44) в одном заказе может быть несколько услуг?

(44) А если строку удалить и добавить заново?

(44) Типа в рамках одного заказа могут заказать несколько однотипных услуг с разными характеристиками и характеристики всегда уникальны? Ну, такое... На несчастной табличке сэкономили, зато кучу неудобств приобрели.

да, странно, почему услугу заказа нельзя идентифицировать двумя полями Заказ+Номенклатура

(48) А вдруг в одном заказе две одинаковых услуги?)

(49) если это шутка то смешно, если не шутка то одно из двух

(50) Это шутка с долей шутки) Может, у них услуги все должны быть уникальны.

(51) Должен же быть какой-то признак уникальности в жизни. А вообще ТС со своими темами просто достоин звания архитектор-абстракционист.