A inicios de agosto armé un pedido de mentira para un cliente ficticio, dejé el modo prueba activado y el proveedor devolvió un comprobante electrónico real y firmado. De las tres cosas, la única que existía ante la Superintendencia Nacional de Aduanas y de Administración Tributaria (SUNAT) era el comprobante. Consumió un número de serie, y esa numeración correlativa que exige SUNAT no se recicla. Era la primera prueba de la integración directa de facturación en LENZ Service, nuestro taller de cámaras. Lo anulé a mano esa misma tarde.
Sacamos el intermediario y confiamos en una bandera
Hasta ese día la facturación pasaba por un servicio intermedio que nosotros mismos habíamos puesto en el camino. Lo sacamos para llamar directo a la API del proveedor y tener un solo lugar donde revisar cuando un comprobante sale mal. El botón de emitir quedó con el modo prueba prendido por defecto, y asumí, igual que el resto del equipo, que esa bandera por pedido decidía si el documento era de verdad.
La API ignoró la bandera y no dijo nada
Lo primero que revisé fue el nombre del campo, convencido de que lo habíamos escrito mal. Estaba bien escrito. La API no devolvió error ni advertencia, y el documento quedó válido ante SUNAT. La documentación lo decía con todas las letras; yo no la había leído. El entorno lo define la configuración de la cuenta del contribuyente, que se cambia a mano en el panel del proveedor, y la nuestra estaba en producción.
Es como escribir "ANULADO, SOLO PRÁCTICA" en el concepto de un cheque y confiar en eso. El banco lee la cuenta y el monto, y paga. Si quieres saber si el cheque es de verdad, llamas al banco y preguntas de qué cuenta salió.
El candado tosco que puse esa noche
La mitigación fue fea a propósito: mientras la configuración local diga "prueba", el código bloquea la emisión por completo. Preferí dejar al taller sin botón unos días antes que arriesgar un segundo documento fiscal nacido de un ensayo.
La v1 trajo dry-run, token e idempotencia
Cuando el proveedor publicó su API v1 cambié el candado por algo con criterio. La v1 tiene un endpoint de dry-run, una emisión en seco que corre todos los validadores sin emitir ni consumir serie. También hay una llamada que valida el token de acceso y responde en qué entorno está esa cuenta. Y las claves de idempotencia ahora son obligatorias: un identificador único por pedido para que un reintento no cree un segundo comprobante.
Esa última parte salió de otra cicatriz. Con la integración anterior emitimos un duplicado real por un timeout ambiguo, de esos donde no sabes si el documento salió o no, y un duplicado solo se corrige con nota de crédito. Ahora la clave se deriva del pedido, siempre igual, y el proveedor la devuelve en los errores ambiguos para que el reintento reuse la misma.
79 de 79 y cero comprobantes creados
Verifiqué la migración completa a v1 contra la API real, con un pago real y sin crear un solo documento fiscal. El proveedor calculó la misma base imponible y el mismo Impuesto General a las Ventas (IGV) que nuestro sistema, y la suite cerró en 79 de 79 pruebas en verde.
Si el proveedor no contesta, el taller no factura
La compuerta depende de que la verificación del token responda. Sin respuesta no hay entorno confirmado, y el sistema bloquea la emisión hasta que el proveedor vuelva. Acepto ese costo. El interruptor de entorno sigue estando en su panel, fuera de nuestro código, y ahí solo podemos mirar.
Antes de cada emisión, el sistema le pregunta al proveedor en qué entorno está la cuenta y lo compara con su propia configuración. Si las dos respuestas no coinciden, no emite nada. El cliente ficticio sigue siendo ficticio, y desde esa tarde sus comprobantes también.
