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

Нужно сделать модуль с одной стороны максимально интегрированным с типовой, с другой стороны типовую по максимум не модифицировать.

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

1. Встраивание в типовую конфигурацию. Модуль целиком встраивается и модифицирует типовую конфигурацию.
(+) доступ к общим справочникам (контрагенты номенклатура и т.д.)
(+) возможность напрямую просматривать документы и генерация их пользователем или модулем.
(–) требуется ручное обновление при каждом выпуске нового релиза типовой. Со всеми вытекающими: нет автоматического обновления, задержка в выпуске.

2. Ведение в режиме обмена через файл. Модуль будет самостоятельной конфигурацией с возможностью обмена. Цепляемся к общему плану обмена.
(+) типовая конфигурация будет не тронута
(–) необходимые для работы документы и справочники типовой придется загружать в модуль, с дополнительной синхронизацией двусторонней.
(–) потребуется отслеживать структуру типовой в части общих данных, и реализовать дублирующий функционал в модуль.

3. В режиме обмена по COM соединению. Модуль будет самостоятельной конфигурацией, но общие данные онлайн извлекаются из типовой конфигурации. Пример: справочник контрагенты есть и в типовой и в модуле, но в модуле не хранятся все его реквизиты. При попытке модификации пользователем, открывается через COM элемент справочника из типовой, модифицируется и закрывается.
(+) типовая не модифицируется вообще
(+) не требуется дублировать функционал типовой в части общих объектов.
(–) для полноценной работы требуется постоянное подключение к типовой конфигурации
(–) для генерации отчетов и выборок потребуется дополнительно обрабатывать типовую по COM соединению.

(0)почему не рассматриваешь внешние источники?

Какая конфигурация и платформа?

(0) "открывается через COM элемент справочника из типовой, модифицируется и закрывается." - давно COM умеет с формами работать? Да и через Application это будет криво с постоянным перескакиванием фокуса.
Тогда уж так: копируем в свою нетленку структуру справочников и там они редактируются/синхронизируются.

(0) По первому варианту - если нормально интегрировать, не изменяя типовые объекты конфигурации, обновление сведется к шелканью кнопкой Далее-Далее-Готово

(4)+ Делай подписку на событие далее на свой код только не в типовом объекте, и проблем с обновлением не будет!
однозначно 1 вариант!
вариант 2: геморно для пользователей работать в 2 базах плюс куча обмена при изменении добавлении элементов и документов!
Вариант 3: вообще не стоит рассматривать! получить данные по COM Обработать и вывести.... боле мене серьёзный отчет будет отрабатывать очень и очень долго!

(1) - Я не вполне понял, поясните всю цепочку.
(2) - Рассматриваю сферическую типовую конфигурацию, т.к. потребуется и для БП и для УПП делать.
(3) - Да тут момент по структуре, в типовых, до недавних пор одинаковые справочники были разнородны по реквизитам, а т.к. хотелось бы иметь возможность связывать с разными конфигурациями, то и структуру забирать не вполне хочется. (4) - Это да, но когда 1С штампует типовые с интервалом в пару дней и там критические исправления, палец начинает уставать.
(5) - Да, первый вариант реализуется достаточно просто и прозрачно, но нужно будет постоянно мониторить обновления типовой.

Я немного поясню вводную. Данный модуль планируется как тиражный продукт. Первый описанный вариант обкатан мной вдоль и поперек на другом продукте, основное узкое место это выпуск релизов сразу вслед за 1С, - это большие затраты времени.

(0) нубский вопрос. автор никогда не ломал типовую конфигурацию?

(6) аа, вот оно что. В этом случае 3й путь ваш

(0) Как показывает опыт разнообразных отраслевых решений
Сначала используется способ 2.
Затем на основании способа 2 реализуется способ 1.

Затем либо способ 2 снимается с поддержки, либо поддерживаются оба.

С точки зрения конечного пользователя (а тиражный продукт  подразумевает его наличие) способ 1 предпочтительней.
Периоды когда обновление нужно срочно - случаются 1 раз в 2-3 года (когда у законодателей случается приступ законотворчества). А обмен с второй базой (и все связанные с этим неудобства) происходит постоянно.

(9) Согласен, со стороны пользователя при ежедневной работе вариант 1 предпочтительнее. Так же как, связка БП + УТ проигрывает интегрированному решению КА или УПП, в части одного функционала.

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

Так же возможна ситуация, когда типовой пользуется большая группа пользователей, а узкий функционал, нужен 1-2 пользователям. И ради них не хотят изменять типовую, либо мониторить эти изменения.

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

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

(6)А если делать все по человечески, и выносить максимум дописок во всякие общие модули и доп объекты, которые будут в своей подсистеме, то никаких проблем с обновлением не будет.