Добавить регистр накопления в расширение 1с
Данная статья является анонсом новой функциональности.
Не рекомендуется использовать содержание данной статьи для освоения новой функциональности.
Полное описание новой функциональности будет приведено в документации к соответствующей версии.
Полный список изменений в новой версии приводится в файле v8Update.htm.
Реализовано в версии 8.3.11.2867.
Теперь с помощью расширений конфигурации вы можете добавлять к прикладному решению собственные структуры для хранения данных: справочники, документы, регистры сведений.
В расширении вы добавляете (или модифицируете) соответствующий объект конфигурации. При загрузке расширения, «на лету», выполняется реструктуризация базы данных, и, перезапустив сеанс, вы сразу же можете заполнять новые структуры своими данными.
Что мы сделали
Можно сказать, что это самая сложная и самая ожидаемая доработка механизма расширений. Мы доработали механизм расширений таким образом, что теперь вы можете добавить в прикладное решение объекты или реквизиты, данные которых будут сохранены в информационной базе. Раньше вы могли дорабатывать прикладное решение, но расширение не влияло на структуру хранимых данных. Теперь с помощью расширений вы можете изменить и структуру данных тоже.
Вы можете добавлять собственные:
- Справочники;
- Документы;
- Регистры сведений;
- Планы обмена.
Кроме этого к справочникам и документам прикладного решения вы можете добавить собственные:
- Реквизиты;
- Табличные части;
- Реквизиты табличных частей.
Как это устроено физически
Чтобы не усложнять, рассмотрим основные принципы работы этого механизма на примере справочника.
Если расширение добавляет собственный справочник, то для него создаётся новая таблица в базе данных. В этом случае всё просто и очевидно.
Сложнее обстоят дела, когда расширение модифицирует уже существующую структуру данных. Если расширение добавляет собственный реквизит к справочнику прикладного решения, то для этого справочника создаётся отдельная таблица с новой структурой (с дополнительной колонкой для нового реквизита). Будем называть её расширенная таблица. В неё переносятся данные из старой таблицы справочника. В дальнейшем все обращения к этому справочнику будут переадресовываться к расширенной таблице.
Независимо от количества расширений, модифицирующих этот справочник, расширенная таблица будет всегда одна. Её структура будет содержать изменения, добавленные всеми расширениями.
Если прикладное решение использует разделение данных, и расширение применяется к одной рабочей области, то в расширенную таблицу будут копироваться только те данные справочника, которые относятся к этой области. На рисунке расширенная таблица называется _REFERENCE1X, оранжевым цветом обозначена колонка, добавленная расширением.
В этой рабочей области обращение к данным справочника будет переадресовываться к расширенной таблице. А для остальных областей, для которых не применялось расширение, все обращения к данным будут адресоваться к старой, исходной таблице справочника _REFERENCE1.
Из такой реализации вытекает одно ограничение, которое, на наш взгляд, не должно существенно помешать вам использовать новые возможности.
Если расширение, модифицирующее структуру данных, вы хотите применять к отдельным областям, то все объекты прикладного решения, которые модифицируются расширением, должны разделяться только «независимо».
Если же вы хотите модифицировать и те объекты, которые разделяются «независимо и совместно», то в этом случае вам не удастся применить расширение только к одной области. Его надо будет применить ко всей базе, ко всем областям сразу. Для этого нужно указать, что разделение данных на расширения «не действует» (свойство общего реквизита Разделение расширений конфигурации = Не использовать).
Дальше рассмотрим несколько ситуаций, которые могут возникнуть после того, как вы применили к прикладному решению расширение, модифицирующее структуру данных.
Изменение расширяемой конфигурации
Итак, в базе данных появились расширенные таблицы. Но после этого конфигурация прикладного решения изменилась. Что будет происходить при реструктуризации базы данных?
Все расширенные таблицы также будут реструктуризироваться. Общая стратегия заключается в том, что все расширенные таблицы должны обновиться до нового состояния расширяемой конфигурации. При этом если в процессе их обновления возникнут ошибки, вызванные исключительно изменениями основной конфигурации, то информация об этом будет выдана так же, как и раньше.
Невозможность применения расширения
Другая ситуация - пользователи поработали, заполнили расширенные таблицы данными. После этого конфигурация прикладного решения изменилась, и при очередном запуске расширение не применилось. Что будет с данными в расширенных таблицах?
Самое главное – данные никуда не исчезнут, они останутся в таблицах. А вот способы работы с этими таблицами могут быть разными.
Самый простой случай, если расширение добавляло собственный справочник. Тогда мы оказываемся в ситуации, когда таблица есть, а метаданных, которые её описывают, нет. В этом случае данные просто будут недоступны. До тех пор, пока не будет решена проблема с применением расширения.
Более интересная ситуация получается тогда, когда расширение модифицировало существующий справочник. В этом случае мы имеем расширенную таблицу и метаданные (из конфигурации), которые описывают только часть этой таблицы. В такой ситуации данные, находящиеся в колонках, добавленных расширением, также будут недоступны. Но остальные данные можно будет прочитать.
Однако запись в этот справочник будет недоступна. До тех пор, пока не будет решена проблема с применением расширения. То есть до тех пор, когда у платформы не появится полный набор метаданных, описывающих эту таблицу.
Удаление расширения
Раньше вы могли спокойно удалять расширения из информационной базы. Это не имело никаких последствий для данных, так как расширения привносили только свою функциональность.
Теперь удаление расширений становится ответственной операцией. Потому что при удалении расширения из базы данных будут удалены и все данные, которые содержатся в структурах, добавленных расширением.
При этом если получается так, что конечная структура таблиц полностью описывается конфигурацией прикладного решения, будет выполнена и «обратная» реструктуризация. То есть данные из расширенных таблиц будут скопированы обратно в исходные таблицы объектов, а сами расширенные таблицы будут удалены.
Загрузка, применение и реструктуризация
Как вы понимаете, результатом использования новых возможностей расширения должна стать база данных с новыми таблицами. Процесс изменения структуры таблиц базы данных (реструктуризация) обычно, раньше, выполнялся только в конфигураторе. В тот момент, например, когда вы нажимали кнопку Обновить конфигурацию базы данных.
Теперь ситуация меняется. Расширения могут подключаться как в конфигураторе, так и в режиме работы 1С:Предприятие. Если при этом требуется изменить структуру таблиц, то в том же режиме будет выполняться и реструктуризация. И для её выполнения требуется монопольный режим.
Если вы работаете с неразделённой базой, то будет установлена монопольная блокировка всей базы. А если база использует режим разделения данных, то будет установлена монопольная блокировка той области, в которую загружается расширение.
При работе в конфигураторе реструктуризация, как и раньше, выполняется в момент обновления конфигурации базы данных. То есть сначала вы загружаете (или создаёте) расширение, сохраняете его в информационной базе. А затем выполняете обновление конфигурации базы данных. В этот момент происходит реструктуризация и создание новых и расширенных таблиц.
А при работе в режиме 1С:Предприятие процессы загрузки расширения и реструктуризации базы данных совмещены, не разделяются.
То есть в момент добавления расширения, или в момент его загрузки в существующее расширение, будут выполнены следующие действия:
- Загрузка расширения в информационную базу;
- Проверка возможности применения расширения;
- Анализ изменений;
- Если на предыдущем этапе выяснилось, что нужно изменять структуру данных, то будет установлен монопольный режим;
- Реструктуризация (если она необходима).
Если на 2 шаге окажется, что расширение применить невозможно, весь процесс будет возвращён к исходному состоянию, в том числе и загрузка расширения в информационную базу.
Реструктуризация в режиме 1С:Предприятие выглядит проще, чем в конфигураторе. Чтобы понять разницу, напомним, как это выглядело в конфигураторе раньше.
Сначала платформа анализировала изменение метаданных и готовила всё, что необходимо для последующего изменения структуры базы данных. Когда всё было готово, она отображала диалог будущих изменений, и ожидала от вас явной команды для того, чтобы всё это выполнить. Вы соглашались, и платформа начинала менять структуру базы данных. Если в этом месте происходил сбой, то оставшиеся изменения платформа выполняла при следующем запуске конфигуратора. Если реструктуризация не была завершена, а вы пытались запустить сеанс 1С:Предприятия, платформа не позволяла вам это сделать, и предлагала перейти в конфигуратор, чтобы завершить реструктуризацию.
Теперь, когда реструктуризация выполняется в режиме 1С:Предприятие, всё происходит так же, но проще. Отсутствует диалог явного принятия будущих изменений. Если в фазе подготовки никаких ошибок не возникло, платформа автоматически примет все изменения и изменит структуру базы данных. Если в фазе изменения структуры базы данных произойдёт сбой, то завершение изменений будет выполнено при следующем запуске сеанса 1С:Предприятия (или при следующем входе в область, если база в режиме разделения данных). То есть тут не требуется участие конфигуратора ни на какой стадии.
Ограничения и планы
Нужно сказать, что в описываемой версии мы сделали не всё, что хотелось сделать. Однако мы решили, что важнее выпустить то, что уже сделано, пусть даже с некоторыми ограничениями.
На текущий момент существенные, на наш взгляд, ограничения выглядят так:
- Регистраторы регистра сведений. Заимствованному регистру нельзя назначить ни собственный, ни заимствованный регистратор (документ);
- При этом собственному регистру можно назначить как заимствованный, так и собственный регистратор;
Эти ограничения мы планируем устранять, в ближайшее время мы будем работать в этом направлении.
Кроме этого мы планируем увеличить набор объектов конфигурации, которые можно дорабатывать с помощью расширений.
Также мы будем работать над тем, чтобы упростить создание расширений, упростить их адаптацию к изменениям прикладного решения (тот случай, когда расширение перестаёт подключаться).
Помимо этого мы готовы принимать ваши пожелания, анализировать их, и учитывать. В настоящий момент существует довольно широкий спектр задач и направлений для дальнейшего развития, поэтому своими пожеланиями вы можете повысить приоритет тех или иных задач в нашей будущей работе. Прежде всего, нам хотелось бы увидеть пожелания, основанные на реальной практике создания и использования расширений.
Здравствуйте. Подскажите пожалуйста.
В расширении пытаюсь доработать динамический запрос. При попытке сохранить его выдает ошибку:Ошибка получения информации набора данных
по причине:
Ошибка в запросе набора данных
по причине:
<(66, 49)>: Поле не найдено "РасчетыСКлиентамиОбороты.Регистратор.ДокументОснование.ДокументОснование"
ТОГДА РасчетыСКлиентамиОбороты.Регистратор.>ДокументОснование.ДокументОснованиеЧто нужно добавить в расширение, чтобы не было ошибки?
База Розница 2.2.10.19 - режим совместимости 8.3.10.(1) Добавить в расширение все элементы на которые ссылается само расширение - но это только в том случае если вы хотите доработать непосредственно в самом расширении динамический список - путем формирования нового текста запроса, а так это никак не повлияет на работоспособность расширения - если все отборы и запросы там написаны правильно.
(5) в Вашем случае, вы скорее всего пытаетесь изменить уже существующий запрос или отбор, который ранее где то был и работал и вы хотите его адаптировать под свои реалии но уже через расширение. Как понимаю ругается оно на регистрнакопления "Расчеты с клиентами" в этом регистре есть регистратор (их там куча на самом деле), вы. в конфигураторе открываете регистр. и выбираете регистратор и жмете. - добавить в расширение:
и еще возможно так же в расширение попросит добавить сами документы - чтоб из них получить еще ссылку на документ основание.(9) а у этого регистра есть форма? (ну мало ли, вдруг есть форма по умолчанию какая то), тогда добавь форму к себе, а затем нажми на этой форме вот эту конопочку:
(10)Такого тоже нету. Пробовал свою форму создать. Не помогло. 1с видит регистратор, но никаких его свойств не видит.
Видимо, придется программно менять запрос, кидать реквизит на форму и делать условное оформление.(9)Вы были на правильном пути. Надо было именно регистратор добавить в регистр. Но он немного по хитрому, получается нужна связка документ - регистр. И задавать ее можно через документ, а не через регистр. Добавить регистр и документ в расширении. И указать у документа движения по этому регистру. Правда не проверял, не сломается ли что нибудь потом в движениях документа?
Работать будет. А чтобы не было ошибки при сохранении - заимствовать эти реквизиты в расширение. На на работоспособность не влияет.
(2) Работать не будет. В окне динамического списка ввожу код и 1с не дает его сохранить. Добавил все реквизиты всех документов, которые называются ДокументОснование. Всё равно не работает.
Коллеги! К сожалению, не прозвучало конкретного ответа - можно ли обращаться к реквизитам регистратора в запросе, размещаемого в расширении?
У меня сейчас актуальная проблема. В расширение вношу отчёт (СКД), в котором запросом обращаюсь к реквизиту регистратора регистра накопления (РН) . К сожалению - выходит ошибка (прилагаю скрин).
Все объекты, которые могут быть регистратором РН, добавил в расширение.
Текущая платформа: 1С:Предприятие 8.3 (8.3.18.1208)
Режим совместимости конфигурации: Версия 8.3.14В этих версиях вообще такое реально делать?
А реквизит ЗаказКлиента так же добавлен в расширение у всех? Если хоть в одном типе, который объявлен регистратором, не будет в расширение этот реквизит, то соответственно и ошибка такая будет.А реквизит ЗаказКлиента так же добавлен в расширение у всех? Если хоть в одном типе, который объявлен регистратором, не будет в расширение этот реквизит, то соответственно и ошибка такая будет.
Не у всех документов, являющимися возможным регистраторов есть такой реквизит. Но там, где этот реквизит есть - в расширение добавил.
Вот, например, у АвансовыйОтчет - нет реквизита ЗаказКлиента, а у АктВыполненныхРабот - есть.
Данная статья является анонсом новой функциональности.
Не рекомендуется использовать содержание данной статьи для освоения новой функциональности.
Полное описание новой функциональности будет приведено в документации к соответствующей версии.
Полный список изменений в новой версии приводится в файле v8Update.htm.Реализовано в версии 8.3.13.1513.
Мы продолжаем развивать механизм расширений конфигурации. Теперь вы можете расширять данные, используемые для задач оперативного и бухгалтерского учёта, а также для расчёта зарплаты. Кроме этого мы увеличили возможности доработки планов обмена.
Расширение данных для специальных прикладных задач
В механизм расширения данных мы включили все объекты, которые используются в специальных прикладных областях:
- Учёт движения средств – регистры накопления;
- Бухгалтерский учёт – регистры бухгалтерии, планы видов счетов и планы видов характеристик;
- Расчёт зарплаты – регистры расчета и планы видов расчета.
Теперь в расширениях конфигурации вы можете создавать собственные объекты перечисленных типов, и, тем самым, расширять состав специальных прикладных данных, с которыми работает программа.
Кроме этого перечисленным собственным регистрам вы можете назначать в качестве регистратора как собственные, так и заимствованные документы.
Для собственных регистров накопления есть одно ограничение - в них не поддерживается механизм агрегатов.
Новые возможности расширения планов обмена
Мы увеличили возможности расширения планов обмена.
Теперь в состав собственных планов обмена вы можете включать заимствованные объекты. В результате собственные планы обмена теперь имеют функциональность почти такую же, как планы обмена конфигурации, за исключением того, что собственные планы обмена нельзя использовать в распределенной информационной базе.
Заимствованным планам обмена вы можете добавлять теперь собственные реквизиты, табличные части и реквизиты табличных частей.
Для изменения состава заимствованного плана обмена у вас есть теперь новые возможности:
- Вы можете включить в его состав те объекты расширяемой конфигурации, которых в нём ещё нет. Раньше вы могли добавлять в его состав только собственные объекты;
- Тем объектам, которые есть в его составе, вы можете изменить значение свойства Авторегистрация. Это свойство отвечает за то, каким образом будут регистрироваться изменения данных объекта: автоматически платформой или с помощью алгоритма, написанного разработчиком;
- Объекты расширяемой конфигурации вы можете проверить на то, входят они в этот план обмена, или нет. Раньше вы могли проверять таким образом только собственные объекты.
Для заимствованных планов обмена есть одно ограничение - из их состава вы не можете исключить объекты расширяемой конфигурации.
Предупреждения при удалении расширений с данными
Расширения, изменяющие структуры данных, требуют повышенного внимания к себе. Неосторожное их удаление может привести к потере данных, содержащихся в тех структурах данных, которые были добавлены расширением.
В версии 8.3.12, для того, чтобы снизить риск таких действий, мы добавили в платформу возможность деактивации (отключения) расширений. При этой операции само расширение не удаляется, но перестаёт применяться к конфигурации. Это позволяет вам посмотреть, как конфигурация работает без расширения.
Теперь мы решили, что кроме этого нужно несколько «усложнить» и сам процесс удаления расширений. Но не всех расширений, а только тех, у которых есть «собственные» данные:
- В конфигураторе вы не сможете удалить такое расширение, пока оно активно (будет показано предупреждение). Сначала необходимо расширение деактивировать.
- В конфигураторе перед применением изменений таких расширений (в том числе при удалении таких расширений), будет показано окно с изменением структуры данных, в котором вы можете отказаться от этих изменений. Визуально оно похоже на тот диалог, который возникает при реструктуризации основной конфигурации.
В режиме 1С:Предприятие при удалении таких расширений также будет теперь выводиться предупреждение, позволяющее отказаться от их удаления.
Кроме этого во встроенный язык мы добавили проверку того, что расширение влияет на структуры данных (объект РасширениеКонфигурации, метод ИзменяетСтруктуруДанных()).
Расширения конфигурации 1С облегчают доработку и поддержку типовых решений на внедрениях. Для облачных вариантов это практически единственный способ доработки. Также на расширениях реализуются хотфиксы — быстрые исправления. В последних версиях платформы доступны функции, облегчающие создание «универсальных расширений», независимых от конфигурации. Например, интеграционный инструментарий, консоли, файловый менеджер.
Алексей Тютякин, разработчик 1С в компании Neti, рассказывает о расширениях конфигурации и предупреждает о подводных камнях, с которыми может столкнуться каждый программист.
Краткая справка
Технология с довольно скудным функционалом появилась в 2015 году, в платформе 8.3.6.
Возможности расширений в типовых конфигурациях зависят от режима совместимости, который обычно ограничен версией БСП. На февраль 2021 года в основных линейках типовых конфигураций (ЕРП, БП, ЗУП) используется БСП версии 3.1.3 и режим совместимости 8.3.14.
В базовых версиях расширения не поддерживаются.
Как это выглядит при разработке
Как это выглядит при разработке. Есть основная конфигурация и ее расширение (отдельная мини-конфигурация). Объекты бывают собственными, созданными в самой конфигурации или в расширении, и заимствованными, захваченными из основной конфигурации в расширение. Для заимствованных объектов можно переопределять ряд свойств.
Свойства объектов бывают контролируемые и модифицируемые. Контролируемые свойства менять нельзя — они должны совпадать у основной конфигурации и расширения, иначе расширение не запустится. Модифицируемые свойства можно изменять в расширении.
Возможности технологии
В версии платформы 8.3.14, поддерживаемой современными типовыми решениями, широкий спектр возможностей для изменения. В частности, можно:
- менять большое количество свойств заимствованных объектов;
- создавать собственные справочники, документы и РС;
- создавать и переопределять подсистемы и роли, шаблоны доступа;
- переопределять практически все модули и формы;
- версионировать расширения в хранилище.
В последних версиях платформы появилось множество интересных возможностей. Отметим самые существенные:
- в версии 8.3.13 — поддержка создания своих РН, РБ, РР и связанных объектов, функционал планов обмена;
- в 8.3.14 — собственные параметры сеанса, что дает полноценное создание своих РЛС;
- в 8.3.15 — появилась возможность заимствовать процедуры и функции с контролем изменения кода в основной конфигурации и в расширении — аннотация &ИзменениеИКонтроль;
- в 8.3.16 — создание собственных констант, функциональных опций и критериев отбора, изменение состава заимствованных критериев отбора и функциональных опций;
- в 8.3.17 — создание своих подписок на события и заимствование существующих;
- в 8.3.18 — возможность расширения состава типов заимствованных объектов (с некоторыми исключениями, например, для определяемого типа).
Более подробно с описанием механизма расширений можно узнать в следующих материалах:
Кейс: переход на ЗУП 3.1 КОРП в федеральной торгово-производственной компании
Основной источник кейсов для этой статьи — проект перехода на ЗУП 3.1 КОРП с ЗУП 2.5 в крупной торгово-производственной компании. Особенности проекта:
- холдинговая структура, состоящая из десятка юрлиц;
- пять тысяч сотрудников;
- существенная текучка кадров и большой объем документооборота;
- управленческий учет, аналогичный ЗУП 2.5.
Важное требование заказчика: доработки конфигурации необходимо выполнить только с помощью расширений. Удалось на 99%, 1% — ограничения технологии, о которых поговорим отдельно.
Проект выполнялся на версии платформы 8.3.13, 8.3.15, поэтому для некоторых кейсов сейчас доступны альтернативные решения.
Собственные структуры данных
Одна из первых задач любого внедрения — адаптация структуры хранимых данных к реалиям конкретного проекта, то есть расширение структуры данных.
С версии 8.3.11 платформа умеет через расширения создавать справочники, документы, регистры сведений. С 8.3.13 — РН, РБ, РР, полноценные планы обмена, ПВХ, ПС, ПР.
Эти возможности широко применялись на проекте для расширения структуры данных. Расширялся реквизитный состав заимствованных справочников и документов, добавлялись собственные документы, регистры сведений, регистры накопления. Более того, на смежном проекте внедрения решения 1С:ERP в той же компании проектная команда решила не использовать дополнительные реквизиты вообще. В итоге для описания всей специфики номенклатуры в едином расширении было создано более 100 новых реквизитов, десяток перечислений и справочников-классификаторов. Результат по производительности не ставит каких-либо значимых вопросов, все работает так же быстро, как и типовая ERP.
Работать с расширенной структурой данных удобно. Она поддерживается конструктором запросов и в пользовательском режиме, и в конфигураторе.
Однако стоит учитывать ряд особенностей:
1. Тип ЛюбаяСсылка не содержит ссылок на собственные типы расширения. Механизмы, использующие этот тип, с данными расширения работать не будут.
2. Если в заимствованный справочник/документ добавлен новый реквизит, необходимо захватить в расширение роль, дающую права на этот справочник/документ, иначе реквизит останется без прав и не будет показан на форме.
Хранение новых реквизитов
Рассмотрим способ реализации хранения данных в расширении. Под новые справочники и документы создаются новые таблицы. Они помечаются суффиксом Х и порядковым номером. Например, Reference789X1.
Когда в заимствованный объект расширения добавляется новый реквизит, табличная часть или реквизит табличной части, в базе данных копируется весь набор таблиц объекта с теми же суффиксами в названиях. Например, для таблицы справочника Reference34 будет создана Reference34X1, для новой табличной части может быть создана таблица Reference34_VN34437X1.
Таблицы нового набора дополняются созданными в расширении структурами, после чего данные переносятся в новые таблицы. Дальше вся работа идет с этими таблицами в рамках разделителей текущей области.
Если расширение после изменения основной конфигурации не может быть запущено, оно переводится в неактивный режим. Новые данные не удаляются и не теряются. Для отключения расширения необходимо выбрать соответствующий пункт меню и подтвердить свои намерения в диалоге. Случайно это сделать сложно, поэтому опасения, которые возникли, когда возможность только появилась, сейчас напрасны.
Есть особенность в работе глобального метода ПолучитьСтруктуруХраненияБазыДанных(): в именах таблиц не показываются суффиксы, поэтому определить этим методом наличие или отсутствие расширенной структуры невозможно.
На иллюстрации приведен пример, как выглядит расширенная структура данных для заимствованного справочника расширения, в которую добавлены новый реквизит и новая табличная часть. Видим, что созданы копия таблицы с суффиксом X1 и таблица для табличной части, в конце которой тоже суффикс. Все данные справочника перенесены в новую таблицу.
Во второй части статьи о расширениях поговорим о РН, изменении режима совместимости, доработке модулей и форм, отчетах и печатных формах.
В первой части статьи о расширениях конфигурации 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 порядка меньше основной конфигурации, и все операции с хранилищем выполняются быстро.
Расширения, как и основную конфигурацию, можно разбирать на файлы и собирать обратно.
Заключение
● Технология достигла зрелости. В продуктивной среде проблем стабильности и производительности нет.
● Можно использовать на крупных проектах, в том числе и для расширения данных.
● Ошибки работы расширений редкие, но есть особенности применения. Необходимо заранее проверять проектные решения на работоспособность в используемой версии платформы.
Не стоит применять расширения для развития уже существенно переписанных систем или если в проекте изначально предполагается масштабная переработка типовых механизмов. Причина — исключается преимущество (нетронутая основная конфигурация) при возрастающей сложности доработки (особенности механизмов и несколько мест правки кода).
Не следует использовать в одной конфигурации несколько расширений, изменяющих один и тот же объект метаданных. Это приводит к запутыванию работы кода, доработки будет сложно выполнять. Исключение: временные исправления ошибок, которые в ближайшем релизе будут устранены.
Читайте также: