El tique que no se puede borrar

Casi todo el trabajo de cumplimiento es papeleo que se queda al lado del software. El derecho alemán de cajas registradoras no es así. Entra en el esquema de la base de datos y lo reordena.

La regla es breve. Toda transacción en una caja debe ir firmada por un dispositivo técnico de seguridad certificado — una TSE — y el registro firmado debe sobrevivir diez años, a disposición de la administración tributaria en un formato de exportación prescrito cuando lo pida.

Léala otra vez con ojos de ingeniero. No existe el borrado.

Qué le hace a un diseño el «sin borrado»

Piense en algo corriente: una transacción de prueba. Todo sistema tiene un modo de pruebas, y todo desarrollador ha pasado alguna vez un pedido de prueba por producción para ver si funciona.

Hágalo aquí y el pedido de prueba queda en el registro fiscal una década. No incómodo: permanente. No se puede quitar, porque el sentido del dispositivo es justamente que no se pueda quitar nada.

Así que «pruebas y producción están separadas» deja de ser una convención y se convierte en estructura. En este proyecto un dispositivo de caja declara su entorno como de pruebas o de producción, y una restricción CHECK más un índice único parcial hacen de un solo dispositivo de producción a la vez una garantía que impone la base de datos. No una regla en un manual. No una costumbre. Algo que la base de datos se negará a dejarle hacer.

Esa es la diferencia que marcan los diez años. Normalmente uno escribe la restricción que atrapa el error. Aquí se escribe la restricción que atrapa la década.

Componer desde la especificación, no desde la memoria

La carga fiscal tiene un esquema, y ese esquema está publicado. El cliente, aquí, la compone a partir de la especificación que la propia API sirve, y no del recuerdo de cómo se llamaban los campos.

Suena pedante hasta que se ve la alternativa: un desarrollador que lee la especificación una vez, escribe lo que recuerda y publica. Pasa las pruebas, porque las pruebas se escribieron desde la misma memoria. Falla en la inspección, años después, de una forma que ya nadie puede reconstruir.

Los detalles que solo enseña la producción

Aquí va uno que vale la entrada.

La marca de tiempo de la firma vuelve del dispositivo en el formato que declara el módulo de seguridad, y eso es una propiedad del módulo, no una constante del estándar. El de este proyecto informa unixTime: segundos desde la época, como número. Otro configurado de otra manera bien puede enviar una cadena ISO.

Por eso el código acepta ambos. Nadie diseña eso por adelantado. Se aprende la primera vez que un tique sale con una fecha de 1970, y entonces se anota por qué en el fichero, para que la siguiente persona no lo simplifique de nuevo con la mejor intención.

Escribir para el inspector, no para la batería de pruebas

La exportación lleva el certificado y la clave pública del módulo de seguridad. No porque el formato exija rellenar un campo, sino para que un inspector pueda verificar las firmas sin conexión, contra raíces de confianza, sin pedirle al sistema inspeccionado que responda por sí mismo.

Si se omite, comprobar una firma significa fiarse justo de lo que se está comprobando. El formato lo permite. El sentido del ejercicio no.

Ese principio da forma a la exportación entera. Es un paquete de dieciséis tablas en el orden en que la administración las enumera — datos maestros, luego el cierre diario, luego los registros individuales — y cuando no se puede componer, dice por qué. Un tipo de IVA no congelado, un código de impuesto sin mapear, un número fiscal ausente: cada uno se convierte en un problema anotado en el resultado, y no en una excepción que sube por la pila. La tarea de quien llama es registrar el intento fallido, no caerse. Una exportación que falla en silencio es peor que una que falla.

Por qué esto no es solo un problema alemán

Hacemos el mismo trabajo para la facturación electrónica de Egipto y para ZATCA en Arabia Saudí. Los formatos difieren, las autoridades difieren, los plazos difieren.

La disciplina no. Allí donde el registro sobrevive al software que lo produjo, el registro es el producto — y el código que lo escribe debería ser legible para alguien que lo leerá dentro de años, en medio de una discusión, sin usted en la sala para explicarlo.

Hablemos de un proyecto donde el cumplimiento es crítico