Как в запросе 1С обратиться к конкретному виду операции документа при переходе на Розницу 3.0?

← На главную

Переход с конфигурации «Розница 2.3» на «Розницу 3.0» представляет собой не просто плановое обновление, а серьезную смену архитектурной платформы. Если версия 2.3 базировалась на логике «Управления торговлей 11», то новая 3.0 построена на коде «1С:Управление нашей фирмой» (УНФ). Для разработчика это означает полную перестройку модели метаданных. Ранее привычные документы, такие как ВозвратПоставщику или ПриходТоваров, превратились в единые объекты (например, ПриходнаяНакладная), где конкретный смысл операции определяется реквизитом ВидОперации.

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

Смена архитектурной концепции: от множества документов к видам операций

Проанализируем ситуацию: в старой архитектуре под каждую хозяйственную операцию существовал отдельный тип документа. В «Рознице 3.0» реализован принцип «единого журнала». Рассмотрим основные изменения:

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

Это требует от программиста изменения логики построения запросов. Если раньше мы выбирали данные из таблицы Документ.ПоступлениеТоваровУслуг, то теперь нам нужно обращаться к Документ.ПриходнаяНакладная и обязательно накладывать фильтр по нужному значению перечисления.

Решение проблемы через конструкцию ЗНАЧЕНИЕ() в запросе

Самый быстрый способ ограничить выборку документов конкретной операцией — использовать встроенную конструкцию ЗНАЧЕНИЕ(). Рассмотрим пример запроса, который выбирает данные из табличной части Запасы (обратите внимание, что в УНФ-архитектуре табличная часть с товарами чаще всего называется именно Запасы, а не Товары).

Допустим, нам необходимо получить данные только по поступлениям от поставщиков. Нам нужно обратиться к перечислению ВидыОперацийПриходнаяНакладная. Посмотрим на правильный синтаксис условия ГДЕ:


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

Важный момент: часто начинающие разработчики допускают ошибку, ставя символ амперсанда & перед словом ЗНАЧЕНИЕ. Помните, что & используется только для передачи внешних параметров. Конструкция ЗНАЧЕНИЕ() является встроенной функцией языка запросов для обращения к предопределенным элементам (перечислениям, справочникам, планам счетов) и не требует передачи через метод УстановитьПараметр().

Альтернативный подход: использование параметров запроса

Несмотря на удобство ЗНАЧЕНИЕ(), стандарты разработки «1С» рекомендуют использовать параметры. Это делает ваш код более гибким и универсальным. Например, если завтра вам понадобится использовать ту же обработку для выборки «Возвратов от покупателей», вам не придется менять текст запроса — достаточно изменить передаваемый параметр.

Разберем, как это реализовать программно:


Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |   ПриходнаяНакладная.Ссылка
    |ИЗ
    |   Документ.ПриходнаяНакладная КАК ПриходнаяНакладная
    |ГДЕ
    |   ПриходнаяНакладная.ВидОперации = &ВидОперации";

// Устанавливаем конкретное значение перечисления как параметр
Запрос.УстановитьПараметр("ВидОперации", Перечисления.ВидыОперацийПриходнаяНакладная.ПоступлениеОтПоставщика);

Результат = Запрос.Выполнить();

Нюансы структуры данных в «Рознице 3.0»

При переносе обработок из версии 2.3 важно учитывать не только виды операций, но и другие изменения в структуре метаданных:

Сквозные регистры: В архитектуре УНФ данные о движениях товаров и закупках часто эффективнее получать не из документов, а из регистров накопления, таких как Закупки или Запасы. В этих регистрах данные уже разделены по типам движений, что может избавить вас от необходимости сложных соединений с шапками документов.
Статусы документов: В отличие от Розницы 2.3, здесь активно используется реквизит Состояние. Документ может быть проведен, но иметь статус «В работе» или «Завершен». При построении отчетов по взаиморасчетам или остаткам обязательно проверяйте, какие именно состояния влияют на нужные вам показатели.
Налогообложение: Реквизит Налогообложение в шапке документа (УСН, ОСНО, Патент) напрямую влияет на то, как рассчитываются суммы НДС в табличной части. Если ваша обработка пересчитывает цены или налоги, логику расчетов нужно адаптировать под этот реквизит.
Дополнительные реквизиты: Многие поля, которые в 2.3 были типовыми, в 3.0 могут быть вынесены в механизм «Дополнительных реквизитов и сведений». Если вы не находите нужного поля в списке реквизитов документа, проверьте его наличие в табличной части ДополнительныеРеквизиты.

Типичные ошибки при работе с перечислениями в запросах

Проанализируем ситуацию, с которой столкнулся автор темы: Конструктор ругается, что-то не так со строчкой.... Основная причина — смешение понятий «Ссылка» и «Значение». В языке 1С реквизит ВидОперации имеет тип ссылки на перечисление. Когда мы сравниваем его в запросе, мы сравниваем одну ссылку с другой.

Выясним причины ошибок:

Использование &ЗНАЧЕНИЕ(...) — неверно (лишний амперсанд).
Сравнение с пустой строкой или числом — неверно (несоответствие типов).
Попытка обратиться к Перечисление.ВидыОперацийПриходнаяНакладная.ПоступлениеОтПоставщика без использования функции ЗНАЧЕНИЕ() внутри текста запроса — приведет к синтаксической ошибке.

Использование правильного подхода к фильтрации по видам операций — залог успешной адаптации ваших доработок под новую платформу «Розница 3.0».