НАСТРОИТЬ ФИЛЬТРЫ ДЛЯ ОТОБРАЖЕНИЯ НА ГРАФИКЕ ОБРАЩЕНИЙ ПЕРЕВЕДЕННЫХ ПОЛЬЗОВАТЕЛЯМИ ИЗ СОСТОЯНИЯ НОВОЕ В СОСТОЯНИЕ В РАБОТЕ
Помогите разобраться, как настроить фильтры для графика в итогах, чтобы на нем отображалось количество переведенных обращений из состояния НОВОЕ в состояние В РАБОТЕ по нескольким пользователям.
На скриншоте то, как я пытаюсь настроить, но на графике ничего не отображает по такому фильтру.
Нравится
Если без VIEW на SQL, то примерно так:
1. В объект CaseLifecycle добавьте поле "Предыдущий статус"
2. Сделайте простой БП: на добавление записи в CaseLifecycle читайте последнюю (предыдущую) запись CaseLifecysle по данному обращению, и значение Статус из неё записывайте в добавленную запись в поле "Предыдущий статус".
3. А потом построите аналитику по CaseLifecycle и записям, где Предыдущий статус = Новый, а Статус = В работе.
Если надо и исторические данные изменить, то по уже существующим обращениям тоже можно написать аналогичный процесс, только в п.2. читайте первую запись, где Дата создания < Даты создания искомой записи, сортируя записи по Дате создания в порядке убывания
Так в одной записи таблицы CaseLifecycle хранится одно состояние, а Вам нужно и старое, и новое. Или пока это не важно, хотя бы переходы в работу откуда угодно?
А самым верхним условием пытаетесь отфильтровать, что по обращению на детали есть только одна запись? Тогда те, где таких две и больше (сначала в новом, потом в работе и т. д.) в выборку не попадут.
Если есть доступ к базе, попробуйте написать SQL-запрос по выборке нужной информации и убедиться в адекватности результатов. А потом либо, ориентируясь по нему, настроить фильтр, либо, как любят тут советовать, сделать view, объект и далее строить диаграмму по нему.
Зверев Александр, доступа к базе нет.
Надо чтобы выводило только один переход: с состояния Новое в состояние В работе. Не подскажите, как тогда по-другому можно реализовать это в итогах на графике?
Для этого нужно смотреть и другие записи этой детали по обоим состояниям (если в работу переходят не только из новых). Или сделать на уровне объектов какую-то дополнительную логику и наполняемые ею поля, по которым уже фильтровать.
Если без VIEW на SQL, то примерно так:
1. В объект CaseLifecycle добавьте поле "Предыдущий статус"
2. Сделайте простой БП: на добавление записи в CaseLifecycle читайте последнюю (предыдущую) запись CaseLifecysle по данному обращению, и значение Статус из неё записывайте в добавленную запись в поле "Предыдущий статус".
3. А потом построите аналитику по CaseLifecycle и записям, где Предыдущий статус = Новый, а Статус = В работе.
Если надо и исторические данные изменить, то по уже существующим обращениям тоже можно написать аналогичный процесс, только в п.2. читайте первую запись, где Дата создания < Даты создания искомой записи, сортируя записи по Дате создания в порядке убывания
Владимир Соколов пишет:
Сделайте простой БП: на добавление записи в CaseLifecycle читайте последнюю (предыдущую) запись CaseLifecysle по данному обращению, и значение Статус из неё записывайте в добавленную запись в поле "Предыдущий статус".
Дополню, поскольку на момент запуска БП в базе уже сохранена новая запись, для получения статуса из предыдущей можно в блоке чтения данных отсортировать по дате создания и отфильтровать по Id, не равному Id той записи, по которой запустился процесс, а также по равному с ней полю CaseId (обращению).
Владимир Соколов пишет:
Если надо и исторические данные изменить
Судя по дате «сегодня» в настройках графика на скриншоте, думаю, их не нужно.