Конструктор движений в расширении
Обновлено: 17.05.2024
Привет! Кто может помочь?
Я программист 1С8 (опыт работы с 2014, с лета 2016 работаю в 1С Франчайзи). Но с Расширениями имею дело впервые.
Инфы нашел достаточно:
http://v8.1c.ru/o7/201410ext/
http://catalog.mista.ru/public/369451/
но это - как на стандартную задачу наложить Расширение.
И все вроде понятно.
А у меня задача ОБРАТНАЯ. Имеется у клиента несколько доработанных баз (оттого, проблемы со стандартными обновлениями). Требуется - доработки по максимуму вынести в Расширения, оставив БД максимально приближенные к Стандартным.
И я совершенно не понимаю как это сделать! Не нашел - какой там механизм?
Кто может "на пальцах" объяснить?
Сначала определяю все интересующие меня объекты - сравнить конфигурацию с конфой поставщика, эт просто.
Создать в исходной нестанд. конфе новое расширение - создал.
А дальше?
Перенести все измененные объекты в Расширение?
Так переносятся ТОЛЬКО формы. А мне ж надо и модуль, и все команды - мне их вручную заполнять?
(Например, Отчет1, совсем новый. Ладно, делаю его внешним и Расширение - вставить. А "прототип" из исходной конфы убираю.
Ругается - требует "не обнаружен в конфе". Какое . если я ясно прочел что в Расширении ДОЗВОЛЕНЫ НОВЫЕ отчеты и обработки - отсутствующие в конфе? Или я не так понял??)
Еще вопрос - вот в Док или Спр изменена Форма. Еще появился / был изменен реквизит - но тут сказано, реквизиты можно оставить, их будем по-прежнему вручную обновлять, раз их расширение не берет.
Переношу Форму (заодно перелетает весь Объект в дерево, Ок!). А поле модуля чистое. Понимаю, что это значит - использовать модули конфы. А как мне изменения перенести - вручную копировать все процедуры где измененный текст - с префиксом расширения перед именем? Ладно, делаю так - а что делать, если внутри еще обращения к процедурам (другим в модуле формы, или в модуле Менеджера, или среди Общих модулей?).
Перенес, ругается.
Мне тогда "охватом" все их тоже переносить? Общие - ладно. А прочие модули той же формы (к которым ссылки) - их куда? И ставить ли перед ними префикс расширения?
В общем, крутился, не получается.
ЧТО делаю не так?
Не понятно конкретно:
1) если объект новый. Как его ПОЛНОСТЬЮ перенести?
1а - добавить - модули не переносятся.
1б при удалении "прототипа", ругается.
2) если объект лишь изменен. ЧТО переносить? ФОрму измененную перенести, ладно. А модули как - я ж написал?
Если команда и "стерильно" чистая - ладно, прописано по ссылке.
А если она ссылается на другую процедуру, ее тоже переносить? С префиксом РАсш - или это лишь для команд?
3) Я главного не понимаю. Какие Объекты конфы видны из Расширения? Или их все (к которым ссылки) надо переносить?
4) насколько обязательно для Расширения наличие "прототипа"? Вот если новая форма, или макет. Переношу, а из конфы удаляю. Ругается!
5) совместимость! Даже в гугле в одних пишут - ставить "не использовать совместимость", в других - "ставить 8.3.9" (чтоб можно было расширять и модули объекта, и модули менеджера). Так что писать??
6) и общие модули - даже в гугле встретил что "не все". А какие.
7) наконец, а что со Свойствами делать? Вот в различии/ сравнении конф, выдало что например в Свойствах формы стоит что-то иное. А в Расширении это поле на форма/свойства вообще отсутствует, что с этим делать?
(0) рашсирения это только обработки и отчеты. максимум формы.
больше НИЧЕГО
никаких реквизитов или обьектов
Повторяю, когда я перенес Отчет (сначала, сделал как обычно, Добавить в Расширение - модуль и команды пустые!) - тогда я исходный сохранил как Внешний, и в Расширении на него заменил. Модуль и команды перенеслись.
Ругается, не работает.
Аналогично - при переносе отдельной Формы. Удаление "прототипа" - и ругань. В чем дело?
3) и вопрос - ЧТО ВИДНО из Расширения? Или мне тупо вручную, по перенесенным модулям отслеживать ВСЕ ссылки и соответствующее переносить?
Я так понимаю, что перенос есть ДВУХ типов.
а)) - переносим то что меняем. Объекты не любые а строго из списка (формы, обработки, отчеты, с 8.9 - еще что-то).
б)) - то что НЕ меняем - но там есть ссылки, по которым обращается из а)).
Верно?
И что НЕ перенесено по группе б) - Расширение просто не видит?
Или я ошибаюсь?
Тогда отчего ругается?
Спасибо.Читаю.
Но если что - вернусь с вопросами.
(просто я не на работе счас - и до баз данных и практики доберусь лишь вечером, а то и в понедельник)
(5) Вы уже утомили по десять раз в каждом посте повторять про чью-то там ругань.
Либо позовите специалиста, либо, если хотите, чтобы тут помогли, задайте конкретный вопрос с описанием того в каком месте что не работает, и как выглядит эта ваша ругань.
Отчеты и обработки абсолютно нормально выносятся в расширение.
Предположу, что если Вы делали через выгрузку во внешний отчет (обработку), то потеряли по дороге модуль менеджера (у внешних отчетов/обработок модуля менеджера нет, т.к. нет самого менеджера). Если я прав, то достаточно просто перенести модуль менеджера из исходного объекта основной конфигурации в объект, который у вас теперь в расширении.
Спасибо.
Но все же вопрос (вот прочел по ИТС ссылке - не нашел).
Верно ли я понял, что Расширение - НЕ ВИДИТ объектов основной конфы, если я их не перенес?
(например, если в измененной конфе есть Константа, или Регистр - и к нему идет обращение. Обязательно надо перенести и этот объект тоже?)
(9) Смотря что понимать под "видит". Если есть например константа в основной конфе и ты в раширении в обработке устанавливаешь значение этой константы то все будет ок, за исключением нескольких моментов. В расширении константа не видна при автодополнении кода, т.е. ты пишешь Константы. и имя константы из основной конфы показано не будет, при этом синтаксический контроль ругаться не будет. Константа также не будет видна в конструкторе запроса.
Рекомендую создать пустую базу и экспериментировать - это самый быстрый путь.
Единственным ограничением расширений являеится невозможность добавления некоторых объектов метаданных и их реквизитов. Для себя делаю так. Надо добавить новый док - добавляем в основную конфу, но форму, модуль менеджера, модуль объекта - все это описываем уже в расширении. В общем в расширении все кроме самих скелетов объектов метаданных.
И последнее, надо учесть что из основной конфы модули расширения не видны. При этом из одного расширения видно другое без проблем, независимо от порядка их подключения
Так надо чтоб режим совместимости основной конфигурации (равно как и расширения) был не ниже 8.3.10, чтобы новые объекты и реквизиты можно было добавлять
Резюмирую: Заимствовать надо объекты конфигурации поставщика, а все изменения и интерфейсного и модульного порядка делать в расширении. Отлично работает. У меня куча, БОЛЬШАЯ куча доработок. ВСЕ перенес на расширения. Не вешаю на конфу замок только потому, что пока поставщик делает все конфы с совместимостью с 8.3.8. Как только режим совместимости повысят, вообще закрою конфу
(15) Подкреплять слова "рашсирения это только обработки и отчеты. максимум формы . никаких реквизитов или объектов" фразой "нельзя добавить свой справочник" - сильно.
(16) ну и? где противоречия ты увидел?
Я от 1С уже 15 лет жду чтобы можно было свою подсистему с любыми метаданными добавлять в типовую.
Вести ее отдельно, разрабатывать. Потом подключать к базе данных. В том числе естественно со справочниками и документами и прочими обьектами которые также и БД расширяют.
А пока что все на уровне форм, отчетов и обработок. Полноценно задача не решена. Хотя обещалось что с выходом восьмерки решения будут блоковыми (хотя может я не правильно воспринял)
Пока что если ты что то дописываешь в типовой - даже нельзя поставку сделать без типовой.
(17) а для меня если нельзя добавить справочники, документы. регистры - это все равно что ничего)) Остальное вообще даже не волнует.
(19) Конечно, если вы, условно, из УТ делаете Автосервис, тогда - ДА, расширения не помогут. Но они и не предназначены для этого. А если вам надо скорректировать движения, добавить реквизит, доп расчет, автоматическое заполнение и т.п., то расширение - то что надо. Да, они и в таких задачах еще не все умеют, но скорость прогресса в возможностях впечатляет(сравните 8.3.8 и 8.3.10 - велосипед и авто). Так что .
(18) "где противоречия ты увидел?" // Ты утверждаешь несколько пунктов, а подтверждаешь только последний из них
(20) да я тоже надеюсь. А так кстати и на безрыбье рыба.
Кстати вот наверное сейчас все обработки перенесу в расширения.
Конструктор движений регистров предназначен для визуальной настройки правил заполнения движений документа по регистрам, настроенным в конфигурации. Результатом работы конструктора является создание предопределенной процедуры ОбработкаПроведения() в модуле редактируемого документа. Конструктор движений работает только для документов.
Конструктор можно вызвать двумя способами:
Внимание! Конструктор доступен только для тех документов, для которых перечислены зависимые регистры накопления и\или сведений.
Описание конструктора
Сам конструктор состоит из одной единственной формы с тремя табличными полями и набором кнопок:
Поле А — список регистров, по которым формируются движения;
Поле Б — список реквизитов текущего документа, доступные для выбора (если в движениях участвует табличная часть, ее необходимо выбрать в одноименном поле);
Поле В — список полей текущего регистра накопления, доступные для заполнения;
При выделении регистра в поле А происходит изменение списка реквизитов в поле В. Поля Б и В также взаимосвязаны: в списке реквизитов (поле Б) отображаются только те реквизиты, которые подходят для выбора в качестве заполнителя для выделенного реквизита в поле В (совпадают по имени и типу). Галочкой в поле Б помечаются те реквизиты документа, которые имеют тот же тип, что и реквизит, выделенный в поле В.
Кнопка «Заполнить выражения» производит автоматическое заполнение полей регистра по совпадающим имени и типу. Для тех реквизитов в поле В, где конструктор не увидел совпадений, поля останутся пустыми.
Кнопка «Очистить выражения» — очищает любые изменения.
Кнопка «ОК» завершает работу конструктора с сохранением изменений.
Кнопка «Отмена» завершает работу конструктора без сохранения изменений.
Примечательно то, что в значения в поле В можно вводить и вручную. Однако, конструктор не проверяет синтаксическую верность введенных формул. Кроме того, автоматическое заполнение не всегда работает корректно.
Результатом работы конструктора будет процедура ОбработкаПроведения() в модуле текущего объекта. Обратите внимание, что в процедуре присутствуют служебные комментарии конструктора. Таким образом конструктор отделяет свои изменения от кода, введенного вручную:
Внимание! Если Вы впервые вызываете конструктор, а процедура ОбработкаПроведения() уже есть в модуле объекта и содержит код, то по окончании работы конструктора она будет замещена. Все изменения, внесенные вручную могут быть утеряны!
Смотреть на Youtube
Алгоритм проведения документа с учетом подписок на события
Если посмотреть свойства документа через палитру свойств, то можно увидеть два важных свойства: "Удаление движений" и "Запись движений при проведении", причем второе НЕ вынесено на закладку "Движения" окна редактирования документа.
1. Удаление движений.
Если свойство "Удаление движений" уставновлено в "Удалять автоматически", то ПЕРЕД началом проведения программа очищает все движения по регистрам. Фактически это означает запись пустого набора записей регистра с видом записи - замещение. А значит, программа выполняет код из процедур "ПередЗаписью" и "ПриЗаписи" модуля набора записей регистров.
2. Процедура "ОбработкаПроведения" модуля документа.
Обратим внимание: в начале обработки проведения у всех движений флаг модифицированности Ложь (значение возвращает метод Движения.Регистр.Модифицированность() ).
При работе с набором записей регистра (например, Движения.Регистр.Очистить() , Движения.Регистр.Добавить() и т.д.) флаг модифицированности становится Истина.
После записи движения в базу Движения.Регистр.Записать() модифицированность снова ложь.
Если в модуле процедуры подписки происходит запись набора регистра в явном виде ( .Записать() ), то программа выполняет код из процедур "ПередЗаписью" и "ПриЗаписи" модуля набора записей регистров и процедуры из подписки на событие "При записи" регистра.
3. Подписки на событие "При проведении" документа
Очередность подписок на одно и то же событие явным образом не определяется 1С, но на практике подписки вызываются в порядке следования в ветке "Подписки на события" окна редактирования конфигурации.
Если регистры записываются с помощь метода Записать () , то выполняются все связанные процедуры.
4. Запись движений.
Вспомним про свойство "Запись движений при проведении" из настроек документа.
Если оно равно "Записывать модифицированные", то в базу будут записаны все движения документа, у которых флаг "Модифицированность" Истина.
Если оно равно "Записывать выбранные", то в базу будут записаны движения регистров, для которых мы явным образом указали необходимость записи.
Запись движений в базу происходит с режимом замещения Истина . Это означает, что будут записаны записи из текущего набора записей регистра коллекции Движения и очищены предыдущие записи.
И в конце р ассмотрим несколько примеров:
Пусть свойство документа "Запись движений при проведении" равно "Записывать модифицированные", а "Удаление движений" - "Не удалять автоматически".
При такой процедуре проведения документ при каждом перепроведении будет добавлять запись в регистр, записи будут множиться. Т.к. строка //*** добавляет записи в регистр, признак Модифицированности снимается.
Правильнее будет написать строку //*** как
или вообще ее опустить, и тогда программа сама запишет модифицированные движения.
В 1С 8 движения документа могут формироваться не только в обработке проведения, но и извне, например, из некоторой служебной обработки (так реализовано допроведение документов, восстановление авансов и т.д.).
В этом случае при перепроведении документа, если происходит изменение движений регистра бухгалтерии (флаг Модифицированности Истина), записи будут замещены записями, сформированными документом.
Перед началом проведения документа все реквизиты документа записываются в базу данных (т.е. программист может их получить с помощью запроса). Во внутренней памяти создается Объект документа, и у этого объекта есть коллекция движений, которая будет записана после окончания процедуры проведения (см. этап 4).
Если в процессе проведения документа движения по регистрам формируются не с помощью коллекции Движения, принадлежащей внутреннему объекту , а другими способами (вручную в форме набора записей или как в примере 2 и т.д.), то на этапе 4 эти записи будут замещены. Чтобы избежать замещения в типовых базах, для документа "ОперацияБух" свойство документа "Проведение" устанавливается в "Запретить".
Если документ должен проводиться по другим регистрам и нельзя запретить проведение, тогда нужно внимательно настраивать свойства документа:
- выбрать вариант записи движений "Записывать выбранные" и убедиться, что Движения.Регистр.Записывать = Ложь
- выбрать вариант записи движений "Записывать модифицированные" и контролировать признак Модифицированности для набора записей этого регистра.
Нужно понимать, что объект, полученный по ссылке (назовем его "ОбъектДок"), и внутренний объект ("ЭтотОбъект"), созданный в памяти в момент проведения, это два разных экземляра объектов.
Соответственно и коллекции движений у них будут разные. У "ОбъектаДок" коллекция движений будет включать только записанный в базу набор записей регистра, а у "ЭтогоОбъекта" - как записанные, так и добавленные и незаписанные записи. По окончании проведения (этап 4) в базу будут записаны наборы записей "ЭтогоОбъекта", причем с признаком Замещать = Истина.
Если записи в набор записей добавляются по способу, описанному выше, то они могут быть замещены на этапе 4.
В релизе 1.15, уже доступном для ознакомления официальным пользователям «1С:EDT», появилась работа с внешними источниками данных, а также конструктор движений.
Поддержка внешних источников данных
На странице официального блога 1С:EDT разработчики сообщили о выходе новой ознакомительной версии своего продукта.
В тестовом релизе реализована одна из самых долгожданных и востребованных возможностей – работа с внешними источниками данных.
Речь идет о прикладных объектах конфигурации, которые позволяют работать с внешними базами данных, не основанными на «1С:Предприятии». Благодаря этим объектам конфигурации информацию из внешних баз можно использовать внутри прикладного решения так же, как будто бы она хранится в самой информационной базе. Внешний источник может получать данные из ODBC-источников в операционных системах Windows и Linux, причем при работе с СУБД Microsoft SQL Server, IBM DB2, PostgreSQL и Oracle Database обеспечиваются полные возможности языка запросов.
Кроме этого, внешние источники данных позволяют подключить к прикладному решению многомерные источники данных, такие как:
- Microsoft Analysis Services;
- Oracle Essbase;
- IBM InfoSphere Warehouse.
Начиная с релиза 1.15, работа с внешними источниками будет доступна и в «1С:EDT». Можно будет импортировать внешние источники из конфигурации, а также создавать их вручную, добавляя таблицы, поля, кубы, функции и т.д.
Автоматическое формирование описания внешнего источника с помощью строки соединения пока не поддерживается, эта функциональность будет реализована позже.
Конструктор движений с дополнительными возможностями
С помощью данного инструмента можно создавать процедуру проведения документа. Этот конструктор аналогичен конструктору движений регистров, который существует в конфигураторе «1С:Предприятия 8», но предоставляет ряд дополнительных возможностей:
- автоматическая проверка синтаксиса на этапе конструирования выражений;
- предварительный просмотр процедуры проведения, которая будет сформирована конструктором;
- добавление новых регистраторов документа не покидая конструктора.
Изменение стандартной компоновки перспективы 1С:Enterprise
Кроме конструктора движений и возможности работать с внешними источниками данных, в тестовой «1С:EDT 1.15» изменена стандартная компоновка перспективы 1С:Enterprise.
Работа с ней существенно упростилась за счет скрытия панелей, которые используются редко. Теперь по умолчанию слева расположена панель «Навигатор», в центре — область редакторов, а справа — панели «Свойства», «Схема» и «Синтакс-помощник».
Панели «Ошибки конфигурации» и «Информационные базы» свернуты с левой стороны экрана, а все остальные панели, которые были раньше в этой перспективе — скрыты.
Такая компоновка перспективы понятнее для новых пользователей и не пугает их обилием «неизвестных» панелей.
Самый большой минус EDT - не получится вести групповую разработку по допиливанию типовых конфигураций с использованием Git. (1С не разрешает выкладывать в Git код из типовых конфигураций)
Грубо говоря, можно пользоваться Git'ом только для разработки самописных конфигураций.
(5) Может, все-таки, нельзя выкладывать в публичные репозитории типа GitHub? Почему нельзя использовать локальный сервер git?
(6)Имел ввиду это
С сайта 1С ИТС:
- Свою собственную конфигурацию, не содержащую фрагментов, поставляемых фирмой «1С», вы можете публиковать на GitHub.
- Свою разработку, содержащую фрагменты, поставляемые фирмой «1С» (например, вы модифицировали типовую конфигурацию), публиковать на GitHub нельзя.
(8)И это правильно. Ведь со стандартным хранилищем 1С все так и работают - приватно внутри своей организации. Так вот и с применением Git тоже можно так работать
Ну и дорабатывать управляемые приложения типовых конфигураций лучше, всё-таки, через расширения - из можно было бы выложить на публичный GitServer - хотя нет,наверное нельзя - если там будут функции модулей или объекты метаданных, импортированные (и, возможно, расширенные) из основной поставки.Хотя - если с программным кодом всё относительно прозрачно (хотя тут тоже есть свои нюансы*), то вот с импортированными метаданными - всё хитрее - в целом в Расширении импортированные метаданные не имеют чёткого следа и идентификаторов, которые могут их однозначно идентифицировать с типовой конфигурацией. Вы можете импортировать хоть только определение, скажем, справочника "Номенклатура" или ещё и часть, да хоть все - реквизиты - этого всё в расширении никак не будет связано с иcходной конфигурацией - и потому может принадлежать любой, в т.ч. не типовой и не 1С-ной конфигурации - и доказывать обратное никто не будет - так что тут можно смело публиковать расширения с такими заимствованиями - вон - тут на Infostart же народ публикует (хотя Insfistart - это не GitHub) - и ничего, такие публикации не удаляются.
*С исходным кодом всё немного сложнее. Вообще-то в авторском праве РФ вроде как (простите не уверен, но если их нет - то и нарушений закона нет) есть некоторые правила допустимого цитирования чужих текстов, не являющихся коммерческой или иной тайной, в составе своей продукции. Навряд ли несколько заимствованных функций и типовой конфигурации тут возимеют достаточный объём для появления юридических оснований к признанию их нарушающих авторское право. На если при заимствовании ещё и в текст будут внесены правки, в т.ч. с перестановкой и переименованием (что при заиствовании текста функций в Расширения обычно и подразумевается) - то тут уж точно будет очень сложно к этому придраться - так, что никто этого делать не будет.
Поэтому, я не вижу проблем в ведении групповой разработки в публичных Git-репозиториях, ну если Вы, конечно, не всю типовую конфигурацию там будете размещать - а для таких случаев - есть приватные online репозитории - причём, скажем, на Bitbucket, Gitlab и др. такие репозитории можно создавать бесплатно . Да, даже Github сейчас позволяет делать любое число приватных репозиториев . Ну а если у Вас большая команда - так можно просто расфасовать участников по разным репозитриям и обмениваться изменениями через pull-request (ну или, таки, завести свой сервер Git)
В первой части статьи о расширениях конфигурации 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 порядка меньше основной конфигурации, и все операции с хранилищем выполняются быстро.
Расширения, как и основную конфигурацию, можно разбирать на файлы и собирать обратно.
Заключение
● Технология достигла зрелости. В продуктивной среде проблем стабильности и производительности нет.
● Можно использовать на крупных проектах, в том числе и для расширения данных.
● Ошибки работы расширений редкие, но есть особенности применения. Необходимо заранее проверять проектные решения на работоспособность в используемой версии платформы.
Не стоит применять расширения для развития уже существенно переписанных систем или если в проекте изначально предполагается масштабная переработка типовых механизмов. Причина — исключается преимущество (нетронутая основная конфигурация) при возрастающей сложности доработки (особенности механизмов и несколько мест правки кода).
Не следует использовать в одной конфигурации несколько расширений, изменяющих один и тот же объект метаданных. Это приводит к запутыванию работы кода, доработки будет сложно выполнять. Исключение: временные исправления ошибок, которые в ближайшем релизе будут устранены.
Читайте также: