Добавить регистр накопления в расширение 1с

Обновлено: 07.01.2025

Обычно мы делаем расширения, чтобы не менять основную конфигурацию. Я не рекомендую менять режим совместимости конфигурации поставщика в типовых решениях. Однако если в основной конфигурации установлен режим совместимости 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.44 необходимо создать отчет, как на картинке:
Таким образом, получается, что регистр остатков можно вывести в ноль только в разрезе контрагента, но не обоих измерений. И это на экзамене считается грубой ошибкой.

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

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

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

Ответ

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

Дублировать регистратор смысла нет. Он и так хранится в регистре и доступен при получении оборотов (виртуальные таблицы Обороты , ОстаткиИОбороты регистров накопления). Это обычное поле, которое можно получить, группировать по нему, включать в итоги и т.п. Тем более здесь довольно простой случай – не требуется получать реквизиты регистратора, достаточно его стандартного представления.

В данном случае построение отчета видится с помощью использования в запросе виртуальной таблицы ОстаткиИОбороты (сразу будут и начальные и конечные остатки, приход и расход), далее – задание итогов по покупателю (контрагенту). Чтобы выбрать регистратор в конструкторе, поставьте параметр Периодичность у виртуальной таблицы в Регистратор или Авто.

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

Новые регистры накопления (РН)

В ходе адаптации под нужды заказчика потребовалось переработать типовой механизм учета НДФЛ к перечислению. Для этого понадобилась возможность создавать собственные РН, которая стала доступна в версии 8.3.13 платформы. В БСП, актуальной на тот момент, режим совместимости был только 8.3.12, поэтому его потребовалось повысить.

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

Кстати, модифицированные объекты легко отобрать прямо из дерева конфигурации с помощью кнопки-фильтра. В свежих версиях платформы (например, 8.3.15 и выше в режиме совместимости 8.3.13) эта проблема не воспроизводится.

Изменение режима совместимости

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

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

С чем сталкивались мы:

● Менялась сигнатура метода НачатьПомещениеФайла. Третий параметр в 8.3.12 мог быть простой строкой, которая шла в заголовок диалога, а в 8.3.13 должен быть объект ДиалогВыбораФайла.

Доработка модулей

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

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

Существует настройка — безопасный режим и имя профиля безопасности. Она влияет на переопределение кода в общих модулях. Если не разрешить ее для расширения, код из его общих модулей не будет срабатывать без каких-либо видимых оповещений.

Доработка форм

Механика процесса сложнее, чем кажется на первый взгляд.

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

После вычисления разницы они совмещаются с приоритетом изменений расширения — так получается результирующая форма.

Проблемы, к которым может привести алгоритм

Во-первых, вычисление разниц требует времени, и на больших сложных формах типа РМК возможно существенное замедление.

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

Подходы к доработке форм

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

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

Отчеты и печатные формы

Для подключения отчетов расширения к подсистеме БСП «Варианты отчетов» нужно по сути два действия:

1. Подключить отчет к хранилищу вариантов, предварительно захватив его в расширение (это актуально для ЗУП, где в корне основной конфигурации не проставлено свойство хранилища вариантов).

2. Описать подключаемые варианты кодом в менеджере отчета функцией НастроитьВариантыОтчета().

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

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

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

Решение: подготовка текста запроса или схемы СКД в пользовательском режиме в консоли запроса или СКД. Результат можно загрузить в конфигурацию, и он будет исполняться корректно (не работает только конструктор).

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

Ограничения расширений

Несколько существенных ограничений технологии, с которыми мы столкнулись на проекте.

Планы обмена. В версии 8.3.13 они практически полноценные: можно создавать свои, в заимствованных менять состав, добавлять и заимствованные и собственные объекты. Но в версии платформы 8.3.13.1644 это не работало: таблицы изменений для собственных добавленных объектов метаданных не создавались, в конструкторе запросов тоже не было таблиц изменений.

Решение простое, но требует вмешательства в основную конфигурацию: создаем пустышку плана обмена — только сам объект с требуемым именем — захватываем в расширение. Остальное: реквизиты и ТЧ, состав, макеты и прочее — можно настроить в расширении.

Кстати, в 8.3.15 даже с режимом совместимости 8.3.13 работает корректно.

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

Нельзя создавать в расширении регламентные задания (альтернатив нет вплоть до 8.3.18). Варианты решения: метод пустышек или внешний отчет, подключаемый к подсистеме БСП с типом команды ВызовСерверногоМетода (для него из стандартного интерфейса есть возможность настройки расписания).

Версионирование

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

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

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

Заключение

● Технология достигла зрелости. В продуктивной среде проблем стабильности и производительности нет.

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

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

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

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

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