Cómo funciona un TPV que vende sin internet

Resumen: las operaciones se guardan en una cola local y se reenvían al volver la red. Los datos comerciales (pagos, líneas de pedido) solo se añaden, nunca se sobrescriben; los datos mutables (estado de mesa) se resuelven por última escritura. Cada terminal reserva por adelantado su propio bloque de numeración fiscal, así nunca hay dos facturas con el mismo número.

Por qué esto importa más de lo que parece

La conexión de un local de hostelería falla más de lo que reconocen los folletos. Un router saturado un sábado noche, una obra en la calle, un corte del operador. En un negocio donde el ticket medio es bajo y el volumen alto, media hora sin poder cobrar es dinero y es cola en la barra.

Muchos TPV en la nube gestionan esto mal: o se bloquean, o guardan los pedidos en una lista que luego hay que reintroducir a mano. Lo segundo es peor, porque parece que funciona.

Paso uno: la cola local

Lo básico es que el terminal no dependa del servidor para operar. Tiene su propia copia del catálogo y de las mesas, y cada acción que realizas —abrir un pedido, añadir una línea, cobrar— se anota en una cola local antes de intentar enviarla.

Si hay red, se envía al instante. Si no la hay, se queda en la cola y se reintenta con espera creciente: primero a los pocos segundos, luego cada vez más espaciado, para no saturar el servidor cuando vuelva.

Paso dos: qué pasa cuando vuelven todos a la vez

Aquí empieza lo interesante. Imagina dos terminales que han estado veinte minutos sin conexión y reconectan a la vez. Cada uno trae su historial. ¿Qué pasa si los dos han tocado la mesa 7?

La respuesta no puede ser la misma para todos los datos, y esa es la clave del asunto:

Datos comerciales (pagos, líneas de pedido): solo se añaden, nunca se sobrescriben. Si el camarero A añadió dos cafés y el camarero B añadió una tostada, el resultado son dos cafés y una tostada. Descartar uno de los dos sería perder una venta real.
Datos mutables (estado de una mesa, si está libre u ocupada): gana la última escritura. Aquí no tiene sentido acumular: la mesa tiene un estado, no cinco.

La propiedad que hay que demostrar: convergencia

La regla anterior no basta con enunciarla; hay que demostrar que se cumple una propiedad concreta: que el estado final es el mismo independientemente del orden en que lleguen los cambios.

Si el terminal A sincroniza antes que el B, o al revés, o los dos a la vez, el resultado tiene que ser idéntico. Si no, tienes un sistema que produce cuentas distintas según el azar de la red, que es la peor clase de fallo: intermitente e imposible de reproducir cuando lo reclamas.

Esa propiedad se comprueba con pruebas automáticas que simulan todos los órdenes posibles de llegada.

Paso tres: la numeración fiscal, que es lo verdaderamente difícil

Todo lo anterior es resoluble con técnicas conocidas. El problema serio aparece con la facturación.

Verifactu exige que las facturas formen una cadena en la que cada una incorpore la huella de la anterior. Si dos terminales emiten sin conexión, ambos creen ser "el siguiente" de la cadena. Al reconectar tienes una bifurcación, y una cadena bifurcada no es válida.

Renumerar después no es opción: cambiaría el contenido de las facturas y, con él, todas las huellas.

La solución: rangos reservados por dispositivo

Cada terminal pide al servidor un bloque de numeración antes de necesitarlo — por ejemplo, del 1000 al 1099 — y esa entrega es atómica: dos terminales nunca reciben rangos que se solapen.

A partir de ahí, cada terminal tiene su propia serie y su propia cadena de huellas, completamente independiente de la del otro. Puede emitir sin conexión durante horas sin colisionar con nadie y sin bifurcar nada, porque nunca estuvo compartiendo cadena.

Cuando vuelve la red, los registros se envían en diferido a la Agencia Tributaria, en orden y sin huecos.

El detalle que evita cobrar dos veces

Falta una pieza. Si un terminal envía un cobro y la red se corta justo antes de recibir la confirmación, el terminal no sabe si llegó o no. Si reintenta, ¿se duplica la venta?

No, si cada operación lleva un identificador único generado por el cliente. El servidor lo comprueba: si ya procesó esa operación, devuelve el mismo resultado sin volver a ejecutarla. Reintentar cien veces produce el mismo efecto que hacerlo una.

Esta propiedad —que repetir una operación no cambie el resultado— es lo que permite reintentar con tranquilidad. Sin ella, cualquier corte de red es un riesgo de cobro duplicado.

Qué preguntar a tu proveedor

Así es como está construido Axon TPV, nuestro punto de venta para hostelería. Está en desarrollo y buscamos locales piloto en Alicante y San Vicente del Raspeig.

¿Qué pasa exactamente si se cae la conexión a mitad de servicio? Pide una demostración desconectando la red.
¿Cómo se evita que dos terminales generen la misma numeración de factura sin conexión?
¿Qué ocurre si un cobro se envía dos veces por un reintento?
¿Puedo exportar mis registros fiscales si cambio de sistema?

Relacionado: Axon TPV