СрезПоследних по РС возвращает разный набор записей, т.е. ВЫБРАТЬ 1 - разные вызовы возвращают разные значения.
Пример:
1 набор:
Пользователь 1 - 01.12.2019 << ВЫБРАТЬ ПЕРВЫЕ 1
Пользователь 2 - 01.01.2019
Пользователь 3 - 01.12.2018

2 набор:
1 набор:
Пользователь 2 - 01.01.2019 << ВЫБРАТЬ ПЕРВЫЕ 1
Пользователь 1 - 01.12.2019
Пользователь 3 - 01.12.2018
(значение по 'ВЫБРАТЬ ПЕРВЫЕ 1' показаны условно "по консоли запросов", т.к. порядок записей, выводимый в консоли, и порядок реальной выборки - разные, но принцип "один запрос - разные записи" аналогичен).

В РС несколько измерений (да, изначально при проектировании РС одно из измерений - нужно было сделать реквизитом, т.к это искомое значение, по нему отбор не используется, но уже не переделаешь).
Условия через ГДЕ, а не в параметрах (т.е. сначала отбираются последние записи, а потом на них накладывается фильтр, а не последние среди условий как в противном случае).
Запрос не меняется, естественно.
Кто что думает, почему так?

сортировать пробовал?

(1) пробовал, но вопрос в другом - SQL возвращает разные наборы. В случайном порядке. То правильно, то - неправильно. Причем неправильно - набор всегда одинаков, как и "правильно".
>>кстати, читать "
2 набор:
1 набор:"
как:
"2 набор:"

Да, исходный запрос без сортировки и отбора по дате.

При отсутствии явной сортировки порядок возвращаемых записей не гарантируется и может быть разным. Твой запрос неявно завязан на порядок, поэтому сортировка обязательна.
Но вообще странно, что каждый раз разный. Обычно план выполнения запроса кэшируется и порядок повторяется до изменения каких-то внешних условий (самого запроса, обновления статистики, обновления кэша планов выполнения и т.п)

показывай уже свой запрос

>>сортировки порядок возвращаемых записей не гарантируется и может быть разным
Не "может быть", а разный))
Мне непонятно только, почему он "разный" в случайный момент времени, и всегда разный "одинаково" - т.е. нет других возвращаемых порядков кроме этих двух.
Поэтомы row-хранение записей в SQL отпадает, т.к. физический порядок записей не повторяется (если её изменяют), или вообще не меняется в таблице (если её только читают).

(5) запрос неправильно написан, не по данному РС, я уже это отметил.
Он элементарный.
Да, нужно менять или РС (измерение - перебросить в реквизит), либо запрос (сортировка, отбор по дате и т.д.)
Мне интересно, что происходит с данными именно по этому запросу)

(6) Что такое разный "одинаково"? Один и тот же запрос при последовательном выполнении попеременно выдает то один порядок, то другой?
Да кто ентот оптимизатор запросов разберет. Похоже на то, что в зависимости от какого-то "дрожащего" параметра выбирается то один план выполнения, то другой. Можно запрофайлить. Либо даже это "дрожание" находится под оптимизатором запросов - порядок обхода страниц почему-то разный бывает. ИМХО, это может быть интересно только для очень узких специалистов. Прикладному программисту достаточно знать только вышесказанное. Есть завязка на порядок - сортируй.

Кому вот прям интересно, что за запрос. Но это ничего вам не даст :)

ВЫБРАТЬ ПЕРВЫЕ 1
    ОтветственныеЛицаСрезПоследних.Период,
    ОтветственныеЛицаСрезПоследних.Документ,            <<ИЗМЕРЕНИЕ 1
    ОтветственныеЛицаСрезПоследних.Организация,            <<ИЗМЕРЕНИЕ 2
    ОтветственныеЛицаСрезПоследних.Подписант КАК ОсновнаяПодпись,    <<ИЗМЕРЕНИЕ 3
    ОтветственныеЛицаСрезПоследних.Приказ
ИЗ
    РегистрСведений.ОтветственныеЛицаСрезПоследних КАК ОтветственныеЛицаСрезПоследних

ГДЕ
    ОтветственныеЛицаСрезПоследних.Организация = &Организация
    И ОтветственныеЛицаСрезПоследних.Документ = &СчетФактура

(9) добавь сортировать По не иби нам созг.

мозг

(8)>>Один и тот же запрос при последовательном выполнении попеременно выдает то один порядок, то другой?
Именно :)
Я и так старался подробно описать, что такое "разные наборы".

(10) умный ответ в первой части. Но глупый - в целом.
Все это давно понятно -> (7)

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

(8)>> Прикладному программисту достаточно знать только вышесказанное
Понимаешь, люди годами работали, и, возможно, нивелировали ошибки на своем урвоне - просто меняли вручную, когда неправильно выводилось, списывая на "это опять там где-то в базе чей-то поменяли с подписями".
А выясняется вот такая "магия" тут, оказывается, работает - и выдает эта "магия" разные результаты. Поэтому нужно как-то обосновать, что данный участок надо переделывать.

