О времени и 1С

Ничего нового. Практически каждый разработчик сталкивался с этими функциями.

// Инициализация даты

// 1. Константой
Дата = '20250308143015'; // 08.03.2025 14:30:15
// 2. Строкой
Дата = Дата("20250308143015"); // 08.03.2025 14:30:15
// 3. Частями
Дата = Дата(2025, 3, 8, 14, 30, 15); // 08.03.2025 14:30:15

// Получение частей даты в виде числа

Год =  Год(Дата); // 2025
Месяц =  Месяц(Дата); // 3
День =  День(Дата); // 8
Час =  Час(Дата); // 14
Минута = Минута(Дата); // 30
Секунда =  Секунда(Дата); // 15

// Основные операции с датами

// 1. Добавить одну секунду
Дата = Дата + 1; // 08.03.2025 14:30:16

// 2. Добавить 2 месяца
Дата = ДобавитьМесяц(Дата, 2); // 08.05.2025 14:30:16

// 3. Отнять 3 месяца
Дата = ДобавитьМесяц(Дата, -3); // 08.02.2025 14:30:16

// 4. Получить порядковый номер дня в году
НомерДняВГоду = ДеньГода(Дата); // 39

// 5. Получить порядковый номер дня в неделе (начиная с понедельника)
НомерДняВНеделе = ДеньНедели(Дата); // 5

// 6. Получить порядковый номер недели в году
НомерНеделиВГоду = НеделяГода(Дата); // 6

// 7. Начало предопределенных периодов
НачалоГода = НачалоГода(Дата); // 01.01.2025 00:00:00
НачалоКвартала = НачалоКвартала(Дата); // 01.01.2025 00:00:00
НачалоМесяца = НачалоМесяца(Дата); // 01.02.2025 00:00:00
НачалоНедели = НачалоНедели(Дата); // 04.02.2025 00:00:00
НачалоДня = НачалоДня(Дата); // 08.02.2025 00:00:00
НачалоЧаса = НачалоЧаса(Дата); // 08.02.2025 14:00:00
НачалоМинуты = НачалоМинуты(Дата); // 08.02.2025 14:30:00

// 8. Конец предопределенных периодов
КонецГода = КонецГода(Дата); // 31.12.2025 23:59:59
КонецКвартала = КонецКвартала(Дата); // 31.03.2025 23:59:59
КонецМесяца = КонецМесяца(Дата); // 28.02.2025 23:59:59
КонецНедели = КонецНедели(Дата); // 10.02.2025 23:59:59
КонецДня = КонецДня(Дата); // 08.02.2025 23:59:59
КонецЧаса = КонецЧаса(Дата); // 08.02.2025 14:59:59
КонецМинуты = КонецМинуты(Дата); // 08.02.2025 14:30:59

// Арифметические операции с датами

Дата1 = Дата(2025, 3, 8, 14, 30, 15); // 08.03.2025 14:30:15
Дата2 = Дата1 - Дата(2025, 1, 1, 0, 0, 0); // 37 290 615
Дата3 = Дата(2025, 1, 1, 0, 0, 0) + Дата2; // 08.03.2025 14:30:15
КоличествоСекунд = Дата1 - Дата3; // 0

Или есть все же что-то еще? 🙂

Язык запросов платформы также поддерживает различные операции над датами.

ВЫБРАТЬ
// Инициализация даты в запросе
ДАТАВРЕМЯ(2025, 3, 8, 14, 30, 50) КАК ДатаЧастями,
&ДатаПараметром КАК ДатаПараметром,
// Части даты
ГОД(&ДатаПараметром) КАК Год,
КВАРТАЛ(&ДатаПараметром) КАК Квартал,
МЕСЯЦ(&ДатаПараметром) КАК Месяц,
ДЕНЬГОДА(&ДатаПараметром) КАК ДеньГода,
ДЕНЬ(&ДатаПараметром) КАК День,
НЕДЕЛЯ(&ДатаПараметром) КАК Неделя,
ДЕНЬНЕДЕЛИ(&ДатаПараметром) КАК ДеньНедели,
ЧАС(&ДатаПараметром) КАК Час,
МИНУТА(&ДатаПараметром) КАК Минута,
СЕКУНДА(&ДатаПараметром) КАК Секунда,
// Преобразование даты к указанному периоду
// Возможные типы периодов:
// - Минута
// - Час
// - День
// - Неделя
// - Месяц
// - Квартал
// - Год
// - Декада
// - Полугодие
НАЧАЛОПЕРИОДА(&ДатаПараметром, ДЕНЬ) КАК НачалоПериода,
КОНЕЦПЕРИОДА(&ДатаПараметром, ДЕНЬ) КАК КонецПериода,
ДОБАВИТЬКДАТЕ(&ДатаПараметром, МЕСЯЦ, 6) КАК ДобавитьКДате,
// Разность дат для указанного периода
// Из 2 параметра вычитается первый.
РАЗНОСТЬДАТ(&ДатаПараметром, &ТекущаяДата, ДЕНЬ) КАК РазностьДат

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

