Для чего нужны запросы в 1С и как их применять

Запрос в 1С — это основной способ получить данные из информационной базы: документы за период, остатки по складам, список контрагентов с задолженностью, обороты по счетам. Практически любой отчёт, печатная форма, обработка или проверка в конфигурации внутри использует запрос. Без понимания того, как они устроены, невозможно ни разрабатывать в 1С, ни грамотно читать чужой код.

Язык запросов 1С внешне похож на SQL, но работает не с физическими таблицами базы, а с объектами метаданных: справочниками, документами, регистрами накопления и сведений. Это значит, что разработчик оперирует понятиями предметной области — «РеализацияТоваровУслуг», «ОстаткиТоваров» — а платформа сама преобразует запрос в команды для СУБД. Такой подход делает код переносимым между разными базами данных и защищает от прямого доступа к таблицам в обход логики платформы.

Пользователи сталкиваются с запросами даже не подозревая об этом: любой отчёт на СКД (системе компоновки данных), динамический список, подбор товаров в документе — всё это запросы, сформированные разработчиком или автоматически. Понимание их назначения помогает и администраторам: когда отчёт «тормозит» или выдаёт не те цифры, причина почти всегда в тексте запроса или в параметрах его выполнения.

Что такое запрос в 1С и как он устроен

Запрос состоит из текста на встроенном языке запросов и объекта Запрос, который этот текст выполняет. Минимальная структура текста: секция ВЫБРАТЬ (какие поля нужны), секция ИЗ (откуда брать данные) и необязательные секции ГДЕ, СГРУППИРОВАТЬ ПО, УПОРЯДОЧИТЬ ПО, ИТОГИ ПО. Платформа компилирует этот текст и передаёт СУБД уже готовый SQL.

Важная особенность — виртуальные таблицы. Кроме физических таблиц документов и справочников, у регистров есть виртуальные таблицы: Остатки, Обороты, ОстаткиИОбороты, СрезПоследних, СрезПервых. Они рассчитываются платформой на лету и позволяют одной строкой получить, например, остатки товаров на дату — без ручного суммирования движений.

Результат выполнения запроса — это не сразу таблица, а объект РезультатЗапроса. Из него данные получают двумя способами: методом Выбрать() — для построчного обхода в цикле, или Выгрузить() — для получения таблицы значений целиком. Выбор зависит от задачи: для обхода с иерархией и итогами удобна выборка, для передачи в табличное поле или дальнейшей обработки — таблица значений.

Основные задачи, которые решают запросы

Первая и самая массовая задача — отчётность. Любой отчёт по продажам, остаткам, взаиморасчётам или зарплате строится на запросе: выбираются данные за период, фильтруются по организации или складу, группируются по нужным измерениям. В отчётах на СКД запрос лежит в основе набора данных, а пользовательские настройки отбора и группировки платформа добавляет к нему автоматически.

Вторая группа задач — обработки и сервисные операции. Массовое изменение реквизитов, поиск дублей контрагентов, свёртка базы, загрузка данных из файла с сопоставлением по существующим элементам — везде сначала запросом выбирается нужное подмножество данных, а затем оно обрабатывается в цикле. Правильно составленный запрос здесь критичен: выбрать лишнее — значит рисковать изменить не те объекты.

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

Отдельно стоит упомянуть динамические списки и подборы. Список документов с отбором по статусу, подбор номенклатуры с остатками и ценами, история взаимодействий с клиентом — всё это запросы, которые платформа выполняет при каждом обновлении списка.

Где писать и отлаживать запросы

Основной инструмент разработчика — конструктор запроса в конфигураторе. Он открывается из модуля при работе с текстом запроса и позволяет собрать выборку мышью: выбрать таблицы, поля, условия, соединения, группировки. Для начинающих это самый безопасный путь: конструктор не даст сослаться на несуществующее поле и сам пропишет правильные имена таблиц.

