Как перенести в расширение стандартные реквизиты

Доброго дня, коллеги!

А вы теряли стандартные реквизиты в конструкторе запросов в расширении? Сколько времени ушло на поиск решения проблемы? А наш слушатель получил  ответ оперативно. Теперь данной хитростью делимся с вами! Безвозмездно

Вопрос

Добрый день! Подскажите, а добавляются ли в расширение стандартные реквизиты, например, для справочника реквизит “ЭтоГруппа” или “Владелец” (когда я делаю запрос в расширении и хочу отобрать элементы, не являющиеся каталогами, данных реквизитов  нет). Пробовал добавлять все реквизиты и формы данного справочника в расширение, но стандартные так и не добавились. В свойствах стандартных реквизитов так же не нашел возможности добавить в расширение. Платформа 1С 8.3.15, конфигурация 1С:УПП 1.3.

Ответ

Добрый день! Нужно в расширении указать, что этот справочник является иерархическим (то есть указать в расширении свойство Иерархический как контролируемое):

Тогда конструктор запроса покажет поле ЭтоГруппа.

Или давайте рассмотрим на примере, на пустой базе. Пусть у нас есть справочник Спецификации, подчиненный справочнику Номенклатура:

Создадим расширение конфигурации, заимствуем оба справочника в расширение.

В расширении воспользуемся конструктором запроса. Для справочника Спецификации поле Владелец недоступно:

Теперь отметим для справочника Спецификации свойство Владельцы как контролируемое:

После этого в конструкторе запроса появляется поле Владелец:

На форме объекта в расширении можно отобразить владельца:

Перенос в расширение реквизитов из конфигурации, такое возможно?

Я

   Trance_1C

15.06.20 — 04:38

   Галахад

1 — 15.06.20 — 05:37

(0) Сравнения с расширением нет.

   AAA

2 — 15.06.20 — 05:56

(0)Что Вы собрались сравнивать в расширении с основной конфигурацией ?)

   Trance_1C

3 — 15.06.20 — 08:32

(2) Есть обновляемая база на конфигурации бухгалтерия корп 2.0, в ее документах есть нетиповые реквизиты.

Готовлю конфигурацию 3.0 для загрузки в обновляемую базу. Не хочу снимать с поддержки новую конфигурацию, для этого добавил расширение, в него закинул измененные объекты, и хотел объединившись с конфой обновляемой базы, закинуть в расширение реквизиты измененных объектов, чтобы сохранились идентификаторы реквизитов…

   Trance_1C

4 — 15.06.20 — 08:34

Интересно какие религиозные предубеждения помешали 1С оставить нам возможность объединять конфигурации с расширениями?!

   Trance_1C

5 — 15.06.20 — 08:43

Вот интересно, как тогда перенести в расширение реквизиты с сохранением идентификаторов?!

придется закидывать их сначала в основную конфигурацию сняв ее с поддержки,

  затем передать объекты в расширение,

   сохранить конфигурацию расширения

    вернуть поддержку на основную конфигурацию

     создать новое расширение

      объединиться с сохраненным расширением, и профит! у нас реквизиты с правильными идентификаторами в расширении…

   Фрэнки

6 — 15.06.20 — 08:43

   Trance_1C

7 — 15.06.20 — 08:44

расширение с расширением объединять вроде можно?

   2S

8 — 15.06.20 — 08:45

(0) реквизиты в расширение, ну ну

   Фрэнки

9 — 15.06.20 — 08:45

(7) не пробовал. Ожидаемо, что должна быть такая возможность — это позволить «собирать» одно большое расширение взамен нескольких маленьких.

   Фрэнки

10 — 15.06.20 — 08:47

   Trance_1C

11 — 15.06.20 — 08:50

(10) это когда объединяясь с конфигурацией заимствуешь не весь объект а его отдельные реквизиты, таким образом в обновляемый объект переносятся реквизиты с сохранением идентификаторов созданных в загружаемой конфигурации.

   Chameleon1980

12 — 15.06.20 — 08:51

зачем реквизиты переносить в расширение?

   Trance_1C

13 — 15.06.20 — 08:52

(12) чтобы сохранились данные в этих реквизитах, т.к. если создать их заново, это будут новые реквизиты и данные будут утеряны.

   Фрэнки

14 — 15.06.20 — 08:53

(13) бред

   AAA

15 — 15.06.20 — 08:53

Я думаю, что все-таки самое простое это сделать из Вашей нетиповой БП 2.0 аналогичную нетиповую БП 3.0, все перенести, все проверить. А затем уже привести БП 3.0 у типовой, убирая все нетиповое в расширение. Это тоже не так просто и трудоемко, но по крайней мере все будет более или менее под контролем

   Trance_1C

16 — 15.06.20 — 08:54

(13) Если вы к примеру, удалите в конфигурации реквизит «Контрагент» у документа реализация, и добавите новый точно такой-же с тем-же типом, разве контрагенты во всех реализациях не исчезнут?

   Trance_1C

17 — 15.06.20 — 08:56

(15) я этот вариант описал в (5) сообщении. Похоже так и придется.

   Фрэнки

18 — 15.06.20 — 08:56

(16) А если эту манипуляцию произвести на основной конфигурации и при этом выполнить ее сохранение и применение к основной — не исчезнут?

   Trance_1C

19 — 15.06.20 — 08:59

(18) Понятное дело исчезнут, поэтому вся эта возня с переносом реквизитов из обновляемой бухни 20, в новую конфигурацию, Просыпайся Фрэнки!

   Фрэнки

20 — 15.06.20 — 09:00

   Trance_1C

21 — 15.06.20 — 09:07

(20) в чем бред, если в обновленной конфигурации в документах не будет ранее созданных реквизитов, после загрузки такой конфигурации в базу, данные в этих реквизитах будут потеряны. Что здесь непонятного?

   Trance_1C

22 — 15.06.20 — 09:08

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

   Галахад

23 — 15.06.20 — 09:12

Хм. А чего можно удалить реквизит из основной конфигурации помещенный в расширение?

   hhhh

24 — 15.06.20 — 09:19

(22) но так как ты предлагаешь в (0), реквизиты тоже ведь исчезнут. Какая разница?

   AAA

25 — 15.06.20 — 09:23

C тем же самым идентификатором реквизиты в расширение все равно не перенести, но и зачем? Почему все уперлось во внутренний идентификатор ?

   Фрэнки

26 — 15.06.20 — 09:28

(25) А чтоб перенос данных не писать

   AAA

27 — 15.06.20 — 09:30

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

   hhhh

28 — 15.06.20 — 09:37

(27) тогда похоже 2 раза придется значения реквизитов переносить. При переходе с 2.0, а потом при переносе в расширение.

   Trance_1C

29 — 15.06.20 — 09:37

(26) Бинго!

(27) Вот это именно тот вариант который очень хочется избежать, я пожалуй лучше перенесу все эти реквизиты объектов в доп реквизиты перед обновлением….

   Фрэнки

30 — 15.06.20 — 09:45

   Фрэнки

31 — 15.06.20 — 09:47

   hhhh

32 — 15.06.20 — 09:47

(29) ну, то есть чтобы не делать обычный простой перенос, ты выбрал сделать более сложный перенос?

   Trance_1C

33 — 15.06.20 — 09:58

(32) я думал можно закинуть реквизиты в расширение из старой конфы и старая база узнает эти реквизиты как родные подсунет туда все данные

   Фрэнки

34 — 15.06.20 — 10:00

(33) угу. Ты слишком хорошо подумал о разработчиках платформы и о разработчиках расширений внутри этой самой платформы

Закинуть то в расширение из основной конфы добавленные реквизиты можно, но вот только потом из основной не уберешь ))

Как добавить, изменить реквизит формы через расширение

В новых версиях платформы, при изменении типовых форм, стандартные и новые реквизиты (добавленные в расширение) по умолчанию недоступны: их нельзя изменить, ни добавить в форму. Дело в том, что немного изменился механизм добавления реквизитов в расширение, для изменения типовых форм объектов.

Вам необходимо выполнить следующие действия:

• В дереве метаданных нажать правой кнопкой мыши на реквизит -> «Добавить в расширение» -> выбрать расширение;

• Перейти в расширение конфигурации, открыть форму, в которую планируем добавить (или изменить) реквизит -> в области справа выделить реквизит -> нажать правую кнопку мыши -> «Добавить реквизит»;

Почему в новой платформе изменился данный механизм?

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

Реквизиты, которые возможно изменить в форме выделяются черным цветом, а недоступные — серым. При этом при обновлении реквизиты в старых расширениях будут сразу доступны для редактирования.

Связанные статьи

Доброго времени суток, уважаемые коллеги! В этой статье приведен реальный пример реализации переноса изменений конфигурации Бит. Автотранспорт (3.0.80.36/3.0.4.55) в расширение конфигурации и установка конфигурации под «замок» с возможностью обновления. Также показано, как решить возникшие проблемы по ходу переноса. Давайте разберёмся!

