Уважаемые господа!
Есть некое регламентное задание, суть которого сводится к проведению некоторых докуентов. Документы может также проводить простой пользователь. Вопрос, как-нибудь программно можно узнать кто осуществляет проведение, пользователь или фоновое задание?
Может быть есть что-то типа

#Если ФоновоеЗадание Тогда
ЗаписатьЛогСообщений(ТекстСообщения);
#Иначе
ОбщегоНазначени.СообщитьОбОшибке(ТекстСообщения);
#КонецЕсли

получить пользователя?

(1) глЗначениеПеременной("глТекущийПользователь")= Неопределено ?
А может ли в другой ситуации быть неопределённым текущий пользователь?

(2) Да. Если он не определен.
А зачем тебе знать такие вещи вообще?

(3) Похоже там всё же пользователь "Не авторизован".
Ну условно говоря, реализую методику отложенного проведения. Надо куда-то логи ошибок проведения писать . Кроме того, принимать решение в каком режиме проводить документ надо в зависимости от пользователя, а для фонового задания по-другому. В общем, пока нет ничего такого, что бы я не обошёл... Интерес у меня такой, полуакадемический..

"Кроме того, принимать решение в каком режиме проводить документ надо в зависимости от пользователя, а для фонового задания по-другому" - расстреливать за такое. Тупыми пулями.

(5) Да вы что... надо же. Обоснуйте.

(6) А чего тут обосновывать? Логика проведения не должна зависеть от пользователя. Это настолько очевидный факт, что мне вообще непонятно, как такое людям приходит в голову, и что именно вам объяснять.

(7) Не зависить от пользователя? - возможно, с этим согласен.
А вот определить как проводиться документ :
Интерактивно пользователем, т.е. можно использовать Предупредить(), Сообщить() и т.д., либо на сервере в рамках фонового задания (к примеру восстановление последовательности) бывает просто необходимо.
Пример :
Интерактивное проведение - Сообщить("Документ не проведен, нет товра!")
Фоновое проведение - ЗаписатьВЛог("Документ не проведен, нет товра!");

(8) ОбщегоНазначения.СообщитьОбОшибке(). И не надо даже думать.
Если уж совсем охота - #Если Клиент ... #КонецЕсли

(8) #Если Клиент Тогда
       Сообщить();
   #Иначе
       ЗаписатьВЛог

(8) Предупреждение в проведении карается отрыванием рук

(7) Логика проведения не зависит от пользователя. От пользователя зависит РЕЖИМ проведения. Банальный пример: перемещение товаров в УПП пишет в регистры учёта товаров (на складах, в резерве и т.п.) и ещё пытается провести по партионным регистрам. В ряде случаев по бизнес-логике, проведение по партиям в режиме он-лайн не нужно, и зависеть это может как раз от пользователя, который проводит документ.
Вобщем, потребность бывает, не всегда бесспорная, возможно организуемая и другими способами, но бывает.

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

(13) Это интерактивный, но у меня режим проведения ещё зависит от самого режима, сорри за тавтологию (оперативный / неоперативный). Т.е. отложенное проведение у меня реализуется только для оперативного проведения, для пользователей-исполнителей. Для пользователей-админов или продвинутых пользователей - режим полного проведения.

(14) Ну, сам себе придумал трудности - теперь сам их и героически преодолевай. Мы за тебя будем болеть.

(риторический вопрос) К чему такие сложности? Зачем усложнять, когда нужно упрошать... "Стандартизировать, типизировать и еще раз..."(я)

Жизнь заставляет. Борюсь с блокировками и общей производительностью. Релиз УПП достаточно старый (1.2.9) обновиться практически нереально. По логике работы складские работники проводят очень много перемещений со складов хранения в зону выдачи. Одновременно менеджеры осуществляют резервирование под заказы. В результате возникает много блокировок. Принял решение проводить перемещения в оперативном режиме, так сказать в режиме "полупроведения" только по ТоварамНаСкладах и ТоварамВРезерве, а ночью фоновым заданием допроводить по партиям и т.п.. При этом последовательность партионного учёта восстанавливается отдельно по другому расписанию (с гораздо меньшей актуальностью). Однако, в ряде случаев, перемещения необходимо провести в полном режиме (с партиями). Например, для бухгалтерии, чтобы сформировать себестоимость ОС при сборке, чтобы списать материалы и т.п., т.е. для тех случаев, когда заведомо известно, что партионный учёт актуален, чтобы распечатать первичку требующую указания реальной суммы себестоимости.  Решение о том в каком режиме проводятся документы принимается в зависисимости от пользователя (его настроек).

