Не так давно заметил что многие зачастую стараются избегать использование расширений в угоду привычным внешкам. Сразу же стало интересно почему так, ведь зачастую решение задачи расширением в сотню раз проще. Можете описать плюсы и минусы, к примеру, доработки типовой ПФ или обработки путём расширения?
(0) В базовых кофигурациях расширения не работают.
(0) Изменение формы объекта. Изменение логики объекта.
(3) смена режима совместимости на расширения влияет не благотворно, а на внешние обработки — почти никак
Вопрос в тему: Если, например, в каком-либо модуле с помощью расширения изменили процедуру. Затем в последующем типовом обновлении данная процедура была переписана, добавлены входящие параметры и прочее. Расширение как то на это реагирует или нужно самому постоянно помнить что где у тебя через расширения изменено и мониторить при обновлениях?
(6) Самому, в лучшем случае расширение не применится если процедура новая не та по входным что перекрывали
(6) Оно отвалится. Нужно будет смержить. Это будет видно в списке расширений.
(0) Изменять ПФ оч удобно. Зашел, подменил одну строку, готово.
(6) По идее оно никак не реагирует на это, если ты в своём расширении заменил какую-то типовую процедуру на свою, а типовая и все с ней связанные при обновлении вдруг поменялись, то думаю всё к чертям полетит и надо будет переделывать.
Расширение требуется когда надо изменить поведение типовой и сохранить относительную легкость типовых обновлений.
Если можно обойтись без расширения — лучше без него обойтись путем внешних обработок.
(10) Ну вот как в моём примере, когда на создание внешней УПД уйдёт уйма времени и сил, я честно даже пытаться не стану и просто сделают расширением.
(9) это будет хорошо, если к чертям полетит. А так может и будет тихо себе работать, но некорректно. и найдут последствия этой работы через полгода.
(10) а в чем легкость типовых обновлений? как мержить изменения типовой и переписанные процедуры или переделанные формы в расширении?
(13) Делать через ИзменениеИКонтроль. В конфигураторе реализовано трехстороннее объединение модулей через внешнюю программу. Пока что у меня все мержилось одной кнопкой.
(0) Плюсы: Расширение проще тиражировать.
Минусы:
1. Если есть добавленные реквизиты в расширении — есть риск потерять эти данные.
2. Не все объекты конфигурации можно использовать в расширении.
Моё мнение: расширение — это один из инструментов. Это не «волшебная таблетка от всех болезней».
Отлично подходит, когда нужно использовать «временную заплатку».
Для крупных проектов не подходит. Для средних — возможно, но с учетом ограничений (п.2 в минусах).
Пользоваться расширением или нет — нужно решать исходя из следующего правила:
«Любая сложная система стремится к повышению уровня хаоса. Задача разработчика держать уровень хаоса в допустимых пределах».
(15) Ну да, потеря данных из реквизитов в расширении это конечно было бы крайне печально. Буду иметь в виду. А вообще открыл для себя расширения вот буквально недавно, раньше как-то всё вне поля зрения оставалось, и был приятно удивлён. Да конечно выходит это не идеальный инструмент, но вспоминая прошлые задачи, которые я мог решить в сотню раз быстрее расширением и без каких либо рисков, понимаешь что всё таки крайне полезная вещь.
(16) не имей это ввиду. Абсолютно точно также можно прохерить данные и по объектам изнутри конфиги, если без включения мозга туда пхать куда попало.
А идеальных инструментов вообще не бывает.
Можно и с большим удобством ногой от микроскопа гвозди в подошвы ботинок вколачивать — очень удобно. Только микроскоп не для того придумывали.
Если можно обойтись без расширения — тогда и вообще можно обойтись без доработок, а решить все средствами типовой.
Зависит от условий типовой и задач, которые на ней будут решать.
(14) т.е. надо использовать нештатные средства для сравнения модулей. а что с изменениями форм делать?
Не буду сильно удивлен, если в скором времени на наиболее продвигаемых конфигурациях совсем откажутся от поддержки внешних, а принудительно заставят использовать только расширения.
Плюсов от применения Расширения, как способа модификации прикладного решения очень много. Тут сам подход, что позволяется перехватывать почти любой код, размещенный в типовой.
Инструменты расширений будут постепенно развиваться и в этом нет сейчас никаких сомнений.
Например, в направлении большего удобства разработки и в направлении повышения безопасности хранения встраиваемых через расширение данных.
(23) Слышал, расширения изначально были не очень юзабельны, а сейчас уже отличный инструмент. Остаётся только ждать этого райского времени, когда с безопасностью хранения данных в расширениях будет порядок. А в плане удобства и сейчас пойдёт.
(24) Данные бывают разные. Если их нормально проектировать и нормально использовать — все с ними вполне безопасно.
Разрекламированная, в том числе и на Мисте, ситуация с исчезновением данных, которые грохает выполняемое ТИИ, это ошибка, но по хорошему ошибка как раз в том, что не должно Расширение позволять создавать такие данные такими способами.
Речь шла о добавлении новых реквизитов в табличную часть и или в реквизиты существующего типового, заимствуя его внутрь расширения.
Т.е. само желание провернуть подобное уже достойно критике, как безграмотный и небезопасный подход к доработке типового объекта и типовой функциональности.
(15) Если есть добавленные реквизиты в расширении — есть риск потерять эти данные
Поэтому я у своих клиентов применяю гибридный вариант.
Данные — и это принципиальный подход, храню исключительно в конфигурации (не в расширении).
А вот код — по-возможности в расширении. Но тут смотреть надо, иногда удобнее модицифировать код прямо в конфигурации, чем через расширение.
(23) «Плюсов от применения Расширения, как способа модификации прикладного решения очень много.»
Я правильно понимаю — смысл расширения в следующем.
У тебя есть форма. На нее нужно вынести пару реквизитов. Или добавить пару колонок в табличную часть.
Вариант решения который сейчас.
С формы снимается признак нахождения на поддержке. Вносятся изменения. При каждом обновлении необходимо проверять не затрут ли изменения доработки.
При варианте с расширением редактируемая формы выносится в расширение. Признак нахождения на поддержке с формы не снимается. Но работает та форма которая добавлена в расширение.
Проблем с обновлением в этом случае нет.
(29) Где происходит добавление реквизитов на форме ? В новой форме которая добавляется в расширения ?
Или реквизиты добавляются только программно ?
(30) да, только программно, я про вариант без расширения
Пустой разговор. Выбирать надо то, что удобнее и с минимальными затратами на последующее сопровождение. Расширение это один из инструментов. Но есть и другие способы внесения изменений.
Послее ввода расширений с УФ и вообще стало гораздо легче все эксплуатировать
один тот факт что нужно частенько исправит очередной велосипед от любимой коровы
типа любит любимая фирма прятать все реквизиты и нужные и не нужные вот и приходиться часто лепить костыль
да примеров очень много можно привести когда расширение очень сильно спасает и облегчает жизнь
один тот факт что можно одним движение отделить привнесенный код от стандартной очень много чего стоит
(32) +100500
Зачем или-или. Надо пользоваться тем инструментом, который подходит к для решения задачи, а не использовать всегда тот, который привычней.
Главный минус — это расширение нельзя сравнить конфигурацией
но есть EDT, который всё никак не может догнать платформу
хотя уже 8.3.16
(39) кто ж спорит, сейчас кошерно реквизиты программно прописывать
Буквально на днях открыл еще один немаловажный плюс расширений — работа в веб клиенте. Столкнулся с важной, для работы программы клиента по его запросам, внешней обработкой, которая прекрасно работает в тонком клиенте и наотрез отказывалась трудиться в веб. Мудрил два дня, пришел к решению перенести обработку в расширение — все заработало как надо
(28) Я больше думаю не о модификации уже существующих форм — если я использую расширение. Да, так можно сделать и многие так и делают.
Но мне больше интересны возможности перехвата вызовов всяких разных процедур.
Визуализация тоже возможна, но она все-таки вспомогательная. Можно свою визуализацию в расширении написать 🙂
Полностью свою форму сделать и только при необходимости, что эта форма в основной конфиге получила некие изменения, внести в свою форму новшества, чтоб поддержать изменения.
Не самый простой вариант, наверное. Но с типовой точно конфликтовать не будет.
(43) Но это все я фрагментами перепобовал. Но готовую, чтоб похвастаться не дам.
Но на самом деле, есть определенные проблемы с тем, что все больше и больше функциональности именно в форме документа или вызывается из формы документа.
Много. Переделывать нужно очень и очень аккуратно.
Это болезнь всех продвинутых типовых.
не боюдут 1совцы заветы MVC
(45) ну это да. Но тем не менее, у разработчиков платформы этот опыт имеется на должном уровне.
Подскажите пожалуйста пару моментов.
Позволяют ли расширения сделать следующее
1. У документы / справочника изменена длина кода / номера. На поддержке остается объект с прежней длиной кода / номера, в расширении объест с увеличенной длиной кода / номера.
2. В конфигурацию добавлен новый регистр, у существующих документов добавлено проведение по этому регистру. Возможно ли с использованием расширения иметь документ полностью на поддержке, а в расширении возможность движения по новому регистру ?
(48)
1. нет
2. Да
А отладка в расширениях работает ?
(49) То есть получается что если у документа изменен модуль объекта и движения по новому регистру с помощью расширений это можно вынести в расширения и оставить документ полностью на поддержке ?
(52) да. но это и раньше работало, с помощью подписок.
(0) В расширении нельзя использовать некоторые объекты, например константы, приходится костылить. При разработке ооооочень долго идёт сохранение конфигурации, очень бесит. Есть некоторые моменты, когда ты не добавляешь в расширение объекты, но используешь их в запросах, при этом конструктор запроса может не работать.
Мне работать с расширениями не понравилось, лучше вносить изменения в конфигурацию, так наглядней и руки не связаны ограничениями. Когда мало доработок, то их можно использовать, но ты заранее не знаешь сколько их будет всего. Мне надо было добавить пару функций, потом это переросло в большой список доработок. Теперь надо тратить ресурсы на перенос доработок из расширения в конфигурацию.
Из минусов внешних печатных форм — когда их много (10 и более), то при обновлении конфигурации неудобно отслеживать изменения.
Мое резюме — лучше вносить изменения в основанную конфигурацию. Если это только печатные формы, то делать их внешними, если есть ещё другие доработки, то печатные формы вносить в конфигурацию.
(48) (49) что будет с данными, если расширение отвалится? Есть документ, который является регистратором для регистра из расширения, если такое расширение отвалится из-за ошибок, данные продадут?
(54) Забыл дописать про плюсы расширений — это перехват результатов процедур и функций.
(54) Начиная с 8.3.16 уже и константы в рсширении можно добавлять
(55) Смотря что за расширения. В общем случае если мы добавляем объект (например Регистр), то создается отдельная табличка. И если расширение отвалиться то ничего не будет. пока расширение не удалишь, таблица останется в базе
Берем Пустую конфигурацию и создаем пустой справочник.
Физически будет создана таблица с именем ReferenceN, где N число — внутренний номер таблица. Для новой пустой базы это будет 31, следующая таблица будет с номером 32 и т.д.
Добавляем расширение и в расширении добавляем реквизит, физически будет создана новая таблица ReferenceNX1, т.е. у меня это Reference31X1, в которую будет скопирована структура и данные из таблица Reference31 и добавлено новая колонка под мой реквизит
Добавляем расширение 2 и в расширении добавляем реквизит 2, новых таблиц нет, а в таблице ReferenceNX1 появиться вторая новая колонка
Из режима предприятия добавляем данные — эти данные будут записаны в Reference31X1, в первичную таблицу ничего писаться не будет
Удаляем расширение 2, а из расширения 1 удаляем наш реквизит 1. Так как теперь расширение не изменяет данные, то данные из Reference31X1 будут перенесены в Reference31, а таблица Reference31X1 будет удалена. Естественна данные из наших реквизитов будут утеряны навсегда, так как мы физически удалили эти реквизиты
Больше года работаю с двумя базами УНФ с ну очень обширными расширениями. Не могу сказать, что проблем совсем не возникает, но глобального ничего. в основном глюки случаются после обновления конфы. В других моментах не припомню.
Первое преимущество расширений — базу не нужно снимать с поддержки, для многих клиентов это ключевое условие. Соответственно, обновление конфы также проходит как обычной типовой базы, за редкими исключениями.
Второе, это возможность вносить изменния в код модуля объекта, менеджера, общие модули, модуль сеанса, модуль приложения. Разумеется, внешниие обработки здесь не помогут. А вносить изменения в аналогичные модули в типовой конфигурации — прощай возможность обновления, ну или превратить этот процесс в ад.
А вот ради добавления/изменения печатной формы создавать расширения точно не стоит — внешние печатные формы прекрасно с этим справляются.
(61) не всякие печатные формы прекрасно. Есть и такие, что можно или внутри конфигурации или только в расширении. в ЗУП кое-какие попадаются.
Но если на вкус и на цвет — всем фломастеры разные. Поэтому я спорить не хочу.
Просто лично для тех расширений, которые мне приходится лепить гораздо проще и быстрее разработать в Расширении. Тем более, что это всего лишь ПФ
(0) Странный вопрос.
В типовых на последних версиях БСП возможности использования дополнительных внешних отчетов и обработок сохранены только для совместимости.
Для всего остального необходимо использовать расширения.
Никаких преимуществ от применения внешних обработок нет.
Исключения — базовые конфигурации. Не удивлюсь, если в в планах 1С есть введение запрета в обозримом будущем на использование внешних обработок в базовых версиях.
Сказанное касается исключительно вопроса из (0) — дополнительных обработок и отчетов.
По всем прочим вопросам и сферам, где можно применить расширение, однозначного ответа нет. Расширения пока остаются слишком сырым инструментом для повсеместного и более широко его применения. Его использование имеет огромное количество оговорок — когда и как его надо обязательно использовать, а когда — правильнее делать доработку в исходной конфе. Когда (и если) появится инструмент, позволяющий сравнивать расширение с исходной конфигурации — это станет первым серьёзным шагом к переводу всех доработок на расширения. Пока же доработки через расширения становятся источником бесконечной головной боли при каждом обновлении. Всё то время, которое раньше тратили при обновлении на анализ доработок в конфе, сейчас тратиться на анализ этих же доработок в расширении. Причем без какого-либо инструментария автоматизировать этот процесс и уж тем более без трёхстороннего сравнения в одном окне.
Когда расширений становится более трёх штук, проблема растёт уже в геометрической прогрессии, т.к. необходимо делать сравнение и анализ применимости всех расширений и совместимости их с обновлением. И даже если вы всё сделали правильно, это не избавит вас от необходимости делать тесты. Ибо невозможно предусмотреть всё.
Поэтому пока что, на сегодняшний день, расширение годно только лишь для совсем небольших доработок — того, что прикручивается сбоку. Если стоит задача вмешательства в основные ключевые алгоритмы исходной конфы, то лучше делать это в ней самой.
(64) это не пара лет. Обрати внимание хотя бы на то, что практически к каждому очередному обновлению типовой успевают выдать в сопровождениях на релизах по нескольку штук, а иногда и больше десяти расширений до момента выхода нового обновления или релиза типовой.
Проблема уже не в том, сырое расширение или переспевшее. Нужна нормальная вдумчивая работа. Попробуй осмыслить пост (60). Для меня этот пост показывает, что точно такие же проблемы были бы и со снятым с поддержки типовым решением. Но вот почему-то разработчикам хочется, чтоб оно само разбиралось с ошибочным поведением разработчика, а не ему самому нужно голову включать.
Временные патчи — это всего лишь один из частных случаев, где расширения действительно можно применять.
Тут не надо анализировать применимость такого патча в следующем новом релизе. В новом релизе этот патч уже будет включен внутрь самой конфы и его можно выкинуть.
А для разработки долгоиграющих расширений мало вдумчивой работы. Потому что в любой момент поставщик конфигурации (форма 1С) может без предупреждения пересмотреть логику и алгоритмы тех объектов, которые ты очень вдумчиво дорабатывал в своём расширении. И тебе мало того, что надо каждый раз анализировать и искать такие проблемы, а потом ещё и переписывать, но и тестировать каждое обновление. Потому что зачастую проблема совместимости расширения с конфигурацией не очевидна. Например, ты расширил какую-то процедуру или функцию, которую 1С не меняла в обновлении, но 1С поменяла другую процедуру, которая теперь по-новому формирует структуру параметров для твоей доработанной процедуры. Никакой синтаксконтроль не предупредит тебя о такой ошибке. Выявить её можно только на этапе тестирования, а иногда и очень тщательного, обрабатывая все возможные варианты и случаи, где задействован доработанный функционал.
Пример функция возвращает текстзапроса. Мы вносим изменения, потому что в типовой ошибка. В следующем релизе 1С исправляет текст и добавляет новые поля. И что твой контроль покажет?
(69) проблема в том, что такого рода ошибку и внутри конфигурации пропустит точно также
Расширения хороши (чертовски хороши), но без нормализации конфигураций — они так и будут «поставщиками сюрпризов», потому как 1Су глубоко наплевать на писателей расширений.
(71) И на потребителей тоже, особенно в ERP
(60) Это одна из проблем расширений (я не про добавление реквизитов — ибо на мой взгляд это в принципе не верно а про невозможность отключения расширений при изменении структуры данных), но все равно — возможности перекрывают все недостатки.
(72) и на собственных разработчиков типовых тоже
Расширения мне понравились тем что правишь 1 процедуру в модуле, а у тебя хоп и в расширении показывает пол конфигурации. Т.е. надо дополнительно описывать где и что им меняется
(75) Нажимаешь кнопочку с воронкой и знаком заимствования и выводятся только измененные объекты. Никаких записей не надо. Ну а по-хорошему, надо после завершения расширения почистить его от ненужных элементов
(70) нет, так как сравнение конфигураций покажет что тут вся функция переписана в хлам, и ты включаешь голову
(67) Если ты не понял моего примера, переспроси. Встроенная проверка применимости расширения никак и никогда не выявит описанной проблемы. Даже если расширенная функция или процедура полностью переписана, не говоря уже о приведенном мною примере.
Можно. Но вероятность ниже. В окне трёхстороннего сравнения ты увидишь, что текст запроса тобою дорабатывался. И увидишь, что 1С В обновлении 1С тоже что-то поменяла в тексте запроса.
В случае, когда ты что-то допилил в расширении, ты не увидишь ничего. Тебе надо самому помнить, что ты дорабатывал некую процедуру и раз 1С изменила её в обновлении — надо идти в расширение и проверять совместимость твоих дописок с дописками 1С.
(61) «это возможность вносить изменния в код модуля объекта, менеджера, общие модули, модуль сеанса, модуль приложения»
Так это ключевое что нужно.
Наглядный пример с чем столкнулся.
Есть конфа БП. Не обновлялась три года. В конфу добавлено несколько регистров и у существующих документов включена возможность проведения по регистрам.
То есть
1. Изменены формы документов.
2. Изменены модули объектов документов.
3. Изменен состав регистров по которым проводится документ (добавление возможности проведения про новому регистру).
И на эту всю конструкцию надо натянуть релизы за 3 года. А это около 30 штук.
И начинаются пляски с бубном.
Самое веселое что на каком-то этапе обновления фирма 1С подкидывает проблем и вносит изменения в документ который часто используется. В ту же расходную накладную или поступление. И при накатывании
обновления слетает все — и форма и модуль и состав регистров по которым проводится документ.
И самое паршивое что от этого не закроешься. Либо при каждом накатывании релиза смотреть все изменения (а это время) либо накатывать а потом если что-то отвалилось благодаря чудесной сериализации объектов (тому что это придумал в фирме 1С надо памятник при жизни ставить) выгружать из копии и загружать.
Если расширения позволят хотя бы 2 пункта из 3 решать то это уже будет здорово.
(73) «я не про добавление реквизитов — ибо на мой взгляд это в принципе не верно»
Да добавление реквизитов это вообще на мой взгляд не страшно. Снял галочку с корня документа и пусть реквизиты добавляются себе.
А вот то что при обновлении документа поступления от поставщика конфигурации отваливаются все движения по добавленным в конфигурацию регистрам которым добавлены тобой это уже веселей.
Рекомендации от Павла Чистова https://expert.chistov.pro/public/1039552/
В принципе, согласен со всем и пришел к тем же выводам, кроме пункта 2. Теперь приму к сведению
(11) почему у тебя на создание внешней упд уйдет много времени?
получение данных для ПФ — уже описана, макеты — тоже есть, остается вызвать один метод, подменить в нем данные, выполнить заполнение макета и все
на все про все обычно уходит полчаса — час
(82) На сколько мне известно он чистый теоретик. По пятому пункту абсолютно не согласен. Я вообще сильно сомневаюсь, что он, что то разрабатывал (возможно ошибаюсь)
(81) можно подробнее? (Не совсем понял о чем речь)
(84) чтоб ты там понял, если это была ссыль на статью, которую опубликовала какая-то девушка-программистка, совершенно посторонний и независимый пользователь его сайта. Ну и комментаторы, в общем, примерно такие же, как и здесь.
про патчи уже писали — как сценарий использования расширений?
(87) Писали. Им тут патчи не интересны.
(86) в (82) написано «рекомендации от..» 🙂 кто то , что там писАл я не разбирался 🙂
(84) На сегодняшний день 5-й и 3-й пункт, на мой взгляд, самые важные и обязательные к исполнению. По крайней мере моя личная практика говорит именно об этом
(89) А здесь ты прав. не важно кто написал статью, важно что она опубликована на сайте Чистова, значит он полностью согласен и рекомендует
(90) а, моя личная практика говорит об обратном. Всех клиентов перевел на расширения (с добавлением в них новых объектов, справочников, документов , регистров) — никаких проблем нет.
Автор стати из (82) описывала собственный опыт.
Причем весьма богатый опыт использования расширений. Значительно более широкий, чем у некоторых присутствующих тут апологетов расширений.
Все её выводы абсолютно справедливы.
Мы поначалу тоже очень радовались возможностям, которые давали расширения, и пытались абсолютно все доработки перевести на них.
Но чем большее количество доработок выносилось в расширение, тем с бОльшими проблемами мы сталкивались при каждом обновлении исходной конфигурации. Были попытки разнести не связанные между особой доработки в разные расширения, ограничить доработки форм только программными методами, не делать расширения данных, и множество других компромиссов. Однако количество косяков при каждом очередном обновлении не сильно уменьшается. Причем косяков, которых не возникло бы будь доработки сделаны внутри конфы.
Так что расширения хороши, но только для очень небольшого круга задача. Да и то при условии соблюдения ограничений, изложенных в той статье.
А те кто пишет, что у него никаких проблем не было, либо ограничивался мелкими доработками (контролировать небольшие расширения действительно довольно легко), либо работает с расширениями недавно и не сталкивался со значительными изменениями расширенных объектов в исходной конфе при обновлении, когда едва ли не половину доработки приходится воспроизводить чуть ли не с нуля из-за того, что 1С-ники решили переработать логику какой-то подсистемы.
(82) https://expert.chistov.pro/ это зеркало Инфостарта.
Можешь в этом убедиться поменяв в адресе ссылки на статью https://expert.chistov.pro/ на http://catalog.mista.ru/
Этих клонов (зеркал) полно. Для примера
У тебя есть документ «ПоступлениеТоваровУслуг».
В типовой редакции БП 3 у него в свойствах есть возможность проведения по 39 регистрам.
В конфигурацию добавляется еще один регистр. Например «УчетДвиженийЗапчастиРемонт».
В документе «ПоступлениеТоваровУслуг» добавляется возможность проведения по этому регистру. То есть было 39 регистров, стало 40.
Теперь смотри что получатся дальше.
Ты накатываешь обновления БП за 3 года. В какой-то момент поставщик конфигурации (фирма 1С) вносит изменения в документ «ПоступлениеТоваровУслуг» (например добавляет реквизит или меняет модуль объекта). И при замещении объекта тем объектом который есть в конфигурации поставщика у тебя слетает добавление возможности движения по регистру «УчетДвиженийЗапчастиРемонт».
В результате реструктуризации ты получаешь пропадание движений по регистру «УчетДвиженийЗапчастиРемонт» где регистратором был документ «ПоступлениеТоваровУслуг».
Так вот мой вопрос был в следующем — позволяет ли расширение сделать так чтобы эти добавления (возможность движения по регистру «УчетДвиженийЗапчастиРемонт» документа «ПоступлениеТоваровУслуг») не
не затирались при замещении объекта.
То есть у тебя документ стоит в состоянии «изменения запрещены», но при этом расширение говорит что по этому документу возможно формирование движения по регистру «УчетДвиженийЗапчастиРемонт»).
(95) Хоррроший вопросик
И какой ответ на ннего?
(96) Ответ на него можно получить от те кто плотно пользуется расширениями.
(97) я не использую типовые конфигурации, но если ты заимствовал документ в расширение и назначил ему дополнительные регистры то при обновлении ничего не слетает.
(97) если я плотно пользуюсь расширениями, то добавление возможности движения по моему самописному регистру никуда не слетит.
Скорей всего, что я привяжу обработку движений в наборе записей по нужному мне регистру с обработчиком события от платформы, который не смогут сломать разработчики типовой, даже если им умышленно поставят такую задачу.
(99) Как ты используя расширение сможешь сделать что документ полностью стоящий на поддержке формирует движения по новому регистру ?
