Contract
PLIEGO DE PRESCRIPCIONES TÉCNICAS QUE HA DE REGIR LA CONTRATACIÓN DE UNA APLICACIÓN INFORMÁTICA Y CONSULTORÍA PARA LA GESTIÓN INTEGRAL DE NÓMINA Y RECURSOS HUMANOS PARA EL AYUNTAMIENTO DE GUADALARA
ÍNDICE
1. INTRODUCCIÓN 4
2. OBJETO DEL CONTRATO 4
3. DETALLE DE LOS SERVICIOS: REQUISITOS FUNCIONALES Y TECNOLÓGICOS 4
3.1. Requisitos funcionales del sistema 4
3.1.1 Gestión de los Recursos Humanos 5
3.1.1.1 Organigrama y Gestión de la relación de puestos de trabajo (RPT) 6
3.1.1.2 Gestión de Plantilla 6
3.1.1.3 Gestión de Personas 7
3.1.1.4 Contratación y Expedientes Administrativos 7
3.1.1.5 Oferta de Empleo Público 8
3.1.1.6 Simulaciones y Presupuestos 9
3.1.1.7 Sistema Delt@ 9
3.1.2 Portal del Empleado 10
3.1.3 Gestión de la Nómina 11
3.1.3.1 Aplicaciones Presupuestarias. Integración con contabilidad 14
3.1.3.2 Préstamos y Embargos 15
3.1.3.3 Gestión de Profesionales 15
3.1.4 Herramientas y Utilidades 16
3.1.4.1 Generador de Consultas, Listados e Impresos 16
3.1.4.2 Auditoría de Seguridad 16
3.1.4.3 Módulo de Traspaso de Datos 17
3.1.4.4 Editor SQL 17
3.2. Requisitos Técnicos del Sistema 17
3.2.1 Requisitos de integración con otros sistemas 17
3.2.2 Requisitos de Seguridad 17
3.2.2.1 Requisitos generales 17
3.2.2.2 Seguridad lógica 18
3.2.3 Entorno Tecnológico 19
3.2.3.1 Arquitectura global del Sistema 19
3.2.3.2 Módulos Web 19
3.2.3.3 Plataforma Servidor BBDD 19
3.2.3.4 Plataforma Servidor WEB 19
3.2.3.5 Plataforma cliente 19
3.2.3.6 Otras consideraciones 19
4. DOCUMENTACIÓN 20
5. PLANIFICACIÓN Y FASES 20
6. EQUIPO DE TRABAJO 21
7. PRECIO DE LICITACIÓN 21
8. PLAZO DE EJECUCIÓN 22
9. GARANTÍA, MANTENIMIENTO Y SERVICIO DE SOPORTE DE ATENCIÓN AL CLIENTE 22
10. TRANSFERENCIA TECNOLÓGICA 22
11. PROPIEDAD INTELECTUTAL Y CONFIDENCIALIDAD 22
11.1. Propiedad Intelectual 22
11.2. Confidencialidad 22
12. PRESENTACIÓN DE PROPOSICIONES Y ESTRUCTURA DE LA OFERTA 23
1. INTRODUCCIÓN
El nuevo marco regulador del Empleado Público y la observancia de los principios de eficacia y eficiencia en el ámbito público hacen necesaria la dotación de herramientas profesionales y adecuadas para atender las demandas en materia de gestión de personal.
Por ello y con la finalidad de atender la existente en este ámbito, resulta imprescindible, constituyendo el objeto del presente pliego el CONTRATO DE SUMINISTRO DE SOFTWARE, INSTALACIÓN Y PUESTA EN MARCHA DEL MISMO Y CONSULTORÍA PARA LA GESTIÓN INTEGRAL DE LOS RECURSOS HUMANOS Y LA NÓMINA EN EL AYUNTAMIENTO DE
GUADALAJARA. Asimismo se hace necesario su soporte en un sistema de trabajo moderno que posibilite la gestión de una forma ágil y sencilla.
2. OBJETO DEL CONTRATO
A continuación se relacionan los objetivos que debe cubrir la solución ofertada:
• Dotación a la Gestión de Recursos Humanos de un instrumento abierto y flexible para gestionar de forma integrada toda la información cumpliendo con las obligaciones y estándares legales aplicables por razón de la materia.
• Obtención de un sistema de información modular, parametrizable y flexible que permita, de forma sencilla, la implementación de nuevas necesidades, y la actualización de las ya existentes.
• Integración de la información, de manera que todos los módulos que componen el sistema se comuniquen entre sí, según una filosofía de dato único, es decir, que la información se introduzca desde un módulo pero que el resto pueda interactuar con dicha información, sin tener que volver a ser introducida y que permitan homogeneizar la gestión.
3. DETALLE DE LOS SERVICIOS: REQUISITOS FUNCIONALES Y TECNOLÓGICOS
3.1. Requisitos funcionales del sistema
La aplicación objeto del presente concurso deberá satisfacer las siguientes especificaciones de carácter general, técnico y funcional.
La aplicación de recursos humanos, que llevará la gestión de las personas que trabajan en el Ayuntamiento de Guadalajara, cualquiera que sea su régimen jurídico (laboral temporal, laboral permanente, funcionario interino, funcionario xx xxxxxxx, eventual, etc.).
Actualmente, el organismo gestiona 800 personas desde 1 único Centro Gestor de RRHH, pero la licencia contratada deberá contemplar la posibilidad de gestionar hasta 1.000 personas para poder absorber posibles puntas de contratación. El sistema deberá contemplar un mínimo de 10 usuarios concurrentes.
Por lo tanto debe ser una aplicación informática para la gestión de los recursos humanos de una administración local con todas las características funcionales y el marco normativo legal que le es propio, debe recoger la multi-aplicación, es decir, que permita la gestión de varias entidades (Organismos Autónomos, Empresas municipales ..)
Los módulos del sistema deben estar completamente integrados con una base de datos única, de forma que no sólo compartan la información relevante entre ellos sino que con su interacción consiga la máxima eficacia administrativa
Integrar la información manejada por el servicio con sistemas externos estándar de la Administración, estableciendo los mecanismos y procedimientos para intercambiar información, los cuales deben permitir también la explotación de datos a través del portal del empleado integrado en la intranet municipal.
Como características funcionales indispensables, aparte de las mencionadas anteriormente, se consideran indispensables los siguientes módulos, que deberán cumplir las soluciones ofertadas:
• Organigrama y Gestión de Relación de Puestos de Trabajo
• Gestión xx Xxxxxxxxxx
• Gestión de Personas
• Contratación y Expedientes Administrativos.
• Gestión de Nóminas
• Partidas presupuestarias
• Préstamos y Embargos
• Simulación y Presupuestos
• Sistema Delt@
• Sistema Contrat@ y Certific@
• Servicios Web para enlazar con Intranet Corporativa
• Sistema de Indicadores para la Toma de Decisiones para la Dirección (Bussiness Intelligence).
• Herramientas y Utilidades
• Generador de Consultas, Listados e Impresos
• Auditoría de Seguridad
• Módulo de traspaso de datos
• Editor SQL
Otras funcionalidades complementarias del sistema: El sistema suministrado debe disponer de los siguientes módulos complementarios, integrados en el mismo Sistema de Información de RRHH, al objeto de poder ser ampliado en fases posteriores:
• Portal Web del empleado
• Gestión de la Formación
• Gestión de las Prestaciones Sociales
• Gestión del tiempo
• Cuerpo de nómina, según Orden del 30 de Julio de 1992 de confección de nóminas.
• Gestión de Profesionales
• Gestión de centros periféricos
• Módulo para la vigilancia de la salud
• Prevención de riesgos laborales
3.1.1 Gestión de los Recursos Humanos
Esta aplicación debe permitir la gestión y seguimiento de las diferentes incidencias y situaciones de cada una de las personas al servicio del Ayuntamiento, cualquiera que sea su régimen jurídico, así como el histórico de los datos de las mismas. Se puede clasificar funcionalmente la gestión de los recursos humanos en los siguientes apartados o áreas relacionadas entre sí.
3.1.1.1 Organigrama y Gestión de la relación de puestos de trabajo (RPT)
Comprenderá la gestión de todas las actuaciones derivadas del mantenimiento de la estructura organizativa (organigrama) y de la relación de puestos de trabajo. Debe permitir efectuar simulaciones de organigrama y de creación de puestos de trabajo nuevos. Todos los movimientos de la RPT y del organigrama deberán quedar registrados el histórico.
La RPT debe comprender todos los puestos de trabajo vigentes con todas sus características: Código, descripción, unidad, nivel de complemento de destino, complemento específico, tipo de jornada, grupos de adscripción (puestos barrados), sistema de provisión, tipo de puesto de trabajo, titulación específica para desempeñar el puesto, otra formación necesaria para la provisión, formación relevante para su provisión, adscripción a cuerpos y escalas. .
Estos datos deberán estar relacionadas con el registro de personal (persona que lo ocupa), con la plantilla (plaza vinculada al sitio) y con la estructura organizativa (organigrama) y permitirá la relación con la partida presupuestaria a nivel de orgánico, funcional, económico y cuenta del PGC.
La gestión de la estructura de la empresa permitirá la creación, modificación y simulación del árbol del organigrama, con la grabación de los datos históricos. A través del árbol del organigrama se podrá efectuar la asignación de puestos de trabajo y del empleado dentro de la organización. Deberá permitir la impresión del árbol, estableciendo el usuario el nivel de detalle que se quiere imprimir.
La aplicación deberá contemplar adicionalmente, las siguientes funcionalidades:
• Definición genérica xx Xxxxxxxxxx de Puestos, a partir de las cuales se pueden crear todos los puestos de trabajo del organismo.
• A nivel de puesto podrán definirse atributos relacionados con todo el sistema retributivo (C.E., C.D., Nivel, Complementos,…), misión, funciones y tareas del puesto, requisitos de acceso, etc.
• Existirá un versionado de Puestos, para historificar la evolución y cambios en la definición de dichas estructuras.
• Aplicación multiorganigrama, con históricos de movimiento y creación de estructuras y asignaciones a empleados.
• Confección de borradores y diferentes versiones de la Relación de Puestos de Trabajo, orientada a la confección del Presupuesto, y a partir de su aprobación, repercusión en los puestos de trabajo incluidos en dicha RPT.
• Enlace con la Nómina, de las características retributivas de los puestos, a partir de un Buzón de Comunicaciones.
• Posibilidad de impresión del organigrama en formato ofimático
3.1.1.2 Gestión de Plantilla
Se deben incluir los procesos necesarios para crear, modificar, consultar y, en su caso, dar de baja, la información relativa a las plazas de la plantilla. Los cambios deben quedar reflejados en el histórico.
Los datos mínimos a contener son el código de la plaza, denominación, número de orden, escala, subescala, clase, categoría y grupo, forma de ingreso, sistema de selección, tipo de personal y situación de la plaza. Estos datos deberán estar relacionados con el registro de personal (persona que lo ocupa), con la relación de puestos de trabajo (lugar de trabajo al que se encuentra vinculada la plaza) y con la estructura organizativa (organigrama).
• Definición de Plazas, con atributos orientados a gestión presupuestaria, así como un histórico de las personas ocupantes y propietarias a lo largo de la vida de la plaza.
• Gestión de las diferentes situaciones de las Plazas, según las diferentes opciones de ocupación (ocupadas, en provisión, vacantes, a extinguir, etc.)
• Existirá un versionado de Plazas, para historificar la evolución y cambios en la definición de dichas estructuras.
• Extracción de Informes de Plantilla Orgánica, orientados a conocer las dotaciones existentes en el Ayuntamiento, así como para realizar la propuesta de Oferta de Empleo Público en función de las vacantes.
3.1.1.3 Gestión de Personas
Gestión, mantenimiento e histórico del registro general de personal con inclusión de las anotaciones de actos y resoluciones relativas historial administrativo de la persona empleada. Datos personales, familiares, académicas y profesionales. Puestos de trabajo desempeñados, contratos, formación recibida y situaciones administrativas a lo largo de su carrera profesional, antigüedad, servicios previos reconocidos, grado personal consolidado, etc. Gestión y mantenimiento unificado del Registro de personal (expediente de personal) como recopilación de toda la información histórica del personal vinculado con la administración.
La aplicación deberá contemplar adicionalmente, las siguientes funcionalidades:
• Histórico de Situaciones Administrativas, donde se recojan todas las relaciones de servicio de un trabajador, con el desglose de situaciones administrativas vividas en cada una de las relaciones (excedencias, sanciones, reducciones de jornadas, etc.) y con la posibilidad de incluir casos derivados de las comisiones de servicio, y el reconocimiento de servicios prestados en otros organismos, orientado al cálculo de antigüedad, y a la obtención de los Certificados de Servicios Prestados.
• Gestión de múltiples relaciones de servicios y múltiples ocupaciones de los trabajadores del Ayuntamiento (ocupación, reserva, provisión, etc.).
• Cálculo del Grado Consolidado.
• Gestión de la Antigüedad de los empleados, con el reconocimiento de la misma de forma diferenciada a personal funcionario y laboral, con su repercusión en la gestión económica, así como en los históricos de situaciones administrativas de los empleados, de forma que siempre se conozca el número de trienios de cada trabajador, su fecha de último vencimiento, y la fecha del próximo.
• Posibilidad de obtener Certificados del Trabajador, como consecuencia de la Gestión del Histórico de Situaciones Administrativas del Empleado:
• Certificado de Servicios Prestados.
• Certificado de Servicios Previos.
• Certificado de Liquidación de Trienios.
• Otros Certificados.
• Gestión del Absentismo totalmente personalizada y orientada a la Administración Pública.
• Configuración de Tipología Propia de Ausencias (vacaciones, asuntos propios, IT, horas sindicales,…).
• Configuración de Topes distintos según variables de la aplicación (Tipos de Personal, Incrementos por Antigüedad y Trienios, Tipos de Jornada, etc.).
• Incompatibilidad de Ausencias entre sí (No poder juntar días de permiso de vacaciones y asuntos propios).
• Planificación de disponibilidad de personas por centro / departamento / servicio.
• Indicadores de Absentismo por centro / departamento / servicio.
3.1.1.4 Contratación y Expedientes Administrativos
Gestión e impresión de los diferentes Expedientes Administrativos de RRHH, tanto de ámbito Laboral como Funcionario:
• Nombramientos,
• Tomas de posesión,
• Contrataciones,
• Permisos y licencias,
• Cambios de situación administrativa,
• Ceses,
• Trienios,
• Comisiones de Servicios,
• …
Repercutir la información de los expedientes en el registro de Personal del trabajador, todos los cambios procedentes de cada uno de los expedientes. El objetivo es tener la garantía que esta información se ha repercutido en la situación laboral/administrativa del empleado y sus históricos pertinentes de una forma automática según la fecha de repercusión establecida para cada uno de estos expedientes, pudiendo reconstruir fácilmente su historia completa desde la entrada en la entidad. Es decir, una vez procesado el expediente, los usuarios del departamento de Nómina y de RRHH no necesitarán volver a reescribir ni actualizar la información relativa al trabajador, porque ésta debe venir informada automáticamente (previa validación) a partir de la propia anotación realizada desde los expedientes administrativos.
Los requisitos deseados de esta área son:
• Poder definir y establecer el flujo y los estados de tramitación que considere necesarios para llevar a cabo un determinado expediente y la interrelación entre los diferentes estados.
• Seguimiento de cada uno de los expedientes para cada uno de sus estados de tramitación.
• Los usuarios maestros podrán visualizar todos los expedientes para cada uno de los estados, mientras que los usuarios básicos solamente ven los expedientes que se encuentran en los estados de tramitación que pueden gestionar (p.e: borrador, validado, autorizado, impresión de documentos...)
• El sistema debe permitir vincular documentos externos a los expedientes así como generar documentación a partir de los datos del propio expediente (configuración y generación de documentos).
• Los expedientes deben soportar firma electrónica de documentos a través xxx xxxxx-firmas de Acrobat Reader PDF, y la autentificación es compatible con los certificados emitidos por las autoridades reconocidas a nivel estatal (CatCert, FNMT,...)
• Configuración gráfica de las pantallas (organización de la información del usuario campos visibles, requeridos, editables)
• Configuración de las plantillas de precarga de datos, en función del tipo de expediente.
• Configuración de los estados de tramitación, necesarios para resolver cada proceso.
• Configuración de los usuarios que intervienen en cada estado de tramitación
• Configuración de las acciones asociadas a cada estado de tramitación (p.ej. imprimir documentos, cambiar de estado, modificar datos…)
• Configuración de los documentos generados automáticamente para cada estado de tramitación.
3.1.1.5 Oferta de Empleo Público
Se pretende realizar la gestión y la convocatoria oficial de las plazas vacantes derivada tanto de la Oferta Pública de Empleo como del Plan de Promoción Interna.
Contemplar también la provisión de puestos de trabajo según las especificaciones de la Ley 30/84 y sus posteriores Reglamentos de Desarrollo. El objetivo del área es la selección y
promoción del personal de la administración pública. Contempla la gestión de la provisión de los puestos de trabajo, de acuerdo con las características de los mismos determinadas en la RPT, a través de los sistemas previstos legalmente (Definitivo: concurso, libre designación. Temporales: adscripción provisional, comisión de servicios, etc.).
Las características que se demandan son:
• Gestionar las pruebas selectivas y baremación de méritos, para el ingreso del personal en la Administración utilizando un sistema de selección preestablecido (concurso, oposición, concurso-oposición…).
• Gestión de Acreditaciones de cada uno de los candidatos.
• Importación de resultados de pruebas selectivas al sistema de búsqueda, para localizar a los mejores candidatos.
• Gestión de Tribunales.
• Gestionar las diferentes bolsas de empleo, derivadas de la resolución de las convocatorias formadas por candidatos aptos sin plaza.
• Gestionar convocatorias con tratamiento de candidatos internos y externos.
• Tratamiento de toda la documentación impresa relativa a listas provisionales/definitivas de candidatos admitidos/excluidos, gestión de tribunales, control de plazos, fechas, citaciones y registro de datos curriculares de los candidatos (datos personales, académicos, profesionales…)
• Integración con los sistemas de Contratación y de Expedientes Administrativos de Alta en el Sistema de Gestión de RRHH y Nóminas.
3.1.1.6 Simulaciones y Presupuestos
El objetivo de esta área es realizar el anteproyecto de presupuestos (Masa Salarial) y la gestión de los costes de personal, calcular e imprimir la masa salarial real de un determinado ejercicio, la valoración parcial de una Plantilla/RPT teóricas, o incluso las propuestas de nuevas contrataciones. Finalmente se debe poder obtener un resumen de efectivos presupuestados por conceptos salariales.
El alcance de este módulo debe abarcar las siguientes funcionalidades:
• Proporcionar la información necesaria para la elaboración de la Solicitud de la Masa Salarial del ejercicio siguiente.
• Permitir simular un cálculo aproximado de la cuantía de presupuestos del ejercicio siguiente, teniendo en cuenta la posibilidad de simular distintos escenarios presupuestarios, indicando las dotaciones existentes para cada uno de los periodos presupuestados, y con la posibilidad de la variación de determinadas circunstancias.
• El Usuario puede aplicar Porcentajes de incremento o disminución para cada concepto salarial y calcular porcentajes de aumento o disminución sobre una o varias partidas presupuestarias. Evidentemente también puede manipular libremente cualquier importe de conceptos o partidas presupuestarias.
• Gestionar las propuestas de gasto para nuevas contrataciones, simulando su coste según distintas variables (tipo de contrato, tiempo de contratación, conceptos personales, etc.).
3.1.1.7 Sistema Delt@
El alcance de esta área debe abarcar las siguientes funcionalidades:
• Gestión y tramitación de los partes de accidente, tanto en modalidad de baja médica, como sin baja médica
• Gestión y tramitación de los partes de enfermedad profesional
• Comunicación con el sistema telemático Delt@, en formato XML, tanto para el parte de accidente con baja médica, como de la relación mensual de accidentes sin baja médica
• Posibilidad de extracción de la información a través de informes
3.1.1.8 Sistemas Contrat@ y Certific@
Comunicación de contratos y certificados de empresa con los sistemas telemáticos Contrat@ y Certific@.
3.1.2 Portal del Empleado
Con el objetivo de descentralización y optimización de los procesos de gestión de personal se requiere una solución basada en tecnología Web que permita a los empleados gestionar solicitudes, cambios de sus datos personales y acceso a documentación relativa a sus nóminas, certificados, etc.
Se requieren las siguientes funcionalidades:
• Es obligatorio que El Portal del empleado/a esté completamente integrado con la solución de nómina y recursos humanos de la solución ofertada. El Portal del Empleado/a debe estar soportado con tecnología HTML que permita conectar a través de un Navegador de Internet (Microsoft Internet Explorer, Firefox).
• El Portal debe disponer de una herramienta para gestión de procesos (Workflow) de tal manera que se puedan definir diferentes flujos de procesos en función del tipo de solicitud/autorización que se realiza (vacaciones, formación, etc.)
• El sistema de Workflow debe realizar notificaciones a través de e-mail para que los/as solicitantes y autorizadores puedan estar informados del proceso.
• El Portal debe disponer de un módulo de administración independiente que permita gestionar niveles de seguridad, alta de usuarios, gestión de contenidos, personalización, etc.
• La seguridad del Portal debe estar basada en el establecimiento de roles, se deben poder crear tantos roles como se necesiten y asignar éstos a usuarios/as. Xxxx permitirse adjudicar varios roles a un mismo usuario/a.
• Se requiere que el sistema de Seguridad del Portal permita definir qué datos puede consultar el/la Responsable de las personas que dependen de él.
• Gestión de Solicitudes que se deben gestionar desde el acceso de empleado/a: Gestión de vacaciones, Inscripción a cursos, Gestión de viajes, Cambio de domicilio, Cambio cuenta bancaria, Cambio porcentaje IRPF, Cambio otros datos personales, Solicitud permisos y licencias, Gestión de gastos personales, Notificación de ausencias/incidencias, Solicitudes de préstamos y anticipos.
• Acceso a documentos electrónicos consulta/impresión/archivo: Nóminas archivadas, Certificado de Retenciones, Contrato de trabajo, Otras certificaciones.
• Acceso a información sobre datos de empleado: Situación de Solicitudes (pendientes, aceptadas, rechazadas, etc), Tablón de anuncios, Documentación on-line para empleados, Consulta de saldos de vacaciones y permisos (disfrutados/pendientes), Consulta de Calendario de su centro de trabajo o particular, Directorio telefónico.
• Cuando el Ayuntamiento decida implantar otros módulos del ámbito de los Recursos Humanos, el Portal del empleado ofertado debe contemplar la posibilidad de realizar, desde el perfil de empleado/a las siguientes funcionalidades:
• Consulta del Catálogo de formación oficial.
• Evaluación de cursos realizados.
• Consulta de la formación realizada
• Consulta de puestos vacantes
• Solicitud de candidatura a puesto vacante
Además, el/la responsable debe tener las siguientes posibilidades de gestión:
• Autorización de las Solicitudes realizadas por las personas que dependen jerárquicamente de él y que sean definidas en el flujo de procesos como responsable.
• Consulta de los datos que se definan como visibles de las personas que dependen jerárquicamente de él.
• Consulta de Calendario laboral de sus empleados, individual o en grupo.
• Consulta de la formación realizada por sus empleados
• Solicitud para apertura de puestos vacantes
3.1.3 Gestión de la Nómina
La gestión de nóminas y seguros sociales comprende la tramitación y gestión de todos los expedientes, actas y documentos que integran el sistema retributivo, hacienda y de seguridad social del personal del Ayuntamiento.
Este apartado debe cumplir como mínimo las siguientes características funcionales:
• Gestionar la nomina según las relaciones laborales que se dan en la actualidad:
• Funcionarios
• Xx Xxxxxxx
• Interinos
• En Prácticas
• Eventuales
• Laborales
• Fijos
• Fijos discontinuos
• Indefinidos por sentencia (continuos o discontinuos)
• Temporales (eventuales, atendiendo a los diferentes tipos de contrato: por obra ó servicio, por circunstancias de la producción, etc.).
• Altos Cargos
• Becarios
• Profesionales.
• Disponer de una Base de Datos de RRHH totalmente integrada, en la que la gestión realizada en otros módulos, como en el módulo de gestión de Relaciones de Puestos de Trabajo, Convocatorias de selección, Expedientes administrativos, etc. se traspase al módulo de la nómina, mediante un módulo de comunicación, en el cual los responsables de la nómina puedan revisar la información que va a formar parte de la nómina, decidiendo en cada caso si se incorpora a la nómina y en qué momento.
• Contemplar el proceso de gestión de cualquier nómina de el Ayuntamiento de Guadalajara (normal, atrasos, ayudas sociales, etc.), efectuando el cálculo de la nómina, la gestión de las cotizaciones a la S.S., el cálculo del IRPF, elaborando la documentación justificativa de la misma a efectos contables y presupuestarios, etc.
• Permitir la generación de las distintas nóminas de un mes para todo el personal o por grupos (de empleados, de puestos, etc.), así como poder realizar todos los recálculos que se quiera mientras la nómina correspondiente al grupo no esté cerrada; teniendo en cuenta que la gestión para el cálculo de cotizaciones a la SS y del IRPF, exige la refundición de la información contenida en las distintas nominas mensuales en un único documento, siguiendo el criterio del DNI, siendo este documento en el primer caso mensual y en el segundo anual.
• Disponer un módulo de generación de nóminas basado en una estructura absolutamente parametrizable, donde se puedan componer distintas tablas salariales, definir distintos tratamientos de los conceptos que componen la nómina a efectos de cotización, tributación, etc.., así como tratamientos de IT, pagas extras, etc..
• Facilitar una definición parametrizable de los comportamientos y formulación de conceptos retributivos, que permita además establecer condiciones para la aplicación de dichas fórmulas. Esta definición deberá permitir incorporar nuevos conceptos de una forma ágil y sencilla, de manera que un usuario de la aplicación pudiera definirlos sin necesidad de incluir programación alguna salvo en casos excepcionales, justificados por cambios legales.
• Disponer de herramientas de actualización de los importes definidos en la estructura retributiva del Organismo.
• Elaborar los ficheros AFI para efectuar la comunicación a la Tesorería General de la Seguridad Social (TGSS) de las incidencias relativas a la afiliación: altas, bajas, variaciones de datos de trabajadores, así como consultas de trabajadores y empresas, eliminación de movimientos comunicados con anterioridad. Permitir al usuario señalar la afiliación on-line realizada desde fuera del sistema
• Confeccionar los modelos oficiales de los contratos en formato de documento de Microsoft Word para Windows, permitiendo la personalización y actualización de dichos modelos, tanto en el contenido a incluir como en el formato de presentación de los mismos.
• Reflejar los vencimientos de los contratos por fechas y tipos, ó individualmente, así como las prórrogas, las renovaciones, las suspensiones, los períodos de prueba, etc.
• Gestionar adecuadamente la antigüedad (habitualmente Trienios), que se reconocerían de forma automática a partir de la fecha de cómputo de antigüedad, que se introdujera a cada trabajador.
• Calcular automáticamente las pagas extras, atendiendo a las diferencias existentes entre personal funcionario y laboral, según la Orden de confección de nóminas vigente, que establece el pago de las pagas extras, y considerando los casos fuera de convenio; prestando especial atención al cómputo de los meses de alta y de baja del trabajador, que deberá hacerse como meses completos, a excepción de que la baja del trabajador haya sido por renuncia, despido, etc. en cuyo caso no se le computaría el mes completo, sino únicamente los días naturales trabajados.
• Calcular mensualmente los tipos de IRPF de acuerdo a las normas de la Agencia Tributaria.
• Gestionar las retribuciones en especie teniendo en cuenta los ingresos y las retenciones a cuenta correspondientes.
• Gestionar adecuadamente las bajas por enfermedad, común o profesional, la maternidad, las situaciones de bajas por riesgo por embarazo, tanto a nivel retributivo, como a efectos de Seguridad Social (sistema RED), como de gestión, según se indica a continuación:
• A nivel de Seguridad Social (Sistema RED)
• A nivel retributivo estas situaciones no aparecerían en la nómina, ya que se calcularían de forma interna los conceptos necesarios para efectuar la cotización en los seguros sociales.
• A nivel de gestión de partes médicos: el sistema deberá notificar al gestor las fechas en que se deberán ir presentando los partes médicos correspondientes, para ayudar a realizar un control de estas ausencias.
• Realizar la gestión de los anticipos reintegrables (anticipo a cuenta que se devuelve mediante ‘n’ descuentos mensuales). En esta gestión se podrá alterar las condiciones y cuadros de amortización, pudiendo amortizar el anticipo o préstamo en nómina, o fuera de la misma como un pago de caja.
• Facilitar la introducción de conceptos retributivos variables, aplicables durante períodos de tiempos concretos (desde fecha hasta fecha), tanto a nivel individual como masivo, admitiendo que los correspondientes importes sean fijos (aunque diferentes para cada individuo) o bien sean el resultado de un cálculo.
• Disponer de un módulo de gestión de cargas de incidencias externas masivas para poder recoger información del control de presencia, o de otros sistemas que contengan información de incidencias que tengan relevancia a efectos retributivos.
• Resolver y regularizar las incidencias que se produzcan entre el día de pago de la nómina hasta el último día del mes.
• Resolver las incidencias producidas por la llegada de información posterior al cierre de una nómina, tanto dentro como fuera del ejercicio (Incapacidad Permanente, licencias…Modificación o eliminación de información introducida por error)
• Calcular nóminas de Atrasos de Convenio, producidas por acuerdos a finales del ejercicio, con carácter retroactivo.
• Contemplar la realización de distintos tipos de liquidaciones de seguros sociales complementarios entre los que cabe destacar por su importancia para el Ayuntamiento:
• Atrasos de Convenio (L03) y otras liquidaciones complementarias (L09) a todo el personal o bien a un grupo determinado del mismo, realizando las liquidaciones complementarias de los seguros sociales correspondientes.
• Salarios de tramitación (L02): Regularizaciones exigidas por sentencia judicial de los salarios de tramitación que se fijen en cada caso, teniendo en cuenta que habría que reconstruir toda la historia de dicho empleado, pudiendo existir otras contrataciones que se superponen a dicha regularización, pudiéndose tener que reconocer trabajos no realizados previos a la primera contratación.
• Complementarias Negativas (A76): Regularización de las bases de cotización por una cotización excesiva, lo que vendrá unido inseparablemente con una gestión de los reintegros de nómina, lo que llevaría a poder realizar un control de “morosos”, para poder pasar dicha información a los encargados de gestionar su cobro (así como poder conocer esa información a la hora de contratar a un empleado).
• Devolución de prestaciones indebidas (L04): Devolución de las prestaciones por enfermedades que hayan sido descontadas en seguros sociales y que se aplicaron de forma incorrecta.
• Generar finiquitos y liquidaciones, teniendo en cuenta que si se liquidasen vacaciones, se debería realizarse una liquidación complementaría L13 de Liquidación de Vacaciones, según se establece en la legislación vigente.
• Elaborar los ficheros FAN para efectuar la comunicación a la Tesorería General de la Seguridad Social (TGSS) de la cotización, pudiendo así realizar la presentación de documentos de las series TC2, así como la tramitación de saldos acreedores e incluso la domiciliación del pago/cargo en cuenta de las cuotas, si la Tesorería Municipal así lo decidiera.
• Generar los ficheros de transferencias según las normas del AEB, permitiendo la posibilidad de una generar pagos a distintas cuentas bancarias, según el concepto que estemos transfiriendo en cada caso, ya que con ello se resolverían situaciones como los embargos judiciales, las aportaciones al Plan de Pensiones, cuotas sindicales, etc.
• Emitir el modelo 190 así como los modelos mensuales 111, y trimestrales 110 y los correspondientes certificados de retenciones de IRPF. Se deberá poder reimprimir estos certificados, por selección del usuario, para perceptores de ejercicios anteriores. Es preciso tener en cuenta que además de la información de la nómina deberá recoger la información de otros módulos, como puede ser la información del módulo de gestión de pagos a los profesionales.
• Disponer de mecanismos para controlar y gestionar las aportaciones realizadas por el promotor al Plan de Pensiones.
• Disponer de consultas, listados y generación de ficheros con información por de la nómina por conceptos retributivos /meses /nominas /personas., y por deducciones /meses
/nominas /personas, con el nivel de desagregación variable y decidido por el usuario en el momento de la generación.
• Disponer de informes de modificaciones por conceptos, de forma que se puedan identificar fácilmente las unidades de dichos conceptos que se han ido modificando mes a mes.
• Disponer de cierres que impidan la modificación de la información de nomina que se haya dado por definitiva.
• Poder reimprimir toda la documentación de una nómina del Histórico, incluidos los recibos, a petición del usuario.
3.1.3.1 Aplicaciones Presupuestarias. Integración con contabilidad.
Se pretende que la aplicación en cuestión pueda gestionar y contabilizar el presupuesto del Ayuntamiento, en función del régimen económico que tenga cada trabajador.
Las características que se demandan son:
• Clasificar los distintos tipos de personal en la Administración y la de los componentes de las partidas contables (Clasificación orgánica, funcional y económica), de modo que se pueda ordenar el listado de nómina comprensivo del desglose por trabajador, tanto por orden alfabético, como por orden de los componentes de la clasificación por programas.
Dichos listados contendrán, por cada trabajador, el programa presupuestario en el que se halla encuadrado.
• Definir y asignar el empleado a la Clasificación Orgánica y Funcional que le corresponda.
• Definir las distintas partidas tanto presupuestarias como no presupuestarias y establecer las correspondencias entre los conceptos salariales de nómina y la partida económica.
• Tratamiento de excepciones por centro de costo (obras, proyectos) y/o por empleado.
• Tratamiento de excepciones por empleado.
• Confeccionar los ficheros informáticos de intercambio (IDE) de la nómina (A,D,O,P) de cada cuerpo de nómina que se emita en cada mes. El formato del fichero de intercambio figura como XXXXX X.
• Disponer de herramientas de gestión del gasto para la nómina, contrastando el importe efectivamente gastado con el presupuestado. Posteriormente, sería necesario poder simular las situaciones de nómina posibles hasta final de año e ir indicando dónde se podrán producir desviaciones tanto en positivo como en negativo.
• Generar una serie de listados contables por funcional y aplicaciones presupuestarias para poder repasar y cuadrar las distintas partidas presupuestarias, tanto en soporte papel como en fichero informático.
• Parametrización de las partidas presupuestarias al Plan General de Contabilidad Pública establecidos en la ORDEN EHA/3565/2008, de 3 de diciembre.
• Se requerirá la generación de la información contable y procesos para llevar la contabilidad de la nómina. Debe de contar con el aplicativo o proceso que permita de forma automática traspasar los datos necesarios de la aplicación de nómina a la de contabilidad existente en el Ayuntamiento (actualmente, la suministrada por la mercantil Sage-Aytos). El formato del fichero de intercambio figura como XXXXX X.
3.1.3.2 Préstamos y Embargos
El objetivo de esta área es gestionar las distintas retenciones judiciales, admitiendo que pueden existir de diferentes tipos (según los distintos tramos del S.M.I establecidos en ley de Enjuiciamiento Civil: por porcentajes del líquido, cuota fija, etc.) y teniendo en cuenta que pueden coexistir varios embargos al mismo tiempo. El sistema deberá tener en cuenta el importe total a retener, para realizar un control del saldo pendiente de retener de forma automática.
Las características que se deben cumplir en este ámbito son:
• Cálculo de los embargos según tramos S.M.I. con dos sistemas distintos: mediante prorrateo del embargo (cuotas variables) o de forma independiente cada uno de ellos (cuotas fijas), a elección del usuario, y en función xxx xxxxxxx, jornal, retribución o pensión de cada mes.
• Gestionar todo lo relativo a descuentos de retenciones judiciales y anticipos de nómina reintegrables.
• Tratamiento específico para la gestión, control y contabilización de los préstamos concedidos al personal a través de los cuadros de amortización.
• Cálculo de forma automática del importe total a retener, y control del saldo pendiente de retener.
• Pago de transferencias a través de distintas cuentas bancarias del propio trabajador neto o a cuentas bancarias de otras personas o entidades distintas al trabajador estableciendo una cantidad fija por mes o estableciendo un porcentaje sobre el neto.
• Flexibilidad para ajustar los pagos a los requerimientos del empleado.
3.1.3.3 Gestión de Profesionales
El alcance de esta área debe abarcar las siguientes funcionalidades:
• Gestión de los movimientos (emisión de facturas) por parte del personal profesional propio o ajeno al organismo, para completar los datos correspondientes a los procesos de IRPF para residentes y de IRNR para no residentes.
• Posibilidad de entrada de “facturas” de las distintas actividades económicas (profesionales, agrícolas, ganaderas, forestales) o pagos a consejeros.
• Posibilidad de entrada de los pagos realizados fuera de nómina a personal empleado o no en el organismo (cursos, conferencias, seminarios y premios literarios).
• Inclusión de los datos de este apartado en los modelos de IRPF 110/111 y 190 para los Residentes.
• Cálculo, mantenimiento y generación de los modelos 216 y 296 para tratamiento de las retenciones efectuadas a los no residentes.
• Posibilidad de cargar datos de forma masiva que provengan de cualquier aplicación externa (datos de personas y datos de facturas).
3.1.4 Herramientas y Utilidades
La herramienta seleccionada debe ser totalmente modular, escalable y altamente parametrizable en consultas y filtros de selección.
3.1.4.1 Generador de Consultas, Listados e Impresos
El sistema debe presentar un paquete integrado por herramientas destinadas al usuario final cuyo objetivo es la explotación visual de los datos contenidos en la Base de Datos, aspecto que debe proporcionar un sistema altamente parametrizable en la composición y diseño de informes. Estas herramientas deben formar parte integrada del Sistema de Información de RRHH, por lo que no deben existir redundancias ni incoherencias en la información presentada.
Las características solicitadas para estas herramientas son:
• Acceso a todos los campos existentes en la base de datos.
• Utilización de formulas de cálculo en las consultas
• Ordenación ascendente / descendente por cualquier columna
• Definición de rupturas por campo
• Definición de agrupaciones por campo
• Definición de totalizaciones por campo
• Nombre de las columnas definibles por el usuario
• Salida de la consulta en formato lista o tabular
• Resumen a pie de página con el criterio de selección
• Posibilidad de fijar parámetros fijos a la consulta
• Utilidades de duplicar consultas
• Asignación a una consulta de un filtro
• Configurar consultas e informes por usuario de la aplicación
• Vincular datos con procesadores de texto, en formato “Combinar Correspondencia”.
• Descarga de datos en formato ofimático
3.1.4.2 Auditoría de Seguridad
La Agencia de Protección de Datos a través de la Ley Orgánica, Real Decreto 994/1999 sobre los “Modelos de notificación de la Agencia de Protección de Datos”, obliga a todas las aplicaciones a proteger los datos que manipulan en diferente nivel, de menor a mayor seguridad, dependiendo de la naturaleza de los mismos.
Es por ello que el sistema debe incorporar una herramienta de gestión de usuarios y accesos que cumpla con dicha Ley.
Las características de la herramienta de seguridad deben ser:
• Diferenciación entre usuarios administradores del sistema, y usuarios de aplicación.
• Gestión de Usuarios orientada a las personas que accedan a la herramienta (un usuario, una persona).
• Caducidad de contraseñas, y requisitos adicionales a establecer por el Ayuntamiento.
• Bloqueo de usuarios en caso de errores repetidos en el intento de acceder, con la posibilidad de activar / desactivar dicho bloqueo por parte de un administrador de la herramienta.
• Registro de Acciones realizadas por los usuarios (inserción, modificación, eliminación).
• Registro de Lectura de registros por parte de los usuarios, tanto a nivel de informes, como a nivel de pantallas.
• Registro de Acceso de los usuarios a cada una de las áreas de la herramienta.
• Encriptación de las contraseñas de acceso de cada usuario, dentro del sistema.
3.1.4.3 Módulo de Traspaso de Datos
Se valorará la existencia de una herramienta de traspaso de información hacia el nuevo sistema. Así, dicho sistema debe incorporar las siguientes funcionalidades:
• Existencia de un Diccionario de datos, debidamente documentado y actualizado, de forma que el personal de Informática de el Ayuntamiento de Guadalajara tenga acceso al diseño de tablas de la aplicación.
• Mecanismos para alimentar, cada vez que se requiera, desde sistemas externos a opciones concretas de la aplicación, de forma que sea sencillo el activar dichos procesos por parte de los usuarios.
• Documentación orientada a poder construir los ficheros origen para poder alimentar a la aplicación (en este caso destino de la información).
• Debe permitir tanto cargas iniciales de datos, como cargas periódicas.
• Además, debe ser lo suficientemente sencillo y ágil como para que determinadas gestiones de traspaso de información puedan realizarse de forma autónoma.
3.1.4.4 Editor SQL
Se valorará la existencia de una herramienta que permita ejecutar sentencias y scripts SQL directamente conectando a la base de datos, de forma integrada con la aplicación. Este módulo debe ser independiente de las herramientas facilitadas por fabricante de la Base de Datos, y por lo tanto, no será necesario tenerlas instaladas ni utilizarlas, así como tampoco conocer su funcionamiento.
3.2. Requisitos Técnicos del Sistema
3.2.1 Requisitos de integración con otros sistemas
Los mecanismos de integración del sistema deben contemplar el uso de estándares de integración XML, SOAP y HTTP a través de Servicios Web.
Los sistemas con los que debe integrarse el nuevo sistema de información de RRHH, son los siguientes:
• Con la S.S. (RED) aprovechando las funcionalidades ofrecidas vía extranet por la S.S. (RED). Permite cargas masivas de incidencias, generación de Altas/Bajas/Modificaciones…
• Con Hacienda y la Agencia Tributaria
• Entidades bancarias, planes de pensiones, seguros de vida
• Con el sistema DELT@ del Ministerio de Trabajo y Asuntos Sociales
• Sistemas Contrat@ y Certific@ del SEPECAM
• Sistema Financiero Contable SICALWIN xx XXXX-AYTOS
• Sistema de Control de Presencia de AEBIA
3.2.2 Requisitos de Seguridad
3.2.2.1 Requisitos generales
Restricción de utilización del sistema y de acceso a los datos e informaciones a las personas autorizadas mediante mecanismos que permitan la identificación, la autenticación, la gestión de
derechos de acceso y, en su caso, la gestión de privilegios. El responsable del sistema podrá configurar y administrar en cualquier momento los citados mecanismos.
Garantía de la recuperación y disponibilidad del servicio y de la información, realización de copias de salvaguardia, y realización de trazas de las transacciones efectuadas.
Protección del sistema frente a manipulaciones no autorizadas, es decir, la garantía de que la corrección del funcionamiento del sistema no se vea afectada por la actuación de agentes fuera del control de administradores usuarios.
Minimizar los errores de mal uso de la aplicación mediante programación defensiva, pantallas amigables para el usuario, a base de menús verticales flotantes, árbol de ventanas en ‘scroll’, ventanas de ayuda superpuestas, etc.
Mecanismos que garanticen la prevención de la pérdida de datos e informaciones, es decir, garantía de integridad.
3.2.2.2 Seguridad lógica
El acceso al sistema se realizará con la identificación y autenticación del DIRECTORIO ACTIVO. Se valorará la experiencia de integración con herramientas de portafirmas (de cara al uso firma digital y certificados electrónicos).
En detalle, el sistema permitirá:
Crear distintos usuarios de la aplicación (creados previamente en DIRECTORIO ACTIVO) con distintos privilegios de acceso a los datos contenidos, y de realización de acciones sobre dicha información (altas, bajas, modificaciones y consultas, así como dotar distintos accesos a los módulos de aplicación.
Controlar adecuadamente los accesos según la tipología del usuario que se conecte al Sistema y las políticas de seguridad, dotando al Sistema de una Infraestructura adecuada que permita una integración efectiva de los diferentes módulos, así como facilite la visión conjunta de la información.
Los Centros Gestores accederán al sistema y de forma exclusiva podrán gestionar sus propios trabajadores, con independencia del tipo de personal asignado al centro gestor. No les será posible visualizar trabajadores asignados a otros centros gestores. La División de Recursos Humanos podrá gestionar todos los empleados.
Manejar una auditoria extensiva y eficaz controlando tanto las fechas como los usuarios que modifiquen información relevante. Permitir que la auditoria sea parametrizable (activar
/desactivar) por operaciones.
Deben contemplarse todos los aspectos de la legislación en materia de Protección de Datos de Carácter Personal. El módulo de seguridad debe ser totalmente personalizable por el responsable de seguridad, desde el que se podrán controlar los diferentes niveles de acceso.
A los usuarios se les debe poder asignar hasta 4 tipos diferentes de perfiles en función del nivel de seguridad a cumplir (restricción sobre la interfaz gráfica, restricción sobre los registros, restricción sobre las operaciones a efectuar en los registros y restricciones sobre los listados.
Restricciones gráficas: deben permitir restringir los objetos de la interfaz de la aplicación. Los objetos (pantallas, campos, opciones de menú, listados,...) se podrán ocultar o inhabilitar.
Restricciones sobre las operaciones: permitirán controlar las operaciones sobre los registros (alta, baja, modificación, eliminación).
Restricciones sobre los listados: para cada usuario de aplicación se deberá poder especificar qué listados puede generar y cuáles no.
El usuario administrador podrá administrar los diferentes perfiles de restricciones. El administrador podrá definir el periodo de vigencia de un usuario de aplicación.
Se podrá definir el número de intentos erróneos después de los que se bloqueará el usuario en la aplicación.
El administrador podrá reactivar usuarios bloqueados en la aplicación.
3.2.3 Entorno Tecnológico
3.2.3.1 Arquitectura global del Sistema
El entorno actual. La aplicación debe estar desarrollada al menos para entornos Microsoft Windows, con una única base de datos en un sistema Gestor de Base de Datos Relacional. Módulos Cliente/Servidor
• Arquitectura cliente/servidor de 3 capas (acceso a datos, lógica aplicación e interfaz gráfica)
• Capa de negocio de la aplicación disponible en biblioteca de Servicios Web.
• Interfaz con menús de persiana, pantallas de datos estructuradas por pestañas, opciones claras para el usuario y de acceso rápido, etc.
• Publicación de los componentes y objetos de lógica de la aplicación mediante Web Service Seguros (WSS) accesibles desde cualquier herramienta de terceros que suporte esta tecnología, para ejecutar funcionalidades internas de la aplicación
3.2.3.2 Módulos Web
• Arquitectura web.
• Apariencia 100% Web, utilizando páginas HTML, DHTML, Hojas de estilo (CSS) y JavaScript.
• Capa de negocio de la aplicación disponible en biblioteca de Servicios Web.
• Posibilidad de modificar el formato y colores de las pantallas Web, mediante hojas de estilo (CSS) y directivas de formato.
• Posibilidad de integración con intranets.
• Autenticación mediante Directorio Activo.
3.2.3.3 Plataforma Servidor BBDD
• La aplicación debe ser operativa al menos en Oracle 10 y 11, tanto de 32 como de 64 bits.
3.2.3.4 Plataforma Servidor WEB
• Sistema Operativo Windows Server.
3.2.3.5 Plataforma cliente
• Los clientes podrán ser Windows XP o Windows 7, tanto sus versiones de 32 bits como de 64 bits.
• Deberá permitir la ejecución en entorno Terminal Server 2003 y 2008 y Citrix.
3.2.3.6 Otras consideraciones
• Entorno Gráfico en los equipos clientes del sistema.
• Total integración con las herramientas ofimáticas de Microsoft, OpenOffice y LibreOffice .
• Mediante las herramientas anteriores el usuario debe poder generar cualquier documento que muestre la información de la base de datos a través de un generador de impresos o de alguna otra herramienta de la aplicación de una forma fácil e intuitiva para el usuario.
• Todos los listados de la aplicación desde la pantalla de previsualización se deberán poder exportar a formato .odt, .xls, .doc, .html y .PDF. En ninguno de los casos dicha exportación deberá suponer la adquisición por parte del Ayuntamiento de herramientas de terceros.
• Posibilidad de Integración con sistemas de correo electrónico. El servidor actual es Lotus Domino.
Dentro del proyecto objeto del concurso está incluido, a cargo del proveedor, los siguientes servicios:
• Estudio, consultoría, implantación, configuración, parametrización y pruebas de validación y funcionamiento de todas las aplicaciones integrantes del sistema.
• Configuración y adaptación del software de gestión de las bases de datos
• Programa de formación para los diferentes perfiles.
• Migración de los datos desde la aplicación actual (UNIT4, antes SPAI).
En definitiva, todo el proyecto debe incluir todos los servicios y el apoyo necesario para que el resultado final sea la correcta operatividad de la implantación objeto del concurso.
• Migración: El nuevo sistema debe incorporar, mediante los procedimientos correspondientes, los datos existentes la aplicación de nóminas actual. Inicialmente esta migración deberá incluir todos los aspectos relativos a la nómina, necesarios para su arranque y puesta en funcionamiento. El adjudicatario realizará las tareas de análisis, asesoramiento en el alcance del traspaso, así como el soporte necesario para la resolución de dudas durante la generación de los ficheros de extracción y migración necesarios, para cargar en el nuevo sistema. La extracción de la información desde los sistemas anteriores y la generación de los ficheros adecuados al formato establecido y requerido por la nueva aplicación, se realizará con la colaboración del personal técnico del Organismo. Las empresas concurrentes al proceso deberán aportar en sus ofertas los trabajos y las herramientas necesarias, la forma de llevar a cabo el trabajo y el plazo estimado para el operación
• Formación: Las empresas que se presenten al concurso deberán determinar en sus propuestas las actividades de formación sobre la utilización de los recursos ofertados. El plan de formación deberá comprender todos los aspectos del proyecto, en función de los perfiles de gestores y usuarios de la aplicación. La formación deberá hacerse en la sede del Ayuntamiento.
• Implantación: El proceso de implantación de la aplicación se llevará a cabo de manera coordinada, ateniéndose a criterios de parametrización y al establecimiento de las funcionalidades, de conformidad con las especificaciones del personal técnico del Ayuntamiento. Sobre las fases del proceso de implantación, las empresas deberán presentar un plan detallado con indicación de recursos humanos, jornadas de trabajo y materiales que el proveedor destinará al proyecto.
4. DOCUMENTACIÓN
Como parte de los trabajos objeto del contrato, el adjudicatario se compromete entregar toda la documentación pertinente relativa al Sistema Contratado, así como el modelo de datos del mismo.
Toda la documentación se entregará en español, en formato digital, que se instalará en la ubicación designada por el Ayuntamiento de Guadalajara a tal efecto, para facilitar el tratamiento y reproducción de los mismos.
Durante el período de garantía, el adjudicatario deberá suministrar al Ayuntamiento de Guadalajara las nuevas versiones de la documentación que se vayan produciendo.
5. PLANIFICACIÓN Y FASES
El licitador deberá aportar una planificación detallada que permita observar la realización de las actividades a desarrollar a lo largo de la vida del proyecto.
Además, la oferta deberá incluir una propuesta de calendario del proyecto hasta la finalización del mismo, destacando los hitos necesarios para determinar su correcta evolución.
El alcance previsto para le realización de los trabajos objeto de esta contratación es de cinco
(5) meses. El plazo de ejecución se iniciará el día siguiente al de la notificación de la adjudicación definitiva. Si el licitador presenta una mejora en el plazo, ése será el que se tomará como máximo.
6. EQUIPO DE TRABAJO
El Ayuntamiento de Guadalajara, por su parte, deberá asegurar la colaboración de Técnicos, responsables en las distintas fases del proyecto.
El Ayuntamiento de Guadalajara designará un Director de proyecto con capacidad suficiente para realizar labores de dirección, seguimiento y coordinación, el cual podrá incorporar al proyecto durante su realización, a las personas que estime necesarias para verificar y evaluar todas las actuaciones.
Los técnicos de el Ayuntamiento de Guadalajara podrán solicitar informes resumen de situación cada vez que lo consideren oportuno, que les permitan disponer de un conocimiento permanentemente actualizado del desarrollo de los trabajos.
Tras las revisiones técnicas, el Director de proyecto podrá rechazar en todo o en parte los trabajos realizados, en la medida en que no respondan a lo especificado o no superen los controles de calidad acordados.
Las empresas interesadas en la adjudicación del servicio presentarán en su propuesta la descripción de su equipo de trabajo, especificando los recursos humanos que destinarán al proyecto, sus perfiles profesionales, y las dedicaciones por cada una de sus categorías:
• Número de personas dedicadas al proyecto por cada categoría profesional.
• Número de horas por categoría que se ofertan para la realización de los trabajos.
Con el objeto de supervisar los trabajos, existirá un Jefe de Proyecto por parte de la empresa adjudicataria, representante de la misma e interlocutor y responsable de los trabajos ante el Ayuntamiento de Guadalajara.
El adjudicatario deberá:
• Informar al Ayuntamiento de Guadalajara de la marcha de los trabajos encomendados.
• Corregir o modificar los distintos trabajos realizados si no fueran de conformidad del Director de proyecto por parte del Ayuntamiento de Guadalajara en base a los criterios técnicos que rigen el presente pliego.
7. PRECIO DE LICITACIÓN
El importe máximo de licitación para la realización de los trabajos incluidos en el presente pliego de prescripciones técnicas asciende a 59.300,00 EUROS más 10.674,00 EUROS en concepto de IVA.
En este importe van incluidos todos los gastos derivados del objeto del presente concurso, es decir, software de soporte, trabajos de análisis y configuración del sistema, documentación, formación, garantía y servicio de soporte de atención al cliente durante al menos un año, gastos de personal, etc.
Se deberá indicar el precio del servicio de mantenimiento anual para su posible realización a partir del periodo de garantía. Este servicio incluirá mantenimiento y servicio de soporte de atención al cliente de todas las aplicaciones instaladas. La contratación de este servicio es discrecional para el ayuntamiento de Guadalajara. En el caso de que decida su contratación, esto lo será por un periodo máximo de cuatro años, por el precio anual ofertado por el
adjudicatario, que se actualizará anualmente con el IPC. El importe máximo anual de este servicio de mantenimiento será de 7.100 EUROS más 1.278,00 EUROS en concepto de IVA
8. PLAZO DE EJECUCIÓN
La finalización del proyecto será como máximo el 30/11/2011.
9. GARANTÍA, MANTENIMIENTO Y SERVICIO DE SOPORTE DE ATENCIÓN AL CLIENTE
El adjudicatario deberá garantizar por un año los productos derivados de la presente contratación, obligándose a realizar durante dicho período los cambios necesarios para solventar las deficiencias detectadas imputables a la firma adjudicataria si así lo solicita el centro directivo, sin coste adicional para el organismo
Dicha garantía incluirá la subsanación de errores o fallos ocultos que se pongan de manifiesto en el funcionamiento de las aplicaciones, o que se descubran mediante pruebas o cualesquiera otros medios, así como la conclusión de la documentación incompleta y subsanación de la que contenga deficiencias. Los productos originados como consecuencia de la subsanación de fallos deberán entregarse de conformidad con lo exigido en este pliego
Durante el periodo de 1 año, a partir de la fecha de recepción, el adjudicatario estará obligado a realizar las modificaciones que se produzcan como consecuencia de cambios legislativos, sin que esto suponga coste adicional para el organismo.
La empresa adjudicataria está obligada a presentar un Plan de Mantenimiento, que entrará en vigor una vez haya finalizado el periodo de garantía, incluyendo la descripción y valoración del servicio en sus distintas modalidades (mantenimiento preventivo, correctivo, incorporación de mejoras y nuevas funcionalidades, así como el soporte a la explotación del sistema).
El servicio de mantenimiento durante el periodo de garantía quedará incluido en el objeto del contrato y dentro del precio pactado.
10. TRANSFERENCIA TECNOLÓGICA
Durante la ejecución de los trabajos objeto del contrato, el adjudicatario se compromete a facilitar, a la persona designada por el Ayuntamiento de Guadalajara a tales efectos, la información y documentación que ésta solicite para disponer de un pleno conocimiento de las circunstancias en que se desarrollan los trabajos, así como de los problemas que puedan plantearse y de las tecnologías, métodos y herramientas utilizados para resolverlos.
Toda la documentación se entregará en soporte digital para facilitar el tratamiento y reproducción de los mismos.
El adjudicatario deberá proporcionar al personal designado, las nuevas versiones de la documentación que se vayan produciendo.
11. PROPIEDAD INTELECTUTAL Y CONFIDENCIALIDAD
11.1. Propiedad Intelectual
El contratista consignará en la oferta la propiedad intelectual del software y las condiciones de la cesión de licencia de uso al Ayuntamiento de Guadalajara.
En cualquier caso, el adjudicatario se comprometerá a realizar un depósito notarial de los fuentes de la aplicación suministrada al Ayuntamiento de Guadalajara, cuyos gastos correrán por cuenta del adjudicatario.
11.2. Confidencialidad
El adjudicatario queda expresamente obligado a mantener absoluta confidencialidad y reserva sobre cualquier dato que pudiera conocer con ocasión del cumplimiento del contrato,
especialmente los de carácter personal, que no podrá copiar o utilizar con fin distinto al que figura en este pliego, ni tampoco ceder a terceros ni siquiera a efectos de conservación.
La empresa adjudicataria será responsable de daños y perjuicios que se deriven del incumplimiento de esta obligación.
El adjudicatario quedará obligado al cumplimiento de lo dispuesto en la Ley orgánica 15/1999 de 13 de Diciembre, de protección de datos de carácter personal.
12. PRESENTACIÓN DE PROPOSICIONES Y ESTRUCTURA DE LA OFERTA
Con independencia de que las empresas interesadas puedan adjuntar a su oferta cuanta información complementaria considere de interés, la propuesta técnica deberá estar estructurada de la siguiente forma:
1. Índice
2. Introducción
3. Objetivos y alcance del proyecto:
• Se incorporarán los aspectos más significativos y relevantes de la solución ofertada.
• Se deberá incluir una memoria descriptiva detallada de la solución propuesta para satisfacer los requisitos técnicos del contrato.
4. Mejoras que aporte la propuesta: El adjudicatario podrá incluir en su oferta cuantas prestaciones adicionales considere oportunas, siempre referidas al objeto del presente pliego, valoradas económicamente.
5. Metodología de proyecto
6. Plan de trabajo
• Los plazos de ejecución de las distintas actividades (Diagrama xx Xxxxx)
• Equipo de trabajo
• Plan de formación tanto del personal técnico como de los usuarios tramitadores que utilicen el sistema.
7. Documentación técnica.
• Requisitos mínimos en cuanto a servidores, puestos de trabajo, comunicaciones, etc.
• Aspectos tecnológicos de la implantación.
• Plan de implementación del proyecto.
• Condiciones del mantenimiento, garantía y servicio de soporte de atención al cliente.
• Documentación de la aplicación: manuales de usuario y documentación técnica informática.
• Documentación referente a la estructura de la base de datos, tablas y relaciones existentes entre ellas (modelo de datos).
8. Plan de mantenimiento (mantenimiento preventivo, correctivo, incorporación de mejoras y nuevas funcionalidades, así como el apoyo a la explotación del sistema).
GUADALAJARA, 22 xx xxxxx de 2010
LA JEFA DE SECCIÓN DE PERSONAL LA JEFA DE SECCIÓN DE PERSONAL
Xxxxxxxx Xxxxxx Xxxx Xxx Xxxxxxxx Xxxxxxx
EL JEFE DE SISTEMAS
Xxxxxxxxx-Xxxxxx Xxxxxx Xxxxxx
ANEXO I
ESTRUCTURA DEL FICHERO SECUENCIAL DE NÓMINAS
Concepto | Inicio | Longitud | Tipo |
Tercero | 1 | 12 | Texto |
Tipo Concepto | 13 | 1 | Texto |
Proyecto | 14 | 18 | Texto |
Partida | 32 | 21 | Texto |
Importe | 53 | 8 | Numérico |
Grupo Apuntes | 61 | 6 | Texto |
Operación Cancelada Número | 67 | 12 | Numérico |
Operación Cancelada Línea | 79 | 3 | Numérico |
Operación Cancelada Tipo | 82 | 1 | Texto |
Base IRPF | 83 | 12 | Numérico |
Porcentaje IRPF | 95 | 6 | Numérico (dos últimos decimales) |
Código Territorial | 101 | 8 | Texto |
Plan Actuación Municipal | 109 | 5 | Texto |
Centro de Coste | 114 | 6 | Texto |
Grupo Apuntes (superiores a 6 caracteres) | 120 | 15 | Texto |
Gasta de Remanentes (S/N) | 135 | 1 | Texto |
EXPLICACIONES DE CONCEPTOS
Tercero. Es el NIF xxx Xxxxxxx perceptor de la nómina. El sistema permite generar registros por cada trabajador, pero si se hace así, en Sicalwin deben estar dados de alta todos los trabajadores. Esto no quiere decir que la operación contable se vaya a hacer individualmente. Se hará una sola obligación por “Grupo de apuntes” (ver más adelante), pero en las tablas internas de la contabilidad estará el detalle original de lo percibido por cada persona. Si los datos ya se van a enviar agrupados, puede venir siempre el mismo tercero ficticio (Tesorería, Personal, … puede ser un NIF ficticio, pero que exista en contabilidad)
Tipo de Concepto:
D-Devengos, R-Retenciones, T-Reintegro, P-Propuestas
X. Xxxxxxxx. Imputación a la aplicación de gastos que corresponda.
R. Retenciones. Son las retenciones a IRPF, Seguridad Social, u otras. Se debe indicar el concepto no presupuestario. También podría ser retención a concepto de ingresos (por ejemplo en anticipos al personal que se hayan pagado por presupuesto)
T. Reintegros. Son reintegros en aplicaciones de gastos. En lugar de un gasto se genera un reintegro (cobro) en la aplicación presupuestaria.
P. Propuestas. Son propuestas de mandamientos de pago no presupuestarias, por si se desea realizar un pago no presupuestario en lugar de presupuestario. En lugar de una partida de gastos, deberá venir en la línea un concepto no presupuestario.
Proyecto:
Ejercicio(4) + Tipo(1) + Órgano(7) + Numero(3) + Expediente (3)
Es el código de proyecto de gasto o gasto con financiación afectada, en su caso. Puede venir a blancos.
Partida:
1. Si es un devengo (D) o es un reintegro de pagos (T) la partida es de Gastos: Ejercicio+Orgánica+Funcional+Económica) Ejercicio: 4, Orgánica: 5 ; Funcional/Programa: 5 ; Económica: 7. Cada apartado se debe completar a blancos si el tamaño es menor, La clasificación funcional a partir del ejercicio 2010 pasa a denominarse “programa”.
Por ejemplo, para una xxxxxxx xxx xxxxxxxxx 0000 con orgánica “10”, programa “920” y económica “12000”, el registro sería: “201010 920 12000 “.
2. Si es una retención (R )la partida pude ser:
a. Ingresos (poner un 1+Orgánica (5) + Económica (5)+Blancos)
b. No presupuestaria (poner un 3+Orgánica (5)+Económica (5)+Blancos)
La orgánica y la económica si tienen un tamaño menor a 5, completar a blancos.
3. Para Propuestas (P): 3+Orgánica+Económica+Blancos
Grupo de Apuntes:
Se generarán tantas operaciones, como grupos de apuntes distintos haya.
Excepto los Reintegros que se harán tantos como líneas haya en el secuencial.
Puede definirse un solo grupo de apuntes, llamado “NOMINA”, por ejemplo, o crear distintos grupos según los trabajadores (FUNC,LABOR,….). Este campo es alternativo al “Grupo de apuntes suplementario”. No se deben utilizar los dos. Se utilizará este grupo si es suficiente con 6 caracteres, y el suplementario si se necesitan más (hasta 15). Este último se añadió en versiones recientes por peticiones de usuarios, pero si se utiliza el primero, puede venir vacío el segundo.
Operación Cancelada Número:
Cuando las retenciones son de ingresos presupuestarios y cancelan a derechos reconocidos, en este campo viene el número del derecho.
Cuando las retenciones son de ingresos no presupuestarios y cancelan a un pago no presupuestario que el concepto va controlado por operaciones, aquí vendrá el número del pago no presupuestario (por ejemplo anticipos al personal pagados por no presupuestario)
Cuando son líneas de reintegros nos indica el pago a reintegrar.
Cuando se trata de propuestas, que van a una partida de naturaleza acreedora, y controladas por operación, será necesario indicar el ingreso que se cancela.
Operación Cancelada Línea:
Cuando las retenciones son de ingresos presupuestarios y cancelan a derechos reconocidos, en este campo viene la línea del derecho.(Monoaplicación, Multiaplicación). Si las operaciones son monoaplicación, este valor será siempre “1”.
Cuando las retenciones son de ingresos no presupuestarios y cancelan a un pago no presupuestario que el concepto va controlado por operaciones, aquí vendrá el número de la línea del pago no presupuestario. (Monoaplicación, Multiaplicación). Si las operaciones son monoaplicación, este valor será siempre “1”.
Cuando son líneas de reintegros nos indica la línea del pago a reintegrar (“1” si es monoaplicación)
Para las propuestas que cancelan ingresos, se le indicará el numero de linea del mismo (“1” para monoaplicación)
Operación Cancelada Tipo:
Cuando las retenciones son de ingresos presupuestarios va en blanco.
Cuando las retenciones son de ingresos no presupuestarios y cancelan a un pago no presupuestario que el concepto va controlado por operaciones, aquí vendrá el tipo de operación a cancelar. (1 = Indica que la operación es un pago no presupuestario que no proviene de IVA, Será el valor normal para las operaciones que vienen de nóminas.
2 = Si la operación fue consecuencia de la contabilización de otra operación con IVA, desde el Presupuesto de Gastos, Ingresos,
3 = Si es un descuento No Presupuestario generado en una operación Presupuestaria, o incluso No Presupuestaria)