В современных версиях «1С:Управление торговлей» (начиная с релиза 11.5) и других конфигурациях на базе Библиотеки стандартных подсистем (БСП) произошли существенные изменения в механизме хранения присоединенных файлов, в том числе изображений номенклатуры. Если раньше данные можно было легко получить из регистра сведений ДвоичныеДанныеФайлов, то теперь этот регистр помечен как устаревший (УдалитьДвоичныеДанныеФайлов) и на смену ему пришла новая, более сложная, но и более гибкая архитектура.
Эта ситуация вызывает закономерный вопрос: где теперь искать двоичные данные картинки и как адаптировать старые отчеты на СКД, которые выводили изображения товаров? Давайте разберем этот вопрос по шагам.
Переход от одного регистра к другому — это не просто переименование, а часть планомерного развития платформы. Фирма «1С» унифицирует работу с файлами во всех своих типовых решениях, внедряя механизм из БСП.
Основные причины изменений:
.1CD), ускоряет резервное копирование и обслуживание. В базе хранятся только ссылки (пути), а сами файлы лежат в папках на сервере.Чтобы правильно составить запрос для отчета, нужно понимать новую цепочку объектов, которая связывает номенклатуру с ее изображением. Раньше связь была проще, теперь она более многоуровневая, но логичная.
Вот как выглядит современная схема:
Номенклатура → НоменклатураПрисоединенныеФайлы → ВерсииФайлов → ХранилищеФайлов
Разберем каждый элемент этой цепочки:
Справочник.НоменклатураПрисоединенныеФайлы: Это справочник, подчиненный номенклатуре. Он хранит метаданные о файле: его имя, автора, дату создания, размер и, что самое важное, ссылку на текущую версию файла. У каждого объекта конфигурации, к которому можно прикреплять файлы (договоры, контрагенты или даже добавленные через расширения коммерческие предложения), есть свой аналогичный справочник.Справочник.ВерсииФайлов: Этот служебный справочник отвечает за версионирование. Каждое сохранение измененного файла создает новую запись-версию. Кстати, существуют подходы, позволяющие организовать общий справочник присоединенных файлов для документа-основания и подчиненных документов, чтобы избежать дублирования версий. Именно версия, а не сам присоединенный файл, напрямую связана с местом хранения двоичных данных.РегистрСведений.ХранилищеФайлов: Это конечная точка нашего поиска. Если в настройках выбрано хранение «в информационной базе», то бинарное содержимое конкретной версии файла (тип ХранилищеЗначения) помещается в ресурс этого регистра.Таким образом, чтобы добраться до картинки, нам нужно пройти по всей этой цепочке с помощью соединений в запросе.
Теперь, зная структуру, мы можем построить корректный запрос в конструкторе схемы компоновки данных. Для тех, кто пишет код загрузки файлов программно, а не через СКД, также пригодится небольшая шпаргалка по прикреплению файлов методами БСП. Но в нашем случае рассмотрим именно запрос.
Основная таблица. Начнем с основного объекта — справочника Номенклатура.
Присоединяем файл картинки. В справочнике Номенклатура есть реквизит ФайлКартинки. Он ссылается на основной файл изображения в справочнике НоменклатураПрисоединенныеФайлы. Используем его для первого соединения.
Делаем ЛЕВОЕ СОЕДИНЕНИЕ со справочником НоменклатураПрисоединенныеФайлы по условию Номенклатура.ФайлКартинки = НоменклатураПрисоединенныеФайлы.Ссылка.
Получаем версию файла. Теперь от присоединенного файла нам нужно перейти к его версии. В справочнике НоменклатураПрисоединенныеФайлы есть реквизит, ссылающийся на текущую активную версию (обычно это реквизит типа СправочникСсылка.ВерсииФайлов, например, ТекущаяВерсия).
Делаем ЛЕВОЕ СОЕДИНЕНИЕ со справочником ВерсииФайлов по условию НоменклатураПрисоединенныеФайлы.ТекущаяВерсия = ВерсииФайлов.Ссылка.
Извлекаем двоичные данные. Финальный шаг — получить само изображение из нового хранилища.
Делаем ЛЕВОЕ СОЕДИНЕНИЕ с регистром сведений ХранилищеФайлов по условию ВерсииФайлов.Ссылка = ХранилищеФайлов.ВерсияФайла. Из этого регистра забираем ресурс Хранилище — это и есть наши двоичные данные.
Важный момент: обратная совместимость. При обновлении конфигурации старые файлы могут оставаться в устаревшем регистре УдалитьДвоичныеДанныеФайлов. Чтобы отчет работал корректно в переходный период, пока все данные не будут перенесены фоновым заданием, лучше объединить данные из двух регистров. Это можно сделать с помощью ОБЪЕДИНИТЬ ВСЕ.
Посмотрим на пример итогового запроса:
ВЫБРАТЬ
Номенклатура.Ссылка КАК Номенклатура,
Номенклатура.Наименование,
Хранилища.Хранилище КАК Изображение
ИЗ
Справочник.Номенклатура КАК Номенклатура
ЛЕВОЕ СОЕДИНЕНИЕ (ВЫБРАТЬ
ХранилищеФайлов.ВерсияФайла КАК ВерсияФайла,
ХранилищеФайлов.Хранилище КАК Хранилище
ИЗ
РегистрСведений.ХранилищеФайлов КАК ХранилищеФайлов
ОБЪЕДИНИТЬ ВСЕ
ВЫБРАТЬ
УдалитьДвоичныеДанныеФайлов.Файл,
УдалитьДвоичныеДанныеФайлов.ДвоичныеДанныеФайла
ИЗ
РегистрСведений.УдалитьДвоичныеДанныеФайлов КАК УдалитьДвоичныеДанныеФайлов) КАК Хранилища
ПО Номенклатура.ФайлКартинки.ТекущаяВерсия = Хранилища.ВерсияФайла
Обратите внимание: в примере выше используется подзапрос с объединением для получения данных из нового и старого хранилищ. Имя реквизита для связи с версией в справочнике присоединенных файлов может отличаться (например, ТекущаяВерсия или другое), его следует уточнить в конфигураторе. После того как все данные будут перенесены в новый регистр, часть запроса с ОБЪЕДИНИТЬ ВСЕ и регистром УдалитьДвоичныеДанныеФайлов можно будет убрать для оптимизации.
После получения поля с двоичными данными в СКД не забудьте настроить его отображение в макете. В поле вывода установите тип «Картинка». Если же перед вами стоит задача не вывести саму картинку, а лишь отобразить индикатор наличия вложений в формах списков, рекомендуем ознакомиться с решением по выводу «скрепки» в журналах документов для УТ 11.5.
Таким образом, несмотря на усложнение архитектуры, задача вывода изображений остается вполне решаемой. Главное — понимать новую структуру связей между объектами и корректно строить запрос.