Функция проверить работает 1с

Обновлено: 06.07.2024

Проектирование в 1С очень часто пропускается. Если оно и происходит, то только в достаточно небольшом объеме, и то только у серьезных команд. Чаще всего, оно происходит в уме (где-то, как-то).

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

Дальше идет следующий этап – это этап тестирования. То есть, тестирование – это мы проверяем требования заказчика (требования, которые мы должны выполнить).

Дальше идет поиск ошибок, отладка.

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

Есть такой закон, который я, например, прочитал у Макконелла – Главный закон качества ПО:

Повышение качества программного обеспечения снижает затраты на разработку и сопровождение системы.

Что это означает? Это означает, что чем лучше у нас написана система, чем лучше она спроектирована, чем лучше обоснованы связи, тем легче мы сможем ее дорабатывать, исправлять и т.д.

Пример правильности этого закона: Отладка и исправление неверного кода занимает около 50 % времени. То есть – 50 % времени всей разработки мы тратим на поиск ошибок.

Это касается как крупных проектов, так и мелких. Методик, чтобы снизить свои затраты и не допустить ошибок, очень много – главный принцип, которого нужно придерживаться в разработке, используя разные методики, - это просто их использовать (использовать комбинации методик, использовать одну методику, а не просто писать свой код не думая над ним, не исправляя его).

Методики разработки

Защитное программирование
Обзоры кода
Проектирование
Тестирование
Экстремальное программирование

Я лично пользуюсь всеми перечисленными методиками.

Защитное программирование – это методика, когда мы ведем разработку и само написание кода помогает нам не допускать ошибок. То есть, в этом случае мы что делаем? Мы проверяем данные.
Элементарный пример – у нас есть какая-то функция, которая принимает входные параметры определенного типа, определенных значений. Мы можем в функции сделать предположение (так называемый инвариант или утверждение) и проверить эти предположения. То есть, мы не пишем, как 1С привыкла: параметр и в комментариях пишем, что тип такой-то, значения такие-то, варианты и так далее… Мы можем прямо написать утверждение – вот этот параметр должен быть такого типа. Если это утверждение не выполняется, программа просто выдает исключение и останавливает свою работу, потому что это является ошибкой разработки.
Следующая методика – это «Обзоры кода». То есть, мы можем читать чужой код. То есть, один кто-то написал код, мы можем попросить соседнего разработчика, руководителя посмотреть и проанализировать ошибки, которые были допущены в этом коде. Это методика очень эффективна.
Я люблю читать чужой код, люблю свой код пересматривать. Таким образом находится достаточное число ошибок.
Следующая методика - проектирование. Чем лучше мы построим программу, чем лучше продумаем связи, чем лучше продумаем архитектуру, интерфейсы взаимосвязей, тем лучше наша система будет работать, тем удобнее нам ее будет исправлять.
Методика, которая известна лучше всех предыдущих – это тестирование. Фактически, каждый разработчик выполняет эту функцию, применяет методику тестирования. Но очень многие проверяют в уме. То есть этот код должен получить такие-то результаты… Мы проверяем какой-то один вариант, проверяем два варианта, проверяем три варианта… А на самом деле в сложных системах вариантов очень много и их нужно проверять достаточно большое количество. И когда вариантов очень много для проверки, фактически получается, что они не проверяются все. У меня есть пример, есть система, идет цикл разработки, система отдается на проверку пользователю. У пользователя стоит тестирование – проверить 40 разных пунктов – релиз выпускается, например, раз в два месяца (или в месяц). Пользователь должен перед выпуском каждого релиза проверить 40 пунктов – это тяжело и он никогда практически не будет этого делать. Он будет помнить, что он это проверял в прошлый раз – и сегодня он этого делать не будет, потому что тогда на это придется потратить весь день. Как правило, отдельный тестировщик на проекте есть очень редко, обычно человек должен выполнить функцию тестировщика и выполнить свою основную функцию. В итоге функции тестировщика, как правило, пропускаются и тестирование не выполняется в полном объеме.
Дальше я еще потом на тестировании остановлюсь…
Следующая – очень эффективная методика – это методикаэкстремального программирования. Это методика свежая, буквально начала-середины 90-х годов. На западе очень сильно распространена, очень много информации по ней. У нас применяется не так много. Иногда эту методику называют «гибкие методики разработки», иногда – экстремальное программирование.

Экстремальное программирование

У него есть несколько принципов:

Единая команда
Совместное владение кодом системы
Обзоры кода и парное программирование
Разработка через тестирование (TDD)
Функциональное тестирование
Рефакторинг
Простота
Короткие циклы
Непрерывная интеграция
Улучшение дизайна, постоянное планирование

