Árbol de páginas

Versiones comparadas

Clave

  • Se ha añadido esta línea.
  • Se ha eliminado esta línea.
  • El formato se ha cambiado.

...

En este apartado se recogerá el desglose presupuestario del proyecto en solicitud. Para este desglose se partirá de las restricciones de elegibilidad añadidas en la convocatoria. El presupuesto se deberá desglosar en base a los conceptos de gasto configurados a nivel global en el SGI (IU-CSP-0090 - Gestión de conceptos de gasto). Para cada concepto de gasto seleccionado:

Como la convocatoria puede admitir varias entidades financiadoras o incluso el proyecto (solicitud en este momento) podría tener otras fuentes de financiación adicionales a las que promueven la convocatoria, el desglose del presupuesto se recogerá especificado por entidad financiadora.

De esta forma, para cada entidad financiadora especificada en la convocatoria podrá recogerse un desglose de presupuesto, a partir de :

  • Concepto de gasto. Que será seleccionable a partir de los conceptos de gasto definidos en el apartado Elegibilidad de la convocatoria. El sistema informará si es elegible o no y si tiene un importe límite premarcado, de acuerdo a la información registrada en la convocatoria.
  • Para el concepto de gasto se deberá de indicar:
    • El importe solicitado (campo obligatorio)
    • Anualidad (no obligatorio)
    • Se
  • El sistema informará si es elegible o no y si tiene un importe límite premarcado, de acuerdo a la información registrada en la convocatoria.
  • Se deberán de indicar obligatoriamente:
    • El importe solicitado 
    • El importe total presupuestado
  • Adicionalmente se
    • dispondrá de un campo Observaciones para recoger en formato de texto libre cualquier nota de interés sobre la consideración del concepto de gasto en el presupuesto

Con los importes introducidos en todos los conceptos de gasto, se obtendrán dos campos calculados:

  • Importe total solicitado 
  • Importe total presupuestado

Entidades de configuración asociadas

...

Los roles del equipo de proyecto serán configurables por los ACT-CSP-004-Administrador. No será habitual que los valores cambien tras la implantación, pero el SGI dará cobertura a ello. La definición de un tipo de rol de proyecto se realizará por medio de los siguientes campos:

  • Abreviatura
  • Nombre
  • Descripción
  • Indicador de si el rol es el principal del equipo. 
  • Indicador de si el rol es el responsable económico del equipo
  • Activo. Indicador de si el tipo de rol está o no activo en la configuración del SGI.

Los indicadores de rol principal y responsable económico son necesarios por el hecho de permitir la configuración de nombres de roles. De esta forma el SGI no establece de antemano que el rol principal sea llamado siempre, por ejemplo, "investigador principal". Aunque será lo habitual, una Universidad podría darle otra nomenclatura. No se limitará el número de roles para los que se marque el indicador de rol principal y/o económico, pudiendo un mismo rol estar marcado con ambos indicadores.

Con el campo "Activo" se permitirá que un rol sea desactivado de la configuración del SGI para que no pueda ser asociado a los nuevos componentes de los equipos de proyecto pero de forma que se puedan seguir manteniendo en el histórico de datos del SGI todas las referencias existentes para equipos de proyectos ya creados utilizando ese rol.

Tanto el campo "abreviatura" como el "nombre" deberán de ser únicos. No se permitirá la repetición de estos valores aunque ya no estuvieran activos (campo "Activo" a "no").

Los tipos definidos en la tabla "tipo rol proyecto" que estén activos (campo "Activo" a "sí") serán los que se muestren en los desplegables "rol" de los apartados de "Equipo de proyecto" de solicitudes y proyectos.

Ver formularios de gestión en IU-CSP-0100 - Gestión de roles de equipo de proyecto

...

En función de si el presupuesto se recoge ya expresado en anualidades, el mismo concepto de gasto podrá repetirse varias veces. El sistema solo impondrá como limitación que el mismo concepto de gasto no se repita para una misma anualidad y entidad financiadora. Es decir, un mismo concepto de gasto también podría aparecer para una misma anualidad en el desglose de presupuesto asociado a distintas entidades financiadoras.


