8.х Как вычислить время за которое проводится документ?

Стандартных средств нет. Только замер производительности.

--- Объединение сообщений, 18 сен 2014 ---

Что означает это "ээээээ....."?

А чем стандартный замер производительности не устраивает?

Я вот, например, сейчас занимаюсь как раз почти тем же самым. Замер нормально отрабатывает

Ну вот и я спрашиваю, что не устраивает

Не изобретайте велосипед. Ставите точку останова на самой первой строке кода процедуры обработка проведения. Как отладчик сработает нажимаете Отладка -->Замер производительности. Ставите точку останова на фразе КонецПроцедуры и продолжаете процесс отладки. Как управление перейдет на последнюю строку опять жмете Замер производительности. Там уже все будет видно. Сколько потрачено и на что.

Ну замером производительности делайте все и сохраняйте данные, кто вам мешает. Ну или делайте копии базы. в которых потом сможете продемонстрировать.
Только учтите особенности КЭШИРОВАНИЯ. у Вас базы какие файловые или серверные. Если серверные то учтите что документ после первого проведения дает одни данные, а после повторного его же другие т.к инфа по выборке иже в лог файле есть и он ее оттуда тянет. Ну это все из области как правильно тестить - это уже другой вопрос.
А стандартный замер вам выдаст все что надо и покажет на каких именно процедурах вы выйграли, а если не выйнграли то почему вы там не можете оптимизировать

Кстати, если есть много лишних денег, то можно конечно и КИП купить и им тогда уже полный анализ с отчетностью .все как Вы хотите

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

--- Объединение сообщений, 18 сен 2014 ---

И можно было не извращаться так а
в начале написать
Сообщить(ТекущаяДата())

и в конеце то же самое

Идеи накидали - выбирайте

И мои пять копеек. Не согласен что какой либо код даст Вам более менее правильное осознание сколько времени проводится документ. Дело в том что ОбработкаПроведения это всего лишь одна часть операции, не забудьте что фиксация набора данных может очень сильно замедлять процесс записи документа, и как следствие замедляется для пользователя весь процесс. Оптимизация текста без оптимизации самой базы данных может не привести к желаемому результату.
Моё мнение таково, подобными вещами имеет смысл плотно заниматься только при наличии сервера, т.к. нагрузки самого жесткого на чтение/запись нужно проверять, скорость секторов, наличие бадов, и при всём этом тяжело сделать выводы о производительности.
При наличии сервера можно использовать
• SQL Server Connect Time (usec) – время подключения к SQL серверу.
• SQL Operation Time (usec) – время выполнения SQL операции.
• Total Transaction Time (usec) – полное время выполнения тестовой
транзакции.
Возможны два варианта кастомизации теста:
ƒ Простая кастомизация.
ƒ Расширенная кастомизация.
При простой кастомизации изменяется только тип выполняемого SQL запроса. SQL
запрос, установленный в тесте по умолчанию, заменяется на SQL запрос, специфичный
для конкретного бизнес-приложения.
При расширенной кастомизации изменяется не только SQL запрос, но и логика работы
теста, например, добавляются новые метрики. Для реализации второго варианта
кастомизации необходимо знание языка VBScript.
При этом мы уже можем делать конкретные выводы, т.к. в тест попадает весь процесс на сторону сервера, как само проведение так и фиксация транзакции, может остаться только одна проблема - сеть, ну тут тоже есть свои решения, ни кто не запрещает выполнить пинг своего сервера и проверить пороговые значения с клиентских машин.