Para quién: soporte y quien instala o configura un local.
Versiones: servicio 18.0.15 → 18.0.18 · aplicación 14.8.0.
Las versiones son acumulativas: un local en 18.0.18 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 |
|---|---|
| Todo el paquete de la caída del SRI (seis correcciones) | 18.0.16 |
| Los correos se atascan con un SMTP que no responde | 18.0.16 |
| La factura consolidada se guarda con hora UTC | 18.0.17 |
| La factura consolidada no la autoriza el SRI por diferencia de IVA | 18.0.18 |
Las seis de la caída del SRI se integraron juntas el 4 de octubre: un local con comprobantes
atrapados necesita 18.0.16 como mínimo.
Antes. No había dónde registrar a qué dirección iba un pedido. En los documentos solo salía la
dirección de facturación del cliente.
Ahora. Se registra la dirección de entrega al facturar y sale impresa en la nota de entrega y
la factura. Un cliente puede tener varias direcciones guardadas, reutilizarlas, editarlas o
eliminarlas. Funciona por cuenta: si la mesa se divide, cada factura lleva la dirección de su
propia venta, no la del pedido.
Cómo se activa. Viene apagado. En Configuración > Opciones, se activa "Múltiples
direcciones por cliente en la venta" y se presiona Guardar. Apagado, el campo no aparece, la
aplicación no envía el dato y el servicio no guarda nada.
📖 Guía de configuración y uso, con pantallas
La migración. El bloque 20261007_0845.sql crea la tabla de direcciones y corre sola al
actualizar, como cualquier otro bloque.
Lo que conviene saber al instalarlo:
El sábado 3 de octubre el SRI estuvo en mantenimiento de 05:00 a 21:00, con fallos hasta cerca de
medianoche. Los locales siguieron facturando y los comprobantes quedaron con ae_estado en ERROR
EN ENVÍO, con la hora del intento en ae_ultimoEnvio y su fila en AE_MC_ERROR. Eso es lo
correcto: el intento quedó registrado a tiempo.
El problema apareció el domingo. El barrido horario los recogía, pero la autorización los rechazaba
antes de enviarlos: «La fecha de emisión del comprobante (October 3, 2026) debe ser igual a hoy
(October 4, 2026)». Eso se repetía cada hora durante los 60 días de la ventana y el comprobante
nunca se autorizaba.
Ahora un comprobante de ayer que ya intentó salir —con ae_ultimoEnvio no nulo— se reenvía con
su fecha de emisión y su clave de acceso originales, conforme a la resolución NAC-DGERCGC18-00000233
artículo 9 y la ficha técnica offline v2.34 punto 5.10, que exigen conservar el mismo secuencial y la
misma clave. Uno de ayer que nunca se intentó, o uno de anteayer o anterior, sigue bloqueado a
propósito.
Del mismo episodio salieron cuatro correcciones más:
MC_XML.enviado se quedaba en NULL cuando la autorización se conocía por consulta y no porQué hacer con un local afectado: actualizar a 18.0.16 o superior. El barrido horario recoge los
comprobantes atrapados y los envía con su fecha original. No hay que tocar la base ni refechar nada.
Medido el 4 de octubre en producción: con el SMTP sin responder, cada correo esperaba dos minutos
antes de fallar, y como el envío reintenta una vez, eran unos cuatro minutos por correo. Las tres
conexiones del pool quedaban ocupadas y la cola entera se atascaba. El reenvío de pendientes empezaba
con una verificación que también esperaba dos minutos.
El transporte se creaba sin límites de tiempo propios, así que regían los del paquete: dos minutos
para conectar y diez para el envío. Ahora se fijan 15 segundos para conectar, 15 segundos
para el saludo y 60 segundos de inactividad en el envío. Ese último mide inactividad y no
duración, así que un correo con la factura en PDF sigue saliendo por un enlace lento mientras los
datos fluyan.
Si el local tiene sus propios valores en smtpOptions dentro de app.json, esos mandan. Afecta
a todo local con correo saliente configurado.
Se guardaba con la hora en formato universal, cinco horas adelantada: una consolidación de las 09:18
quedaba registrada a las 14:16. En el listado del día aparecía primero, como si fuera la última
venta, y los reportes por hora quedaban corridos.
Y había un caso peor: al consolidar después de las 19:00 la fecha universal ya era del día
siguiente, así que la fecha de emisión y la clave de acceso salían con otro día. Si se elegía otra
fecha en "Emitido", llegaba con hora 00:00 y la factura quedaba como la primera venta de ese día.
Ahora toma la fecha elegida en "Emitido" y la hora local en que se consolida. Solo hay que actualizar.
El mensaje es: «Hay una diferencia en 'Total Impuestos': valor esperado (3.77) y la sumatoria
(3.747)».
Pasaba al consolidar muchas notas de entrega pequeñas. La cabecera sumaba el IVA ya redondeado de
cada nota, mientras la línea consolidada calculaba el IVA sobre la base total. Con doce notas, seis
de ellas con base 0.78 e IVA 0.117 redondeado a 0.12, la diferencia acumulada superaba el centavo que
el SRI tolera.
Ahora la base gravada se obtiene del total con IVA de las notas y el IVA es la diferencia, así que
siempre cuadra. El total sigue siendo exactamente lo que suman las notas. Afecta a toda
consolidación de muchas notas de monto bajo. Solo hay que actualizar.
El pedido se reabría, la cuenta cargaba con el cliente, pero el abono no aparecía en sus pagos y el
total abonado salía en cero. El cajero no veía lo que el cliente ya había pagado, con riesgo de
cobrarle de más o de registrar el abono otra vez.
El local seleccionaba un cierre, presionaba IMPRIMIR, y no pasaba nada: no se imprimía, no se abría
la ventana y no salía aviso. Ocurría con la impresión automática activada y el módulo de
impresión anterior; el módulo nuevo ya funcionaba.
En el escritorio, al abrir Configuración > Impresoras o al presionar Imprimir en un documento sin
impresora configurada, todas las opciones del selector decían "undefined", así que no se podía
elegir ni configurar ninguna impresora local. Solo hay que actualizar.
Además se listaban todas las formas de pago, incluidas las deshabilitadas y las que no se usan. Ahora
solo aparecen las habilitadas y en uso, ordenadas como en el resto del sistema, y la casilla "Todos"
selecciona todos los consumos. Reportado el 1 de octubre. Solo hay que actualizar.
En la barra inferior de ventas, pedido de mesa y ajuste de inventario: el usuario tocaba la lupa,
escribía, y al tocar otra línea del listado o guardar el teclado la búsqueda se cerraba y perdía el
texto y el filtro. Ahora el cierre automático solo ocurre si el campo quedó vacío; la X sigue
cerrando y limpiando. Solo hay que actualizar.
La columna Cédula salía vacía: el exportador buscaba la clave con una mayúscula distinta a la del
dato. Solo hay que actualizar.
Un cliente lo pidió de vuelta. Esas líneas se habían quitado porque la fórmula anterior de efectivo
restaba todos los gastos, aunque no se hubieran pagado en efectivo. El cálculo correcto se agregó
en su momento solo a la pantalla y nunca volvió al impreso.
Ahora el impreso muestra TOTAL EFECTIVO con el mismo valor que "Efectivo Final" en pantalla, y
TOTAL PAGOS TARJETAS. Solo hay que actualizar.