Расширения как единое целое

Сегодня большинство доработок в 1С делают не правкой типовой конфигурации, а расширениями. Это разумный подход: обновления от вендора продолжают устанавливаться, а изменения живут отдельной поставкой, не трогая типовую напрямую. Но у него есть обратная сторона — реальная конфигурация, с которой работает пользователь, оказывается «размазана» по нескольким выгрузкам: часть логики в типовой, часть — в одном расширении, часть — в другом. Чтобы понять, что на самом деле случится при проведении документа, разработчику приходится держать всю эту мозаику в голове и сводить её руками.

one-s-mcp собирает мозаику обратно в одну картину. Вы подключаете к конфигурации выгрузки её расширений, и продукт индексирует их вместе с типовой — точно так же, как платформа 1С в момент запуска «склеивает» всё в единую работающую конфигурацию. После этого ассистент видит не «типовую отдельно и расширение отдельно», а итоговую карточку справочника «Контрагенты» со всеми реквизитами — родными и добавленными расширением, — и знает, где расширение перехватывает процедуры типовой: перед ними, после них или вместо них.

Какую боль решает

Первая проблема, с которой сталкивается ассистент без понимания расширений, — дубликаты. Если индексировать типовую и расширение по отдельности, ассистент видит два справочника «Контрагенты»: один из типовой, другой из расширения, с частью совпадающих и частью новых реквизитов. Он не понимает, что в работающей базе это один и тот же объект, и начинает путаться: то отвечает по неполной картине, то советует реквизит, которого в этой конкретной сборке вообще нет.

Вторая, более коварная проблема — невидимые перехваты. Расширение может тихо вклиниться в проведение документа или запись справочника через &Перед, &После или &Вместо — и тогда штатная логика типовой это ещё не всё, что реально произойдёт. Без карты перехватов разработчик узнаёт о чужом коде только тогда, когда что-то уже сломалось, а не заранее. Та же беда бьёт и по поиску: если индексировать только типовую, доработки из расширений в него просто не попадают, и ассистент про них не знает — хотя в базе они выполняются наравне со штатной логикой.

Отдельно эта боль касается франчайзи и аналитиков. Разработчик, впервые попавший на проект с десятком подключённых расширений, тратит дни на то, чтобы понять, «что тут вообще наворочено»: какие расширения что меняют, где они пересекаются, не конфликтуют ли между собой. Без единой картины это ручная сверка нескольких выгрузок, объект за объектом.

Как это работает

Начинается всё с выгрузки, и отдельного обряда «а теперь выгрузите ещё и расширения» больше нет: приложение выгружает конфигурацию и её расширения одной выгрузкой — конфигурация и каждое расширение ложатся рядом, каждое в свою подпапку. Каждая выгрузка идёт в новую папку: Конфигуратор очищает целевую папку перед выгрузкой, поэтому дописывать в рабочую нельзя. Практический смысл простой — невозможно случайно проиндексировать типовую без её доработок. Если выгрузки расширений у вас уже есть, их по-прежнему можно указать вручную: на карточке конфигурации кнопкой «Подключить расширение» задаётся путь, а галочкой — какие из подключённых расширений индексировать.

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

Когда расширение добавляет реквизиты или табличные части к объекту типовой — например, к справочнику «Контрагенты», — продукт не заводит для него второй справочник. Он по виду и имени объекта распознаёт, что такой объект уже есть в типовой (в выгрузке 1С такие объекты помечены как заимствованные, Adopted), и подшивает новые реквизиты в карточку того же самого справочника, отмечая у каждого, что он пришёл из расширения. Точно так же не теряются и правки в уже заимствованные реквизиты, табличные части и команды: они хранятся отдельным слоем наложений и накладываются на объект основы при чтении карточки. Раньше такая правка пропадала, и ассистент видел типовой объект вместо доработанного — «в базе поле есть, а помощник о нём не знает» был отдельным классом ошибок. Заодно отсеиваются пустые копии: реквизит, который расширение просто заимствовало, ничего в нём не поменяв, дублем в карточке не появится.

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

