Доброго времени суток!

Клиент-сервное решение, УПП , платформа 8.2. Пользователи работают через RDP.

Я уже много чего перепробывала, но проблема не уходит.

После обновления конфигурации(УПП) у одного пользователя стала неправильно работать обработка "Согласование заявок". Эта обработка есть копия стандартной с добавлением условия на выбор следующего этапа согласования.
В отладчике проверила работу обработки под этим пользователем, там все нормально срабатывает. А вот у него нет!
Воникло подозрение, что это кэш. Почистили кэш в его RDP сессии. Заработало!
Но на следующий день опять та же песня! Создали новую учетку в 1С, помогло. На след день опять то же самое. Удалили учетку с терминального сервера и создали новую, помогло. Но на следующий день опять то же самое.
Вопрос: что же еще может влиять на его работу? И что такое кэш конфигурации сервера 1С, для чего он нужен?

(0) "В отладчике проверила"
Девушка. А в карточке пол мужской и фото нет...

кэш сервера 1с находится в папке srvinfo... нужен собственно для того же, но он вроде как для всех, а не конкретных пользователей...
попробуйте запустить у него клиента разок с параметром:
/ClearCache — очистка кэша клиент-серверных вызовов (используется для тонкого и толстого клиентов в режиме 1С:Предприятия).

(0) Смотрите в отладчике под тем пользователем у которого проблемы

(3) Я под тем пользователем и отлаживала, но RDP сессия у меня была своя.

(2) То есть Вы считаете, что я не так кэш чистила? Скажите какие папки отвечают за кэш пользователя в RDP сессии?

(5) я говорю попробовать просто, возможно в серверном кэше что-то затясалось, а вы чистили клиентский. Хотя симптомы странные

(5)Честно скажу, что баловалась до обновления и после с динамическим обновление. В интернете начиталась про то, что динамическое обновление сильно  вредит. Рекоменддуют  почистить кеш пользователей. Ладно этим и занимаемся, а может что-то на серваке еще подглючивает?

(7) а я про что писал?
/ClearCache — очистка кэша клиент-серверных вызовов

не только клиентский кэш будет резать

/ClearCache не помог. Еще есть у кого идеи?
Прошу о помощи, если не решу эту проблему, меня обзовут морской свинкой. Я вместо того чтобы текущими задачками заниматься всякой ерундой занимаюсь... кэши чищу...

Да надо все таки запустить его RDP сессию. Из его RDP сессии запустить конфигуратор под собой и поймать отладчиком его 1с сеанс и посмотреть что происходит.

из RDP сессии пользователь выходит(LogOff) или обрывает её крестиком (Disconnect)?
Попробуй удалить пользователя с терминального сервера, иногда глюкает сам сервер терминалов и в реестре остаётся мусор, особенно при оставленных включенными сессиях и проги (не только 1С) начинают колбаситься, под одним юзером всё работает, как часы, а под другим что-то да вылазит боком.

Все такие опытные, аж жуть...
А что именно не работает, никому не интересно?

(11)Уже грохали учетку на терминальном сервере, сейчас работает под новой. Сразу после эксперимента обработка заработала как надо, но на следующий день опять не так. Причем каждый раз результат один и тот же. Такое ощущение, что берется какой-то другой код(по поведению очень похож на старый стандартный код этой обработки) и выполняется.

(12) Стандартная обработка согласования заявок работает следующим образом: сначала определяется текущий этап согласования, потом на его основании следующий. В нашей обработке при определении следующей еще есть ряд проверочных условий на основании которых решается следующий брать этап или перепрыгнуть через него(т.е. брать послеследующий).
Так вот на этом пользователе заявки должны перепрыгнуть через этап, но этого не происходит.

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

(14)Измененный код в студию. Что там наворочено можно только гадать на пивной жиже.