Конструктор запросов 1С теряет комментарии: почему и как это исправить

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

Почему конструктор запросов 1С стирает комментарии

Разработчик компании на 30 пользователей пол-дня собирает запрос для отчёта по остаткам: добавляет соединение с регистром сведений по пересчёту единиц, вписывает три строки комментариев: почему условие отбора именно такое и какую ошибку клиента оно закрывает. Через два дня открывает тот же запрос в конструкторе, чтобы добавить ещё одно поле в выборку. Жмёт «ОК» — и все три строки комментариев исчезают вместе с форматированием. Восстановить их через Ctrl+Z нельзя: конструктор уже пересобрал текст заново.

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

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

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

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

Как исправить потерю комментариев в запросе 1С

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

Где взять запрос с комментариями обратно

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

Инженерная консоль запросов вместо стандартного конструктора

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

Что делать, если ошибка повторяется

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

Если потеря повторяется, устного правила недостаточно, нужен процесс:

• ✓Ввести код-ревью для изменений в СКД-отчётах и запросах перед закрытием задачи, сверять актуальный текст с последней сохранённой версией по хранилищу.
• ✓Хранить эталонный текст ключевых запросов вне 1С, отдельным файлом в задаче или в общем репозитории, синхронизировать при значимых правках.
• ✓Перевести объекты с критичной логикой запросов на разработку через EDT с Git — там текст хранится построчно, конфликт слияния виден в дифф-отчёте, а потеря комментариев обнаруживается на этапе проверки, а не через два месяца после релиза.
• ✓Закрепить в регламенте разработки: конструктор — инструмент для черновика новой логики, финальный текст с комментариями редактируется вручную в консоли.

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

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

Как предотвратить потерю комментариев в запросах 1С

Правила, которые снимают проблему на уровне процесса, а не памяти конкретного разработчика:

• ✓Не открывать конструктор на финализированном тексте запроса с комментариями, новое поле добавлять вручную, по аналогии с соседними строками.
• ✓Держать блок комментариев в шапке запроса с пометкой, что текст редактируется только вручную, а не через визуальный конструктор.
• ✓Перевести отчёты со сложной логикой на разработку через EDT и Git, где потеря видна в истории коммитов до того, как попадёт в рабочую базу.
• ✓Включить эту особенность в адаптацию новых разработчиков и подрядчиков: она не очевидна, пока не столкнёшься с ней один раз на боевых данных.

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

Сколько стоит настроить процесс, чтобы комментарии не терялись 💰

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

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

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

❓ Частые вопросы

Почему в 1С после конструктора запроса пропадают комментарии?

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

Можно ли восстановить комментарии, если запрос уже пересобран конструктором?

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

Теряются ли комментарии в отчётах на системе компоновки данных?

Да, механика та же самая. Если запрос отчёта СКД редактируется через конструктор набора данных, а не через закладку с текстом, любое ручное форматирование и комментарии теряются при первом сохранении настройки схемы компоновки. Это касается и 1С:ERP, и 1С:Управление торговлей, и любой другой конфигурации на этой платформе.

Что делать, если в компании нет хранилища конфигурации и Git?

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

Сколько стоит настроить процесс, чтобы комментарии в запросах не терялись?

Стоимость зависит от числа отчётов со сложной логикой и текущей инфраструктуры команды: работа идёт по ставке сопровождения от 3800 руб/час. Точную оценку даём после аудита отчётов и того, как сейчас организована разработка. Для команды на разрозненных локальных базах имеет смысл сначала объединить среду через аренду сервера 1С от 3300 руб/мес.