Расскажем о них поподробнее:

Вернемся к тестированию. Будем говорить только о тестировании.

Виды тестирования

Модульное тестирование (юнит-тестирование)
Функциональное тестирование
Тестирование методом черного ящика и методом белого ящика
Нагрузочное тестирование
Тестирование разработчиком и специальными тестерами
Самый проблемный вид тестирования – тестирование пользовательского интерфейса

Теперь об этих видах тестирования подробнее:

Сейчас немного коснусь существующих систем тестирования

Существующие системы тестирования

Первое, с чем мы знакомы, когда говорим «Тестирование 1С» - это, конечно конфигурация «Сценарное тестирование» (входит в пакет 1С:КИП).
Мое мнение вкратце – не пригодно оно к реальному использованию.
Оно сделано больше для функционального тестирования и очень сильно зависит от изменений в программе.
Если в форме добавился какой-то реквизит, Сценарное тестирование может вылетать, если в форме удалился какой-то реквизит – Сценарное тестирование может вылетать.
Нет возможности исключить ошибки, прогнать все тесты за исключением ошибок. Если есть ошибка, тест остановится весь.
Кроме этого, неприятным моментом является то, что конфигурация «Сценарное тестирование» не продается отдельно от пакета конфигураций «Корпоративный инструментальный пакет». А цена этого пакета очень велика.
Хотя – лично мое мнение, что тестирование в 1С должно быть бесплатным.
Есть очень хорошая подсистема (автор - Сергей Старых) – называется Подсистема «Инструменты разработчика».
В этой подсистеме недавно появилось тестирование. Были введены начальные понятия тестирования – тестируются все формы и часть метаданных, то есть, тестируется открытие всех форм, которые есть в конфигурации, для документа тестируется проведение документа, запись документа, удаление документа и т.д.
Самое интересное – тестируются события и интерактивные изменения форм.
Например, тестируется ввод пользователем. Как будто пользователь вручную вносит данные. Это очень важно.
Не в одной из систем, о которых я расскажу далее, нет тестирования этих интерактивных изменений. Например, там можно протестировать поиск по форме (по списку). То есть, как будто пользователь набирает символы, и подсистема это отрабатывает. Очень полезный инструмент.
Еще есть некоторые публикации на сайте «Инфостарт».

Одна из самых первых разработок, поэтому я о ней упомянул.
Она неудобная и непродуманная на самом деле.

Это опять же, зачаточный такой модуль, просто пример того, как это можно организовать в 1С.

достаточно интересная, но почему-то автор ее удалил

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

Дальше я укажу те системы, которые я сам реально использовал, с которых мое знакомство с системами тестирования для 1С началось:

Я ее в 8.2 до сих пор успешно использую.
Недостатки: немного устарела, нет управляемых форм

Шаги в нужном направлении
Только Управляемое приложение

В этом тестировании используется два клиентских приложения. Одно приложение является тестером, другое приложение является клиентом.

То есть, толстый клиент или тонкий клиент менеджер тестирования взаимодействует (общается) с клиентом тестирования (толстым, тонким или Web-клиентом).
То есть – пишется тест на языке 1С. И заданные действия выполняются в клиенте тестирования.

Пример вызова приложения-теста

На данном скриншоте красная стрелка как раз показывает – есть вариант вызова записи действий пользователя, то есть в 8.3 можно использовать следующую схему работы:

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

(я фактически ее product-owner и один из авторов) -

Защитное программирование

Защитное программирование – очень важный этап применения методики тестирования

На своем опыте - а я общался с разными программистами, специалистами - очень мало народу почему-то использует утверждения. А этот метод очень удобен в разработке.

Использование инвариантов/утверждений

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

Потому что иногда начинают использовать утверждения для передачи данных во внешнюю систему – это неправильно. Это уже не утверждение.

Я использую утверждения для разных случаев – у меня есть функция, например, в которой я знаю, что должен быть передан параметр, например СправочникСсылка.Номенклатура. Я так и пишу в коде:
Тесты.ПроверитьТип(Параметр, СправочникСсылка.Номенклатура)

Теперь – самое интересное: Тестирование разработчиком и разработка через тестирование.

Тестирование разработчиком

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