Даты нельзя можно преобразовать к строке и наоборот. Во встроенном языке преобразование доступно, например, с помощью функции "Строка()". По замечанию philya, исправил информацию, что дату нельзя преобразовать к строке в запросе.

ВЫБРАТЬ
ПРЕДСТАВЛЕНИЕ(ДАТАВРЕМЯ(2025, 1, 1)) КАК ДатаСтрокой,
ПРЕДСТАВЛЕНИЕ(&ТекущаяДата) КАК ПредставлениеПараметраДатаСтрокой

Еще одной особенностью работы с датами в запросах является использование выражения "МЕЖДУ", с помощью которого в краткой форме можно установить фильтр по диапазону дат. Вот пример.

ВЫБРАТЬ
НекотороеПоле
ИЗ
КакойТоТамТаблицы
ГДЕ
ПолеПериод МЕЖДУ &НачалоПериода И &КонецПериода

Этот запрос будет аналогичен следующему.

ВЫБРАТЬ
НекотороеПоле
ИЗ
КакойТоТамТаблицы
ГДЕ
ПолеПериод >= &НачалоПериода И ПолеПериод <= &КонецПериода

В отличии от встроенного языка, в запросе есть ряд ограничений:

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

ВЫБРАТЬ
ДАТАВРЕМЯ(ГОД(&ТекущаяДата), 3, 8, 14, 30, 50) КАК ДатаЧастями

• Недоступны операции сложения или вычитания с датами.

ВЫБРАТЬ
&ТекущаяДата - &ДругаяДата КАК ВыражениеСДатами,
&ТекущаяДата + ДАТАВРЕМЯ(2025, 3, 8, 14, 30, 50) КАК ДругоеВыражениеСДатами

Большинство ограничений обусловлены именно особенностями платформы, а не возможностями СУБД. По крайней мере SQL Server и PostgreSQL позволяют выполнять SQL-запросы с подобным синтаксисом.

Для того, чтобы понять является ли дата пустым значением, необходимо:

• Для встроенного языка сравнить значение с датой "01.01.01 00:00:00" или использовать функцию "ЗначениеЗаполнено()".
• В запросах необходимо сравнить со значением "01.01.01 00:00:00", например вот так:

ВЫБРАТЬ
&ТекущаяДата = ДатаВремя(1,1,1) ЭтоПустаяДата

На этом основные возможности работы с датами исчерпаны. Есть чем дополнить? Комментарии ждут Вас!

Платформа поддерживает все стандартные часовые пояса. Для получения списка часовых поясов из встроенного языка есть системные функции.

// Список доступных часовых поясов
МассивЧасовыхПоясов = ПолучитьДопустимыеЧасовыеПояса();
// Пример вывода
// ...
// - Europe/Amsterdam
// - Europe/Andorra
// - Europe/Astrakhan
// - Europe/Athens
// - Europe/Belfast
// - Europe/Belgrade
// - Europe/Berlin
// - Europe/Bratislava
// - Europe/Brussels
// - Europe/Bucharest
// - Europe/Budapest
// - Europe/Chisinau
// - Europe/Copenhagen
// ...

// Получение локализованного представления часового пояса
ПредставлениеЧасовогоПояса = ПредставлениеЧасовогоПояса("Europe/Astrakhan");
// Пример вывода
// - "GMT+04:00"

В этом примере, представление часового пояса — это локализованное значение для стандартного имени этого пояса. Вот небольшой пример.

