Blog de Amazon Web Services (AWS)

Sistemas de Factura Electrónica sobre AWS

Cristian Romero, Solutions Architect for Public Sector on AWS

 

Amazon Web Services ha trabajado con más de 6,500 agencias de gobierno a nivel mundial, entre las cuales existen organizaciones encargadas de recibir, validar, almacenar y consolidar análisis sobre las Facturas Electrónicas que generan grandes, medianos y pequeños comercios dentro de un país.

Ejecutar este tipo de cargas en la nube reduce los costos de facturación, simplifica los procesos administrativos, aumenta el control gubernamental y la transparencia, e incrementa la seguridad con la que se intercambia información sensible de personas y comercios.

Generalmente, los procesos de Factura Electrónica requieren tres grandes capas a nivel tecnológico:

  • Recepción: la recepción puede escalar desde decenas a cientos de facturas emitidas por un pequeño negocio hasta facturas generadas en lote (miles o millones) por un negocio de grandes superficies. Cada persona jurídica debe cumplir con los requerimientos de envío al gobierno, pero pueden elegir hacerlo en tiempo real ó en algunos momentos específicos del día, según la regulación lo permita. Los servicios de tecnología gubernamental deben estar preparados para soportar la modalidad elegida por cada negocio de forma flexible.
  • Procesamiento: involucra la validación de las facturas electrónicas ingresadas, aplicando reglas sobre campos específicos, clasificando la información recibida y, en muchos casos, aplicando cifrado especial dada la sensibilidad de los datos con tecnologías de manejo de llaves, como lo es Hardware Security Module (HSM). En este punto existen distintas estrategias para resolver el procesamiento que pueden ir en línea con la recepción, es decir, se procesa en tiempo real ó, con un sistema de encolamiento de mensajes donde se procesa de acuerdo a la capacidad de cómputo
  • Almacenamiento y Análisis: es la capacidad de hacer resúmenes de cuentas, consultar negocios específicos para hacer seguimiento, generar métricas globales de transparencia y ofrecer servicios de búsqueda de esta información a otras aplicaciones o dependencias que consoliden impuestos. Idealmente, un auditor público debería ser capaz de ver en tiempo real o por lo menos con un rango de tiempo definido, métricas de la facturación de un comercio emisor; así como un Ministro requiere visibilidad del día a día sobre el avance del país en términos de comercio.

Para Amazon Web Services la seguridad es la prioridad número uno, por eso se recomienda que los clientes hagan uso de las herramientas de seguridad respectivas en cada paso para cumplir con los más altos estándares de cifrado, prevención de ataques, transferencia de datos y manejo de información personal (Personal Identifiable Information PII). La seguridad aplica en las tres capas nombradas anteriormente, desde los puntos de entrada (insumo de datos) hasta los puntos de salida (acceso a terceros) hacia otras aplicaciones o usuarios.

Recepción de Factura Electrónica

En el momento de publicación de este post, Amazon Web Services cuenta con más de 175 servicios disponibles para usarse como bloques de construcción en diversas soluciones que se ajusten a cada carga de trabajo. Esta guía busca dar lineamientos generales, pero puede ser modificada de acuerdo a la necesidad de cada institución.

En recepción de Factura Electrónica se han visto dos modalidades: a través de APIs autenticados por token para controlar el acceso y, manualmente a través de un sitio web. Generalmente la segunda opción se brinda a comercios pequeños o uni-personales que no cuentan con un sistema de facturación que se integre con el API ofrecido por el gobierno.

Los elementos más importantes a tener en cuenta son:

  • La recepción por Portal Web debe escalar según el tráfico que reciba. En el ejemplo se muestra un portal servido por AWS CloudFrontContent Delivery Network de AWS, que a través de caché reduce la latencia y mitiga ataques de DDoS. Este componente se integra con el servicio de AWS Web Application Firewall para prevenir ataques como SQL Injection o Cross-site Scripting. Más ejemplos sobre sitios web escalables en https://aws.amazon.com/es/websites/.
  • El sitio web estático, almacenado en el servicio de Amazon Simple Storage Service (S3), hace uso del mismo API Gateway que recibirá peticiones autenticadas vía token. Para la generación de estos tokens de autenticación se recomienda el uso de AWS Cognito; aunque se podría integrar otro servicio dispuesto por la institución sobre contenedores o instancias de cómputo ejecutando el desarrollo u software particular escogido. Estos tokens pueden ser generados en el momento por login y usuario (portal web) o, entregados a cada una de las compañías emisoras de facturas electrónicas para que las integren directamente en sus sistemas de facturación.
  • En algunos casos se usan empresas certificadoras que cumplen la función de intermediarios entre las personas jurídicas y la institución de gobierno. En este caso, serían ellas las que cuenten con los tokens de acceso hacia los servicios de recepción de Factura Electrónica y es posible limitar o inhabilitar la entrada mediante Portal Web. Depende de la estructura que proponga el gobierno a sus contribuyentes.
  • AWS API Gateway permite hacer seguimiento del número de llamadas a las APIs, latencia, tasas de errores mediante el servicio de monitoreo de AWS Cloudwatch. Con este punto de entrada, no solamente se permite un acceso seguro, autenticado y cifrado sino, además, controlado para un rápido debugging en caso de ser necesario.
  • Algunas instituciones eligen tener distintos puntos de entrada, dependiendo de la persona jurídica emisora de las facturas electrónicas. Esto quiere decir que generan varios API Gateways para proveer un punto exclusivo de recepción dado el volumen que genera una única compañía, brindando acceso exclusivo para esta o un conglomerado de empresas, y otros puntos masivos. Luego de la recepción, se envían los datos a la misma cola de mensajes para procesamiento. Se sugiere evaluar los límites por defecto del servicio de AWS y solicitar un incremento si es necesario.
  • Finalmente, hay una cola de mensajes asegurando que cada Factura Electrónica sea procesada. Amazon Kinesis Data Streams captura y realiza la ingesta de información en tiempo real generada desde los gateways de entrada, permitiendo almacenarla hasta por 7 días mientras un recurso de cómputo los procesa (estos consumidores se detallaran en las siguientes secciones). Este servicio administrado por AWS permite reducir los puntos de fallo y adaptarse a los recursos disponibles después de este paso. Es posible adaptar un esquema híbrido, en el cual AWS Cloud reciba las facturas electrónicas y, luego sean procesadas de forma local con recursos on-premises, sin sobrecargarlos o generar fallas en la disponibilidad del servicio. Todos los datos puestos en Kinesis Data Streams pueden ser cifrados por llaves generadas en AWS o por llaves importadas mediante la integración con AWS Key Management Service.

Desde Cloudfront hasta Kinesis Data Streams se cuenta con funcionalidades de monitoreo desde AWS Cloudwatch. Puede tenerse una granularidad hasta de un minuto y generación de alarmas que envíen notificaciones por medio de mensajes SMS, email o integraciones hacia servicios como Slack o Amazon Chime que habiliten un monitoreo proactivo y casi en tiempo real para corregir posibles cuellos de botella o fallas en general.

Procesamiento

Los archivos de Factura Electrónica pueden ser procesados en tiempo real o de forma masiva. Generalmente estos archivos tienen formato .xml o .json y se recomienda almacenar los originales para auditorias posteriores. Para esto se puede usar Amazon Kinesis Data Firehose, un servicio de encolamiento especializado en recibir información y asegurar la entrega a un repositorio (bucket) en Amazon S3, para su resguardo. Este último permite habilitar la opción de cifrado automático para los archivos y, asegurarse de que el bucket cumpla con las metas y objetivos de tratamiento de información que disponga la institución.

En caso de que se haya optado por una opción híbrida y el procesamiento de datos se este haciendo fuera de AWS, on-premises, se puede integrar Kinesis Data Streams Consumer que toma los elementos puestos en la cola de mensajes y sigue un workflow determinado.

Este post propone usar los servicios de AWS aprovechando los beneficios de servicios administrados, como la eficiencia en costos, rendimiento, innovación y eliminación de cargas operativas. Los elementos más importantes a tener en cuenta son:

  • La idea de separar flujos y utilizar colas distintas para procesamiento y almacenamiento, permite involucrar menos lineas de código y delegar esta función a servicios especializados. Kinesis Data Streams se encargará de manejar los mensajes que requieran ser procesados mientras que Kinesis Data Firehose se ocupará de enviar la información hacia un bucket de S3 que tendrá los archivos .xml o .json originales enviados por la organización encargada de la generación de la Factura Electrónica. Esta práctica, permitirá en auditorias posteriores o ajustes al proceso, disponer del archivo original para consulta.
  • Paralelo al almacenamiento del archivo original, el procesamiento puede tener tantas variantes como requiera la ley o normatividad. En el ejemplo, se toma una función que valida los campos enviados y determina que estén dentro de los rangos permitidos, o con variables existentes. Esta función puede usar otros servicios según sea el caso, por ejemplo: integración con Bases de Datos relacionales o no-relacionales, de documentos, etc, o, incluso habilitar algoritmos de Aprendizaje de Máquina que podrían ser entrenados para detectar posibles anomalías en los datos en tiempo real. Esto es posible integrando AWS Lambda, servicio que permite ejecutar código sin la necesidad de aprovisionar o gestionar servidores.
  • Según las necesidades de la propia entidad u organismos de control, se puede requerir transformación sobre los datos entrantes. Estos cambios pueden requerir funciones o ejecuciones de código que exceden los límites de tiempo de una función en AWS Lambda, para lo cuál se sugiere el uso de ECS Fargate, desplegando contenedores que se encargarán de esta tarea. A menudo, las instituciones ya tienen la imagen de docker desarrollada, por lo que pueden hacer uso de la misma sin gestionar clusters de contenedores, delegando esta tarea a AWS.
  • Finalmente, un servicio debe encargarse del almacenamiento. Se recomienda el uso de una función separada para que esta ejecución atómica envíe los datos correspondientes a diversas fuentes de información, según la estructura de cada una. Por ejemplo, se podrá hacer envío hacia una fuente de datos no estructurada para hacer consultas de los últimos seis meses sobre las transacciones generadas, mientras que se puede usar una fuente de datos estructurada para la consulta de históricos. También es importante guardar de manera segura los archivos transformados de Factura Electrónica.
  • En todos los puntos de transferencia de datos y de almacenamiento se recomienda el uso de cifrado. En algunos casos, la regulación exige ciertos parámetros especializados en este cifrado y el manejo de llaves lo que hace necesario un HSM. En AWS se puede recurrir a CloudHSM o AWS Key Management Service (KMS) para incorporar este cifrado en los puntos donde sea requerido, dependiendo de los requerimientos de seguridad de la institución. El ejemplo de este post integra el servicio en la función de persistencia, donde se invoca, y se retornan los datos cifrados.

Puede que su equipo ya cuente con imágenes de docker para la capa de procesamiento. Aproveche al máximo los recursos existentes haciendo uso de ECS Fargate y re-arquitecte a AWS Lambda según sea el caso. Es importante determinar un dimensionamiento correcto entre el número de ejecuciones y el tipo de requerimientos para optimizar rendimiento y costos eligiendo el mejor servicio para su carga de trabajo.

Almacenamiento y Análisis

