Servicio de Cancelación de Pedidos

Flujo Especializado (AR/CL y Cencosud)

1. Evaluación de Política de Cancelación

Función: cancel_policy_country()

Configuración del Sistema:

• CANCELLATION_POLICY_HOURS_BEFORE_CLOSING = 2 (horas antes del cierre)
• CANCELLATION_POLICY_HOURS_AFTER_CREATION = 1 (horas después de creación)

Casos Límite:

• Pedido recién creado: Si time_since_creation ≤ 1 hora → Siempre "A TIEMPO"
• Tienda con mucho tiempo: Si time_to_closing ≥ 2 horas → Siempre "A TIEMPO"
• Combinación crítica: time_to_closing < 2h Y time_since_creation > 1h → "A DESTIEMPO"

Flujo de Decisión:

¿Cancelación a Tiempo?
├── SÍ → Retorna créditos y cupones completos + Estado CANCELLED
└── NO → Cancelación a Destiempo
    ├── Cuenta Normal → Estado LATE_CANCELLED  
    └── Cuenta Cencosud → Estado CANCELLED + Evaluación de Stock

2. Reglas Especiales para Cencosud

Función: stock_must_be_returned(store, country)

Configuración por País (solo Cencosud):

• Chile (CL): STOCK_RETURN_WINDOW = 30 minutos
• Otros países: Sin ventana específica

Conceptos Clave:

• No existe el estado "LATE_CANCELLED" para Cencosud
• Todos los pedidos cancelados tienen estado "CANCELLED"
• Se usa el campo stock_returned para diferenciar tipos de cancelación

Reglas de Decisión:

1. Si la tienda ya cerró → stock_returned = False
2. Si faltan ≤ 30 minutos para cerrar → stock_returned = False
3. Si faltan > 30 minutos para cerrar → stock_returned = True

Acciones según Resultado

Cuando stock_returned = True:

• Se devuelve el stock al inventario
• El pedido se marca como cancelado normalmente
• No se crea UnfulfilledOrder

Cuando stock_returned = False:

• NO se devuelve stock al inventario
• Se crea un registro UnfulfilledOrder con:
  • status = STATUS_UNFULFILLED_BY_USER
  • finished = True (proceso completado)
  • Respuestas automáticas del usuario y tienda = "1"
• Implicación de Negocio: El pedido se procesa en caja y se paga a Cencosud en la conciliación

Proceso de Creación de UnfulfilledOrder

Propósito del Negocio:

• Conciliación Financiera: Cencosud recibe el pago del pedido
• Control de Inventario: El stock físico ya fue separado
• Auditoría: Registro de pedidos no recogidos por el usuario

3. Gestión de Stock por Tipo de Cuenta

Cuentas Cencosud:

• Retorno de stock condicional según evaluación de tiempo
• Creación de UnfulfilledOrder cuando no se retorna stock
• Estado siempre "CANCELLED" (nunca "LATE_CANCELLED")

Cuentas No-Cencosud:

• Retorno de stock automático en todas las cancelaciones
• Sin creación de UnfulfilledOrder
• Estados diferenciados: "CANCELLED" vs "LATE_CANCELLED"

Flujo Alternativo (Otros Países - Default)

1. Evaluación de Tiempo de Cancelación

Función: cancel()

Interacción entre Evaluaciones:

• Estado del pedido: Determina si es "CANCELLED" o "LATE_CANCELLED"
• Política de país: Determina si aplican restricciones adicionales (is_applicable)
• Ambas son independientes pero se combinan para el resultado final

Flujo de Decisión:

¿Faltan < 2 horas para cerrar?
├── SÍ → Estado LATE_CANCELLED
└── NO → Estado CANCELLED

Paralelamente:
¿cancel_policy_country() es aplicable?
├── SÍ → Habilita restricciones de basket_size
└── NO → basket_size = False (sin restricciones)

2. Evaluación de Basket Size

Configuración del Sistema:

• BASKET_SIZE_THRESHOLD = 190 (monto mínimo en moneda local)
• Política aplicable: "HIGH_BASKET_SIZE"

Casos de Uso:

1. Pedido grande + Política aplicable: basket_size = True → Restricciones
2. Pedido pequeño + Política aplicable: basket_size = False → Sin restricciones
3. Cualquier pedido + Política NO aplicable: basket_size = False → Sin restricciones

Impacto en el Retorno de Promociones:

• basket_size = True: Retorno parcial o retención de promociones
• basket_size = False: Retorno completo de promociones

3. Prevención de Fraude

Función: CancellationOrdersPolicy.fraud_prevention_evaluation()

Objetivo: Detectar patrones de abuso en cancelaciones para prevenir fraude

Parámetros de Configuración

Variables del Sistema:

• fraud_cancellation_rate: Porcentaje máximo permitido de cancelaciones
• fraud_orders_count: Número mínimo de pedidos para evaluar patrones
• days_range_from_fraud_evaluation: Rango de días para el análisis (típicamente 30 días)

Métricas del Usuario Evaluadas

1. Tasa de Cancelación Reciente:

• Calcula user_cancellation_rate en el rango de días configurado
• Cuenta cancelled_orders_count vs user_orders_count completados

2. Historial de 90 Días:

• Evalúa pedidos efectivos en los últimos 90 días
• Considera el campo reset_cancellation_policy del usuario
• Calcula tasa de cancelación histórica

3. Estado de Política de Cancelación:

• inflicts_cancellation_policy: Usuario bajo política restrictiva
• last_opportunity_cancellation_policy: Usuario en última oportunidad
• warning_cancellation_policy_result: Nivel de advertencia actual

Reglas de Evaluación

Validación Previa - Sin Promociones:

¿El pedido tiene promociones?
├── NO → Retorna FALSE (no hay riesgo de fraude)
│   ├── credits_used ≤ 0 o NULL
│   └── used_coupon = False
└── SÍ → Continúa evaluación

Evaluación Principal:

¿Es intento de fraude?
Condiciones AMBAS deben cumplirse:
├── user_cancellation_rate > fraud_cancellation_rate (configurado)
└── user_orders_count > fraud_orders_count (configurado)

Si AMBAS son TRUE → FRAUDE DETECTADO
Si alguna es FALSE → NO ES FRAUDE

Estados de Advertencia

Niveles de Warning:

• 'warning': Usuario en última oportunidad + bajo política restrictiva
• 'normal': Usuario sin restricciones especiales
• 'restricted': Usuario bajo política restrictiva

Lógica Especial:

• Si inflicts_cancellation_policy = True AND last_opportunity_cancellation_policy = True
• Entonces warning_cancellation_policy_result = 'warning'

Datos de Retorno

Información Completa:

{
  "fraud_cancellation_rate_config": "Configuración del sistema",
  "fraud_orders_count_config": "Mínimo de pedidos requeridos", 
  "days_range_config": "Rango de días evaluados",
  "user_cancelled_orders_count": "Cancelaciones del usuario",
  "user_cancellation_rate": "Porcentaje de cancelación",
  "effective_user_orders_count": "Pedidos completados",
  "warning_cancellation_policy": "Estado de advertencia",
  "user_cancelled_orders_cancellation_policy": "Cancelaciones bajo política"
}

Evaluación:

• Analiza patrones de cancelación del usuario
• Considera: tasa de cancelación, número de pedidos, rango de días

Flujo de Decisión:

¿Es intento de fraude?
├── NO → Retorna créditos y cupones según basket_size
└── SÍ → Retiene promociones temporalmente
    ├── Envía notificación al usuario
    └── Aplica tiempo de retención configurado

4. Gestión de Promociones y Reembolsos

Escenario Normal (Sin Fraude)

Créditos: Retorno basado en basket_size final Cupones: Retorno basado en basket_size final Stock: Retorno automático al inventario

Lógica de basket_size:

• Si basket_size = True: Retorno parcial o con restricciones
• Si basket_size = False: Retorno completo

Escenario de Fraude Detectado

Promociones: Se retienen temporalmente Notificación: Se informa al usuario sobre la retención Duración: Según configuración del sistema

5. Acciones Finales

Análisis Detallado de _review_push_notification_before_cancel()

Función: _review_push_notification_before_cancel(order)

Objetivo: Aprovechar el stock liberado por la cancelación para notificar a usuarios interesados

Configuración del Sistema:

• MAX_NOTIFICATIONS_PER_DAY = 3 (límite diario por usuario)
• STOCK_INTEREST_DAYS = 7 (días para considerar interés en productos)
• MIN_STORE_OPEN_TIME = 30 (minutos mínimos de apertura)

Criterios de Usuarios Interesados:

1. Usuarios sin stock reciente: Tuvieron pedidos sin estos productos en últimos 7 días
2. Usuarios favoritos: Tienen la tienda marcada como favorita
3. Exclusión: El usuario que canceló NO recibe notificación

Control Anti-Spam:

• Cache diario: Máximo 3 notificaciones por usuario por día
• Reset automático: Cache se limpia a medianoche
• Verificación previa: Antes de enviar, verifica límite actual

Condiciones de Activación:

• ✅ Stock será retornado al inventario
• ✅ Tienda permanece abierta >30 minutos

Acciones Posteriores a Cancelación Exitosa

6. Rehabilitación Automática de Usuarios

Función: review_cancellation_policy(user)

Objetivo: Rehabilitar automáticamente usuarios que demuestran comportamiento mejorado

Configuración del Sistema:

• SUCCESSFUL_ORDERS_FOR_REHABILITATION = 3 (pedidos exitosos requeridos)
• EVALUATION_PERIOD = 90 días (período de evaluación)

Criterios de Rehabilitación:

• Condición: Usuario debe completar 3 pedidos exitosos consecutivos
• Estados válidos: Pedidos entregados, no cancelados
• Período: Desde la última restricción aplicada

Acciones de Rehabilitación:

1. Actualizar estado: inflicts_cancellation_policy = False
2. Marcar fecha: reset_cancellation_policy = fecha_actual
3. Registrar log: Crear entrada en CancellationPolicyLog
4. Notificar usuario: "Ya puedes usar pago en efectivo nuevamente"

Impacto en el Usuario:

• Pago en efectivo: Habilitado nuevamente
• Restricciones: Removidas completamente
• Historial: Mantiene registro para futuras evaluaciones

7. Compensación por Experiencia Negativa

Análisis Detallado de _cancel_by_store_experiencie()

Función: _cancel_by_store_experiencie(order, cancel_reason)

Objetivo: Compensar automáticamente usuarios cuando la cancelación es responsabilidad de la tienda

Motivos de Compensación:

• "STORE_CLOSED": Tienda cerrada inesperadamente
• "STORE_NOT_DELIVERED": Tienda no pudo entregar el pedido
• "PACKAGE_NOT_GOOD": Producto en mal estado o no disponible

Compensaciones por Ciclo de Vida:

Usuario Nuevo (life_cycle = "new_user"):

• Cupón: "CANU20" (20% descuento para nuevos usuarios)
• Vigencia: 14 días
• Objetivo: Retener usuario en primera experiencia negativa

Usuario en Primer Rescate (life_cycle = "first_rescue"):

• Cupón: "CAN20" (20% descuento general)
• Vigencia: 14 días
• Objetivo: Recuperar usuario que ya tuvo problemas

Otros Usuarios:

• Sin cupón automático
• Notificación: Disculpa por experiencia negativa
• Seguimiento: Registro para análisis de satisfacción

Registro de Compensación:

• CouponHistory: Estado "0" (disponible)
• Vinculación: Cupón ligado al pedido cancelado
• Expiración: Automática después de 14 días
• Auditoría: Motivo registrado para seguimiento

8. Generación de Deuda por Cancelación Tardía

Configuración del Sistema:

• BASKET_SIZE_THRESHOLD = 190 (monto mínimo para generar deuda)
• CASH_PAYMENT_TYPE = "1" (identificador de pago en efectivo)

Condiciones para Generar Deuda:

1. Monto: order.total_amount >= $190
2. Pago: payment_type = "1" (efectivo)
3. Timing: is_applicable = True (cancelación tardía)

Proceso de Compensación Automática:

1. Verificar créditos: Obtener user.available_credits
2. Calcular compensación: min(créditos_disponibles, monto_deuda)
3. Aplicar compensación: Reducir créditos y deuda proporcionalmente
4. Actualizar registros: Guardar montos compensados
5. Notificar usuario: Informar sobre uso de créditos

Impacto en el Usuario:

• Restricciones de pago: Limitaciones hasta saldar deuda
• Notificaciones: Recordatorios de pago pendiente
• Historial crediticio: Registro para futuras evaluaciones
• Incentivo: Disuade cancelaciones tardías irresponsables

Propósito del Sistema:

• Proteger tiendas: Compensar preparación de pedidos no recogidos
• Disuadir abuso: Reducir cancelaciones tardías de pedidos grandes
• Responsabilidad: Incentivar uso responsable del pago en efectivo

