Все дальнейшие примеры приведены для платформы 8.2.14.439 / Демонсрационная конфигурация УТ 11.0.4.5
Все сокращенные ссылки ведут в Google Docs (учетная запись не требуется)

Имеем самый простой запрос к виртуальной таблице "Остатков и Оборотов" регистра "ТоварыНаСкладах".

Собственно схема компоновки: http://goo.gl/oIWhb
В схеме имеется поле - реквизит измерения "Склад". Всем полям назначены корректные роли.
В настройках в группировках строк имеем группировку по номенклатуре

Ситуация 1:

Настройки: http://goo.gl/6vqwD

Добавляем вывод детальных записей (Поле Регистратор, Сортировка по регистратору).

В результате получаем корректные остатки по измерению номенклатуры, по детальным записям начальные и конечные
остатки, как и ожидалось "СКАЧУТ" - т.е. нарушается связь: начальный остаток записи равен конечному остатку предыдущей записи.

Результат: http://goo.gl/v1KOs

Ситуация 2:

Настройки: http://goo.gl/bPkPV

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

Результат: http://goo.gl/9NSgg

Ситуация 3:

Настройки: http://goo.gl/imTyC

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

И возвращаемся к ситуации 1 :(
Хотелось бы обратить внимание как в данном случае выводятся остатки по регистратору - а именно в колонке периода месяц выводятся только
данные по регистраторам из ДАННОГО периода

Результат: http://goo.gl/B6zlO

Ситуация 4:

Настройки: http://goo.gl/IqR9q

Для того чтобы можно было сгруппировать по регистратору и по периоду, меняем в схеме компоновки у поля периода (в данном примере "ПериодМесяц")
Настройку Роли, а именно снимаем флажок ДОПОЛНИТЕЛЬНОГО ПЕРИОДА

Теперь мы можем сгруппировать и по регистратору и по периоду. Выполняем. И опять облом :(
Теперь получается что по колонке периоду у всех регистраторов Начальный и Конечный Остатки одинаковы - соответственно Начальный и конечный остатки
по ТЕКУЩЕМУ периоду :(
(Результат конечно ожидаем, когда знаешь как СКД рассчитывает остатки - но сейчас не об этом)

Да и к тому же в колонке выводятся остатки и для регистраторов из других периодов (но с этим еще можно бороться)

Результат: http://goo.gl/ffQ66

Убил кучу времени чтобы реализовать и группировку строк по регистратору и группировку колонок по периоду так, чтобы остатки выводились корректно по регистраторам,
а именно - начальный остаток записи, равен конечному остатку предыдущей записи и т.д. - т.е. Примерно как при настройках в Ситуации 3, но чтобы остатки "не скакали"
Добиться желаемого результата (и оставить масштабируемость настроек и скорость работы отчета на приемлемом уровне) пока не удается :(

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

v8: СКД: Начальный и конечный остатки в итогах по группировкам

(0) Группировка по регистратору - это значит должна быть ОБЯЗАТЕЛЬНО в запросе выбран период секунда. В настройках СКД его можно отключить.

(1) По ГРУППИРОВКАМ остатки считаются корректно, проблема в одновременной группировке по регистратору (в строках) и по полю периоду (в колонках - например ПериодМесяц) - в (0) в ссылках на результат продемонстрирована суть проблемы.
Еще раз повторюсь - в общем остатки считаются корректно - по группировке Номенклатура - остатки корректны в любой из перечисленных ситуаций...

(0) и (1) Секунда выбрана, Все роли назначены корректно, Реквизиту измерения так же назначена роль, и указан родитель

Все правила описания запроса для полей остатка знаю, алгоритм расчета остатков знаю - но это не помогает

Просьба (большая) пройтись по ссылкам и посмотреть наглядно на проблему.

Заранее спасибо.

(1) У Вас репутация хорошего специалиста по СКД, могли бы Вы  дать более развернутый ответ (указать на "косяк")... по ссылке сходил - все условия выполнены, но не помогает :(

(2) Оч смешно, а в пределах секунды?
(3) Период должен быть раньше.

(4) Что значит "Период должен быть раньше" - совершенно не понял к чему это... Раньше чего? Раньше чем Группировка по регистратору? Так в этом и есть одна из проблем, как сделать чтобы в колонках была группировка по периоду, а в строках по регистратору и при этом выводились нормально остатки по группировке "Регистратор".

Насчет "обязательности" секунды при выборе в запросе регистратора (но если он выбирается в роли поля-периода) - так и есть, это обязательное условие для корректного расчета остатков.

2 All

Есть какие-нибудь идеи как решить проблему?

(up) Может быть хоть какие-нибудь идеи?

Эта тема мне интересна. Оставьте здесь ссылку на партнерский форум, если отметитесь там.

(up) Попробую еще раз поднять вопрос :/

(8) Перепостил на партнерке. Может там спецы подскажут.
http://partners.v8.1c.ru/forum/thread.jsp?id=961676#961676

(9) У меня к сожалению нет туда доступа, если будет какая-то информация дайте знать, пожалуйста.
И спасибо за помощь.

Пока ответили ссылками: (нужна подписка ИТС)
http://its.1c.ru/db/metod81#content:2664:1
http://its.1c.ru/db/metod81#content:2913:1
http://its.1c.ru/db/metod81#content:3093:1

статья на ИТС "Типичные проблемы при расчете остатков"
вот здесь (v8: Почему СКД задваивает данные ?, пост 24

(12) Все типичные проблемы учтены (и на самом деле суть проблемы несколько в другом).

Данные не задваиваются. По сути даже остатки считаются корректно... Проблема в том, что в данном случае для вывода остатков по регистратору мы не можем использовать детальные записи (остатки по РЕГИСТРАТОРУ (по детальным записям) будут скакать, т.к. в запросе выбирается больше измерений, чем измерений по которым мы группируем, в примере в (0) мы группируем по номенклатуре, но у нас так же есть отбор по РЕКВИЗИТУ измерения СКЛАД, что влечет за собой добавление в запрос выборки по СКЛАДАМ (сейчас не будем обсуждать что можно разделить поля отбора и группировок - суть совершенно не в этом)... так вот при всем при этом детальные записи будут получены для каждого значения измерения СКЛАД, что в общем-то нам не нужно - значит нужно группировать по регистратору... но как только мы группируем по регистратору, одновременно группировать в колонках по периоду, стандартными способами становится невозможно. И даже добавление по группировке-периоду (в строках) перед группировкой по регистратору ситуацию не меняет.

ОСНОВНАЯ СУТЬ ПРОБЛЕМЫ - это отображение остатков при одновременной группировке по полям-периодам (в том числе по регистратору) и в строках и в колонках

(11) Все эти статьи изучил не один раз, к сожалению, понимания как решить проблему это не дало...

Может я упускаю какой-то момент :/

Попробую еще уточнить проблему...

Если мы имеем группировку по полю-периоду в строках (Например ПериодДень) и группировку по полю-периоду в колонках (Например ПериодМесяц), то для всех строк в рамках группировки по колонке (ПериодМесяц) остатки будут одинаковые - т.е. остатки для ПЕРИОДМЕСЯЦ...

например для значений ПЕРИОДДЕНЬ:

1.04
2.04
3.04

Начальные и конечные остатки будут одинаковые в колонке по ПериодМЕСЯЦ (1.04) независимо от того какие были движения (оборот), и будут соответственно равны НАЧАЛЬНЫЙ - начальный остаток на 1.04 и КОНЕЧНЫЙ ОСТАТОК на 30.04

> Железнов Павел (1-й Центр "Программные технологии", Москва)

Немного непонятно какую задачу вы решаете. Если в итоге вы хотите получить остатки по периодам или остсатки по документам то вы зашли не с того конца. Обычно это делается просто динамически-собираемым запросом (для каждого периода свой подзапрос или своя временная таблица) и потом результат запроса передаётся в СКД как объектный источник.

(16)

Задачу вообщем можно описать так:

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

Пока искал решение сам пришел к подобному решению:

  Для полей-периодов (ПериодМесяц) менял роль на "ИЗМЕРЕНИЕ", отдельным запросом получал остатки на начало и конец каждого периода, из основного запроса условием (по пустому регистратору) убирал эти самые остатки... и объединял запросы... тогда все получалось как нужно, за исключением общих итогов (их я просто отключал в настройках, и выводил колонку детальные записи без полей (только с ресурсами - тем самым общие итоги так же получаются корректными)

Основная проблема в использовании этого решения... то, что заранее не известно какие настройки для отчета задаст пользователь (возможно ему не нужна будет детализация до регистратора, или развертка по периодам) - т.е. с таким решением сильно снижается масштабируемость отчета, и растет время его формирования. (ну и просто хотелось бы решить все средствами СКД - не прибегая к ОБЪЕКТНЫМ источникам

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

В таком случае, хотелось бы найти такое решение, для которого не пришлось бы выходить за рамки СхемыКомпоновки - т.е. обойтись без использования объектных источников.

Вообще результат отчета на СКД при подобных группировках (группировки по периодам и в строках и в колонках) я бы не назвал очевидным - ожидал другого результата :(

Зачем нужны группировки по периодам и в строках и в колонках? Почему нельзя обойтись группировкой строк? Какой сакральный смысл в остатках на "15.08.2011" в колонке "май 2011"?

От себя:

Если чесно - не вижу смысла в подобном отчете. Общий отчет может показывать периоды колонками, а расшифровка разъяснять по конкретной позиции.

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

Обороты периодами - ок: общий список. Посмотреть внутрь - ок: карточка.

(19) Группировки строк по периоду - здесь должна быть группировка по регистратору (это ведь тоже поле-период, вообщем конечно)

Группировка колонок по периоду - здесь ПериодМесяц - это просто развертка по периодам.

Почему нельзя обойтись группировкой строк (что делается без проблем и без танцев с бубном) - не знаю, хотят видеть развертку по периодам именно по горизонтале, так удобнее пользователям.

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

(20) Если честно, я тоже не вижу особого смысла в подобной ДЕТАЛИЗАЦИИ отчета, но ПОЛЬЗОВАТЕЛИ утверждают что он есть :(

Мы люди подневольные... говорят надо - значит надо

Вот примерно так должен выглядеть отчет: http://goo.gl/M6IE8

Закладка. Утром посмотрю.