Luego de completar la ingesta y procesamiento de datos, estos se almacenaran en distintos repositorios que servirán como fuentes de datos para análisis. Los elementos más importantes de la arquitectura de ejemplo son:

  • El almacenamiento de los metadatos de las facturas electrónicas puede ser hecho en una base de datos NoSQL con un campo que apunte al archivo almacenado en un Bucket de S3. Para esto AWS DynamoDB permite almacenar esta información en una única tabla, optimizando por indices generales y locales para acelerar posteriores consultas. Dado el tipo de información que viene en Factura Electrónica es común que se use el identificador de la persona jurídica en conjunto con la fecha de transacción para crear el índice local. Sin embargo, cada cliente podrá ajustar según la optimización que requiera.
  • Luego del almacenamiento y clasificación hay dos tipos de usuarios dentro de las instituciones de impuestos:
    • Generalmente los auditores deben tener acceso a información en tiempo casi-real y hacer consultas puntuales sobre negocios o personas jurídicas en segundos. Por ello, un Lago de Datos ofrece valor al permitir almacenar datos estructurados y no estructurados sobre Amazon S3, combinando múltiples fuentes originadas en nube u on-premises enriqueciendo los datos de Factura Electrónica. AWS Lake Formation es una de las herramientas que permite hacer este tipo de despliegues para que los datos sean consumidos por Athena; este servicio orquesta, despliega y gobierna el ciclo de vida de los lagos de datos. La interfaz resultante permitirá que los auditores realicen consultas usando notación SQL para obtener la información que requieren, o incluso tener un repositorio de consultas predefinidas que aceleren sus investigaciones.
    • Otros usuarios a nivel interno de la institución necesitan resúmenes, más allá del detalle transaccional. Sus consultas varian poco y buscan aplicar filtros de búsqueda. Para cubrir sus necesidades, es posible habilitar Amazon Quicksight y realizar labores de Inteligencia de Negocios mediante tableros de control. Algunos de ellos, podrán tener permisos de autores para crear nuevos reportes según sean sus necesidades y acceder a las fuentes de información integradas en el Lago de Datos.
    • Si se tiene experiencia con otra herramienta de reportes y tableros se puede aprovechar ese conocimiento integrando herramientas de Business Intelligence de terceros usando las fuentes que se han establecido previamente. En el AWS Marketplace están disponibles estas herramientas para consulta.
  • Es ideal activar el cifrado en estos servicios para mantener los datos seguros en almacenamiento y en tránsito En cuanto a las herramientas de consulta, deben establecerse los roles (AWS Identity and Access Management) adecuados para que cada uno tenga los permisos acotados a los datos que necesita cada uno de los usuarios. En Quicksight incluso se pueden segmentar las fuentes a las que tiene acceso el usuario final para consulta. Se hace necesario pensar en la mínima cantidad de permisos e información para el trabajo de dicho usuario y acotarlas a ese monto.

Clientes con soluciones de Factura Electrónica

Entre las más de 6500 agencias, AWS ha trabajado con la Secretaría de Administración Tributaria de Guatemala, quienes se dedican a modernizar la administración tributaria, crear eficiencias y minimizar los costos. Mauricio Romero, Consultor de Sistemas de Información y TI de SAT Guatemala, habló sobre la importancia de encontrar el proveedor adecuado de servicios en la nube, la importancia de los microservicios y cómo se enfocan en la contratación de expertos y la capacitación para el futuro.

 


Sobre el Autor

Cristian David Romero es Arquitecto de Soluciones en Amazon Web Services para Sector Público. Cristian ha ayudado múltiples instituciones de Sector Público y Privado en la adopción tecnológica de nube en los últimos 8 años y ha llevado acabo de manera satisfactoria proyectos que marcan impacto social a nivel de ciudadanos y estudiantes alrededor de América Latina.

 

 

 

Revisores Técnicos

Gabriel Paredes es Arquitecto de Soluciones en Amazon Web Services para Sector Público. Gabriel ayuda a múltiples instituciones de educación en Latinoamérica en la adopción tecnológica y mejora de sus servicios estudiantiles.

 

 

 

 

Manuel Cuellar es Arquitecto de Soluciones en Amazon Web Services para Sector Público. Manuel trabaja con organizaciones gubernamentales, no gubernamentales e instituciones de educación en México y el Caribe para facilitar la innovación y adopción tecnológica.