Интересно, а как камарады решают такой трабл:
типом реквизита табличной части какого-либо документа является "Документ". В DH*.SP* хранится nvarchar(какого-то размера) e.g. ' 3BA GASJK1SB1'. Необходимо приджойнить DOCNO этого документа из _1SJOURN. Ничего, кроме
....   dbo.dhsomefuck h inner join dbo._1sjourn jj on  jj.iddoc=right(h.spREFFIELD,9)
не придумал.
PS. Конфига тяжелая и самописная, пределывать низзя.

может так. но тут пример по товару
ТекстЗапроса = "
|SELECT
|    $ДокС.Товар as [Товар $Справочник.Товары],
|    SUM($ДокС.Количество) as Количество
|FROM
|    $ДокументСтроки.Реализация as ДокС
|INNER JOIN
|    $Документ.Реализация as Док ON Док.IDDoc = ДокС.IDDoc AND
|                                 $Док.Склад = :ВыбСклад
|INNER JOIN
|    1SJourn as Жур ON Жур.IDDoc = ДокС.IDDoc
|                       Жур.Date BETWEEN :НачДата~~ AND :КонДата~~ AND
|                       Жур.Closed = 1
|GROUP BY
|    $ДокС.Товар";

(0) Варианты бывают разные. Если известен тип документа, то лучше (с использованием 1С++):
SELECT *
FROM $Документ.Какой-то as Док INNER JOIN _1SJOURN as Жур ON $Док.Поле = $ВидДокумента36.ТипДокумента+Жур.IDDOC

(2) а если может быть любой документ тогда как ? не 1с++ ?

"(прямые запросы)" ввели в заблуждение почтенную публику.
Запросы творю не из 1С, напрямую к БД запрашиваю. 1С 7.7 SQL версия. Конфига не моя, повторюсь. Тип документа известен (префикс могу отделять) , но помогает мало.

тогда текст запроса показывай. это сразу нужно оговаривать. откуда ходишь

(0)
Ну, во-первых, там лежит не nvarchar, а во-вторых, твой вариант в большинстве случаев будет самым оптимальным и сервак нисколько не напряжет.

(5) чего показывать-то? весь вопрос в стремности "inner join ... on  jj.iddoc=right(h.spREFFIELD,9)"

Какой нафиг nvarchar()? Чё, лень хотя бы типы колонок посмотреть что-ли? Как вы вообще эти запросы пишете, не зная нифига?
А так то да, Right(, 9). Уникальность IDDoc обеспечивается 1С, а идДок13 == ВидДок36 + IDDoc
ВидДок36 - это IDDocDef в 36-ричной системе счисления

(7)
Нет в этом никакой стремности, работает шустро и нормально.

(8) - пипец, стоит char(9) с nvarchar() перепутать - уже возбуждаемся. Дофига различий, что сказать.

(10) char(13) вообще-то
дело не в количестве различий, а странности методологии. Типа, пишем не глядя, а если не работает - запостим на форум.

(11) в отличии от "спасите-памагите-не работает" я не просил код. char(9) там, char(13), nvarchar(?) - как это на запрос влияет?

(0)Так и решается

(12) напрямую влияет.
Либо запрос работает, либо не работает...

(12)  Ну а вторую часть моего высказывания ты не воспринял? Я там как раз написал, чем отличается char(9) от char(13)  применительно к документам 1С. А ещё же и справочники есть...