Добавить журнал документов в расширение 1с

Обновлено: 07.07.2024

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

На мой взгляд, самое главное новшество в механизме расширений конфигурации это возможность в расширении конфигурации создавать собственные объекты – документы, справочники, планы счетов обмена и регистры сведений. А так же возможность создавать у заимствованных документов и справочников собственные табличные части и реквизиты. Исследуем эти новые возможности, для реализации примеров, я буду использовать конфигурацию 1С «Управляемое приложение».

У конфигурации должен стоять режим совместимости «Не использовать», так же как и у расширения.

Для этого создадим в конфигурации «Управляемое приложение» подсистему «Учет автомобилей» со следующими объектами

Справочники: Марки автомобилей, Автомобили, Гаражи

Документы: Прибытие в гараж, Выбытие из гаража.

Создадим новое расширение, которое назовем «Учет автомобилей», назначение этого расширения будет «Дополнение».

Добавим в новое расширение собственную картинку, в которую загрузим иконку автомобиля

Теперь создадим новую подсистему, которую назовем «Учет автомобилей», в этой подсистеме отметим флаг «Включать в командный интерфейс» и в свойстве «Картинка» укажем нашу новую иконку.

Создадим справочники: МаркиАвтомобилей, Автомобили (будет реквизит Марка с типом ссылка на справочник МаркиАвтомобилей) и Гаражи.

Создать новый справочник в расширении конфигурации легко, все делается точно так же как и в обычной конфигурации: выделяется ветка справочники, вызывается контекстное меню, в котором нужно кликнуть на пункт «Добавить»

Точно так же создадим новые документы: Прибытие автомобиля и Выбытие автомобиля.

Включим все наши новые объекты в подсистему.

Теперь запустим нашу конфигурацию и посмотрим на новую подсистему

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

Для этого заимствуем справочник Контрагент в расширение.

Добавим для заимствованного справочника новый реквизит, который назовем Автомобиль.

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

И добавить на заимствованную форму реквизит расширения.

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

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

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

Очень доступный и понятный язык изложения
Книга посылается на электронную почту в формате PDF. Можно открыть на любом устройстве!
Поймете идеологию управляемого приложения 1С
Узнаете, как разрабатывать управляемое приложение;
Научитесь разрабатывать управляемые формы 1С;
Сможете работать с основными и нужными элементами управляемых форм
Программирование под управляемым приложением станет понятным

Если Вам помог этот урок решить какую-нибудь проблему, понравился или оказался полезен, то Вы можете поддержать мой проект, перечислив любую сумму:

можно оплатить вручную:

Вступайте в мои группы:

3 thoughts on “ Новые возможности расширений в платформе 1С 8.3.11 ”

Это следует читать как конфигурация должна работать с 8.3.11 и выше.

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

Использование констант в расширениях недопустимо в режиме совместимости 8.3.15 и ниже
При проверке метаданных обнаружены ошибки!
Операция не может быть выполнена.

На сегодняшний день в расширении конфигурации не поддерживается создание следующих собственных объектов:

Общие реквизиты.
Регламентные задания.
Определяемые типы.
Хранилища настроек.
Языки.
Журналы документов.
Бизнес-процессы и задачи.
Внешние источники данных.

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

Новые возможности расширения конфигурации в последних версиях технологической платформы 1С.

Версия 8.3.18

Реализована возможность расширять типы реквизитов заимствованных объектов, кроме:
1. типов общих реквизитов;
2. реквизитов с типами внешних источников данных;
3. реквизитов, имеющие определяемый тип;
4. реквизит Тип плана видов характеристик.
В документации данное изменение описано здесь.

Версия 8.3.17

Реализована возможность заимствования подписок на события и создания собственных подписок в расширении.
В документации данное изменение описано здесь и здесь.

Версия 8.3.16

Реализована возможность создания в расширении конфигурации:
1. констант;
2. функциональных опций и параметров функциональных опций;
3. критериев отбора.
Реализована возможность расширения:
1. состава заимствованных функциональных опций (собственными и заимствованными объектами);
2. состава заимствованных критериев отбора реквизитами собственных объектов расширения.
В документации данное изменение описано здесь, здесь и здесь.

Версия 8.3.15

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

Версия 8.3.14

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

Версия 8.3.13

В расширении конфигурации реализована возможность создания следующих собственных объектов:
1. планы видов характеристик;
2. планы счетов;
3. планы видов расчета;
4. регистры накопления;
5. регистры бухгалтерии;
6.регистры расчета.