• Перечень основных шагов при переносе доработок конфигурации в расширение
• Копирование целого объекта из конфигурации в расширение
• Настройка связей параметров выбора для отбора по владельцу
• Установка проверки заполнения реквизита в расширении
• Перенос констант в расширение
• Добавление команды для формирования документа на основании
• Ввод на основании нескольких документов
• Описание обработки переноса данных
• Добавление дополнительных отчетов в расширение
• Демонстрация добавления и удаления расширения 1С
• Демонстрация доработок, перенесенных в расширение

Перечень основных шагов при переносе доработок конфигурации в расширение

1. Сравнить основную конфигурацию с конфигурацией поставщика. Как это сделать посмотрите здесь.
2. Посмотреть поддерживает ли режим совместимости возможность использования расширений? С версии платформы 8.3.11 появилась эта возможность. Нужно установить этот режим совместимости, если текущая версия ниже. 
3. Создать новое расширение конфигурации и установить префикс для этого расширения. Назначение: Адаптация. 
4. Добавить в расширение все структуры необходимые для хранения данных, которые отличаются от конфигурациии поставщика. Также для правильной работы расширения нужно будет заимствовать все необходимые объекты конфигурации. На этом шаге могут возникать разные ситуации, которые будут препятствовать переносу. Некоторые описаны начиная со следующего подзаголовка. На этом шаге расширение конфигурации уже должно быть готово. Как установить готовое расширение можно посмотреть на видео ниже.
5. Создать обработку для переноса данных из старых структур, которые были в основной конфигурации, в новые структуры, которые были созданы при помощи расширений. Некоторое описание обработки можно посмотреть в подзаголовке, а скачать её можно по ссылке в конце статьи.
6. Перенести данные. 
7. Удалить старые данные из конфигурации в правильном порядке. Это значит, что нужно сначала удалить объекты, в которых есть ссылки на другие объекты. Например, в документе есть реквизит с типом справочник Номенклатура. Сначала удалить этот реквизит, а затем и сам справочник Номенклатура.
8. Вернуть изменённые объекты конфигурации обратно на замок, установив для объектов правило поддержки Объект поставщика не редактируется.
9. Конфигурация — Поддержка — Настройка поддержки.
10. Снова выполнить сравнение с конфигурацией поставщика. Кнопка «Сравнить, обьединить».
11. Выставить в поле «Фильтр» значение «Нет фильтра».
12. Найти нужный объект в дереве, нажать в правом углу кнопку «Изменить» и выбрать правило «Объект поставщика не редактируется». И подобным образом для всех объектов, у которых раньше была снята поддержка. 

Копирование целого объекта из конфигурации в расширение

При копировании целого объекта из конфигурации в расширение может появится сообщение:

ОБНАРУЖЕНЫ НЕРАЗРЕШИМЫЕ ССЫЛКИ:

Это значит, что в расширение нужно заимствовать объекты из конфигурации, которые являются типами для данных, содержащихся в переносимом объекте. После заимствования нужно сохранить конфигурацию, чтобы заимствованные объекты и их стандартные реквизиты стали доступны.

Если нужно добавить новые реквизиты на форму, то сначала нужно заимствовать эту форму и открыть её, затем перейти в правую панель с реквизитами. Основной реквизит формы (Объект) будет выделен серым. Чтобы заимствовать объект нужно в контекстном меню выбрать «Добавить в расширение», после этого основной реквизит формы (Объект) будет выделен черным.

Чтобы были видны реквизиты документа в модуле объекта расширения, например Контрагент или ВидОперации нужно эти реквизиты заимствовать в расширение. Иначе будет выдаваться такая ошибка:

{ЗаказНаТехнику Документ.СписаниеСРасчетногоСчета.МодульОбъекта(11,6)}: Переменная не определена (ВидОперации)

Если нужно на форме документа расширения добавить глобальную команду, то сначала нужно заимствовать эту команду в расширение и указать в ее свойствах «Тип параметра команды», как это показано в подзаголовке. Если, например, это документ СчетНаОплатуПокупателю, то параметром будет ДокументСсылка.СчетНаОплатуПокупателю соответственно. Если есть картинка к команде, то нужно заимствовать и её.

Настройка связей параметров выбора для отбора по владельцу

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

