задачка.
есть оборотный регистр. допустим Регистр.Заказы
Измерения: Заказ-Номенклатура
есть ресурс План (сколько клиент заказал шт)
есть ресурс Факт (сколько склад собрал шт)
есть движения которые по (заказ,номенклатура) двигают отдельно ПЛАН (в плюс)
есть движения который по (заказ,номенклатура) двигают отдельно ФАКТ (пусть тоже в плюс)
.
задача - получить в результате выполнения запроса ТЗ вида
Заказ-Номенклатура-НеВыполнено, где
НеВыполнено (План-Факт) > 0
.
или на крайняк кортежи типа
Заказ-Номенклатура-(План-Факт)-НадоУдалить, где НадоУдалить=1 Когда (План-Факт)<=0

.
Получится ли такое сделать чорным запросом?

Максимум чего добился В ЗАПРОСЕ получение кортежей
(Заказ,Номенклатура,(План-Факт),НадоУдалить) где НадоУдалить=1 только если (План-Факт)=0

Улучшил
Максимум чего добился В ЗАПРОСЕ получение кортежей
(Заказ,Номенклатура,(План-Факт),НадоУдалить) где НадоУдалить=1 если (План-Факт)<=0
/
но вот исключить такие строки чтобы не выдавались как результат запроса - пока никак...

|Период с ДатаН;
    |Без итогов;
    |
    |Заказ = Регистр.Заказы.Заказ;
    |Номенклатура = Регистр.Заказы.Номенклатура;
    |
    |План = Регистр.Заказы.Заказано;
    |Факт = Регистр.Заказы.Отобрано;
    |
    |Функция КоличествоПлан = Сумма(План);
    |Функция КоличествоФакт = Сумма(Факт);
    |Функция КоличествоНаОтбор = Сумма(План-Факт);
    |Функция НадоУдалить = Сумма(1) Когда ((Запрос.КоличествоНаОтбор<=0));
    |
    |Группировка Заказ Без Упорядочивания;
    |Группировка Номенклатура Без Упорядочивания Без Групп;
    |";
Запрос.Выгрузить(ТЗ,1,0);

Разве ещё не все клюшечники перешли на прямые запросы?

(4) ну. у кого объемы больше - те перешли. или терпят.
у меня объемы на таких проектах - несущественные, регистры укладываются в отведенные 16 млн записй даже в ДБФ за несколько лет. Поэтому осовил мало-мало самые простейшие...

(4) а там где на складах большие объемы - там я не программлю, там я в других ипостасях проекты делаю ;-)

И все эти клюшки сейчас больше на Хобби похоже у меня ;-)

В итоге - по существу сабжа кто-нить прокомментиует, или клюшечников не осталось вменяемых?

чорные запросы -зло

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

|Условие(Запрос.КоличествоПлан-Запрос.КоличествоФакт>0);

но.. тебе нужен примитивный select + group by + having ....это в разы проще и быстрее

И Чебур, кто у тебя аккаунт угнал ? Перелогинься

(11) Не злобствуй!

(10) была у меня такая мысль, но не дошел до нее окончательно (ранее использовал подобное).
"select + group by + having ....это в разы проще и быстрее" - это для полиглотов.. а я консерваториев не кончал ;-) это уже позжее если бюджеты будут - тогда оптимизировать, сейчас надо функциональность требуемую обеспечить...
.
Спасибо.

так все равно же перебором запрос выводить, там и удалить можно

(14) куда выводит? зачем выводить? никуда не выводить не планируется..
хочется получить таблицу максимально очищенную от "лишних" данных. а потом эту таблицу куртить/фильтровать/сортировать, но обработкой одиночных записей уже не заниматься - так тупо удобнее, иначе в куче мест придется костылей ставить н апропуск ненужных строк, на проверку а есть ли в подмножестве таблицы ненужные строки и прочее.

(15) "куртить" (и гансить) удобнее ИндексированнойТаблицей. Там же есть и фильтры, и группировки..
Ну есть же удобные инструменты - зачем пользоваться заведомо неудобными? "чтоб служба медом не казалась?"
просто надо принять как данность, что 1с++ и Формекс - это "джентльменский набор клюшечника", и пользоваться.

(16) Убедил! сегодня вечером часть перепишу на ИТЗ. а то выдершгивать из плоской таблицу частную, обрабатывать ее, а потом из нее сливать скорректированные данные обратно в большую - затрахался уже

(17) ну или родить запрос человеческий..

(18) ниасилил. если бы один запрос человеческий - то еще с помощью спецов получилось бы. А так - приведенный - всего лишь один из... там еще куча других таблиз с итогом по этому запросу скрещивается и обрабатывается. По уму как я вижу там процентов 50% кода надо запрсоами делать, но я ж не могу всю работу на когото переложить. да еще и забесплатно ;-)

(10) кстати, неа...
в таком виде
|Условие((Запрос.КоличествоПлан-Запрос.КоличествоФакт)>0);
.
запрос из (3) вообще неверные дает вообще. Количество план - норм, а количествоФакт вообще нулевое получается и итог кривой.
потому видать что
запрос.КоличествоФакт примеяется к отбираемым записям, а План и Факт - отдельные записи по регистру и в каждой записи КоличествоПлан получается = 0... и условие отсеивает все фактовые записи

