В процессе внедрения и адаптации конфигурации 1С:Документооборот 2.1 (а также более новых версий линейки 3.0) разработчики часто сталкиваются с жесткими требованиями бизнеса: добавить в карточку внутреннего, входящего или исходящего документа полноценную таблицу. Это может быть спецификация оборудования, список согласующих лиц, график платежей или перечень материальных ценностей. Стандартный механизм дополнительных реквизитов не предоставляет возможности создавать полноценные табличные части «из коробки».
В этой статье мы подробно разберем, какими путями можно решить эту задачу, проанализируем преимущества и недостатки каждого подхода и выберем наиболее оптимальный вариант в зависимости от ограничений вашей системы.
Если перед вами не стоит жесткого условия «не изменять основную конфигурацию», наиболее прямолинейным решением является добавление новой табличной части непосредственно в метаданные нужного документа. Рассмотрим этот процесс по шагам.
ШаблоныВнутреннихДокументов или самого документа) установим правило «Объект изменен с сохранением поддержки».Важное примечание: данный способ гарантирует максимальное быстродействие базы данных и позволяет использовать стандартные механизмы запросов 1С для построения отчетов по созданной таблице. Однако это усложнит процедуру последующих обновлений 1С:Документооборота.
Если вы хотите сохранить основную конфигурацию полностью на замке, но при этом иметь возможность связывать с документами сложные табличные структуры данных, отличной альтернативой является использование подчиненного регистра сведений. Рассмотрим подробнее этот подход.
Мы создаем новый регистр сведений в расширении или основной конфигурации. Структура регистра будет следующей:
ДокументСсылка (тип ссылки на ваш документ в ДО).НомерСтроки (тип Число, для имитации порядка строк в таблице).Номенклатура, Количество, Сумма).Разберем, как вывести эти данные на форму документа. Мы заимствуем форму документа в расширение и создаем на ней динамический список или таблицу значений, которая при инициализации формы будет заполняться данными из нашего регистра сведений, а при записи документа — выгружать изменения обратно в регистр.
Посмотрим на пример программного кода для загрузки данных при открытии формы:
&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
// Запрос для получения данных из нашего регистра сведений
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| НашРегистрСведений.НомерСтроки КАК НомерСтроки,
| НашРегистрСведений.Номенклатура КАК Номенклатура,
| НашРегистрСведений.Количество КАК Количество
|ИЗ
| РегистрСведений.НашРегистрСведений КАК НашРегистрСведений
|ГДЕ
| НашРегистрСведений.ДокументСсылка = &ДокументСсылка";
Запрос.УстановитьПараметр("ДокументСсылка", Объект.Ссылка);
РезультатЗапроса = Запрос.Выполнить();
Если Не РезультатЗапроса.Пустой() Тогда
ТаблицаНаФорме.Загрузить(РезультатЗапроса.Выгрузить());
КонецЕсли;
КонецПроцедуры
Использование регистра сведений позволяет объекту «жить своей жизнью», не перегружает основную таблицу базы данных и сохраняет конфигурацию чистой для будущих обновлений.
В современных версиях платформы 1С:Предприятие 8.3 появилась возможность добавлять новые реквизиты и табличные части непосредственно через механизм расширений. Это исключает необходимость снимать основную конфигурацию с замка.
Рассмотрим, как реализовать этот вариант:
Этот метод является наиболее современным и правильным с точки зрения стандартов разработки фирмы «1С» для платформы 8.3.
Бывают ситуации, когда изменять метаданные (даже через расширения, затрагивающие структуру БД) категорически запрещено административной политикой компании. В таком случае программисты идут на хитрость — используют сериализацию данных таблицы в формат JSON или XML и хранят их в стандартном строковом дополнительном реквизите неограниченной длины.
Выясним логику работы этого метода по шагам:
Строка (неограниченной длины). Назовем его, например, ХранилищеТаблицыJSON.Проанализируем пример кода для сохранения таблицы в JSON:
&НаСервере
Процедура СохранитьТаблицуВДопРеквизит()
ТаблицаДляЗаписи = ТаблицаНаФорме.Выгрузить();
ЗаписьJSON = Новый ЗаписьJSON;
ЗаписьJSON.УстановитьСтроку();
ЗаписатьJSON(ЗаписьJSON, ТаблицаДляЗаписи);
СтрокаJSON = ЗаписьJSON.Закрыть();
// Записываем полученную JSON-строку в свойства нашего документа
// (Используем механизмы БСП для работы с дополнительными реквизитами)
ЗаписатьЗначениеДопРеквизита(Объект.Ссылка, "ХранилищеТаблицыJSON", СтрокаJSON);
КонецПроцедуры
Минусы метода: По данным в такой таблице невозможно делать простые SQL-запросы в базе данных (придется выгружать и парсить каждую строку программно). Метод подходит только для визуального отображения и хранения справочной информации внутри конкретной карточки.
В ходе обсуждения часто возникает вопрос: можно ли использовать СписокЗначений в качестве типа для дополнительных реквизитов? В стандартном функционале 1С:ДО 2.1 такая возможность напрямую не предусмотрена. Однако эту проблему можно решить с помощью интеграции небольших доработок на базе БСП (Библиотеки стандартных подсистем).
Для реализации множественного выбора значений без изменения метаданных обычно подключается расширение, которое добавляет флаг «Множественный выбор» для свойств дополнительных реквизитов. В пользовательском интерфейсе это выглядит как поле ввода, где пользователь может выбрать несколько элементов (например, несколько контрагентов или проектов), которые система сохраняет в подчиненную табличную часть значений свойств объектов БСП и корректно выводит в списках через запятую.