# MCP:RSV Server — Релиз 7.4.0

## Содержание

- [Время одного вызова](#время-одного-вызова)
  - [Долгий вызов больше не приходит агенту внутренней ошибкой](#долгий-вызов-больше-не-приходит-агенту-внутренней-ошибкой)
  - [Долгой работе хватает времени, а ответ «выполняется» всегда доходит](#долгой-работе-хватает-времени-а-ответ-выполняется-всегда-доходит)
  - [Проверка качества кода по всей типовой конфигурации отвечает сразу](#проверка-качества-кода-по-всей-типовой-конфигурации-отвечает-сразу)
  - [Набор модулей проверяется по времени и говорит, что осталось](#набор-модулей-проверяется-по-времени-и-говорит-что-осталось)
  - [Пакет правок замечает снятие вызова и останавливается](#пакет-правок-замечает-снятие-вызова-и-останавливается)
- [Поиск по коду](#поиск-по-коду)
  - [Поиск по коду работает на 1C:EDT 2026.2](#поиск-по-коду-работает-на-1cedt-20262)
  - [Понятный ответ, если поиск не может быть выполнен](#понятный-ответ-если-поиск-не-может-быть-выполнен)
  - [Найденное в схеме компоновки данных показывается с адресом](#найденное-в-схеме-компоновки-данных-показывается-с-адресом)
  - [Регулярное выражение: сказано там, где оно действительно работает](#регулярное-выражение-сказано-там-где-оно-действительно-работает)
  - [Регулярное выражение по схеме компоновки понимает кириллицу](#регулярное-выражение-по-схеме-компоновки-понимает-кириллицу)
  - [Поиск слова целиком](#поиск-слова-целиком)
  - [Где именно искать — задаётся вызовом](#где-именно-искать-—-задаётся-вызовом)
  - [Найденное внутри объекта попадает в сводку](#найденное-внутри-объекта-попадает-в-сводку)
- [Справка платформы](#справка-платформы)
  - [Справка платформы на 1C:EDT 2026.2](#справка-платформы-на-1cedt-20262)
- [Проверка запроса](#проверка-запроса)
  - [Проверка запроса больше не запрещает записать верный запрос](#проверка-запроса-больше-не-запрещает-записать-верный-запрос)
  - [Подсказка к ненайденному полю указывает на нужную таблицу](#подсказка-к-ненайденному-полю-указывает-на-нужную-таблицу)
- [Схема компоновки данных отчёта](#схема-компоновки-данных-отчёта)
  - [Правка схемы больше не может молча её уменьшить](#правка-схемы-больше-не-может-молча-её-уменьшить)
  - [Ответ на правку схемы возвращает фактические числа](#ответ-на-правку-схемы-возвращает-фактические-числа)
  - [Снимок перед крупной правкой схемы](#снимок-перед-крупной-правкой-схемы)
  - [Отказ по итогу «количество всех строк» подсказывает рабочую запись](#отказ-по-итогу-количество-всех-строк-подсказывает-рабочую-запись)
  - [Отказ проверки выражения называет само выражение](#отказ-проверки-выражения-называет-само-выражение)
  - [В справке сказано, что правка запроса не меняет состав полей набора](#в-справке-сказано-что-правка-запроса-не-меняет-состав-полей-набора)
  - [Ноль полей у набора данных больше не выглядит потерей](#ноль-полей-у-набора-данных-больше-не-выглядит-потерей)
  - [Отчёт ровно с нужными полями: выключенное автозаполнение заработало](#отчёт-ровно-с-нужными-полями-выключенное-автозаполнение-заработало)
  - [Пакетный запрос больше не выкашивает поля набора](#пакетный-запрос-больше-не-выкашивает-поля-набора)
  - [Числа схемы приходят и в ответе на пакет правок](#числа-схемы-приходят-и-в-ответе-на-пакет-правок)
  - [В разборе варианта видно то, что было задано](#в-разборе-варианта-видно-то-что-было-задано)
  - [Понятный отказ вместо внутренней ошибки в списках полей и оформления](#понятный-отказ-вместо-внутренней-ошибки-в-списках-полей-и-оформления)
  - [Оформление поля объясняет, чего не хватает](#оформление-поля-объясняет-чего-не-хватает)
  - [Создание объекта без указания типа объясняет, чего не хватает](#создание-объекта-без-указания-типа-объясняет-чего-не-хватает)
  - [Кросс-таблица заполняется числами](#кросс-таблица-заполняется-числами)
  - [Отбор без значения больше не обнуляет отчёт](#отбор-без-значения-больше-не-обнуляет-отчёт)
  - [Использованием элемента настроек можно управлять](#использованием-элемента-настроек-можно-управлять)
  - [Удаление параметра отчёта не оставляет отчёт нерабочим](#удаление-параметра-отчёта-не-оставляет-отчёт-нерабочим)
  - [Значение-дата сохраняется датой везде, где оно задаётся](#значение-дата-сохраняется-датой-везде-где-оно-задаётся)
  - [В разборе отчёта виден вид значения, а не только его текст](#в-разборе-отчёта-виден-вид-значения-а-не-только-его-текст)
  - [Смена запроса набора не включает автозаполнение полей обратно](#смена-запроса-набора-не-включает-автозаполнение-полей-обратно)
  - [Поле, убранное из набора, не оставляет отчёт нерабочим](#поле-убранное-из-набора-не-оставляет-отчёт-нерабочим)
- [Справочная информация объектов](#справочная-информация-объектов)
  - [Абзац в справку дописывается без пересылки всей страницы](#абзац-в-справку-дописывается-без-пересылки-всей-страницы)
  - [Чтение справки больше не обрывается молча](#чтение-справки-больше-не-обрывается-молча)
  - [Справка заимствованного объекта: честный отказ вместо успеха без результата](#справка-заимствованного-объекта-честный-отказ-вместо-успеха-без-результата)
  - [Оформление не дублируется в теге](#оформление-не-дублируется-в-теге)
- [Расширения: состав заимствованного](#расширения-состав-заимствованного)
  - [Правка оформления больше не отменяет чистку состава](#правка-оформления-больше-не-отменяет-чистку-состава)
  - [Кнопка стандартной команды не оставляет расширение несобираемым](#кнопка-стандартной-команды-не-оставляет-расширение-несобираемым)
  - [Изменение состава расширения всегда названо в ответе](#изменение-состава-расширения-всегда-названо-в-ответе)
  - [Основная таблица динамического списка в расширении](#основная-таблица-динамического-списка-в-расширении)
- [Расширения информационной базы](#расширения-информационной-базы)
  - [Установка и удаление расширения доводятся до конца](#установка-и-удаление-расширения-доводятся-до-конца)
  - [Расширение ставится и в базу, опубликованную на веб-сервере](#расширение-ставится-и-в-базу-опубликованную-на-веб-сервере)
  - [Справку расширения, загруженного в базу, можно прочитать](#справку-расширения-загруженного-в-базу-можно-прочитать)
- [Обновление информационной базы](#обновление-информационной-базы)
  - [Отказ обновления называет, кто держит базу](#отказ-обновления-называет-кто-держит-базу)
  - [Занятую базу можно освободить, не выходя из вызова](#занятую-базу-можно-освободить-не-выходя-из-вызова)
  - [Загруженным считается только то, что база действительно приняла](#загруженным-считается-только-то-что-база-действительно-приняла)
  - [Успех загрузки подтверждается самой базой](#успех-загрузки-подтверждается-самой-базой)
- [Схемы отчётов: значения, оформление и чтение](#схемы-отчётов-значения-оформление-и-чтение)
  - [Отбор по значению перечисления наконец отбирает](#отбор-по-значению-перечисления-наконец-отбирает)
  - [Правка готового правила оформления работает](#правка-готового-правила-оформления-работает)
  - [Формат поля ставится одним вызовом](#формат-поля-ставится-одним-вызовом)
  - [Чтение схемы показывает то, что задано](#чтение-схемы-показывает-то-что-задано)
- [Макеты печатных форм](#макеты-печатных-форм)
  - [Перенос текста по словам](#перенос-текста-по-словам)
  - [Высота строки подбирается по содержимому](#высота-строки-подбирается-по-содержимому)
  - [Оформление ячейки можно прочитать обратно](#оформление-ячейки-можно-прочитать-обратно)
  - [Неверное значение больше не проглатывается молча](#неверное-значение-больше-не-проглатывается-молча)
  - [Формат числа и даты, отступ, поворот текста и защита ячейки](#формат-числа-и-даты-отступ-поворот-текста-и-защита-ячейки)
  - [Ширина колонки подбирается автоматически](#ширина-колонки-подбирается-автоматически)
  - [Прямоугольные области разрешены](#прямоугольные-области-разрешены)
  - [Макет внешней обработки описан в справке](#макет-внешней-обработки-описан-в-справке)
  - [Оформление ячеек макета работает на 1C:EDT 2026.2](#оформление-ячеек-макета-работает-на-1cedt-20262)

## Время одного вызова

### Долгий вызов больше не приходит агенту внутренней ошибкой

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

Теперь плагин заканчивает работу заведомо раньше, чем перестаёт ждать собеседник, и
подготовленный ответ доходит. В нём сказано, сколько времени было, что выполняется в
среде разработки прямо сейчас и — первым делом — как сузить запрос. Если у вашего
MCP-клиента время ожидания настроено иначе, чем принято по умолчанию, лимит вызова
меняется настройкой среды `edt.rsv.toolTimeoutSeconds` (или переменной окружения
`RSV_TOOL_TIMEOUT_SECONDS`) — остальные ограничения времени подстраиваются под неё сами.

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

### Долгой работе хватает времени, а ответ «выполняется» всегда доходит

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

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

### Проверка качества кода по всей типовой конфигурации отвечает сразу

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

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

### Набор модулей проверяется по времени и говорит, что осталось

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

### Пакет правок замечает снятие вызова и останавливается

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

## Поиск по коду

### Поиск по коду работает на 1C:EDT 2026.2

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

Исправлено: поиск по коду работает на 1C:EDT 2026.2 в полном объёме — поиск
текста, поиск ссылок на объект, поиск вызовов метода — в конфигурациях,
расширениях и проектах внешних обработок. Поддержка ранее выпущенных версий
среды сохранена в полном объёме; плагин сам определяет, как обратиться к
поисковому механизму конкретной версии, поэтому отдельной сборки под версию
среды не нужно, а выход следующей версии 1C:EDT не потребует обновления ради
поиска.

### Понятный ответ, если поиск не может быть выполнен

Когда поиск отказывал, в ответе была строка технического текста, по которой
нельзя было понять ни причину, ни что делать дальше, а в журнале 1C:EDT не
оставалось вообще никакого следа — разобраться самостоятельно было невозможно, и
даже присланного отчёта не хватало.

Исправлено: если поиск выполнить нельзя, ответ говорит об этом человеческим
текстом — что произошло, что делать (обновить плагин либо сообщить разработчику
версии среды и плагина, их показывает `show_edt_version`) и какой обходной путь
работает прямо сейчас. Случай «установленная сборка плагина не знает эту версию
среды» отмечается в ответе отдельным признаком, чтобы агент не тратил вызовы на
перебор параметров. Полная запись об ошибке с местом отказа уходит в журнал
1C:EDT — по ней разбор занимает минуты вместо переписки.

### Найденное в схеме компоновки данных показывается с адресом

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

Исправлено: у такого совпадения теперь есть адрес — объект, свойство и номер
строки внутри значения, — а вместо всего значения показывается короткая выдержка
вокруг найденного места. Тот же поиск стал компактнее в семьдесят раз, и по
каждому совпадению сразу видно, в каком объекте оно найдено. Совпадения в
модулях показываются как прежде.

### Регулярное выражение: сказано там, где оно действительно работает

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

Исправлено: описание говорит правду. Поиск по коду ищет подстрокой и
подстановочными знаками `*` и `?`; регулярные выражения работают в поиске по
схемам компоновки данных (`dcsSearch`) — там они и названы. Отказ на попытку
искать регулярным выражением по коду называет обе рабочие замены сразу, поэтому
следующий вызов агента уже попадает в цель.

### Регулярное выражение по схеме компоновки понимает кириллицу

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

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

### Поиск слова целиком

Убедиться, что имя больше нигде не используется, — обычная работа перед
переименованием или удалением, и сделать это поиском по коду было нельзя.
Короткое имя находилось внутри каждого длинного: `Сумма` давала сотни совпадений
из `СуммаДокумента` и `ОбщаяСумма`, и среди них не было видно, остались ли
настоящие вхождения. Приходилось имитировать поиск слова подстановочными знаками
и разбирать выдачу глазами.

Исправлено: у поиска по коду появился режим «слово целиком» (`wholeWord`). В нём
совпадение обязано стоять на границах слова, поэтому в выдачу попадают только
настоящие вхождения имени, а вхождения внутри более длинных имён — нет. Режим
одинаково работает с русскими и латинскими именами и на любой версии среды.

### Где именно искать — задаётся вызовом

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

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

### Найденное внутри объекта попадает в сводку

Сводка ответа поиска считалась только по файлам. У совпадения внутри схемы
компоновки данных или запроса динамического списка файла нет, поэтому такие
совпадения в сводку не попадали вовсе: поиск мог отдать четыре с половиной сотни
совпадений и написать в сводке «файлов с совпадениями: 0», а разбивка по типам
объектов оставалась пустой. По сводке выходило, что не найдено ничего.

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

## Справка платформы

### Справка платформы на 1C:EDT 2026.2

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

Исправлено: справка платформы на 1C:EDT 2026.2 работает в полном объёме —
разделы перечисляются, у типов и их методов приходят описания, статьи языка
запросов и встроенного языка находятся по имени. Поддержка ранее выпущенных
версий среды сохранена, а выход следующей версии не потребует обновления ради
справки. Кроме того, если прочитать справку платформы всё же не удастся, ответ
скажет об этом прямо: перечень раздела вернёт отказ вместо пустого списка, а
ответ по типу — пометку, что пришли только подписи без описаний, и что с этим
делать. Источник ответа теперь называется по тому, что в нём действительно есть.

### Статья справки приходит от того типа, который спросили

Запрос статьи по методу мог вернуть статью одноимённого метода совсем другого
типа — и пометить ответ успешным. «РегистрыСведений.Выбрать» отвечал описанием
метода элемента формы («эмулирует двойной щелчок мышки»), «СписокЗначений.Найти»
— описанием функции поиска подстроки, «Массив.Записать» — описанием записи
объекта. Отличить такой ответ от правильного было нечем: он выглядел как
обычная статья, и код по нему писался с полной уверенностью в своей правоте.

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

### Состав значений системного перечисления

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

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

## Снимок формы

### Снимок формы: ответ теперь совпадает с тем, что произошло

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

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

## Адресация проектов и сред разработки

### Указанный проект теперь действительно граница вызова

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

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

### Объекты расширения больше не «пропадают»

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

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

### «Нигде не нашлось» больше не выносится вслепую

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

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

### Поиск ссылок на роль видит состав конфигурации и расширения

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

Теперь по роли дополнительно просматриваются состав конфигурации или расширения
и описания подсистем — найденные упоминания приходят с файлом и строкой. Ответ
по роли всегда говорит, что просмотрено, а что нет и чем это добрать, чтобы ноль
не читался как «роль нигде не нужна».

### Подсказка «возможно, вы имели в виду» больше не перебивает точный ответ

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

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

### Оглавление большого модуля помещается в ответ

Карта модуля на десять-двадцать тысяч строк — обычное дело в типовых
конфигурациях — не помещалась в ответ даже в самом сжатом режиме: у каждого
метода печаталась и сигнатура, и разобранный список параметров, а имена методов
приходили по три раза. Разведка чужой конфигурации упиралась в это с первого
вызова.

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

## Переименование и удаление

### Репетиция переименования: видно, что именно изменится

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

Теперь у операции `renameObject` есть репетиция. Вызов с `dryRun` ничего не
меняет и возвращает полный список планируемых замен: модуль, номер строки,
прежний и новый текст строки, вид места (код, строка, комментарий) и признак,
пойдёт замена в дело или будет пропущена и почему. Настоящий вызов делает ровно
то, что показала репетиция, и возвращает такой же список — сравнить их можно
построчно. Для реквизита с распространённым именем (Сумма, Дата, Код,
Наименование) репетиция стоит один лишний вызов и показывает всю картину сразу.

### Переименование не трогает комментарии, тексты и чужие объекты

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

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

Для объекта целиком, формы и макета обращения по имени в текстах остаются
рабочими и обновляются, как и раньше.

### Список «оставшихся ссылок» больше не путают со списком замен

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

### Удаление роли отклоняется, если она задаёт видимость по ролям

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

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

### Удаление объекта снимает права ролей на всё, что удаляется вместе с ним

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

Исправлено: удаление снимает права на весь удаляемый узел — на объект, на его
реквизиты, табличные части, формы, команды, значения перечисления, измерения и
ресурсы регистров, на вложенные подсистемы любой глубины. Все задетые роли
названы в ответе, рядом — сколько записей снято. Права на соседние объекты с
похожими именами не затрагиваются.

### Удаление роли больше не оставляет её права в проекте

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

Исправлено: удаление объекта снимает и то, что среда хранит рядом с ним
отдельными записями, — права роли, справку, командный интерфейс. Что именно
снято, перечислено в ответе.

### Обновление базы называет виновника вместо непонятного отказа

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

Теперь такой отказ называет роли поимённо и даёт готовый вызов лечения.

### Лечение прав ролей: `repairRoleRights`

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

### Видимость по ролям: задаётся операцией и видна в структуре формы

«Видимость по ролям» элемента формы теперь задаётся операцией `setProperty`:
можно перечислить роли, задать значение по каждой роли отдельно, задать общую
видимость вместе с ролями или снять ограничение пустым списком. Роли, которой
нет в проекте, операция не примет и назовёт её. Список ролей задаётся целиком —
то, чего нет в переданном значении, из свойства пропадает; общая видимость при
этом сохраняется, если её не меняли явно.

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

## Проверка ошибок

### Проверка по объекту показывает то же, что проверка по проекту

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

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

### Ноль замечаний теперь всегда объяснён

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

Исправлено: объекта с таким именем в модели нет — приходит отказ с прямым
текстом «проверка не выполнялась» и разбором, что могло быть не так (вид объекта
по-английски, полное имя формы, объект в другом проекте рабочей области). Ноль
замечаний сопровождается доказательством: какие именно папки объекта просмотрены,
сколько в них файлов, и сколько в той же области замечаний уровнем ниже, чем
запрошенный. Утверждение «код корректен» без такого подтверждения больше не
выдаётся.

### Слишком широкая проверка сразу говорит, чем её сузить

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

Исправлено: предохранитель работает и для проверки изменённых файлов, и для
проверки по всем проектам, когда не задан ни отбор файлов, ни объект. Первым
шагом сужения вердикт называет отбор файлов — он работает поверх любой области
и сразу приводит ответ к нужному модулю.

## Проверка запроса

### Проверка запроса больше не запрещает записать верный запрос

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

Исправлено: если хотя бы одну таблицу запроса разобрать не удалось, замечания о
таблицах и полях по такому запросу больше не считаются ошибками и запись не
блокируют. Эти таблицы названы в ответе отдельно, с пояснением, что существование
их полей не проверялось: проверка не исчезает, а перестаёт быть приговором.
Настоящие ошибки — опечатка в имени поля при разобранных таблицах или
синтаксическая ошибка — останавливают запись, как и раньше.

### Подсказка к ненайденному полю указывает на нужную таблицу

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

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

## Прогон тестов

### Прогон без указания расширения больше не выглядит зависанием

Запуск тестов без указания расширения искал тесты сразу во всех расширениях
информационной базы и в самой конфигурации — самый долгий режим прогона, а ответ
об этом не говорил ни слова. На базе с десятками расширений такой прогон идёт
минутами, и со стороны это неотличимо от зависшего вызова; описание параметра при
этом обещало умолчание, которого на самом деле нет.

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

### По ответу видно, идёт прогон или встал

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

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

### Отказ перед прогоном называет, что именно разошлось с базой

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

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

### Состояние «требуется обновление» перестало читаться как запрет

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

## Подсистемы

### Перенос подсистемы сохраняет права ролей

Раньше после переноса подсистемы в другое место дерева права, выданные на неё
ролям, переставали действовать: запись в роли оставалась, но указывала в пустоту.
Заметить это было нечем — выгрузка проходила, файл получался корректным, проверки
молчали, и приходилось каждый раз снимать права перед переносом и выдавать их
заново.

Теперь `nestSubsystem` переносит права вместе с подсистемой — и с ней самой, и со
всеми вложенными в неё. Роли, которых это коснулось, перечислены в ответе.
Ничего снимать и выдавать заново не нужно. Проверить состав прав роли можно
`get_object_details` по роли: записи на несуществующие объекты в нём помечены
отдельно.

### Переименование, меняющее только регистр букв

Переименование вида «Товары → товары» удаляло объект вместе с его файлами, а
ответ при этом был успешным. Исправлено: объект остаётся на месте, меняется
только имя.

### Переименование вложенной подсистемы

У подсистемы, вложенной глубже одного уровня, `renameObject` возвращал в ответе
полное имя, которого в конфигурации не существует, — агент шёл по нему и получал
«объект не найден». Та же ошибка была у колонки табличной части. Теперь полное
имя в ответе верное на любой глубине вложенности.

Заодно после переименования вложенной подсистемы каталог прежнего имени убирается
сразу, а не остаётся на диске рядом с новым.
## Схема компоновки данных отчёта

### Правка схемы больше не может молча её уменьшить

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

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

### Ответ на правку схемы возвращает фактические числа

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

### Снимок перед крупной правкой схемы

Перед операцией, которая меняет схему крупно — заменяет текст запроса набора,
добавляет или удаляет набор, ремонтирует схему, удаляет вариант, — плагин делает
снимок проекта, тем же механизмом, что и перед объединением конфигураций. В ответе
приходит короткая команда возврата к состоянию до правки. Снимок делается, если у
проекта уже ведётся история версий; мелкие добавления — одно поле, один параметр —
снимок не создают.

### Отказ по итогу «количество всех строк» подсказывает рабочую запись

Итоговое поле отчёта с записью «Количество(*)» отклонялось глухо: сказано, что выражение
содержит ошибки, а что писать вместо — нет. Между тем такая запись в выражении компоновки
не работает в принципе: схема с ней сохраняется, а отчёт в 1С:Предприятии не собирается
вовсе. Теперь отказ прямо называет причину и рабочую замену — считать по конкретному полю,
а для числа различных значений брать соответствующую функцию. Заодно исправлены примеры
в справке: там эта запись предлагалась как рабочая.

### Отказ проверки выражения называет само выражение

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

### В справке сказано, что правка запроса не меняет состав полей набора

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

### Ноль полей у набора данных больше не выглядит потерей

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

### Отчёт ровно с нужными полями: выключенное автозаполнение заработало

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

### Пакетный запрос больше не выкашивает поля набора

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

### Числа схемы приходят и в ответе на пакет правок

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

### В разборе варианта видно то, что было задано

Задать вид группировки «по иерархии» и значение периода отчёта можно было и раньше,
а вот убедиться, что они легли, — нет. В разборе варианта печаталось только имя поля
группировки, без её вида, и только факт вывода параметра в шапку, без его значения.
Единственным способом проверки оставался запуск отчёта в 1С:Предприятии. Теперь вид
группировки приписан к имени поля, когда он отличается от обычного, а значение периода
приходит значением — «прошлый год» так и написано. Обычная группировка печатается
по-прежнему, одним именем: умолчание не засоряет ответ.

### Понятный отказ вместо внутренней ошибки в списках полей и оформления

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

### Оформление поля объясняет, чего не хватает

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

### Создание объекта без указания типа объясняет, чего не хватает

Имя нового объекта передаётся вместе с типом. Если тип забыт, отказ сообщал, что пустое
имя не годится, — про имя, которого никто не передавал. Теперь отказ называет настоящую
причину, показывает переданное имя и правильную форму записи.

### Кросс-таблица заполняется числами

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

### Отбор без значения больше не обнуляет отчёт

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

### Использованием элемента настроек можно управлять

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

### Удаление параметра отчёта не оставляет отчёт нерабочим

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

### Значение-дата сохраняется датой везде, где оно задаётся

Любое значение-дата в настройках отчёта сохранялось строкой — и в значении параметра, и в
отборе, и в условии условного оформления. Схема при этом выглядела совершенно правильной,
проверка проекта молчала, а отчёт молча отдавал ноль строк: со строкой платформа дату не
сравнивает. Отбор по дате, дающий 35 строк настоящей датой, давал ноль. Теперь дата
сохраняется датой во всех трёх местах. Принимаются записи `ГГГГ-ММ-ДД`,
`ГГГГ-ММ-ДД ЧЧ:ММ:СС` и `ДД.ММ.ГГГГ`; прочитанное значение можно записать обратно, не
переводя его руками. Если тип параметра объявлен датой, а переданное значение на дату не
похоже, операция отказывает и объясняет формат — вместо того чтобы записать строку, с
которой отчёт ничего не найдёт. Число, булево, строка и ссылочные значения сохраняются как
прежде.

### В разборе отчёта виден вид значения, а не только его текст

Дата, записанная строкой, и настоящая дата выглядят в разборе схемы одинаково: текст у них
один и тот же. Поэтому проверить, что значение легло нужным типом, было нечем — ни агенту,
ни постоянной проверке. Теперь рядом со значением приходит его вид: дата, число, булево,
строка, ссылка, список значений, стандартный период. Он есть у правого значения отбора, у
условия условного оформления и у значения параметра. Ошибку типа теперь видно чтением, а не
только запуском отчёта.

### Смена запроса набора не включает автозаполнение полей обратно

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

### Поле, убранное из набора, не оставляет отчёт нерабочим

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

## Справочная информация объектов

### Абзац в справку дописывается без пересылки всей страницы

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

### Чтение справки больше не обрывается молча

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

### Справка заимствованного объекта: честный отказ вместо успеха без результата

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

### Оформление не дублируется в теге

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

Теперь свойство попадает в тег один раз, и побеждает то значение, которое победило бы в
браузере: заданное точнее, а помеченное `!important` обычным не перебивается. Своё оформление
автора, написанное прямо в теге, по-прежнему главнее. Если ровно те же правила на странице уже
есть, второй такой же блок в заголовок не добавляется — об этом сказано в ответе.

## Расширения: состав заимствованного

### Правка оформления больше не отменяет чистку состава

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

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

### Кнопка стандартной команды не оставляет расширение несобираемым

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

Теперь такая кнопка сама доводит форму до состояния, которое платформа принимает. Делать для этого
ничего не нужно.

### Изменение состава расширения всегда названо в ответе

Заимствование реквизита формы (`adoptFormItem`) меняло состав расширения молча — и вдобавок
сообщало в ответе, что дополнительных изменений не потребовалось, хотя снятые ранее реквизиты и
объекты возвращались обратно. Понять это можно было, только сравнив состав расширения до и после
вручную.

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

### Основная таблица динамического списка в расширении

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

Теперь основная таблица заимствуется в расширение вместе с назначением — так же, как это давно
работает при создании самого реквизита-списка. Что именно затянуто в расширение, названо в ответе.

### Сокращение состава больше не упирается в ложный отказ

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

Теперь отказ приходит только там, где он обоснован — когда объект нужен собственному элементу
расширения. В тексте отказа названо, что именно удерживает объект, и указан способ проверить
результат: собрать файл поставки.

## Расширения информационной базы

### Установка и удаление расширения доводятся до конца

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

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

### Расширение ставится и в базу, опубликованную на веб-сервере

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

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

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

### Справку расширения, загруженного в базу, можно прочитать

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

## Обновление информационной базы

### Отмена обновления не отвечает успехом, когда отменять нечего

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

### Отказ обновления называет, кто держит базу

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

Теперь отказ называет занявшие базу сеансы поимённо: пользователь, номер сеанса, время
начала и приложение — и отдельно **вид держателя**, потому что от него зависит, что делать.
Держателем часто оказывается не человек, а программа: соединение с HTTP-сервисом у
опубликованной базы, внешнее соединение, фоновое задание. В таком случае в ответе прямо
сказано, что закрывать клиенты 1С бесполезно — их нет, и базу отпустит та программа, которая
открыла соединение. Клиенты 1С и конфигуратор названы своими словами, с рецептом под них.

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

### Занятую базу можно освободить, не выходя из вызова

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

Разрешить — `sync_database` с `terminateActiveSessions=true`: плагин ответит платформе
«Завершить сеансы и повторить», обновление пройдёт, а в успешном ответе будет громкое
предупреждение о том, что сеансы прерваны, — его нужно передать пользователю. Если у
платформы другой вопрос или нужен другой вариант ответа, его можно назвать явно параметром
`answerPlatformQuestion` — варианты с их кодами приходят в самом отказе и не зависят от языка
среды разработки.

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

### Загруженным считается только то, что база действительно приняла

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

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

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

### Успех загрузки подтверждается самой базой

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

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

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

## Схемы отчётов: значения, оформление и чтение

### Отбор по значению перечисления наконец отбирает

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

Теперь такое значение записывается так же, как его хранят типовые конфигурации. Пишется оно
привычным адресом — `Перечисление.СтатусыЗаказов.Закрыт`, а для пустой ссылки
`Справочник.Валюты.ПустаяСсылка`; принимаются и английские написания вида объекта. То же самое
работает в условии условного оформления и в значении параметра настроек. Опечатка в имени
значения больше не уходит в схему молча: операция отказывает и перечисляет значения
перечисления. Имя элемента проверяется не только у перечислений: у справочника и планов
значением может быть предопределённый элемент либо пустая ссылка, у документа, задачи,
бизнес-процесса и плана обмена — только пустая ссылка, и выдуманное имя отклоняется с
перечнем допустимого. Конкретный элемент базы по идентификатору отклоняется с объяснением, как
бы он ни был записан — схема живёт в конфигурации, а элементы у каждой базы свои, и такой отчёт
работал бы ровно в одной базе; если элемент выбирает пользователь, отбор выводится в шапку
отчёта. Число, булево и строка пишутся как прежде, дата — датой.
Подробности — `help topic=dcsReferenceValues`.

### Правка готового правила оформления работает

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

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

### Формат поля ставится одним вызовом

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

### Чтение схемы показывает то, что задано

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

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

## Макеты печатных форм

### Перенос текста по словам

Ячейке макета не удавалось задать перенос текста по словам: длинный заголовок колонки уходил
за её край или обрезался, и печатная форма средствами макета не версталась — оформление
приходилось дописывать кодом. Теперь размещение текста задаётся у ячейки прямо при её
заполнении: переносить по словам, обрезать, забивать или выходить на свободные соседние ячейки.

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

### Высота строки подбирается по содержимому

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

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

### Оформление ячейки можно прочитать обратно

Чтение макета возвращало только текст ячейки и имя параметра. Проверить собственную правку было
нечем: задал шрифт, цвет и выравнивание — и убедиться, что они легли, можно было только глазами
в среде разработки. Ячейка, у которой есть оформление, но нет текста, из карты макета пропадала
целиком.

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

### Неверное значение больше не проглатывается молча

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

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

### Формат числа и даты, отступ, поворот текста и защита ячейки

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

### Ширина колонки подбирается автоматически

Ширина колонки задавалась только точным числом. Теперь колонке можно включить автоподбор ширины
по содержимому и задать весовой коэффициент — долю, в которой между колонками делится свободное
место. Эти свойства платформа сохраняет начиная с режима совместимости 8.3.10.

### Прямоугольные области разрешены

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

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

### Макет внешней обработки описан в справке

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

### Оформление ячеек макета работает на 1C:EDT 2026.2

На 1C:EDT 2026.2 задать ячейке макета шрифт или границы было нельзя: вызов завершался
внутренней ошибкой среды, и печатная форма оставалась без оформления. На 1C:EDT 2026.1 то же
самое работало, поэтому проблема выглядела как случайный сбой. Оформление ячеек макета —
шрифт, начертание, размер, гарнитура, границы и их стиль — теперь применяется одинаково
на обеих версиях среды разработки.
