Flujo canónico: prealerta¶
Objetivo¶
Permitir al cliente avisar una compra con la mínima fricción posible, incluso antes de recibir tracking.
Forma recomendada¶
Paso 1 — Compra (obligatorio) - Tienda. - Número de orden / referencia. - Fecha de compra. - Categoría aduanera. - Descripción. - Cantidad. - Valor declarado / pagado. - Moneda (default USD).
Paso 2 — Seguimiento (opcional) - Número de tracking. - URL del producto. - Captura del pedido. - Notas para el operador.
Confirmación
- ID demo (REP-XXXX-YYYY).
- Estado canónico inicial.
- CTA: "Ver reporte".
- CTA secundaria: "Añadir tracking después" si quedó reportada_sin_tracking.
Campos que no deben pedirse en prealerta¶
- Decisión de consolidación (preguntar al consolidar).
- Servicios adicionales (preguntar al recibir el paquete).
- Vía de envío (preguntar al consolidar/despachar).
- Destinatario final (preguntar al consolidar, salvo regla operativa aprobada — ver D-206).
Estados resultantes¶
| Condición al confirmar | Estado canónico | Siguiente acción |
|---|---|---|
| Con tracking | reportada |
Mostrar tracking en detalle. |
| Sin tracking | reportada_sin_tracking |
Añadir tracking cuando llegue. |
Manejo de errores¶
- Errores específicos por campo.
- Foco automático al primer error.
- Conservar datos al rotar o salir.
- CTA "Guardar borrador" si existe persistencia; mientras no exista, no prometerla.
Estado actual del prototipo¶
La APK demo crea la prealerta en DemoSessionRepository, la muestra de inmediato en listas y detalle, y conserva el estado durante la sesión. El tracking es opcional; cuando falta, el detalle ofrece el CTA "Añadir tracking después". El mismo detalle incluye una herramienta demo de recepción en almacén para validar la transición posterior sin depender de backend.
La prealerta no solicita vía, destinatario, consolidación ni servicios adicionales. Esas decisiones ocurren al preparar el envío.