(19) ну сделайте регистр остатков. У него всё это на уровне платформы вшито, надо удалить, не надо удалить, он всё делает сам. Как-то получается, что вы через задний проход пытаетесь вытащить остаток из оборотного регистра.

(21) пофиг. можно сделать на регистре остатков. Но кроме Остатка (План-Факт) мне нужен Оборот ПЛАН - и как предлагаешь тянуть его их регистра остатков - да, Приход и Расход - но в оборотном регистре это хоть как-то оптимизировано...

(21) на самом деле не суть важно пока, объемы небольшие

(16) нет, не удобнее.
Первый же "глюк", с которым столкнулся (знал-забыл), но вспомнил походу...
ИТЗ.ЗагрузитьЗапрос(Запрос,1,0).
При разработке и отладке много и часто пользуюсь Универсальной печатью ТЗ,
ПечататьИТЗ оно не умеет, это понятно, сделал обертку, если на вход ПечатьТЗ(ИТЗ) - тогда ИТЗ перегружаю в ТХ и вызываю уже ПечатьТЗ(ТЗ). Только незадачка... в ТЗ все выгружается нетипизированными колонками. И все процедуры и прочие феньки, которые можно делать опираясь на типизированность колонок - идут в топку, в данном случае - автосуммирование колонок ТЗ по числовым колонкам... и все.. ахеренное удобство накрылось медным тазиком.
.

как теперь выводить отладку? писать быдлокод типа если ИмяКолонки = "ЧтоТо" тогда считать что тип колонки число?

фича в (24) сразу напрочь убивает скорость контроля/отладки при тестировании.
.
есть что-то аналогичное универсальной ПечатьТЗ(ТЗ), чтобы печатать ИТЗ не заморачиваясь частностями конкретной ИТЗ?

Блин, и всего-то надо было что для начала в ИТЗ: Группировать и все...
Теперь проще от ИТЗ отказаться на этапе разработки и тестирования, нарисовать собственную группировку ТЗ (пострадав в скорости выполнения, но благо это не в миллионном цикле) и пролоджать работать на ТЗ отлаживаясь и тестируясь. а на ИТЗ переходить после запуска в продакшн, когда все отлажено будет...

..Или я чего-то не знаю хитростей ИТЗ?

даже рисовать не надо собственную группировку - уже все написано до нас...

Попутно обнаружил такую штучку занятную
Допустим,есть строка сортировки ТЗ, типа

СтрокаСортировки = "Контрагент-,Направление+,Маршрут*"
если по этой строке сделать свертку ТЗ.Свернуть(СтрокаСортировки,) - то знаки сортировки + и - - никак не мешают свертке, а вот зна к * - в итоговй ТЗ соответсвующей колонки не будет...

(27) Лучше один раз разобраться, чем лепить      медленные решения на обычной ТЗ.
В ИТЗ - там всё просто как грабли.

(31) я в курсе и согласен. но нетипизированность ИТЗ - мешает (пока)

(19) "лучше день потерять - а потом за час долететь"©

(26) валялось где-то - печать сгруппированной ИТЗ (ну, чт-то типа дерева). поможет?

И..был еще Класс.ИтогиПоГруппировкам от А.Диркса

(34) а то! конечно, пригодится.

(31) ага, как же.. в ТЗ все просто как грабли. если что-то "не работает" - значит тупо "не работает" и все понятно, - ищется на раз.
в ИТЗ - хз... пока не наблатыкаешься... то там надо индекс указать, то здесь, то отсортировал, при обходе нломается потому что "количество" меняшь, которое оказывается индекс входит когда раньше сортировал.

и ТЗ.сортировать(<Колонки>,<ДокумПоДате>)
как в ИТЗ сделать чтобы доки по Хронологии сортировались, как в типовой ТЗ?

(38) ну создай колонку с моментом документа.

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

в чорных запросах вроде веачале все выберем, а затем наложим фильтр

(31) Убедил, делаю сейчас, используя ИТЗ по некоторым моментам

(40) да, строится дбф-ка по всем полям запроса, вытягивается на клиента, и уже там фильтруется - вычисляется.

(43) как-то совсем нехорошо... а почему условия на "сервере" не могут считаться?
навскидку и не вспомню .. - это только если условия могут применяться к уже сгруппированным/сконсолидированным числовым данным - а такое в условиях запроса может быть?

Условие из (2) - например, вообще нифига правильно не считается, не применяется к "сгруппированным/просуммированным" числам на уровне группировок...

поправка - .."условие из (20).."

(44) так создал БоГ (БОрис Георгиевич) :-)
Видимо, консистентности ради. Ну и  вообще, выбирать из дбф... я по заветам ВилдХаре вроде начинал разбираться, но сразу плюнул и перелез на прямые.. прикинь, вот совсем черных не знаю, кроме того, что конструктором построить можно.

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