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

Если пишу в лог при открытии формы нового документа, то нет номера.

Если сразу (программно или интерактивно) записываю документ, то время зафиксирую, но что-то мне это не нравится. Как минимум тем, что при отказе от записи документа он всё равно останется в базе.

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

УПП, SQL, 8.3.10

при открытии - в лог пиши идентификатор(любой, на что фантазии хватит) и время открытия; при записи - находишь по идентификатору, записываешь номер и время записи

(0) Apdex вроде интегрирован в платформу уже давно.  Время на технические операции с документом он приемлемо учитывает.

Или у тебя задача "Определить какого черта оператор открыл документ, и нифига с ним не делает гад?  "

(1) Да, вариант, спасибо.
(2) А чем мне этот Apdex поможет?
Задача будет ясна только к моменту выполнения, пока дам отчёт, где будет посчитано общее время открытых пользователем документов в разрезе документов. Инициатор не может понять, чего хочет. И сформулировать тоже не может. Но форму нарисовал, и на том спасибо.

(2) вроде нет такого показателя как время заполнения документа пользователем

Устанавливай ссылку и пиши ее в ЖР, тогда будет документ виден

(0)
Вариант 1 (очень простой): добавляем реквизит типа дата, заполняем при открытии формы нового документа
Вариант 2: пишем в дополнительные свойства, призаписи сохраняем в регистр - лог

ка же этого чорта лысого звать-то... есть, короче, в платформе ключ запуска, который все действия с формой в %userpdofile% логирует. ВОт его включи и анализируй лог потом. Там будет все с точностью до секунд

logui - что ли?.. не помню. Ну, в общем, сам найдешь

(8) /UILogRecorder
а оно не для УФ исключительно?

(6) Поскольку инициатор не называет виды документов, во все 440 видов документов по реквизиту - плохая идея.

(7) На базе в сотню пользователей, часть из которых я знаю лично (и, что опаснее, они знают меня)?

(10) общий реквизит добавь

(10) Есть общие реквизиты, и вариант 2.

(9) а, ну да. А тут еще и упп-ень...

(11) совместимость, бблин

лучше все-таки в ЖР писать ПриОткрытии, если новый, какую-нить полюбень
менее омерзительно, да и подобное с подобным храниться будет. Оккам будет дволен.

чем версионирование не подходит?

(15) Так и пойду делать. Спасибо!

(15) при наличии регламентных заданий использовать ЖР для прикладных целей - ну на фиг. Тормоза и риски обрушения

(16) тем, что нужно время событий, которые происходили ДО первой записи в БД

(18) вынеси регламентные на отдельный сервер

(20) можно логи разделить?

(16) Да, оно тут включено, но пошёл по пути "Считать ЖР и программно обработать".
(18) Я подозреваю, что данный отчёт пополнит коллекцию одноразовых.

(21) добродетельному человеку можно всё

(23) продолжай, интересно. Без шуток

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

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

(25) понятно
по 1 соглашусь с (26),
а 2 вроде не вариант: события COM так же будут регистрироваться в ЖР

(27) а, ну да, ну тогда вариант 1