De forma adicional, se podrán añadir al presupuesto otras entidades financiadoras . Estas entidades procederán, como funcionamiento global del SGI, de la integración con el SGE: eentidades pagadoras REQ - NF - INT - 0010 - SGE - 0040 - Entidad Pagadora. Para cada una de estas entidades el presupuesto se podrá especificar también en base a conceptos de gasto.

  • Concepto de gasto. Será seleccionable del total de conceptos de gasto activos configurados a nivel global en el SGI (IU-CSP-0090 - Gestión de conceptos de gasto). En este caso no se establecerá limitación de acuerdo a la Elegibilidad de la convocatoria, puesto que la entidad financiadora no es una de las promotoras de la convocatoria.
  • Para el concepto de gasto se podrá recoger:
    • Importe presupuestado (campo obligatorio)
    • Anualidad (no obligatorio)
    • Observaciones

Como en el caso del presupuesto vinculado a las entidades financiadoras de la convocatoria, el mismo concepto de gasto podrá repetirse varias veces.  El sistema solo impondrá como limitación que el mismo concepto de gasto no se repita para una misma anualidad y entidad financiadora. 


Con los importes introducidos en todos los conceptos de gasto, para todas las entidades financiadoras, se obtendrán tres campos calculados:

  • Total del presupuesto solicitado con financiación de la convocatoria. Obtenido a partir de la suma de los importes de todos los conceptos de gasto recogidos en los desgloses presupuestarios asociados a las entidades financiadoras de la convocatoria. 
  • Total del presupuesto no financiado bajo la convocatoria. Obtenido a partir de la suma de los importes de todos los conceptos de gasto recogidos en los desgloses presupuestarios asociados a las entidades financiadoras ajenas a la convocatoria.
  • Total del presupuesto. Suma de los dos totales anteriores.



Entidades de configuración asociadas

Ancla
rol_equipo
rol_equipo
Tipos de rol de proyecto

Los roles del equipo de Los roles de los socios colaboradores en el desarrollo de un proyecto serán configurables por los ACT-CSP-004-Administrador. Como en el caso de los roles del equipo de proyecto, no será No será habitual que los valores cambien tras la implantación, pero el SGI dará cobertura a ello. La definición de un tipo de rol de socio colaborador proyecto se realizará por medio de los siguientes campos:

  • Abreviatura
  • Nombre
  • Descripción
  • Indicador de si el rol es el principal del equipo. 
  • Indicador de si el rol es el responsable económico del equipo
  • Activo. Indicador de si el tipo de rol está o no activo en la configuración del SGI.

Con el campo "Activo" se permitirá que un rol sea desactivado de la configuración del SGI para que no pueda ser asociado a los nuevos colaboradores de proyecto pero de forma que se puedan seguir manteniendo en el histórico de datos del SGI todas las referencias existentes para proyectos ya creados utilizando ese rol.

Tanto el campo "Abreviatura" como el "Nombre" deberán de ser únicos. No se permitirá la repetición de estos valores aunque ya no estuvieran activos (campo "Activo" a "no").

Los tipos definidos en la tabla "tipo rol socio" que estén activos (campo "Activo" a "sí") serán los que se muestren en los desplegables "rol" de los apartados de "Socios colaboradores" de solicitudes y proyectos.

Ver formularios de gestión en IU-CSP-0105 - Gestión de roles de socios de proyecto

...

Los indicadores de rol principal y responsable económico son necesarios por el hecho de permitir la configuración de nombres de roles. De esta forma el SGI no establece de antemano que el rol principal sea llamado siempre, por ejemplo, "investigador principal". Aunque será lo habitual, una Universidad podría darle otra nomenclatura. No se limitará el número de roles para los que se marque el indicador de rol principal y/o económico, pudiendo un mismo rol estar marcado con ambos indicadores.

Con el campo "Activo" se permitirá que un rol sea desactivado de la configuración del SGI para que no pueda ser asociado a los nuevos componentes de los equipos de proyecto pero de forma que se puedan seguir manteniendo en el histórico de datos del SGI todas las referencias existentes para equipos de proyectos ya creados utilizando ese rol.

Tanto el campo "abreviatura" como el "nombre" deberán de ser únicos. No se permitirá la repetición de estos valores aunque ya no estuvieran activos (campo "Activo" a "no").

Los tipos definidos en la tabla "tipo rol proyecto" que estén activos (campo "Activo" a "sí") serán los que se muestren en los desplegables "rol" de los apartados de "Equipo de proyecto" de solicitudes y proyectos.

Ver formularios de gestión en IU-CSP-0100 - Gestión de roles de equipo de proyecto

Ancla
rol_socio
rol_socio
Tipos de rol de socios colaboradores

Los roles de los socios colaboradores en el desarrollo de un proyecto serán configurables por los ACT-CSP-004-Administrador. Como en el caso de los roles del equipo de proyecto, no será habitual que los valores cambien tras la implantación, pero el SGI dará cobertura a ello. La definición de un rol de socio colaborador se realizará por medio de los siguientes campos:

  • Abreviatura
  • Nombre
  • Descripción
  • Activo. Indicador de si el tipo de rol está o no activo en la configuración del SGI.

Con el campo "Activo" se permitirá que un rol sea desactivado de la configuración del SGI para que no pueda ser asociado a los nuevos colaboradores de proyecto pero de forma que se puedan seguir manteniendo en el histórico de datos del SGI todas las referencias existentes para proyectos ya creados utilizando ese rol.

Tanto el campo "Abreviatura" como el "Nombre" deberán de ser únicos. No se permitirá la repetición de estos valores aunque ya no estuvieran activos (campo "Activo" a "no").

Los tipos definidos en la tabla "tipo rol socio" que estén activos (campo "Activo" a "sí") serán los que se muestren en los desplegables "rol" de los apartados de "Socios colaboradores" de solicitudes y proyectos.

Ver formularios de gestión en IU-CSP-0105 - Gestión de roles de socios de proyecto

Ancla
#tipo_estado_solicitud
#tipo_estado_solicitud
Tipos de estado de solicitud

La tabla "Tipo estado solicitud" contendrá el código interno y el nombre de los estados que definen el ciclo de vida de una solicitud. Estos estados serán fijos en el SGI, para cualquier implantación, puesto que existe un comportamiento predefinido del sistema sobre ellos. Sí, podrá ser modificado en cada implantación el nombre elegido par cada uno de los estados, pero no el número de estados o el comportamiento del ciclo de vida de los mismos. La configuración de los nombres de los estados deberá ser realizada por ACT-008-Sysadm.

