Смена автора и ответственного по документу в 1С

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

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

Что такое автор документа и почему его не переписать в форме

В типовых конфигурациях встречаются два похожих реквизита, и их часто путают:

• 🧑‍💼 Ответственный — пользователь, отвечающий за документ. Есть в большинстве типовых: БП 3.0, УТ 11, ЗУП 3.1. Обычно доступен для изменения в карточке.
• ✍️ Автор — тот, кто создал объект. Встречается в 1С:Документооборот и в ряде отраслевых решений. Чаще служебный и правке через форму не поддаётся.

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

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

Способов три, и выбирают их по объёму и по тому, доступен ли реквизит:

В 1С:Документооборот «Автор» — полноценное поле карточки, и там его меняют средствами самой программы (при наличии прав), а описанные ниже технические приёмы нужны для типовых учётных конфигураций, где поле служебное.

Групповое изменение реквизитов — штатный способ режима «Предприятие»

Это основной инструмент библиотеки стандартных подсистем (БСП). Он меняет реквизит сразу у выбранных объектов одного вида, не трогая остальное.

Как открыть обработку:

1. Включите команду «Все функции», если её нет: Главное меню → Сервис → Параметры → галочка «Отображать команду “Все функции”».
2. Откройте Главное меню → Все функции → Стандартные → Групповое изменение реквизитов. В БП 3.0 она доступна ещё и через Администрирование → Обслуживание → Корректировка данных.
3. В поле «Изменять» выберите вид документа, например Документ.РеализацияТоваровУслуг.
4. Задайте отбор — например, по старому ответственному, чтобы захватить только его документы.
5. На вкладке реквизитов найдите Ответственный (или Автор) и укажите нового пользователя.
6. Нажмите «Изменить реквизиты».

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

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

Правка ответственного в карточке одного документа

Если нужно поправить один документ и реквизит «Ответственный» на форме доступен — ничего изобретать не нужно.

1. Откройте документ.
2. Найдите поле Ответственный (в БП 3.0 оно обычно в подвале формы или на отдельной вкладке).
3. Выберите другого пользователя и запишите документ.

Если поля на форме не видно, добавьте его через Ещё → Изменить форму — в дереве реквизитов поставьте галочку у «Ответственный». Когда поле есть, но закрыто для изменения (серое), в карточке его не поправить — переходите к групповому изменению или коду. Поле «Автор» в карточке почти всегда только для чтения, его через форму не изменить.

Через внешнюю обработку и код (режим «Конфигуратор»)

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

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

СтарыйПользователь = Справочники.Пользователи.НайтиПоНаименованию("Иванов");
НовыйПользователь  = Справочники.Пользователи.НайтиПоНаименованию("Петров");

Запрос = Новый Запрос;
Запрос.Текст =
    "ВЫБРАТЬ Ссылка
    |ИЗ Документ.РеализацияТоваровУслуг
    |ГДЕ Ответственный = &Старый";
Запрос.УстановитьПараметр("Старый", СтарыйПользователь);

Выборка = Запрос.Выполнить().Выбрать();
Пока Выборка.Следующий() Цикл
    Объект = Выборка.Ссылка.ПолучитьОбъект();
    Объект.Ответственный = НовыйПользователь;
    Объект.ОбменДанными.Загрузка = Истина; // пишем без автозаполнения и перепроведения
    Объект.Записать();
КонецЦикла;

Что здесь важно:

• 🔑 Ответственный замените на реальное имя реквизита своей конфигурации (может быть Автор).
• 🛡️ Строка Объект.ОбменДанными.Загрузка = Истина; отключает бизнес-логику записи: документ не перепроводится, движения по регистрам не пересчитываются. Без неё платформа может заново заполнить реквизит или переписать движения.
• 🧪 Прогоните код сначала на копии базы. Запускать нужно под пользователем с полными правами.

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

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

Прямое изменение в SQL — крайняя мера

Технически значение можно переписать прямо в таблице СУБД командой UPDATE. На практике это последний вариант, к которому прибегают, когда в саму платформу зайти уже нельзя.

Почему способ рискованный:

• 📛 Фирма «1С» не поддерживает прямое изменение базы на уровне СУБД. Имена таблиц и полей обфусцированы (вида _Document123, _Fld5678) и не читаются без карты структуры.
• 🧨 Платформа кэширует данные. Правка в обход платформы может разойтись с кэшем и привести к ошибкам до перезапуска кластера.
• 🔒 Писать нужно в правильное поле нужной таблицы — ошибка здесь портит данные без возможности отката.

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

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

Что останется в журнале регистрации и аудите

Главное, что нужно понимать про смену автора: вы меняете значение реквизита, а не историю действий.

Журнал регистрации (Главное меню → Все функции → Стандартные → Журнал регистрации, в БП 3.0 — Администрирование → Обслуживание → Журнал регистрации) фиксирует сеансы и изменения данных отдельно от реквизитов документа. В нём по-прежнему будет видно:

• кто и когда реально создал документ;
• что потом реквизит «Автор» изменил такой-то пользователь — сама правка тоже попадёт в журнал под вашей учётной записью.

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

Вывод: смена автора уместна для порядка в учёте (например, передать документы новому ответственному), но она не поможет «переписать» историю для проверки. Для аудита первоисточник — журнал регистрации, а не реквизит.

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

Частые ошибки при смене автора

• ❌ Поменяли реквизит и ждут изменений в журнале. Журнал регистрации не меняется — это разные механизмы.
• ❌ Перепровели документ при правке в карточке. Документ встал в текущую дату/изменил движения. В коде спасает ОбменДанными.Загрузка = Истина.
• ❌ Поправили не тот реквизит. «Автор», «Ответственный» и «Подразделение» — разные поля. Уточните, что ищете, до правки.
• ❌ Запустили групповое изменение без отбора. Один пользователь проставился всем документам вида. Всегда задавайте отбор и делайте копию.
• ❌ Правили SQL на рабочей базе без бэкапа. Откатить изменение будет нечем.

Как не возвращаться к этой задаче

Чаще всего автора приходится менять из-за беспорядка с учётными записями. Несколько простых правил снимают проблему на будущее:

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

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