При разработке механизмов интеграции, переноса данных или создания сложных отчетов в конфигурации «Управление производственным предприятием» (УПП) редакции 1.3 разработчики часто сталкиваются с задачей выборки данных из документов поступления. На первый взгляд задача кажется тривиальной, однако специфика архитектуры УПП таит в себе множество подводных камней.
В этой статье мы подробно разберем, как правильно спроектировать запрос к документу ПоступлениеТоваровУслуг, почему нельзя ограничиваться только одной табличной частью, как избежать критических проблем с производительностью СУБД и какой источник данных выбрать — регистры накопления или сами документы.
В сообществе разработчиков 1С часто возникает дискуссия: откуда правильнее получать данные для выгрузки — из табличных частей документов или из движений по регистрам (например, по регистру накопления Закупки или ПартииТоваровНаСкладах)?
Давайте проанализируем обе концепции и выясним, почему для задач синхронизации и переноса данных обращение к физическим таблицам документов является единственно верным решением:
НомерВходящегоДокумента, ДатаВходящегоДокумента), счета учета номенклатуры и НДС (СчетУчетаБУ, СчетУчетаНДС), складские характеристики мест и тары, а также текстовые комментарии и ответственные лица.ПартииТоваровНаСкладах отражает движение исключительно материальных ценностей. Если в документе поступления содержались сторонние услуги (например, доставка или аренда) или внеоборотные активы (оборудование), этот регистр их попросту «не увидит».Таким образом, если перед нами стоит задача переноса документов или заполнения формы подбора для загрузки, мы должны обращаться **напрямую к табличным частям документов**.
Рассмотрим исходный запрос, предложенный автором темы, и выясним, почему он не только не решит поставленную задачу, но и вызовет системную ошибку при компиляции в 1С.
Ошибка 1: Несоответствие полей в выборке и группировке (Синтаксическая ошибка)
В секции СГРУППИРОВАТЬ ПО исходного запроса указаны поля КоличествоМест и ЕдиницаИзмеренияМест. При этом в секции ВЫБРАТЬ этих полей нет. Платформа 1С строго контролирует соответствие полей: все неагрегированные поля из секции выбора обязаны присутствовать в секции группировки, и наоборот. Данный запрос вернет ошибку синтаксиса еще на этапе проверки.
Ошибка 2: Игнорирование других активов (Услуги, Оборудование, Тара)
Документ ПоступлениеТоваровУслуг в УПП 1.3 является универсальным. Продукция и услуги могут быть распределены по нескольким табличным частям:
Товары — сырье, материалы, товары на продажу.Услуги — транспортно-заготовительные расходы, нематериальные затраты.Оборудование — основные средства, требующие монтажа или принятия к учету.Тара — возвратная многооборотная тара.Обращаясь только к табличной части Товары, мы теряем до половины всей информации о закупках.
Ошибка 3: Проблема производительности (Разыменование ссылок через точку)
Обращения вида ПоступлениеТоваровУслугТовары.Ссылка.Номер или ПоступлениеТоваровУслугТовары.Ссылка.Дата заставляют СУБД выполнять неявные левые соединения (LEFT JOIN) таблицы табличной части с таблицей шапки документа. На крупных базах УПП это приводит к колоссальному падению скорости выполнения запроса и избыточным блокировкам таблиц БД.
Ошибка 4: Склады в табличной части
В УПП 1.3 склад поступления может определяться как для всего документа в шапке (реквизит СкладОрдер), так и индивидуально для каждой строки в табличной части (реквизит Склад). Если в настройках документа включена детализация по складам в ТЧ, обращение к реквизиту шапки вернет пустое значение или неактуальный склад.
Выяснив все узкие места, перейдем к проектированию правильного и оптимизированного алгоритма решения задачи.
Для создания быстрого и надежного механизма выгрузки мы применим методику работы с временными таблицами и объединением табличных частей.
Сначала выберем только те документы, которые соответствуют нашим критериям (период проведения, пометка удаления, статус проведения). Это позволит СУБД наложить первичный индекс и работать дальше только с отфильтрованным набором данных шапки.
Обратите внимание: вместо конструкции Проведен = ИСТИНА правильнее писать просто Проведен, так как это поле имеет булев тип.
Рассмотрим структуру первого пакета запроса:
ВЫБРАТЬ
Док.Ссылка КАК Ссылка,
Док.Номер КАК НомерДок,
Док.Дата КАК ДатаДок,
Док.СкладОрдер КАК СкладШапка
ПОМЕСТИТЬ ВТ_Документы
ИЗ
Документ.ПоступлениеТоваровУслуг КАК Док
ГДЕ
Док.Дата МЕЖДУ &НачДата И &КонДата
И Док.Проведен
И НЕ Док.ПометкаУдаления
;
Теперь мы выберем данные из трех основных табличных частей (Товары, Услуги, Оборудование) и соединим их с нашей временной таблицей документов. Для корректной типизации данных мы добавим текстовое поле-маркер ТипСтроки.
Также учтем нюанс со складами: с помощью функции ЕСТЬNULL проверим наличие склада в табличной части. Если он там не заполнен или отсутствует в метаданных конкретной ТЧ (например, в Услугах склада нет), обратимся к складу из шапки документа.
Проанализируем итоговый оптимизированный запрос:
ВЫБРАТЬ
ВТ.Ссылка КАК Ссылка,
ВТ.НомерДок КАК НомерДок,
ВТ.ДатаДок КАК ДатаДок,
"Товары" КАК ТипСтроки,
ТЧТовары.Номенклатура КАК Номенклатура,
ТЧТовары.Номенклатура.Код КАК КодНоменклатуры,
ЕСТЬNULL(ТЧТовары.Склад, ВТ.СкладШапка) КАК Склад,
ТЧТовары.ЕдиницаИзмерения КАК ЕдиницаИзмерения,
ТЧТовары.Коэффициент КАК Коэффициент,
ТЧТовары.Количество КАК Количество,
ТЧТовары.Цена КАК Цена,
ТЧТовары.Сумма КАК Сумма,
ТЧТовары.СтавкаНДС КАК СтавкаНДС,
ТЧТовары.СуммаНДС КАК СуммаНДС
ИЗ
ВТ_Документы КАК ВТ
ВНУТРЕННЕЕ СОЕДИНЕНИЕ Документ.ПоступлениеТоваровУслуг.Товары КАК ТЧТовары
ПО ВТ.Ссылка = ТЧТовары.Ссылка
ОБЪЕДИНИТЬ ВСЕ
ВЫБРАТЬ
ВТ.Ссылка,
ВТ.НомерДок,
ВТ.ДатаДок,
"Оборудование",
ТЧОборудование.Номенклатура,
ТЧОборудование.Номенклатура.Код,
ЕСТЬNULL(ТЧОборудование.Склад, ВТ.СкладШапка),
ТЧОборудование.ЕдиницаИзмерения,
ТЧОборудование.Коэффициент,
ТЧОборудование.Количество,
ТЧОборудование.Цена,
ТЧОборудование.Сумма,
ТЧОборудование.СтавкаНДС,
ТЧОборудование.СуммаНДС
ИЗ
ВТ_Документы КАК ВТ
ВНУТРЕННЕЕ СОЕДИНЕНИЕ Документ.ПоступлениеТоваровУслуг.Оборудование КАК ТЧОборудование
ПО ВТ.Ссылка = ТЧОборудование.Ссылка
ОБЪЕДИНИТЬ ВСЕ
ВЫБРАТЬ
ВТ.Ссылка,
ВТ.НомерДок,
ВТ.ДатаДок,
"Услуги",
ТЧУслуги.Номенклатура,
ТЧУслуги.Номенклатура.Код,
ВТ.СкладШапка, // Для услуг склад берется только из шапки
ТЧУслуги.Содержание, // Содержание услуги часто важнее самой номенклатуры
1, // Коэффициент для услуг всегда равен 1
ТЧУслуги.Количество,
ТЧУслуги.Цена,
ТЧУслуги.Сумма,
ТЧУслуги.СтавкаНДС,
ТЧУслуги.СуммаНДС
ИЗ
ВТ_Документы КАК ВТ
ВНУТРЕННЕЕ СОЕДИНЕНИЕ Документ.ПоступлениеТоваровУслуг.Услуги КАК ТЧУслуги
ПО ВТ.Ссылка = ТЧУслуги.Ссылка
УПОРЯДОЧИТЬ ПО
Ссылка,
ТипСтроки
Давайте подведем итог проведенной оптимизации и выделим ключевые преимущества обновленной архитектуры запроса:
ТЧ.Ссылка.Дата в блоке условий. Фильтрация по дате происходит на первом шаге по индексу шапки документа, что мгновенно отсекает ненужные записи.ОБЪЕДИНИТЬ ВСЕ гарантирует, что при переносе данных выгрузятся не только товары, но и сопутствующие услуги, а также основные средства (оборудование).СГРУППИРОВАТЬ ПО. При переносе документов важно сохранить структуру строк в оригинальном виде. Если вам все же потребуется свернуть одинаковые позиции в приемнике, это безопаснее сделать кодом при загрузке или принудительно сгруппировать уже отобранную коллекцию в оперативной памяти.Используя предложенный подход, вы сможете организовать надежный и быстродействующий обмен данными даже в высоконагруженных и объемных информационных базах 1С:УПП 1.3.