Несколько полезных методов в составлении запросов, которые вы захотите использовать

11.09.25

Разработка - Запросы

Предлагаю рассмотреть несколько полезных методов в использовании запросов. Все исключительно из моей практики.

Введение

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

В этом году столкнулись с тем, что многие компании все-таки решились на переход со своих старых версий программ 1с на современные. За основную конфигурацию для данной статьи я возьму 1С:Управление торговлей 11.5 (11.5.22.92 длительной поддержки) на 1С:Платформе 8.3.27.1688 - самой последней на начало осени 2025. Также, в описании, я затрону использование некоторых штатных составляющих Библиотеки стандартных подсистем.

Итак, переходим к описанию.

 

Причины написания материалы - клиенты, их базы и методы ведения учета в них

Понимая, что мы являемся официальным франчайзингом 1с, большинство клиентов приходят к нам с готовностью работать на длительную перспективу и уверенностью, что их задача будет решена. Все наши заказчики рассчитывают на индивидуальный подход к решению их задачи.

 

Что я вижу в "старых" базах клиентов? Не могу сказать, что совсем уж плохо все - базы разные, уровень ведения учета в базах так же разный - от "ведения на коленке" до "запредельно усложненного учета с кучей ненужных действий". Но я не видел ни одной базы, где бы учет шел без ошибок - одни исполнители поработали "так", другие - "сяк", в результате получаем то, что получаем.

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

 

Отмечу, что последнее время, мне очень понравилась конфигурация 1С:Управление торговлей 11.5 своей универсальностью, гибкостью настройки, стабильностью в работе. Считаю, что при умелом подходе ее можно настроить так, что она будет проще старой 10-ки. Поэтому, для перехода на что-то "новое" я выбираю последнее время только ее.

 

К чему я написал этот абзац? Да к тому, что в основном заказчик считает, что все необходимые данные для перехода в старой базе у него есть, не обращая внимание на технические тонкости работы программы, либо вообще отсутствие корректного подхода к работе в "старой" программе.

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

 

Использование ключей-фильтров для получения необходимых данных

В данной ситуации я имею старую УТ 11, в которой нет регистрации закупочных цен. Все закупочные цены можно "отловить" только документам. Мной было принято решению создать "виртуальный срез" последних закупочных цен по документам поступления от поставщиков. Сделал я это единым запросом, без использования циклов конечно.

Общий запрос выглядит вот так:

 
 Использование "фильров-ключей" в запросе для получения среза закупочных цен 

 

ВЫБРАТЬ
	НАЧАЛОПЕРИОДА(ПриобретениеТоваровУслуг.Дата, ДЕНЬ) КАК Дата,
	ПриобретениеТоваровУслуг.Контрагент КАК Контрагент,
	ПриобретениеТоваровУслугТовары.Номенклатура КАК Номенклатура,
	ПриобретениеТоваровУслугТовары.Цена КАК Цена
ПОМЕСТИТЬ ВТ_ВесьЗакупДолго
ИЗ
	Документ.ПриобретениеТоваровУслуг КАК ПриобретениеТоваровУслуг
		ВНУТРЕННЕЕ СОЕДИНЕНИЕ Документ.ПриобретениеТоваровУслуг.Товары КАК ПриобретениеТоваровУслугТовары
		ПО ПриобретениеТоваровУслуг.Ссылка = ПриобретениеТоваровУслугТовары.Ссылка
ГДЕ
	ПриобретениеТоваровУслуг.Дата <= &ДатаТек
	И ПриобретениеТоваровУслуг.Проведен = ИСТИНА
	И ПриобретениеТоваровУслуг.Организация = &Организация

СГРУППИРОВАТЬ ПО
	ПриобретениеТоваровУслуг.Дата,
	ПриобретениеТоваровУслуг.Контрагент,
	ПриобретениеТоваровУслугТовары.Номенклатура,
	ПриобретениеТоваровУслугТовары.Цена

ИНДЕКСИРОВАТЬ ПО
	Контрагент,
	Номенклатура,
	Дата
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
	МАКСИМУМ(ВТ_ВесьЗакупДолго.Дата) КАК Дата,
	ВТ_ВесьЗакупДолго.Номенклатура КАК Номенклатура,
	ВТ_ВесьЗакупДолго.Контрагент КАК Контрагент