Затруднение у разработчиков (Цель тестирования отлична от других этапов разработки, Тестирование требует поиска ошибок в своем коде)
Тестирование разработчиком вызывает затруднения, потому что цель тестирования отлична от цели разработки. То есть от разработки мы хотим получить правильный код, который правильно работает, получает верные результаты, содержит минимум ошибок и т.д. А в тестировании мы должны найти ошибки, наоборот. Иногда бывает это трудно. Разработчику бывает лень искать ошибки. Разработчик не понимает, что ошибки нужно искать и т.д.
Тестирование никогда не доказывает отсутствия ошибок.
Но наличие тестов – это лучше, чем отсутствие тестов.

Что еще можно сказать об основных требованиях к тестированию:

Два главных требования тестирования:

Тестирование должно быть автоматизированным. А еще лучше – автоматическим 100%. Если тестирование не будет автоматизированным, его никто никогда выполнять не будет.
Тестирование должно быть быстрым.
Если тесты будут выполняться медленно, их опять же никто не будет делать. Это все из опыта.

Разработка через тестирование (TDD)

Быстро расскажу о результатах, которых можно достичь, используя методику разработки через тестирование:

Результаты использования TDD

Здесь указаны основные принципы, как надо выполнять разработку через тестирование (TDD).

Описание процедур и функций

Область применения: управляемое приложение, мобильное приложение, обычное приложение.

1. Описание процедур и функций рекомендуется выполнять в виде комментария к ним. Необходимость комментирования отдельных участков кода процедур и функций должна определяться разработчиком исходя из сложности и нестандартности конкретного участка кода.

При разработке на платформе 1С:Предприятие 8.3 текст комментария также выводится в контекстной подсказке процедур, функций и их параметров. Подробнее см. раздел «Контекстная подсказка при вводе текстов модулей» главы 27 «Инструменты разработки» в документации к платформе.

При разработке в 1C:Enterprise Development Tools (EDT) текст комментария также используется для уточнения типизации параметров и возвращаемого значения процедур и функций, и тем самым помогает выявлять ошибки кодирования на этапе разработки.

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

3. Прочие процедуры и функции (в том числе обработчики событий модулей форм, объектов, наборов записей, менеджеров значений и т.п.) рекомендуется комментировать, если требуется пояснить назначение процедуры (функции) или особенности её работы. Также рекомендуется описывать причины невыполнения некоторых действий, если они кажутся неочевидными для данной процедуры или функции.

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

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

В этих примерах комментарии избыточны, так как из названий процедур очевидно, что это обработчики событий. А с их описанием и назначением параметров можно ознакомиться в синтакс-помощнике.

Этот комментарий не дает никакой дополнительной информации о функции.

5. Комментарий размещается перед объявлением процедуры (функции) и имеет следующий вид.

5.1. Секция "Описание" (англ. "Description" ) содержит описание назначения процедуры (функции), достаточное для понимания сценариев ее использования без просмотра ее исходного кода. Также может содержать краткое описание принципов работы и перекрестные ссылки на связанные процедуры и функции.

Может быть единственной секцией для процедур без параметров. Описание не должно совпадать с именем процедуры (функции). Для процедур и функций секция должна начинаться с глагола. Для функций это, как правило: «Возвращает…». В тех случаях, когда возвращаемый результат является не основным в работе функции, – то с основного действия, например: «Проверяет…», «Сравнивает…», «Вычисляет…» и т.п. Не рекомендуется начинать описание с избыточных слов «Процедура. », «Функция. », а также с имени самой процедуры (функции), от удаления которых смысл не меняется.

5.2. Секция "Параметры" (англ. "Parameters" ) описывает параметры процедуры (функции). Если их нет, секция пропускается. Предваряется строкой "Параметры:", затем с новой строки размещаются описания всех параметров.

5.2.1. Описание параметра начинается с новой строки, далее имя параметра, затем дефис и список типов (*), далее дефис и текстовое описание параметра.

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

Описание типа является обязательным. Тип может быть описан явно, при этом может быть указан или один тип или список типов. Под «списком типов» подразумеваются имена типов, разделенные запятыми. Имя типа может быть простым (в одно слово) или составным - в два слова, разделенных точкой.
Например: Строка, Структура, Произвольный, СправочникСсылка.Сотрудники .

В качестве типов значений следует использовать только существующие в платформе типы, а также специальные типы, предусмотренные в EDT: ОпределяемыйТип.<Имя> , СправочникСсылка , ОбъектМетаданныхОтчет , РасширениеДекорацииФормыДляНадписи и т.п.

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

// Проверяет, что переданные адреса включены в задачу. Если проверка не проходит – генерируется исключение.
//
// Параметры:
// Адреса - Строка - строка, содержащая электронные адреса
// ЗадачаИсполнителя - ЗадачаСсылка.ЗадачаИсполнителя – проверяемая задача
//
Процедура ПроверитьАдресаЗадачи( Адреса, ЗадачаИсполнителя )

