Скрипты в 1С:Документооборот: как писать и не сломать процессы

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

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

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

Где в Документообороте используются скрипты

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

• Бизнес-процессы — скрипты в точках маршрута: выбор исполнителя, условие перехода, действия «выполнение» и «проверка условия».
• Обработчики событий — код, срабатывающий при создании, изменении, записи документа, файла или задачи.
• Автоподстановки — вычисляемые значения в шаблонах документов и файлов (например, автоматическое формирование заголовка).
• Правила обработки писем и загрузки файлов — скрипты определения адресата, папки, вида документа.

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

Синтаксис и доступные объекты

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

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

Пример простого скрипта условия, который проверяет заполненность суммы в документе:

Если ЗначениеЗаполнено(Источник.СуммаДокумента)
И Источник.СуммаДокумента > 100000 Тогда
Результат = Истина;
Иначе
Результат = Ложь;
КонецЕсли;

Как написать первый скрипт: пошаговый порядок

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

1. 1
   Сформулируйте задачу одним предложением: что должно произойти и при каком условии.
2. 2
   Найдите точку внедрения: обработчик события, условие процесса или автоподстановку.
3. 3
   Откройте подсказку настройки и выпишите доступные переменные контекста.
4. 4
   Напишите код с проверками ЗначениеЗаполнено() и блоком Попытка/Исключение.
5. 5
   Протестируйте на копии базы или на тестовом документе с несколькими наборами данных.
6. 6
   Проверьте граничные случаи: пустые поля, незаполненный контрагент, отменённый документ.
7. 7
   Только после успешных проверок перенесите скрипт в рабочую базу.

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

Типовые сценарии с примерами

Автоматический выбор исполнителя по подразделению

Частая задача — направить задачу согласования руководителю подразделения автора документа. Скрипт в точке выбора исполнителя получает подразделение из документа и находит ответственное лицо через соответствующий регистр или реквизит подразделения.

Попытка
Подразделение = Источник.Подразделение;
Если ЗначениеЗаполнено(Подразделение)
И ЗначениеЗаполнено(Подразделение.Руководитель) Тогда
Результат = Подразделение.Руководитель;
Иначе
Результат = Неопределено;
КонецЕсли;
Исключение
Результат = Неопределено;
КонецПопытки;

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

Заполнение полей при записи документа

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

Проверка условия в маршруте

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

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

Отладка и проверка результата

Полноценный интерактивный отладчик для скриптов, выполняемых внутри процессов, обычно недоступен, поэтому отладка строится на журналировании. Самый надёжный приём — записывать промежуточные значения в журнал регистрации через ЗаписьЖурналаРегистрации() и затем смотреть их в разделе администрирования.

ЗаписьЖурналаРегистрации("ОтладкаСкрипта",
УровеньЖурналаРегистрации.Информация,,,
"Подразделение: " + Строка(Подразделение));

После внедрения скрипта проверьте его на минимальном наборе сценариев: штатный случай, пустые реквизиты, документ, созданный не вручную (обменом или загрузкой). Именно нестандартные способы создания чаще всего ломают скрипты, которые «вчера работали».

Контрольные точки

Как проверить результат

Запуск процесса

Норма

Процесс стартует и уходит по нужной ветке маршрута

Тревожный признак

Процесс останавливается с ошибкой или зависает на точке со скриптом

Журнал регистрации

Норма

Есть отладочные записи, ошибок выполнения скрипта нет

Тревожный признак

Записи об ошибке выполнения внешнего кода или обработчика

Данные документа

Норма

Реквизиты заполнены ожидаемыми значениями

Тревожный признак

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

Ограничения и риски

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

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

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

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

Когда скриптов недостаточно

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

Сравнение вариантов

Скрипт в настройках

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

Расширение конфигурации

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

Доработка конфигурации

Для глубоких изменений механизмов. Максимальные возможности, но усложняет обновления и требует разработчика.

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

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

Нужно ли снимать конфигурацию с поддержки, чтобы использовать скрипты?

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

Можно ли отладить скрипт через точку останова в конфигураторе?

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

Что произойдёт с запущенными процессами, если изменить скрипт?

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

Почему скрипт работает у администратора, но не работает у пользователя?

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

Как перенести скрипты из тестовой базы в рабочую?

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

Можно ли в скрипте выполнять запросы к базе?

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