Con Reconocimiento de Validez Oficial de Estudios de la Secretaría de Educación Pública según Acuerdo Número 974226 de la Fecha 25 de Julio de 1997
ELABORACIÓN DE ESTUDIO DE CASO
QUE PARA OTENER EL GRADO DE MAESTRO EN TECNOLOGÍAS DE LA INFORMACIÓN EN LA DIRECCIÓN DE NEGOCIOS
PRESENTA:
Melissa Olivares Santana
Asesor: MTI. Ismael Villegas Ochoa
Ciudad de México, febrero 2023
El presente trabajo lo dedico especialmente a mi esposo, quien siempre me ha brindado su amor y su apoyo, y que sin duda fue un pilar muy importante para lograr la culminación de este proceso; a mi hija, para que tenga un precedente de que se pueden lograr nuestros sueños y metas siempre y cuando nos comprometamos con nosotros mismos, y que sepa que siempre contará conmigo en lo que necesite para lograr los suyos. A mis padres, quienes me educaron y guiaron para siempre buscar crecimiento tanto personal como profesional. A mis amigas, ya que sin su impulso, cariño y apoyo hoy no estaría escribiendo estas dedicatorias, y sin ellas los dos años que estuvimos estudiando no hubieran sido tan amenos y divertidos; a todos los profesores con los que conté a lo largo de la maestría, puesto que con sus enseñanzas y experiencias abrieron mi mente a nuevas formas de hacer y crecer. A mis amigos y compañeros de trabajo, quienes de forma directa o indirecta me apoyaron en mis estudios y en la creación de este trabajo; en general a todo Konesh Soluciones por el apoyo con la información necesaria para incluir en este trabajo y que contara con los elementos necesarios para su elaboración. Y principalmente agradezco a Dios por permitirme vivir esta experiencia, y por poder concluir este sueño que por momentos parecía inalcanzable, pero que hoy es una realidad.
INTRODUCCIÓN................................................................................................................................7
OBJETIVOS DE INVESTIGACIÓN....................................................................................................8
OBJETIVO GENERAL ..........................................................................................................................8 OBJETIVOS ESPECÍFICOS...................................................................................................................8
APARTADO 1 PROBLEMÁTICA.......................................................................................................9
1.1 PROBLEMA DE INVESTIGACIÓN......................................................................................................9
1.2 JUSTIFICACIÓN ............................................................................................................................9
APARTADO 2 MARCO SITUACIONAL ..........................................................................................12
2.1 CARACTERÍSTICAS ORGANIZACIONALES DE KONESH SOLUCIONES................................................12
2.2 IDENTIDAD ORGANIZACIONAL ......................................................................................................13
2.2.1 Estructura organizacional ................................................................................................14
2.3 SERVICIOS QUE OFRECE KONESH SOLUCIONES...........................................................................18
2.3.1 Catálogo de los principales servicios...............................................................................21
APARTADO 3 MARCO REFERENCIAL .........................................................................................37
3.1 FACTURA ELECTRÓNICA EN MÉXICO ...........................................................................................37
3.2PAC (PROVEEDOR AUTORIZADO DE CERTIFICACIÓN)..................................................................38
3.3 ACTUALIZACIÓN FACTURA ELECTRÓNICA – REFORMA FISCAL 2022 ..............................................39
3.4 SERVICIOS WEB.........................................................................................................................42
3.4.1 Tipos de aplicaciones de los servicios web .....................................................................44
3.4.2 Servicios Web SOAP.......................................................................................................45
3.4.3 Servicios Web REST .......................................................................................................50
3.5COMPARACIÓN DE RENDIMIENTO ENTRE SOAP Y REST..............................................................53
3.6 FLUJO DE DATOS Y PROCESO DE EMISIÓN DE UN COMPROBANTE FISCAL DIGITAL POR INTERNET EN KONESH SOLUCIONES .....................................................................................................................55
3.6.1 Infraestructura e implementación.....................................................................................58
APARTADO 4 MÉTODO..................................................................................................................61
4.1 TIPO DE INVESTIGACIÓN.............................................................................................................61
4.2 DISEÑO METODOLÓGICO ............................................................................................................62
4.2.1 Descripción de la muestra ...............................................................................................62
4.2.2Variables y Unidades.......................................................................................................63
4.2.3 Operacionalización de variables......................................................................................63
4.2.4 Análisis cualitativo de las diferencias...............................................................................64
APARTADO 5 ALTERNATIVA DE SOLUCIÓN..............................................................................67
CONCLUSIONES.............................................................................................................................77
REFERENCIAS ................................................................................................................................79
ANEXO A..........................................................................................................................................81
ANEXO B..........................................................................................................................................84
IMAGEN 1 ORGANIGRAMA DE KONESH SOLUCIONES Y ÁREAS INVOLUCRADAS ..........................................17 IMAGEN 2OFERTADESOLUCIONESDE KONESH SOLUCIONES ................................................................19 IMAGEN 3 LOGO SICUMPLE..................................................................................................................23 IMAGEN 4CFDCONNECT.....................................................................................................................26 IMAGEN 5 INTERCAMBIO ELECTRÓNICO .................................................................................................28 IMAGEN 6 LOGO DATZILLA ....................................................................................................................32 IMAGEN 7 ARQUITECTURA DE UN SERVICIO WEB ....................................................................................42 IMAGEN 8 ESQUEMA DE UN SERVICIO WEB SOAP....................................................................................46 IMAGEN 9 EJEMPLO DE MENSAJE SOAP.................................................................................................48 IMAGEN 10ESQUEMA DE UN SERVICIO WEB REST.............................................................................51 IMAGEN 11 EJEMPLO DE UNA ESTRUCTURA EN JSON ...........................................................................53 IMAGEN 12 TIEMPO DE RESPUESTA EN EL CONSUMO DE LOS SERVICIOS WEB 500-1000-1500 VU’S CON
JAVA ..........................................................................................................................................54 IMAGEN 13 RENDIMIENTO EN EL CONSUMO CON JAVA............................................................................54 IMAGEN 14 SIMBOLOGÍA UTILIZADA EN EL DIAGRAMA DE PROCESO DE TIMBRADO DE CFDI.......................55 IMAGEN 15 DIAGRAMA DE FLUJO DE DATOS PARA EL TIMBRADO DE UN CFDI...........................................56 IMAGEN 16 DIAGRAMA DE FLUJO DEL SERVICIO DE TIMBRADO ................................................................57 IMAGEN 17 ARQUITECTURA DEL SERVICIO DE TIMBRADO PRODUCTIVO....................................................58 IMAGEN 18 SECUENCIA DE VALIDACIONES REALIZADAS POR EL SERVICIO DE TIMBRADO ...........................60
IMAGEN 19 GRÁFICA DE TIEMPO PROMEDIO DE TIMBRADO .....................................................................65 IMAGEN 20 GRÁFICA COMPORTAMIENTO TIEMPO DE RESPUESTA ............................................................66 IMAGEN 21WSDL TIMBRADO SOAP KONESH.......................................................................................69 IMAGEN 22 EJEMPLO DE PETICIÓN DE TIMBRADO SOAP........................................................................70 IMAGEN 23 RESPUESTA EXITOSA TIMBRADO SOAP...............................................................................71 IMAGEN 24 RESPUESTA ERROR TIMBRADO SOAP.................................................................................72 IMAGEN 25 EJEMPLO DE PETICIÓN DE TIMBRADO REST ........................................................................72 IMAGEN 26 RESPUESTA EXITOSA TIMBRADO REST...............................................................................73 IMAGEN 27 RESPUESTA ERROR TIMBRADO REST.................................................................................73 IMAGEN 28 DIAGRAMA DE FLUJO DE DATOS PARA EL TIMBRADO DE UN CFDI...........................................75 IMAGEN 29 ACTORES EN EL PROCESO DE EMISIÓN DE CFDIS ................................................................76
Gran parte de la oferta de valor que ofrece Konesh Soluciones, radica en el proceso de emisión y recepción de facturas electrónicas, con el plus que le da el contar con la certificación como Proveedor de Certificación Autorizado por el SAT (Servicio de Administración Tributaria), para dar fe de que los documentos que emiten sus clientes no son apócrifos y que cuentan con la validez que el propio SAT puede dar.
Por lo anterior, en el proceso de timbrado de CFDIs el tiempo es un factor crucial al que se le debe prestar la atención necesaria para que el tiempo de respuesta sea eficiente y eficaz, sobre todo para aquellos clientes que manejan un número mayor a 10,000 documentos timbrados por día. Así pues, con este trabajo se pretende proponer un cambio en el tipo de servicio web que se utiliza para dicho proceso, con la finalidad de optimizarlo para reducir el tiempo de respuesta. Para ello se buscará describir las principales diferencias entre los servicios SOAP y REST.
A continuación, se describirán y detallarán los apartados que componen el presente documento a fin de establecer los beneficios en el rendimiento que puede ofrecer el servicio propuesto.
Es importante señalar que se dispone del permiso para usar la marca de la empresa con el objetivo de presentar y detallar la información necesaria dentro del trabajo, el cual se encuentra en el anexo B al final de este documento.
OBJETIVO GENERAL
Mejorar el tiempo de respuesta del Servicio de Timbrado para los clientes que timbran una mayor cantidad de CFDIs con Konesh Soluciones, mediante el uso de servicios web tipo REST en la emisión de CFDIs v4.0 publicados en la miscelánea fiscal 2022.
OBJETIVOS ESPECÍFICOS
En el siguiente apartado se desarrollará con más detalle la problemática que se presenta dentro del proceso de timbrado de Konesh Soluciones, lo cual daría pie a la pérdida de clientes o prospectos de negocio al no poder cubrir ciertas expectativas de estos.
Las soluciones tecnológicas que utiliza Konesh Soluciones para implementar los requerimientos técnicos para emitir y timbrar los diferentes tipos de comprobantes hacen uso de servicios tipo SOAP, lo que genera que el timbrado de documentos no sea tan rápido como algunos de nuestros clientes esperan, adicional a esto, para realizar una integración directa (consumir el servicio de timbrado sin necesidad de una aplicación intermedia proporcionada por Konesh Soluciones), algunos clientes encuentran compleja dicha integración, ya que se les dificulta el manejo de SOAP y, por tanto, eligen alguna otra opción. Asimismo, cuando se implementan soluciones hechas a la medida para nuestros clientes, las cuales generan el ciclo completo de emisión, tienden a verse un poco lentos cuando manejamos los servicios tipo SOAP; en consecuencia, se propone aprovechar la brecha que los cambios de la reforma fiscal 2022 genera, para mejorar nuestros servicios de timbrado ofreciendo tiempos más competitivos e integraciones más simples.
El presente estudio tiene como objetivo principal mejorar los tiempos de timbrado de Konesh Soluciones, para poder tener una mayor cantidad de documentos
timbrados en un menor tiempo, mediante el uso de servicios web tipo REST, en lugar de SOAP.
Los servicios web son una combinación de protocolos y estándares abiertos que permiten la comunicación entre el cliente y el servidor. Proporcionan una interoperabilidad entre aplicaciones contrastadas. La Transferencia de Estado Representacional (REST) y el Protocolo Simple de Acceso a Objetos (SOAP) son los dos principales servicios web utilizados hoy en día. REST es un estilo arquitectónico, mientras que SOAP es un protocolo subyacente. Ambos servicios tienen algunas ventajas e inconvenientes y es decisión del desarrollador web elegir qué servicio es mejor emplear según sus necesidades.
El estudio se llevará a cabo únicamente en las áreas involucradas con el desarrollo e implementación del timbrado de CFDIs para cubrir con los requisitos que como PAC debe cumplir la empresa Konesh Soluciones, de acuerdo con el Anexo 20 de la Resolución Miscelánea que publica el SAT, con una muestra de 1 cliente corporativo que tiene un gran volumen de documentos timbrados y que además timbra sus documentos con dos PACs, uno de ellos es Konesh; usando como instrumento los archivos log que contienen información del tiempo entre el envío de la petición al PAC de timbrado y la respuesta que este regresa.
Un cliente corporativo es aquel que requiere de una solución a la medida de acuerdo con sus necesidades específicas y particularidades propias, son empresas que cuentan con un ERP (Enterprise Resource Planning) propio para la administración de sus actividades empresariales. Cada cliente cuenta con un volumen de timbrado propio (cantidad de documentos timbrados en determinado tiempo), pueden emitir desde 1000 CFDIs al mes, hasta un aproximado de 250,000 CFDIs diariamente, y esto depende completamente de su operación.
Como se ha mencionado anteriormente, Konesh Soluciones es parte importante para la validación y certificación de los comprobantes que sus clientes emiten a través de sus productos y servicios, por tanto, es de suma importancia conocer quién es Konesh Soluciones para poder entender el impacto que podría tener el hecho de que pierda clientes al no cumplir con los tiempos de timbrado esperados por los clientes, sobre todo aquellos que vienen de grandes corporaciones y que manejan una gran cantidad de documentos, los cuales no se pueden dar el lujo de que su proceso demore días, ya que la ley establece un límite de tiempo de 72 horas después de haber emitido el documento para poder timbrarlo y reportarlo a la autoridad que en este caso es el SAT.
Por tanto, en los siguientes apartados daremos a conocer quién es Konesh Soluciones y su oferta de productos y servicios.
Konesh Soluciones es una empresa 100% mexicana, cuya oferta de servicios se centra en brindar soluciones integrales que permitan crear valor tangible y medible en las organizaciones que deciden hacer equipo con ellos. La empresa tiene 15 años de experiencia en el mercado mexicano, además:
Sus productos y servicios están creados para afrontar implementaciones rápidas con menor costo y sobre todo menor riesgo.
En Konesh Soluciones se tiene la creencia de que la parte más importante y esencial de una organización, son las personas, por ello han adaptado sus productos, servicios y procesos a implementar mejoras en la vida de sus clientes, enfocándose en respetar sus procesos internos y generando proyectos que incentiven la gestión del cambio en las organizaciones.
En Konesh Soluciones creen en la evolución de las organizaciones a partir de las buenas ideas. Por ello, su misión, visión y objetivos están alineados para ofrecer un valor tangible y medible a las empresas que deciden hacer equipo con ellos.
MISIÓN DE LA EMPRESA
En Konesh Soluciones son expertos en tecnología y consultoría especializada en facturación electrónica, intercambio electrónico de documentos y visualización analítica de información.
Su misión es colaborar en la construcción de valor tangible y medible, mediante el uso e implementación de soluciones que integran las cadenas de valor en el ecosistema de negocios de sus clientes.
VISIÓN DE LA EMPRESA
Ser una empresa líder en tecnología de punta y consultoría especializada en Latinoamérica, considerada como socio de negocios y aliado estratégico por nuestros clientes.
La conjunción de la misión y misión de Konesh Soluciones ha permitido el establecimiento de objetivos estratégicos empresariales, buscando como objetivo el mantener relaciones estratégicas de negocio con sus clientes, así como lograr el crecimiento más allá de las fronteras mexicanas.
OBJETIVOS DE LA EMPRESA
Los objetivos que persigue la empresa son:
La filosofía interna de Konesh Soluciones, les ha ayudado a reconocer, a través de los años, que lo más importante de las organizaciones son las personas, por lo que están enfocados en que cada miembro del equipo colabore con miras en generar proyectos exitosos más allá de las peticiones de una sola persona, a través de soluciones no intrusivas ni invasivas, capaces de ser modificadas rápidamente; garantizando la eficiencia del recurso humano al desarrollar soluciones tecnológicas que optimicen el potencial de cada uno de los procesos internos y externos de sus clientes.
Para lograr lo anterior, Konesh Soluciones consta de las siguientes funciones administrativas:
El equipo de gobierno corporativo trabaja de la mano con ventas y consultoría, buscando que cualquier relación con los clientes cumpla con las normas
bajo las cuales la organización debe de regirse y a su vez con recursos humanos, buscando que toda la organización conozca el actuar del día a día.
El equipo de cobranza, pagos / nómina y contabilidad son los encargados de mantener el ingreso para soportar la operación, así como de los pagos a proveedores y/o internos y asegurar que los números están siendo tratados de manera correcta.
Finalmente, el equipo de Bienestar apoya a que el recurso humano en operación tenga una calidad de vida operativa lo mejor posible.
A continuación, se puede observar el organigrama del cómo está constituido hoy Konesh Soluciones. Se muestran en los recuadros de color rojos las áreas que intervienen en los procesos de timbrado de documentos.
PROPUESTA DE IMPLEMENTACIÓN DE SERVICIOS WEB TIPO REST EN KONESH SOLUCIONES PARA MEJORAR LOS TIEMPOS DE TIMBRADO DE DOCUMENTOS CFDI 4.0 PUBLICADOS EN LA REFORMA FISCAL 2022
IMAGEN 1 ORGANIGRAMA DE KONESH SOLUCIONES Y ÁREAS INVOLUCRADAS
En los últimos años, se ha visto como cada vez son más las empresas que están cambiando su estrategia de estar concentradas en el producto o servicio a estar alineadas hacia el cliente. Esto debido, principalmente, a tres factores: evolución de las necesidades de los clientes, la entrada de más competidores y la apertura comercial con otros países.
Los principales retos observados de las empresas que están orientadas hacia el cliente son:
En Konesh Soluciones se integran soluciones especializadas en la cadena de valor de las empresas a través de:
Asimismo, en Konesh Soluciones cuentan con los más altos estándares de seguridad, puesto que, la información de los clientes está debidamente protegida. Cuenta con centros de datos confiables, eficientes y escalables; accesibles desde cualquier parte del mundo, que, al mismo tiempo, mantienen los datos a salvo.
Se ofrecen soluciones a la medida, como se puede observar en la imagen 2.
IMAGEN 2 OFERTA DE SOLUCIONES DE KONESH SOLUCIONES
Actualmente, Konesh Soluciones tiene una cartera de más de 20,000 clientes de los más diversos giros: manufactura, transformación, servicios, telecomunicaciones, retail, turismo, entidades financieras y asociaciones sin fines de lucro.
Cuenta con una red comercial y de servicios presente en 20 de los 32 estados de la República Mexicana y más de 300 colaboradores en todo el país.
Tiene presencia internacional en Colombia, Boston, Massachusetts, y West Palm Beach, Florida. Y proyectos en producción en Brasil, Argentina, Perú, Estados Unidos, Italia, Holanda, entre otros.
Su fuerte es la FACTURACIÓN ELECTRÓNICA, tanto para pequeños como grandes contribuyentes, con la cual se está buscando el posicionamiento de la marca en América Latina.
Facturación electrónica: Integración de los procesos de emisión, envío, recepción, validación, procesamiento y almacenamiento de comprobantes fiscales digitales por internet a ERPs que manejan múltiples razones sociales para cualquier giro de negocio y plataforma de información. Genera documentos con formatos personalizados, adendas y mecanismos interactivos de comunicación con clientes y proveedores. Puede incluir el desarrollo de herramientas complementarias como portales, internos y externos de consulta u descarga de documentos.
México tiene uno de los sistemas de factura electrónica más sofisticados de Latinoamérica. Denominada la factura electrónica localmente como Comprobante Fiscal Digital por Internet, o simplemente CFDI, este fue establecido en México en el 2011, cuando sustituyó al CFD o Comprobante Fiscal Digital. La diferencia entre estos dos tipos de comprobantes que vinieron a sustituir la factura en papel es que el CFDI requiere la validación de un Proveedor Autorizado de Certificación, también conocido como PAC.
Konesh Soluciones fue de las empresas pioneras en contar con la certificación PAC otorgada por el SAT, la cual se obtuvo en el año 2011, y se ha mantenido vigente con el paso de los años, cosa que no ha sido fácil, ya que cada dos años la autoridad renueva esta certificación por lo que la empresa debe estar siempre en cumplimiento con los requisitos mencionados anteriormente, así como con las nuevas disposiciones que la autoridad libere a medida que la facturación electrónica evoluciona y se vuelve más madura.
El SAT emite periódicamente publicaciones técnicas dirigidas a cambiar el contenido de los CFDI. Los esquemas, archivos, guías y otros documentos necesarios para cumplir con el mandato de facturación electrónica son habitualmente actualizados por el SAT, y publicados en el portal de dicha institución.
Hoy en día se tiene vigente la versión 3.3 del CFDI y existen diferentes tipos de comprobantes como lo son Ingresos, Egresos y Traslados, adicionalmente existen comprobantes con complementos para la emisión de recibos de nómina en su versión 1.2; la recepción de pagos en su versión 1.0, complementos de carta porte en versión 2.0. Asimismo, existe la emisión de constancias de retenciones en su versión 1.0.
Como se menciona en la página del SAT (Trámites y Servicios, s/f), a partir del 1 de enero de 2022, se actualizó la versión del CFDI pasando a la versión 4.0, tendrá un periodo de convivencia con la versión 3.3 del CFDI, el cual comprende del 1 de enero al 31 de diciembre de 2022, por lo que, a partir del 1 de enero de 2023 la única versión válida será la 4.0.
Konesh Soluciones ofrece diversos tipos de soluciones y servicios dentro de los que destacan las que mencionaremos a continuación, ya que son el core del negocio de Konesh Soluciones.
PROPUESTA DE IMPLEMENTACIÓN DE SERVICIOS WEB TIPO REST EN KONESH SOLUCIONES PARA MEJORAR LOS TIEMPOS DE TIMBRADO DE DOCUMENTOS CFDI 4.0 PUBLICADOS EN LA REFORMA FISCAL 2022
Facturación y Contabilidad Electrónica
Integración, validación, transformación y distribución de CFDIs (facturas, recibos de nómina, recibos de pago, documentos contables, etc.).
Es a través de sus herramientas CFDConnect (clientes corporativos) y SICumpleCFDConnect (clientes masivos, Pymes) con las que ha logrado el mayor crecimiento dentro de la empresa, esto sumado a la certificación con la que cuenta como PAC, lo cual brinda a los clientes una mayor certeza de que sus documentos fiscales cumplirán con todas las regulaciones propuestas por la autoridad, el SAT.
IMAGEN 3 LOGO SICUMPLE
La solución SICumpleCFDConnect, además de cumplir con la normativa fiscal, atiende de manera integral los procesos de Facturación, Compras, Ventas y Bancos, permitiendo la administración eficiente de su operación.
Permite consultar, imprimir y generar reportes con la información almacenada.
Transfiere los documentos validados a la autoridad tributaria y al cliente.
Procesa la información de los sistemas internos de la organización en una estructura estándar apta para la transferencia.
IMAGEN 4 CFDCONNECT
Intercambio Electrónico y Transferencia Segura
Sistemas personalizados para enviar y recibir información en cualquier formato.
Generación de sistemas personalizados que permiten enviar cualquier tipo de documento en formatos XML, EDIFACT, EDI-X12, EDI-Consent, Binario. Incluye notificaciones automáticas configurables, mail, SMS, HTTPS que dan visibilidad a las transacciones y seguridad a las operaciones.
Sistemas a la medida para crear las bases técnicas, administrativas, tecnológicas y normativas necesarias para el adecuado manejo de la documentación. Acompañamiento a los procesos esenciales de su empresa para facilitar la consulta, conservación y generación de información para la mejor toma de decisiones.
IMAGEN 5 INTERCAMBIO ELECTRÓNICO
Se puede implementar en conjunto con la solución de CFDConnect para tener un ciclo completo tanto en la emisión como en la recepción de documentos, o bien se puede implementar de forma independiente para el intercambio exclusivo de documentos.
PROPUESTA DE IMPLEMENTACIÓN DE SERVICIOS WEB TIPO REST EN KONESH SOLUCIONES PARA MEJORAR LOS TIEMPOS DE TIMBRADO DE DOCUMENTOS CFDI 4.0 PUBLICADOS EN LA REFORMA FISCAL 2022
Business Intelligence – Datzilla Big Data
Transformación de los datos en información y de la información en conocimiento, para optimizar el proceso de toma de decisiones.
La plataforma de BI de Konesh es una herramienta montada en la nube y de alta disponibilidad, que permite recopilar la información de las diferentes fuentes de su empresa, almacenarla, analizarla y presentarla en forma de datos estructurados y no estructurados, de manera sencilla, rápida y precisa. Una herramienta de gran valor para la toma de decisiones.
Análisis y validación de la consistencia de la información contenida en los recibos de nómina, particularmente lo referente impuestos trasladados y retenidos para evitar discrepancias en la información.
Cruce de información fiscal existente. Comparación entre los datos del SAT, los sistemas internos y la información contenida en nuestros timbradores para reducir riesgos.
Auditoría y monitoreo de impuestos pagados, retenidos y trasladados, para garantizar la calidad y certeza de la información que se entrega a la autoridad.
Confirmación de la congruencia entre las órdenes de compra, las facturas pagadas, las emitidas, las mercancías recibidas y entregadas para definir patrones de venta y compra.
Plataformas que garantizan el adecuado registro del ingreso y previenen la generación de fugas.
PROPUESTA DE IMPLEMENTACIÓN DE SERVICIOS WEB TIPO REST EN KONESH SOLUCIONES PARA MEJORAR LOS TIEMPOS DE TIMBRADO DE DOCUMENTOS CFDI 4.0 PUBLICADOS EN LA REFORMA FISCAL 2022
Aseguramiento del ingreso – Datzilla Big Data
Plataformas que garantizan el adecuado registro del ingreso y previenen la generación de fugas.
Análisis y comparación de los flujos financieros de ingresos y egresos para dar visibilidad a los puntos críticos donde pudiera haber fugas para evitar pérdidas e incrementar los márgenes de utilidad.
Con un enfoque holístico y un completo análisis de la información transaccional, se generan soluciones a la medida para identificar y cuantificar fugas potenciales dentro de las áreas de mayor riesgo de los ciclos de ingresos y egresos, utilizando técnicas estructuradas de análisis, detección, respuesta y prevención.
La solución de Aseguramiento del Ingreso de Konesh utiliza bases de datos pre-agregadas, asegura una rápida disponibilidad para el análisis, reporte y visualización de líneas base y habilita al usuario para rastrear sistemáticamente los casos de pérdidas potenciales, desde la detección hasta la recuperación, haciendo una contribución inmediata a la organización y acelerando el retorno de la inversión (ROI).
IMAGEN 6 LOGO DATZILLA
Datzilla es una plataforma de servicios (software, infraestructura, data, procesos, y comunicaciones) orientada a usuario final que, mediante el análisis de grandes volúmenes de información, patrones y contenidos, permite visualizar, analizar, modelar y comprender el peso de las interacciones entre las diferentes áreas del negocio y entre este y todos los factores externos.
Asimismo, Konesh Soluciones ofrece varios servicios dentro de los que se encuentran:
Consultoría
Evaluación y automatización de actividades, procesos y sistemas con el fin de optimizar la operación y generar eficiencia en su empresa.
PROPUESTA DE IMPLEMENTACIÓN DE SERVICIOS WEB TIPO REST EN KONESH SOLUCIONES PARA MEJORAR LOS TIEMPOS DE TIMBRADO DE DOCUMENTOS CFDI 4.0 PUBLICADOS EN LA REFORMA FISCAL 2022
Gestión de proyectos
Análisis, planeación, organización de recursos y ejecución de cada solución. Estableciendo una comunicación asertiva con los clientes, para lograr el entendimiento de sus procesos, así como la identificación y respuesta a los posibles impactos y riesgos durante el desarrollo e implementación de una solución.
Implementación de diversas técnicas de apreciación del riesgo con metodologías 100% parametrizables que permiten identificar, analizar y evaluar los riesgos en función de los objetivos y alcance de los proyectos.
Creación de sistemas personalizados para generar las bases técnicas, administrativas, tecnológicas y normativas necesarias para el adecuado manejo de la documentación. Identificación de los procesos esenciales en la operación de los clientes para facilitar la consulta, conservación y generación de información que permita la toma de decisiones.
Desarrollo e implementación de técnicas y metodologías que logran minimizar la resistencia al cambio y facilitan la implementación de todo tipo de transformación organizacional, tecnológica y/o procedimental en las empresas.
Las herramientas logran construir y comunicar, de manera eficaz, los beneficios de los procesos de cambio dentro de las corporaciones.
Desarrollo de aplicaciones
Diseño de herramientas que permiten al usuario automatizar tareas complicadas, para las que no existen aplicaciones estándar.
Las soluciones resuelven problemas específicos, por lo que son de rápida implementación y mucho más rentables que las soluciones existentes en el mercado, que incluyen aplicaciones que el usuario paga, pero no necesita.
PROPUESTA DE IMPLEMENTACIÓN DE SERVICIOS WEB TIPO REST EN KONESH SOLUCIONES PARA MEJORAR LOS TIEMPOS DE TIMBRADO DE DOCUMENTOS CFDI 4.0 PUBLICADOS EN LA REFORMA FISCAL 2022
• Gestión de bases de Datos
Las aplicaciones que se desarrollan son escalables y dinámicas, de tal forma que podrán aumentar o disminuir en función de las futuras necesidades de cada cliente.
Servicios PAAS (Platform As A Service)
El modelo de computación en la nube permite a nuestros clientes crear software a medida, utilizando las herramientas desarrolladas por nuestro equipo técnico.
Proveemos los servidores, la red, el almacenaje, los ambientes de prueba y una gran variedad de servicios, dependiendo de los niveles de escalabilidad y mantenimiento que requieran nuestros clientes.
Soporte
Nuestro trabajo continúa aún después de la puesta en marcha de una solución, ayudamos a resolver los retos a los que nuestros clientes se enfrentan después de la implementación.
Estos son los distintos esquemas de soporte que ofrecemos, dependiendo de la necesidad de cada cliente:
Como se pudo observar en este apartado, la oferta de Konesh Soluciones es amplia y vasta, por lo que mantener una buena relación con sus clientes a través de la calidad en sus entregables es de gran importancia para mantener el negocio a flote y seguir creciendo y expandiendo el mercado.
Dentro de la revisión de la literatura que se hizo para el presente estudio, se encontró que existen variedad de definiciones, autores y sitios que hacen referencia sobre lo que se describe a continuación de algunos términos que se considera importante que se conozcan, por tal motivo se hacen solo referencias sobre lo que se logró obtener de información al respecto.
La facturación electrónica básicamente es un esquema de comprobación fiscal. Actualmente, es conocida también como Comprobante Fiscal Digital por Internet (CFDI) y es utilizada tanto por el comprador como por el vendedor como comprobante de una transacción entre ambos, ante las autoridades y en auditorías internas. Esta transacción se realiza de forma digital y no en papel, por tanto, puede ser generada, transmitida y resguardada a través de medios electrónicos.
Cada factura electrónica emitida debe contar con un sello digital (Firma Electrónica Avanzada), el cual comprueba su origen y le da validez ante el Servicio de Administración Tributaria (SAT). Este sello se conforma de una cadena que funciona como un resumen del contenido de la factura, su finalidad también es la de asegurar que una vez firmado o sellado el documento, no pueda ser modificado.
Es importante mencionar que, la facturación electrónica en México se inició en el 2004, cuando el Servicio de Administración Tributaria, mejor conocido como SAT, creó el marco legal que definió la implantación del Comprobante Fiscal Digital. En este mismo año, por primera vez se publica el Anexo 20 de la Resolución de Miscelánea Fiscal (RMF), el estándar técnico definido por el SAT, el cual específica la estructura, forma y sintaxis que deben de contener los Comprobantes Fiscales Digitales.
La obligación general de emitir CFDI está definida en el Código Tributario de México, también conocido como Código Fiscal de la Federación. El artículo 29, párrafo II, exige que los contribuyentes emitan los CFDI usando los formatos establecidos para tal fin por el Servicio de Administración Tributaria (SAT). La regla
2.7.1.2 de la RMF obliga a que los CFDI, y los sellos digitales para los mismos, cumplan con las reglas técnicas establecidas en esa resolución (Factura Electrónica (México) -Cambios regulatorios a la ley, s/f). El hecho de no cumplir con dichas especificaciones convierte en apócrifos los comprobantes y pueden ser motivo de sanción por parte del SAT.
Para que un CFDI sea válido, debe ser debidamente validado antes de su envío a su destinatario. Por lo general, las validaciones de los CFDIs no son realizadas directamente por el SAT (salvo pocas excepciones), sino por los Proveedores Autorizados de Certificación (PACs), por esta razón en el sistema de facturación electrónica en México es indispensable esta figura.
El SAT en su portal web (Proveedores Autorizados de Certificación (PAC´S) Consultas de orientación -Portal de trámites y servicios -SAT, s/f) define que un Proveedor Autorizado de Certificación (PAC) es la persona moral que cuenta con la autorización del Servicio de Administración Tributaria para generar y procesar fuera del domicilio fiscal de quien lo contrate, los comprobantes para efectos fiscales por medios electrónicos y de manera 100% digital.
Una de las actividades que realizan son las validaciones que consisten en revisar la integración del archivo XML, asegurándose que se observa con el estándar tecnológico vigente definido por el SAT, asimismo tiene como obligación, enviar a la autoridad la copia de los CFDIs que validen de sus clientes.
Una vez que el PAC ejecuta todas las validaciones, timbra o certifica el archivo y así este se convierte en una Factura Digital.
Para ser Proveedor Autorizado de Certificación, se debe acreditar una exhaustiva auditoría tanto técnica como jurídica. Técnica para saber que sus aplicaciones y soluciones son realmente seguras de forma operativa, y que cumplen con las expectativas del cliente, contando con una infraestructura adecuada; jurídica para corroborar que todos sus documentos estén en orden. Es importante saber que, para obtener la autorización como proveedor de certificación de CFDI, debes cumplir con los requisitos señalados en el Anexo 1-A de la RMF vigente.
De acuerdo con el portal del SAT (Actualización factura electrónica – Reforma Fiscal 2022 -Factura electrónica -Portal de trámites y servicios -SAT, 2021), los cambios de la factura electrónica a partir del 1 de enero de 2022 son:
FUNDAMENTO LEGAL
Artículos 29 y 29-A del Código Fiscal de la Federación del DECRETO, por el que se reforman, adicionan y derogan diversas disposiciones de la Ley del Impuesto sobre la Renta, de la Ley del Impuesto al Valor Agregado, de la Ley del Impuesto Especial sobre Producción y Servicios, de la Ley Federal del Impuesto sobre Automóviles Nuevos, del Código Fiscal de la Federación y otros ordenamientos.
En la guía de llenado publicada por el SAT (Anexo_20_Guia_de_llenado_CFDI.pdf, s/f, p. 3) se establece que el artículo 29-A del Código Fiscal de la Federación (CFF) establece los requisitos que deben contener los Comprobantes Fiscales Digitales por Internet (CFDI), en relación con lo establecido en el artículo 29, fracción VI del citado Código, dichos comprobantes deben cumplir con las especificaciones que, en materia de informática, determiné el Servicio de Administración Tributaria (SAT), mediante reglas de carácter general.
Expedir CFDI, es una obligación de los contribuyentes, personas físicas o morales, de conformidad con los artículos 29, párrafos primero y segundo, fracción IV y penúltimo párrafo del CFF y 39 del Reglamento del CFF, en relación con la regla 2.7.5.4., y el Capítulo 2.7.“De los Comprobantes Fiscales Digitales por Internet
o Factura Electrónica” de la Resolución Miscelánea Fiscal vigente.
Podemos encontrar diversas definiciones sobre lo que es un servicio web, tales como:
El servicio web es un servicio para integrar aplicaciones basadas en la web que utilizan estándares abiertos como el Lenguaje de marcado extensible (XML), el Protocolo simple de acceso a objetos (SOAP), el Lenguaje de definición de servicios web (WSDL) y la Descripción, descubrimiento e integración universales (UDDI) a través de la columna vertebral del protocolo de internet (Haviluddin et al., 2019, p. 783). En la imagen 2 podemos observar la arquitectura de un servicio web.
Un servicio web es un componente software que se comunica con otras aplicaciones codificando los mensajes en XML y enviándolos a través de protocolos estándares de Internet, tales como Hipertexto Transfer Protocol (HTTP). (H. et al., 2019, p. 12)
IMAGEN 7 ARQUITECTURA DE UN SERVICIO WEB
Podemos concluir entonces que los servicios web ayudan a mejorar la flexibilidad de los procesos empresariales para permitir la comunicación entre aplicaciones sin importar el lenguaje o plataforma en que se desarrollen, tal y como lo menciona la empresa IBM (IBM, 2022):
Los servicios web reflejan el enfoque de arquitectura orientada a servicios (SOA) para la programación. Este enfoque se basa en la idea de crear aplicaciones mediante el descubrimiento y la implementación de servicios de red disponibles, o invocando las aplicaciones disponibles para llevar a cabo una tarea. Los servicios web ofrecen inter operatividad, por ejemplo, las aplicaciones de servicios web proporcionan componentes creados en distintos lenguajes de programación para trabajar juntos como si se crearan utilizando el mismo idioma.
PRINCIPIOS DE FUNCIONAMIENTO DE LOS SERVICIOS WEB
De acuerdo con la revista CUEPE (Cortés, s/f), existen algunos principios para el funcionamiento de los servicios web, los cuales deben tenerse presentes para poder comprender el funcionamiento del sistema en sí:
Fundamentalmente, hay dos tipos de servicios web:
De acuerdo con la empresa Red Hat (Red Hat, 2019):
REST y SOAP son 2 enfoques diferentes para la transmisión de datos en línea. Específicamente, ambos definen cómo construir interfaces de programación de aplicaciones (API), que permiten que los datos se comuniquen entre aplicaciones web. La transferencia de estado representacional (REST) es un conjunto de principios arquitectónicos. El protocolo simple de acceso a objetos (SOAP) es un protocolo oficial mantenido por el World Wide Web Consortium (W3C). La principal diferencia es que SOAP es un protocolo, mientras que REST no lo es. Por lo general, una API se adherirá a REST o SOAP, según el caso de uso y las preferencias del desarrollador.
Existe una nueva tecnología un poco más reciente llamada GraphQL, la cual
es más un tipo de lenguaje de acuerdo con la definición que podemos encontrar en
la página oficial de GraphQL (GraphQL, s.f.), que dice lo siguiente:
GraphQL es un lenguaje de consulta para API y un tiempo de ejecución para cumplir con esas consultas con sus datos existentes. GraphQL brinda una descripción completa y comprensible de los datos en su API, brinda a los clientes el poder de solicitar exactamente lo que necesitan y nada más, facilita la evolución de las API con el tiempo y habilita poderosas herramientas para los desarrolladores.
Dado que se puede comunicar incluso con servicios tipo REST, podemos considerarlo como una capa intermedia, para poder interpretar de mejor manera los datos entre un cliente y los servicios web o de base de datos. Por tanto, para el presente estudio, y dado que para Konesh no sería funcional, no se considerará como parte de la solución al problema planteado.
SOAP es una especificación para el intercambio de información estructurada. Como tal, representa la principal forma de comunicación entre los tres actores clave en una arquitectura orientada a servicios (SOA): proveedor de servicios, solicitante de servicio e intermediario de servicios.
De acuerdo con Red Hat (REST vs. SOAP, 2019), SOAP es un protocolo estándar que se diseñó primero para que las aplicaciones creadas con diferentes lenguajes y en diferentes plataformas pudieran comunicarse. Debido a que es un protocolo, impone reglas integradas que aumentan su complejidad y sobrecarga, lo que puede generar tiempos de carga de página más prolongados. Sin embargo, estos estándares también ofrecen cumplimientos integrados que pueden hacerlo preferible para escenarios empresariales robustos.
Cuando se envía una solicitud de datos a una API SOAP, se puede manejar a través de cualquiera de los protocolos de la capa de aplicación: HTTP (para navegadores web), SMTP (para correo electrónico), TCP y otros. Sin embargo, una vez que se recibe una solicitud, los mensajes SOAP devueltos deben devolverse como documentos XML, un lenguaje de marcado que es legible por humanos y máquinas. Un navegador no puede almacenar en caché una solicitud completa a una API de SOAP, por lo que no se puede acceder a ella más tarde sin volver a enviarla a la API, lo cual podría en determinado momento representar una desventaja. En la imagen 8 podemos observar el esquema de un servicio web SOAP.
IMAGEN 8 ESQUEMA DE UN SERVICIO WEB SOAP
Un mensaje SOAP se codifica como un documento XML, que consta de un sobre o envoltorio, que contiene a su vez un elemento cabecero opcional y un elemento cuerpo obligatorio. El elemento de falla, que se encuentra dentro del cuerpo, se utiliza para notificar errores.
A continuación, se detalla un poco más cada uno de los elementos de los que consta un mensaje SOAP:
• Envelope: es el elemento raíz en cada mensaje SOAP y contiene dos elementos hijo, un valor opcional <Header> y un elemento obligatorio <Body>.
En la imagen 9 veremos un ejemplo de un mensaje SOAP.
IMAGEN 9 EJEMPLO DE MENSAJE SOAP
Se utiliza la misma estructura de mensaje SOAP para enviar solicitudes y respuestas entre el cliente y el servicio web.
Como se mencionó anteriormente, el elemento Fault dentro del elemento Body es opcional. Un elemento de falla solo se devuelve si ocurre un error dentro del servicio web. De lo contrario, se devuelven los datos normales del mensaje.
SOAP no especifica cómo llega un mensaje del cliente al servicio web, aunque el escenario más común es a través de HTTP.
De acuerdo con Wallarm (Wallarm, s.f.), las principales ventajas y desventajas que obtendrá un desarrollador de un servicio SOAP son:
REST es un conjunto de principios arquitectónicos adaptados a las necesidades de los servicios web ligeros y las aplicaciones móviles. Debido a que es un conjunto de pautas, deja la implementación de estas recomendaciones a los desarrolladores. De acuerdo con la empresa Red Hat (Red Hat, 2019):
Cuando se envía una solicitud de datos a una API REST, generalmente se realiza a través del protocolo de transferencia de hipertexto (comúnmente conocido como HTTP). Una vez que se recibe una solicitud, las API diseñadas para REST (llamadas API RESTful o servicios web RESTful) pueden devolver mensajes en una variedad de formatos: HTML, XML, texto sin formato y JSON. JSON (notación de objetos de JavaScript) se prefiere como formato de mensaje porque puede ser leído por cualquier lenguaje de programación (a pesar del nombre), es legible por humanos y máquinas, y es liviano. De esta forma, las API RESTful son más flexibles y pueden configurarse más fácilmente.
En el estilo arquitectónico REST, los datos y la funcionalidad se consideran recursos y se accede a ellos mediante identificadores uniformes de recursos (URI), normalmente enlaces en la web. Se actúa sobre los recursos mediante el uso de un conjunto de operaciones simples y bien definidas. El estilo arquitectónico REST restringe la arquitectura a una arquitectura cliente/servidor y está diseñado para usar un protocolo de comunicación sin estado, típicamente HTTP.
Las API, producidas con REST, están listas para presentar la funcionalidad de la aplicación o el sitio web a través de HTTP y son compatibles con verbos HTTP como GET y POST. Como las API REST tienen una interoperabilidad inigualable en la web, se han convertido en la elección principal de muchos.
IMAGEN 10 ESQUEMA DE UN SERVICIO WEB REST
De acuerdo con Oracle (Oracle, 2013), los siguientes principios que fomentan que las aplicaciones RESTful sean simples, livianas y rápidas son:
REST está optimizado para la web. El uso de JSON como formato de datos lo hace compatible con los navegadores.
Acerca de esta notación IBM (IBM, 2022) dice lo siguiente:
JSON (JavaScript Object Notation) es un formato ligero de intercambio de datos. Es fácil para los humanos leer y escribir. Es fácil para las máquinas analizar y generar. Se basa en un subconjunto del estándar de lenguaje de programación JavaScript ECMA-262 3ra edición -diciembre de 1999. JSON es un formato de texto que es completamente independiente del lenguaje, pero utiliza convenciones que son familiares para los programadores de la familia de lenguajes C, incluidos C, C++, C#, Java, JavaScript, Perl, Python y muchos otros. Estas propiedades hacen de JSON un lenguaje de intercambio de datos ideal.
IMAGEN 11 EJEMPLO DE UNA ESTRUCTURA EN JSON
En el estudio realizado por (H. et al., 2019), se realizó un análisis comparativo de datos experimentales con el lenguaje de programación C# y Java, para efectos de lo aplicable dentro de Konesh se tomará la información de Java y solo se considerará la información correspondiente a SOAP y REST. Esta comparación es muy importante porque las pruebas que se ejecutaron consistieron en simular determinadas cantidades de usuarios virtuales consumiendo los servicios, lo cual bien podría ayudarnos con este estudio, ya que sin duda el servicio de timbrado recibe muchas peticiones simultáneas, lo que también afecta el desempeño de este y afecta a todos los clientes, sobre todo a aquellos con mayor volumen de timbrado.
En la siguiente imagen se puede observar cómo el tiempo de respuesta empieza a tener diferencia a partir de 500 usuarios concurrentes.
IMAGEN 12 TIEMPO DE RESPUESTA EN EL CONSUMO DE LOS SERVICIOS WEB 500-1000-1500 VU’S CON JAVA
En la siguiente imagen se observa el rendimiento de los servicios web.
IMAGEN 13 RENDIMIENTO EN EL CONSUMO CON JAVA
Como se observa, REST tiene mucho mejor comportamiento en situaciones de mayor concurrencia, como es el caso de Konesh en su proceso de timbrado de CFDIs, lo que da una idea bastante clara de que se podrá lograr el objetivo planteado para resolver la problemática de este estudio.
Como se ha podido observar a lo largo del marco teórico presentado, hay características muy particulares que pueden marcar diferencia en el uso de servicios web tipo REST y SOAP, aunque claramente no se indica que uno sea mejor que el otro, sino que eso dependerá de los objetivos que se persigan al usarlos y en las necesidades propias de un negocio, como lo puede ser el que persigue Konesh al querer mantener tiempos de timbrado bajos en relación con sus competidores sin perder la seguridad y calidad en el proceso.
DIGITAL POR INTERNET EN KONESH SOLUCIONES
A continuación, en las imágenes 15 y 16 se observa el proceso para realizar el timbrado de un CFDI.
IMAGEN 14 SIMBOLOGÍA UTILIZADA EN EL DIAGRAMA DE PROCESO DE TIMBRADO DE CFDI
En el diagrama de procesos de la imagen 15 se observa que los actores que intervienen son:
(3.3 o 4.0). En caso de que todas las validaciones sean satisfactorias, se genera el timbre. Una vez que el documento ha sido generado, realiza el envío a los servicios de recepción del SAT.
IMAGEN 16 DIAGRAMA DE FLUJO DEL SERVICIO DE TIMBRADO
En la imagen 16 se observa el diagrama de flujo a detalle que ocurre dentro del paquete de software del Servicio de Timbrado.
En la siguiente imagen se muestra la arquitectura general del Servicio de Timbrado en Konesh Soluciones.
IMAGEN 17 ARQUITECTURA DEL SERVICIO DE TIMBRADO PRODUCTIVO
Como puede observarse, se cuenta con dos nodos trabajando en un balanceador de cargas que atienden las peticiones de servicio provenientes de la aplicación gratuita. Esta configuración tecnológica permite crecer los recursos de forma horizontal conforme el volumen de consumo del servicio se incremente o decrecerlos en caso de que la demanda disminuya, también permite realizar adecuaciones al servicio sin interrumpir necesariamente la operación. Todos los dispositivos se encuentran protegidos por un firewall CISCO ASA y un IDS Imperva Web Application Firewall.
El flujo de información ocurre de la siguiente forma:
A continuación, se muestran las validaciones y el orden en el que son ejecutadas por el Servicio de Timbrado.
IMAGEN 18 SECUENCIA DE VALIDACIONES REALIZADAS POR EL SERVICIO DE TIMBRADO
En el caso de que alguna de las validaciones no sea satisfactoria, el procesamiento se interrumpe y se envía el mensaje de error correspondiente al usuario que envió la petición, el servicio funciona de forma síncrona. Las validaciones que se realizan son todas las determinadas por el SAT en el anexo 20 y en la documentación técnica proporcionada en la certificación de PAC.
El presente estudio se desarrolló bajo un tipo de investigación cuantitativa con un alcance comparativo, dado que se busca conocer y establecer las características diferenciadoras entre los servicios de tipo SOAP vs. los servicios de tipo REST con la finalidad de descubrir aquellas que nos ayuden a resolver el problema existente en el tiempo de respuesta del Servicio de Timbrado de CFDIs. Asimismo, el estudio tiene un tratamiento no experimental haciendo uso de información de un proceso existente dentro de la empresa Konesh Soluciones, sobre el cual ya se realizó un cambio de tipo de servicio web, ya que para la recepción de CFDIs v4.0 se tiene implementado el servicio REST y para la recepción de CFDIs v3.3 se tiene implementado el servicio SOAP, con esto se puede tomar dicha referencia en el tiempo de validaciones para impulsar el cambio también en la emisión y timbrado de los CFDIs v4.0 que serán obligatorios a partir del 1 de enero de 2023. Por esta misma razón, la temporalidad es de tipo transversal, ya que la información analizada se centra en un periodo de 3 meses, pues la información podría ser la misma independientemente del tiempo.
En este estudio se usaron 2 archivos log con información correspondiente a la emisión de CFDIs v3.3 de un cliente en un día, los cuales contienen datos que pertenecen a los tiempos de timbrado de Konesh Soluciones, y de un externo para identificar las características en los tiempos de timbrado. Adicionalmente, se cuenta con información de 4 peticiones hacia 2 servicios web para la validación de CFDIs, con la intención de dar un referente de la diferencia en el tiempo de respuesta entre un servicio SOAP y un servicio REST. Los archivos log se pueden consultar en el anexo A, la muestra quedó constituida por 10 archivos log correspondientes a 2 días de procesamiento, de un cliente corporativo que cuenta con dos 2 PACs para el timbrado de documentos.
El tipo de muestreo es de tipo no probabilístico, dado que se utilizó la información contenida en archivos log, de los cuales no se emplea toda la información contenida en dichos archivos, sino que se centra únicamente en el tiempo que se llevó una petición de timbrado, desde la solicitud hasta la obtención de la respuesta; la otra característica que discrimina información a revisar es la cantidad de documentos enviados en dicha petición para tratar de tener una muestra lo más equilibrada posible, todo esto independientemente de si el documento se timbró o no debido a algún error. Asimismo, se tiene la comparación del tiempo de respuesta de dos servicios web para la recepción y validación de CFDIs, uno de los servicios valida CFDIs v3.3 y usa SOAP, este servicio realiza aproximadamente 100 validaciones. El otro servicio valida CFDIs v4.0 empleando REST y ejecuta aproximadamente 125 validaciones.
Las variables consideradas en este trabajo son el tiempo de respuesta en el timbrado/validación de CFDIs como variable dependiente, y el uso de servicios web tipo REST como variable independiente, puesto que, será el elemento que ayudará a tener una mejora de respuesta en el proceso de timbrado de CFDIs v4.0
La unidad de observación que se consideró es el tiempo de respuesta en el timbrado o validación de documentos, y la unidad de registro son los archivos log con los que se logró contar para obtener los tiempos a analizar.
A continuación, se mostrarán las variables que se midieron dentro de este estudio, las cuales son el tiempo de respuesta, que tiene que ver con el tiempo que demora el servicio web desde que recibe una petición hasta que regresa la respuesta correspondiente (error o éxito); y el tipo de proceso que puede ser Emisión (timbrado) y Recepción (validación). Aunque el presente trabajo se centra en el proceso de Emisión, como se ha comentado anteriormente, el proceso de recepción es el que nos puede ayudar a tener ya una pauta en la mejora de rendimiento al usar servicios REST en lugar de SOAP, puesto que en dicho proceso ya se hizo el cambio que se propone en este estudio.
Los indicadores utilizados son básicamente el tiempo en milisegundos que demora una petición en ser procesada, y el tipo de proceso que recibe la petición.
Finalmente, nuestra fuente de información son los archivos log que fueron proporcionados por el equipo correspondiente dentro de la empresa.
PROPUESTA DE IMPLEMENTACIÓN DE SERVICIOS WEB TIPO REST EN KONESH SOLUCIONES PARA MEJORAR LOS TIEMPOS DE TIMBRADO DE DOCUMENTOS CFDI 4.0 PUBLICADOS EN LA REFORMA FISCAL 2022
| Variable | Dimensiones | Indicadores | Fuente de información |
| Tiempo de respuesta | No aplica | Tiempo en milisegundos que duró el timbrado o validación de un CFDI | Archivo log |
| Tipo de proceso | No aplica | Emisión Recepción | Archivo log |
Dentro de este apartado se presentarán los hallazgos obtenidos del análisis de los datos obtenidos de los archivos log recolectados, y de acuerdo con las características que fueron relevantes para el estudio y con la finalidad de observar el tiempo de respuesta del Servicio de timbrado que se maneja en Konesh Soluciones en comparación con otro PAC.
En la gráfica de la imagen 19 se muestra el tiempo promedio, en milisegundos, que se demora el timbrado de 1 documento entre un PAC que comparte servicios con un cliente de Konesh Soluciones y el servicio de timbrado de esta. Como se puede apreciar la diferencia si llega a ser considerable y puede ser determinante para enfocar la carga más grande de documentos hacia el otro PAC y no hacia Konesh, lo que puede derivar en la perdida de transacciones y, por tanto, pérdida de dinero con este cliente.
En la gráfica de la imagen 20 se puede observar el comportamiento de los tiempos de timbrado entre un PAC externo y Konesh para muestras de peticiones de 1 solo documento hacia los servicios de timbrado. Se puede apreciar que los tiempos pueden variar dependiendo de ciertas características de los documentos, como puede ser el tamaño de la factura en cuanto a cantidad de conceptos, o simplemente el tipo de documento, ya que no es lo mismo un CFDI de Factura (ingreso) que un CFDI con complemento de Pago (pago) o un CFDI con complemento de carta porte (traslado); sin embargo, a pesar de esto, el otro PAC mantiene tiempos bajos, con variaciones, pero sin superar los 700 milisegundos.
IMAGEN 20 GRÁFICA COMPORTAMIENTO TIEMPO DE RESPUESTA
Este mismo comportamiento de tiempos se pudo observar en los servicios internos de Konesh que realizan la validación de CFDIs, ya que se tienen implementados ambos tipos de servicios, SOAP para la validación de CFDIs v3.3 y REST para la validación de CFDIs 4.0. Y a pesar de que hay más validaciones dentro de los CFDIs 4.0, en comparación con los CFDIs 3.3, los tiempos en las respuestas se ven mejorados al usar servicios de tipo REST. Además de que para los desarrolladores ha sido más simple la implementación de las soluciones en los clientes que hacen uso de los servicios tipo REST.
De acuerdo con la información analizada, hasta el momento, y las referencias con respecto a la comparación de rendimiento de los servicios que nos interesan para el presente estudio, se puede determinar que los servicios REST tienen un mejor desempeño que los servicios SOAP. A continuación, se presenta una tabla interpretativa de las diferencias principales entre un servicio y otro.
| SOAP | REST |
| Es un servicio muy restrictivo, ya que emplea XML como único formato para la transmisión de datos | Es un servicio muy flexible al poder utilizar más de un formato para los datos, tales como texto plano, JSON, XML, HTML, entre otros |
| Requiere de transformaciones para el procesamiento de datos según la solicitud del cliente | No es necesario realizar una transformación para recuperar los datos de la petición |
| Define estándares (reglas y regulaciones) que deben seguirse estrictamente, lo que lo hace difícil de implementar y con mayor probabilidad de tener errores si no se conoce bien | No define estándares estrictos como lo hace SOAP, lo que hace más simple su implementación |
| Por su complejidad, requiere de muchos recursos y ancho de banda, lo cual lo hace tener menor rendimiento que REST | Es muy ligero en cuestiones de recursos y anchos de banda, por lo que su rendimiento suele ser mayor, en comparación con SOAP, logrando llegar al objetivo mucho más rápido |
| Soporta varios protocolos como HTTP, SMTP, FTP, etc. | Solo requiere HTTP para su funcionamiento |
Adicionalmente, como se ha planteado desde el inicio del proyecto, la intención de esta comparativa es poder implementar los servicios REST en el timbrado de documentos CFDI 4.0 en Konesh Soluciones para poder dar mejor tiempo de respuesta a los clientes que tienen un mayor volumen de documentos que procesar y de esta forma agilizar sus procesos y tiempos de entrega de las facturas hacia sus clientes.
Por tanto, se considera que, resultado del análisis realizado, este tipo de servicios puede resultar beneficioso para Konesh y sus clientes, ya que además de que se pueden reducir los tiempos de timbrado, sería posible captar un mayor número de clientes, tanto por las recomendaciones que puede haber por los clientes, como por aquellos prospectos que no necesiten una solución completa de emisión de CFDIs, sino que únicamente buscan la integración con un PAC para poder contar con el timbre necesario para que sus facturas (ya emitidas a través de otro sistema que no sea uno de Konesh) puedan cumplir con las regulaciones que establece la autoridad, el SAT, ya que como hemos visto antes, una de las grandes ventajas de los servicios REST es la facilidad en su implementación por lo cual no se requerirá de cumplir con estrictas reglas y estructuras para poder realizar el timbrado de los documentos.
En cuanto a los cambios que podrían impactar a la arquitectura actual, la gran ventaja es que no cambiaría, ya que en principio solamente cambia la interpretación de los datos que llegan en la petición de timbrado, por lo cual los recursos con los que se cuenta ahora serán suficientes para soportar el cambio propuesto sin necesidad de adquirir algo adicional, generando un costo cero a la empresa.
Para representar el cambio visual que los clientes e integradores que usan o usarían el servicio de timbrado, veremos un ejemplo visual de la petición que se recibe actualmente en SOAP y la propuesta de petición que se estaría recibiendo con REST, así como las respuestas de ambos servicios, tanto para cuando ocurre un error, como para cuando una transacción resulta exitosa.
El request de una petición SOAP para solicitar un timbrado de un CFDI se identifica a través de lo que se conoce como WSDL, del cual se ha hablado anteriormente. A continuación, se presenta un fragmento del WSDL del servicio actual y posteriormente veremos un ejemplo de la petición SOAP mediante el uso de una herramienta que nos permite hacer el llamado manual a los servicios de tipo SOAP.
IMAGEN 21 WSDL TIMBRADO SOAP KONESH
IMAGEN 22 EJEMPLO DE PETICIÓN DE TIMBRADO SOAP
Los parámetros requeridos por el servicio de timbrado están especificados en el WSDL, como se mencionó anteriormente, y son los siguientes:
Si los datos de user, pass, token y cuenta enviados no son correctos, el servicio responderá con un error indicando que la transacción no ha sido autenticada.
El servicio puede tener 2 tipos de respuesta:
IMAGEN 23 RESPUESTA EXITOSA TIMBRADO SOAP
IMAGEN 24 RESPUESTA ERROR TIMBRADO SOAP
El request propuesto para solicitar un timbrado de CFDI al servicio REST es:
IMAGEN 25 EJEMPLO DE PETICIÓN DE TIMBRADO REST
La sección de credentials incluye los datos proporcionados por Konesh para autenticarse en el servicio. La sección issuer incluye el RFC del emisor del CFDI, este RFC debe ser el mismo del atributo RFC del emisor del CFDI. El atributo business es opcional. En la sección document, el atributo format debe tener el valor fijo “xml”, type debe tener el valor fijo “cfdiv4”, operación debe ser el valor fijo “stamping” y en el atributo content debe ser el XML del CFDI para timbrar en formato base64.
En caso de lograr un timbrado exitoso, la respuesta del servicio será como la siguiente:
IMAGEN 26 RESPUESTA EXITOSA TIMBRADO REST
El atributo type incluye el tipo de operación solicitada, en este caso el valor será “stamping”, el atributo transactionId incluye un dato para identificar la traza de la transacción en las bitácoras del servicio, el atributo result incluye un identificar para saber si el proceso fue correcto o no (VALID/INVALID), el atributo uuid incluye el folio fiscal generado para el CFDI, el atributo content tiene el CFDI timbrado en base64, el atributo node es el identificador de la instancia de timbrado que procesó la transacción y el atributo transactionDate es la fecha y hora en que se procesó la petición.
En caso de que el timbrado no se haya generado exitosamente, la respuesta del servicio será como la siguiente:
IMAGEN 27 RESPUESTA ERROR TIMBRADO REST
El atributo result indica si el proceso fue exitoso o no (VALID/INVALID), el atributo stage indica la fase de validaciones donde se detectó el o los errores que impiden el timbrado del documento, message indica si se reporta un solo error o múltiples errores. El atributo error_id incluye un dato numérico para localizar y hacer debugging más rápidamente. El uuid solo se incluye cuando el timbrado es exitoso. La sección de error_details puede contener más de un error en algunos casos. Actualmente, únicamente se pueblan los atributos de message y code con los mensajes de validación definidos por el SAT en las matrices de validación y estándares de CFDI y sus complementos.
En cuanto al flujo de datos que se tendría con los servicios REST, como se mencionó anteriormente, no tendría mayor impacto y, por tanto, quedaría de la siguiente forma:
IMAGEN 28 DIAGRAMA DE FLUJO DE DATOS PARA EL TIMBRADO DE UN CFDI
En la siguiente imagen se podrán observar los actores dentro del proceso y una pequeña descripción del proceso con cada actor.
IMAGEN 29 ACTORES EN EL PROCESO DE EMISIÓN DE CFDIS
Lo que se ha logrado hasta este momento ha sido la recolección de información que permita iniciar la comparativa de rendimiento entre los servicios, para destacar que al implementar servicios tipo REST mejorarán los tiempos de timbrado en los CFDIs v4.0, ya que, como se ha mencionado, este nuevo tipo de documento requiere de nuevas validaciones, se agregan más campos y se integran nuevos tipos de documentos, lo que podría reflejar una afectación en el tiempo de respuesta si se sigue utilizando SOAP. Esto solamente generará afectaciones a los clientes y con ello se generarán repercusiones para Konesh que podrían llegar incluso a la pérdida de clientes y su confianza.
Se espera que con la culminación de este trabajo se pueda lograr tener las herramientas necesarias para comprobar que el uso de nuevas tecnologías, como los servicios web tipo REST, ayudará a la empresa Konesh Soluciones a mejorar el tiempo de respuesta en el Servicio de Timbrado de CFDIs, lo cual logrará mantener y mejorar la confianza de sus clientes generando grandes beneficios como la asignación de nuevos proyectos y la expansión de mercado.
Dado que ya se ha tenido acercamiento al uso de servicios web tipo REST para otros proyectos y otros procesos, tenemos ya los antecedentes de que la implementación es mucho más fácil y rápida en comparación con los servicios web tipo SOAP que se han implementado. Pese a que las interpretaciones son diferentes entre un servicio y otro, se ha notado que no genera mayor complicación hacer cambio de un SOAP a REST en caso de que sea necesario, por lo que se considera que al cambiar el timbrado mediante servicios REST en definitiva logrará una mejoría significativa en los tiempos de implementación como en los tiempos de procesamiento de timbrado, ya que como se ha mencionado anteriormente, no será necesario hacer una interpretación adicional al request que llegue al servicio, sino que simplemente se mapearán los datos y se procesarán con normalidad, haciendo los tiempos más efectivos y que esto se pueda ver reflejado en las respuestas que reciben los clientes, tanto de error como de timbrado exitoso.
Actualmente, dentro de la empresa se tiene planeado liberar a pruebas una versión de la propuesta hecha en el presente caso de estudio para poder analizar con más detenimiento el tiempo de respuesta y que se vea comprobada la teoría planteada en este documento, la fecha tentativa de liberación es a mediados de febrero de este año, para su posible liberación a producción a mediados o finales de marzo y que pueda estar a tiempo para su uso a inicios de abril y cumplir así con la fecha límite que establece la autoridad, el SAT, para poder emitir documentos CFDI v4.0 y dejar de lado la emisión de documentos CFDI v3.3.
Actualización factura electrónica – Reforma Fiscal 2022—Factura electrónica— Portal de trámites y servicios—SAT. (2021, diciembre). https://www.sat.gob.mx/consultas/43074/actualizacion-factura-electronica--reforma-fiscal-2022
Anexo_20_Guia_de_llenado_CFDI.pdf. (s/f). Recuperado el 31 de marzo de 2022, de http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/Anexo_ 20_Guia_de_llenado_CFDI.pdf
Cortés, D. (s/f). ¿Qué son los servicios web? Ceupe. Recuperado el 31 de marzo de 2022, de https://www.ceupe.com/blog/que-son-los-servicios-web.html
Factura Electrónica (México)—Cambios regulatorios a la ley. (s/f). Sovos SSA. Recuperado el 30 de marzo de 2022, de https://sovos.com/es/iva/reglasfiscales/mexico-facturacion-electronica/
GraphQL. (s.f.). GraphQL. Obtenido de GraphQL: https://graphql.org/
H., J. P. S., C., E. L. F., & Recalde, A. (2019). Análisis Comparativo entre los Estándares Orientados a Servicios Web SOAP, REST y GRAPHQL: Comparative Analysis between Standards Oriented to Web Services SOAP, REST and GRAPHQL. Revista Antioqueña de las Ciencias Computacionales, 9(2), 10–22. https://doi.org/10.5281/zenodo.3592004
Haviluddin, H., Budiman, E., & Hidayat, N. F. (2019). A Database Integrated System Based on SOAP Web Service.: EBSCOhost. TEM Journal, 8(3), 782–787. https://doi.org/10.18421/TEM83-12
IBM. (14 de marzo de 2022). Servicios web. Obtenido de https://prod.ibmdocsproduction-dal-6099123ce774e592a519d7c33db8265e-0000.ussouth.containers.appdomain.cloud/docs/es/was-nd/9.0.5?topic=servicesweb
IBM. (07 de 06 de 2022). Formato JSON (JavaScript Object Notation). Obtenido de https://prod.ibmdocs-production-dal6099123ce774e592a519d7c33db8265e-0000.ussouth.containers.appdomain.cloud/docs/es/baw/20.x?topic=formatsjavascript-object-notation-json-format
Konesh Soluciones. (2021). SGSI-DOC-04-01 Contexto del negocio.
Oracle. (2013). What Are RESTful Web Services? Obtenido de https://docs.oracle.com/javaee/6/tutorial/doc/gijqy.html
Proveedores Autorizados de Certificación (PAC´S)—Consultas de orientación— Portal de trámites y servicios—SAT. (s/f). Recuperado el 30 de marzo de 2022, de https://www.sat.gob.mx/consulta/76969/proveedores-autorizadosde-certificacion-(pac%C2%B4s)
Red Hat. (8 de abril de 2019). REST vs. SOAP. Obtenido de https://www.redhat.com/en/topics/integration/whats-the-difference-betweensoap-rest
REST vs. SOAP. (2019, agosto 9). https://www.redhat.com/en/topics/integration/whats-the-difference-betweensoap-rest
Trámites y Servicios. (s/f). Recuperado el 31 de marzo de 2022, de http://omawww.sat.gob.mx/tramitesyservicios/Paginas/anexo_20_version33.htm
Wallarm. (s.f.). Differences SOAP Vs REST API. Obtenido de https://www.wallarm.com/what/differences-soap-vs-rest
Archivos log utilizados para el análisis del presente estudio.
ANEXO B