ПОМЕСТИТЬ ВТ_ПакетФильтра
ИЗ
	ВТ_ВесьЗакупДолго КАК ВТ_ВесьЗакупДолго

СГРУППИРОВАТЬ ПО
	ВТ_ВесьЗакупДолго.Номенклатура,
	ВТ_ВесьЗакупДолго.Контрагент
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
	ВТ_ПакетФильтра.Дата КАК Дата,
	ВТ_ПакетФильтра.Номенклатура КАК Номенклатура,
	ВТ_ПакетФильтра.Контрагент КАК Контрагент,
	ВТ_ВесьЗакупДолго.Цена КАК ПоследнийЗакупЦена
ИЗ
	ВТ_ПакетФильтра КАК ВТ_ПакетФильтра
		ВНУТРЕННЕЕ СОЕДИНЕНИЕ ВТ_ВесьЗакупДолго КАК ВТ_ВесьЗакупДолго
		ПО ВТ_ПакетФильтра.Дата = ВТ_ВесьЗакупДолго.Дата
			И ВТ_ПакетФильтра.Номенклатура = ВТ_ВесьЗакупДолго.Номенклатура
			И ВТ_ПакетФильтра.Контрагент = ВТ_ВесьЗакупДолго.Контрагент

СГРУППИРОВАТЬ ПО
	ВТ_ПакетФильтра.Дата,
	ВТ_ПакетФильтра.Номенклатура,
	ВТ_ПакетФильтра.Контрагент,
	ВТ_ВесьЗакупДолго.Цена

УПОРЯДОЧИТЬ ПО
	Номенклатура

 

Код 1. Общий запрос по получению среза последних закупочных цен.

 

Сделаю небольшое описание:

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

 
 Выборка строк по документам поступления

 

ВЫБРАТЬ
	НАЧАЛОПЕРИОДА(ПриобретениеТоваровУслуг.Дата, ДЕНЬ) КАК Дата,
	ПриобретениеТоваровУслуг.Контрагент КАК Контрагент,
	ПриобретениеТоваровУслугТовары.Номенклатура КАК Номенклатура,
	ПриобретениеТоваровУслугТовары.Цена КАК Цена
ПОМЕСТИТЬ ВТ_ВесьЗакупДолго
ИЗ
	Документ.ПриобретениеТоваровУслуг КАК ПриобретениеТоваровУслуг
		ВНУТРЕННЕЕ СОЕДИНЕНИЕ Документ.ПриобретениеТоваровУслуг.Товары КАК ПриобретениеТоваровУслугТовары
		ПО ПриобретениеТоваровУслуг.Ссылка = ПриобретениеТоваровУслугТовары.Ссылка
ГДЕ
	ПриобретениеТоваровУслуг.Дата <= &ДатаТек
	И ПриобретениеТоваровУслуг.Проведен = ИСТИНА
	И ПриобретениеТоваровУслуг.Организация = &Организация

СГРУППИРОВАТЬ ПО
	ПриобретениеТоваровУслуг.Дата,
	ПриобретениеТоваровУслуг.Контрагент,
	ПриобретениеТоваровУслугТовары.Номенклатура,
	ПриобретениеТоваровУслугТовары.Цена

ИНДЕКСИРОВАТЬ ПО
	Контрагент,
	Номенклатура,
	Дата
;

 

Код 2. Формирование запроса на основе общей таблицы (может работать долго).

 

Далее, я создаю некий запрос - фильтр по требуемым мной ключам,  где намеренно выбираю измерения фильтрации (отбора):

 
 Запрос - фильтр-ключ по выбранным измерениям


 

ВЫБРАТЬ
    МАКСИМУМ(ВТ_ВесьЗакупДолго.Дата) КАК Дата,
    ВТ_ВесьЗакупДолго.Номенклатура КАК Номенклатура,
    ВТ_ВесьЗакупДолго.Контрагент КАК Контрагент
ПОМЕСТИТЬ ВТ_ПакетФильтра
ИЗ
    ВТ_ВесьЗакупДолго КАК ВТ_ВесьЗакупДолго

