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

Код:

"ВЫБРАТЬ
СправочникНоменклатура.Код,
СУММА(ЕСТЬNULL(ТоварыВРозницеОстатки.КоличествоОстаток, 0)) КАК ОстатокРозница,
СУММА(ЕСТЬNULL(ТоварыНаСкладахОстатки.КоличествоОстаток, 0)) КАК ОстатокОпт,
СУММА(ЕСТЬNULL(ТоварыНаСкладахОстатки.КоличествоОстаток, 0) + ЕСТЬNULL(ТоварыВРозницеОстатки.КоличествоОстаток, 0)) КАК ОстатокОбщий
ИЗ
Справочник.Номенклатура КАК СправочникНоменклатура
ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.ТоварыНаСкладах.Остатки КАК ТоварыНаСкладахОстатки
ПО СправочникНоменклатура.Ссылка = ТоварыНаСкладахОстатки.Номенклатура
ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.ТоварыВРознице.Остатки КАК ТоварыВРозницеОстатки
ПО СправочникНоменклатура.Ссылка = ТоварыВРозницеОстатки.Номенклатура
</span>
СГРУППИРОВАТЬ ПО
СправочникНоменклатура.Код"
</FONT></FONT></pre>

Ну можно я думаю и без группировки:

Код:

"ВЫБРАТЬ
СправочникНоменклатура.Код,
ЕСТЬNULL(ТоварыВРозницеОстатки.КоличествоОстаток, 0) КАК ОстатокРозница,
ЕСТЬNULL(ТоварыНаСкладахОстатки.КоличествоОстаток, 0) КАК ОстатокОпт,
ЕСТЬNULL(ТоварыНаСкладахОстатки.КоличествоОстаток, 0) + ЕСТЬNULL(ТоварыВРозницеОстатки.КоличествоОстаток, 0) КАК ОстатокОбщий
ИЗ
Справочник.Номенклатура КАК СправочникНоменклатура
ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.ТоварыНаСкладах.Остатки КАК ТоварыНаСкладахОстатки
ПО СправочникНоменклатура.Ссылка = ТоварыНаСкладахОстатки.Номенклатура
ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.ТоварыВРознице.Остатки КАК ТоварыВРозницеОстатки
ПО СправочникНоменклатура.Ссылка = ТоварыВРозницеОстатки.Номенклатура"

Так тоже должно работать..

Здраствуйте!
Совет: не захламляйте запросы лишними вычислениями, а просто изучите существующие регистры перед формированием запроса.

Код:

ВЫБРАТЬ
НоменклатураСписка.Код,
НоменклатураСписка.Наименование,
ТоварыВРозницеОстатки.КоличествоОстаток КАК ОстатокРозница,
ТоварыНаСкладахОстатки.КоличествоОстаток КАК ОстатокОпт,
ТоварыОрганизацийОстатки.КоличествоОстаток КАК ОбщийОстаток
ИЗ
Справочник.Номенклатура КАК НоменклатураСписка
ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.ТоварыВРознице.Остатки КАК ТоварыВРозницеОстатки
ПО НоменклатураСписка.Ссылка = ТоварыВРозницеОстатки.Номенклатура
ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.ТоварыНаСкладах.Остатки КАК ТоварыНаСкладахОстатки
ПО НоменклатураСписка.Ссылка = ТоварыНаСкладахОстатки.Номенклатура
ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.ТоварыОрганизаций.Остатки КАК ТоварыОрганизацийОстатки
ПО НоменклатураСписка.Ссылка = ТоварыОрганизацийОстатки.Номенклатура

ЕСТЬNULL в таком запросе ОБЯЗАТЕЛЕН!
Ибо соединение ВСЕГДА может породить NULL

Разве! NULL нас интерисует если мы собираемся что-либо вычислять, а нам то вычислять ничего не надо. Мы собираем остатки на оптовых и розничных складах, а потом просто выводим остаток организации, ни одного вычисления мы не выполняем, и нам все-равно бараны или бублики там, т.к. там либо остаток, либо ничего.

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

Может быть, но я не считаю это правилом хорошего тона по одной причине, это снижает производительность, что является одним из главных аспектов при оценке программного обеспечения Производительность<->Надежность. Когда обработка результатов запроса продолжается в выборке, да, тогда у нас просто выхода нет, а в нашем случае это нецелесообразно. Всё это ИМХО, если есть конкретное мнение почему лучше писать нули в запросах при отсутствии значений, прошу поделиться, т.к. меня этот вопрос сильно интересует, но весь вопрос при снижении производительности хотя бы на толику рабочего времени машины сводится к актуальности выполняемой операции.

Поясню мысль. Если брать данный конкретный пример, то да, соглашусь в нем нет необходимость в конструкции ЕСТЬNULL, поскольку с большой долей вероятности мы можем предположить что запрос пишется для одного вполне конкретного отчета без обработки результатов и больше нигде использоваться не будет (хотя с другой стороны - разницу в производительности с и без конструкции ЕСТЬNULL на данном конкретном запросе мы тоже думаю не увидим).
Если же мы возьмем общий случай, то представим запрос, который пишется изначально для конкретной определенной цели. Мы знаем, где он у нас используется, и предполагаем что проверка ЕСТЬNULL нам не нужна. Со временем мы можем захотеть результаты этого запроса использовать в других целях (сам запрос к тому времени может вообще затерятся где-то в модулях) - и вот здесь, мы можем уже не вспомнить, что когда-то пренебрегли данной проверкой. Второй вариант: у нас есть функция (с запросом) которая возвращает данные. Мы то знаем что у нас там нет соответствующей проверки, но вот допустим кто-то третий, захотя использовать эту функцию и оринтируясь только лишь на описание - может получить неожиданные для себя результаты (согласитесь не каждый полезет в дебри неизвестной функции разгребать ее логику и запросы, и контролировать проверки).
Примеры так, можно конечно сказать надуманные, первое что пришло в голову, но тем не менее получается что лучше сделать один раз и забыть, чтобы потом ни самому, ни кому-то третьему не пришлось заново анализировать код и искать ошибки.

Странно, вообще-то все конфигурации в основном пишутся по правилам, обратным от ваших :unsure:
Изучите результат деликатного запроса выборки остатков номенклатуры справочника "Номенклатура", всё с точностью наоборот
Посмотреть вложение 4267
Ладно, тему считаю закрытой.

Принял к сведению, но остался при своем мнении. :smile:
Я бы все-таки проверил, привычка. Несмотря на производительность. Проверил бы и в запросе, и если данные допустим передаются в какую-то внешнюю функцию, то и в ней бы результат проверил еще раз. (не шучу).

Да, немного отклонились.

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

В данном случае важна надежность, т.е. гарантированный резульат.
Производительность от использования ЕСТЬNULL мало отличается (воспользуйтесь стандартным замером 1С или посмотрите в профайлере)

Далее, при выводе в отчет, например, если пользователь захочет использовать какую-либо группировку, отличной от предложенной - результат непредсказуем, ибо с NULL бесполезно что-то делать.

Общий вывод: использовать обязательно, ибо малейший шаг в сторону от первоначальной идеи вызывает потребность полностью переписать текст, т.к. результат будет неизвестен.
Например, в отчете по остаткам можем запросто получить NULL, если сложем NULL и 5, например.