После этого в заимствованном документе расширения (бит_мат_ЗаказНаТехнику) у нового реквизита (Заказ_ИсполнительДоговор) с типом ДоговорыКонтрагентов в форме «Связи параметров выбора» из выпадающего списка в левой панели можно выбрать «Отбор.Владелец» со значением отбора по владельцу (Заказ_Исполнитель).

Установка проверки заполнения реквизита в расширении

В документе (бит_мат_ЗаказНаТехнику) в табличной части (ТребованияКТехнике) есть реквизит Техника со свойством “Проверка заполнения”, значение которого установлено как “Выдавать ошибку”, а нужно для него в расширении проставить значение “Не проверять”. Хотя этот реквизит перенесен в расширение, его свойства недоступны для редактирования. К сожалению, далеко не все свойства реквизитов документа являются расширяемыми. Но существует программное изменение значений свойств в расширении.

Хотя и невозможно поменять свойство “Проверка заполнения” в расширении у заимствованного реквизита, но можно изменить обработку ОбработкаПроверкиЗаполнения() в модуле объекта через расширение, так чтобы реквизит, даже не заимствованный, не проверялся. Вот, что можно написать:

&После("ОбработкаПроверкиЗаполнения")
Процедура Заказ_ОбработкаПроверкиЗаполнения(Отказ, ПроверяемыеРеквизиты)
	ИндексПоляТехника = ПроверяемыеРеквизиты.Найти("ТребованияКТехнике.Техника");
	Если ИндексПоляТехника <> Неопределено Тогда
		ПроверяемыеРеквизиты.Удалить(ИндексПоляТехника);
	КонецЕсли;
КонецПроцедуры

Перенос констант в расширение

В конфигурации были добавлены две константы (бит_Номенклатура и НоменклатурнаяГруппа). Нужно было их перенести в расширение, но к сожалению, объекты Константы в расширении можно создавать только на платформе 8.3.16 и выше. Данная конфигурация не поддерживала режим совместимости 8.3.16. Поэтому было решено создать регистр сведений (Заказ_Константы) и хранить значение констант там, а для получения значений констант нужно использовать функцию общего модуля ЗаказНаТехнику. Эта функция возвращает структуру со всеми значениями констант, сохраненных в ресурсах регистра. Вот код этой функции:

Функция ПолучитьКонстанты() Экспорт
	Результат = Новый Структура();
	Результат.Вставить("бит_Номенклатура", Справочники.Номенклатура.ПустаяСсылка()) ;
	Результат.Вставить("НоменклатурнаяГруппа", Справочники.НоменклатурныеГруппы.ПустаяСсылка());
	Запрос = Новый Запрос;
	Запрос.Текст = 
	"ВЫБРАТЬ
	|   Заказ_Константы.бит_Номенклатура КАК бит_Номенклатура,
	|   Заказ_Константы.НоменклатурнаяГруппа КАК НоменклатурнаяГруппа
	|ИЗ
	|   РегистрСведений.Заказ_Константы КАК Заказ_Константы";
	
	РезультатЗапроса = Запрос.Выполнить();
	
	Выборка = РезультатЗапроса.Выбрать();
	
	Пока Выборка.Следующий() Цикл
		ЗаполнитьЗначенияСвойств(Результат, Выборка);
	КонецЦикла;
	Возврат Результат;
КонецФункции // ПолучитьКонстанты()

Добавление команды для формирования документа на основании

В конфигурации для документа РеализацияТоваровУслуг добавили возможность его ввода на основании документа бит_мат_ЗаказНаТехнику, а это значит, что стандартный реквизит ВводитсяНаОсновании документа РеализацияТоваровУслуг изменился. Чтобы сохранить возможность ввода документа РеализацияТоваровУслуг нужно:

• В расширении в разделе «Общие -> Общие команды«, создать новую команду. 
• Дать название, например, «Заказ_РеализацияТоваровУслугСоздатьНаОсновании«. 
• Группу у команды указать: «Командная панель формы.Создать на основании».
• Тип параметра команды: Ссылки тех документов, в которых появится новая строка в подменю ВводаНаОсновании. В данном случае «ДокументСсылка.битматЗаказНаТехнику«.
• Режим использования параметра: «Одиночный». Теперь в меню документа битматЗаказНаТехнику появится новая команда ввода на основании.

Теперь в меню документа битматЗаказНаТехнику появится новая команда ввода на основании. В модуле команды в процедуре ОбработкаКоманды написать код, который будет делать ввод нового документа на основании:

&НаКлиенте
Процедура ОбработкаКоманды(ПараметрКоманды, ПараметрыВыполненияКоманды)
	СтрДанные = Новый Структура("Основание", ПараметрКоманды);
	ПараметрыФормы = Новый Структура("ЗначенияЗаполнения", СтрДанные);
	
	ОткрытьФорму("Документ.РеализацияТоваровУслуг.ФормаОбъекта", ПараметрыФормы, 
	ПараметрыВыполненияКоманды.Источник, ПараметрыВыполненияКоманды.Уникальность, 
	ПараметрыВыполненияКоманды.Окно, ПараметрыВыполненияКоманды.НавигационнаяСсылка);
КонецПроцедуры

И еще, чтобы уже все работало в расширении после исполнения обработки заполнения Реализации добавить код с использованием аннотации ИзменениеИКонтроль (Вызвать вместо (с контролем)): 

&ИзменениеИКонтроль("ОбработкаЗаполнения")
Процедура Заказ_ОбработкаЗаполнения(ДанныеЗаполнения, СтандартнаяОбработка)
	...
			#Вставка
			ИначеЕсли ТипДанныхЗаполнения = Тип("Структура")
				И ДанныеЗаполнения.Свойство("Основание")
				И ТипЗнч(ДанныеЗаполнения.Основание) = Тип("ДокументСсылка.бит_мат_ЗаказНаТехнику") Тогда				
				ДокументОснование = ДанныеЗаполнения.Основание;			
			#КонецВставки
			
	...
КонецПроцедуры

Ввод на основании нескольких документов

Чтобы можно было передавать сразу несколько документов в списке и создавать на их основе одну реализацию можно сделать следующее. Создать команду формы СоздатьНаОснованииРеализацияТоваровУслуг и расположить кнопку этой команды на форме списка в группе ГруппаГлобальныеКоманды и скрыть видимость этой кнопки. В списке документа в обработчике события ПриСозданииНаСервере переопределить команду, чтобы она появилась в ранее сформированной группе «Командная панель формы. Создать на основании»: 

&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
	...
		// Переопределим команду меню формы
		НазваниеКомандыФормы = "ФормаОбщаяКомандаЗаказ_РеализацияТоваровУслугСоздатьНаОсновании";
		ГруппаСоздатьНаОсновании = Элементы.ГруппаГлобальныеКоманды.ПодчиненныеЭлементы.Найти("ФормаСоздатьНаОсновании");
		Если ГруппаСоздатьНаОсновании <> Неопределено Тогда
			КнопкаСозданиеРеализации = ГруппаСоздатьНаОсновании.ПодчиненныеЭлементы.Найти(НазваниеКомандыФормы);
			Если КнопкаСозданиеРеализации <> Неопределено Тогда	
				КнопкаСозданиеРеализации.Видимость = Ложь;
				Элементы.ФормаСоздатьНаОснованииРеализацияТоваровУслуг.Видимость = Истина;
				Элементы.Переместить(Элементы.ФормаСоздатьНаОснованииРеализацияТоваровУслуг, 
										ГруппаСоздатьНаОсновании, КнопкаСозданиеРеализации);
	 		КонецЕсли; 
		КонецЕсли;
	
		// Переопределим команду контекстного меню
	        НазваниеКомандыФормы = "СписокКонтекстноеМенюОбщаяКомандаЗаказ_РеализацияТоваровУслугСоздатьНаОсновании";
		ГруппаКонтекстноеМенюСоздатьНаОсновании = 
		Элементы.Список.КонтекстноеМеню.ПодчиненныеЭлементы.Найти("СписокКонтекстноеМенюСоздатьНаОсновании");
		Если ГруппаКонтекстноеМенюСоздатьНаОсновании <> Неопределено Тогда
			КомандаСоздатьНаОсновании = 
			ГруппаКонтекстноеМенюСоздатьНаОсновании.ПодчиненныеЭлементы.Найти(НазваниеКомандыФормы);
			Если КомандаСоздатьНаОсновании <> Неопределено Тогда
			
				КомандаСоздатьНаОсновании.Видимость = Ложь;
				Элементы.СписокКонтекстноеМенюСоздатьНаОснованииРеализацияТоваровУслуг.Видимость = Истина;
				Элементы.Переместить(Элементы.СписокКонтекстноеМенюСоздатьНаОснованииРеализацияТоваровУслуг, 
										ГруппаКонтекстноеМенюСоздатьНаОсновании, КомандаСоздатьНаОсновании);
			КонецЕсли; 
		КонецЕсли;
		
	...
		
		#Область СлужебныеПроцедурыИФункции
		
		&НаКлиенте
		Процедура СоздатьНаОсновании(Команда)
			ВыделенныеСтроки = Элементы.Список.ВыделенныеСтроки;
			Если ТипЗнч(ВыделенныеСтроки) = Тип("Массив") Тогда		
				Если ВыделенныеСтроки.Количество() > 0 Тогда
				
					СтрДанные = Новый Структура("Основание", Новый ФиксированныйМассив(ВыделенныеСтроки));
					ПараметрыФормы = Новый Структура("ЗначенияЗаполнения", СтрДанные);
					
					ОткрытьФорму("Документ.РеализацияТоваровУслуг.ФормаОбъекта", ПараметрыФормы, ЭтотОбъект);
		
				КонецЕсли; 
			КонецЕсли; 
		КонецПроцедуры
		
		#КонецОбласти
		
	...
