Estado: BORRADOR (revisión intensiva 02-sep) · Material de consulta.
A.6.1 Cómo nace una devolución
Las devoluciones no se crean a mano ni las empuja el ERP: la app las extrae de los pedidos en memoria — cada línea con unidades negativas genera una devolución (las unidades se muestran en positivo). Consecuencias visibles:
- Las devoluciones nuevas salen de la lista de pedidos ya cargada. 💡 Si esperas una que todavía no ves, pulsa «Recargar» en la cabecera: aparece en la siguiente pasada.
- Cada línea negativa es una devolución independiente (dos comodines 66M del mismo pedido son dos devoluciones).
- Comodines (código
66X): el artículo real se busca en el texto de la nota — el último segmento tras un guion con formadddd…L(p. ej. «…015058M MASCOW…»); si no casa, se muestra el texto libre. Las instrucciones son la línea de comentario inmediatamente posterior a la línea negativa. - Las devoluciones incompletas se hidratan solas desde ALO (una vez por sesión, requiere VPN en beta): la lista se completa a los pocos segundos sin aviso.
A.6.2 Los tres carriles y su regla de cierre
| Carril | Qué contiene realmente |
|---|---|
| Por recibir | Sin recepción confirmada — incluidas las ya abonadas si nadie confirmó la llegada. |
| En almacén | Con recepción confirmada, pendiente de destino del producto. |
| Resueltas | Destino decidido Y parte administrativa cerrada (abono/reposición). Una vez resuelta, no se recalcula. |
La lista es en tiempo real y se organiza en acordeón de dos niveles: cliente → pedido → líneas (así se coteja tal y como llega la mercancía al almacén):
| Nivel | Qué muestra | Detalles finos |
|---|---|---|
| Cliente | Nombre y NIF, nº de pedidos y de líneas, unidades totales (globo rojo). | Con un solo pedido, su nº y fecha se pintan ya en la fila del cliente. La clave de agrupación es el id del cliente en ALO (o el nombre normalizado si falta). |
| Pedido | Nº de documento, estado de venta del ERP con su color real (el del propio ALO), fecha y nº de líneas. | El chip de estado sale del catálogo de estados de venta (referencia del estado). |
| Línea | Imagen y código del artículo, instrucciones de la devolución, unidades. | Pulsar abre el Proceso de Devolución; deslizar → «Ver pedido». |
Lo desplegado sobrevive a las re-emisiones del listener (no se te cierra el acordeón porque
![]()
A.6.3 Proceso de devolución — acciones y efectos exactos
El modelo son dos carriles (la guía en pantalla lo explica): la parte física (producto) y la administrativa (dinero). Si se puede abonar o reponer antes de recibir lo decide el ajuste de empresa «Devoluciones: abonar y reponer solo lo recibido» (campo exigirRecepcionAntesAbono, capítulo 21), con la misma regla para los dos botones: activado, abono y reposición esperan a la recepción y llevan lo recibido; desactivado, los dos carriles son independientes y, sin recepción, se usan las unidades anunciadas. Reintegrar y Devolver a proveedor exigen el abono con cualquier ajuste: el abono es el documento que da de alta el stock en la playa de devoluciones del ERP, y esos dos destinos lo sacan de allí. Configuración que exige cada acción, y su efecto real:
| Acción | Efecto real | Requiere |
|---|---|---|
| Confirmar recepción | Solo traza: unidades recibidas + estado («Recibida VENDIBLE» / «Recibida DAÑADA») y nota. No mueve stock. | — |
| Generar abono | Albarán de abono en el ERP: descuenta al cliente y da entrada al stock en la playa de devoluciones. Unidades: las recibidas; sin recepción y con el ajuste desactivado, las anunciadas (la confirmación dice «Aún no se ha recibido: se abonarán las N unidades anunciadas»). Guarda las unidades abonadas en la devolución. Con 0 recibidas no hay abono. Es la pieza de la que dependen Reintegrar y Devolver a proveedor. | Serie de abono + almacén de devolución (+ recepción previa si el ajuste está activado). |
| Reponer | Abono + pedido de venta nuevo para reenviarle al cliente esas mismas unidades: los dos documentos llevan las mismas, con la regla de «Generar abono» —las recibidas; sin recepción y con el ajuste desactivado, las anunciadas (la confirmación dice «Aún no se ha recibido: se abonarán y se repondrán las N unidades anunciadas»)—. Guarda las unidades abonadas y las del pedido en la devolución. Con 0 recibidas no hay reposición. | Serie de abono + almacén de devolución (+ recepción previa si el ajuste está activado). |
| Rechazar | Cierra la decisión sin documento: tipo «rechazo», con fecha, empleado y motivo, y evento «Devolución rechazada (sin abono)» en el historial del pedido. No crea nada en el ERP. Si llegó género, no se abona: su destino se decide en el carril físico (merma o cuarentena; reintegrar y devolver a proveedor necesitan un abono). | Motivo obligatorio; solo mientras no haya abono ni reposición. |
| Acción | Efecto real | Requiere |
|---|---|---|
| Reintegrar a venta | Traspaso playa de devoluciones → almacén de entrada: el producto vuelve a ser vendible. | Abono previo + almacén de devolución + almacén de entrada + serie de traspaso. |
| Tirar (merma) | Registro de merma con motivo. No crea documento ni mueve stock en el ERP. | Recepción previa (como todas las disposiciones). |
| Devolver a proveedor | Albarán de compra negativo a precio 0 (administración lo valora); el stock sale de la playa de devoluciones. | Abono previo + serie de albarán de compra + proveedor asociado en la ficha ALO («Sin proveedor asociado» si falta). |
| Añadir nota | Va a las observaciones del documento que se genere (abono/reposición). ⚠️ Solo vive en memoria: si cierras sin decidir, la nota se pierde. | Escribirla antes de decidir. |
![]()
- Los botones desaparecen al cerrarse su carril (no se deshabilitan): una devolución abonada ya no muestra «Generar abono».
- Guardas con texto claro: «Falta configuración de empresa» (nombrando los campos), «Primero registra la recepción», «No ha llegado nada que abonar» (o «…que reponer», con la recepción a 0: ofrece «Rechazar»), «Primero genera el abono», «Falta el motivo» (al rechazar sin escribirlo).
- Recepción después del abono o la reposición. Con el ajuste desactivado se puede abonar o reponer antes de recibir. Si luego se confirma la recepción con menos unidades de las abonadas, aparece «Ha llegado menos de lo abonado» («Abonadas 5, recibidas 3: la diferencia (2 ud.) queda en la playa de devoluciones sin género…»); si se repuso, «Ha llegado menos de lo abonado y repuesto» («Abonadas y repuestas 5, recibidas 3…», y el aviso añade que el pedido de reposición lleva al cliente esas unidades de más). La devolución queda marcada (
diferenciaAbono): se ve en el resumen del proceso y debajo de la línea en la lista. No se crea ningún documento en el ERP por esa diferencia: se revisa en ALO. - Éxitos: «✅ Abono generado», «✅ Reposición completada», «✅ Reintegrado a venta», «✅ Devuelto al proveedor». Errores «no se ha creado nada — puedes volver a intentarlo» + detalle del ERP.
- Dos avisos delicados que hay que respetar al pie de la letra: «Abono creado, registro incompleto» (el abono SÍ existe: no regenerar) y «Reposición incompleta» (el abono se creó, el pedido de reposición falló: crearlo a mano en el ERP o avisar a administración).
- La ficha inferior muestra artículo, instrucciones destacadas, cliente/documento/dirección/ vendedor/ruta, «Nota para el documento» y los adjuntos del pedido (ampliables).
- El proceso trabaja sobre la devolución tal como estaba al abrirla. 💡 Para que cada decisión quede como la tomas, que cada devolución la lleve una sola persona a la vez.
- La guía «¿Cómo funciona…?» se recuerda por dispositivo, y su texto sigue el ajuste: con «Abonar y reponer solo lo recibido» activado dice «⚠️ En esta empresa no se puede abonar ni reponer hasta confirmar la recepción»; desactivado, que las dos partes son independientes y que antes de recibir se usan las unidades anunciadas. En los dos casos recuerda que reintegrar y devolver al proveedor esperan siempre al abono. La ayuda bajo «Reponer» también cambia con el ajuste.
A.6.4 Entradas — pedidos de compra
- Buscador libre (nombre o código del proveedor, nº visible «serie/registro» o interno «PC-…», id; y artículos: código, referencia y código de barras siempre; descripción de la línea y descripción ampliada del catálogo si el texto no es solo números; varias palabras = todas en el mismo artículo, en cualquier orden)
- chip de rango de fechas + «Limpiar filtros». No hay filtro por estado del documento.
- La lista se organiza en acordeón de un nivel: proveedor → pedidos (el mismo lenguaje que devoluciones por cliente, con un nivel menos):
| Nivel | Qué muestra | Detalles finos |
|---|---|---|
| Proveedor | Código en pastilla (si lo hay) y nombre; debajo «N pedidos · art. · uds. · kg» y el importe solo para Administrador y Responsable; a la derecha, chip con el nº de pedidos. | Con un solo pedido, la fila dice ya «Pedido: serie/registro · fecha». La clave de agrupación es el id del proveedor en ALO (si falta, el código; si falta, el nombre normalizado): dos fichas con el mismo nombre no se mezclan. Orden alfabético; «Sin proveedor» al final. |
| Pedido | serie/registro, estado del documento, fecha, artículos, unidades, kg (calculados desde el catálogo), importe solo Administrador y Responsable y «fecha prevista de entrada». Sin el proveedor, que ya lo nombra la cabecera. |
Dentro de cada proveedor, el más reciente primero. Pulsar despliega sus artículos (código, descripción, «faltan N de M uds.»); el botón «Recibir» abre la Entrada de almacén. |
- Qué se abre solo: sin filtro, todos los proveedores empiezan cerrados (salvo que haya uno solo, que se abre siempre). Al cambiar la búsqueda o las fechas, los proveedores sin ningún pedido que coincida desaparecen y, si quedan 15 o menos, se abren todos. Lo que el usuario abre o cierra sobrevive a las actualizaciones en vivo de la lista.
- Pedidos con un artículo que casa: se despliegan solos (hasta 30), con la línea resaltada en ámbar y, si casa por código de barras o por descripción ampliada, el motivo debajo. Al borrar la búsqueda vuelve lo que estaba abierto antes de buscar.
- El resumen de la cabecera («filtrados / total» pedidos, art., uds., kg y el importe para Administrador y Responsable) suma todo lo filtrado, no solo los proveedores cargados.
- Pull-to-refresh y scroll infinito de 25 en 25 proveedores.
- Dos pestañas. Pendientes: en tiempo real, solo los pedidos sin cerrar (se piden así a la base de datos: los cerrados no llegan al dispositivo). Los totalmente recibidos salen de ella, también los que se reciben directamente en ALO: la aplicación lo comprueba con ALO cada hora. La lista y el badge del menú cuentan siempre lo mismo.
- Recibidos: los cerrados, sin tiempo real, del más reciente al más antiguo (por número de documento), de 50 en 50 con scroll infinito (la siguiente página del servidor al llegar abajo). Proveedores ordenados por su pedido más reciente (no alfabético): cada página nueva se añade al final, sin saltos. Misma agrupación. Búsqueda: nº de pedido («PC-…» o solo dígitos) y código de proveedor, exactos, en todo el histórico (consulta al servidor 400 ms después de teclear; lo encontrado se suma mientras haya texto); nombre y fechas, sobre lo ya cargado. Filas de solo consulta (se despliegan, pero sin «Recibir»). Estado: «Recibido el dd/mm/aaaa», o «Anulado en ALO» cuando el cierre vino de un anulado. Un pedido que ALO reabre vuelve a Pendientes.
- Búsqueda, pestañas y resumen (en ese orden: el resumen es de la pestaña activa y cambia con ella) quedan fijos arriba al hacer scroll. Color por pestaña: azul Pendientes y verde (el de ALO para «recibido») Recibidos, en la pestaña activa, en la cabecera de cada proveedor (tinte + borde izquierdo) y en el pijama de las filas. Además del color, cada pestaña lleva icono (reloj / doble check) y su contador; el de Recibidos se cuenta en el servidor, sin descargarlos, y el resumen dice «cargados / total». Un filete del color de la pestaña une la pestaña activa con su resumen. Se recuerda la última pestaña usada.
A.6.5 Entrada de almacén (recepción)
- Cabecera: chips de unidades marcadas/disponibles, «Completo / En curso» y barra de progreso. Dos toggles: ocultar procesados y ordenar por ubicación.
- Línea: borde de color (gris/naranja/verde), miniatura pulsable (zoom con el código de barras dibujado), badges «Recibido: N» (esta pasada), «Anterior: N», «Max: N» y «+N sobre pedido» (solo posible con «permitir exceso» activo — es el único aviso de exceso).
- Controles − / nº / + / ✓; la cantidad tecleada se normaliza al salir del campo. Escaneo con
![]()
Recepciones por partes (fascículos) — segunda pasada
- Las líneas ya completas no aparecen (no es el toggle: no están en la lista).
- Las parciales reaparecen con lo anterior en «Anterior: N» y arrancan pintadas de naranja aunque aún no hayas recibido nada nuevo.
- Los totales de cabecera y del resumen incluyen las pasadas anteriores — lo que moverá el albarán es solo la diferencia de esta pasada.
- La pantalla trabaja sobre el pedido tal como estaba al abrirlo: lo cómodo es que cada pedido lo reciba una sola persona. Salir y volver conserva el progreso si el pedido no cambió.
|
← Anterior
|
Siguiente →
Anexo A.7 · Referencia — Rack de pedidos e Informe de operaciones |