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