El número de estados y el nombre inicialmente propuesto para cada uno de ellos es:

    • Borrador. Estado inicial. Es el estado en el que por defecto se creará la solicitud en el SGI. Una solicitud en estado borrador solo podrá ser pasada a estado "presentada".
    • Presentada: Una solicitud solo pasará a estado "presentada" de manera manual, porque así lo indique o bien el  ACT- CSP-001-Investigador que la haya creado o bien cualquier ACT-CSP-004-Administrador o ACT-CSP-003-Gestor de la unidad de gestión correspondiente, en caso que la solicitud no esté abierta al registro directo por parte de los ACT- CSP-001-Investigador.
    • Admitida provisional. Estado intermedio, solo disponible para los ACT-CSP-004-Administrador o ACT-CSP-003-Gestor independientemente que la solicitud haya sido registrada en el SGI directamente por un ACT- CSP-001-Investigador.
    • Excluida provisional. Estado intermedio, solo disponible para los ACT-CSP-004-Administrador o ACT-CSP-003-Gestor independientemente que la solicitud haya sido registrada en el SGI directamente por un ACT- CSP-001-Investigador.
    • Alegada admisión. Estado intermedio. Este estado podrá ser marcado por ACT-CSP-001-Investigador, en caso que la solicitud esté abierta al registro directo por parte de los ACT- CSP-001-Investigador en el SGI, o por cualquier ACT-CSP-004-Administrador o ACT-CSP-003-Gestor de la unidad de gestión correspondiente. Indicará que el ACT-CSP-001-Investigador ha presentado la alegación pertinente.
    • Desistida. Estado final, que indicará que el Solicitud queda desestimada por el propio solicitante. Este estado podrá ser puesto por ACT- CSP-001-Investigador, en caso que la solicitud esté abierta al registro directo por parte de los ACT- CSP-001-Investigador o por cualquier ACT-CSP-004-Administrador o ACT-CSP-003-Gestor de la unidad de gestión correspondiente, para indicar que la Solicitud ha sido desestimada por el propio Solicitante.
    • Excluida. Estado final. La solicitud no ha sido admitida. Solo disponible para los ACT-CSP-004-Administrador o ACT-CSP-003-Gestor independientemente que la solicitud haya sido registrada en el SGI directamente por un ACT- CSP-001-Investigador.
    • Admitida definitiva. Estado intermedio, solo disponible para los ACT-CSP-004-Administrador o ACT-CSP-003-Gestor independientemente que la solicitud haya sido registrada en el SGI directamente por un ACT- CSP-001-Investigador.
    • Concedida provisional. Estado intermedio, solo disponible para los ACT-CSP-004-Administrador o ACT-CSP-003-Gestor independientemente que la solicitud haya sido registrada en el SGI directamente por un ACT- CSP-001-Investigador.
    • Denegada provisional. Estado intermedio, solo disponible para los ACT-CSP-004-Administrador o ACT-CSP-003-Gestor independientemente que la solicitud haya sido registrada en el SGI directamente por un ACT- CSP-001-Investigador.
    • Alegada evaluación. Estado intermedio. Este estado podrá ser marcado por ACT-CSP-001-Investigador, en caso que la solicitud esté abierta al registro directo por parte de los ACT- CSP-001-Investigador en el SGI, o por cualquier ACT

La tabla "Tipo estado solicitud" contendrá el código interno y el nombre de los estados que definen el ciclo de vida de una solicitud. Estos estados serán fijos en el SGI, para cualquier implantación, puesto que existe un comportamiento predefinido del sistema sobre ellos. Sí, podrá ser modificado en cada implantación el nombre elegido par cada uno de los estados, pero no el número de estados o el comportamiento del ciclo de vida de los mismos. La configuración de los nombres de los estados deberá ser realizada por ACT-008-Sysadm.

El número de estados y el nombre inicialmente propuesto para cada uno de ellos es:

  • Borrador: estado inicial.
  • Presentada: estado intermedio, que constituirá un ciclo iterativo junto con los estados "en estudio" y "en subsanación".
  • En estudio: estado intermedio, que constituirá un ciclo iterativo junto con los estados "en estudio" y "en subsanación".
  • En subsanación: estado intermedio, que constituirá un ciclo iterativo junto con los estados "en estudio" y "en subsanación".
  • Abandonada: estado final, podrá ser puesto por ACT- CSP-001-Investigador, para indicar  que la Solicitud  queda desestimada por iniciativa propia. También podrá ser utilizado por ACT
    • -CSP-004-Administrador o ACT-CSP-003-
  • Gestor para indicar que la Solicitud ha sido desestimada por el propio Solicitante.
    • Gestor de la unidad de gestión correspondiente. Indicará que el ACT-CSP-001-Investigador ha presentado la alegación pertinente.
    • Concedida. Es un
  • Concedida:
    • estado final. Solo los ACT-CSP-004-Administrador o ACT-CSP-003-Gestor podrán marcar una solicitud como concedida. A partir de este estado se podrá iniciar el registro del  Proyecto asociado.
  • Rechazada: estado
    • Denegada. Es un estado final. Solo los ACT-CSP-004-Administrador o ACT-CSP-003-Gestor podrán marcar una solicitud como rechazada. La solicitud no podrá quedar vinculada a ningún Proyecto.