КонецПроцедуры

Для контекстного меню сделаем почти тоже самое. Создадим кнопку на форме списка СписокКонтекстноеМенюСоздатьНаОснованииРеализацияТоваровУслуг и присвоем ей, ранее созданную команду СоздатьНаОснованииРеализацияТоваровУслуг. Последняя процедура СоздатьНаОсновании является действием команды СоздатьНаОснованииРеализацияТоваровУслуг. Из нее передается массив документов, выделенных в форме списка, который нужно правильно обработать при заполнении документа РеализацияТоваровУслуг.

Как это будет сделано зависит от задачи, которую поставит заказчик. Может быть он захочет, чтобы из нескольких документов списка создавался один документ РеализацияТоваровУслуг, а может захочет, чтобы формировалось столько же документов РеализацияТоваровУслуг, сколько было выделено в списке. Любая постановка задачи от заказчика ложится на плечи разработчика. В данном, конкретном случае, нужно было сделать только для одного документа, все выше это как пример для тех, кому нужно реализовать с несколькими документами.

Описание обработки переноса данных

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

Если говорить об обработке для данного расширения, то ещё с помощью этой обработки были устранены проблемы, связанные с дублированием данных в регистрах сведений ДвоичныеДанныеФайлов и ФайлыВРабочемКаталоге. Дело в том, что разработчик, изменил определяемый тип ПрисоединенныйФайл, добавив к нему новый тип СправочникСсылка.битматЗаказНаТехникуПрисоединенныеФайлы. Если просто изменить определяемый тип, убрав оттуда лишний тип и попытаться сохранить конфигурацию базы данных, то это не получится, так как возникнет такая ошибка:

Записи регистра сведений стали не уникальными: ДвоичныеДанныеФайлов

ДвоичныеДанныеФайлов. Имеются записи с одинаковыми измерениями

Дело в том, что у этих двух регистров измерение Файл имеет определяемый тип ПрисоединенныйФайл. Когда происходит удаление одного из типов в определяемом типе ПрисоединенныйФайл, то некоторые записи в этих регистрах становятся дублирующими, так как раньше, до удаления типа, в измерении Файл присутствовали элементы справочника бит_мат_ЗаказНаТехникуПрисоединенныеФайлы, а теперь там появились значения Null. В обработке реализован механизм, который устраняет эту проблему.

К сожалению, на момент написания статьи, система 1С:Предприятие не поддерживает ОпределяемыйТип. Только начиная с версии «1С:Предприятие 8.3.20», расширения будут поддерживать изменение определяемых типов.

Кроме того, в документе бит_мат_ЗаказНаТехнику в реквизите ОтветственноеЛицо был изменён тип. Раньше был СправочникСсылка.ФизическиеЛица, а стал СправочникСсылка.Пользователи. Поэтому в расширение был добавлен новый реквизит Заказ_ОтветственноеЛицо. Чтобы перенести данные в новый реквизит в обработке был сформирован определенный механизм.

Обработку нужно запускать дважды. Первый раз после установки и сохранения новых структур данных расширения, а второй раз после удаления старых данных из конфигурации и установки ее на «замок».

Добавление дополнительных отчетов в расширение

Для получения сводной информации о движениях в новом регистре накопления бит_ВзаиморасчетыСКонтрагентом были созданы два отчета. Чтобы перенести эти отчеты нужно было сначала сохранить их в расширение, потом менять запрос СКД. Если так не сделать, а изменять их как внешние отчеты, то при открытии схемы компоновки данных будет выдаваться ошибка о невозможности найти некоторые данные. Находясь в расширении отчет видит структуры данных, как конфигурации, так и расширения. Какую информацию показывают эти два отчета можно посмотреть на видео ниже.