В данном примере текстовое описание для параметра «Адреса» нужно чтобы

указать правило передачи нескольких адресов (через зяпятую);
привести пример.

Текстовое описание для параметра ЗадачаИсполнителя не нужно.

5.2.2. Для параметров типа Структура и ТаблицаЗначений также задается описание их свойств и колонок, которые начинаются с новой строки и предваряются символом *.
Например:

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

5.2.3. Для параметров типа Массив следует указывать тип элементов с помощью ключевого слова "из" (англ. "of" ):

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

5.2.4. Также для параметра типа СтрокаТаблицыЗначений ( СтрокаДереваЗначений ) возможно задать состав свойств, соответствующий колонкам его таблицы-владельца (дерева-владельца):
Например:

// СведенияОРегионе – СтрокаТаблицыЗначений: см. РегистрыСведений.АдресныеОбъекты.КлассификаторСубъектовРФ

где КлассификаторСубъектовРФ - экспортная функция модуля менедежра регистра сведения АдресныеОбъекты, которая возвращает таблицу значений.

5.2.5. Также для каждого параметра можно задать одно или несколько дополнительных описаний типов параметра. Каждое дополнительное описание начинается с новой строки, затем обязательный дефис, далее список типов параметра далее дефис и текстовое описание.
Например:

5.2.6. Описание также могут быть заданы с помощью ссылки на функцию-конструктор в формате "см. ПутьКФункции" (англ "see MethodPath" ).
Например:

// ПараметрыУказанияСерий - см. НоменклатураКлиентСервер.ПараметрыУказанияСерий
// Дубли - см. ОбработкаОбъект.ПоискИУдалениеДублей.ГруппыДублей
// РеквизитыКомпонент - Массив из см. ВнешниеКомпоненты.РеквизитыКомпоненты

При разработке кода, обращающегося к реквизитам конкретного объекта метаданных или формы, можно ссылаться на типы реквизитов этого объекта (формы):

Также в редких случаях, когда подходящей функции-конструктора не существует и ее невозможно создать, допустимо указывать ссылку на другую процедуру (при полном совпадении параметров) или на параметр другой процедуры или функции, например:

// См. ПодключаемыеКомандыПереопределяемый.ПриОпределенииКомандПодключенныхКОбъекту
//
Процедура ПриОпределенииКомандПодключенныхКОбъекту(НастройкиФормы, Источники, ПодключенныеОтчетыИОбработки, Команды) Экспорт

// Параметры:
// НастройкиФормы - см. ПодключаемыеКомандыПереопределяемый.ПриОпределенииКомандПодключенныхКОбъекту.НастройкиФормы
// Источники - см. ПодключаемыеКомандыПереопределяемый.ПриОпределенииКомандПодключенныхКОбъекту.Источники
// ПодключенныеОтчетыИОбработки - см. ПодключаемыеКомандыПереопределяемый.ПриОпределенииКомандПодключенныхКОбъекту.ПодключенныеОтчетыИОбработки
// Команды - см. ПодключаемыеКомандыПереопределяемый.ПриОпределенииКомандПодключенныхКОбъекту.Команды
//
Процедура ПриОпределенииКомандПодключенныхКОбъекту(НастройкиФормы, Источники, ПодключенныеОтчетыИОбработки, Команды) Экспорт

5.3. Секция "Возвращаемое значение" (англ. "Returns" ) описывает тип и содержание возвращаемого значения функции. Для процедур эта секция отсутствует. Предваряется строкой "Возвращаемое значение:". Затем с новой строки тип возвращаемого значения, дефис и текст описания. При использовании возвращаемого значения составного типа следует каждый тип писать с новой строки и с дефиса. Например:

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

Для возвращаемых значений также действуют требования п.5.2.2 и 5.2.3.

5.4. Секция "Пример" (англ. "Example" ) содержит пример использования процедуры, или функции. Предваряется строкой "Пример:". Далее с новой строки пример использования. Имя процедуры (функции) следует писать вместе с именем общего модуля, в котором она расположена. Из примера должно быть понятно, что передается на входе и что возвращается на выходе.
Например, неправильно:

5.4.1. В переопределяемых модулях в секции "Пример" следует размещать пример реализации переопределяемой процедуры, а не пример ее вызова. Например, для процедуры ПриОпределенииОбщихПараметровБазовойФункциональности(ОбщиеПараметры):

