¶ Entrega del 16 de octubre de 2026
Servicio 18.0.19 → 18.0.21 · Aplicación 14.8.0
Cinco cambios: dos funciones nuevas y tres correcciones, en el manejo de los pagos y en el trabajo con varias computadoras a la vez.
¶ Desde qué versión está corregido cada caso
Las versiones son acumulativas: un local en 18.0.21 tiene todo lo de esta entrega. Esta tabla sirve para cuando un local está en una versión intermedia y hay que decirle hasta dónde subir.
| Corrección | Servicio |
|---|---|
| Los anticipos no se pueden anular desde el arqueo | 18.0.20 |
| PROPINA INTERNA no aparece en el reporte de movimientos | 18.0.20 |
| Permiso CAMBIAR DATOS DE PAGOS (función nueva) | 18.0.21 |
¶ 🎉 Nuevo
¶ 🔐 Permiso para modificar los pagos
Ahora los pagos ya registrados se pueden proteger: solo quien tenga el permiso CAMBIAR DATOS DE PAGOS puede modificarlos.
Dónde aplica:
- Arqueo de caja, al modificar una venta: sin el permiso, los pagos quedan en solo lectura — no se agregan, ni se editan, ni se borran.
- Reservas: los pagos ya hechos quedan bloqueados, pero sí se pueden agregar pagos nuevos.
- Cuentas por cliente: los pagos ya hechos quedan bloqueados.
El permiso llega activado solo para los roles que ya podían cambiar datos de las ventas. Un rol como MESERO, que no podía hacerlo, tampoco recibe este permiso. Desde la configuración de accesos cada local lo ajusta a los roles que quiera.
¶ 🛠️ Para soporte
- No hay nada que activar. La migración
20261015_1310.sqlcrea el permiso en el módulo PERMISOS ESPECIALES y lo asigna a los roles que tienen CAMBIAR DATOS DE VENTAS.
¶ 🖥️ El recuadro de las formas de pago externas ya no recorta el contenido
De qué se trata. Algunos locales cobran con una forma de pago conectada a un sistema de un tercero: tarjeta de consumo, monedero, puntos de fidelización. Al elegir esa forma de pago en el cobro, se abre un recuadro con la página de ese proveedor — el cajero digita ahí el código de la tarjeta, ve el titular y el saldo, y confirma. El caso que corre hoy en producción es el conector de Terravalle.
Qué pasaba. Ese recuadro tenía un alto fijo de 205 píxeles. Si la página del proveedor era más alta —porque muestra varios datos, o un formulario largo—, el contenido salía recortado y el cajero podía no alcanzar el botón de confirmar.
Ahora el proveedor puede indicar desde su página el tamaño que necesita, y el recuadro crece con él sin salirse de la pantalla en equipos pequeños.
¶ 🛠️ Para soporte
- No se configura desde ninguna pantalla: va en la tabla
FORMAPAGOdel local, en las columnasurlConsultayurlConsultaTipo, y lo deja puesto quien instala la integración. Una forma de pago sin esas columnas es una forma de pago normal y no abre ningún recuadro. - Nada que hacer en el local. Si un integrador reporta que su página sale cortada, ya tiene cómo resolverlo desde su lado.
- Las integraciones que no indican tamaño conservan los 205 píxeles de siempre, así que ninguna de las que ya funcionan cambia.
¶ 🐛 Corregido
¶ 🔄 La pantalla de mesas se actualiza sola en las demás computadoras
Cuando se mueve un pedido a otra mesa, o se anula, las demás computadoras que tienen abierta la pantalla de mesas mostraban la mesa nueva ocupada, pero la anterior seguía apareciendo con el pedido. Había que salir de la pantalla de mesas y volver a entrar para verla libre.
Ahora las dos mesas quedan al día solas, sin salir de la pantalla. Vale igual al mover, al anular y al cobrar el pedido.
¶ 🛠️ Para soporte
Cómo se reconoce: hay dos o más computadoras trabajando y una está parada en la pantalla de mesas.
- En la caja se mueve el pedido de la mesa 5 a la mesa 8, o se anula.
- En la otra computadora la mesa 8 aparece ocupada — eso funcionaba bien.
- Pero la mesa 5 sigue mostrándose con el pedido.
- Recién al salir de la pantalla de mesas y volver a entrar, la mesa 5 aparece libre.
Cuando llegaba el aviso de que algo cambió, la pantalla recargaba los pedidos pendientes y marcaba como ocupadas las mesas que los tienen, pero nunca soltaba las que habían dejado de tenerlo. Solo hay que actualizar.
¶ 💵 Los anticipos se pueden anular desde el arqueo de caja
Al intentar anular un anticipo desde el arqueo de caja, salía "Ocurrió un problema de incompatibilidad" y la anulación nunca se hacía. Además, cuando había varios anticipos sin pedido asociado, aparecían agrupados en una sola fila en lugar de uno por uno.
Ahora cada anticipo se lista por separado y se puede anular.
¶ 🛠️ Para soporte
El local entra a Arqueo de caja, busca la fila ANTICIPO RECIBIDO, presiona Anular, y el mensaje sale sin que la anulación llegue al servidor.
La consulta de anticipos del arqueo no devolvía dos datos que la aplicación necesita para anular. A eso se sumaba que el identificador del pedido estaba pisando al del anticipo, de modo que la fila llegaba vacía y todos los anticipos sin pedido se agrupaban en una sola. Reportado el 13 de octubre. Solo hay que actualizar.
¶ 📊 PROPINA INTERNA vuelve a aparecer en el reporte de movimientos
En Reportes > Ventas > Movimientos, al abrir el selector de documentos no aparecía la opción PROPINA INTERNA, aunque hubiera propinas internas en el rango de fechas consultado. No había forma de verlas en ese reporte.
Ahora aparece como opción y sus filas se listan con normalidad.
¶ 🛠️ Para soporte
Venía de una corrección anterior que quitó las propinas internas del cierre de caja —donde salían mal, contadas como ventas anuladas— pero que de paso también las quitó de este reporte, donde sí tenían que aparecer. El filtro del cierre de caja se mantiene; el del reporte se retiró. Solo hay que actualizar.