Resolución de Pedidos No Completados en Cencosud

¿Cuándo se ejecuta?

Este comando se ejecuta automáticamente cada 3 horas (8 veces al día) a través de un cron job configurado como 30 */3 * * *. Las ejecuciones ocurren a los 30 minutos de cada tercera hora: 00:30, 03:30, 06:30, 09:30, 12:30, 15:30, 18:30, 21:30 todos los días. En cada ejecución procesa todos los pedidos no completados que fueron creados hace más de 24 horas y están pendientes de resolución.

El comando cencosud_unfulfilled es un proceso automatizado que finaliza y resuelve los pedidos no completados después de 24 horas de su creación, específicamente para las operaciones en Chile y Argentina. Su objetivo principal es cerrar el ciclo de vida de los pedidos que requieren gestión manual, aplicando reglas de resolución automática según el tipo de caso.

Cobertura Geográfica

• Países: Chile (CL) y Argentina (AR)
• Alcance: Todas las cuentas en estos países
• Criterio temporal: Pedidos con más de 24 horas desde su creación

Funcionalidad Principal

1. Identificación de Pedidos Pendientes

El comando categoriza los pedidos en tres tipos distintos según su estado actual:

Tipo 1: Pedidos No Completados

Criterios de Búsqueda:

• Status: STATUS_UNFULFILLED (9)
• Países: Chile y Argentina
• Antigüedad: Más de 24 horas desde creación
• Condición: created_at <= now() - 24 horas

Tipo 2: Pedidos en Revisión

Criterios de Búsqueda:

• Status: STATUS_IN_REVIEW (14) en UnfulfilledOrder O en Order
• Países: Chile y Argentina
• Antigüedad: Más de 24 horas desde creación
• Condición: Cualquiera de los dos modelos puede tener status 14

Tipo 3: Pedidos Cancelados a Destiempo

Criterios de Búsqueda:

• Status UnfulfilledOrder: STATUS_UNFULFILLED_BY_USER (4)
• Status Order: STATUS_CANCELLED
• Stock no devuelto: order.stock_returned = False
• Países: Chile y Argentina
• Antigüedad: Más de 24 horas desde creación

2. Lógica de Resolución por Tipo

Pedidos No Completados(9)

Proceso de Evaluación: Para cada pedido se ejecutan tres métodos de resolución en secuencia. Solo se procede al siguiente método si el anterior retorna False (no aplicó):

Flujo de Evaluación:
1. unfulfilled_resolution_complete_order() → Si retorna True: COMPLETADO ✅
   ↓ (solo si retorna False)
2. unfulfilled_resolution_unfulfilled_by_user() → Si retorna True: USUARIO ✅  
   ↓ (solo si retorna False)
3. unfilled_resolution_unfulfilled_by_store() → Si retorna True: TIENDA ✅
   ↓
4. finish_unfulfilled_order() → FINALIZACIÓN FORZADA

Resolución 1: Completar Pedido

Método: unfulfilled_resolution_complete_order()
Lógica de Evaluación:
├── store_answer = null Y user_answer = "0" (entregado) → COMPLETADO
├── store_answer = null Y user_answer = null → COMPLETADO (beneficio de la duda)
├── store_answer = "0" Y user_answer = "0" → COMPLETADO (ambos confirman)
└── store_answer = "0" Y user_answer = null → COMPLETADO + notificación al usuario

Acciones Adicionales:
- Envía notificación push al usuario si solo la tienda confirmó
- Status final: STATUS_COMPLETED (1)
- Retorna True si se aplicó la resolución

Resolución 2: No Completado por Usuario

Método: unfulfilled_resolution_unfulfilled_by_user()
Lógica de Evaluación:
├── store_answer = null Y user_answer = "1" (no recogió) → UNFULFILLED_BY_USER
└── store_answer = "1" Y user_answer = null → UNFULFILLED_BY_USER + notificación

Acciones Específicas:
- Notifica al usuario que la tienda reportó que no recogió el pedido
- No se devuelven créditos (responsabilidad del usuario)
- Status final: STATUS_UNFULFILLED_BY_USER (4)
- Mensaje: "Se te cobró el monto del pedido"

Resolución 3: No Completado por Tienda

Método: unfilled_resolution_unfulfilled_by_store()
Lógica de Evaluación:
├── store_answer = "1" Y user_answer = "2" → UNFULFILLED_BY_USER (4)
├── store_answer = null Y user_answer = "2" → UNFULFILLED_BY_STORE + créditos
├── store_answer = "2" Y user_answer = "1" → UNFULFILLED_BY_STORE (4)
└── store_answer = "2" Y user_answer = null → UNFULFILLED_BY_STORE + créditos + notificación

Acciones de Compensación:
- Devuelve créditos: order.cost + coupon_value + credits_used
- Envía notificación disculpándose por la mala experiencia
- Status final: STATUS_UNFULFILLED_BY_STORE (4)
- Mensaje: "Recibiste un reembolso en créditos para tu próximo rescate"

Códigos de Respuesta:

• "0": Entregado/Recogido exitosamente
• "1": Usuario no recogió / Tienda reporta no pickup
• "2": Tienda no entregó / Usuario reporta no entregado

Finalización de Encuesta:

• Status: Se marca como finalizado en todos los casos
• Estados: finished=True, user_finished_view=True, store_finished_view=True
• Resultado: El pedido sale del flujo de gestión manual (carrusel)

Pedidos en Revisión(14)

Proceso de Resolución:

Método: unfulfilled_review_resolution()
Lógica de Evaluación Simplificada:
├── store_answer = "0" (entregado) → STATUS_COMPLETED (1)
├── store_answer = "2" (no entregado) → STATUS_UNFULFILLED_BY_STORE (4)
├── store_answer = "1" (usuario no recogió) → STATUS_UNFULFILLED_BY_USER (4)
└── Sin respuesta de tienda → Mantiene status actual

Acciones Específicas:
- Actualiza tanto UnfulfilledOrder como Order con el mismo status
- Guarda automáticamente los cambios en ambos modelos
- Prioriza la respuesta de la tienda sobre otras consideraciones

Características:

• Resolución más directa basada únicamente en la respuesta de la tienda
• Se guarda automáticamente sin requerir finalización externa
• Ideal para casos donde solo hay respuesta del partner

Pedidos Cancelados a Destiempo

Proceso de Limpieza:

Acción: late_canceled_order.save()
Objetivo: Disparar signals del sistema
Signal: handle_unfulfilled_order_in_realtime
Resultado: Elimina el pedido del carrusel de tiempo real

Propósito:

• Limpiar la interfaz de tiempo real después de 24 horas
• Evitar que pedidos cancelados aparezcan indefinidamente
• Mantener consistencia en el dashboard de stock

3. Sistema de Eventos y Tracking

Integración con Marketing Automation

Para cada resolución se registran eventos específicos:

Eventos Registrados:

• EventAction.ORDER_COMPLETED: Pedido completado exitosamente
• EventAction.ORDER_UNFULFILLED_BY_USER: No completado (cualquier razón)

Cliente de Eventos:

• Sistema: EventsClient()
• Función: register_event_drip_order()
• Datos: app_user, unfulfilled_order, action

Trazabilidad de Decisiones

• Cada resolución genera logs específicos
• Se mantiene registro de la lógica aplicada
• Permite auditoría posterior de decisiones automáticas

Status Procesados

Estados de Finalización de Encuesta.

• finished: True para todos los casos procesados
• user_finished_view: True - Usuario no necesita más acciones
• store_finished_view: True - Tienda no necesita más acciones
• stock_returned: Se verifica para pedidos cancelados