Resolución de Pedidos No Completados en 24h

¿Cuándo se ejecuta?

Este comando se ejecuta automáticamente cada 6 horas (4 veces al día) a través de un cron job configurado como 0 */6 * * *. Las ejecuciones ocurren al inicio de cada sexta hora: 00:00, 06:00, 12:00, 18:00 todos los días. En cada ejecución procesa todos los pedidos no completados que no han sido actualizados en las últimas 24 horas.

Criterios de Procesamiento

• Antigüedad: Pedidos sin actualizar por más de 1 día (24 horas)
• Estado: Status '9' (Unfulfilled) o '14' (In Review) en ambos modelos
• Alcance: Solo México (MX)
• Condición temporal: updated_at <= now() - 1 día

Funcionalidad Principal

1. Identificación de Pedidos Pendientes

Criterios de Búsqueda:

UnfulfilledOrder.objects.filter(
    updated_at__lte=datetime.now() - timedelta(days=1),
    status__in=['9', '14'], 
    order__status__in=['9', '14'],
    store__cities__country='MX'
)

Características:

• Alcance geográfico: Exclusivamente México
• Estados específicos: Solo status 9 y 14
• Criterio temporal: Basado en updated_at no created_at
• Doble validación: Verifica status en UnfulfilledOrder Y Order

2. Lógica de Resolución Simplificada

El comando aplica dos reglas de resolución básicas sin lógica compleja de evaluación:

Regla 1: Confirmación de Entrega

Condición: user_answer = '0' O store_answer = '0'

Lógica de Resolución:
└── Cualquiera confirma entrega → PEDIDO COMPLETADO

Acciones:
- Order.status = '1' (COMPLETED)
- UnfulfilledOrder.status = '1' (COMPLETED)
- finished = True

Características:

• Operador OR: Basta con que UNA parte confirme la entrega
• Sin notificaciones: No envía mensajes al usuario
• Sin compensaciones: No maneja créditos o reembolsos

Regla 2: No Entregado por Tienda con Confirmación de Usuario

Condición: user_answer = '1' Y store_answer = '2'

Lógica de Resolución:
└── Usuario no recogió Y tienda no entregó → No Entregado por Tienda

Acciones:
- Order.status = '12' (UNFULFILLED_BY_STORE)
- UnfulfilledOrder.status = '12' (UNFULFILLED_BY_STORE)
- finished = True

Características:

• Operador AND: Requiere ambas condiciones específicas
• Sin compensaciones: No devuelve créditos automáticamente

3. Casos No Cubiertos

El comando NO procesa:

• Casos donde solo el usuario responde negativamente
• Casos sin respuestas de ninguna parte
• Combinaciones de respuestas no contempladas en las dos reglas
• Casos que requieren notificaciones o compensaciones

Implicación:

• Pedidos que no cumplan las dos reglas específicas permanecen sin cambios
• Se procesarán en ejecuciones futuras o por otros comandos (Resolve Unfulfilled.)

Impacto en el Negocio

Beneficios

• Procesamiento Ágil: Resolución rápida para casos claros en México
• Simplicidad Operativa: Lógica directa sin complejidades adicionales
• Cobertura Geográfica: Específico para el mercado mexicano
• Frecuencia Alta: 4 veces al día para procesamiento continuo

Casos de Uso Típicos

• Confirmaciones de entrega tardías en México
• Casos donde cualquier parte confirma éxito
• Situaciones de doble falla (usuario no recoge + tienda no entrega)

Diferencias con Otros Comandos

vs update_unfulfilled

• Geografía: Solo México vs Universal
• Lógica: 2 reglas simples vs lógica compleja con múltiples escenarios
• Compensaciones: Sin manejo vs sistema completo de créditos/deuda
• Notificaciones: Sin push vs notificaciones completas
• Criterio temporal: updated_at vs created_at

vs cencosud_unfulfilled

• Países: México vs Chile/Argentina
• Partners: Todos vs Cencosud/Falabella/Tiendas Normales específicamente
• Complejidad: Básico vs métodos de resolución avanzados
• Frecuencia: Cada 6 horas vs cada 3 horas

vs restart_stock_v2

• Función: Resuelve casos existentes vs Crea nuevos casos
• Timing: 1 día de inactividad vs 15 minutos post-cierre
• Alcance: Casos específicos vs todos los pedidos

Reglas de Negocio Específicas

Filosofía de Resolución

• Optimista: Si alguien dice que se entregó, se acepta
• Conservadora: Solo procesa casos con evidencia clara
• Geográfica: Enfoque exclusivo en el mercado mexicano

Priorización de Decisiones

1. Confirmación de entrega: Si cualquiera confirma → Completado
2. Doble falla específica: Usuario no recoge + Tienda no entrega → Falla de tienda
3. Casos ambiguos: No se procesan (quedan para otros comandos)

Modelos y Status Utilizados

Modelos Principales

• UnfulfilledOrder: Registro principal que se procesa
• Order: Pedido original que se actualiza
• Sin dependencias de créditos, notificaciones o eventos

Status Procesados

Status Finales

Estados de Finalización

• finished: True para todos los casos procesados
• user_finished_view: No se modifica
• store_finished_view: No se modifica