Рабочие часы в Dynamics 365

[Дмитрий А.А.]

Доброго дня.
Возник следующий вопрос:
В Dyn365, как и в прошлых версиях CRM, у пользователя есть связанные "Рабочие часы".
Можно ли как-то на уровне плагинов или другими способами отлавливать изменения в этом объекте и, если да, то как правильно это делать.

[Артем Enot Грунин]

Доброго времени суток. Ответ: да, можно, но не рекомендую. Расскажите, пожалуйста, о задаче. Возможно, есть более простой пусть ее решения.


Что-то мне подсказывает, что вам не рабочие часы нужны, а свободное время сотрудников.

[Дмитрий А.А.]

Задача следующая:
Есть круг менеджеров, которые занимаются работой на нескольких объектах. За каждой локацией закреплен отдельный менеджер, но, при необходимости, должны менять свою дислокацию и другие менеджеры по определенным правилам (условно если "ключевой" занят работой с клиентом, но на это же время записывается другой клиент, то подключаем менеджера с другой локации).
Доступность менеджеров планировалось обновлять исходя из их индивидуальных рабочих часов (у каждого они свои).
И возник один из кейсов: если у менеджера уже есть записанные клиенты (встречи в CRM), и ему, по какой-то необходимости, требуется изменить свой график (взять отгул, изменить время работы в конкретный день), то нам нужно отловить это событие (изменение его индивидуальных рабочих часов), и что-то сделать со встречами, которые уже есть на время, которое теперь становится недоступным.
Если коротко - то как-то так.

[Дмитрий А.А.]

Цитата:

Сообщение от Артем Enot Грунин

да, можно, но не рекомендую.

Подскажете, о каком способе идет речь?

[Артем Enot Грунин]

Вы говорите о сценарии планирования сервиса. Тут, как и везде, первичный вопрос в том, что вы хотите: шашечки, или поехали? В вашем случае, он звучит: вы хотите спланировать рабочее время, или знать о его изменениях?


Чтобы спланировать сервис, есть 2 варианта:

1. Классический модуль планирования сервиса. Прекрасно работает со встречами, но опирается на отдельный вид активности "действие сервиса". Этот функционал считается устаревшим и в далеком будущем будет удален
2. Universal Resource Scheduling. Может работать на он-премис, но требует купить онлайн подписку

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


Если нужно поймать изменения, тогда вам нужно работать с сущностями Calendar и CalendarRule. Я планировал написать серию постов по этой тебе, но забил так как эта область мало кому интересна. Если выберите этот пусть, я могу рассказать про это, но это корабль в бутылке. Геморрой я вам гарантирую.

[Дмитрий А.А.]

Цитата:

Сообщение от Артем Enot Грунин

Если нужно поймать изменения, тогда вам нужно работать с сущностями Calendar и CalendarRule. Я планировал написать серию постов по этой тебе, но забил так как эта область мало кому интересна. Если выберите этот пусть, я могу рассказать про это, но это корабль в бутылке. Геморрой я вам гарантирую.

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

Если я не прав, поправьте меня пожалуйста.

[Артем Enot Грунин]

Все же вы решили пойти сложным путем?

Если так, вы можете отловить факт изменения календаря при помощи плагина. Вопрос в том, что дальше? Календарь устроен приблизительно следующим образом:



Есть календарь который связан с пользователем, назовем его Root. Его отличает поле Type = 0. Далее у него есть атрибут CalendarRules типа EntityCollection. Это единственный объект, с таким полем, который я знаю. Как нетрудно догадаться, это набор "правил" который и определяет расписание.

Вот тут начинается интересное. Root календарь у пользователя один, но так как расписание может меняться, для хранения этой информации используются дочерние календари Type = -1. Поэтому все его правила CalendarRule имеют ссылку на InnerCalendar, а уже эти InnerCalendar, как раз определяют конечное расписание: или действующее в настоящий момент, или действовавшие в прошлом. Как правило, у дочернего календаря есть как минимум 2 правила: первое - это правило для рабочих дней, второе для рабочих часов.

Правило для рабочих дней хранится в формате iCalendar в строке вида FREQ=WEEKLY;INTERVAL=1;BYDAY=MO,TU,FR,SA. Правило для рабочих часов определятся полями Offset, Duration, TimeCode и Subcode.

Например, вы имеете рабочий день ПН-ПТ с 9 до 18. Правило дней будет: FREQ=WEEKLY;INTERVAL=1;BYDAY=MO,TU,WE,TH,FR. А правило рабочих часов будет Offset=540 (60 минут * 9 часов); Duration=480 (60 минут * 8 часов); TimeCode=0 (Avalable); SubCode=1 (Schedulable). Если есть перерыв, то это будет еще одно правило, у него тоже будет сдвиг, длинна, но другие TimeCode и SubCode, и более высокий приоритет - ExtentCode.

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