СГРУППИРОВАТЬ ПО
    ВТ_ВесьЗакупДолго.Номенклатура,
    ВТ_ВесьЗакупДолго.Контрагент
;

 

Код 3. Формирование запроса - фильтра на основе общей таблицы.

 

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

Рис. 1. Срез последних закупочных цен по контрагентам по документам поступления.

 

Далее, распоряжаюсь этой таблицей по своему усмотрению.

 

Использование календарей БСП для получения заданных периодов

Еще один интересный подход, который почему-то многие программисты даже с опытом не применяют и задают вопросы "а как сделать?"...

Проблема заключается в получении полного периода (по дням или месяцам) в таблицу запроса для дальнейшего использования. Мой подход такой:

Поскольку, большинство из вас работает в типовых конфигурациях или конфигурациях, которые основаны на БСП, для получения вспомогательных таблицы периодов рекомендую использовать типовые данные "производственных календарей".

Для месяцев, запрос выглядит вот так:

 
 получение периода "по месяцам"

 

ВЫБРАТЬ
	НАЧАЛОПЕРИОДА(ДанныеПроизводственногоКалендаря.Дата, месяц) КАК Дата
ИЗ
	РегистрСведений.ДанныеПроизводственногоКалендаря КАК ДанныеПроизводственногоКалендаря
ГДЕ
	ДанныеПроизводственногоКалендаря.Год = 2025

СГРУППИРОВАТЬ ПО
	НАЧАЛОПЕРИОДА(ДанныеПроизводственногоКалендаря.Дата, месяц)

УПОРЯДОЧИТЬ ПО
	Дата

 

Код 4. Формирование запроса - получение вспомогательной таблицы месяцев.

 

а для дней вот так:

 
 получение периода "по дням"

 

ВЫБРАТЬ
	НАЧАЛОПЕРИОДА(ДанныеПроизводственногоКалендаря.Дата, день) КАК Дата
ИЗ
	РегистрСведений.ДанныеПроизводственногоКалендаря КАК ДанныеПроизводственногоКалендаря
ГДЕ
	ДанныеПроизводственногоКалендаря.Год = 2025

СГРУППИРОВАТЬ ПО
	НАЧАЛОПЕРИОДА(ДанныеПроизводственногоКалендаря.Дата, день)

УПОРЯДОЧИТЬ ПО
	Дата

 

Код 5. Формирование запроса - получение вспомогательной таблицы периода по дням.

 

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

 

Заключение и выводы

В данной статье я привел два практических метода работы с запросами - использование фильтрации запросом и формирование вспомогательных таблиц необходимых периодов. Уверен, что многим будет полезны эти практики, и они будут применять эти механизмы, лежащие "на поверхности применения запросов в типовых". 

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

Собственно говоря, одними переносами мы и занимаемся последнее время - не важно, "типовая или не типовая"....

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

Ну а кто меня знает - может найти другие материалы на нашем личном тг-канале.

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

 

Другие полезные материалы автора

Из интересных публикаций могу порекомендовать ознакомиться с этими:

Простой и быстрый перенос справочника "Номенклатура" из УТ 11.4 в Розницу 2.3

Технический перенос "Номенклатуры" (с указанием новых ставок НДС) и "Контрагентов" из УТ 10.3 в УТ 11.5

Легкий и быстрый способ переноса контрагентов и партнеров разными версиями УТ 11

Взаиморасчеты с сотрудниками - начислено, удержано и выплачено для ЗУП 3.1 [Май 2025]

Начисления, НДФЛ и взносы за период для ЗУП 3.1 [Апрель 2025]

Кадровая история сотрудников с указанием ФОТ для ЗУП 3.1 [Май 2025]

Служебная выгрузка-загрузка номенклатуры, штрихкодов, остатков, видов цен из 1С:Розницы в 1С:Розницу

 

Так же, в профиле есть много интересной информации о применении торгового оборудования в рамках библиотеки подключаемого оборудования.

Вступайте в нашу телеграмм-группу Инфостарт

запрос управление торговлей запрос цен остатков библиотек стандартных подсистем лайфхаки

См. также

Инструментарий разработчика Роли и права Запросы СКД Программист Руководитель проекта 1С v8.3 Управляемые формы Запросы Система компоновки данных Платные (руб)