(15) Об эту "магию" убился еще легион криворуких семерочных программистов, перенося базу на сиквел :)

(14) прикол еще и в том, что совершенно непонятно, когда-какие наборы выдаются.
Вообще неясен триггер данного поведения - со стороны пока в случайный момент времени меняется вывод.
Правильно - правильно - правильно - неправильно - правильно - неправильно - правильно - правильно - правильно

(16) Забанен в 12:12 и все равно пишет, он ИЗБРАННЫЙ.

(16) так и не разобрались до конца? :)

(18) он модератор веток

(19) Были уволены нафиг. Ибо нехер рабочее время на фигню спускать.

(19) Это РТФМ. В СУБД со страничной организацией данных порядок выдачи результата при отсутствии явной сортировки не гарантируется.
Просто для файловых баз прокатывало (простые алгоритмы ходили по данным всегда в одинаковом порядке), а во "взрослых" СУБД извлечение данных зависит от кучи факторов.

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

(22) т.е. железобетонно без заумностей ничего не показать в обосновании?
Жаль.
Я, правда, тоже ничего не нашел по данному вопросу в инете.
>>В СУБД со страничной организацией данных порядок выдачи результата при отсутствии явной сортировки не гарантируется
Это понятно, но это RTFM (т.е. как подойдет доказательство - на этапе внедрения), а база с таким косяком уже внедрена, и работала годами :)

>>(т.е. как подойдет доказательство - на этапе внедрения)
"т.е. как доказательство подойдет толькько на этапе внедрения"

(18) Меня пока только в политических ветках забанили. Что для политических веток великий модераторский прогресс, должен признать.

(24) Работало годами в сиквеле? Либо везло, либо забивали, либо и то и другое.
В обосновании очень просто: трудновыявляемая ошибка в запросе. Это явная ошибка, за которую линейкой по рукам лупят.

(24) она ждала момента

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

обоснование - ибо это г..нокод

Это примерно как ходить по стройке и каску не носить.
Можно всю жизнь ходить и ничего не словить.
А можно и словить

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

(32) Пойдет в качестве доказательства? https://docs.microsoft.com/ru-ru/sql/t-sql/queries/top-transact-sql?view=sql-server-ver15
"Если вы используете TOP с предложением ORDER BY, в результирующий набор включаются только первые N строк отсортированного результата. В противном случае TOP возвращает N строк в неопределенном порядке"

Ну или из встроенной справки 1С: "Будут отобраны самые первые (в соответствии с правилами упорядочивания результатов запроса) строки"
Ошибка - правила упорядочивания не были заданы. Что тут еще обосновывать?

(34)>> Что тут еще обосновывать?
Как-то обыгрывать возражения "код же рабочий" и "работало же" :)

Плохо, что пользователи не в курсе, я вот сунулся использовать эти разработки - и дальше уже как-бы моя "ошибка" пойдет, поэтому желательно сразу поправить.

(36) не используй для своих доработок эту процедуру.
если уж не дают конфу корячить

(37) оставляя как прежде - я "подтверждаю", что там все ок. А это не так.
Запрос-то так и работает непредсказуемо.

(35) "Усы вот и хвост мои документы!" (с)

(27) Такие ошибки и в типовых встречались..

(40) Каких только ошибок в типовых не встречалось. Чай не боги их пишут, всяк ошибиться может. Но одно дело провтыкать - это со всеми бывает. А вот по незнанию - это плохо. Такие вещи специалист понимать должен. Тут же даже на уровне здравого смысла просто обязан родиться вопрос - если я выбираю первую из многих, то какая именно должна быть первой и почему?

(41) на такой случай в платформе должна быть защита от дурака и сортировка ПО умолчанию

В регистре сортировка при выборке по кластерному индексу,но он здесь изначально по периоду,соответственно,в зависимости от обновления статистики будет выполняться или полное сканирование или сканирование по индексу,что даст разные результаты.
Ещё можно предположить,что до этого выполняется подобный запрос,результат которого идёт как база для текущего.

Как бы,план запроса для двух случаев посмотреть не мешает.

(42) с таким ником давать подобные рекомендации грех

(44) сейчас чувства неверующего задели (словом грех), осторожней

(42) С чего вдруг? Есть ведь варианты, когда устраивает любая первая. И даже наличие дефолтовой сортировки вовсе не исправляет логическую ошибку программиста, когда алгоритм зависит от порядка, но порядок явно не определили. Будет точно такая же логическая ошибка, которая может выстрелить не сразу. Заведут новый элемент в базу, который в соответствии с дефолтовой сортировкой (но против задумки) вылезет вперед - и вуаля.

(45) грех осторожничать

(42) Любая сортировка по умолчанию - это изначально дополнительные тормоза, даже там где сортировки не требуется. Оно надо?

(9) Перенеси ГДЕ в параметры виртуальной таблицы.