Андрей, эта логика реализована в веб-сервисе /0/ServiceModel/PackageInstallerService.svc/CreateBackup, он реализован на уровне ядра. Насколько понял, сохранение происходит в системную папку для временных файлов на веб-сервере, создаются файлы с именами DeleteList.txt, AppInfo.txt, AppDependentPackagesUIdsInfo.txt.

Информация, в том числе и  лог о результатах загрузки пакета, пишется в подпапки внутри папки PackageInstallation, у меня она была в C:\Windows\Temp\3\IIS APPPOOL_MySiteName\Default.

Здравствуйте, Александр.

В версии devexpress которая поставляется с нашим продуктом, нет интеграции с элементом "Вложенный отчет", т.е. использовать данный элемент для построения отчетов нет возможности.

Попробуйте включить режим отладки для конкретного пользователя через БД.

Таблица с настройками:

select * from SysSettingsValue

where SysSettingsId = 'F7827AB8-2EF2-4ACB-A28B-BFB7EB7A01C3'

Можно сделать insert например

GUID_USER - id пользователя, которому нужно включить отладку.

insert into SysSettingsValue

(SysSettingsId, SysAdminUnitId, BooleanValue)

VALUES ('F7827AB8-2EF2-4ACB-A28B-BFB7EB7A01C3', GUID_USER, 0)

Либо включить глобально для всех через системные настройки: Режим отладки (IsDebug)

Здравствуйте, Кирилл!

Ваш вопрос по нескольким DCM в зависимости от типа записи? Если да, то это настраивается в дизайнере и работает в новых (созданных мастером) разделах. В CasePage тоже по идее должно. Если вопрос как сделать разные наборы для портала и системы – никак. DCM один и он общий для обоих пользователей. Пользователь на портале видит те же шаги, что и пользователь системы. А тип выбирается в зависимости от записи и тоже не зависит от типа пользователя.

Мотков Илья,

Да, по нескольким DCM. В разделе Case  в мастере настроил несколько progressbar в зависимости от значения поля. Для системных пользователей всё работает. Но для портальных пользователей не работает. Отображается progressbar по умолчанию при любом значении указанного поля. Разные наборы для портала и системы мне не нужно делать

Походу проблема, возможно, из-за кастомной разработки. Развернул чистую версию 7.14.3 и там всё корректно работает.

Руслан, это два разных вопроса:

1. В системе есть версионность процессов. Если вносятся изменения, старые запущенные экземпляры процессов доработают в старой версии. А новые будут уже с учётом исправлений.

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

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

Зверев Александр,  в данный момент в продуктивной системе 1485 обращений по которым эскалация либо уже идёт, либо теоретически может начаться. Поэтому сложно предугадать момент когда БП точно не будут отрабатывать. По 1-му пункту не знал, спасибо. Буду делать в нерабочее время с сохранением новой версии процессов.

В любом случае сервер когда-то останавливается на некоторое время: для обновления версии системы, каких-то работ на серверах IIS и БД и др. Если есть доступ к базе, увидеть, что происходит в системе на сервере, можно при помощи запросов на свежие записи в таблицах SysUserSession, SysProcessLog и SysProcessElementLog.

Добрый день.

Сделайте скриншот настроек для этой колонки.

Подтверждаю наличие проблемы. Попытки указать в формате ячеек Числовой или 0,00 ни к чему не привели.

вот что пишет Excel

Алексей С.,

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

Ирина Лазоренко,

Алла Савельева,

Настроил как в эксель, 0,00 но почему-то не применился формат колонки вообще, может в настройках отчета, что-то не правильно делаю?

Может у кого есть идеи?

Алексей,

изменения в системных настройках применяются после перезахода в приложение. Проверяли сразу после внесения изменений или после перезахода в приложение?

Ирина Лазоренко,

Проверял остается ошибка в excel

https://prnt.sc/srpqmg - настойки excel

https://prnt.sc/srppad - настройки отчета

https://prnt.sc/srpq2o - настройки переменной

Может что нибудь не так настроено ?

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

разработчик решения воспроизвел ошибку. В планах выпустить обновление с исправлением до 15 июля. По результатам выпуска обновления напишу здесь.

Добрый день!