Инструменты для разработчиков 1С 8.3: Infostart Toolkit. Автоматизация и ускорение разработки на управляемых формах. Легкость работы с 1С.

15500 руб.

02.09.2020    212797    1159    413    

1049

Инструментарий разработчика Запросы Программист 1С v8.3 Сложные периодические расчеты Запросы 1С:Зарплата и кадры государственного учреждения 3 1С:Зарплата и Управление Персоналом 3.x Абонемент ($m)

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

1 стартмани

16.05.2025    5086    86    zup_dev    20    

67

Инструментарий разработчика Запросы Программист 1С v8.3 Управляемые формы Запросы 1С:ERP Управление предприятием 2 Абонемент ($m)

В данной публикации рассказывается о решении, которое позволяет находить сразу все ошибки в тексте запроса за раз, а не только самую первую.

2 стартмани

05.03.2025    3742    15    XilDen    12    

25

Обновление 1С Запросы Программист 1С v8.3 1С:ERP Управление предприятием 2 Абонемент ($m)

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

3 стартмани

06.02.2025    3445    26    XilDen    26    

37

Запросы Программист 1С v8.3 Запросы 1C:Бухгалтерия Бесплатно (free)

В статье приведена удобная возможность отладки исполняемого запроса динамического списка.

03.12.2024    8205    artemusII    11    

24

Запросы Программист Бесплатно (free)

Увидел cheatsheet по SQL и захотелось нарисовать подобное, но про запросы.

18.10.2024    16593    sergey279    18    

69

Запросы Программист 1С v8.3 Запросы 1C:Бухгалтерия Бесплатно (free)

Столкнулся с интересной ситуацией, которую хотел бы разобрать, ввиду её неочевидности. Речь пойдёт про использование функции запроса АВТОНОМЕРЗАПИСИ() и проблемы, которые могут возникнуть.

11.10.2024    11297    XilDen    38    

102

СКД Механизмы типовых конфигураций Запросы Программист 1С v8.3 1С:Зарплата и кадры государственного учреждения 3 1С:Зарплата и Управление Персоналом 3.x Россия Бесплатно (free)

Работая с типовыми отчетами в конфигурациях «Зарплата и управление персоналом, редакция 3», «Зарплата и кадры государственного учреждения, редакция 3» и подобных, в схемах компоновки данных можно встретить конструкции запросов, которые обращаются к некоторым виртуальным таблицам.

20.08.2024    5276    PROSTO-1C    0    

28
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. paulwist 11.09.25 08:58 Сейчас в теме
ПОМЕСТИТЬ ВТ_ВесьЗакупДолго
...
ИНДЕКСИРОВАТЬ ПО
	Контрагент,
	Номенклатура,
	Дата


Поясните плиз, зачем применено индексирование в ВТ_ВесьЗакупДолго, какая цель преследовалась??
2. aximo 2407 11.09.25 09:01 Сейчас в теме
(1) убыстрить обращение к выборке в дальнейшем. Думаете не сработает? Почему?
3. user-z99999 76 11.09.25 09:23 Сейчас в теме
(2) Порядок полей в индексе и порядок в соединении - разный.
Это плохо.
Прикрепленные файлы:
v8devops; FedorovArtem_1C; +2 Ответить
4. gzharkoj 539 11.09.25 10:06 Сейчас в теме
(3) под порядком имеется ввиду порядок без пропусков, то есть если только укажите Номенклатура в соединение индекс не задействуется, а если Номенклатура, Контрагент или Контрагент, Номенклатура, то планировщику этого достаточно, порядок соединения нужный он выстроит сам, даже сможет определить, какую таблицу выбрать ведущей при соединении в зависимости от размеров таблиц по статистике.
baranchikov; aximo; +2 Ответить
5. user-z99999 76 11.09.25 10:10 Сейчас в теме
(4) написал как нужно делать, а вы пишете, что можно переложить эту заботу на 1с.
когда перекладываете ответственность, что-то может пойти не так)