Análisis Detallado de Métricas de Usuario

Manager: effective_orders_in_90_days()

Objetivo: Calcular pedidos efectivos (completados) en rango de tiempo

Configuración del Sistema:

• Rango por defecto: 90 días (DAYS_RANGE_CANCELLATION_POLICY)
• Fecha base: reset_cancellation_policy del usuario o fecha actual - 90 días

Estados EXCLUIDOS (No cuentan como efectivos):

• 0: STATUS_REQUESTED (solicitado, no procesado)
• 6: STATUS_PRE_CANCELLED (pre-cancelado)
• 7: STATUS_CANCELLED (cancelado)
• 16: STATUS_LATE_CANCELLED (cancelado tardío)
• 17: STATUS_UNFULFILLED_BY_USER (no cumplido por usuario)

Estados INCLUIDOS (Cuentan como efectivos):

• Todos los demás estados (entregados, en proceso, preparando, etc.)

Manager: cancel_orders()

Objetivo: Contar cancelaciones atribuibles al usuario en rango de tiempo

Configuración del Sistema:

• Rango: Mismo que effective_orders_in_90_days (90 días)
• Estados de cancelación: [7, 16] (STATUS_CANCELLED, STATUS_LATE_CANCELLED)

Motivos INCLUIDOS (Cancelaciones atribuibles al usuario):

• 'NOT_PICKED_UP': Usuario no recogió el pedido
• 'OTHER': Otros motivos del usuario
• None: Sin motivo específico (asumido como usuario)

Motivos EXCLUIDOS (No atribuibles al usuario):

• 'STORE_CLOSED': Tienda cerrada inesperadamente
• 'STORE_NOT_DELIVERED': Tienda no pudo entregar
• 'PACKAGE_NOT_GOOD': Producto en mal estado

Manager: cancellation_rate()

Objetivo: Calcular porcentaje de cancelación del usuario

Fórmula:

cancellation_rate = cancel_orders / max(effective_orders, 1)

Protección contra División por Cero:

• Usa max(effective_orders, 1) para evitar división por cero
• Si usuario no tiene pedidos efectivos, denominator = 1

Manager: inflicts_cancellation_policy_result()

Objetivo: Determinar si usuario debe estar bajo política restrictiva

Configuración del Sistema:

• EFFECTIVE_ORDERS_CANCELLATION_POLICY = 8 (umbral de pedidos)
• CANCEL_ORDERS_CANCELLATION_POLICY = 5 (límite de cancelaciones)
• CANCEL_RATE_CANCELLATION_POLICY = 0.25 (25% tasa máxima)

Reglas de Aplicación:

Regla 1 - Usuarios con Pocos Pedidos:

SI effective_orders ≤ 8 Y cancel_orders = 5
ENTONCES inflicts_cancellation_policy = TRUE

Regla 2 - Usuarios con Muchos Pedidos:

SI effective_orders > 8 Y cancel_orders ≥ 5 Y cancellation_rate ≥ 25%
ENTONCES inflicts_cancellation_policy = TRUE

Ejemplos Prácticos:

• Usuario A: 6 pedidos efectivos, 5 cancelaciones → RESTRINGIDO (Regla 1)
• Usuario B: 20 pedidos efectivos, 6 cancelaciones (30%) → RESTRINGIDO (Regla 2)
• Usuario C: 20 pedidos efectivos, 4 cancelaciones (20%) → NO RESTRINGIDO

Casos de Uso Prácticos Completos

Escenario 1: Cancelación Temprana - Cencosud

• Situación: Usuario cancela a las 10:00 AM, tienda cierra a las 8:00 PM
• Evaluación: stock_must_be_returned() = True (>30 min para cerrar)
• Resultado:
  • stock_returned = True
  • Stock devuelto al inventario
  • Estado: CANCELLED
  • Sin UnfulfilledOrder

Escenario 2: Cancelación a Destiempo - Cencosud

• Situación: Usuario cancela a las 7:45 PM, tienda cierra a las 8:00 PM
• Evaluación: stock_must_be_returned() = False (≤30 min para cerrar)
• Resultado:
  • stock_returned = False
  • Se crea UnfulfilledOrder
  • Estado: CANCELLED
  • Pedido se paga en conciliación

Escenario 3: Cancelación Temprana - País Default