Для отладки на реальных данных используют консоль запросов — обработку, которая выполняет текст запроса в пользовательском режиме и показывает результат. Это незаменимо, когда нужно проверить, что вернёт запрос до того, как вставлять его в код: видны и сами данные, и количество строк, и время выполнения. Консоль запросов входит во многие типовые инструменты разработчика и легко добавляется в любую базу.

Ещё один практический приём — временный вывод результата через Выгрузить() в таблицу значений и её просмотр в отладчике. Так проверяют запросы, которые выполняются внутри проведения документа или регламентного задания, где интерактивная консоль недоступна.

1. 1
   Откройте модуль и в месте, где нужен запрос, создайте объект: Запрос = Новый Запрос
2. 2
   Правой кнопкой по тексту — вызовите конструктор запроса
3. 3
   Выберите таблицу (например, РегистрНакопления.ТоварыНаСкладах.Остатки) и нужные поля
4. 4
   Добавьте условия через параметры (&Склад, &Дата), не вставляйте значения в текст напрямую
5. 5
   Вставьте текст в консоль запросов, задайте параметры и выполните — проверьте результат
6. 6
   Перенесите проверенный текст в код и обработайте результат через Выбрать() или Выгрузить()

Параметры, соединения и временные таблицы

Параметры запроса обозначаются символом & и заполняются методом УстановитьПараметр() до выполнения. Использовать параметры нужно всегда вместо подстановки значений конкатенацией строк: это защищает от ошибок с типами (особенно с датами и ссылками) и позволяет платформе кэшировать план запроса. Отдельный частый приём — передача в параметр массива или списка значений для условия В (&Список).

Соединения таблиц (ЛЕВОЕ СОЕДИНЕНИЕ, ВНУТРЕННЕЕ СОЕДИНЕНИЕ) применяют, когда данные лежат в разных источниках: документы и их статусы, номенклатура и остатки, контрагенты и задолженность. Левое соединение сохраняет все строки левой таблицы, подставляя NULL там, где пары не нашлось, — это стандартный способ показать «все товары, включая те, которых нет на складе». Внутреннее соединение оставляет только совпавшие пары.

Пакетные запросы и временные таблицы нужны для сложных выборок. Промежуточный результат помещается во временную таблицу конструкцией ПОМЕСТИТЬ ИмяТаблицы, а следующие запросы пакета используют её как обычный источник. Это читаемее и часто быстрее, чем один гигантский запрос с вложенными подзапросами. Временные таблицы живут в менеджере временных таблиц и уничтожаются после выполнения пакета или явно командой УНИЧТОЖИТЬ.

Производительность: почему запрос работает медленно

Самая частая причина медленного запроса — обход большой таблицы без использования индексов. Условия по неиндексированным реквизитам, функции над полями в условиях (например, ПОДСТРОКА(Наименование, 1, 5) = "Товар"), соединения по вычисляемым выражениям — всё это заставляет СУБД читать таблицу целиком. На больших базах такой запрос может выполняться минутами вместо секунд.

Вторая типичная проблема — запросы в цикле. Код вида «для каждой строки табличной части выполнить запрос» на документе в тысячу строк даёт тысячу обращений к базе. Правильный подход — один запрос с условием по списку значений или соединением с временной таблицей, а затем обход уже готового результата. Это одно из самых эффективных улучшений, которое можно внести в чужой медленный код.

Третий фактор — лишние данные. Выборка всех полей документа, когда нужны три, соединение с таблицей, из которой не берётся ни одного поля, получение данных без ограничения периода — всё это увеличивает и время выполнения, и объём передаваемых данных. Диагностировать проблемы помогает технологический журнал с замером длительных запросов и план выполнения на стороне СУБД.

Безопасность и границы самостоятельной работы

Сам по себе запрос данные не изменяет — он только читает. Риск появляется там, где результат запроса используется в обработке, которая изменяет или удаляет объекты. Ошибка в условии отбора (например, забытый параметр организации) приведёт к тому, что обработка затронет чужие данные. Поэтому любую обработку, меняющую данные по результатам запроса, сначала запускают в режиме «только показать, что будет изменено» и обязательно на копии базы.

Вторая граница — права доступа. Запрос в привилегированном модуле видит данные независимо от прав пользователя, и если его результат выводится в отчёт, можно случайно показать сотруднику то, что ему не положено: зарплату коллег, себестоимость, чужие заказы. Перед публикацией отчёта проверьте, в каком режиме он выполняется и какие данные попадают в выборку.

Третий момент — прямой доступ к базе средствами SQL в обход платформы. Чтение через SQL ещё допустимо для аналитики, но любая запись напрямую в таблицы нарушает целостность данных: итоги регистров, последовательности, служебные поля. Такие действия выполняют только специалисты, понимающие структуру конкретной конфигурации, и только после резервного копирования.

Как проверить, что запрос возвращает правильные данные

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

Второй приём — проверка на граничных случаях: пустой период, отсутствие данных по отбору, одиночная запись, дублирующиеся строки в соединяемой таблице. Запрос, который «работает на нормальных данных», часто ломается именно на таких ситуациях: теряет строки при внутреннем соединении или задваивает суммы при дублях.

Третий шаг — контроль количества строк и итоговых сумм до и после группировки. Если после добавления соединения число строк выросло, а суммы увеличились кратно — это классический признак декартова размножения строк из-за неполного условия связи.

Контрольные точки

Как проверить результат запроса

Итоговые суммы

Норма

Совпадают со штатным отчётом по тем же отборам

Тревожный признак

Суммы завышены кратно — дубли при соединении

Количество строк

Норма

Соответствует ожидаемому числу объектов

Тревожный признак

Строк резко больше после добавления соединения

Граничные случаи

Норма

Пустой отбор даёт пустой результат без ошибок

Тревожный признак

Запрос падает или возвращает лишнее при пустых параметрах

Время выполнения

Норма

Секунды на типовом объёме данных

Тревожный признак

Минуты — проверьте условия и параметры виртуальных таблиц

Частые вопросы

Чем запрос в 1С отличается от SQL-запроса к базе?

Запрос 1С работает с объектами метаданных — справочниками, документами, регистрами — и платформа сама переводит его в SQL конкретной СУБД. Поэтому один и тот же запрос работает на разных базах без изменений, а разработчик не обязан знать физическую структуру таблиц. Прямой SQL даёт больше свободы, но привязывает к конкретной СУБД и обходит механизмы платформы.

Можно ли изменять данные запросом?

Нет, язык запросов 1С предназначен только для чтения. Изменение выполняется объектным способом: запрос выбирает нужные ссылки, затем в цикле каждый объект получается методом ПолучитьОбъект(), изменяется и записывается. Это дольше, чем SQL UPDATE, но гарантирует срабатывание всех проверок и обработчиков платформы.

Что выбрать: Выбрать() или Выгрузить()?

Выбрать() подходит для построчного обхода, работы с иерархией и обхода по группировкам с итогами — при этом не требуется держать весь результат в памяти. Выгрузить() возвращает таблицу значений, которую удобно сортировать, искать, сворачивать и передавать на форму. Для небольших результатов разница несущественна, для больших выборок предпочтительнее обход выборкой.

Почему отчёт на СКД выдаёт другие цифры, чем мой запрос в консоли?

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

Нужно ли учить язык запросов бухгалтеру или менеджеру?

Полноценно — нет. Пользователю достаточно уметь настраивать отборы и группировки в отчётах на СКД: платформа сама модифицирует запрос. Знание языка запросов требуется разработчикам, внедренцам и администраторам, которые создают отчёты, обработки и разбираются в причинах неверных данных.

Как понять, что медленный отчёт тормозит именно из-за запроса?

Выполните текст запроса из схемы компоновки в консоли запросов с теми же параметрами и замерьте время. Если в консоли запрос тоже выполняется долго — проблема в самом запросе: отборах, соединениях, параметрах виртуальных таблиц. Если в консоли быстро, а отчёт медленный — причина в настройках СКД, выводе большого объёма данных или постобработке.