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

что значит: "настройки процесса отправки почты" и "настройки того процесса,из которого вызывается отправка почты"?
Это стандартный процесс "Управление инцидентами" в стандартной версии bpm service desk itil transitions.
Это коробочная версия

настройки почты - заведены два почтовые записи, прикреплены к учетной записи Supervisor.
Один из этих ящиков указан как ящик службы поддержки в системной настройке,
у другого указано, что он общий.

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

Дарья, добрый день!

Базовый процесс управления инцидентами стартует по следующим событиям:
1. Создано новое обращение, в котором указаны:
- Категория = Инцидент
- Состояние = Новое
- заполнены поля "Сервис" и "Ответственный" любыми значениями;
2. Изменено любое поле записи обращения, если по результатам сохранения в записи указаны:
- Категория = Инцидент
- Состояние = Новое
- заполнены поля "Сервис" и "Ответственный" любыми значениями.
В описанном Вами кейсе выполняется работа с существующей записью, но по результатам сохранения запись не соответствует выше перечисленным параметрам.

Рекомендую протестировать запуск и работу процесса повторно с учетом описанной логики.

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

А есть где-нибудь описание вообще этого процесса. Какие шаги, что происходит в том или ином случае.
В руководстве пользователя нет(

Например, процесс корпоративных продаж в руководстве к sales очень хорошо описан, и это удобно.
А вот про процесс управление инцидентов в руководстве к service desk написано пару строчек.

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

Дарья, ниже приведены комментарии по Вашим вопросам.

1. «А есть где-нибудь описание вообще этого процесса. Какие шаги, что происходит в том или ином случае.»

Процесс описан верхнеуровнево на ресурсе Terrasoft Academy (http://academy.terrasoft.ru/documents/?product=transitions&ver=7.5.0) в разделе Функциональность bpm’online ITIL service/Раздел [Обращения]/Бизнес-процесс управления инцидентами.
Если у Вас будут возникать дополнительные вопросы, то мы готовы ответить.

2. «Подскажите, пожалуйста, еще почему может не заполняться по умолчанию ответственный в обращении. У сервиса указан сервисный инженер и владелец. В какой момент должен заполниться ответственный по обращению на основании выбранного сервиса?»

Сервисные инженеры в сервисе указываются с целью порекомендовать специалисту поддержки, выполняющему классификацию обращения, в чью компетенцию входит обслуживание текущего сервиса. Иными словами, указав одного или несколько сервисных инженеров по определенному сервису, система не будет автоматически определять ответственно по обращению с таким сервисом, а ограничит список рекомендуемых специалистов для выбора.
Детально данная функциональность описана в параграфе «Подбор сервисных инженеров» раздела Функциональность bpm’online ITIL service/Раздел [Обращения]/Страница обращения на ресурсе Terrasoft Academy (http://academy.terrasoft.ru/documents/?product=transitions&ver=7.5.0)

Ответственный по обращению при этом устанавливается вручную.

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

Задам вопрос по инциденту и процессу тогда:
Если я правильно поняла, система не подставляет ответственного по обращению автоматически (даже если в сервисе указан только один сервисный инженер).
Тогда возникает следующий вопрос:
Вы писали, что базовый процесс по инциденту стартует в этих случаях.
1. Создано новое обращение, в котором указаны:
- Категория = Инцидент
- Состояние = Новое
- заполнены поля "Сервис" и "Ответственный" любыми значениями;
2. Изменено любое поле записи обращения, если по результатам сохранения в записи указаны:
- Категория = Инцидент
- Состояние = Новое
- заполнены поля "Сервис" и "Ответственный" любыми значениями.

Т.е. получается, что когда создается инцидент через веб-портал, то ответственный при создании инцидента не заполняется.
Процесс таким образом не стартовал пока еще, так как ответственный еще не заполнен.

Далее оператор видит обращение, и должен его обработать - назначить ответственного(так как там пусто).
В этот момент оператор ни в коем случае не должен переводить инцидент в состояние отличное от "новый", иначе процесс не стартует.
Т.е. например, человек увидев обращение, и выбрав в качестве ответственного себя, должен помнить, что ему не надо переводить пока обращение в другое состояние в этот момент. Правильно я понимаю?

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

Только если будете вносить изменения процесс нужно "Сохранить как новую версию"

закомментируйте строку

Incident = GetIncidentDataBySubject(MailItem.Subject);

в function SaveMailItem(MailItem, Options) в scr_MSOutlookLibrary

Кстати, логика поиска такова:
1. Выявить ключевое понятие для данное проблемы - в данном случае это номер инцидента
2. перевести его на язык террасофт - IncidentNumber (была бы продажа - было бы OpportunityNumber и т.д.)
3. открыть администратора и воспользоваться GREP-search
4. Найти пересечение между результатами поиска и темой, в контексте которой рассматриваем проблему - в данному случае это интеграция с Outlook, а значит нас интересует scr_MSOutlookLibrary.

Открываем, смотрим по названию\коду то ли это, что нас интересует, если да, то поднимаемся по функциям до места срабатывания.

Огромное спасибо!

Добрый день, Акмаль.
Логика будет корректна, если создать определенное количество SLA (для каждого клиента) со своим пакетом и объектами обслуживания.
Таким образом Вы обойдете ситуацию, когда любой сторонний клиент получает весь пакет услуг поддержки абонентов.

Кто-нибудь может объяснить данный функционал?

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

Добрый день, Алексей.

Но в тех же задачах используются такие же контролы и там все работает корректно!!!!

Прошу прощения! Не проверил, в задачах тот же БАГ.

В задачах это не так критично как в инцидентах, где необходимо учитывать, скажем, время разрешения инцидента. Может стоит кэшировать время открытия карточки т.е. при открытии проверяем наличие данных в поле, если поле пустое, то прописываем туда текущую дату/время?

Если вернуться к Вашему первому посту, то какое время для даты 03.07.2009 было бы корректным?

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

Если я правильно Вас понял, это происходит из-за того что при "первом" открытии карточки экземпляр сервиса кешируется в глобальную переменную?

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

В Вашем случае необходимо настроить время разрешения и время реакции в Сервисах по Сервисным Договорам, тогда время реакции и время разрешения в инциденте будут расчитываться автоматически

Что-то не понял по поводу Сервисных Договоров, может Вы имеете ввиду ServiceDesk? Я приводил пример для X25, в которой есть только справочник "приоритеты инцидентов", но и по этому справочнику никаких расчетов времени разрешения и времени реакции не происходит

А я уже решил что Вы активно используете Service Desk...

:)))

Так как быть с X25? Вообще, было бы неплохо в OnPrepare окна очищать кеш контрола.

Ну так Вы все равно не угадаете какое время реакции необходимо установить. Если у Вас есть свой алгоритм по которому оно устанавливается, то необходимо его отдельно реализовывать. А установка, например, текущей даты, будет неверным решением.