Полезная функция при локализации прикладных решений.

Начнем с примера работы с настройками информационной базы.

// Для установки часового поиска информационной базы
// нужно использовать монопольный режим
УстановитьМонопольныйРежим(Истина);

// Получаем текущий часовой пояс базы
ЧасовойПоясБазы = ПолучитьЧасовойПоясИнформационнойБазы();
Сообщить("До: " + ЧасовойПоясБазы);

// Устанавливаем новый часовой пояс
НовыйЧасовойПоясБазы = "Europe/Moscow";
УстановитьЧасовойПоясИнформационнойБазы(НовыйЧасовойПоясБазы);

// В этом случае функция вернет имя только что установленного
// часового пояса
ЧасовойПоясБазы = ПолучитьЧасовойПоясИнформационнойБазы();
Сообщить("После: " + ЧасовойПоясБазы);

УстановитьМонопольныйРежим(Ложь);

В примере мы считали текущий пояс ИБ, а после установили новое значение "Europe/Moscow". Значение устанавливаемого часового пояса должно быть одним из тех, которое возвращает функция "ПолучитьДопустимыеЧасовыеПояса()".

Для работы с часовым поясом сеанса используются следующие функции.

// Получаем текущий часовой пояс сеанса
ЧасовойПоясСеанса = ЧасовойПоясСеанса();
Сообщить("До: " + ЧасовойПоясСеанса);

// Устанавливаем новый часовой пояс текущего сеанса
НовыйЧасовойПоясСеанса = "Asia/Oral";
УстановитьЧасовойПоясСеанса(НовыйЧасовойПоясСеанса);

// Получаем новое значение часового пояса
ЧасовойПоясСеанса = ЧасовойПоясСеанса();
Сообщить("После: " + ЧасовойПоясСеанса);

Работа с часовым поясом сеанса очень похожа на работу с часовым поясом самой информационной базы, но есть существенные различия:

• Часовой пояс информационной базы сохраняется в базе данных, а часовой пояс сеанса должен устанавливаться каждый раз при его старте:
  • В первую очередь выполняется попытка получить его из часового пояса информационной базы.
  • Если для ИБ часовой пояс не установлен, то берется часовой пояс сервера.
  • Если при старте сеанса часовой пояс сеанса устанавливается явно в коде встроенного языка, то в дальнейшем используется именно это значение.
• Установить часовой пояс базы можно только в монопольном режиме.

Для получения текущего часового пояса компьютера используется функция, внезапно, "ЧасовойПояс()".

Итого, для управления настройками часовых поясов всей базы или отдельного сеанса используется всего лишь несколько методов:

1. ПолучитьЧасовойПоясИнформационнойБазы()
2. УстановитьЧасовойПоясИнформационнойБазы("ИмяЧасовогоПояса")
3. ЧасовойПояс()
4. ЧасовойПоясСеанса()
5. УстановитьЧасовойПоясСеанса()

// Получение текущего часового пояса компьютера
Сообщить(ЧасовойПояс());

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

Выше уже был пример использования функции "ТекущаяДата()", которая возвращает текущую дату и время для компьютера. Если функция вызвана на клиенте, то она вернет дату и время клиентского компьютера. Если ее вызвать на сервере, то будет возвращена дата и время сервера. Но есть и другие функции получения текущей даты.

&НаКлиенте
Процедура ПроверкаТекущейДаты(Команда)

// Текущая дата на клиенте
Сообщить("Текущая дата на клиенте: " + ТекущаяДата());

ПроверкаТекущейДатыНаСервере();

КонецПроцедуры

&НаСервере
Процедура ПроверкаТекущейДатыНаСервере()

// Текущая дата на сервере
Сообщить("Текущая дата на сервере: " + ТекущаяДата());

// Текущая универсальная дата (UTC)
Сообщить("Текущая универсальная дата на сервере: " + ТекущаяУниверсальнаяДата());

// Текущая универсальная дата в миллисекундах, начиная от 01.01.0001
Сообщить("Текущая универсальная дата в миллисекундах на сервере: " + ТекущаяУниверсальнаяДатаВМиллисекундах());

КонецПроцедуры

Из всех функций получения текущей даты и времени только одна может использоваться в тонком клиенте — это "ТекущаяДата()". Далее мы рассмотрим работу этих функций более подробно на примере.

