Предположим, есть один документ "Реализация товаров", есть совершенно другой документ "Списание товаров", создали и там и там по одному документу на одну дату, какая будет сортировка и можно ли гарантировать, что при следующем вводе двух документов (одной реализации и одной списании) на одну дату сортировка сохранится в той же последовательности?

нет. позиция документа формируется из вида + момента времени вноса в базу(если не вру)

(0)дата + идентификатор

(0) Момент времени - это дата+ссылка(внутренний идентификатор).

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

(2) на инфостарте вроде было написано, что УИД "делится на две части", первая - это "порядковый номер таблицы типа документа", второй - это непосредственно уникальный номер записи (конкретный документ одного типа).

(4) уид никак не делится

00000001-0101-0101-000001 первая реализация 12.02.2013
00000001-0101-0101-000002 вторая реализация 13.02.2013

00000002-0101-0101-000001 первое списание 12.02.2013
00000002-0101-0101-000002 второе списание 13.02.2013

тут сортировка такая:
00000001-0101-0101-000001 первая реализация 12.02.2013
00000002-0101-0101-000001 первое списание 12.02.2013

00000001-0101-0101-000002 вторая реализация 13.02.2013
00000002-0101-0101-000002 второе списание 13.02.2013


или же второй случай может быть таким:

00000001-0101-0101-000001 первая реализация 12.02.2013
00000001-0101-0101-000002 вторая реализация 13.02.2013

00000002-0101-0101-000001 первое списание 12.02.2013
00000002-0101-0098-000002 второе списание 13.02.2013

тогда получим:
00000001-0101-0101-000001 первая реализация 12.02.2013
00000002-0101-0101-000001 первое списание 12.02.2013

00000002-0101-0098-000002 второе списание 13.02.2013 - УЖЕ ВПЕРЕДИ
00000001-0101-0101-000002 вторая реализация 13.02.2013

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

(7) *на одну дату (два разных типа) разные случаи выдаст... плохо

(7) создай регистр сведений и пиши туда порядковые номера документов.

+(9) если так принципиально, что однажды отсортированный документ не должен менять свое место в сортировке

+(10) Но это, имхо, уже маразм

(11) да проще тогда время пробить как константу для каждого вида документа. Это не маразм, просто потом если вдруг один документ окажется ранее другого - то проверка не даст такой провести документ.

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

(13) время и спасет, причем если рассматривать одну дату, то на начало и конец дня могут быть только по одному документу (разного вида), а в середине дня (третий вид документа) - пусть ставится по времени, лишь бы на 23:59:59 не наехал.

просто здесь вот написано: "http://infostart.ru/public/127208/", цитирую: "Итак, ссылка логически состоит из двух  частей – имени соответствующего объекта метаданных (тип ссылки), например «Справочник.Контрагенты»,  и УИДа, являющегося по своей природе GUIDом" - т.е. делится на левую и правую часть... похоже так...

хотя через консоль запросов смотрим уид одной таблицы;
6e63cf04-dc23-11db-8015-0016763184e2
6b4d9ab4-b4c4-11de-801e-0016763184e2
6b4d9ab6-b4c4-11de-801e-0016763184e2
6b4d9ab8-b4c4-11de-801e-0016763184e2
973fc8c4-ced6-11e0-8025-0016763184e2
acb817ca-b6de-11e1-8056-0016763184e2
acb817cc-b6de-11e1-8056-0016763184e2
d946118e-85fc-11e0-8076-0016763184e2
d9461190-85fc-11e0-8076-0016763184e2

все разные, на левую и правую часть не делятся... т.е. левая не одинаковая...

пример плохой, правая одинаковая, вот дальше из той же таблицы:

b5e1cbb5-da50-11de-bf3d-0016763184e2
b5e1cbbe-da50-11de-bf3d-0016763184e2
d00d4bfc-bbc5-11da-bf3d-505054503030
d00d4bfd-bbc5-11da-bf3d-505054503030
d00d4bfe-bbc5-11da-bf3d-505054503030

(17) а еще у разных таблиц может быть одинаковый ГУИД...

(18) + Правда если руками его присваивать...