¶ Documentación técnica — Entrega del 30 de septiembre de 2026
Para quién: soporte y quien instala o configura un local.
Versiones: servicio 18.0.9 → 18.0.15 · aplicación 14.8.0.
¶ Desde qué versión está corregido cada caso
Las versiones son acumulativas: un local en 18.0.15 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 |
|---|---|
| El pedido que no se puede guardar por falta de versión | 18.0.12 |
| Producción Abierta no guarda | 18.0.12 |
| Producción rechaza los productos en gramos | 18.0.13 |
| El abono de reserva que reaparece | 18.0.14 |
| Una sola comanda por impresora (configuración nueva) | 18.0.15 |
¶ Configuración nueva
¶ 🎉 nuevo: Una sola comanda por impresora
Antes. Si varias categorías de un pedido salían por la misma impresora —por ejemplo BARRA,
COCINA y SALA, todas a CAJA—, se imprimía un ticket por categoría, cada uno con su corte, y el mesero
tenía que juntar los papeles.
Ahora. Se puede imprimir todo en un solo ticket, con un solo corte al final.
Cómo se activa. Viene apagado. En app.json, dentro del bloque impresion → pedido que ya
existe, se agrega esta línea y se reinicia el servicio:
"un_solo_ticket_por_impresora": true
Lo que conviene saber:
- El corte sigue a
cortar_papel, que está en ese mismo bloque. Si está entrue, sale un solo
corte al final; si está enfalse, el ticket sale unido y sin corte. - Apagado, todo queda como antes: un ticket por categoría.
- No hace falta actualizar la aplicación al mismo tiempo. Funciona con cualquier versión y no
salen cortes de más.
¶ Lo que soporte va a escuchar de los locales
¶ 🐛 datos asumidos: "Producción no guarda, dice que el egreso es diferente al ingreso"
Pasaba al producir miles de unidades de un producto de costo muy bajo: por ejemplo 8750 gramos de
una mezcla, con un egreso de $16.10. El servidor respondía que el valor del egreso era distinto al
del ingreso, por unos centavos, y no dejaba guardar.
El costo unitario se calculaba redondeado a cuatro decimales, y en productos que se manejan en
gramos eso pierde precisión: $16.10 entre 8750 gramos da $0.00184, que redondeado a cuatro queda en
$0.0018 y al multiplicarlo de vuelta da $15.75 en lugar de $16.10. Ahora se redondea a seis
decimales, que es la precisión con la que la base guarda los costos.
Afecta a todo producto con costo menor a $0.001 por unidad — gramos, mililitros. Solo hay que
actualizar.
¶ 🐛 no-implementación: "Producción Abierta no guarda"
Al registrar un despiece —un egreso que se abre en varios productos, como un lomo que se separa en
dos cortes— el servidor respondía con error y no creaba el ajuste. El local no podía registrar el
despiece y el inventario quedaba desactualizado.
El servidor había dejado de leer la lista de varios productos y solo entendía uno. Ahora vuelve a
aceptarla, el producto marcado con candado toma la diferencia de costo, y si no llega ningún
producto responde un mensaje claro en vez de un error interno. Solo hay que actualizar.
¶ 🐛 datos asumidos: "En Producción aparecen artículos que no debería poder producir"
La lista de "Elije un Artículo" estaba mostrando también los artículos que no controlan
existencia. El problema no es que se vean de más: es que si el local produjo alguno, su materia
prima se descontó dos veces —una al producir y otra al vender el producto terminado, porque la
receta vuelve a descargarla— y el inventario quedó descuadrado.
¶ 🐛 no-implementación: "El ingreso de inventario no se refleja al reiniciar sesión"
El local hacía un ingreso o egreso, lo veía en pantalla, cerraba sesión, volvía a entrar, hacía otro
ingreso, y la existencia se quedaba en el valor viejo hasta sincronizar a mano. Quien no se daba
cuenta repetía el ingreso y descuadraba el inventario.
La existencia nueva llegaba a la aplicación por un aviso en tiempo real, y ese aviso se pierde
cuando la conexión se cae un momento. Como ese mismo aviso adelantaba la marca de sincronización, el
local quedaba pidiendo "cambios más nuevos" que ya se había saltado. Ahora la marca solo avanza con
una sincronización real y, después de un ajuste, la existencia se pide al servidor en lugar de
esperarla por aviso. Solo hay que actualizar.
¶ 🐛 datos asumidos: "Aparece un abono que ya usé"
El local cobraba una mesa usando el abono de una reserva y, al abrir el cobro otra vez, el abono
seguía apareciendo con su monto completo. Al intentar usarlo, el sistema rechazaba la venta diciendo
que el saldo era cero.
Al consumir un anticipo se bajaba el saldo pero el estado seguía marcado como activo, y la consulta
filtraba solo por estado. Ahora devuelve el saldo disponible y descarta los que ya están en cero.
Los anticipos ya consumidos dejan de listarse sin tocar la base: solo hay que actualizar.
¶ 🐛 datos asumidos: "No puedo guardar el pedido, dice que no incluye versión"
El mesero abría un pedido existente, agregaba un producto o entraba a facturar, y al guardar salía
"El pedido no incluye versión. Vuelve a abrir el pedido para obtener la información actual". Volver
a abrirlo no servía: el pedido quedaba bloqueado y no se podía facturar.
Ocurría en locales con la opción "Agregar un Identificador al guardar pedido" apagada y un
equipo con una aplicación anterior al 8 de abril de 2026, que no manda ese dato. El servidor solo
sabía recuperarlo si la opción estaba encendida, aunque el problema no tenía relación con ella.
Ahora lo recupera siempre.
Ya no hace falta encender esa opción como remedio, que era lo que se venía haciendo.
¶ 🐛 datos asumidos: "La factura de 58 mm no dice si estoy obligado a llevar contabilidad"
En papel de 58 milímetros —32 caracteres— la factura imprimía "Obligado a Llevar Contabilidad:" sin
el SÍ ni el NO. La leyenda mide 34 caracteres y se cortaba al centrarla. Ese dato es obligatorio en
el RIDE, así que la factura salía incompleta.
Pasaba lo mismo con la leyenda de agente de retención y su número de resolución. Ahora las leyendas
tributarias se centran solo si caben, y si no, se imprimen completas. Afecta al módulo de impresión
v1. Solo hay que actualizar.
¶ 🐛 no-implementación: "No puedo elegir impresora en el módulo de impresión nuevo"
De qué opción se trata. En printers.json se puede declarar, para facturas, notas de entrega y
pre facturas, varias impresoras entre las que el usuario elige en el momento. Cada uno de esos
tres documentos tiene su clave …_opciones con la lista de impresoras, entre corchetes y cada nombre
entre comillas:
"prefactura_opciones": ["CAJA", "BARRA"],
"factura_opciones": ["CAJA"],
"nota_entrega_opciones": ["CAJA"]
Con eso, al presionar Imprimir una pre factura, se abre un recuadro con un botón por cada
impresora de la lista —CAJA y BARRA— y el documento se manda a la que se elija. Es lo que permite
que la pre factura salga en caja o en barra según quien la pida.
Qué pasaba. El módulo de impresión nuevo nunca implementó ese recuadro: mandaba el documento a
la impresora por defecto y el aviso solo decía "ENVIADO". En locales con varias impresoras en red
todos los documentos salían por una sola, y por eso varios locales seguían en el módulo anterior.
Ahora el módulo nuevo reutiliza el mismo recuadro del módulo anterior. Ya no hace falta quedarse
en el módulo v1 por este motivo.
Un documento sin su clave …_opciones no pregunta nada y se comporta como antes.
¶ 🐛 typo: "La impresión no avisa cuando algo falla"
Si fallaba la carga de los formatos de impresión, no salía ningún aviso: la pantalla no hacía nada y
el usuario no sabía por qué. El mensaje de error existía, pero estaba mal escrito y fallaba al
intentar mostrarse. Ahora el aviso aparece.