Есть и другая более интересная функция получения текущей даты — это получение текущей даты сеанса.

// Информация от сервера. Для Windows настройки часового пояса
// и текущего времени задаются через "Панель управления -> Язык и региональные стандарты"
// и "Дата и время"
// Примечание: для разных версий Windows названия могут отличаться.
// В дистрибутивах Linux настройки также могут отличаться.
Сообщить("Часовой пояс сервера: " + ЧасовойПояс()); // Asia/Novosibirsk
Сообщить("Текущее время сервера: " + ТекущаяДата()); // 27.03.2025 22:35:28

// Ранее мы установили часовой пояс информационой базы "Europe/Moscow"
ЧасовойПоясБазы = ПолучитьЧасовойПоясИнформационнойБазы();
Сообщить("Часовой пояс информационной базы: " + ЧасовойПоясБазы); // Europe/Moscow

// До этого момента часовой пояс сеанса не был настроен.
// Т.к. мы установили пояс информационной базы, то часовой пояс
// сеанса теперь по умолчанию имеет такое же значение.
// Примечание: если часовой пояс базы не был бы настроен,
// то по умолчанию устанавливался бы часовой пояс сервера.
Сообщить("Часовой пояс сеанса: " + ЧасовойПоясСеанса()); // Europe/Moscow
Сообщить("Текущее время сеанса: " + ТекущаяДатаСеанса()); // 27.03.2025 18:35:28

// Явно установим часовой пояс сеанса
УстановитьЧасовойПоясСеанса("Asia/Oral");
Сообщить("Часовой пояс сеанса: " + ЧасовойПоясСеанса()); // Asia/Oral
Сообщить("Текущее время сеанса: " + ТекущаяДатаСеанса()); // 27.03.2025 20:35:28

// И поменяем его еще раз!
УстановитьЧасовойПоясСеанса("Europe/Amsterdam");
Сообщить("Часовой пояс сеанса: " + ЧасовойПоясСеанса()); // Europe/Amsterdam
Сообщить("Текущее время сеанса: " + ТекущаяДатаСеанса()); // 27.03.2025 16:35:28

Текущая дата сеанса — очень важное понятие для информационных баз, где работа ведется в разных часовых поясах. Фактически это дата сервера, приведенная к часовому поясу сеанса. По стандартам разработки именно ее следует использовать в прикладном коде, вместо функции "ТекущаяДата()", за исключением редких случаев. Например, при создании новых документов используется именно текущая дата сеанса, позволяющая поддерживать единую последовательность документов для часовых поясов.

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

Также важный момент — это использование функции "ТекущаяДата()" на клиенте. В абсолютном большинстве случаев это будет ошибкой, т.к. привязываться к текущей дате клиента очень ненадежно, даже если его часовой пояс совпадает с часовым поясом информационной базы. Причин этому несколько:

• Часовой пояс клиента может быть любым. Это может быть пользователь, зашедший в базу часового пояса "EuropeMoscow", но находящийся в часовом поясе "America/New_York". Фактически мы никак не можем использовать текущую дату клиента, т.к. она сильно отвязана от часового пояса системы.
• Даже если часовые пояса клиента и информационной базы совпадают, то клиентскую дату и время все равно нельзя использовать, потому что она может отличаться от серверной даты. Например, если на клиенте часы ошибочно идут "назад" на 10 минут, то при использовании этой даты для проверки остатков или другой информации может произойти ошибка в учете. Пользователь продаст товар, который 10 минут назад уже распродали!

Но что же делать, если на клиенте нужна текущая дата? Самым правильным подходом будет использование текущей даты сеанса, которую нужно получить с сервера на клиент. В некоторых случаях можно использовать дату документа, но нужно смотреть по конкретной задаче.

И напоследок рассмотрим еще несколько функций, которые платформа предоставляет для работы с часовыми поясами.

ЧасовойПоясСервера = ЧасовойПояс(); // Asia/Novosibirsk
ТекущаяДатаСервера = ТекущаяДата(); // 28.03.2025 1:27:06
ЧасовойПоясИнформационнойБазы = ПолучитьЧасовойПоясИнформационнойБазы(); // Europe/Moscow

