СКД: Группировка по регистратору и полю-периоду (развернутый вопрос) #566694

Все дальнейшие примеры приведены для платформы 8.2.14.439 / Демонсрационная конфигурация УТ 11.0.4.5 Все сокращенные ссылки ведут в Google Docs (учетная запись не требуется) Имеем самый простой запрос к виртуальной таблице "Остатков и Оборотов" регистра "ТоварыНаСкладах". Собственно схема компоновки: В схеме имеется поле - реквизит измерения "Склад". Всем полям назначены корректные роли. В настройках в группировках строк имеем группировку по номенклатуре Ситуация 1: Настройки: Добавляем вывод детальных записей (Поле Регистратор, Сортировка по регистратору). В результате получаем корректные остатки по измерению номенклатуры, по детальным записям начальные и конечные остатки, как и ожидалось "СКАЧУТ" - т.е. нарушается связь: начальный остаток записи равен конечному остатку предыдущей записи. Результат: Ситуация 2: Настройки: Исправляем предыдущую ситуацию - вместо детальных записей выводим группировку по регистратору. Все отлично, т.е. так как и надо. Остатки по регистратору "не скачут". Результат: Ситуация 3: Настройки: Добавляем группировку Колонок "Период месяц". Так как с группировкой по регистратору вывести не получится, вместо группировки по регистратору используем детальные записи с полем регистратор. И возвращаемся к ситуации 1 :( Хотелось бы обратить внимание как в данном случае выводятся остатки по регистратору - а именно в колонке периода месяц выводятся только данные по регистраторам из ДАННОГО периода Результат: Ситуация 4: Настройки: Для того чтобы можно было сгруппировать по регистратору и по периоду, меняем в схеме компоновки у поля периода (в данном примере "ПериодМесяц") Настройку Роли, а именно снимаем флажок ДОПОЛНИТЕЛЬНОГО ПЕРИОДА Теперь мы можем сгруппировать и по регистратору и по периоду. Выполняем. И опять облом :( Теперь получается что по колонке периоду у всех регистраторов Начальный и Конечный Остатки одинаковы - соответственно Начальный и конечный остатки по ТЕКУЩЕМУ периоду :( (Результат конечно ожидаем, когда знаешь как СКД рассчитывает остатки - но сейчас не об этом) Да и к тому же в колонке выводятся остатки и для регистраторов из других периодов (но с этим еще можно бороться) Результат: Убил кучу времени чтобы реализовать и группировку строк по регистратору и группировку колонок по периоду так, чтобы остатки выводились корректно по регистраторам, а именно - начальный остаток записи, равен конечному остатку предыдущей записи и т.д. - т.е. Примерно как при настройках в Ситуации 3, но чтобы остатки "не скакали" Добиться желаемого результата (и оставить масштабируемость настроек и скорость работы отчета на приемлемом уровне) пока не удается :( Если кто сталкивался с такой проблемой и знает решение или ссылки на информацию, которая поможет его найти - подскажите, пожалуйста.

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

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

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

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

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

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

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

Перепостил на партнерке. Может там спецы подскажут.

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

Пока ответили ссылками: (нужна подписка ИТС)

статья на ИТС "Типичные проблемы при расчете остатков" вот здесь (, пост 24

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

Все эти статьи изучил не один раз, к сожалению, понимания как решить проблему это не дало... Может я упускаю какой-то момент :/

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

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

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

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

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

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

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

Вот примерно так должен выглядеть отчет:

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