Отдельно продукт разбирает перехваты — аннотации в коде расширения, которые говорят платформе встроить процедуру расширения перед штатной процедурой типовой, после неё или вместо неё. Понимаются оба варианта записи, русский и английский: &Перед/&Before, &После/&After, &Вместо/&Around, регистр значения не имеет. Всё это сводится к трём типам связи — «перед», «после», «вместо». Для каждой штатной процедуры видно, кто её перехватывает; для каждого перехватчика — какую именно процедуру он трогает и каким способом. Связь хранится по координатам процедуры, поэтому перехват виден в карте даже в том случае, если сама перехватываемая процедура отсутствует в имеющейся выгрузке типовой.

На этой карте построен готовый сценарий ассистента — «собери всё, что расширения делают с этим объектом». Один вопрос про конкретный справочник или документ — и встроенный ИИ-агент сам обходит карту: смотрит, какие расширения подключены, какие из них модифицируют объект, какие реквизиты добавляют и какие процедуры перехватывают, — и возвращает результат таблицей «расширение — что добавляет — что перехватывает». В приложении на карточке каждого расширения после индексации показана краткая сводка того же рода: сколько объектов оно модифицирует, сколько приносит своих, сколько процедур перехватывает. Подробнее о том, как это устроено внутри и почему единая картина конфигурации важнее суммы отдельных выгрузок, — разбор в блоге.

После правок переиндексируется только то, что изменилось, — и это касается не только типовой, но и всех подключённых расширений. Продукт сверяет, какие файлы выгрузки поменялись, и обновляет только их, обходя при этом все источники сразу. Ранний прототип при инкрементальном обновлении обходил только типовую и из-за этого «терял» данные расширений; сейчас обход идёт по всем источникам, и накопленные данные расширений не пропадают.

Что это даёт

• Ассистент видит реальную базу, а не мозаику. Запрос «покажи карточку справочника Контрагенты» возвращает полную картину сразу — с родными и добавленными расширением реквизитами, без путаницы дублей.
• Доработки не выпадают из поиска. Поиск и карта связей работают по всему контуру — типовая и все подключённые расширения — сразу, с возможностью сузить фильтром на конкретный источник.
• Одна выгрузка вместо двух. Приложение выгружает конфигурацию вместе с расширениями за один заход — проиндексировать типовую без её доработок по невнимательности уже нельзя.
• Перехваты на виду, а не сюрприз при отладке. Карта &Перед/&После/&Вместо сразу показывает, что кроме штатной логики в процедуре отработает ещё и код расширения.
• Приёмка чужой доработки — один вопрос, а не сведение выгрузок вручную. Сводка «что делает расширение с этим объектом» заменяет ручное сопоставление нескольких файлов выгрузки.
• Быстрый вход в чужой проект. Франчайзи или новый разработчик, попавший на базу с десятком расширений, получает карту того, что и где меняется, за секунды, а не за дни разведки.
• Всё локально. Анализ расширений клиента идёт на его машине, код доработок не покидает контур — это снимает вопрос для тех, кто работает с базами под NDA.

Честно об ограничениях

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

Охват типов объектов стал полным, но не бесконечным. В индекс входят и служебные классы, которых раньше не было вовсе: подписки на события, регламентные задания, функциональные опции и их параметры, параметры сеанса, нумераторы, группы команд и другие; роли и права разбираются отдельно и видны в разделе прав у объекта. Осознанно отложено содержимое пользовательской справки объектов, командный интерфейс и карты маршрутизации бизнес-процессов — это зафиксировано с причиной, а не забыто. Если расширение меняет только отложенное, сводка по нему честно покажет ноль изменённых объектов — это точная отчётность, а не баг.

Тела процедур не сливаются в единый «итоговый текст»: продукт сводит списки процедур и связи перехватов, но не генерирует синтетический псевдокод «вот что реально выполнится». Тело каждой процедуры остаётся в своём исходном модуле, а ассистент собирает картину по связям.

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

И последнее: это статический анализ выгрузки, а не исполнение конфигурации. Продукт не запускает базу и не «проигрывает» проведение документа — карта перехватов отвечает на вопрос «кто куда вклинивается», а не «какое именно число в итоге получится».

Что дальше

Хотите увидеть, как ассистент отвечает по вашей собственной сборке «типовая плюс расширения», без дублей и слепых пятен на перехватах? Скачайте one-s-mcp и подключите выгрузки расширений на карточке конфигурации. Полный список возможностей продукта — на странице Все возможности.

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