La realidad de integrar AFIP en 2024
Si estás buscando una integración limpia, bien documentada y con SDKs oficiales mantenidos, AFIP no es lo que esperás. La API de servicios web de AFIP es un sistema SOAP de los años 2000 con certificados digitales, ambientes de homologación separados, y errores que a veces no tienen descripción.
La arquitectura de servicios web de AFIP
Para facturación electrónica los servicios relevantes son WSAA (Web Service de Autenticación y Autorización) y WSFEv1. WSAA da tickets de acceso temporales que duran 12 horas. WSFEv1 recibe el XML con los datos de la factura y devuelve el CAE (Código de Autorización Electrónica).
El certificado digital: el primer obstáculo
Necesitás un certificado digital vinculado al CUIT del contribuyente. El proceso: generar un par de claves RSA con openssl, crear un CSR, subirlo al portal de AFIP, y esperar que AFIP emita el certificado. Guardamos el certificado y la clave como secrets en Coolify y los montamos como variables de entorno en formato PEM.
El plugin de arquitectura que elegimos
Implementamos la integración como un plugin independiente con una interface bien definida: emitirComprobante, consultarComprobante, obtenerUltimoComprobante. Internamente el plugin maneja la autenticación, el cache del token WSAA, la construcción del XML y la comunicación SOAP.
Lo que el XML de AFIP no te dice
El campo FchVtoPago es requerido para comprobantes clase B pero no para clase A. Los importes tienen que mandarse con exactamente dos decimales. El error 10016 aparece cuando hay un problema con el certificado de autenticación, no con fechas como dice la descripción.
Cache del token de WSAA
El token de WSAA dura 12 horas pero cada llamada tiene latencia de 300-800ms. Cacheamos el token en memoria: si vence en menos de 10 minutos, lo renovamos preventivamente. En producción, el primer comprobante emitido con un nuevo punto de venta tiene que ser número 1.