УниверсальнаяДата = УниверсальноеВремя(ТекущаяДатаСервера, ЧасовойПоясСервера); // 27.03.2025 18:27:06
ТекущаяДатаИнформационнойБазы = МестноеВремя(УниверсальнаяДата, ЧасовойПоясИнформационнойБазы); // 27.03.2025 21:27:06

// Часовой пояс сеанса в этом случае аналогичен
// часовому поясу информационной базы
ЧасовойПоясСеанса = ЧасовойПоясСеанса(); // Europe/Moscow
// Текущая дата сеанса, получаемая платформенной функцией,
// такая же как и "ТекущаяДатаИнформационнойБазы", которую мы получили выше
ТекущаяДатаСеанса = ТекущаяДатаСеанса(); // 27.03.2025 21:27:06

// Смещение времени в секундах между указанным часовым поясом и универсальным временем (UTC)
СмещениеОтСтандартногоВремени = СмещениеСтандартногоВремени(ЧасовойПоясИнформационнойБазы, УниверсальнаяДата); // 10 800 секунд (3 часа)
// Смещение летнего времени в секундах для указанного часового пояса
СмещениеЛетнегоВремени = СмещениеЛетнегоВремени(ЧасовойПоясИнформационнойБазы, УниверсальнаяДата); // 0 секунд

Это все основные возможности платформы 1С при работе с часовыми поясами.

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

ДокументОбъект = Документы.ПростойДокумент.НайтиПоНомеру("000000001");

Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| КакойТоТамРегистрОстатковОстатки.Номенклатура КАК Номенклатура,
| КакойТоТамРегистрОстатковОстатки.КоличествоОстаток КАК КоличествоОстаток
|ИЗ
| РегистрНакопления.КакойТоТамРегистрОстатков.Остатки(
|   &Период,
|   Номенклатура = &Номенклатура)
|  КАК КакойТоТамРегистрОстатковОстатки";
Запрос.УстановитьПараметр("Номенклатура", Справочники.Номенклатура.Товар1);
Запрос.УстановитьПараметр("Период", ДокументОбъект.Дата);
РезультатЗапроса = Запрос.Выполнить();

В этом случае платформа выполнит такой запрос на стороне базы данных.

-- Запрос с использованием даты
SELECT
T1.Fld27RRef,
T1.Fld28Balance_
FROM (
SELECT
T2.Fld27RRef AS Fld27RRef,
CAST(SUM(T2.Fld28Balance_) AS NUMERIC(33, 2)) AS Fld28Balance_
FROM (
-- Получение данных из текущих итогов
SELECT
T3._Fld27RRef AS Fld27RRef,
CAST(SUM(T3._Fld28) AS NUMERIC(27, 2)) AS Fld28Balance_
FROM dbo._AccumRgT29 T3
-- Фильтр накладывается только по дате текущих итогов (3999-11-01 00:00:00 - дата конца света по календарю 1С)
WHERE T3._Period = @P1 AND ((T3._Fld27RRef = @P2)) AND (T3._Fld28 <> @P3) AND (T3._Fld28 <> @P4)
GROUP BY T3._Fld27RRef
HAVING (CAST(SUM(T3._Fld28) AS NUMERIC(27, 2))) <> 0.0

UNION ALL

-- Получение данных из основной таблицы движений (без использования итогов)
SELECT
T4._Fld27RRef AS Fld27RRef,
CAST(CAST(SUM(CASE WHEN T4._RecordKind = 0.0 THEN -T4._Fld28 ELSE T4._Fld28 END) AS NUMERIC(21, 2)) AS NUMERIC(27, 2)) AS Fld28Balance_
FROM dbo._AccumRg26 T4
-- Фильтр накладывается по периоду, с учетом переданного параметра в запрос
-- Обычно здесь указывается период таким образом, чтобы получить записи, для которых итоги еще не рассчитаны,
-- но вникать в работу виртуальных таблиц сейчас не будем.
WHERE T4._Period >= @P5 AND T4._Period < @P6 AND T4._Active = 0x01 AND ((T4._Fld27RRef = @P7))
GROUP BY T4._Fld27RRef
HAVING (CAST(CAST(SUM(CASE WHEN T4._RecordKind = 0.0 THEN -T4._Fld28 ELSE T4._Fld28 END) AS NUMERIC(21, 2)) AS NUMERIC(27, 2))) <> 0.0
) T2
GROUP BY T2.Fld27RRef
HAVING (CAST(SUM(T2.Fld28Balance_) AS NUMERIC(33, 2))) <> 0.0
) T1

