Как правильно сравнить цены заказа поставщику с ценами в документе поступления товаров в 1С?

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

Анализ проблемы: почему данные не объединяются?

Частой ошибкой при создании отчетов является попытка получения данных из табличных частей документов путем обращения к ним через «точку» от ссылки (например, Документ.Имя.ТабличнаяЧасть). Также нередко пользователи пытаются использовать регистры сведений там, где необходимо оперировать данными конкретного первичного документа. В 1С важно помнить: для получения детальных данных о номенклатуре и ценах необходимо обращаться напрямую к табличной части как к самостоятельной таблице базы данных.

Решение задачи: использование единого запроса

Наиболее надежным способом решения поставленной задачи является объединение данных в одном запросе с использованием механизма ЛЕВОЕ СОЕДИНЕНИЕ. Это позволяет не терять записи из документов поступления, даже если для некоторых товаров не удалось найти соответствующий заказ.

Давайте рассмотрим, как правильно построить такой запрос. Мы будем использовать таблицы Документ.ПриобретениеТоваровУслуг.Товары и Документ.ЗаказПоставщику.Товары.

Шаги для реализации:

1. Выбираем основной источник данных — табличную часть поступления товаров.
2. Соединяем её с табличной частью заказов.
3. В условии соединения обязательно указываем сопоставление как по ссылке на документ-заказ, так и по самой номенклатуре, чтобы избежать дублирования строк.

Ниже представлен пример кода, который решает задачу сравнения цен:

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

Почему это решение наиболее эффективно?

Рассмотрим подробнее преимущества данного подхода:

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

Рекомендации по работе с конструктором запросов

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

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

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