Для собственных регистров накопления не поддерживается создание агрегатов.
Реализована возможность включать собственные регистры любого вида в состав движений собственных и заимствованных документов расширения.

В документации данное изменение описано здесь.

Версия 8.3.12

Реализована возможность управлять областью действиярасширения конфигурации и активностью установленных расширений. Областью действия расширения может быть или текущая область данных или вся информационная база.
Управление активностью позволяет отключить расширение, не удаляя его из информационной базы.
Для объекта РасширениеКонфигурации реализованы свойства ОбластьДействия и Активно.
Изменен порядок подключения расширений: в первую очередь подключаются расширения, имеющие областью действия всю информационную базу.
В документации данное изменение описано здесь, здесь и здесь.

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

В документации данное изменение описано здесь.

Версия 8.3.11

Реализована возможность добавлять в расширение конфигурации ;

справочники,
документы,
планы обмена
регистры сведений.

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

Данная статья является анонсом новой функциональности.
Не рекомендуется использовать содержание данной статьи для освоения новой функциональности.
Полное описание новой функциональности будет приведено в документации к соответствующей версии.
Полный список изменений в новой версии приводится в файле v8Update.htm.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Регистраторы регистра сведений. Заимствованному регистру нельзя назначить ни собственный, ни заимствованный регистратор (документ);
- При этом собственному регистру можно назначить как заимствованный, так и собственный регистратор;
Эти ограничения мы планируем устранять, в ближайшее время мы будем работать в этом направлении.

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

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

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

Работа с журналами документов

В данном разделе будут рассмотрены особенности работы с журналами документов и даны некоторые рекомендации по их разработке.

Журнал документов как вторичные данные

Основной особенностью журналов документов в 1С:Предприятии 8.1 является то, что журналы - вторичные данные не несущие никакой первичной информации и представляющие собой не более чем еще одно представление списка документов. Эта особенность журналов документов и определяет их поведение.

При реструктуризации

Таблица журнала документов имеет следующий состав полей:
"Ссылка" - ссылка на регистрируемый в журнале документ; "Номер" - номер регистрируемого документа, поле существует, если хоть один из регистрируемых документов имеет номер с длиной отличной от нуля; "ПометкаУдаления" - пометка удаления регистрируемого документа; "Проведен" - пометка проведенности регистрируемого документа; Поля, соответствующие графам документа - содержимое соответствующих реквизитов регистрируемых документов.
При сохранении конфигурации информационной базы, реструктуризация журналов документов выполняется в тех случаях, когда:
Изменяется состав граф журнала документов или состав включенных в графы реквизитов документов; В журнал включается еще один существовавший ранее вид документов; Изменяется тип или длина номера документа, включенного в журнал; Изменяется тип реквизита документа, включенного в одну из граф документа; В журнал включается вид документов, созданный при текущем сеансе конфигурирования.
Первые три случая реструктуризации возникают при манипуляциях с самим журналом или подчиненными ему объектами конфигурации - графами журнала.

Случаи 4 и 5 возникают при манипуляциях с документами, включенными в журнал и тоже вполне объяснимы.

Реструктуризация журнала из-за добавления в него нового для данной конфигурации документа (т.е. такого, по которому пока еще нет данных) на первый взгляд не нужна и требует некоторого комментария. Действительно, изменения данных в журнале документов при таких обстоятельствах не требуется, но следует учитывать влияние каждого включенного в журнал документа на тип поля "Номер", тип поля "Ссылка" и, возможно, тип полей, соответствующих графам журнала.

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

При тестировании и исправлении информационной базы

Действия, которые выполняются при тестировании и исправлении журнала документов также следует из его "вторичности". Проверяется соответствие записей журнала и записей таблиц документов. При этом, если данные рассогласованы, то при исправлении информационной базы выполняется "дозаполнение" журналов по таблицам документов и, наоборот, удаление записей журнала, которые не соответствуют таблицам документов.

При записи документов

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

Во всех этих случаях также выполняется "перерегистрация" во всех журналах документов, в которых регистрируется документ.

Удаление документов, разумеется, также будет выполняться с удалением в той же транзакции соответствующих записей журналов документов.

Рекомендации по конфигурированию

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

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

Оптимизация отбора по графам журнала

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

Описанные в данном разделе особенности имеют отношение к реализации журналов документов в версии программы 8.0.10 и более поздних версиях.

Читайте также: