Как система будет сравнивать моменты времени если выборку двжижений ограничить моментом времени?

1. Указанный в запросе момент времени (Дата,ССылка) отсутствует в движениях?
2. Документ по идентификатору выписан будущим числом, но имеет не соответствующую идентификатору дату

http://help1c.com/faq8/view/502.html

просвещайся

(0) "имеет не соответствующую идентификатору дату" - это сильно. ВнушаетЪ.
И какая же, интересно, дата соответствует идентификатору "c3fc51d8-43ca-4b09-ace8-1529a181b47e"?

Меня интересует ситуация:
во время проведения документа я выбираю движения из регистра, в котором этот документ не является регистратором.
Если выборку движений я ограничу МоментомВремени проводимого документа, то какие записи попадут в запрос?

+(4) Движение.МоментВремени < &МоментВремени

(3) А какой смысл это делать?

(5)
многие документы в разрабатываемой системе делают записи в зависимости от выбранных запросом движений.

Пример: проводится документ, который выбирает движения, на основе этих движений формирует новые движения.

Встает проблема: условие запроса могут пройти движения, которые находятся в будущем по временной шкале.

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

Думаю, как красиво выйти из этой проблемы.

МВ = Дата+Ссылка и то и другое вполне себе сравниваются

(6) У тебя нет других вариантов - играйся временем. Ссылка неизменяемая (кроме новых документов для которых можно поставить произвольную)

(7) как сравнится ссылка и дата, если:
- 01/01/2012 рнк 1
- 01/01/2012 рнк 2 (рнк 2 была создана раньше рнк1, но в ней поменяли дату)

Ссылка = Тип+УИД. Поэтому ссылки одного типа будут блдше всех ссылок другого типа

МВ1 < МВ2 = (Д1<Д2) ИЛИ (Д1=Д2 И С1<С2)

(10) вот я и говорю, что если УИД создан раньше, но находится по шкале времени в будущем, то возникнут проблемы

(6) Если документ не делает движений по регистратору, ты никак не сможешь точно ограничить внутри 1 секунды.
Бери остатки на начало секунды данного документа.
Хотя, имхо, где-то у вас неправильность в постановке задачи...

(2) одинес не сравнивает идентификаторы по возрастанию и убыванию? :)

(10) Хотя может в моменте времени тип не присутствует

(12) Уид может быть присвоен руками, он может быть присвоен на другом сервере, в результате сортировка по ссылке у тебя будет некорректна.

(12) создан раньше/позже вообще никого не должно волновать

(12) Совсем необязательно последовательность создания УИД соответстветсвует возрастанию. Кроме того есть УРБД и документы других узлов

(13) Если бы разговор шел об остатках, то вообще проблем бы не было, обошелся бы Граница(МоментВремени,ВидГраницы.Исключая)

Речь о движениях

(19) Пофиг. Суть в том, что если данного документа нет в регистре, по которому ты отбираешь данные, то можно взять данные с тончостью до секунды. Остальное - от лукавого.
Хотя 1с вообще не очень удачно работает с данными, которые требуют точности большей, чем 1 секунда, имхо.

(20) понял, буду извращаться по типу    И РасчетыСПокупателями.Период <= &Период + проверки при создании и проведении документа

(0) Непредсказуемо.

Упорядочивание внутри секунды (по моменту времени) - в 1С понятие вообще весьма условное.
Применение имеет весьма ограниченное.

(22) один раз при проверке БД база выдала ошибку, в которой содержалось время типа 01.08.2012 14:00:01:03.

Вот эта 03 - это что?

(23) В скуле точность мремени до милисекунд. Но 1с с этим не умеет работать.

(3) сторнирую одни данные и формирую другие