Dos controles para dejar el ticket cerrado en cero.

Un binario, dos saneamientos

El mismo ticket se guarda como un documento JSON en la columna jsonticket de una tabla de SQL Server (por defecto trx). IVAFix lo lee, diagnostica y —solo si se lo pedís— escribe la corrección. El escaneo es siempre dry-run.

El 10,5% que se volvió 11%

La alícuota reducida en Argentina es 10,5%. En algún punto, 10.5 se truncó a 11 y el IVA se calculó como base × 0,11. El 21% no está afectado: ya es entero.

Qué hace con esos 7,24

Como no se puede bajar el total, la diferencia se reinyecta como una línea de ajuste en el mismo ticket — del mismo producto (default) o un ítem exento — y se reconcilian los movimientos. El total queda idéntico; el IVA, bien discriminado.

El portón: "no cuadra"

Después de corregir en memoria, el motor valida dos invariantes: que la suma de componentes dé el total y que la corrección no mueva el ledger. Los PAGO reales traen importes de alta precisión (≈8 decimales) y las VENTA van a 2, así que el ledger original casi nunca es 0 exacto — por eso se valida el cambio, no el cero absoluto (tolerancia 0,005). Si al reducir una VENTA su PAGO no se empareja 1:1 (pago consolidado, anulaciones, promos), el Δ salta y el ticket se marca error: validation y no se escribe.

Cobró, pero el pago no se asentó

En tickets QR a veces el cobro se aprueba pero la sección de PAGO no se graba. Quedan VENTA sin PAGO, el ledger abierto, montoPagado y ordenDePago.monto en 0, pero con "estadoPago":"PAGO_APROBADO" y la orden en PAGADA.

La regla del pago

• Un PAGO por cada VENTA, con movimientoId = id de la VENTA.
• origenId = idGlobalUUID del medio (no el paymentId de Mercado Pago).
• El PAGO espeja el neto a pagar: VENTA + Σ PROMOCION que la apuntan. Las promociones no generan PAGO propio.
• montoPagado y ordenDePago.monto = neto a pagar (totalAPagar.monto), nunca el bruto.
• El portón suma todos los movimientos (incluidas las PROMOCION); deben dar ≈ 0.

El cockpit, en dos modos

Una interfaz web local (solo 127.0.0.1) para conectar, elegir el control, escanear en dry-run, inspeccionar cada ticket y aplicar selectivamente. Esta es una reconstrucción fiel de la pantalla real.

Los gauges y los estados

Dos indicadores de problema fijos — Con IVA mal (modo IVA) y Falta pago (modo PAGO) — más Leídos, Completados y Errores. En la grilla, cada fila trae su estado y el botón { } ver JSON, que abre el documento completo con toggle original / resultado.

En modo PAGO, los QR aprobados salen a completar (seleccionables); los no aprobados salen no aprobado (solo informan, no se tocan).

Compilar y correr

Fat-jar autocontenido (Jackson + mssql-jdbc vía shade). Requiere JDK 17+ y Maven.

# compilar
cd ivafix-tool
mvn clean package        # → target/ivafix.jar

# cockpit (recomendado; única vía para Control PAGO)
java -jar target/ivafix.jar --ui

# CLI del Control IVA — dry-run y luego aplicar
java -jar ivafix.jar --server SRV --db MiBase --user sa --pass *** 
java -jar ivafix.jar --server SRV --db MiBase --user sa --pass *** --apply

Al arrancar con --ui imprime una URL con token (http://127.0.0.1:8742/?t=…). Si refrescás, usá Ctrl+F5. Sin --apply en CLI, nunca escribe.

La API local

Antes de escribir, respalda

Al aplicar (y solo entonces), cada registro se respalda y se actualiza en transacción; si algo falla, rollback de ese registro.

1. Crea (si no existe) trx_jsonticket_bkp con trx_id, jsonticket_original y un hash SHA-256.
2. Por ticket: INSERT del original, UPDATE con el JSON resultante, commit.
3. El motor revalida cada registro en el server antes de tocarlo (doble portón).

Volver atrás

UPDATE t SET t.jsonticket = b.jsonticket_original
FROM trx t JOIN trx_jsonticket_bkp b ON b.trx_id = t.id
WHERE t.id = <id>;