Имя: Пароль:
1C
 
Странности с отбором в СКД при наличии ДВУХ наборов данных...
0 AquaKosh
 
01.02.10
15:41
Приветствую, коллеги. Столкнулся с непонятным поведением СКД при наличии отбора в ОДНОМ из наборов данных (отбор СКДшный, который в {}).

Есть основная таблица (первый набор данных - факт) и вспомогательная (второй набор данных - план). Вспомогательная цепляется к основной (план к факту).
1) В самом примитивном варианте это выглядит так:
---------------------------------
Товар      |  план    |  факт   |
---------------------------------
Мясо       |    5     |   10    |
Сало       |    6     |   15    |
---------------------------------

2) Если, к примеру, плана нет, то выводится один факт (в плане 0).
---------------------------------
Товар      |  план    |  факт   |
---------------------------------
Мясо       |          |   10    |
Сало       |          |   15    |
---------------------------------

Во вспомогательном наборе данных (ПЛАН) есть отбор по товару, при активизации которого СКД выводит пустую таблицу (шапка и сразу итог), а по идее должна выводить таблицу как в п.2, т.е. должен выводиться как минимум факт.

Вся странность в том, что отбор в ПЛАН'е, заданный в запросе через параметр отрабатывает нормально, т.е. фильтруется только план, а если задать отбор в {}, то при активизации его получаю таблицу без строк.

Может кто сталкивался?

P.S.
1. Сделал маленький отчёт, иллюстрирующий проблему (отчёту не нужны данные из базы, они прописаны в запросах).
http://slil.ru/28578325
По-умолчанию отчёт выводит всё правильно, но стоит в настройках поставить активность у отбора - пустота.

2. Два набора данных нужно обязательно. :)

3. Проблему можно обойти через задание отбора параметром в запросе, но это не есть правильный выход...

4. Платформа 8.1.15. На всякий случай пробовал на 12-ой - тоже самое.
1 IronDemon
 
01.02.10
15:55
Зачем НоменклатураПлан? Поставь в условиях везде Номенклатура
2 AquaKosh
 
01.02.10
15:57
(1) Это пример. В реальном отчёте условие должно накладываться ТОЛЬКО на ПЛАН.
3 AquaKosh
 
01.02.10
15:58
(1) +(2) А "НоменклатураПлан", чтобы СКД не накладывала отбор на факт.
4 IronDemon
 
01.02.10
16:25
Я не вижу разницы в отборе номенклатуры.
5 AquaKosh
 
01.02.10
16:35
(4) Отбор по номенклатуре стоит только в план'овом наборе данных. И фильтровать этот отбор должен только план'овые данные, а этого не происходит, точнее происходит фигня какая-то - то-ли фильтруется всё, то-ли ещё что-то, но в итоге - пусто.
Получал результирующий запрос, который формирует СКД - параметр на отбор стоит только в плане (что собственно и должно быть), но СКД всё равно выводит пустую таблицу.
6 AquaKosh
 
01.02.10
17:48
ап
7 IronDemon
 
01.02.10
17:56
Какой смысл отбора по Плану если левое соединение с Фактом?
8 AquaKosh
 
01.02.10
18:09
(7) Этот пример... это просто пример, имеющий мало общего с реальным отчётом.
В реальном же отчёте, конечно никакого отбора но номенклатуре нет.
Пример нужен только для того, чтобы показать странность, связанную с работой отбора, которую я не могу победить настройками СКД.
А в реальном отчёте плановые суммы будут меняться тоже отбором, но не по номенклатуре, а по плановым сценариям.
9 MNS_Ротерта
 
01.02.10
18:21
(0) в статье по переходу на 8.2 с 8.1 на ИТС было скзано что если есть 2 связанных набора данных то если в одном из них накладывается отбор, то при связи что то там гоорилось будут добавляться дополнительные псевдо записи. ну суть в том что получишь неверный результат. может быть у тебя как раз такая ситуация?
10 MNS_Ротерта
 
01.02.10
18:21
(0) СКД вообще часто выдает интересные результаты так что не надо удивляться. Там полно глюков
11 Garkin
 
01.02.10
18:40
(5) Поправь если ошибаюсь.

Соединение наборов данных СКД делает на стороне клиента, причем сначала вытягиваются наборы данных, соединяются, а только потом накладываются отборы.
Это не странность, это особенность.
12 Garkin
 
01.02.10
18:46
+(11) Использовать наборы данных в СКД имеет смысл только в трех случаях:

1) При построении иерархии
2) При необходимости хитро считать итоги по группам.
3) Третьего к сожалению еще не знаю.

У тебя какой? Зачем тебе 2 набора?
13 Garkin
 
01.02.10
18:48
+(12) Вру, третий тоже знаю.
14 AquaKosh
 
01.02.10
18:48
(11) Не-не, дело скорее всего не в этом... В реальном отчёте отбор накладывался на виртуальную таблицу регистра и была такая же фигня...

(12) Надо хитро итоги по группа считать.
15 Garkin
 
01.02.10
18:51
(14) Как ты умудряешься указать  СКД на какой набор ты отбор накладываешь?
16 AquaKosh
 
01.02.10
18:53
(15) Опа! ... Хм... Что-то меня настораживает этот вопрос! :)
См. файлик (банальный отбор в {} в конкретном наборе данных).
17 IronDemon
 
01.02.10
19:10
Соединение набором в СКД от лукавого. Используйте связи в обычном запросе.  :)
18 Defender aka LINN
 
01.02.10
19:10
Месеье знаком с идеей левого соединения?
19 Defender aka LINN
 
01.02.10
19:11
(17) Итоги будешь вручную поправлять, когда в наборах строки дублируются? :)
20 Garkin
 
01.02.10
19:13
(16) отбор то банальный, но только непонятно из каких соображений ты делаешь вывод что он должен действовать только на один набор а не на все соединение?
21 AquaKosh
 
01.02.10
22:13
(20) Делаю вывод из здравого смысла, т.к. указываю отбор только в одном из наборов и имя отбора задаю уникальное.

Коллеги, напоминаю, что отбор, указанный вручную в запросе через параметр, к примеру Запрос.Номенклатура = "Блин", отрабатывает правильно, т.е. план по нулям и факт выводится, а такой же отбор, заданный через компоновку приводит к пустой таблице, чего быть по идее не должно.
22 AquaKosh
 
01.02.10
22:21
(20) +(21) По поводу того, что якобы установленный отбор каким-то образом накладывается на другой набор данных: если-бы это было так, то задав отбор как НЕ_РАВНО я бы увидел результат, а получается, что хоть РАВНО, хоть НЕ_РАВНО - без разницы.
23 Garkin
 
01.02.10
23:35
(21) Добавь в набор данных "План"  поле "ЛицоСотавившееПлан" и расскажи как сделать отбор в целом по соединению.