Демонстрация доработок, перенесенных в расширение

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

09.06.2017

Расширение данных

Реализовано в версии 8.3.11.2867.

Теперь с помощью расширений конфигурации вы можете добавлять к прикладному решению собственные структуры для хранения данных: справочники, документы, регистры сведений.

В расширении вы добавляете (или модифицируете) соответствующий объект конфигурации. При загрузке расширения, «на лету», выполняется реструктуризация базы данных, и, перезапустив сеанс, вы сразу же можете заполнять новые структуры своими данными.

Что мы сделали

Можно сказать, что это самая сложная и самая ожидаемая доработка механизма расширений. Мы доработали механизм расширений таким образом, что теперь вы можете добавить в прикладное решение объекты или реквизиты, данные которых будут сохранены в информационной базе. Раньше вы могли дорабатывать прикладное решение, но расширение не влияло на структуру хранимых данных. Теперь с помощью расширений вы можете изменить и структуру данных тоже.

Вы можете добавлять собственные:

• Справочники;
• Документы;
• Регистры сведений;
• Планы обмена.

Кроме этого к справочникам и документам прикладного решения вы можете добавить собственные:

• Реквизиты;
• Табличные части;
• Реквизиты табличных частей.

Как это устроено физически

Чтобы не усложнять, рассмотрим основные принципы работы этого механизма на примере справочника.

Если расширение добавляет собственный справочник, то для него создаётся новая таблица в базе данных. В этом случае всё просто и очевидно.

Сложнее обстоят дела, когда расширение модифицирует уже существующую структуру данных. Если расширение добавляет собственный реквизит к справочнику прикладного решения, то для этого справочника создаётся отдельная таблица с новой структурой (с дополнительной колонкой для нового реквизита). Будем называть её расширенная таблица. В неё переносятся данные из старой таблицы справочника. В дальнейшем все обращения к этому справочнику будут переадресовываться к расширенной таблице.

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

Если прикладное решение использует разделение данных, и расширение применяется к одной рабочей области, то в расширенную таблицу будут копироваться только те данные справочника, которые относятся к этой области. На рисунке расширенная таблица называется _REFERENCE1X, оранжевым цветом обозначена колонка, добавленная расширением.

В этой рабочей области обращение к данным справочника будет переадресовываться к расширенной таблице. А для остальных областей, для которых не применялось расширение, все обращения к данным будут адресоваться к старой, исходной таблице справочника _REFERENCE1.

Из такой реализации вытекает одно ограничение, которое, на наш взгляд, не должно существенно помешать вам использовать новые возможности.

Если расширение, модифицирующее структуру данных, вы хотите применять к отдельным областям, то все объекты прикладного решения, которые модифицируются расширением, должны разделяться только «независимо».

Если же вы хотите модифицировать и те объекты, которые разделяются «независимо и совместно», то в этом случае вам не удастся применить расширение только к одной области. Его надо будет применить ко всей базе, ко всем областям сразу. Для этого нужно указать, что разделение данных на расширения «не действует» (свойство общего реквизита Разделение расширений конфигурации = Не использовать).

Дальше рассмотрим несколько ситуаций, которые могут возникнуть после того, как вы применили к прикладному решению расширение, модифицирующее структуру данных.

Изменение расширяемой конфигурации

Итак, в базе данных появились расширенные таблицы. Но после этого конфигурация прикладного решения изменилась. Что будет происходить при реструктуризации базы данных?

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

Невозможность применения расширения

Другая ситуация — пользователи поработали, заполнили расширенные таблицы данными. После этого конфигурация прикладного решения изменилась, и при очередном запуске расширение не применилось. Что будет с данными в расширенных таблицах?

Самое главное – данные никуда не исчезнут, они останутся в таблицах. А вот способы работы с этими таблицами могут быть разными.

Самый простой случай, если расширение добавляло собственный справочник. Тогда мы оказываемся в ситуации, когда таблица есть, а метаданных, которые её описывают, нет. В этом случае данные просто будут недоступны. До тех пор, пока не будет решена проблема с применением расширения.

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

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

Удаление расширения

Раньше вы могли спокойно удалять расширения из информационной базы. Это не имело никаких последствий для данных, так как расширения привносили только свою функциональность.

Теперь удаление расширений становится ответственной операцией. Потому что при удалении расширения из базы данных будут удалены и все данные, которые содержатся в структурах, добавленных расширением.