5.5. В редких случаях, когда сразу несколько параметров имеют дополнительные типы, рекомендуется добавить секцию "Варианты вызова" (англ. "Сall options" ), в которой дать описания наиболее частых или всех возможных вариантов вызова функции с различными комбинациями типов параметров. Секция начинается фразой "Варианты вызова:" с новой строки, затем идут описания вариантов, каждое начинается с новой строки. Каждый вариант вызова представляется в виде имени функции со списком типов, перечисленных через запятую в круглых скобках, затем следует дефис и текстовое описание варианта.

5.6. В любом месте документирующего комментария можно добавить переход к другим объектам конфигурации, процедурам и функциям (в частности, для перехода к функциям-конструкторам структур). При использовании 1C:Enterprise Development Tools среда оформит такие переходы в виде гиперссылки.
Например:

5.7. В случаях когда возникает необходимость отметить процедуру (функцию) как устаревшую, в первой строке ее описания размещается слово "Устарела" (англ. "Deprecated" )..
Например:

6. Если требуется прокомментировать процедуру или функцию с директивой компиляции, то вначале следует размещать комментарий, а затем -
директиву компиляции. Например:

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

7. Код процедур и функций должен отделяться друг от друга в тексте модуля пустыми строками.

Примеры описания процедур и функций

Пример описания функции с одним параметром:

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

Для автоматического упорядочивания комментариев к процедурам или функциям с директивами компиляции можно воспользоваться приложенной обработкой ФорматированиеДирективКомпиляции.epf .

Проверка с помощью функции глобального контекста РольДоступна()

Если в программном коде необходимо проверить установлена ли какая-либо роль у текущего пользователя, то можно воспользоваться функцией глобального контекста РольДоступна(<Роль>), которая возвращает значение Истина, если указанная в скобках роль доступна и Ложь, если не доступна.

Однако, в конфигурациях на основе БСП при включении пользователя в предопределенную группу доступа Администраторы, пользователю назначаются только две роли: Полные права и Администрирование (в этом можно убедиться с помощью Конфигуратора: Администрирование - Пользователи - Пользователь - Прочие). Все остальные роли отключаются вне зависимости от того, включен ли пользователь в какие-либо еще группы доступа. Система считает, что другие роли этому пользователю не нужны. Поэтому функция РольДоступна() возвращает в этом случае Ложь, что не подходит для решения нашей задачи.

Проверка с помощью функций БСП

Проверить наличие роли можно также с помощью функций БСП: Пользователи.РолиДоступны() и УправлениеДоступом.ЕстьРоль(). Но данные функции для полноправного пользователя (с ролями Полные права или Администратор системы) вернут всегда Истину независимо от того, назначена ли данная роль пользователю или нет:

Можно было пойти по легкому пути, скопировать данные функции и убрать в них проверку на полноправного пользователя, но мы ~~не ищем легких путей~~ это бы нам не помогло, так как функция Пользователи.РолиДоступны() все равно используют функцию глобального контекста РольДоступна(), а функция УправлениеДоступом.ЕстьРоль() слишком громоздка (текст функции около 300 строк при этом текст основного запроса около 200 строк).

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

Решение

Для решения этой задачи в любой конфигурации на базе БСП я использую свою функцию:

Буду признателен, если Вы будите делиться своим опытом решения данной задачи.

Ниже рассмотрим основные методы использования механизма отладки в виде практической инструкции на конкретном примере.

Внимание! Если Вы используете клиент-серверный режим работы (на сервере), Вам необходимо включить отладку на сервере 1С Предприятия.

Запуск отладки в 1С

Отладка фоновых заданий 1С

Если вы только начинаете программировать в 1С или просто хотите систематизировать свои знания - попробуйте Школу программирования 1С нашего друга Владимира Милькина. Пошаговые и понятные уроки даже для новичка с поддержкой учителя.
Попробуйте бесплатно по ссылке >>

В этом окне Вы можете установить соответствующий флаг.

Установка точки останова (брейкпойнта)

Для того чтобы установить точку останова, необходимо найти нужный программный код и кликнуть дважды на поле, слева от поля ввода кода (или нажать кнопку F9):

Точка останова 1С с условием (синяя)

Например, остановим цикл на строке с номером 25:

Неактивная точка останова (серая)

Точка останова по ошибке

Пошаговое перемещение по программному коду 1С

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

Чтобы перейти с текущего положения курсора к нужному, минуя промежуточные строчки кода, необходимо установить курсор на нужной строке и нажать shift + F10 (Идти до курсора).