Estado: BORRADOR (revisión intensiva 02-sep) · Material de consulta. Todo lo de este anexo ocurre sin que nadie lo pulse (o como efecto colateral no obvio de una acción normal): saber que existe evita buscar fantasmas.
A.11.1 Notificaciones push
| Cuándo llega | Título | A quién |
|---|---|---|
| Te asignan un pedido | «Nuevo pedido asignado» — «Pedido N — cliente» («…DropShipping asignado» si es drop) | Al asignado. |
| Te asignan una preparación | «Nueva preparación asignada» | Al asignado. |
| Alguien completa un picking | «Picking completado» — «{operario} ha completado el picking del pedido N (cliente)» | A todos los Administradores. |
| Alguien completa un packing | «Packing completado» — ídem | A los Administradores. |
| Mensaje de chat | «Nuevo mensaje de chat, {sala}» | Sala General → todos; sala de departamento → ese departamento. |
| Cambio de departamento / solicitud aceptada | «Cambio de departamento» / «Solicitud aceptada» | Al afectado. |
Reglas: el actor nunca se avisa a sí mismo; quien tenga «Recibir notificaciones» apagado no recibe; «Administradores» no incluye a los Responsables. Al completar picking/packing los admins reciben dos avisos (el push del hito + el push del mensaje automático de chat). En la PWA, dos avisos del mismo pedido se pisan (solo se ve el último). Si pulsas una notificación con la sesión cerrada, la app inicia sesión sola con las credenciales recordadas.
A.11.2 Emails automáticos
| Cuándo | Asunto | A quién |
|---|---|---|
| Registrar la expedición (uno por albarán) | «Su albarán N ha sido enviado» | El email del cliente en ALO, con copia interna configurable (avisoEnvioEmails; si no hay, la lista de emails de errores). |
| Reportar un error de artículo en picking | «Error en articulo: {nombre} – Código: {código}» | La lista de emails de errores de Configuración. |
| «Anular sin picking» (según política) | «Su pedido N ha sido anulado» (modo prueba: «[PRUEBA] …») | El email del cliente en ALO (modo prueba: solo la lista interna). Diseño fail-closed: si la anulación en ALO falla, no se envía. |
Así se ven los dos emails que reciben los clientes (maquetas con las plantillas reales de la aplicación y datos de ejemplo — no llevan datos de ningún cliente):
A.11.3 El pedido se mueve solo
- Asignar (primera vez) empuja «En preparación» al ERP y avanza el estado SGA al último obligatorio de la fase inicial. Reasignar no toca el ERP.
- Entrar en picking/packing sella el inicio de fase (evento + estado) para todos.
- El último escaneo del picking de un pedido lo cierra solo: estado, evento, ERP, push y mensaje al chat de Administrador. En packing, el cierre automático solo salta si el albarán ya existe; si no, se habilita «Finalizar».
- El artículo de portes se recoge y empaqueta solo (autor «Sistema») y no entra en el traspaso.
- Al finalizar packing, el empuje de «Servido total/parcial» al ERP corre en segundo plano con un toast de progreso que sobrevive a la navegación.
A.11.4 El ERP manda (y el SGA obedece solo)
Cuando ALO cambia un pedido, el SGA reacciona sin intervención:
| ALO dice | El SGA hace |
|---|---|
| Anulado / finalizado, con trabajo hecho | Soft-close: se sella conservando el trabajo y sale del flujo (y de su preparación). |
| Anulado / finalizado, sin tocar | Se elimina. |
| Servido (parcial/total) | Se retira de su preparación (la preparación «encoge sola»). |
| Bloqueado (5) | Desaparece de picking/packing sin sellarse: si ALO lo desbloquea, vuelve con todo su trabajo intacto. |
| Reactiva un pedido cerrado | Reapertura: vuelve al inicio del flujo y pierde su asignación (incluso se desarchiva del histórico) — hoy en modo sombra, activable por empresa. |
Si esto ocurre mientras trabajas, la pantalla te lo dice («Pedido retirado por ALO», «Pedido cerrado en ALO») — ver Anexo A.3.7.
A.11.5 Archivado al histórico (por horas)
Un proceso horario archiva los pedidos terminados — desaparecen de las listas vivas y quedan en el Histórico (capítulo 17):
- Pedido normal servido: unos días después del albarán.
- Pedido dropshipping servido: en la siguiente pasada (menos de una hora).
- Packing cerrado sin envío finalizado: se archiva en ese mismo plazo, con «Envío completado manualmente».
- Con trabajo en curso no se archiva (salvo 6 h sin ningún evento); un bloqueado nunca se archiva por abandono.
A.11.6 Reconciliadores y sincronizaciones de fondo
- estadoAPI cada 30 min (prod): corrige los estados ALO desincronizados — los badges y contadores pueden «cuadrarse de golpe» sin que nadie toque nada.
- Compras cada 60 min (prod): cierra las entradas que ALO ya no da como pendientes.
- Catálogo cada 30 min: refresca artículos/ubicaciones/códigos (beta se espeja de prod).
- Vigilantes de coherencia y avisos a Teams para los responsables (albaranes, incoherencias, accesos denegados).
- Al detectar una versión nueva de la app, se recarga sola. Si la caché local se corrompe, alerta bloqueante «Datos locales corrompidos» con «Recargar ahora».
A.11.7 Lo que se recuerda solo (y dónde)
Por dispositivo (no viaja contigo a otro equipo): impresora elegida, agente del modal de albarán, rango de fechas de Lista de pedidos, ojo de importes, ayudas/guías ocultadas, explicaciones del informe, empresa seleccionada (auto-entra la próxima vez), sesión (auto-login 24 h) y contexto de picking/packing (sobrevive a un F5). Por empresa (todos los usuarios): emails de errores y toda la Configuración de empresa.
|
← Anterior
|
Siguiente →
|