например, когда много таблиц и соединений.
8. gzharkoj 539 11.09.25 10:23 Сейчас в теме
(5) даже на ИТС написано, что указывать можете в любом порядке, главное не пропускать (если нужно ссылку приведу). Все зависит от того, в каком контексте рассматривать вопрос, если речь про производительность, то индексировать на всякий случай плохо, если таблица менее 10к записей, то не стоит индексировать, не индексировать, используя таблицу в соединении, плохо. В контексте поддержки кода лучше все явно указать, так понимаешь, что разработчик понимает. В общем - это не плохо, это не симпатично =(
pavlov_dv; +1 Ответить
9. paulwist 11.09.25 10:36 Сейчас в теме
(2)
убыстрить обращение к выборке в дальнейшем.


В дальнейшем на каких запросах?? Приведите пример.

(2)
...Думаете не сработает? Почему?


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

PS а пока построение индекса - это лишняя нагрузка на сервер :)
6. aximo 2407 11.09.25 10:11 Сейчас в теме
(4) на самом деле по индексам любят «прикопаться» всегда - четкого понимания ни у кого особо нет - когда он убыстряет, когда замедляет…

Но от себя напишу, опять такие по опыту, при сборке данных по документам, как в примере , я всегда по-умолчанию использую индексы… и, да, сборка связей происходит быстрее
baranchikov; +1 Ответить
7. qwinter 684 11.09.25 10:23 Сейчас в теме
Использование внутренних соединений в данном случае это треш... Хотя на фоне дублей записей (если в один день несколько приходников) это меркнет...
10. starik-2005 3188 11.09.25 11:00 Сейчас в теме
Я вот вообще не ратую за временные таблицы, особенно в которые пытаются засунуть всю базу. А при условиях "меньше равно дате, проведен, организация" это все легко может оказаться всеми документами. А их там может быть сколько угодно. Миллион, например.

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

Ну и временные таблицы - это, в связи с этим вот "методом работы" обычных программистов, - еще и куча записей на диск в те самые tempDB. И, кстати, количество IO для диска не будет больше, если таких таблиц сделать много - выигрыш только в некотором снижении ожиданий на блокировках.
11. ignor 237 11.09.25 11:50 Сейчас в теме
Помню участвовал в доработке ЗУП 2.5 для ФГУП Почта России. Там шло внедрение на 13 тысяч с плюсом рабочих мест. Вот там приходилось переписывать с временных таблиц на вложенные запросы
12. aximo 2407 11.09.25 11:55 Сейчас в теме
(11) вложенные запросы - это ад... отвлекся на пару дней и заново начинай разбираться, что там делал)
13. ixijixi 2045 11.09.25 12:52 Сейчас в теме
Разрешите докопаться)

Код 5. Формирование запроса - получение вспомогательной таблицы периода по дням

Можете пояснить, зачем там НАЧАЛОПЕРИОДА, группировка и упорядочивание? В регистре дата хранится без времени, значит НАЧАЛОПЕРИОДА(Дата, ДЕНЬ) - излишне. Порядок по умолчанию и так будет по дате, они в регистре уже по порядку расположены. Группировка по дням вообще выше моего понимания.

Код 4. Формирование запроса - получение вспомогательной таблицы месяцев.

Здесь группировка по месяцам даст нам нужный результат. Но почему не РАЗЛИЧНЫЕ например вместо этого?
ВЫБРАТЬ РАЗЛИЧНЫЕ
	НАЧАЛОПЕРИОДА(ДанныеПроизводственногоКалендаря.Дата, МЕСЯЦ) КАК Дата
ИЗ
	РегистрСведений.ДанныеПроизводственногоКалендаря КАК ДанныеПроизводственногоКалендаря
ГДЕ
	ДанныеПроизводственногоКалендаря.Год = 2025
Такой запрос не требует ни группировки, ни порядка, а результат тот же.
SemandCheb; 0x00; +2 Ответить
14. aximo 2407 11.09.25 12:58 Сейчас в теме
(13) разрешаю докопаться… пусть будет… кто-нибудь узнает, что так тоже можно
15. SemandCheb 11.09.25 18:47 Сейчас в теме
(13)
Полностью согласен.
Используя производственный календарь нет нужды в группровке дней, это не выборка нескольких записей с одним днем.
По выборке месяцев вариант с "различные" читается легче и скорость выборки будет выше из-за отсутствия необходимости применения преобразования по полю группировки
Для отправки сообщения требуется регистрация/авторизация