Facturación Electrónica al SRI para Agentes de IA: Firma XAdES-BES y SOAP

SRI_GATEWAY: CONNECTED // XADES_SIGNATURE_OK

Integrar la facturación electrónica del SRI en Ecuador suele ser un dolor de cabeza burocrático y técnico. Cuando intentas que un agente de Inteligencia Artificial (como un bot de WhatsApp o un orquestador local) emita facturas, el problema se multiplica: los LLMs no pueden lidiar de forma nativa con firmas digitales complejas ni con peticiones SOAP.

La solución que implementé en mcp-sri consiste en desacoplar por completo estas responsabilidades en un servicio modular stateless.

El Problema de la Firma XAdES-BES

El SRI exige que cada factura electrónica sea firmada digitalmente usando un certificado PKCS#12 (.p12) bajo el estándar XAdES-BES (XML Advanced Electronic Signatures). Esto implica:

• Generar una estructura XML en formato estricto SRI v2.1.0.
• Firmar utilizando algoritmos de criptografía asimétrica (usualmente RSA-SHA256).
• Mantener la integridad de los namespaces y canonicalización del XML.

Hacer esto directamente en Python con librerías nativas es propenso a fallos debido a incompatibilidades de dependencias de criptografía y formateo de firma XML en sistemas operativos no alineados.

La Arquitectura de Firma Desacoplada

Para garantizar estabilidad radical, decidí separar el proceso en un microservicio de firma basado en Java (utilizando Apache Santuario y Bouncy Castle) y un servidor MCP basado en Python que expone las herramientas al agente.

[Agente IA]
    │
    ▼ (Generar XML v2.1.0)
[mcp-sri (Python)] ───► [Microservicio de Firma (Java)] (Lee certificado .p12)
    │                                 │
    │ ◄───────────────────────────────┘ (Retorna XML Firmado XAdES-BES)
    ▼
[SOAP Recepción / Autorización SRI]

1. Generación del XML y Clave de Acceso

El servidor MCP en Python toma los datos de entrada estructurados (ítems, cliente, montos) y construye el XML base. Al mismo tiempo, genera la clave de acceso de 49 dígitos requerida por el SRI usando el algoritmo de módulo 11.

2. Firma XAdES-BES Determinista

El XML sin firmar se envía mediante una petición HTTP POST al microservicio Java en local. Este servicio carga el certificado .p12 desde memoria/disco, realiza la firma digital precisa y devuelve el XML completamente firmado y estructurado sin añadir overhead.

3. Transporte SOAP Offline

El SRI expone dos web services basados en SOAP (Simple Object Access Protocol):

• RecepcionComprobantesOffline: Para enviar el archivo firmado.
• AutorizacionComprobantesOffline: Para consultar si el documento fue autorizado legalmente.

El servidor MCP realiza estas peticiones SOAP de forma asíncrona, parseando las respuestas y manejando los reintentos en caso de intermitencia de los servidores del SRI (un problema extremadamente común).

Abstracción para el Agente

Lo potente de este diseño es que toda esta complejidad se reduce a una sola herramienta expuesta al LLM:

{
  "name": "flujo_completo_factura",
  "arguments": {
    "secuencial": "42",
    "tipo_identificacion_comprador": "RUC",
    "identificacion_comprador": "0993396918001",
    "razon_social_comprador": "UPGRADE-EC S.A.S.",
    "email_comprador": "[email protected]",
    "items": [
      {
        "mainCode": "SRV-001",
        "description": "Desarrollo de Agente IA Corporativo",
        "quantity": 1,
        "unitPrice": 1500.00
      }
    ]
  }
}

El agente ejecuta el flujo, y recibe de vuelta el estado definitivo: AUTORIZADO, la clave de acceso, el XML firmado y la representación física RIDE. Ningún parser manual, ningún manejo de SOAP. Ingeniería limpia para habilitar la autonomía financiera de los agentes.