Contract
PLIEGO DE PRESCRIPCIONES TÉCNICAS OBLIGATORIAS QUE RIGE LA CONTRATACIÓN DEL SUMINISTRO DE UNA APLICACIÓN DE DIGITALIZACIÓN DE LOS TICKETS DE LA SOCIEDAD MERCANTIL CORPORACIÓ XXXXXXXX XX XXXXXXX AUDIOVISUALS, S.A.
-PROCEDIMIENTO ABIERTO-
Expediente número: 2207OB04
1. ESCENARIO PARTICULAR DE LA CCMA, SA
La Corporació Xxxxxxxx xx Xxxxxxx Audiovisuals (en adelante, CCMA, SA) es el ente público que gestiona los medios de comunicación audiovisual de la Generalidad de Cataluña, los canales de Televisió de Catalunya y el grupo de emisoras de Catalunya Ràdio, además de los contenidos digitales generados por estos medios.
Actualmente, la CCMA, SA está inmersa en un proceso de transformación digital cuyo objetivo es evolucionar el modelo operativo, entre otros a partir de la mejora de los procesos y la incorporación de nuevas metodologías de trabajo. Y, por otra parte, desde Administración se desea limitar las solicitudes de dinero en efectivo, por motivos de seguridad, para disminuir el consumo de recursos humanos y económicos, para eliminar el papel, y porque a raíz de la pandemia se ha acentuado una migración general de las personas a los medios de pago digitales. Como consecuencia, la CCMA, SA ha decidido implantar una herramienta para la gestión de gastos de personal, optando por un sistema multiplataforma que permita la automatización de captura de tickets con OCR. De este modo, el proceso se optimizará, habrá un claro ahorro de tiempo, y los usuarios notarán una clara mejora de su experiencia en cuanto a ubicuidad, movilidad, conectividad e inmediatez a la hora de hacer y gestionar una liquidación. Todo ello, por supuesto, mientras se sigue manteniendo un control del gasto acorde a normativa.
1.1. Objeto del contrato
El objeto del contrato es la implementación en la CMASA de un servicio de gestión de gastos, que, a través de diferentes funcionalidades de control y seguimiento, permita automatizar parte del actual proceso de gestión de gastos de los empleados de la organización y, en especial, mejorar y automatizar la introducción de las notas de gasto por parte de los usuarios.
El servicio debe ser del tipo SaaS y debe ser capaz, mediante una APP móvil o una aplicación web alternativa, de obtener soporte digitalizado de los comprobantes de los gastos (facturas o facturas simplificadas), garantizando su validez y homologación de la copia digital frente a la Agencia Estatal de Administración Tributaria (AEAT).
El servicio debe estar completamente integrado con el ERP de la CCMA, SA, que es un software desarrollado a medida por el departamento de desarrollo de informática de gestión de la CCMA, SA. El servicio deberá tener la capacidad de extraer de las facturas simplificadas y facturas la información requerida por el suministro inmediato de información del IVA (SII) de la AEAT. También se tendrán que poder introducir gastos de kilometraje.
1.2. Situación actual, histórico de liquidaciones y encaje de la nueva herramienta
La CCMA, SA dispone de un Enterprise Resource Planning o sistema de planificación de los recursos empresariales, en adelante ERP, y de un sistema de autorizaciones internas/firmas de desarrollo propio. Actualmente existen varios circuitos de liquidaciones, y se desea utilizar la App sólo para dos de estos:
• Liquidaciones sin entrega monetaria previa: el trabajador adelanta dinero de su bolsillo y después realiza una liquidación que, una vez autorizada, implica una transferencia bancaria a su favor.
• Tarjetas de crédito corporativas: el trabajador hace el gasto con la VISA corporativa y en la App digitaliza el ticket y concilia el movimiento (el fichero de movimientos proviene a diario del banco) con el ticket digitalizado.
En general, diferenciaremos dos tipos de notas de gasto o liquidaciones:
• Los estándares (la gran mayoría): gastos relacionados con viajes, desplazamientos, etc. Se deben poder completar desde la app externa. En el ERP se establecerá un circuito casi automático en el que una vez autorizado el gasto casi no será necesario hacer nada más
• Otras más especiales/específicas, esto es, conceptos que no son los típicos. El procedimiento es igual que el anterior, con la diferencia de que el usuario deberá seleccionar el artículo “Artículo no estándar (multas, tributos, etc.)” en la app. En este caso, la nota de gasto quedará en un estado inicial pendiente de completar y confirmar en nuestro ERP. A priori, éste sólo deberíamos mantener en SAWI las liquidaciones de caja para cosas especiales (por ejemplo, tributos, aduanas, etc.).
La intención es que el usuario de la CCMA, SA utilice por defecto la aplicación para introducir las liquidaciones de gastos asociadas a tickets, facturas o kilometrajes, y más adelante seguramente también dietas. Y también la intención es que las notas de gasto se hagan a medida que se generan los gastos y no tanto que los usuarios esperen a realizar notas de gasto a final de mes, aunque esto quedará a discreción de cada usuario.
2. ORIENTACIÓN DEL PROYECTO
En cuanto a escenario del proyecto, es importante observar que sólo licitaremos por el momento la herramienta de digitalización de tickets. A efectos prácticos esto significa que:
• No será necesario licitar servicio de tarjetas VISA, ya que tenemos acuerdo con CaixaBank
• No se incluyen en la licitación los siguientes dos temas complementarios que, en su caso, se dejan para más adelante: la recuperación IVA y también el posible módulo de gestión de viajes.
Por otra parte, la solución ajena para la gestión de gastos deberá poder integrarse con el ecosistema de la CCMA, SA a distintos niveles. Podemos resumir esta integración en los siguientes aspectos:
• Integración de la app con nuestro ERP, que es de desarrollo propio y llamamos SAWI: en líneas generales, la nota de gasto se digitalizará desde la app móvil o la MFP, y se completará desde la misma app móvil o la app web. El circuito de autorizaciones se gestionará sin embargo desde nuestro ERP.
• Habrá que hacer una integración para delegar la autenticación de los usuarios hacia el proveedor de identidades de la CCMA.
• Habrá que crear las pasarelas de información para que la app reciba los movimientos diarios de las tarjetas VISA corporativas. La aplicación facilitará la conciliación automática de los movimientos con las notas de gasto.
3.OPERATIVA DE USUARIO Y REQUERIMIENTOS DE LA APP
El usuario deberá instalar la app en el móvil, y la primera vez que se conecte se le pedirá un login y password. El usuario deberá introducir las credenciales corporativas, y la app se sincronizará con los sistemas de la CCMA, SA y hará un login en la app en caso de que éstas sean correctas. Es decir, la app debe delegar la autenticación contra proveedor de identidades de la CCMA, SA. Esta autenticación es algo que la app hará siempre, pero que resultará transparente para el usuario en caso de que el usuario siga dado de alta en el directorio activo de la CCMA, SA y no haya cambiado la contraseña corporativa desde la última conexión; de lo contrario, aparecerá de nuevo la pantalla para introducir identificador de usuario y contraseña.
Una vez el usuario haya iniciado sesión en la app, podrá realizar entre otras, las siguientes funcionalidades:
1. Introducir una nota de gasto (liquidación):
a. Una nota o informe de gasto - lo que en nuestro ERP identificamos como "liquidación"- contempla uno o varios tickets agrupados por usuario.
Una nota de gasto sólo puede estar asociada a un centro de coste (ya que de ello depende el posterior circuito de autorizaciones) y a un único tipo de pago (VISA corporativa o liquidación sin entrega monetaria previa).
La app no permitirá mezclar gastos con comprobante (factura completa, factura simplificada o ticket) con gastos de dietas y/o kilometraje en una misma nota de gasto (ya que el ERP abona los conceptos al trabajador de forma diferente).
b. El usuario deberá identificar obligatoriamente cuál es el centro de coste de la nota de gasto
c. El usuario deberá identificar el artículo (tipo de gasto) de cada gasto incluido en la nota de gasto.
d. El usuario tendrá que identificar la moneda de cada gasto. Puede haber gastos de diferentes monedas en una misma nota de gasto.
e. El usuario deberá identificar el tipo de documento de cada gasto: factura completa, factura simplificada, ticket o sin ticket (ticket extraviado o no obtenido en origen).
f. El usuario deberá escribir una descripción complementaria con información adicional sobre el gasto (en caso de gastos sin ticket y de gastos especiales/específicos es obligatorio).
g. Gastos con ticket:
i. El usuario deberá tomar la foto del ticket, excepto en los casos donde se ha perdido el ticket. La app identificará automáticamente los campos Importe, Razón fiscal, Fecha, Número de documento y CIF, y cualquier otro que sea de obligatorio cumplimiento enviar al SII.
ii. El usuario validará que estos campos detectados automáticamente son correctos.
iii. Los gastos que deberían tener ticket pero el usuario no dispone del mismo porque lo ha perdido o porque no lo ha obtenido de origen (por ejemplo, la máquina del peaje estaba estropeada y no ha salido ticket), en
este caso el usuario deberá marcar en algún campo que no se dispone de ticket. El usuario podrá añadir la foto del ticket a posteriori y, en caso de que finalmente decida enviar la nota de gasto a autorizar sin el ticket, será necesario que el gasto sin ticket tenga informada la descripción complementaria (ya que aquí el usuario escribirá la justificación del ticket no disponible).
h. Otros gastos sin ticket también se podrán agregar como gasto a pesar de no tener ticket asociado (visto más adelante):
i. Kilometraje
ii. Dietas (más adelante, cuando se añada la funcionalidad)
2. Actualizar una nota de gasto que ha sido rechazada desde el ERP y ha vuelto al estado inicial.
3. Consultar el estado de las notas de xxxxx que ha enviado a autorizar
4. Consultar el histórico de notas de xxxxx (al menos desde la versión web).
5. Validar la conciliación automática que se ha hecho con los movimientos de las tarjetas VISA y realizar la conciliación manual para aquellos casos en los que la app no es capaz de hacer una conciliación semiautomática.
Por otra parte, la App debe contemplar la delegación. La delegación será posible siempre que el/la usuario/a de la CCMA, SA esté habilitado en el ERP (SAWI) para poder hacer una nota de gasto en nombre de otro/a usuario/a. En este caso, no debe ser necesario cerrar la sesión para introducir tickets de otro. Por otra parte, no será necesario que la persona en nombre de quien se ha hecho la nota de gasto dé el OK para que la misma prospere, ya que esto se gestionará desde el sistema de la CCMA, SA. Desde la multifunción se debe poder escanear tickets que después se utilizarán para realizar una nota de gasto de otro usuario (siempre que la persona esté delegada).
A la hora de introducir información sobre el gasto desde la App móvil o App web, los usuarios deben poder interaccionar de forma intuitiva con la App y encontrar fácilmente el artículo y el código analítico cuando hacen una nota de gasto:
• Artículos:
o Puede ser un selector.
o Se debe poder realizar una búsqueda por código o por el texto de la descripción.
• Centros de coste:
o El usuario debe poder preseleccionar entre:
▪ Códigos analíticos estructurales: hablamos de unos 550 centros de coste (en este caso debe enseñar por defecto el centro de coste de la unidad del trabajador)
▪ Códigos de programas (dosieres). Hablamos de unos 1.800 centros de coste.
▪ Favoritos y/o últimos códigos analíticos utilizados.
o La aplicación debe permitir filtrar y buscar por el código analítico o por el texto de su descripción. El filtro por texto dará resultados que contengan la cadena, no sólo aquellos que empiecen por el texto indicado (hablamos de un comportamiento similar al que hace el operador LIKE del lenguaje SQL). Es OK que se den resultados a partir de cierto número de caracteres (3, 4 o 5 caracteres). La función autocompletar no es obligatoria, pero se ve como una función que facilita la tarea al usuario.
Una vez el usuario dé por buena la nota de gasto, podrá enviarlo a autorizar a nuestro ERP, ya que es éste quien gestionará el circuito de autorizaciones.
Aparte de los requerimientos ya comentados, la App debe cumplir con los siguientes otros requerimientos:
• La App móvil debe ser compatible con los sistemas operativos IOS y Android.
• Aparte de la versión móvil, el servicio de introducción y gestión de notas de gasto también será accesible desde una página web, que debe ser completamente funcional con los principales navegadores web y, más concretamente, Chrome, Edge, Firefox, Internet Explorer y Safari.
• La versión móvil y web de la App deben estar disponibles en el idioma catalán.
• La App debe permitir la entrada de facturas multi-IVA
• La descarga de esta App debe ser gratuita y no debe tener ningún coste para los usuarios de la empresa.
3.1. MFP, impresoras multifunción
La CCMA, SA dispone de un parque de 104 impresoras multifunción marca CANON modelo imageRUNNER ADVANCE DX (C5840i) desplegadas por las distintas instalaciones.
Se requerirá que la App disponga de un conector con estas MFP en un plazo máximo de 5 meses desde la adjudicación definitiva del contrato. El adjudicatario será penalizado económicamente en las siguientes circunstancias:
Si pasados 5 meses desde el día del inicio de vigencia del contrato el adjudicatario no dispone todavía de un conector con las impresoras multifunción Canon antes mencionadas, o si durante la vigencia del contrato hay algún cambio respecto a este punto App deja de ser compatible con las MFPs operativas en las instalaciones de la CCMA1, SA, la CCMA, SA penalizará la siguiente factura mensual con un 25 % del total de la facturación, y mantendrá dicha penalización mientras el adjudicatario no ponga a disposición del contrato la compatibilidad con las impresoras multifunción. En el tercer mes contado de incumplimiento la CCMA, SA estará facultada para resolver el contrato sin que el adjudicatario tenga derecho a ningún tipo de indemnización.
En caso de que sea necesario hacer un desarrollo del conector, los costes de este desarrollo propio no podrán ser repercutidos directamente sobre la CCMA, SA. Por el contrario, los gastos de puesta en marcha e instalación de los conectores en las MFP sí que serán asumidos por la CCMA, SA.
En caso de que se utilice la MFP para la digitalización, el usuario escaneará tickets en la MFP y después completará la nota de gasto a la versión de backoffice accesible vía navegador web.
Los usuarios de la CCMA, SA se autentifican en las MFPs utilizando la tarjeta corporativa o introduciendo usuario y contraseña en caso de que no dispongan de la misma. Una vez se ha identificado correctamente, el usuario ya podrá hacer uso directamente del conector de tickets, sin tener que identificarse otra vez.
Asimismo, se debe poder escanear tickets para realizar notas de gasto en nombre de otro para poder hacer una nota de gasto en nombre del otro usuario que generó el gasto. En ningún caso se requerirá que el usuario delegado deba autenticarse.
1En la renovación de la licitación de las MFPs, se exigirá a los licitadores compatibilidad con la App que haya ganado la presente licitación.
El licitador deberá poner a disposición de la CCMA, SA la funcionalidad del escaneo de multi- tickets desde la MFP una vez ésta esté disponible; a título orientativo, se estima que esta funcionalidad debería estar disponible en un máximo de 12 meses desde la adjudicación definitiva del contrato.
3.2 Dietas
Para la fase inicial del proyecto no se prevé utilizar la App para que el usuario introduzca dietas. Sin embargo, sí se prevé incorporar esta funcionalidad una vez el uso de la App sea más generalizado (en este caso se utilizará la partida de adaptaciones tecnológicas u organizativas para costear el gasto asociado a poner en marcha esta nueva funcionalidad).
3.3. Kilometraje
Los kilometrajes son gastos que también se deben poder introducir desde la App a pesar de no tener tickets asociados.
Todos los movimientos deben tener una descripción complementaria para que el usuario proporcione información sobre el desplazamiento.
Los usuarios podrán introducir un kilometraje desde la app.
Se deberá poder diferenciar desplazamiento en automóvil o motocicleta, así como si el desplazamiento lo ha hecho personal propio o artistas. A efectos prácticos, de cara al ERP, estamos hablando de 4 artículos diferentes para contemplar las 4 posibilidades.
3.4. Comidas del personal de la CCMA, S.A.
La CCMA, SA ha distribuido los tipos de comidas en diferentes grupos que requieren comportamientos específicos:
1 - Comidas y gastos de cafetería derivados de viajes y desplazamientos en territorio español.
Los gastos relacionados con esta tipología deben liquidarse solo con unos artículos determinados, que son los siguientes:
• RESTAURANTE/CAFETERÍA VIAJE PP
• SERVICIO COMIDA CATERING PERSONAL DEPT PGM
El ticket que justifique este gasto, debe ser de carácter individual.
Cuando por razones extraordinarias no sea posible pedir un ticket individual, el responsable de la liquidación debe introducir la cantidad de “comensales” y sus nombres (no se aceptará a nadie que no sea personal de la CCMA SA), para cumplir lo que establece la norma vigente.
El importe unitario por persona no podrá superar el precio máximo establecido. Si se superase este importe la diferencia irá a cargo del responsable de la liquidación.
2 - Restaurantes viajes al extranjero o invitados programas
Cuando se den estas circunstancias las comidas deben liquidarse con unos artículos determinados, que son los siguientes:
• RESTAURANTE VIAJE EXTRANJERO
• RESTAURANTE INVITADO PROGRAMAS
En ese caso cuando haya más de un comensal se pedirá su cantidad. Habrá que informar de una lista de personas y/o cargos, que podrán ser empleados de la CCMA SA o no (en el caso de invitados de programas, debe indicarse el nombre de las personas invitadas).
3 - Comidas de representación que requiere formulario autorizado previamente
Los gastos relacionados con esta tipología deben liquidarse con un artículo concreto, que es el siguiente:
• RESTAURANTE COMIDAS DE REPRESENTACIÓN, ACTOS PUBLICOS Y COMERCIAL
Antes de generar el gasto se debe haber pedido autorización a nuestro ERP a través del formulario de comidas donde debe detallarse el motivo y las personas que asistirán a la comida. Esta autorización de formulario de comida está identificada con un código que en el momento de realizar la liquidación del gasto se introducirá.
4 - Comidas de representación que no requieren formulario autorizado previamente
Los gastos relacionados con esta tipología deben liquidarse con un artículo concreto, que es el siguiente:
• RESTAURANTE COMIDAS DE REPRESENTACIÓN, ACTOS PUBLICOS Y COMERCIAL
Se tendrá que detallar el motivo y las personas que asistirán a la comida.
La App tendrá que permitir gestionar estas 4 casuísticas.
3.5. Alertas
Si bien el ERP de la CCMA, SA dispone de unas alertas y mecanismos que velan para que las liquidaciones sean acordes al convenio de la empresa y a la normativa legal, será necesario que la App ofrezca la posibilidad de crear alertas. Éstas actuarán a modo de pre-control, y permitirán avisar al usuario de que es posible que haya algún defecto de forma en algún gasto de la nota o que, simplemente, ha habido un error humano en la introducción. Este aviso debe ser claramente visible por parte del usuario en la app antes de que el mismo decida enviar a autorizar; de esta forma, el usuario podrá corregir posibles errores antes de que la nota de gasto llegue al autorizador.
Es decir, la herramienta debe permitir configurar controles a nivel de topes de importes o de cualquier valor de los campos existentes en una nota de gasto. De este modo, se podrá realizar un pre-control de las posibles transgresiones de las políticas de gasto y, cuando sea el caso, generar un mensaje de advertencia o incluso de error (en caso de que se incurra en alguna política bloqueante de gasto). Este mensaje será recibido por el usuario para advertir al mismo de un posible error humano. En caso de que la nota de gasto se envíe a autorización, los mensajes se trasladarán al ERP para poder ser mostrados a los autorizadores.
A tal efecto, la app debe permitir crear alertas o indicar error en casos como los siguientes:
• Lo más importante, es necesario detectar tickets duplicados, es decir, ya procesados
• Por gasto de dos comidas por el mismo día y por el mismo trabajador
• Por gasto de un tipo determinado por encima de un umbral.
• Comprobante con fecha muy antigua
• La App debe poder mostrar alarma cuando se exceda el importe máximo por comensal y comprobante en el caso de comidas de representación o comidas de trabajadores desplazados.
• Puede haber cargos exentos de estos límites,
3.6. Campos de información asociados al SII
La App deberá detectar obligatoriamente todos los campos que son de obligado cumplimiento por la normativa fiscal. Es decir, según el tipo de documento, se tendrán que identificar los campos a enviar obligatoriamente al SII (Suministro Inmediato de Información), el suministro electrónico de los registros de facturación a través de la web de la AEAT.
Adicionalmente, se podrá enviar otra información asociada al gasto, como por ejemplo la hora o la ciudad en la que se ha emitido el ticket.
3.7. Disponibilidad de la información ante requerimientos de Hacienda. Plan de devolución
El licitador debe proporcionar la forma para que la CCMA, SA esté cubierta ante cualquier inspección de Hacienda en cuanto a los tickets digitalizados, ya que es la captura de imágenes realizada por la App la que está certificada por la AEAT y permite destruir el papel después de su captura. En este aspecto, esté o no esté vigente la relación contractual con el licitador en el momento de la inspección de Hacienda, el licitador deberá proporcionar un sistema para que la CCMA, SA pueda proporcionar las evidencias documentales a la AEAT y garantizar al inspector que la copia digital es exacta a la original. Las imágenes de los tickets tendrán que ser consultables por la AEAT y/o la CCMA, SA como mínimo durante el límite legal de conservación, incluyendo el hecho de que las aberturas de inspecciones congelan el tiempo en cuanto al límite legal de conservación.
El contrato podrá resolverse por el cumplimiento de la fecha de finalización, por un incumplimiento severo o por acuerdo entre ambas partes. En cualquiera de los casos, previamente siempre deberá ejecutarse la transferencia de los servicios. Para garantizar la correcta transferencia (servicio y conocimientos) a la finalización de la vigencia del contrato, se elaborará un plan de retorno de los componentes, datos y ficheros asociados, así como la totalidad del servicio relacionado, cuyo coste estará incluido en la oferta.
3.8. Tarjetas VISA
El personal de la CCMA, SA que realiza viajes y/o liquidaciones con cierta asiduidad, que se calcula aproximadamente en unas 300 personas, dispone de tarjeta VISA corporativa. Estas tarjetas son de CaixaBank, entidad que proporciona a diario a la CCMA, SA todos los movimientos diarios de las tarjetas, que llegan actualmente a los 2 días. La CCMA, SA remitirá al licitador los ficheros que lleguen del banco.
Es necesario que la App se integre con nuestras tarjetas. La App deberá conciliar (semi- automáticamente) estos movimientos que vienen del banco con las liquidaciones hechas desde la App. Es decir, la App hará una conciliación automática de los movimientos de las tarjetas con las imágenes de los tickets digitalizados, y solo una vez el usuario valide la conciliación como correcta, la información se enviará al ERP para que pueda tener constancia. El usuario también será el encargado de conciliar manualmente todos aquellos movimientos que no se han podido conciliar de forma semiautomática.
En resumen, la operativa de cara al usuario sería: el usuario hace la foto del ticket, el OCR extrae automáticamente los campos con los datos SII, la App hace la conciliación automática en todos los casos que puede, y el usuario debe validar esta conciliación automática y hacer la conciliación manual de lo que no se ha podido conciliar automáticamente.
Remarcar que la conciliación debe poder realizarse desde la App móvil, y que un movimiento de gasto realizado con VISA debe ser obligatoriamente conciliado por parte del usuario antes de poder ser enviado al ERP para autorización.
4.VOLUMETRÍA PREVISTA
En cuanto a volumetría, los datos de referencia de 2019 (2020 no es, por motivos obvios, un año de referencia) a nivel de volumetría son los siguientes (datos anuales):
• Usuarios que realizan liquidaciones: 1.095
• Número de notas de gasto: 11.076
• 6.098 con tickets o factura (29.992 movimientos de gasto asociados, de los que 25.496 corresponden a facturas simplificadas y 4.496 a facturas)
• 4.978 de dietas y/o kilometrajes (20.563 movimientos de gasto de dietas y 4.004 de kilometrajes)
• Movimientos de gasto (sin tener en cuenta las dietas) introducidos en el ERP en 2019: 33.996
• Estimación de los movimientos de gasto “unitarios” de 2019 (sin tener en cuenta las dietas) unitarios, teniendo en cuenta que en el ERP se pueden introducir varios tickets como un solo movimiento de gasto: 55.000
Nota: Es importante observar que el ERP permite agrupar más de un ticket en un mismo movimiento de gasto (por ejemplo, se puede tomar una foto con varios tickets de taxi que actualmente en el ERP se contabiliza como un solo movimiento). A tal efecto, se calcula que el número total real de movimientos de gasto (tickets, facturas o kilometrajes) es del orden de 55.000, y no el indicado en la columna “TOTAL Movimientos Gasto”. Si se tuvieran en cuenta también las dietas, el número total de movimientos de gasto se calcula que sería del orden de 75.000.
En resumen, si extrapolamos 2019, se estima que en un año estándar estaríamos hablando de:
• Usuarios no nominales que realizan liquidaciones en un año: 1.200
• Número de notas de gasto en un año: 12.000
• Número de movimientos de gasto: 55.000 (con dietas, unos 75.000)
Estos datos se dan como estimación de consumos futuros, aunque las cifras futuribles de empleados, usuarios no nominales, notas de gasto y movimientos de gasto podrán variar en función de la evolución que tengan la plantilla y la propia organización de la misma CCMA, SA en los próximos años.
Remarcar que para la fase inicial del proyecto no se prevé utilizar la App para que el usuario introduzca dietas. Sin embargo, sí se prevé incorporar esta funcionalidad una vez el uso de la App sea más generalizado (en este caso se utilizará la partida de adaptaciones tecnológicas u organizativas para costear el gasto asociado a poner en marcha esta nueva funcionalidad).
A continuación, se muestra el histórico de datos (usuarios no nominales, notas de gasto por tipos y movimientos de gasto por tipos) que están registrados en el ERP de la CCMA, SA desde 2015, y el detalle mensual de la anualidad 2019:
AÑO | Mes | Usuari os no nomina les | Notas de gasto de Tickets | Notas de gasto de dietas y Kms | Movimiento s de gastos (tickets, sin factura) | Movimie ntos de gastos (con factura) | Movimien tos de gasto de Dietas | Movimie ntos de gasto de Kms |
2015 | 1 a 12 | 1.109 | 6.930 | 5.774 | 25.742 | 4.070 | 26.384 | 4.090 |
2016 | 1 a 12 | 1.049 | 6.334 | 5003 | 26.833 | 4.398 | 22.936 | 5.074 |
2017 | 1 a 12 | 1.200 | 7.326 | 5.975 | 27.912 | 4.081 | 23.492 | 4.775 |
2018 | 1 a 12 | 1.113 | 6.439 | 5.286 | 22.911 | 4.294 | 19.930 | 4.515 |
2019 | 1 a 12 | 1.095 | 6.098 | 4.978 | 25.496 | 4.496 | 20.563 | 4.004 |
2020 | 1 a 12 | 879 | 3.763 | 2.678 | 14.918 | 3.280 | 10.001 | 1.951 |
2021 | 1 a 12 | 806 | 5.062 | 3.960 | 18.496 | 4.178 | 14.822 | 3.134 |
AÑO | Mes | Usuari os no nomina les | Notas de gasto de Tickets | Notas de gasto de dietas y Kms | Movimiento s de gastos (tickets, sin factura) | Movimie ntos de gastos (con factura) | Movimien tos de gasto de Dietas | Movimie ntos de gasto de Kms |
2019 | 1 | 334 | 364 | 343 | 1.079 | 79 | 1.395 | 175 |
2 | 410 | 491 | 441 | 1.758 | 347 | 2.231 | 255 | |
3 | 459 | 582 | 471 | 2.075 | 455 | 2.059 | 327 | |
4 | 439 | 538 | 470 | 2.133 | 442 | 2.116 | 322 | |
5 | 465 | 605 | 508 | 2.808 | 430 | 1.744 | 380 | |
6 | 452 | 556 | 401 | 2.468 | 450 | 1.769 | 353 | |
7 | 436 | 499 | 386 | 2.481 | 405 | 1.775 | 449 | |
8 | 200 | 212 | 145 | 666 | 121 | 626 | 238 | |
9 | 350 | 400 | 366 | 1.631 | 241 | 1.675 | 220 | |
10 | 506 | 606 | 530 | 2.339 | 407 | 1.849 | 372 | |
11 | 433 | 518 | 479 | 2.526 | 420 | 1.663 | 390 | |
12 | 483 | 727 | 438 | 3.532 | 699 | 1.661 | 524 | |
TOTAL | 1.095 | 6.098 | 4.978 | 25.496 | 4.496 | 20.563 | 4.004 |
5.FLUJO DE INFORMACIÓN ERP-APP
La solución para la gestión de gastos deberá poder integrarse con el ecosistema de la CCMA, SA a distintos niveles. Podemos resumir esta integración en los siguientes aspectos:
• Integración de la app con nuestro ERP, que es de desarrollo propio y llamamos SAWI: en líneas generales, la nota de gasto se digitalizará desde la app móvil o la MFP, y se completará desde la misma app móvil o la app web. El circuito de autorizaciones se gestionará sin embargo desde nuestro ERP.
• Habrá que hacer una integración para delegar la autenticación de los usuarios hacia el proveedor de identidades de la CCMA.
• Habrá que crear las pasarelas de información para que la app reciba los movimientos diarios de las tarjetas VISA corporativas. La aplicación facilitará la conciliación automática de los movimientos con las notas de gasto.
Los movimientos deben iniciarse siempre desde la app o MFP. Se debe realizar una inserción digital del ticket desde la app aprovechando la movilidad. La imagen digitalizada del ticket y los datos necesarios para el SII irán de la app al ERP. Del ERP a la app irá menos información: los maestros de datos (artículo y código analítico y datos trabajador), y el estado de la liquidación para que pueda ser consultada desde la app (pendiente completar, completado y pendiente autorizar, autorizado, denegado). Una liquidación está en la app o en el ERP, y no se podrá modificar a la vez en ambos sistemas.
Existirán varios flujos de información entre la app y el ERP y viceversa. En el punto 14 se muestra un esquema resumen. A continuación, describimos estos flujos de información entre ambos sistemas.
5.1. Maestros de datos
En caso necesario, se establecerán los mecanismos para que se puedan cargar los maestros de datos en el sistema de la app, ya que los licitadores han indicado que así se mejora el rendimiento de la app. En concreto, es imprescindible que la app tenga APIs o servicios similares para facilitar la introducción de los siguientes 3 conceptos:
• Los artículos que definen la naturaleza del gasto (creemos que con menos de 100 artículos cubriremos los casos estándar que antes indicábamos)
• El código analítico. No filtraremos códigos en función del trabajador, es decir, cualquier trabajador podrá realizar una liquidación sobre cualquier centro de coste. Nuestra estructura analítica contiene del orden de unos 2.500 códigos analíticos vigentes en los que se puede imputar gasto.
• La lista de los trabajadores activos, sus centros de coste estructurales asociado y datos relevantes sobre el mismo. Por ejemplo, el municipio de residencia, el municipio del centro de trabajo, el tipo de colectivo son relevantes por la justificación de gastos de comidas de representación y dietas. También se pasará la información de las tarjetas VISA corporativas asociadas a cada trabajador. El ERP también proporcionará información sobre las delegaciones (en nombre de quienes pueden hacer una nota de gasto).
Se realizará una carga inicial de estos maestros, y en régimen permanente se consensuará una cadencia de sincronización (altas, bajas y modificaciones), que será como mínimo de una vez al día.
5.2. Envío de una nota de gasto al ERP
Mientras el usuario edite una nota de gasto, el ERP no tendrá trazabilidad de la misma. Una vez haya completado toda la información obligatoria (código analítico, tipo de movimiento VISA/sin entrega previa, foto de los tickets y artículos de cada gasto, etc.) y esté de acuerdo con el detalle de cada gasto (importe, CIF, etc.), puede enviar la nota de gasto al ERP para autorizar.
Cuando sea el caso, la app enviará (la CCMA, SA habilitará una API para poder hacerlo) al ERP toda la información de la nota de gasto, incluyendo el tipo y descripción de la alerta en caso de que la nota de gasto genere alerta en los controles de la App. Junto a esta información se enviará las URLs que permitan acceder a las imágenes de los comprobantes. Por otro lado, será necesario establecer un mecanismo para poder hacer llegar también una copia física de las imágenes a la CCMA, SA en algún formato estándar de imagen, preferentemente pdf.
Recordar la diferencia entre una liquidación estándar y una no estándar es que la primera referencia artículos concretos y en el segundo caso en alguno de los movimientos de gasto se utiliza un artículo genérico, “Artículo no disponible”.
Una vez enviado al ERP, en la app sí que se podrá consultar la misma, pero en cambio ya no se podrá editar esta nota de gasto.
5.3. Nota de gasto rechazada desde el ERP
Puede que una nota de gasto sea rechazada por el autorizador por defectos de forma. Los motivos pueden ser tan diversos como que existe un campo de información incorrecto (código analítico, artículo, importe, etc.), o que alguno de los gastos de la nota de gasto no aplica por el motivo que sea (no procede, fuera de norma, etc.).
Cuando un autorizador rechaza la nota de gasto indica mediante texto el motivo del rechazo.
Cuando la nota de gasto haya sido rechazada desde el sistema de la CCMA, SA, el ERP informará (vía API) a la app de que esa nota de gasto ha sido rechazada y le transmitirá el texto explicativo del autorizador. El usuario será informado mediante notificación push en la app móvil de que la nota de gasto ha sido rechazada y del motivo del rechazo.
A partir de ese momento, la nota de gasto pasa a ser un borrador editable dentro de la App. El usuario podrá modificarla, actualizando y/o anulando partes o toda la nota de gasto.
5.4. Consulta estado de las notas de gasto
Cuando un usuario entre en la App podrá consultar el estado de sus notas de gasto, el cual podrá ser:
No enviado al ERP (borrador editable en la App). Enviado a ERP y pendiente de autorizar Autorizada y pendiente de validar en el ERP Validada y pendiente de pagar
Pagada
Denegada desde la CCMA, SA (por el autorizador, Administración o usuario). En ese caso, pasa a ser editable desde la App
En los estados 1 y 6 la nota de gasto se podrá editar desde la app, mientras que en los estados 2, 3, 4 y 5 la nota de gasto ya no es editable desde la app porque está en el circuito de autorizaciones del ERP.
5.5. Envío de los movimientos de las tarjetas VISA corporativas
A diario, la CCMA, SA recibirá ficheros de la entidad bancaria con los movimientos de las tarjetas VISA corporativas. Si nada cambia, estos movimientos vendrán con dos días de decalaje. La CCMA, SA por su parte realizará uno o varios (según se acuerde con el proveedor) envíos de información con estos datos de los movimientos diarios de las tarjetas VISA corporativas. Una alternativa es que la CCMA, SA dé acceso instantáneo a los movimientos diarios de las tarjetas de CaixaBank mediante la delegación de las credenciales al proveedor.
5.6. Delegación autenticación de credencial
Los usuarios tendrán que utilizar el login y password corporativos para identificarse en la app. A tal efecto, será necesario que la app valide con el identificador de usuario y contraseña contra el proveedor de identidades de la CCMA, SA utilizando el protocolo SAML2.0 o equivalente. Esto obligará a que haya procesos de alta, baja y modificación de usuarios en la app, pero por otra parte facilitará mucho al trabajador la autenticación.
6.EVALUACIÓN DE LOS CRITERIOS TÉCNICOS
La calidad técnica y las prestaciones de usuario de la App son un factor crítico para la adopción de la App por parte de los usuarios de la CCMA, SA y, en consecuencia, para el éxito del proyecto.
A tal efecto, las empresas requeridas tendrán que estar en disposición de realizar una prueba de concepto, que será presencial, a partir de 7 días desde el momento en que se les comunique la necesidad de hacerlas.
A efectos prácticos, se convocará individualmente a cada uno de los licitadores para realizar la prueba de concepto. Previamente, el licitador deberá haber habilitado 6 cuentas de test que tendrán que estar activas un mínimo de 15 días. Y previamente también, la CCMA, SA habrá seleccionado una muestra de comprobantes de distintos tipos (facturas, facturas simplificadas y comprobantes manuales, en otros alfabetos y/u otros idiomas). Esta muestra de comprobantes es la que se utilizará en la prueba de concepto para todos los licitadores.
En un primer estadio, se revisará el contenido del Anexo 3, que el licitador deberá llevar cumplimentado el día de la prueba de concepto. La CCMA, SA se reserva el derecho de aclarar cualquier duda sobre los puntos indicados en este anexo.
Posteriormente se realizará una evaluación empírica de la App. Para poder realizarla, no se pide ninguna integración previa con el ERP de la CCMA, SA, pero en cambio sí se proporcionarán con antelación al licitador cuando lo requiera unos maestros de datos (códigos analíticos, artículos) para que se pueda hacer una precarga de los mismos. Se medirán los tiempos de respuesta y la precisión en la extracción de los datos, comparando los resultados proporcionados por la App con los resultados de las Apps de los demás licitadores.
Con respecto a esta segunda parte de la prueba de concepto:
• La CCMA, SA proporcionará un móvil (el mismo para todos los licitadores) donde se instalarán las Apps de los distintos licitadores. Este móvil será el que se utilizará para realizar las siguientes medidas empíricas:
o Tiempo medio de procesado de la digitalización y extracción de datos de una pequeña muestra de comprobantes.
o Fiabilidad de la extracción de datos de la muestra de facturas simplificadas.
o Fiabilidad de la extracción de datos de la muestra de facturas completas.
o Fiabilidad de la extracción de datos de la muestra de comprobantes manuales, en otros alfabetos y/u otros idiomas.
Las fotos de los comprobantes serán tomadas por el representante designado por la empresa licitadora.
Al terminar la extracción de datos de la muestra de comprobantes, se compararán los resultados con los datos esperados, y se dará al licitador un comprobante con el resultado
de la prueba. Para poder realizar esta evaluación de la extracción de datos, lo ideal es que la herramienta permita extraer un listado de los resultados, de las notas de gasto realizadas. Si esto no es posible, el proceso se realizará manualmente.
Por otra parte, se volverá a evaluar la extracción de datos al cabo de 48 horas, ya que algunas Apps mejoran la fiabilidad de los datos extraídos, aunque sea por medio de intervención humana. Se ofrecerá al licitador la posibilidad de volver a venir a las instalaciones 48 horas después si lo cree conveniente.
• Se instalará la App en uno o varios móviles y se realizará una serie de operaciones básicas. A posteriori, se evaluará: la usabilidad y experiencia de usuario de la versión móvil y de escritorio.
7. PLAN DE IMPLANTACIÓN
La herramienta del licitador deberá configurarse de forma particularizada e integrarla con los sistemas de la CCMA, SA, especialmente con el ERP y el proveedor de identidades de la CCMA, SA. En consecuencia, habrá que realizar un proyecto de implantación de la herramienta que, entre otros, contemplará los siguientes objetivos:
• Configuración del entorno de la App para la CCMA, SA y de los flujos de trabajo
• Integración entre el ERP de la CCMA, SA y la App (ver apartado 6 Flujo de información ERP-app)
• Carga y sincronización de artículos, códigos analíticos y usuarios CCMA, SA.
• Base de datos de pruebas para realizar test (habrá que proporcionar un entorno de pruebas para poder realizar test en la fase de implantación y para validar futuras modificaciones en el sistema)
• Delegación de autenticación de los usuarios contra el proveedor de identidades de la CCMA, SA.
• Despliegue de la herramienta a nivel de usuarios y formación para la gestión del cambio
• Puesta en producción de la solución
• Integración con MFP (Multifunction Printer) de Canon
• Entrega de la documentación para los usuarios (documentación para la gestión del cambio y manual de usuario con descripción acceso a App, pantallas, campos, funcionalidades disponibles, etc.) y de la documentación de explotación (orientada al personal del departamento informático de la CCMA, SA).
Se estima el siguiente calendario y metas asociadas al plan de despliegue de la herramienta:
• T0: Inicio del proyecto (kickoff)
• T1 = T0 + 1,5 semanas. Final fase de análisis de alto nivel.
• T2 = T1 + 2,5 semanas. Final fase de análisis detallado de todo el proyecto, incluyendo pasarelas entre la herramienta y los sistemas de la CCMA, SA.
• T3 = T2 + 2 meses. Final fase de implantación del proyecto, incluyendo pruebas y una preparación del paso a producción.
• T4 = T3 + 1 mes. Final fase de prototipado con un subconjunto de usuarios de la organización. Se inician las formaciones y la gestión del cambio.
• T5 = T4 + 1 mes. Final fase de despliegue en el resto de los usuarios de la CCMA, SA. Integración con las MFP disponible.
Las metas pueden cambiar, ya que se consensuarán con el adjudicatario. Sin embargo, en el cuarto mes el sistema debe estar operativo, y en el quinto mes la integración con las impresoras multifunción y el despliegue en toda la CCMA, SA deben ser una realidad.
La implantación de la herramienta (mediante la consecución de estos objetivos) está dotada con una partida presupuestaria que es la que en el Pliego de Condiciones Administrativas está descrita como “Puesta en funcionamiento del servicio”.
En caso de que los servidores estén ubicados fuera del territorio español, el licitador facilitará a la CCMA, SA la comunicación en la AEAT del uso de una solución homologada con los datos fuera del país.
8.RECUPERACIÓN DEL IVA
Los módulos de recuperación de IVA no son objeto de la presente licitación, sino de un proyecto que se abordará a posteriori de la implantación de la herramienta de digitalización de tickets. Sin embargo, la empresa adjudicataria debe comprometerse a desarrollar y probar los medios necesarios para que se pueda realizar la recuperación del IVA de los comprobantes por parte de la empresa contratada a tal efecto por la CCMA, SA. En otras palabras, el servicio de recuperación de IVA se adjudicará en un futuro vía licitación y, por tanto, la empresa adjudicataria del servicio de la presente licitación debe comprometerse a poner los medios para que se pueda realizar el servicio de recuperación de IVA, cualquiera que sea la empresa a la que eventualmente se adjudique el servicio de recuperación de IVA.
9.FACTURACIÓN DEL SERVICIO
Se diferenciarán 3 conceptos facturables fruto de esta licitación:
1. el coste inicial de implantación y configuración de la herramienta,
2. el coste recurrente por el uso del servicio
3. el coste de las adaptaciones tecnológicas u organizativas para eventuales cambios no contemplados en la fase de implantación de la herramienta
Cada concepto se facturará en base a distintos criterios, explicados en los siguientes puntos.
9.1 Coste implantación y configuración de la herramienta
El licitador tendrá que ofrecer un importe único para todo el coste de implantación y configuración inicial de la herramienta. Este importe deberá incluir todos los conceptos necesarios para poder llevar a cabo la implantación del proyecto en la CCMA, SA, que son los estipulados en el apartado
7. PLAN DE IMPLANTACIÓN.
Dado que se realizará una implantación progresiva por áreas, se escogerá una o dos áreas para realizar un piloto inicial. El licitador podrá facturar el 40 % del coste de implantación al inicio del proyecto, el 40 % restante a la finalización xxx xxxxxx, y el 20 % restante cuando se haya extendido el uso de la herramienta a la totalidad de la organización.
9.2 Coste del licenciamiento de la herramienta (el coste recurrente por el uso del servicio)
El coste de uso de las licencias incluye el soporte para hacer uso de la herramienta y consulta de incidencias.
Anteriormente se han proporcionado datos con la volumetría histórica de la CCMA, SA, tanto en lo que se refiere a número de usuarios no nominales, número de notas de gasto y número de movimientos de gasto. La CCMA, SA elige que el modelo de licenciamiento por uso para esta licitación debe basarse en el segundo parámetro, el de número de notas de gasto.
En cuanto a facturación de este servicio, la CCMA, SA ofrece dos opciones, a consensuar con el proveedor.
1. La opción preferida por la CCMA, SA es la de que se establezca un período (mes, trimestre o semestre) y se realiza una facturación en base a la realidad una vez finalizado el período y se disponen de datos reales para ese período.
2. Si el proveedor prefiere una facturación por anticipado, existe también la opción de que el proveedor facture por adelantado a principio de semestre un importe correspondiente a un presupuesto calculado a la baja y acordado con la CCMA, SA; por ejemplo, un 40 % de la previsión para ese período, en ningún caso más del 60 %. A posteriori, una vez se conozca la realidad del semestre, se realizará una regularización y la CCMA, SA abonará la diferencia con base en la fórmula:
coste unitario por nota de gasto ofertado de acuerdo al volumen anual x número de notas de gasto gestionadas durante el período] - presupuesto facturado por adelantado.
La CCMA, SA abonará la diferencia y, sólo en el caso excepcional en que la realidad del período no supere el presupuesto abonado anticipadamente, se podrá optar por regularizar la diferencia con una factura rectificativa o bien acumular para próximos períodos el saldo no gastado de notas de gastos.
9.3 Coste posteriores adaptaciones tecnológicas u organizativas, o para un uso de la herramienta superior al previsto
• Para un uso de la app superior a lo previsto, que suponga una facturación anual superior a los 50.000 euros.
• Para adaptaciones tecnológicas u organizativas, como pueden ser para añadir la opción de dietas, anticipos, u otras opciones.
10.INFORMES DE SEGUIMIENTO DEL SERVICIO
Asociado a este servicio, y para poder realizar una medida efectiva de la calidad del mismo, el adjudicatario deberá reportar periódicamente un informe donde se detallen las incidencias, los indicadores reales que permitan realizar un seguimiento del ANS y el detalle de la facturación.
Los informes incluirán obligatoriamente la medida real de los parámetros definidos en el ANS, así como otros KPIS que se definan para el servicio. De igual modo, deberá indicarse la medida real de todos los parámetros que afecten a la facturación, incluyendo las penalizaciones.
Previo a la puesta en marcha del servicio, el adjudicatario y el responsable del servicio de la CCMA, SA consensuarán el detalle concreto de los informes, así como la periodicidad de los mismos, que no puede ser inferior a una vez al trimestre.
11.FORMACIONES Y DESPLIEGUE A USUARIOS
El adjudicatario tendrá entre sus obligaciones proponer, planificar y realizar la formación y la gestión del cambio que implica la implantación de su herramienta en la CCMA, SA, incluyendo en esta gestión del cambio los medios materiales y humanos necesarios para impartir la formación necesaria.
Dentro de la partida de implantación, será necesario que el licitador incluya un plan de formación y gestión del cambio con respecto a los usuarios. Siempre de forma coordinada con la CCMA, SA, será necesario que haya una estrategia que combine formaciones junto con materiales de comunicación: vídeos personalizados, pósteres, etc. La formación y los materiales tendrán que estar disponibles en idioma catalán.
12. REUNIÓN EXPLICATIVA EN LAS INSTALACIONES DE LA CCMA,SA
Las empresas licitadoras podrán asistir a una reunión explicativa en las instalaciones de CCMA, SA, en la sede de la televisión en Sant Xxxx Xxxxx.
A tal efecto, tendrán que confirmar, por correo electrónico y antes del día 20 de julio de 2022, su asistencia a la dirección:
xxxxxxxxxxxxxxxxxxxxxxxxxxxx@xxxx.xxx
indicando en el asunto del correo: CPO 2207OB04 asistencia a la reunión explicativa.
En este correo deberá figurar, necesariamente, el nombre de la empresa, el nombre y el número de DNI de la persona o personas que asistirán (máximo dos), y el nombre de la persona de contacto, su teléfono y la dirección de correo electrónico.
Las visitas tendrán lugar el día 20 de julio de 2022 a las 11:00 horas en las instalaciones de televisión de la CCMA, SA en Sant Xxxx Xxxxx, en la xxxxx Xxxxx Xxxxxxxxx 0.
Cualquier información facilitada en la visita que complemente y actualice la información contenida en estas prescripciones técnicas deberá ser tenida en cuenta.
En caso de que de alguna de las visitas optativas surja documentación o información adicional que todos los licitadores deben tener en cuenta, la CCMA, SA se compromete a publicarla en el perfil del contratante de su web corporativa.
13.ESQUEMA GENERAL FLUJOS INFORMACIÓN ERP-APP
CÁRGA MAESTROS DE DATOS CMMA EN LA APP
Artículos (Naturaleza gasto)
Códigos Analíticos
RHIN / SAWI
Módulo SAWI de
Carga inicial en la Base de datos Actualizaciones diarias
(altas, bajas, modificaciones)
Carga inicial en la Base de datos Actualizaciones diarias
(altas, bajas, modificaciones)
Listado trabajadores activos Delegación en nombre de quien Se pueden hacer liquidaciones
Todos los datos de las notas de gasto Copias de las imágenes de los comprobantes
Alertas asociadas
Unos 30 artículos Selector y búsqueda por texto
Unos 2.500 cecoste
3 selectorsi: últimos códigos, códigos programas, códigos estructurales
No filtramos lista cecostepor trabajador Búsqueda descripción a partir de 3, 4 o 5 caracteres
LISTADO USUARIOS APP Y DELEGACIONES
Liquidación estándar completada desde la APP
INTRODUCCIÓN DE UNA LIQUIDACIÓN EN LA APP
liquidaciones
Todos los datos de las notas de gasto Copias de las imágenes de los comprobantes
Alertas asociadas
Liquidación no estándar (debe terminarse en SAWI)
LIQUIDACIÓN NO AUTORIZADA VUELVE A ESTADO INICIAL PERO
Módulo SAWI de
liquidaciones
Módulo SAWI de liquidaciones Módulo SAWI de liquidaciones
Sistemas
Nota de gasto ha sido rechazada Y vuelve a ser editable desde la app
(se indica el motivo) Estado de las liquidaciones (*1)
Movimientos diarios Tarjetas VISA corporativas
Conciliaciones tickets – movimiento VISA
Datos usuario y OK/denegación (3)
Liquidación con todos los campos completos, lista para ser actualizada/corregida o anulada
A posterior, consulta (modificación también) de mis liquidaciones
Conciliación de los movimientos de tarjetas con las liquidaciones
Autenticación de la credencial
CON DATOS INFORMADOS
CONSULTA ESTADO MIS LIQUIDACIONES (POSTERIOR A LA INTRODUCCIÓN)
CONCILIACIÓN DE LA APP DE LIQUIDACIONES CON MOVIMIENTOS DIARIOS DE LAS VISA
14.ACUERDO DE NIVEL DE SERVICIO
El presente apartado es el Acuerdo de Nivel de Servicio (en adelante, "ANS"), que documenta el nivel acordado para la calidad del servicio y será de aplicación durante la ejecución del servicio fruto de esta licitación.
Mediante la aceptación implícita de este ANS por licitar este servicio, el licitador se compromete a proporcionar continuidad de servicio con el objetivo de asegurar el mejor rendimiento y un nivel muy alto de tiempo de disponibilidad. Los parámetros estipulados en este ANS serán monitorizados y evaluados mensualmente. En otras palabras, el ANS tiene el objetivo de identificar, valorar y realizar un seguimiento de unas expectativas de servicio razonables, y en último término garantizar que las necesidades de la CCMA, SA son cubiertas de formar correcta por parte del proveedor.
La tabla de la página siguiente identifica las métricas que permitirán controlar y auditar el servicio licitado, así como las penalizaciones asociadas en los casos de incumplimiento.
El licitador deberá informar mensualmente a la CCMA, SA de estas métricas.
Preferiblemente, el acceso a esa información debería ser online mediante informes de Business Intelligence; alternativamente, también podría hacerse mediante un correo electrónico a los responsables de la CCMA, SA designados con el propósito de realizar un seguimiento del servicio. En ambos casos, la CCMA, SA tendrá acceso a la información con la realidad de ese mes para cada uno de los parámetros objeto del servicio antes del día 5 de cada mes.
La siguiente tabla identifica las métricas que permitirán controlar y auditar el servicio licitado, así como las penalizaciones asociadas en los casos de incumplimiento.
SERVICIO | PARÁMETRO QUE SE MIDE | Definición | COMPROMISO POR PARTE DEL LICITADOR | OBSERVACIONES | PENALIZACIONES |
App móvil | Disponibilidad del servicio | Tiempo que el sistema está operativo | 99,75 % | El servicio debe estar disponible 24x7, exceptuando mantenimientos o interrupciones programadas e informadas. Por tanto, no deberían haber más de 22 horas al año inoperativo por motivos sobrevenidos. | Horas mensuales por encima de las 2h de interrupción no programadas / horas dentro del mes (*2). Hasta un máximo del 10 % de la facturación del mes. Se descontará de la factura mensual. |
App Web | |||||
Servicio de reconocimiento de datos | |||||
Servicio de soporte | Tiempo máximo de asistencia (TMA) por incidencia crítica | Incidencia crítica es cuando el servicio está parado y los usuarios no pueden trabajar con la aplicación. | < 2 horas | TMA: Tiempo máximo de asistencia (Tiempo que pasa desde que CCMA contacta por email o teléfono hasta que el licitador se pone a trabajar en la incidencia) TR: Tiempo de resolución (tiempo transcurrido entre la notificación de la incidencia y su resolución) Estos tiempos se miden dentro del horario de servicio de 10h x 5 días, es decir, de 8 a 18 h en días laborables. | Horas mensuales por encima de las 2h de TMA máxima / horas dentro del mes. Hasta un máximo del 10 % de la facturación del mes. Se descontará de la factura mensual. |
Tiempo máximo de resolución (TR) por incidencia crítica | < 6 horas | Horas mensuales por encima de las 2h de TR máxima / horas dentro del mes. Hasta un máximo del 10 % de la facturación del mes. Se descontará de la factura mensual. | |||
Tiempo máximo de asistencia (TMA) por incidencia crítica baja | Incidencia de crítica baja es aquella en la que el usuario puede continuar normalmente con sus actividades o que no tiene impacto en el día a día del negocio | < 12 horas | Horas mensuales por encima de las 12h de TMA máxima / horas dentro del mes. Hasta un máximo del 10 % de la facturación del mes. Se descontará de la factura mensual. | ||
Tiempo máximo de resolución (TR) por incidencia crítica baja | < 48 horas | Horas mensuales por encima de las 48h de TMA máxima / horas dentro del mes. Hasta un máximo del 10 % de la facturación del mes. Se descontará de la factura mensual. |
SERVICIO | PARÁMETRO QUE SE MIDE | Definición | COMPROMISO POR PARTE DEL LICITADOR | OBSERVACIONES | PENALIZACIONES |
App móvil | Fiabilidad en el OCR, extracción inmediata de datos de los comprobantes | Número xx xxxxxx detectados correctamente dividido por el número xx xxxxxx totales a detectar | 92,00 % | No entrarán en consideración para la evaluación de este parámetro las imágenes defectuosas de comprobantes (*1) | Entendemos RE (ratio de acierto) = (número xx xxxxxx detectados correctamente / número xx xxxxxx totales a detectar). En el caso de que RE < 92 %, se aplicará una penalización equivalente al (92 % - RE), hasta un máximo del 10 % de la facturación del mes. |
Multi-function-Printer | |||||
App móvil | Tiempo de extracción inmediata de los datos de los comprobantes | Tiempo entre que se escanea un comprobante estándar sin defectos y están disponibles en la App móvil los campos de información | 1 min | Comprobantes con detección xx xxxxxx inmediata por encima del minuto / comprobantes dentro del mes. Hasta un máximo del 10 % de la facturación del mes. Se descontará de la factura mensual. | |
App móvil | Fiabilidad en el proceso de extracción de datos de los comprobantes por el SII | Número xx xxxxxx detectados correctamente dividido por el número xx xxxxxx totales a detectar | 95,00 % | Entendemos RE (ratio de acierto) = (número xx xxxxxx detectados correctamente / número xx xxxxxx totales a detectar). En el caso de que RE < 95 %, se aplicará una penalización equivalente al (95 % - RE), hasta un máximo del 10 % de la facturación del mes. | |
Multi-function-Printer | |||||
App móvil | Tiempo de latencia en la extracción de los datos por el SII | Tiempo entre que se escanea un comprobante y se tienen disponibles todos los campos que son necesarios para el SII | 45 horas | Comprobantes con detección xx xxxxxx inmediata por encima de las 48 h/ comprobantes dentro del mes. Hasta un máximo del 10 % de la facturación del mes. Se descontará de la factura mensual. | |
Multi-function-Printer |
(*1) Las imágenes defectuosas de tickets y facturas no entrarán en consideración para la evaluación de este parámetro. Se consideran imágenes defectuosas aquellas fotos de comprobantes que no reúnen las condiciones de calidad necesarias debido a una mala praxis del usuario. Sí se considerarán en cambio las imágenes que sean nítidas y enfocadas, con un contraste razonable, donde el ángulo (entre la línea del lateral izquierdo del ticket y la línea del lateral derecho de la imagen) esté entre los -15 y +15 grados, el ticket no sea defectuoso (no está cortado, se ven todos los campos, y las letras son identificables y no están difuminadas)
(*2) Por ejemplo, en el caso de enero las horas del mes serían 744 horas (31 días x 24 horas). Por tanto, un exceso de 2 horas sobre el límite esperado supondría una penalización del 0,27 % sobre la facturación del mes.