Доброго всем дня.
Имеется простой запрос по регистру остатков, в функциях которого есть обращение вида:



где Количество и Сумма - ресурсы регистра.

Далее делается запрос по регистру, обращение ко всем его группировкам и наконец к функциям вида Запрос.КолНач и т.д.

Формирую запрос по конкретному набору измерений.
И проблема в том, что функции отрабатывают неверно.

Если делаешь запрос за период 01.04.2024-30.04.2024, то все остатки корректны.
Если делаешь запрос за период 10.04.2024-20.04.2024, то все остатки корректны.
Если делаешь запрос за период 02.04.2024-30.04.2024, то зануляется КОНЕЧНЫЙ остаток.
Если делаешь запрос за период 01.04.2024-29.04.2024, то зануляется НАЧАЛЬНЫЙ остаток.

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

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

Посоветуйте, что ещё можно попробовать в такой ситуации ?

Нужно:
1) сделать пересчет регистров в конфигураторе
2) выложить сюда для анализа полный текст запросв.

Вместо пересказа может текст запроса просто покажете?

(1)
Пробовал сделать полный пересчёт регистров - безрезультатно.

(2)
Запрос = СоздатьОбъект("Запрос");
ТекстЗапроса = "
|Период с ДатаНачала по ДатаКонца;
|Продукт = Регистр.Сыр.Продукт;
|Варка = Регистр.Сыр.Варка;
|ДатаВарки = Регистр.Сыр.Документ.ДатаДок;
|Головы = Регистр.Сыр.Головы;
|Вес = Регистр.Сыр.Вес;
|ВесЗрелого = Регистр.Сыр.ВесЗрелого;
|ЗПодразделение = Регистр.Сыр.Подразделение;
|Док = Регистр.Сыр.ТекущийДокумент;
|ДатаСозревания = Регистр.Сыр.ДатаСозревания;
|Группировка ЗПодразделение;
|Группировка Продукт;
|Группировка ДатаВарки;
|Группировка Варка;
|Функция Приход_Г = Приход(Головы);
|Функция Приход_В = Приход(Вес);
|Функция Приход_З = Приход(ВесЗрелого);
|Функция Расход_Г = Расход(Головы);
|Функция Расход_З = Расход(ВесЗрелого);
|Функция СНД_Г = НачОст(Головы);
|Функция СНД_З = НачОст(ВесЗрелого);
|Функция СКД_Г = КонОст(Головы);
|Функция СКД_З = КонОст(ВесЗрелого);
|";          

Если Сыр.Выбран() = 1 Тогда
    ТекстЗапроса = ТекстЗапроса +
        "Условие (Продукт=Сыр);
        |";                    
КонецЕсли;
    
Если Подразделение.Выбран() = 1 Тогда
    ТекстЗапроса = ТекстЗапроса+
        "Условие(ЗПодразделение = Подразделение);
        |";                    
КонецЕсли;
    
Если Запрос.Выполнить(ТекстЗапроса) = 0 Тогда
    Возврат;
КонецЕсли;
    
Пока Запрос.Группировка(1) = 1 Цикл
    Пока Запрос.Группировка(2) = 1 Цикл
        Пока Запрос.Группировка(3) = 1 Цикл
            Пока Запрос.Группировка(4) = 1
//Получение результатов вида
Запрос.Приход_З
Запрос.Расход_З
Запрос.СКД_З
Запрос.СНД_З

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

Три цикла в запросах - это нормально?

(6)
Между этими циклами ещё формируется печатная форма, я убрал лишний код для удобства чтения.

База СКЛ ДБФ? для ДБВ размер файла данного регистра и повторить эксперимент в монопольном режиме.

(8)
SQL 2008 R2
1С 7.7.027

(7) Для начала неплохо бы понять: ошибка в остатках или всё же в данном трёхцикловом коде. Для этого посмотреть те же интервалы на любом универсальном отчёте по регистрам 7.7

(10)
Проверял движения через стандартный отчёт RegPrint на все запрошенные даты - по этому набору измерений никаких движений нет.

К тому же проблема на всех граничных значениях любого месяца.

Если делаешь запрос за период 01.04.2024-30.04.2024, то все остатки корректны.
Если делаешь запрос за период 10.04.2024-20.04.2024, то все остатки корректны.
Если делаешь запрос за период 02.04.2024-30.04.2024, то зануляется КОНЕЧНЫЙ остаток.
Если делаешь запрос за период 01.04.2024-29.04.2024, то зануляется НАЧАЛЬНЫЙ остаток.

На май тоже всё хорошо для периода 01.05.2024-31.05.2024 и всё плохо для периодов
01.05.2024-30.05.2024 и 02.05.2024-31.05.2024.

