Версии проекта
Обновлено: 27.08.2024
Версия проекта — это отдельная сущность, включающая наименование, состояние и прочие свойства + отдельная версия содержимого проекта (команды, задач, ресурсного плана, тарифов и оценки выручки, затрат и биллинга).
Права доступа
Для доступа к версиям проекта (как сущности) требуется набор прав для роли Управление проектом с активной гранулой Версии проекта (как минимум, для области Просмотр). Доступ к версии содержимого проекта регулируется теми же гранулами, что и на сам проект. Например, права доступа на команду проекта — это права на команду основного проекта и всех его версий.
Версия включает в себя следующие сущности:
|
Классификаторы и ставки
|
- Команда проекта + ставки по членам команды.
- Задачи проекта + назначения на задачи.
- Тарифы + назначение на тарифы.
- Правила периодических затрат.
|
|
Оценки
|
- Ресурсный план (оценка часов / себестоимости).
- Оценка выручки.
- Оценка биллинга и оплаты.
- Оценка затрат.
|
Примечание
Сам по себе проект не является версией и имеет собственный жизненный цикл. Только для проекта могут создаваться фактические данные.
Создать версию возможно путём:
- копированием оценки (из проекта или другой версии).
- копированием прогноза (на базе проекта или другой версии).
- созданием пустой версии.
- слиянием (версий и проекта).
После создания, с версией можно работать в карточке версии:
К содержимому версии можно перейти с помощью кнопки Открыть версию на панели действий.
Переключения между версиями осуществляются с помощью Селектора содержимого:
Для редактирования доступны только версии в редактируемых состояниях, по умолчанию это «Черновик». Редактирование версии осуществляется независимо от проекта и других версий.
Мастер-версия проекта — это версия, которая была принята как основная. На её основе в проекте отображаются плановые показатели. Для установки версии в качестве мастера её необходимо предварительно перевести в состояние Утверждена и затем сделать Мастер-версией с помощью соответствующего действия.
Снапшот — это состояние версии, в котором фиксируются Прогнозные показатели. Версия в состоянии Снапшот дает ответ на вопрос «Как менеджер прогнозировал показатели проекта на момент создания снапшота?».
В снапшот копируется не только оценочные показатели, но и фактические на момент создания снапшота.
Также в снапшот копируется «точка прогнозирования» — дата, до которой учитываются фактические данные на момент создания снапшота.
Примечание
При создании новой версии из снапшота фактические данные и «точка прогнозирования» не копируются.
Управление состояниями версий происходит в карточке версии.
Жизненные циклы версий можно настраивать при помощи компоненты Жизненные циклы.
Схема жизненного цикла версии по умолчанию:
Примечание
Состояния «Отмененная» и «Снапшот» — терминальные, переход в другое состояние не доступен.
Версии в любом состоянии кроме «Черновика» — неизменяемые (в ЖЦ по умолчанию, но это может быть изменено администратором). Это значит, что их нельзя отредактировать вручную и нельзя повлиять через изменение курсов валют, ставок себестоимости пользователей и пр.
При возврате версии в «Черновик» или другое состояние, допускающее редактирование, все расчетные значения (себестоимость, мультивалютные значения и пр.) немедленно будут обновлены.
-
Пустая версия — создание версии проекта, которая не содержит данных.
Создание пустой версии проекта необходимо для планирования дополнительных работ по проекту.
-
Копировать оценку — создание версии проекта на основе выбранного источника. Версия создается в состоянии «Черновик».
-
Копировать прогноз — создание версии проекта на основе проекта и фактических данных на момент создания.
Оценка новой версии по всем показателям = прогнозу проекта, т. е. факт до текущего периода прогнозирования + оценка от текущего периода прогнозирования (включительно) и до конца проекта.
Примечание
Через копирование прогноза версия создается в состоянии «Готова к согласованию». Это важно, т. к. по умолчанию в этом состоянии не происходит перерасчет ставок (состояние с опцией «только чтение»).
Приёмником всегда выступает проект. Т.е. выполняется операция:
[Любая версия] => [Проект]
Поддерживается два способа:
-
Слияние с типом Замена данных делает проект равным версии. Однако есть ряд исключений (см. Особенности логики), т. о. проект не обязательно будет полной копией версии-источника.
-
Слияние с типом Дополнение данных — дополняет проект данными из источника. Т.е. в приемник копируются все данные из источника.
Выполняется операция:
[Любая версия / Проект] + [Любая версия / Проект] => [Новая версия]
В данном случае доступен только один тип слияния — Дополнение данных.
При слиянии с заменой данных:
- Удаляем все сущности в приемнике, кроме тех, что связаны с фактическими данными. Таковыми могут быть только задачи.
- Копируем все сущности из источника в приемник.
- Если какая-либо задача осталась в приемнике и её не было в источнике, то она поднимается на верхний уровень иерархии в списках задач и добавляется в конец списка, при этом помечается как выполненная.
Особенности логики слияния с заменой:
|
Сущность
|
Логика замены
|
|
Член команды
|
Команда приемника заменяется командой источника с некоторыми исключениями:
- Из приемника не удаляются члены команды, на которых есть бронирование или запрос на ресурс, в таком случае для члена команды снимаем флаг Активно (т.е. отключаем члена команда).
|
|
Задачи
|
Список задач приемника заменяется списком задач источника с некоторыми исключениями:
- Если уже были фактические данные, связанные с задачей (задача выбрана в таймшите/ЗнЗ/Акте/Счете/Проводке вне зависимости от их статуса), которой нет в источнике, то такие задачи из приемника не удаляются, а помечаются как выполненные и перемещаются на уровень этапа в конец списка.
|
|
Связи задач
|
-
При удалении задач из приемника (путем удаления их в источнике и последующего слияния) удаляются связи от и к этой задаче (общая существующая логика редактирования задач).
-
Проверяется наличие циклических зависимостей. Если таковые есть — исключение (в штатной ситуации это невозможно, только при нарушении структуры данных).
-
Связи с ведущими задачами в источнике восстанавливаются в приемнике (случай, когда была создана версия проекта, а затем в проекте были удалены связи с ведущей задачей, т. о. после слияния, связи в проекте восстановятся из версии) .
|
|
Оценка биллинга
|
Записи автобиллинга не сливаются, т. е. не выполняется их копирование в приемник.
При этом после завершения слияния автоматически вызывается логика автобиллинга.
|
При слиянии с дополнением данных:
- Выполняется сопоставление сущностей в источнике и приемнике.
- Если сопоставление удалось, то такие сущность будут объединены. При этом могут быть конфликты, которые заблокируют слияние.
- Если сопоставление не удалось, то сущность из источника будет скопирована в приёмник.
Логика сопоставления и объединения:
|
Сущность
|
Как выполняется сопоставление
|
Как выполняется объединение
|
|
Член команды
|
Для именованных членов команды (с типом Пользователи и Подразделение) уникальным идентификатором является Id ресурса. Для локальных дженериков сопоставление выполняется по его имени.
|
Если сопоставление не найдено, то сущность из источника копируется в приемник. Иначе приемник не изменяется.
|
|
Ставка себестоимости члена команды
|
По дате ввода в действие.
|
Если сопоставление не найдено, то сущность из источника копируется в приемник. Иначе приемник не изменяется.
Если сопоставление найдено и ставка/валюта отличаются — объединение невозможно, это конфликт.
|
|
Задача проекта
|
У задачи есть свойство CrossId. Это уникальный номер, присваиваемый при создании задачи. При создании версии путем копирования в новой задаче (созданной для версии) этот номер сохраняется. Тем самым у задач есть сквозной номер внутри проекта и по нему выполняется сопоставление.
|
Если сопоставление не найдено, то сущность из источника копируется в приемник. Иначе приемник не изменяется.
Если задача источника отсутствует в приемнике (т.е. её надо скопировать в приёмник), но при этом в источнике она стала суммарной (т.е. в приемнике надо изменить другие задачи, сделав их подчиненными) — то это конфликт (т.к. запрещено менять данные в приемнике).
См. пример № 1.
|
|
Назначение на задачу
|
По сопоставленному Id члена команды.
|
Если сопоставление не найдено, то сущность из источника копируется в приемник. Иначе приемник не изменяется.
|
|
Зависимости задач
|
По CrossId задачи и CrossId зависимой задачи.
|
Если сопоставление не найдено, то сущность из источника копируется в приемник, если такая связь не нарушает правила зависимостей. Иначе приемник не изменяется.
|
|
Тариф проекта
|
Сопоставление выполняется по наименованию тарифа.
|
Если сопоставление не найдено, то сущность из источника копируется в приемник. Иначе приемник не изменяется.
|
|
Назначение на тариф
|
По сопоставленному Id члена команды.
|
Если сопоставление не найдено, то сущность из источника копируется в приемник. Иначе приемник не изменяется.
|
|
Ставка тарифа
|
По дате ввода в действие.
|
Если сопоставление не найдено, то сущность из источника копируется в приемник. Иначе приемник не изменяется.
Если сопоставление найдено, но ставка/валюта отличаются — объединение невозможно, это конфликт.
|
|
Ячейка ресурсного плана
|
Сопоставление выполняется по дате, CrossId задачи и сопоставленному члену команды.
|
Если сопоставление найдено — часы, а также все суммарные значения источника и приемника складываются. Иначе сущность из источника копируется в приемник.
Если сопоставление найдено, но изменены ставки (себестоимости, биллинга или стандартной себестоимости) — то это конфликт.
|
|
Оценка выручки
|
Сопоставление выполняется по дате и CrossId задачи.
|
Если сопоставление найдено — сумма источника и приемника складываются. Иначе сущность из источника копируется в приемник.
|
|
Оценка биллинга
|
Сопоставление выполняется по Дате счета, Даты оплаты, CrossId задачи и признаку «Авто».
|
Если сопоставление найдено — сумма источника и приемника складываются. Иначе сущность из источника копируется в приемник.
Т.е. для записей, созданных логикой автобиллинга, работает таже логика что и для ручных записей — они «как есть» дополняют приемник.
|
|
Оценка затрат
|
Сопоставление выполняется по дате, CrossId задачи, Типу затрат и CrossId правила.
|
Если сопоставление найдено — сумма источника и приемника складываются. Иначе сущность из источника копируется в приемник.
Записи, созданные через правило периодических затрат, дополняют приемник так же, как и записи созданные вручную.
|
|
Правила периодических затрат
|
Сопоставление выполняется по CrossId правила.
|
Если сопоставление найдено — сумма источника и приемника складываются. Иначе сущность из источника копируется в приемник.
Задача правила сопоставляется по CrossId (для поиска задачи в приемнике).
|