Незнакомая ERP на 1С: как читать конфигурацию по подсистемам и цепочкам документов

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

Подсистемы в конфигурации 1С задают эту границу сама по себе: объекты группируются по подсистемам, и на подсистемах строится командный интерфейс, то есть разделы рабочего места пользователя. Разбор конфигурации по подсистемам идёт тем же путём, которым по системе ходят её пользователи.

🧭 Порядок разбора: от подсистемы к документу

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

1. Начните с подсистемы. Подсистема отвечает на вопрос «кто в системе что делает» и совпадает с рабочим местом пользователя. Возьмите ту, где идёт основная работа компании.
2. Найдите документ-инициатор. В большинстве процессов он один: заказ, заявка, поступление. С него начинается отсчёт.
3. Пройдите цепочку вперёд. Что документ пишет в регистры, какой документ вводится на его основании, чем процесс закрывается.
4. Проверьте ветки. У процесса почти всегда есть условные маршруты: разные схемы проведения в зависимости от реквизита, разные варианты закрытия.
5. Сверьте картину с владельцем процесса. Разговаривайте с человеком, который работает в системе. Программист расскажет про устройство, а порядок работы знает исполнитель: он назовёт шаг, которого нет ни в одном модуле, - звонок поставщику, согласование по почте, проверку по бумаге.

🧱 Что даёт дерево подсистем

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

Из этого следуют три свойства, которые делают подсистему рабочей единицей разбора.

Она совпадает с разделом интерфейса. Командный интерфейс строится на основе подсистем: разработчик создаёт иерархию подсистем, отражающую структуру функций для пользователя, и привязывает к ним объекты. Значит, разбирая подсистему, вы разбираете то, что пользователь видит на своём рабочем месте.

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

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

🔌 Что показал Analyzer 1C на выгрузке расширения

Analyzer 1C строит граф конфигурации: модули, функции, вызовы, запросы и роли. Я запускала его 27.09.2026 на выгрузке расширения вендора и проверяла, что он отвечает на вопросы разбора. Режим «Изучение подсистем» с карточкой процесса в этот прогон не входил: его описание дано по странице продукта.

Что запускалось. Analyzer 1C 2.7.65 в Docker Desktop, интерфейс на http://localhost:8000, редакция Community без лицензии (одна система). Загружена выгрузка расширения «УправлениеОнлайнТорговлей» 1.7.6.276: 524 объекта, 27 подсистем, 9 ролей. Загрузка заняла 2 минуты 38 секунд, пик памяти 0,39 ГБ. Граф получился такой: 596 модулей, 13 669 функций, 897 вызовов, 1044 запроса.

Что удалось спросить. Через REST я получила права каждой роли на два справочника настроек и вызывающих для трёх функций: например, у функции HTTPЗапрос нашлось 141 обращение из 15 модулей. Права ролей совпали с файлами Rights.xml построчно, а число вызовов не разошлось с поиском по выгрузке. Это ответ на вопрос «кто мог» и «кто вызывает», который по дереву метаданных не собирается.

Ловушки. Файлы выгрузки лежат в корне архива: с вложенной папкой загрузка падает с ошибкой «Configuration.xml не найден в архиве». Запрос /api/object/roles?keys=... отвечает 200 и пустым списком, пока не передан параметр object_key: пустой ответ выглядит как «прав нет», и без контрольной сверки с ролью его легко принять за результат. MCP-интерфейс без лицензии отвечает HTTP 402 «Лицензия не установлена», REST при этом работает. Права на отдельные реквизиты (запрет просмотра поля) в ответах не видны.

Что описано по странице продукта. На Infostart Marketplace у Analyzer есть режим «Изучение подсистем»: список подсистем, отсортированный по числу документов, и карточка процесса со списком и графом цепочки документов. Я этот интерфейс не открывала. Продукт разворачивается в Docker, конфигурация загружается из выгрузки в файлы или из git; замер со страницы продукта: загрузка «1C:ERP РУС» на 27 547 объектов занимает около 15 минут. Мой замер относится к расширению на 524 объекта, и по нему время на ERP не масштабируется.

🧪 Как читать цепочку документов

Цепочка читается по трём связям документа. Их можно посмотреть и без инструмента, в конфигураторе.

• Что порождает документ. Свойства документа «Движения» перечисляют регистры, в которые он пишет при проведении. Это ближайший ответ на вопрос, куда уходят данные.
• Что вводится на его основании. Свойство «Ввод на основании» перечисляет документы, которые создаются из текущего. Так собирается путь процесса вперёд.
• Что выполняется при проведении. Модуль объекта, обработчик проведения. Здесь видны проверки и условные маршруты, которых не видно по структуре метаданных.

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