(17) в перед записью в модуле формы поднимай флажок "Отложенное проведение" и в обработке проведения смотри на него, иначе пусть все выполняется стандартно

(18) В общем - да. Но Перемещение у меня проводится из отдельного блока "Сборка товара" в увязке со сборочными листами, с заполнением серий-ГТД, т.е. грубо говоря - программно. :)
Не, в конечном итоге я по пользователю-то определю. Я ж говорю, нет ничего такого что я бы не обошёл.. Просто думал, что, может быт,ь есть какое-то свойство глобального контекста типа "ЭтоРеламентноеЗадание() = Истина" :) Хочется делать красиво...

Ну, в принципе...

Если ФоновоеЗадание.РегламентноеЗадание() = Неопределено Тогда
  Сообщить("Запущенно непосредственно пользователем");
КонецЕсли;

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

вот для красоты еще можно сделать:

В процедуре фонового задания:

Объект = Документ.ХХХ.ПолучитьОбъект();
Объект.ДополнительныеСвойства.Вставить("ЭтоФон", Истина);
Объект.Записать(РежимЗаписиДокумента.Проведение);

В процедуре ОбработкаПроведения():

Если ЭтотОбъект.ДополнительныеСвойства.Свойство("ЭтоФон") Тогда
// ПОЛНОСТЬЮ ПРОВОДИМ
ИНАЧЕ
// НЕ СОВСЕМ ПРОВОДИМ
КонецЕсли;

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

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

(22) Ага, про доп.свойства знаю, пасиб :)

Нее... Степа прав. Методически грамотнее передавать через параметры. Но лучше (имхо) вообще не двоить поведение проведения :) и тем более не использовать типовые "нестандартно" - боком выйдет при обновлении. Хотя, с другой стороны, в УПП весь вывод всех сообщений - в одной процедуре собран...

(9) (10) Как это не странно, но в ОбщегоНазначения.СообщитьОбОшибке() нет условия про Клиент :) есть только про ВнешнееСоединение, потому как метод Сообщить() доступен на сервере. По партиям документ проводятся на сревере, и сообщение выводиться (даже если документ проводится ручками). Т.е. условие Если Клиент - мне не подходит.

(25) Нереально мне обновиться, слишком уж нетиповая уже...  В каком режиме провести - не проблема. Это легко определяется. Даже доп.параметры не нужны. Конечно же лучше не двоить проведени! Но блин, раком всё стоит... Нужна производительность.

(20) Способ в целом навреное приемлимый, главное чтобы пользователь ничего не проводил когда выполняется регламентное задание...

(26) что показывает замер производительности и анализ блокировок??? может лучше сервер помощнее просто, чем такие хитрости???

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

(27) А что сервер? Конфа старая, переписанная, обновиться - нереально... :(

(27) Блокировки абсолютно логичные. Пытаются один и тот же товар на одном и том же складе двигать/резервировать. Единственное решение - ускорять процесс проведения, чтобы как можно скорее освобождать блокировку. Серваки конечно тоже апгрейдим, хранилище новое купили, чтобы чтение/запись быстрее осуществлялось.

(30) может в обработке проведения можно что нить отрезать впринципе, что не используется в вашей организации? + переписывание ресурсоемких операция на языке более низкого уровня...

(31) Да, обрезаем, чего не юзаем. А вот на более низкий уровень не можем, спецов не хватает...

в (0) - классический вопрос классического тупого одинэсника, не знакомого с основами ООП...

(33) Что есть - то есть. В косерваториях не обучался. :)
В (33) классический ответ мегаМистянина, всё знающего, но ничего не объясняющего, ибо все остальные дятлы, о чём непеременно необходимо заявить во всеуслышание.

(34) объясняю: есть такие книжки, называются учебниками. их не курят, их читают...

(35) Читать - лениво, курить интереснее :)
Спасибо за совет. Но боюсь не воспользуюсь.. Проф. программистом становиться нет желания. На 1С можно писать и без этого, хотя не спорю, возможно оно бы помогало. Но уж очень муторно в тоннах учебников по ОПП выискивать крупицы знаний, котрые пригодятся в 1С и которые до этого на интуитивном уровне были непонятны.