При этом если получается так, что конечная структура таблиц полностью описывается конфигурацией прикладного решения, будет выполнена и «обратная» реструктуризация. То есть данные из расширенных таблиц будут скопированы обратно в исходные таблицы объектов, а сами расширенные таблицы будут удалены.

Загрузка, применение и реструктуризация

Как вы понимаете, результатом использования новых возможностей расширения должна стать база данных с новыми таблицами. Процесс изменения структуры таблиц базы данных (реструктуризация) обычно, раньше, выполнялся только в конфигураторе. В тот момент, например, когда вы нажимали кнопку Обновить конфигурацию базы данных.

Теперь ситуация меняется. Расширения могут подключаться как в конфигураторе, так и в режиме работы 1С:Предприятие. Если при этом требуется изменить структуру таблиц, то в том же режиме будет выполняться и реструктуризация. И для её выполнения требуется монопольный режим.

Если вы работаете с неразделённой базой, то будет установлена монопольная блокировка всей базы. А если база использует режим разделения данных, то будет установлена монопольная блокировка той области, в которую загружается расширение.

При работе в конфигураторе реструктуризация, как и раньше, выполняется в момент обновления конфигурации базы данных. То есть сначала вы загружаете (или создаёте) расширение, сохраняете его в информационной базе. А затем выполняете обновление конфигурации базы данных. В этот момент происходит реструктуризация и создание новых и расширенных таблиц.

А при работе в режиме 1С:Предприятие процессы загрузки расширения и реструктуризации базы данных совмещены, не разделяются.

То есть в момент добавления расширения, или в момент его загрузки в существующее расширение, будут выполнены следующие действия:

1. Загрузка расширения в информационную базу;
2. Проверка возможности применения расширения;
3. Анализ изменений;
4. Если на предыдущем этапе выяснилось, что нужно изменять структуру данных, то будет установлен монопольный режим;
5. Реструктуризация (если она необходима).

Если на 2 шаге окажется, что расширение применить невозможно, весь процесс будет возвращён к исходному состоянию, в том числе и загрузка расширения в информационную базу.

Реструктуризация в режиме 1С:Предприятие выглядит проще, чем в конфигураторе. Чтобы понять разницу, напомним, как это выглядело в конфигураторе раньше.

Сначала платформа анализировала изменение метаданных и готовила всё, что необходимо для последующего изменения структуры базы данных. Когда всё было готово, она отображала диалог будущих изменений, и ожидала от вас явной команды для того, чтобы всё это выполнить. Вы соглашались, и платформа начинала менять структуру базы данных. Если в этом месте происходил сбой, то оставшиеся изменения платформа выполняла при следующем запуске конфигуратора. Если реструктуризация не была завершена, а вы пытались запустить сеанс 1С:Предприятия, платформа не позволяла вам это сделать, и предлагала перейти в конфигуратор, чтобы завершить реструктуризацию.

Теперь, когда реструктуризация выполняется в режиме 1С:Предприятие, всё происходит так же, но проще. Отсутствует диалог явного принятия будущих изменений. Если в фазе подготовки никаких ошибок не возникло, платформа автоматически примет все изменения и изменит структуру базы данных. Если в фазе изменения структуры базы данных произойдёт сбой, то завершение изменений будет выполнено при следующем запуске сеанса 1С:Предприятия (или при следующем входе в область, если база в режиме разделения данных). То есть тут не требуется участие конфигуратора ни на какой стадии.

Ограничения и планы

Нужно сказать, что в описываемой версии мы сделали не всё, что хотелось сделать. Однако мы решили, что важнее выпустить то, что уже сделано, пусть даже с некоторыми ограничениями.

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

• Регистраторы регистра сведений. Заимствованному регистру нельзя назначить ни собственный, ни заимствованный регистратор (документ);
  • При этом собственному регистру можно назначить как заимствованный, так и собственный регистратор;
• При обмене в распределенной информационной базе в главном узле и в подчинённом узле должен быть одинаковый набор расширений, модифицирующих структуру данных. Автоматическая синхронизация таких расширений между узлами пока не реализована;
• В состав плана обмена (собственного или заимствованного) могут быть включены только собственные объекты расширения;

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

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

Также мы будем работать над тем, чтобы упростить создание расширений, упростить их адаптацию к изменениям прикладного решения (тот случай, когда расширение перестаёт подключаться).

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

Теги:
расширения 
8.3.11 

Теги:

Похожие темы (5)