Отдельно стоит выписать регистры процесса. Один и тот же учётный результат, записанный в разные регистры в разных ветках процесса, - частая причина расхождений в отчётах, и находится она именно на этом шаге.

🚧 Где этот способ не работает

• Связи через код. Если имя объекта собрано строкой или вызов идёт через общий модуль, статический анализ связи не увидит. Граф по такой ветке будет пустым, а процесс на самом деле работает.
• Условные маршруты. Инструмент показывает все возможные пути, но не говорит, какой из них используется в конкретном сценарии. Условия всё равно придётся читать в модуле.
• Объекты вне подсистем. Проверьте, все ли объекты вашей конфигурации привязаны к подсистемам. Если часть объектов в подсистемы не входит, фильтр по подсистеме даст неполную картину, и такие места придётся смотреть по конфигурации целиком.
• Расширения. Объекты, добавленные расширениями, живут отдельно от типовой конфигурации. Проверьте, загружены ли расширения в инструмент, иначе часть доработок в картине не появится.
• Версии продукта. Состав режима и расположение кнопок в описаниях разных версий расходятся. Сверяйте с тем, что видите у себя.

Разбор инструментом не отменяет чтения модулей. Граф отвечает на вопрос «что с чем связано», а проверки, условия и расчёты остаются в коде.

📋 Чек-лист первого дня в незнакомой базе

1. Спросите, какие процессы основные. Запишите их словами пользователей.
2. Сопоставьте названия процессов с подсистемами конфигурации: обычно совпадение неполное, и разница сама по себе информативна.
3. Для одного процесса соберите цепочку: инициатор, движения, документы на основании, закрывающий документ.
4. Выпишите регистры этого процесса и проверьте, не пишет ли один и тот же результат в разные регистры в разных ветках.
5. Отметьте объекты, которые входят в две и более подсистемы: это места пересечения процессов.
6. Отдельно выпишите расширения и доработки: они не видны в типовой логике, но работают в базе.
7. Сверьте собранную картину с владельцем процесса и допишите шаги, которых нет в коде.
8. Сохраните результат как схему процесса с именами документов и регистров: она понадобится в первой же задаче по этой базе.

Полный чек-лист с полями для заполнения - в архиве к статье.

📚 Источники

• Analyzer 1C на Infostart Marketplace: описание режима «Изучение подсистем», состав поставки, порядок развёртывания в Docker и замер загрузки конфигурации «1C:ERP РУС» (27 547 объектов, около 15 минут). Возможности режима приведены по этой странице.
• Командный интерфейс на сайте платформы 1С:Предприятие: командный интерфейс строится на основе подсистем, объекты конфигурации привязаны к подсистемам.
• Объекты конфигурации 1С:Предприятия 8, методическая поддержка для разработчиков: подсистемы группируют объекты конфигурации, один объект может входить в несколько подсистем, подсистемы вкладываются.
• Руководство разработчика 1С:Предприятие 8.3.27, глава 5 «Объекты конфигурации»: состав свойств объекта конфигурации, включая движения документа и ввод на основании.

📎 Файл к статье

В архиве к статье - 10.3-companion.zip: чек-лист, карта процесса, вопросы владельцу, скрипт analyzer_probe.py с выводом пробы Analyzer и проверка файлов check_files.py. Запустите python check_files.py из распакованной папки: скрипт проверит карту процесса, чек-лист и наличие файлов.

• chek-list-razbora.md: чек-лист первого дня в чужой базе с полями для заполнения: по подсистемам, цепочке документов, регистрам, расширениям и сверке с владельцем процесса;
• karta-processa.csv: шаблон карты процесса - шаг, документ, движения по регистрам, документ на основании, кто выполняет, где смотреть в конфигурации;
• voprosy-vladeltsu.md: вопросы человеку, который работает в системе, - что запускает процесс, какие шаги выполняются вне базы, что считается завершением;
• README.md: что внутри, в каком порядке пользоваться и что в архиве не проверено.

Шаблоны заполняются по конкретной базе: имена документов, регистров и подсистем в них условные.

🏁 Итог

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

 

Нинель Адольевна Щербакова (Ninel_S)

Архитектор • SRE & DevOps инженер • HighLoad 1С

Автор 48 технических публикаций на Infostart. Разработчик NOPik, SRE-Suite-for-1C и мультиагентных ассистентов для экосистемы 1С:Предприятие.

Каталог статей и открытых репозиториев Ninel_S