|ДатаВарки = Регистр.Сыр.Документ.ДатаДок; убрать
|Группировка ДатаВарки; заменить на |Группировка День;

(11) + остатки и на начало, и на конец отбираются верно при любых интервалах запроса.

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

причина - в (13)

(14) Значит ошибка в Вашем коде.

(15) Это верно. Но тогда бы вообще нулились остатки по любым интервалам, а у автора выпадают границы...

(0) Документ - это чего, измерение регистра, да ?
И чего пишешь туда, текущий документ, толкающий регистр ?

(13)
Да, похоже мы на верном пути.
При Вашем варианте отбирает много лишних строк, но по крайней мере не пропадают остатки.

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

(20) а почему ДатаВарки пустая, могу только догадываться, что в регистр её добавляли позже и не перезаполняли все движения.

(20) Тогда проверить все движения на предмет пустого измерения Документ

Должно нормально всё работать.

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

(13)
Остатки не пропадают, но ломается логика отчёта. 🤦
К примеру: формируем за месяц, на остатках имеем 3 партии (1 с пустой датой (старая, без заполненного документа) и 2 с заполненной).
Все остатки на месте, но в табличной форме за счёт Группировки по дням уже не 3 строки с партиями, а 3 * Количество дней в месяце.

(24)
Согласен, но база писалась задолго до меня, и с кодом тут полный швах, полно переменных "ку", "пр", "ню" и т.п. Так и с реквизитами. Но, имеем что имеем.

(25) Проапдейть табличку движений, можешь, хоть всё на один документ повесить. Потом пересчитай итоги прямым запросом.

(25) с какого перепугу там 3 * Количество дней в месяце. Где-то используется "ВСЕ" и выложенный запрос не такой как в обработке? Замени на "все вошедшие в запрос". По большому счету тут наверное проще выгрузить запрос в ТЗ и дальше уже ее сортировать, сжимать и обрабатывать.

А по хорошему переименовываешь Документ В ДокументПрих.
и потом в конфигураторе поиск и замена Регистр.Сыр.Документ на Регистр.Сыр.ДокументПрих
на полчаса работы максимум и в будущем никаких глюков.

Бывали у меня когда то глюки с Пока Запрос.Группировка(3) Помогало прямое указание имени группировки
Пока Группировка("День")=1. Если в отчете не предполагается произвольное перемещение группировок вверх вниз предпочитаю явно прописывать группировки.

(25) скорее всего обрезали базу документ тупа напрямую грохнули, а потом очистили записи.
Для пустого документа Запись Документ.ДатаДок не верна. Тип у реквизита Документ хоть "Документ" или вообще неопределенный ?

(27)
Нет, я оказался неправ, движения регистра имеют заполненный реквизит "Документ" с даты начала ведения базы. Буду раскапывать, почему отчёт для моих конкретных данных возвращает пустую дату.

(28)
Нет в запросе ни конструкции "ВСЕ", ни "Все вошедшие в запрос".
В ТЗ пока не хочу идти, дабы не потерять все красивые группировки итогов.

(30)
Любопытно, попробую.

(31) Обрезка была в 2016 году.
Реквизит "Документ" имеет тип "Документ".

(30)
Попробовал, не помогло.

(30)
С такой группировкой всё грустно: запрос за один день - 3 строки, за 2 дня - 6 строк и т.д.

В общем поменял в исходном запросе
|ДатаВарки = Регистр.Сыр.Документ.ДатаДок;
на
|ДатаВарки = Регистр.Сыр.Документ;

и всё, остатки перестали исчезать, на любые даты всё корректно.
А в печати просто заменю
Запрос.ДатаВарки
на
Запрос.ДатаВарки.ДатаДок

По логике всё должно быть ОК, всё равно не может быть в одной дате больше одного дока.

Но конечно поведение 1с оставляет вопросы:
при группировке по пустому документу всё ОК, а по пустой дате - пропажа остатков.

Всем спасибо огромное за помощь !

(32) посмотри на ИС поиск по NotaBene - универсальный отчёт по ТЗ, с группировками, шахматной..

(35) в документе штатно не бывает пустой даты.

(0) посмотри провайлер, семерышные запросы глючат когда через точку выбираешь данные из объекта, когда в запросе присутствуют данные из регистра в котором есть поля с одинаковым типом.

(39) "когда в запросе присутствуют данные из регистра в котором есть поля с одинаковым типом."
- Как-то мутновато, пример примерный такого чорного запроса и структура регистра с одинаковым типом..?
.

(39) Поэтому про "чорные запросы" пора забыть.