Ничего особенного, обычные фильтры по датам. Обратите внимание, что при получении данных из основной таблицы движений, условие по периоду сделано таким образом, что не учитывает последнюю секунду переданного параметра "Период".

WHERE
T4._Period >= @P5
AND
T4._Period < @P6 -- Вот оно!

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

Теперь попробуем вместо даты передать момент времени.

ДокументОбъект = Документы.ПростойДокумент.НайтиПоНомеру("000000001");

Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| КакойТоТамРегистрОстатковОстатки.Номенклатура КАК Номенклатура,
| КакойТоТамРегистрОстатковОстатки.КоличествоОстаток КАК КоличествоОстаток
|ИЗ
| РегистрНакопления.КакойТоТамРегистрОстатков.Остатки(
|   &Период,
|   Номенклатура = &Номенклатура)
|  КАК КакойТоТамРегистрОстатковОстатки";
Запрос.УстановитьПараметр("Номенклатура", Справочники.Номенклатура.Товар1);
Запрос.УстановитьПараметр("Период", ДокументОбъект.МоментВремени());
РезультатЗапроса = Запрос.Выполнить();

В этом случае запрос на стороне базы данных уже будет несколько отличаться.

-- Запрос с использованием момента времени
SELECT
T1.Fld27RRef,
T1.Fld28Balance_
FROM (
SELECT
T2.Fld27RRef AS Fld27RRef,
CAST(SUM(T2.Fld28Balance_) AS NUMERIC(33, 2)) AS Fld28Balance_
FROM (
-- Получение данных из текущих итогов
SELECT
T3._Fld27RRef AS Fld27RRef,
CAST(SUM(T3._Fld28) AS NUMERIC(27, 2)) AS Fld28Balance_
FROM dbo._AccumRgT29 T3
-- Фильтр накладывается только по дате текущих итогов (3999-11-01 00:00:00 - дата конца света по календарю 1С)
WHERE T3._Period = @P1 AND ((T3._Fld27RRef = @P2)) AND (T3._Fld28 <> @P3) AND (T3._Fld28 <> @P4)
GROUP BY T3._Fld27RRef
HAVING (CAST(SUM(T3._Fld28) AS NUMERIC(27, 2))) <> 0.0

UNION ALL

-- Получение данных из основной таблицы движений (без использования итогов)
SELECT
T4._Fld27RRef AS Fld27RRef,
CAST(CAST(SUM(CASE WHEN T4._RecordKind = 0.0 THEN -T4._Fld28 ELSE T4._Fld28 END) AS NUMERIC(21, 2)) AS NUMERIC(27, 2)) AS Fld28Balance_
FROM dbo._AccumRg26 T4
-- Фильтр накладывается по периоду, с учетом переданного параметра в запрос,
-- а также добавилось условие, что ссылка на регистратор больше ИЛИ равен ссылке, которая находилась в переданном моменте времени
WHERE (T4._Period > @P5 OR T4._Period = @P6 AND T4._RecorderRRef >= @P7) AND T4._Period < @P8
-- В этом случае параметр @P5 указывает с какой даты получать движения, для которых еще нет итогов
-- Параметр @P6 - это дата из момента времени
-- А параметр @P8 - это дата, на которую хранятся текущие итоги
-- Опять же, углубляться в работу виртуальной таблицы не будем :)
AND T4._Active = 0x01 AND ((T4._Fld27RRef = @P9))
GROUP BY T4._Fld27RRef
HAVING (CAST(CAST(SUM(CASE WHEN T4._RecordKind = 0.0 THEN -T4._Fld28 ELSE T4._Fld28 END) AS NUMERIC(21, 2)) AS NUMERIC(27, 2))) <> 0.0
) T2
GROUP BY T2.Fld27RRef
HAVING (CAST(SUM(T2.Fld28Balance_) AS NUMERIC(33, 2))) <> 0.0
) T1

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

Во-первых, теперь изменилась логика отбора:

1. Дата движения должна быть в периоде, где движения еще не рассчитаны
2. ИЛИ дата движения должна равняться дате из момента времени. При этом ссылка регистратора может быть больше или равна ссылке из момента времени.

Во-вторых, теперь у нас могут быть потенциальные проблемы с производительностью из-за использования условия "OR" (ИЛИ) в запросе. Ведь всем известно, что при использовании "ИЛИ" в фильтрах запросов индексы не могут быть использованы.

Но давайте посмотрим, что будет, если использовать границу.

Для начала попробуем использовать границу с видом "Исключая".

ДокументОбъект = Документы.ПростойДокумент.НайтиПоНомеру("000000001");

Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| КакойТоТамРегистрОстатковОстатки.Номенклатура КАК Номенклатура,
| КакойТоТамРегистрОстатковОстатки.КоличествоОстаток КАК КоличествоОстаток
|ИЗ
| РегистрНакопления.КакойТоТамРегистрОстатков.Остатки(
|   &Период,
|   Номенклатура = &Номенклатура)
|  КАК КакойТоТамРегистрОстатковОстатки";
Запрос.УстановитьПараметр("Номенклатура", Справочники.Номенклатура.Товар1);
ГраницаПолученияОстатков = Новый Граница(ДокументОбъект.МоментВремени(), ВидГраницы.Исключая);
Запрос.УстановитьПараметр("Период", ГраницаПолученияОстатков);
РезультатЗапроса = Запрос.Выполнить();

Что же на стороне СУБД?

-- Запрос с использованием границы (вид границы = Исключая)
SELECT
T1.Fld27RRef,
T1.Fld28Balance_
FROM (
SELECT
T2.Fld27RRef AS Fld27RRef,
CAST(SUM(T2.Fld28Balance_) AS NUMERIC(33, 2)) AS Fld28Balance_
FROM (
-- Получение данных из текущих итогов
SELECT
T3._Fld27RRef AS Fld27RRef,
CAST(SUM(T3._Fld28) AS NUMERIC(27, 2)) AS Fld28Balance_
FROM dbo._AccumRgT29 T3
-- Фильтр накладывается только по дате текущих итогов (3999-11-01 00:00:00 - дата конца света по календарю 1С)
WHERE T3._Period = @P1 AND ((T3._Fld27RRef = @P2)) AND (T3._Fld28 <> @P3) AND (T3._Fld28 <> @P4)
GROUP BY T3._Fld27RRef
HAVING (CAST(SUM(T3._Fld28) AS NUMERIC(27, 2))) <> 0.0

UNION ALL

-- Получение данных из основной таблицы движений (без использования итогов)
SELECT
T4._Fld27RRef AS Fld27RRef,
CAST(CAST(SUM(CASE WHEN T4._RecordKind = 0.0 THEN -T4._Fld28 ELSE T4._Fld28 END) AS NUMERIC(21, 2)) AS NUMERIC(27, 2)) AS Fld28Balance_
FROM dbo._AccumRg26 T4
-- Фильтр накладывается по периоду, с учетом переданного параметра в запрос,
-- а также добавилось условие, что ссылка на регистратор больше ссылки, которая находилась в переданном моменте времени
WHERE (T4._Period > @P5 OR T4._Period = @P6 AND T4._RecorderRRef >= @P7) AND T4._Period < @P8 AND T4._Active = 0x01 AND ((T4._Fld27RRef = @P9))
-- В этом случае параметр @P5 указывает с какой даты получать движения, для которых еще нет итогов
-- Параметр @P6 - это дата из момента времени
-- А параметр @P8 - это дата, на которую хранятся текущие итоги
GROUP BY T4._Fld27RRef
HAVING (CAST(CAST(SUM(CASE WHEN T4._RecordKind = 0.0 THEN -T4._Fld28 ELSE T4._Fld28 END) AS NUMERIC(21, 2)) AS NUMERIC(27, 2))) <> 0.0
) T2
GROUP BY T2.Fld27RRef
HAVING (CAST(SUM(T2.Fld28Balance_) AS NUMERIC(33, 2))) <> 0.0
) T1

Если посмотреть внимательно, то никаких различий от передачи обычного момента времени Вы не найдете. Фактически, варианты фильтра по моменту времени и границе вида "Исключая" идентичны.

И последний пример — граница с видом "Включая".