• Situación: Usuario cancela a las 10:00 AM, tienda cierra a las 8:00 PM, pedido $250
• Evaluación:
  • Estado: CANCELLED (>2h para cerrar)
  • is_applicable = False (>2h para cerrar)
  • basket_size = False (política no aplicable)
• Resultado: Retorno completo de promociones

Escenario 4: Cancelación a Destiempo - País Default

• Situación: Usuario cancela a las 7:45 PM, tienda cierra a las 8:00 PM, pedido $250
• Evaluación:
  • Estado: LATE_CANCELLED (<2h para cerrar)
  • is_applicable = True (<2h para cerrar Y >1h desde creación)
  • basket_size = True (≥$190 Y política aplicable)
• Resultado: Retorno con restricciones + posible generación de deuda

Escenario 5: Fraude Detectado - País Default

• Situación: Usuario con patrón de cancelaciones frecuentes
• Perfil: 10 pedidos, 7 cancelaciones (70%), con créditos usados
• Evaluación:
  • user_cancellation_rate = 70% > 50%
  • orders_count = 10 > 4
  • credits_used > 0
• Resultado: FRAUDE DETECTADO → Promociones retenidas temporalmente

Escenario 6: Pedido Pequeño - País Default

• Situación: Usuario cancela pedido de $150 (< $190)
• Evaluación:
  • Independiente del horario y política
  • basket_size = False (monto < umbral)
• Resultado: Retorno completo de promociones

Escenario 7: Detección de Fraude - Ejemplo Detallado

• Configuración del Sistema:
  • fraud_cancellation_rate = 50% (máximo permitido)
  • fraud_orders_count = 4 (mínimo para evaluar)
  • days_range = 30 días
• Perfil del Usuario:
  • 10 pedidos completados en 30 días
  • 7 pedidos cancelados en 30 días
  • user_cancellation_rate = 70% (7/10)
  • Pedido actual tiene créditos usados
• Evaluación:
  • 70% > 50% (supera tasa máxima)
  • 10 > 4 (suficientes pedidos para evaluar)
• Resultado: FRAUDE DETECTADO → Promociones retenidas temporalmente

Escenario 8: Usuario Nuevo - Sin Fraude

• Perfil del Usuario:
  • 3 pedidos completados en 30 días
  • 2 pedidos cancelados en 30 días
  • user_cancellation_rate = 66%
• Evaluación:
  • 66% > 50% (supera tasa máxima)
  • 3 ≤ 4 (insuficientes pedidos para evaluar)
• Resultado: NO ES FRAUDE → Retorno normal de promociones

Escenario 9: Notificaciones Push por Stock Liberado

• Situación: Usuario cancela pedido con hamburguesas, tienda cierra en 45 minutos
• Stock Liberado: 3 hamburguesas vuelven al inventario
• Usuarios Objetivo:
  • 5 usuarios tuvieron pedidos sin hamburguesas en últimos 7 días
  • 2 usuarios tienen la tienda como favorita
• Resultado: 7 notificaciones enviadas (excluyendo al que canceló)

Escenario 10: Rehabilitación de Usuario Restringido

• Situación: Usuario con inflicts_cancellation_policy = True completa su 3er pedido
• Acción: review_cancellation_policy() ejecutada automáticamente
• Métricas actualizadas:
  • reset_cancellation_policy = fecha_actual
  • inflicts_cancellation_policy = FALSE
• Resultado:
  • Usuario rehabilitado
  • Notificación: "Ya puedes usar pago en efectivo nuevamente"
  • Registro en CancellationPolicyLog

Escenario 11: Compensación por Tienda Cerrada

• Situación: Usuario nuevo cancela porque tienda cerró inesperadamente
• Motivo: cancel_reason = "STORE_CLOSED"
• Life Cycle: "new_user"
• Resultado:
  • Cupón "CANU20" (20% descuento) válido por 14 días
  • Notificación de disculpa y compensación
  • Registro en CouponHistory para seguimiento

Escenario 12: Control de Spam en Notificaciones

• Situación: Usuario ya recibió 3 notificaciones hoy por stock liberado
• Nueva Cancelación: Libera stock de productos demandados
• Resultado: No se envían más notificaciones (protección anti-spam)
• Cache: Usuario queda registrado hasta el siguiente día

Escenario 13: Generación de Deuda por Cancelación Tardía

