Єдина модель для довідників, документів, регістрів, констант, форм, команд і модулів. Для 1UA це основа сумісного завантаження прикладних рішень.

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

Навігація по конфігурації як по цілісному дереву об'єктів з пошуком, фільтрами і швидким переходом до залежностей.

Групування функцій у розділи майбутнього інтерфейсу, щоб керовані форми і права доступу відтворювали прикладну структуру конфігурації.

Предметний редактор має показувати реквізити, табличні частини, форми, команди, модулі і пов'язані обмеження без ручної міграції.

Структуроване редагування властивостей з типами, значеннями за замовчуванням, перевірками і поясненням несумісних параметрів.

Місце для налаштувань, які впливають на поведінку об'єкта: доступність, обмін, проведення, індекси, події та розширені атрибути.

Підтримка друкованих форм, табличних документів і шаблонів потрібна для звітності та документів, які мають виглядати так само після запуску у 1UA.

Завантаження зображень, піктограм і статичних ресурсів конфігурації без підміни форматів, щоб інтерфейс зберігав знайому структуру.

Автоматичний зріз складу рішення: об'єкти, модулі, залежності, використані API, ризики сумісності і прогрес покриття тестами.

Довідка по BSL, платформених типах і глобальному контексту повинна працювати поруч з редактором та спиратися на перевірені тести поведінки.

Сніпети для типових BSL-конструкцій, запитів, обробників подій і тестових сценаріїв скорочують рутинний код та зменшують помилки.

Майстри для форм, запитів, звітів і рухів документів мають генерувати сумісну структуру, яку можна перевірити диференційними тестами.

Окремі редактори для модулів, форм, запитів, табличних документів і схем даних повинні працювати з однією канонічною моделлю метаданих.

Безпечний пошук по модулях, формах, макетах і метаданих з попереднім переглядом впливу на конфігурацію.

Підтримка `.erf` як підключених артефактів дозволить запускати звітність без вбудовування її у основну конфігурацію.

Підтримка `.epf` потрібна для сервісних сценаріїв, міграцій, перевірок і допоміжних операцій у супроводі.

Інструмент має показувати різницю між конфігураціями, розширеннями і версіями, а також допомагати з контрольованим злиттям.

Імпорт і експорт конфігурацій у штатних форматах потрібні для перевірки сумісності, резервування і перенесення між стендами.

Робота кількох розробників потребує історії змін, блокувань, перегляду конфліктів і сценаріїв інтеграції з Git-процесом 1UA.

Покрокове виконання BSL, точки зупину, стек, значення змінних і контроль серверних викликів є ключовими для довіри до runtime.

Модель `.cfe` має дозволити накладати зміни на основну конфігурацію, зберігаючи правила сумісності і підтримки.

Пакування релізів, сценарії оновлення, діагностика помилок і політика сумісності мають бути частиною стандартного циклу поставки.

Інтерактивне виконання мови запитів допоможе перевіряти плани, тимчасові таблиці, підсумки і поведінку сховища.

Окремий стенд для схем компонування потрібен, щоб звіти відтворювали фільтри, групування, ресурси і варіанти користувача.

Статичні та поведінкові перевірки мають знаходити непідтримані API, неоднозначні типи, помилки метаданих і ризики виконання.

Склад релізу має фіксувати runtime, завантажувачі, тестовий профіль, міграції сховища і звіт про сумісність.

Профілювання BSL, запитів, транзакцій і UI-подій дає змогу порівнювати 1UA з еталонною поведінкою на реальних сценаріях.

Файлове подання конфігурації потрібне для рев'ю, автоматичних тестів, CI і повторюваного аналізу змін.

Керовані затримки допомагають перевіряти розподіл клієнтського і серверного коду, таймаути та поведінку форм.

Мовні ресурси, переклади і варіанти інтерфейсних рядків мають бути частиною моделі, а не окремим ручним шаром.

Увімкнення і вимкнення частин прикладної логіки має впливати на форми, команди, права і виконання так само, як у цільовій платформі.

Окремі метрики для компіляції, виконання, запитів, блокувань і пам'яті дадуть зрозумілу картину готовності платформи.

Підтримка типових підсистем потрібна як практичний тест сумісності для великих конфігурацій і повторюваних прикладних механізмів.

A unified model for catalogs, documents, registers, constants, forms, commands, and modules. For 1UA this is the base for compatible application loading.

A dedicated mode for diagnostics, service data inspection, and controlled operations needed during implementation and support.

Configuration navigation as a complete object tree with search, filters, and fast jumps to dependencies.

Functional grouping for the future UI so managed forms and access rights reproduce the application structure.

A domain editor should expose attributes, tabular sections, forms, commands, modules, and related constraints without manual migration.

Structured property editing with types, defaults, validation, and clear explanations for incompatible settings.

A place for settings that affect object behavior: availability, exchange, posting, indexes, events, and extended attributes.

Support for print forms, table documents, and templates is required for reports and documents that must look the same in 1UA.

Loading images, icons, and static configuration resources without replacing formats keeps the application interface recognizable.

An automated snapshot of the solution: objects, modules, dependencies, used APIs, compatibility risks, and test coverage progress.

Reference help for BSL, platform types, and the global context should sit next to the editor and rely on tested behavior.

Snippets for common BSL constructs, queries, event handlers, and tests reduce repetitive code and avoid simple mistakes.

Wizards for forms, queries, reports, and document movements should generate compatible structures that differential tests can check.

Dedicated editors for modules, forms, queries, table documents, and data schemas should share one canonical metadata model.

Safe search across modules, forms, layouts, and metadata with a preview of the impact on the configuration.

Support for `.erf` as attachable artifacts allows reporting to run without embedding it into the main configuration.

Support for `.epf` is needed for service flows, migrations, checks, and support operations.

The tool should show differences between configurations, extensions, and versions, then support controlled merging.

Import and export in standard formats are required for compatibility testing, backups, and movement between environments.

Several developers need change history, locks, conflict review, and integration with the 1UA Git workflow.

Step-by-step BSL execution, breakpoints, stack inspection, variable values, and server-call control are key to runtime trust.

The `.cfe` model should allow changes to be layered over a base configuration while preserving compatibility and support rules.

Release packaging, update scenarios, error diagnostics, and compatibility policy should be part of the standard delivery cycle.

Interactive query execution will help check plans, temporary tables, totals, and storage behavior.

A separate workbench for data composition schemas is needed so reports reproduce filters, grouping, resources, and user variants.

Static and behavioral checks should find unsupported APIs, ambiguous types, metadata errors, and runtime risks.

A release bundle should pin the runtime, loaders, test profile, storage migrations, and compatibility report.

Profiling BSL, queries, transactions, and UI events makes it possible to compare 1UA with reference behavior on real scenarios.

A file representation of the configuration is needed for review, automated tests, CI, and repeatable change analysis.

Controlled delays help verify client-server code placement, timeouts, and form behavior.

Language resources, translations, and interface string variants should live inside the model instead of a separate manual layer.

Enabling and disabling application logic should affect forms, commands, rights, and execution the same way as on the target platform.

Separate metrics for compilation, execution, queries, locks, and memory will give a clear readiness picture.

Support for common subsystem patterns is a practical compatibility test for large configurations and reusable application mechanisms.