ДокументОбъект = Документы.ПростойДокумент.НайтиПоНомеру("000000001");

Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| КакойТоТамРегистрОстатковОстатки.Номенклатура КАК Номенклатура,
| КакойТоТамРегистрОстатковОстатки.КоличествоОстаток КАК КоличествоОстаток
|ИЗ
| РегистрНакопления.КакойТоТамРегистрОстатков.Остатки(
|   &Период,
|   Номенклатура = &Номенклатура)
|  КАК КакойТоТамРегистрОстатковОстатки";
Запрос.УстановитьПараметр("Номенклатура", Справочники.Номенклатура.Товар1);
ГраницаПолученияОстатков = Новый Граница(ДокументОбъект.МоментВремени(), ВидГраницы.Включая);
Запрос.УстановитьПараметр("Период", ГраницаПолученияОстатков);
РезультатЗапроса = Запрос.Выполнить();

В этот раз в SQL-запрос будет небольшое отличие.

-- Запрос с использованием границы (вид границы = Включая)
SELECT
T1.Fld27RRef,
T1.Fld28Balance_
FROM (
SELECT
T2.Fld27RRef AS Fld27RRef,
CAST(SUM(T2.Fld28Balance_) AS NUMERIC(33, 2)) AS Fld28Balance_
FROM (
-- Получение данных из текущих итогов
SELECT
T3._Fld27RRef AS Fld27RRef,
CAST(SUM(T3._Fld28) AS NUMERIC(27, 2)) AS Fld28Balance_
FROM dbo._AccumRgT29 T3
-- Фильтр накладывается только по дате текущих итогов (3999-11-01 00:00:00 - дата конца света по календарю 1С)
WHERE T3._Period = @P1 AND ((T3._Fld27RRef = @P2)) AND (T3._Fld28 <> @P3) AND (T3._Fld28 <> @P4)
GROUP BY T3._Fld27RRef
HAVING (CAST(SUM(T3._Fld28) AS NUMERIC(27, 2))) <> 0.0

UNION ALL

-- Получение данных из основной таблицы движений (без использования итогов)
SELECT
T4._Fld27RRef AS Fld27RRef,
CAST(CAST(SUM(CASE WHEN T4._RecordKind = 0.0 THEN -T4._Fld28 ELSE T4._Fld28 END) AS NUMERIC(21, 2)) AS NUMERIC(27, 2)) AS Fld28Balance_
FROM dbo._AccumRg26 T4
-- Фильтр накладывается по периоду, с учетом переданного параметра в запрос,
-- а также добавилось условие, что ссылка на регистратор больше ссылки, которая находилась в переданном моменте времени
WHERE (T4._Period > @P5 OR T4._Period = @P6
AND T4._RecorderRRef > @P7) -- Вот тут!!! Сравнение теперь "Больше", вместо "Больше или равно"
AND T4._Period < @P8 AND T4._Active = 0x01 AND ((T4._Fld27RRef = @P9))
-- В этом случае параметр @P5 указывает с какой даты получать движения, для которых еще нет итогов
-- Параметр @P6 - это дата из момента времени
-- А параметр @P8 - это дата, на которую хранятся текущие итоги
GROUP BY T4._Fld27RRef
HAVING (CAST(CAST(SUM(CASE WHEN T4._RecordKind = 0.0 THEN -T4._Fld28 ELSE T4._Fld28 END) AS NUMERIC(21, 2)) AS NUMERIC(27, 2))) <> 0.0
) T2
GROUP BY T2.Fld27RRef
HAVING (CAST(SUM(T2.Fld28Balance_) AS NUMERIC(33, 2))) <> 0.0
) T1

Одно маленькое различие для текста запроса, но большое различие для логики работы запроса! Сравнение с ссылкой из момента времени теперь выполняется по условию "Больше", а не "Больше или равно" как это было ранее.

Такое условие позволяет получить данные из текущих итогов, при этом исключить запись из таблицы движений для документа из момента времени. Да, да! Вид границы "Включая" исключает запись из таблицы движений и учитывает только запись в итогах.

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

Также стоит отметить, что потенциальные проблемы с производительностью здесь такие же, как и при использовании момента времени, т.к. условие "ИЛИ" также присутствует и индекс будет использоваться неэффективно.