• Situación: Pedido $300, pago efectivo, cancelación 1 hora antes del cierre
• Evaluación:
  • Monto ≥ $190 (basket_size hardcodeado en models.py)
  • Pago en efectivo (payment_type = "1")
  • Cancelación tardía (is_applicable = True)
• Usuario: 80 créditos disponibles
• Resultado:
  • Deuda generada: $300
  • Compensación automática: $80 (créditos usados)
  • Deuda final: $220 pendiente
  • Evento HIGH_BASKET_SIZE registrado

Escenario 14: Métricas de Usuario - Política Restrictiva (Regla 1)

• Historial del Usuario (90 días):
  • 6 pedidos efectivos (entregados)
  • 5 cancelaciones atribuibles (NOT_PICKED_UP)
  • 1 cancelación por tienda (STORE_CLOSED) - NO cuenta
• Evaluación:
  • effective_orders ≤ 8 (6 ≤ 8)
  • cancel_orders = 5 (exacto)
• Resultado: inflicts_cancellation_policy = TRUE → Usuario restringido

Escenario 15: Métricas de Usuario - Política Restrictiva (Regla 2)

• Historial del Usuario (90 días):
  • 20 pedidos efectivos
  • 6 cancelaciones atribuibles
  • Tasa de cancelación: 30% (6/20)
• Evaluación:
  • effective_orders > 8 (20 > 8)
  • cancel_orders ≥ 5 (6 ≥ 5)
  • cancellation_rate ≥ 25% (30% ≥ 25%)
• Resultado: inflicts_cancellation_policy = TRUE → Usuario restringido

Escenario 16: Usuario Protegido - Sin Restricciones

• Historial del Usuario (90 días):
  • 15 pedidos efectivos
  • 3 cancelaciones atribuibles
  • Tasa de cancelación: 20% (3/15)
• Evaluación:
  • effective_orders > 8 (15 > 8)
  • cancel_orders < 5 (3 < 5)
• Resultado: inflicts_cancellation_policy = FALSE → Usuario sin restricciones

Escenario 17: Rehabilitación Automática

• Situación: Usuario restringido completa su 3er pedido exitoso
• Acción: review_cancellation_policy() ejecutada
• Métricas actualizadas:
  • reset_cancellation_policy = fecha_actual
  • inflicts_cancellation_policy = FALSE
• Resultado:
  • Usuario rehabilitado
  • Notificación: "Pago en efectivo habilitado nuevamente"
  • Registro en CancellationPolicyLog

Eventos y Auditoría

Registro de Eventos para Analytics

Función: register_event_drip_order(order, action)

Eventos Registrados:

• ORDER_CANCELLED: Cancelación exitosa
• HIGH_BASKET_SIZE: Generación de deuda por pedido grande
• FRAUD_DETECTED: Detección de patrón fraudulento
• USER_REHABILITATED: Rehabilitación automática de usuario

Metadatos Incluidos:

• ID del usuario y pedido
• Montos involucrados (deuda, compensación)
• Motivos de cancelación
• Métricas de usuario relevantes

Notificaciones Internas del Sistema

Función: _create_notification()

Propósito: Coordinación con equipos operativos

Tipos de Notificaciones:

• Cancelaciones por motivos de tienda
• Detección de patrones de fraude
• Generación de deudas significativas
• Rehabilitaciones de usuarios

Impacto en Conciliación Financiera

UnfulfilledOrder - Contexto de Cancelación

Significado para el Negocio:

• El pedido debe pasar por caja en la tienda
• Cencosud recibe el pago en la conciliación
• El stock no regresa al sistema digital

Casos de Creación:

• Cancelaciones tardías en cuentas Cencosud
• Cuando stock_returned = False
• Solo para pedidos con stock físicamente separado

Impacto Financiero:

• Para Cencosud: Recibe pago por productos separados
• Para la plataforma: Mantiene registro de productos no entregados
• Para auditoría: Trazabilidad completa del proceso

Aclaración de Inconsistencia en Basket Size

Configuración del Sistema:

• En models.py: Valor hardcodeado 190.00 (usado en flujo default)
• En views.py: Configuración BASKET_SIZE con default 200 (usado para generación de deuda)

Diferencia Importante:

• $190: Umbral para restricciones en retorno de promociones (flujo default)
• $200: Umbral para generación de deuda por cancelación tardía

Impacto en Casos de Uso:

• Pedido de $195: Aplica restricciones pero NO genera deuda
• Pedido de $250: Aplica restricciones Y genera deuda