Имею подобные ошибки и проблему с бизнес-заказчиком.

https://community.terrasoft.ua/questions/dev-labskonstruktor-otchetovbpmreportoshibka-excel

Уточните, пожалуйста, обновление уже выпущено?

Спасибо!

Добрый день!

да, обновленный пакет уже опубликован на маркетплейс. Установите дополнение повторно из маркетплейс.

Руслан, добрый день!

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

Ирина Лазоренко, доступ имеется, но есть один нюанс: в данный момент приходится работать удаленно через виртуальную машину. Возможно это как-то влияет, при том в момент автогенерации отчёта я был залогинен.

Ирина Лазоренко, попробовал повторить данную операцию непосредственно с рабочего места - выдаёт такую же ошибку, при том, если указывать путь на локальный диск - ошибку о формировании не выдаёт, но в конечной папке файл отчёта не появляется. Это может быть связано с версией Creatio (7.13?)

Ирина Лазоренко, не знаю, к Вам ли вопрос, ещё при попытке задать период для фильтрации данных в отчёт, если подтянуть  последний параметр на скриншоте (до сегодня >= 7:30), то отчёт формируется пустой

Шарифуллин Руслан,

по доступу еще уточняю. По фильтрам выполните следующую проверку: укажите такие же фильтры в разделе и проверьте результаты. Это скорее все базовая логика работы фильтров.

Ирина Лазоренко,

 Вы правы, такие параметры фильтрации не срабатывают и в разделе

Руслан, статья о фильтрах по датам есть тут. Мне кажется, указание точного времени работает независимо от указания даты и отсеивает моменты за любую дату до 7:30, промежуток не получится.

Но если нужно всего за два дня, вчерашний и сегодняшний, то можно настроить два независимых фильтра, связанных по «или». Примерно так:

Так в одной записи таблицы CaseLifecycle хранится одно состояние, а Вам нужно и старое, и новое. Или пока это не важно, хотя бы переходы в работу откуда угодно?

А самым верхним условием пытаетесь отфильтровать, что по обращению на детали есть только одна запись? Тогда те, где таких две и больше (сначала в новом, потом в работе и т. д.) в выборку не попадут.

Если есть доступ к базе, попробуйте написать SQL-запрос по выборке нужной информации и убедиться в адекватности результатов. А потом либо, ориентируясь по нему, настроить фильтр, либо, как любят тут советовать, сделать view, объект и далее строить диаграмму по нему.

Зверев Александр, доступа к базе нет.



Надо чтобы выводило только один переход: с состояния Новое в состояние В работе. Не подскажите, как тогда по-другому можно реализовать это в итогах на графике?

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

Если без VIEW на SQL, то примерно так:



1. В объект CaseLifecycle добавьте поле "Предыдущий статус"

2. Сделайте простой БП: на добавление записи в CaseLifecycle читайте последнюю (предыдущую) запись CaseLifecysle по данному обращению, и значение Статус из неё записывайте в добавленную запись в поле "Предыдущий статус".

3. А потом построите аналитику по CaseLifecycle и записям, где Предыдущий статус = Новый, а Статус = В работе.



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

Владимир Соколов пишет:

Сделайте простой БП: на добавление записи в CaseLifecycle читайте последнюю (предыдущую) запись CaseLifecysle по данному обращению, и значение Статус из неё записывайте в добавленную запись в поле "Предыдущий статус".

Дополню, поскольку на момент запуска БП в базе уже сохранена новая запись, для получения статуса из предыдущей можно в блоке чтения данных отсортировать по дате создания и отфильтровать по Id, не равному Id той записи, по которой запустился процесс, а также по равному с ней полю CaseId (обращению).

Владимир Соколов пишет:

Если надо и исторические данные изменить

Судя по дате «сегодня» в настройках графика на скриншоте, думаю, их не нужно.

Отправили запрос в тех. поддержку - назвали багом, в итоге получили фикс. Фикс вошел в состав 7.16.1

Добрый вечер.

Сначала нужно определиться с критериями - какие обращения считать дублями.

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

Я бы их не объединяла, так как тогда в срм будет неполная история обращений.

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

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

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

Есть же стандартная  деталь «Подчинённые обращения», можно использовать её.