1с добавить стандартные реквизиты в расширение
Обновлено: 16.05.2024
Механизм расширения конфигурации 1C
Как указано в описании: «Механизм расширения конфигурации – это специальный механизм, предназначенный для доработки расширяемой конфигурации без изменения этой конфигурации (в том числе без снятия с поддержки).»
Основным назначением расширения конфигурации является доработка прикладных решений (конфигураций) под нужды клиента. При этом нет необходимости в снятии дорабатываемой конфигурации с поддержки. В результате сохраняется простота сопровождения и обновления типового прикладного решения, стоящего на поддержке.
При разработке расширений следует учитывать следующие факты:
Расширение может иметь одно из следующих назначений:
Расширение создается в конфигураторе, хранится в информационной базе и может быть выгружено в файл. Для подключения расширения, сохраненного в файл, в прикладное решение нет необходимости использовать конфигуратор. Подключить расширение можно с помощью стандартного функционала (Все функции Стандартные Управление расширениями конфигурации). Подключить расширение также используя программный интерфейс, предоставляемый платформой.
Ограничения использования расширений:
Расширения конфигурации не поддерживают создание следующих собственных объектов:
Не поддерживается расширение следующих объектов:
Не поддерживается добавление реквизитов и табличных частей для:
Не поддерживается изменение структуры регистров всех видов. Поддерживается только расширение состава регистраторов.
В базовых версиях прикладных решений работа с расширениями не поддерживается.
Стоит помнить, что Механизм расширения конфигурации – это перспективный постоянно развивающийся механизм и с выходом новых версий платформ их функционал только расширяется и лишается текущих недочетов.
Как добавить расширение конфигурации 1С 8.3
Для создания расширения необходимо запустить 1С в режиме конфигуратора.
В конфигураторе необходимо зайти в меню «Конфигурация» и выбрать пункт «Расширения конфигурации». Откроется окно со списком расширений (если они есть). Далее нажмем кнопку «Добавить». Мы увидим диалоговое окно создания расширения:
Стоит отдельно выделить поле Назначение – необходимо выбрать его значение в зависимости от решаемой задачи – т.к. мы выполняем добавление объектов по требованиям конкретного заказчика – нам подойдет вариант «Адаптация».
Добавим в расширение справочник Категория должности по Классификатору Предприятия. Стоит обратить внимание, что в название всех объектов процедур и функций созданных в расширении, добавляется его префикс (в нашем случае Расш1_);
Разместим наш новый Справочник в Подсистеме «ШтатноеРасписание» для этого необходимо добавить эту подсистему в Расширение – Перейдем в дерево основной Конфигурации и нажмем правой кнопкой мыши на строке с нужной подсистемой и выберем пункт «Добавить в расширение».
Теперь мы можем управлять ее составом, добавим наш новый объект в подсистему.
Далее добавим в расширение Справочник Должности и добавим для него новый реквизит КатегорияДолжности с типом СправочникСсылка.Расш1_КатегорияДолжностиПоКлассификаторуПредприятия
Далее необходимо решить задачу с выводом реквизита КатегорияДолжности на форму Справочника Должности, реализовать это можно двумя способами:
Останавливаться на плюсах и минусах каждого решения не будем, а ниже рассмотрим оба варианта.
Интерактивное изменение Формы в расширении.
Для того чтобы вывести Реквизит на форму интерактивно: необходимо добавить саму Форму «ФормаЭлемента» в расширение. Обращу ваше внимание на следующий момент – для того чтобы появилась возможность Интерактивного добавления Реквизита объекта на форму необходимо сам Объект тоже добавить в расширение.
Далее добавим новый Реквизит в подходящую Группу на форме.
Запустив 1С в режиме Предприятия убедимся, что новый Справочник появился в интерфейсе
А открыв элемент справочника Должности, увидим, что добавляемый реквизит Категория должности также в нужном месте.
Программное изменение Формы в расширении.
Для того чтобы программно добавить элемент на форму нам необходимо определится в каком месте это сделать оптимально с точки зрения простоты дальнейшей поддержки и обновления конфигурации.
Предлагаю воспользоваться одной из процедур вызываемых в обработчике Формы «ПриСозданииНаСервере», в которую передается наша Форма в качестве параметра например УправлениеСвойствами.ПриСозданииНаСервере.
Перейдем в Общий модуль УправлениеСвойствами где находится данная процедура, и кликнем правой кнопкой мыши по процедуре ПриСозданииНаСервере. В выпадающем меню выберем пункт «Добавить в расширение»
Система предложит нам выбрать одну из аннотаций, подробнее о каждой из них рассмотрим в следующих публикациях, а сейчас выберем «Вызывать после»
Далее в добавленную процедуру поместим следующий код:
Готовое расширение можно выгрузить в файл перейдя в конфигураторе в меню «Конфигурация» и выбрать пункт «Расширения конфигурации». В открывшемся списке расширений по правой кнопкой мыши можно вызвать выпадающее меню, либо выбрать пункт командной панели «Конфигурация» и выбрать пункт «Сохранить конфигурацию в файл…». На выходе мы получим Файл типа *.cfe который можно передать заказчику.
Таким образом, мы научились создавать собственные расширения на примере конкретного кейса.
ТС задает достаточно абстрактный вопрос, на который можно абстрактно ответить и да и нет.
На практике нужно уточнять тип исходного объекта, к которому с помощью расширения собрался еще один реквизит допиливать.
В зависимости от используемой конфигурации может быть гораздо безопасней использовать штатную возможность для добавления доп реквизита, но расписать с помощью расширения обработку для добавленных данных
(0) Если отключат расширение, то реквизит останется на месте. Если удалят расширение, то потеряется.
В расширении или в конфигурации - зависит от использования. Если добавляемый реквизит нужен для расширения, то можно в расширении. Если во внешних ПФ, например, то либо втыкать проверку на наличие реквизита, т.к. расширение могут удалить, либо добавлять реквизит в конфу.
Я расцениваю расширение как временные модификации. Поэтому не использую временное в постоянном. Как-то так.
(19) Визуально удобная доработка форм через расширения пади
(21) Вся эта визуально удобная доработка слетает после обновления.
(17) на неделе столкнулся со следующей ситуацией:
Имеется типовая конфа бухгалтерии, через расширение к документу Реализации добавлена пара реквизитов и программно выведена на форму
После обновления (и сопутствующей ему реструктуризации таблиц) документы Реализации пропали из журнала операций (общий журнал документов). Т.е. в базе они есть, в собственной форме списка отображаются, а в журнале операций пропали. Перепроведение существующих документов не помогает, но при создании новых они отображаются в журнале.
Проблема ушла после удаления добавленных через расширение реквизитов и реструктуризации таблиц базы.
Платформа 8.3.13.1644. Бухгалтерия последнего релиза крутящаяся на MS SQL Server
В качестве эксперимента взял другую бух.базу, копию в файловом варианте, добавил произвольный реквизит в Реализацию и реструктуризировал таблицы. тот же эффект, существующие реализации исчезли из журнала операций.
(24) они не пропали, а просто надо было дать права на новые реквизиты при переходе на версию 8.3.14 и выше
(26) версия 8.3.13
права на новые реквизиты влияют на отображение самих реквизитов, но не объектов владельцев
кроме того, в журнале не отображаются ранее созданные документы, а вновь созданные в него попадают
на мой взгляд, вопрос исключительно в некорректной работе реструктуризации таблиц при использовании добавленных в расширение реквизитов
Данная статья является анонсом новой функциональности.
Не рекомендуется использовать содержание данной статьи для освоения новой функциональности.
Полное описание новой функциональности будет приведено в документации к соответствующей версии.
Полный список изменений в новой версии приводится в файле v8Update.htm.
Реализовано в версии 8.3.11.2867.
Теперь с помощью расширений конфигурации вы можете добавлять к прикладному решению собственные структуры для хранения данных: справочники, документы, регистры сведений.
В расширении вы добавляете (или модифицируете) соответствующий объект конфигурации. При загрузке расширения, «на лету», выполняется реструктуризация базы данных, и, перезапустив сеанс, вы сразу же можете заполнять новые структуры своими данными.
Что мы сделали
Можно сказать, что это самая сложная и самая ожидаемая доработка механизма расширений. Мы доработали механизм расширений таким образом, что теперь вы можете добавить в прикладное решение объекты или реквизиты, данные которых будут сохранены в информационной базе. Раньше вы могли дорабатывать прикладное решение, но расширение не влияло на структуру хранимых данных. Теперь с помощью расширений вы можете изменить и структуру данных тоже.
Вы можете добавлять собственные:
- Справочники;
- Документы;
- Регистры сведений;
- Планы обмена.
Кроме этого к справочникам и документам прикладного решения вы можете добавить собственные:
- Реквизиты;
- Табличные части;
- Реквизиты табличных частей.
Как это устроено физически
Чтобы не усложнять, рассмотрим основные принципы работы этого механизма на примере справочника.
Если расширение добавляет собственный справочник, то для него создаётся новая таблица в базе данных. В этом случае всё просто и очевидно.
Сложнее обстоят дела, когда расширение модифицирует уже существующую структуру данных. Если расширение добавляет собственный реквизит к справочнику прикладного решения, то для этого справочника создаётся отдельная таблица с новой структурой (с дополнительной колонкой для нового реквизита). Будем называть её расширенная таблица. В неё переносятся данные из старой таблицы справочника. В дальнейшем все обращения к этому справочнику будут переадресовываться к расширенной таблице.
Независимо от количества расширений, модифицирующих этот справочник, расширенная таблица будет всегда одна. Её структура будет содержать изменения, добавленные всеми расширениями.
Если прикладное решение использует разделение данных, и расширение применяется к одной рабочей области, то в расширенную таблицу будут копироваться только те данные справочника, которые относятся к этой области. На рисунке расширенная таблица называется _REFERENCE1X, оранжевым цветом обозначена колонка, добавленная расширением.
В этой рабочей области обращение к данным справочника будет переадресовываться к расширенной таблице. А для остальных областей, для которых не применялось расширение, все обращения к данным будут адресоваться к старой, исходной таблице справочника _REFERENCE1.
Из такой реализации вытекает одно ограничение, которое, на наш взгляд, не должно существенно помешать вам использовать новые возможности.
Если расширение, модифицирующее структуру данных, вы хотите применять к отдельным областям, то все объекты прикладного решения, которые модифицируются расширением, должны разделяться только «независимо».
Если же вы хотите модифицировать и те объекты, которые разделяются «независимо и совместно», то в этом случае вам не удастся применить расширение только к одной области. Его надо будет применить ко всей базе, ко всем областям сразу. Для этого нужно указать, что разделение данных на расширения «не действует» (свойство общего реквизита Разделение расширений конфигурации = Не использовать).
Дальше рассмотрим несколько ситуаций, которые могут возникнуть после того, как вы применили к прикладному решению расширение, модифицирующее структуру данных.
Изменение расширяемой конфигурации
Итак, в базе данных появились расширенные таблицы. Но после этого конфигурация прикладного решения изменилась. Что будет происходить при реструктуризации базы данных?
Все расширенные таблицы также будут реструктуризироваться. Общая стратегия заключается в том, что все расширенные таблицы должны обновиться до нового состояния расширяемой конфигурации. При этом если в процессе их обновления возникнут ошибки, вызванные исключительно изменениями основной конфигурации, то информация об этом будет выдана так же, как и раньше.
Невозможность применения расширения
Другая ситуация - пользователи поработали, заполнили расширенные таблицы данными. После этого конфигурация прикладного решения изменилась, и при очередном запуске расширение не применилось. Что будет с данными в расширенных таблицах?
Самое главное – данные никуда не исчезнут, они останутся в таблицах. А вот способы работы с этими таблицами могут быть разными.
Самый простой случай, если расширение добавляло собственный справочник. Тогда мы оказываемся в ситуации, когда таблица есть, а метаданных, которые её описывают, нет. В этом случае данные просто будут недоступны. До тех пор, пока не будет решена проблема с применением расширения.
Более интересная ситуация получается тогда, когда расширение модифицировало существующий справочник. В этом случае мы имеем расширенную таблицу и метаданные (из конфигурации), которые описывают только часть этой таблицы. В такой ситуации данные, находящиеся в колонках, добавленных расширением, также будут недоступны. Но остальные данные можно будет прочитать.
Однако запись в этот справочник будет недоступна. До тех пор, пока не будет решена проблема с применением расширения. То есть до тех пор, когда у платформы не появится полный набор метаданных, описывающих эту таблицу.
Удаление расширения
Раньше вы могли спокойно удалять расширения из информационной базы. Это не имело никаких последствий для данных, так как расширения привносили только свою функциональность.
Теперь удаление расширений становится ответственной операцией. Потому что при удалении расширения из базы данных будут удалены и все данные, которые содержатся в структурах, добавленных расширением.
При этом если получается так, что конечная структура таблиц полностью описывается конфигурацией прикладного решения, будет выполнена и «обратная» реструктуризация. То есть данные из расширенных таблиц будут скопированы обратно в исходные таблицы объектов, а сами расширенные таблицы будут удалены.
Загрузка, применение и реструктуризация
Как вы понимаете, результатом использования новых возможностей расширения должна стать база данных с новыми таблицами. Процесс изменения структуры таблиц базы данных (реструктуризация) обычно, раньше, выполнялся только в конфигураторе. В тот момент, например, когда вы нажимали кнопку Обновить конфигурацию базы данных.
Теперь ситуация меняется. Расширения могут подключаться как в конфигураторе, так и в режиме работы 1С:Предприятие. Если при этом требуется изменить структуру таблиц, то в том же режиме будет выполняться и реструктуризация. И для её выполнения требуется монопольный режим.
Если вы работаете с неразделённой базой, то будет установлена монопольная блокировка всей базы. А если база использует режим разделения данных, то будет установлена монопольная блокировка той области, в которую загружается расширение.
При работе в конфигураторе реструктуризация, как и раньше, выполняется в момент обновления конфигурации базы данных. То есть сначала вы загружаете (или создаёте) расширение, сохраняете его в информационной базе. А затем выполняете обновление конфигурации базы данных. В этот момент происходит реструктуризация и создание новых и расширенных таблиц.
А при работе в режиме 1С:Предприятие процессы загрузки расширения и реструктуризации базы данных совмещены, не разделяются.
То есть в момент добавления расширения, или в момент его загрузки в существующее расширение, будут выполнены следующие действия:
- Загрузка расширения в информационную базу;
- Проверка возможности применения расширения;
- Анализ изменений;
- Если на предыдущем этапе выяснилось, что нужно изменять структуру данных, то будет установлен монопольный режим;
- Реструктуризация (если она необходима).
Если на 2 шаге окажется, что расширение применить невозможно, весь процесс будет возвращён к исходному состоянию, в том числе и загрузка расширения в информационную базу.
Реструктуризация в режиме 1С:Предприятие выглядит проще, чем в конфигураторе. Чтобы понять разницу, напомним, как это выглядело в конфигураторе раньше.
Сначала платформа анализировала изменение метаданных и готовила всё, что необходимо для последующего изменения структуры базы данных. Когда всё было готово, она отображала диалог будущих изменений, и ожидала от вас явной команды для того, чтобы всё это выполнить. Вы соглашались, и платформа начинала менять структуру базы данных. Если в этом месте происходил сбой, то оставшиеся изменения платформа выполняла при следующем запуске конфигуратора. Если реструктуризация не была завершена, а вы пытались запустить сеанс 1С:Предприятия, платформа не позволяла вам это сделать, и предлагала перейти в конфигуратор, чтобы завершить реструктуризацию.
Теперь, когда реструктуризация выполняется в режиме 1С:Предприятие, всё происходит так же, но проще. Отсутствует диалог явного принятия будущих изменений. Если в фазе подготовки никаких ошибок не возникло, платформа автоматически примет все изменения и изменит структуру базы данных. Если в фазе изменения структуры базы данных произойдёт сбой, то завершение изменений будет выполнено при следующем запуске сеанса 1С:Предприятия (или при следующем входе в область, если база в режиме разделения данных). То есть тут не требуется участие конфигуратора ни на какой стадии.
Ограничения и планы
Нужно сказать, что в описываемой версии мы сделали не всё, что хотелось сделать. Однако мы решили, что важнее выпустить то, что уже сделано, пусть даже с некоторыми ограничениями.
На текущий момент существенные, на наш взгляд, ограничения выглядят так:
- Регистраторы регистра сведений. Заимствованному регистру нельзя назначить ни собственный, ни заимствованный регистратор (документ);
- При этом собственному регистру можно назначить как заимствованный, так и собственный регистратор;
Эти ограничения мы планируем устранять, в ближайшее время мы будем работать в этом направлении.
Кроме этого мы планируем увеличить набор объектов конфигурации, которые можно дорабатывать с помощью расширений.
Также мы будем работать над тем, чтобы упростить создание расширений, упростить их адаптацию к изменениям прикладного решения (тот случай, когда расширение перестаёт подключаться).
Помимо этого мы готовы принимать ваши пожелания, анализировать их, и учитывать. В настоящий момент существует довольно широкий спектр задач и направлений для дальнейшего развития, поэтому своими пожеланиями вы можете повысить приоритет тех или иных задач в нашей будущей работе. Прежде всего, нам хотелось бы увидеть пожелания, основанные на реальной практике создания и использования расширений.
Меня очень часто спрашивают, как добавить таблицу к документу или справочнику?
И действительно, как сделать такую задачу не усложняя дальнейшее обновление конфигурации? И вроде есть доп. реквизиты и доп. сведения, но почему же они не могут принимать тип таблицы значений?В итоге чаще всего используется 2 варианта:
![]()
1. Простой способ. Прямо в объекте добавляется таблица, а затем либо программно либо жестко(вручную) выводится на форму.
Минусы. Обновление конфигурации будет требовать соблюдения изменений и повышенной внимательности, чтобы не потерять эти изменения.
Плюсы. Самый простой вариант для разработки, к таблице значений можно обращаться без танцев с бубном, например через запросы.![]()
2. Нормальный вариант, но тоже с доработкой конфигурации.
Добавляется объект с таблицей значений и реквизитом с ссылкой на объект родитель, данная таблица значений выводится, к примеру, через расширение конфигурации на форму основного объекта.
Плюсы. Простое обновление, к таблице значений можно обращаться, например через запросы.
Минусы. Требуется больше предусмотреть различные ограничения на созданный объект а, следовательно, требует определенных знаний. Возможно, потребуется добавление роли\ей и настройки профилей пользователей.Есть, конечно, еще другие варианты к примеру с хранилищем, но статья не об этом…
Статья, о том, как все-таки хранить таблицу значений в доп. реквизитах, ну или в доп. сведениях.Уже более полугода держу в голове этот способ, но ни разу его не применял. Вот, наконец, добрались руки. Я не утверждаю, что никто не придумывал данный способ, но на подобное решение я не натыкался. Заранее скажу, вариант не идеален, и сгодится только под определенные задачи.
Самый главный минус это то, что будет использоваться строка неограниченной длины а, следовательно, с поиском в ней будут определенные сложности. Самый главный плюс, объекты в конфигурации не правятся.
Пример продемонстрирую на конфигурации Документооборот 2.1.6.8. Буду использовать дополнительный реквизит, но можно использовать дополнительные сведения. Весь код будет написан в Расширении конфигурации.
Задача:
Сразу говорю задачка больше шуточная для демонстрации метода. Например, нам понадобилось добавить табличную часть «Адекватность контактных лиц», она должна присутствовать в справочнике Контрагенты и содержать колонки: Контактное лицо, Совет (некая рекомендация по общению с контактным лицом), Тип контакта.1 Добавляем доп. реквизит и называем его к примеру «ТЗ_АдекватностьКонтактныхЛиц».
Я этот реквизит делаю общим для всех видов контрагентов. Тип его будет строка неограниченной длины.![]()
2 Создаем Расширение конфигурации и Дорабатываем форму Контрагентов.
Добавляем реквизиты формы:— «ДопТЗ» тип ПланВидовХарактеристикСсылка.ДополнительныеРеквизитыИСведения
— ТЗ_АдекватностьКонтактныхЛиц тип ТаблицаЗначений:
КонтактноеЛицо тип СправочникСсылка.КонтактныеЛица
ТипКонтакта тип Строка
Совет тип Строка![]()
Добавляем на форму страницу «ГруппаАдекватностьКонтактныхЛиц» и снимаем видимость.
В данную группу выводим «ТЗ_АдекватностьКонтактныхЛиц»![]()
3 Пишем код.
ПриСозданииНаСервере. Необходимо считать сам доп реквизит напомню мы его обозвали «ТЗ_АдекватностьКонтактныхЛиц», далее прочитать его значение и построить по его значению таблицу значений.Значение доп реквизита я предлагаю хранить в формате JSON, у кого более старая платформа можно использовать XML.
ПриОткрытии. Программно прячем доп. реквизит. Он хранит JSON, поэтому пользователю особо неинтересен.
ПередЗаписьюНаСервере. Если ТЗ изменилась сохраняем ее в виде строки JSON в доп. реквизит.Читайте также:
