Todo era efectivo

En resumen: El ERP registraba como efectivo cada cobro del mostrador de servicio, porque nunca le mandábamos el medio de pago real. Lo arreglamos con una tabla de seis filas y confirmamos la inferencia con una boleta real.

Al cerrar el mostrador de servicio técnico, la caja del ERP (el sistema donde llevamos inventario y facturación) decía que ese día cobramos todo en efectivo. Nadie nos pasó un sol en la mano: la plata entró por POS (el terminal de tarjetas), por link de pago y por Yape. El monto del día coincidía con las ventas, pero el medio de pago estaba mal en todo lo que no fue efectivo.

Quien cuadra la caja al cierre no tiene cómo adivinar eso: tiene que abrir cada boleta, acordarse del cliente y corregir a mano. Me equivoqué yo, porque di por hecho que un campo que la SUNAT (la autoridad tributaria peruana) no exige no le importaba a nadie más.

La boleta no pregunta cómo te pagaron

Para la SUNAT el comprobante distingue dos cosas: Contado y Crédito. Pagues en efectivo, con tarjeta o con un link, el XML que se declara (el archivo que viaja a la SUNAT) es el mismo documento. Esa vista legal estuvo bien desde el primer día.

El cierre de caja responde otra pregunta: por dónde entró cada sol y dónde está ahora. Contestábamos la primera y dábamos la segunda por resuelta.

El ERP llenó el campo vacío por nosotros

Nuestro registro interno de pagos sí sabe la verdad. Cada cobro queda guardado con su método: efectivo, tarjeta, Yape, Plin, Mercado Pago o transferencia. Al emitir la boleta nunca mandábamos ese campo.

El ERP no deja el campo vacío: le pone su valor por defecto, Efectivo, y su módulo de caja archiva como plata en el cajón lo que llegó por POS o por link de pago.

Analogía: un cuaderno al lado de la caja donde el vendedor anota toda venta como efectivo, hasta la que llegó por tarjeta. El total del cuaderno cuadra con las ventas del día, pero el cajón nunca cuadra con el cuaderno y la diferencia no dice de dónde salió.

Seis filas que traducen el método al ERP

El arreglo cabe en una tabla, CONDICIONPAGO_POR_METODO. Traduce cada método de nuestro registro al id de condición de pago del ERP, el código numérico con el que el ERP clasifica de dónde vino la plata. Son seis filas y una búsqueda antes de emitir, sin infraestructura nueva.

El catálogo que el API no quiso darnos

Para llenar esas seis filas necesitaba los ids del proveedor de facturación electrónica, y su API (la puerta por donde un programa le pide datos a otro) no publica la lista de condiciones de pago. Probé 26 nombres plausibles de endpoint, uno por uno, y los 26 devolvieron 404, el código que significa "acá no hay nada". El proveedor da por hecho que vas a elegir la condición a mano en su panel web.

El panel sí lo teníamos. Las condiciones aparecen ahí en una lista ordenada, así que deduje cada id contando su posición. Como el panel nunca muestra el número, cada fila quedó como una suposición.

Gastamos una boleta real en comprobarlo

Emitimos un comprobante real, de una venta real, con el método tarjeta. Salió impreso como POS Culqi (Culqi es una de las pasarelas de pago que usamos), igual que predecía la tabla. Esa boleta convirtió la fila de tarjeta en un hecho verificado; las otras cinco siguen apoyadas en la posición del panel.

Antes, los seis métodos llegaban al ERP como Efectivo, y el efectivo acertaba por casualidad. Ahora la boleta viaja con su condición de pago y la caja se parte en dos: lo cobrado en el cajón y lo depositado en cuenta. El cierre dejó de depender de que alguien recuerde cómo pagó cada cliente.

La fila que seguimos sin poder probar

Queda un hueco. El registro guarda "transferencia" sin el banco asociado, así que todas las transferencias caen en un solo banco por decisión de negocio. Para cuadrar caja importa más acertar el tipo de movimiento (plata que entró a una cuenta, no al cajón) que el nombre del banco. Esa fila está marcada como no confirmada en el código y en la documentación, y se corrige el día que el registro guarde el banco.

Lo que hacemos distinto ahora

Quedaron tres hábitos de este arreglo:

• si nuestro registro interno conoce el medio de pago, ese dato viaja con la boleta aunque la SUNAT no lo pida
• antes de confiar en una inferencia emitimos un documento real: la boleta de tarjeta cerró en un intento lo que 26 endpoints no dieron
• la fila que no pudimos probar queda escrita como no confirmada, igual que en otros módulos mostramos un guion antes que un número que no podemos sostener