Добрый день! вы нашли, в чем проблема? у меня возникла похожая проблема

Добрый день!

Эта ошибка возникает из-за типа СУБД. Данное дополнение работает только с MS SQL. При работе на PostgreSQL будут возникать такие ошибки.



Мы зафиксировали данный запрос как пожелание на адаптацию данного приложения с postgreSQL.

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

Алексей Следь, благодарю

В продуктах ServiceDesk есть рабочий календарь (график работы) и расчет рабочих дат через веб-сервисы,(посмотрите TermCalculationService и сделайте что вам нужно по аналогии)

Так же есть бесплатные расширения для БП позволяющие работать с рабочими днями (можете сделать свой вариант по аналогии если существующий функционал вас не устроит)

Решил задачу с использованием класса TermCalculatorActions

Александр, я не вижу другого варианта, кроме того, что каждый пользователь должен создавать задачи с продолжительностью, который он потратил на задачу и привязать (деталь "Связи") с соответствующим разделом. Затем строить необходимую аналитику.

Илья, мы думали об этом, НО создавая на каждое изменение задачу менеджер будет перегружен и много времени уйдет на их завершение

В качестве супербредовой идеи:
1) Унаследоваться от базового объекта, сделать базовый объект с логом(там будет событие записи в базу кто и когда делал изменение в каком поле какого объекта). изменить родителя у основных объектов системы с базового объекта на новый.
2) В basesection на событие загрузки грида тоже прилепить логирование.(либо gridUtils, чтобы ещё и детали отслеживались).
3) скорее всего где-то в системе валяется таблица времени логина пользователя, её тоже можно откопать, вытащить данные.(деталь сеансы)

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

Что-то подобное мы реализовывали тригерами в БД, но в очень узком масштабе - 2 раздела, несколько объектов и некоторые поля в нем.
Ну и я так понимаю Вам необходим хронологический порядок, нас же интересовали удельные итоговые данные по временным интервалам.
Но "на вскидку" хронологию так-же можно "прикрутить".
Можете по-подробнее рассказать как вы видите методику учета "работы" менеджера, aka "Необходимо учитывать время с момента открытия карточки, до ее закрытия" или "необходимо учитывать как скоро после изменения одних данных произошло изменение других этим же пользователем" и т.д.

Илья, да, у нас стоит задача в фиксировании деятельности в хронологическом порядке, т.е. ка Вы правильно указали "Необходимо учитывать время с момента открытия карточки, до ее закрытия", сейчас же система считает сколько менеджер звонит в день или пишет email, фактическое время работы в разделах вовсе не учитывается. Есть одна идея, связанная с лидами или продажами (для данных разделов созданы "большие процессы" и по данным процессам видно, сколько времени процесс "управления лидом" или "корпоративная продажа" находится в активном статусе), быть может и в других разделах фиксацию можно реализовать с помощью процессов, так как с разработкой я "на Вы" и хочется (если это возможно) реализовать все с помощью внутренних инструментов