shopify_run_run/docs/pendientes.md

Pendientes / roadmap

Estado al 2026-09-30. Ver docs/flujo_pipeline.md, docs/mapeo_campos.md y docs/casos_especiales.md para lo construido y probado contra SAP/Shopify reales (ambas tiendas: snobbycl y on-chile-distributor-prod).

Antes de pasar al QA del cliente

1. Correr main.py solo varios ciclos seguidos (el loop real del scheduler, no las herramientas): lock, cursor, estados nuevos (cancelled, ignored), rotación de reintentos.
2. Revisar la configuración de cada tienda contra el SAP de QA: tarjetas de crédito (sap.payment_methods[*].credit_card) y sus cuentas, series de numeración, bodegas (default_warehouse_invoice, locations), generic_card_code, cuenta de reversso (1-1-010-20-000), grupo de artículos (108), grupo de clientes (100), TaxCode IVA, tipo de cambio USD cargado.
3. Datos provisorios de tarjeta (domain/payment.py): últimos dígitos 1234 y vencimiento 2030-12-31. Confirmar con contabilidad.
4. Secretos: ya están fuera del JSON (.env / variables de entorno). Falta definirlos en el equipo de QA, y evaluar verify_ssl: true en sap_connection.
5. Zona horaria: el QA está en UTC-3 (America/Santiago) y el desarrollo en UTC-5. La BD guarda UTC y tools/consultar muestra hora local (APP_TIMEZONE). main.py usa la hora local del equipo para las ventanas de scheduler.json; hay que confirmar que el servidor de QA tenga su zona correcta o fijar la zona en el scheduler.
6. Limpieza de artefactos de prueba: download/, respaldos de la BD en data/, artículos y entradas de mercancía de prueba (precio 5000, cuenta 1-1-080-40-000) de SBODemoCL.
7. Repositorio git: el proyecto no es un repositorio (no hay .git); el .gitignore ya existe. Falta git init, primer commit y definir el remoto. Antes de subir, verificar que git status no incluya .env, data/*.db, logs/ ni download/.
8. Fallback de órdenes manuales: retirado (carpeta ordenes_manuales/ y pipeline/manual_orders.py); un error de la API vuelve a verse como error de tienda.
9. Gateways nuevos: un gateway que no esté en sap.payment_methods solo se detecta al crear el pago (la Invoice ya existe y la orden queda en error). Conviene validar los gateways de la orden antes de crear la Invoice, o alertar apenas aparezca uno nuevo (hoy: Venti/Transbank en on-chile, PayPal configurado sin uso).
10. Tests automáticos: no hay carpeta de tests. Los JSON reales de download/ sirven de datos para probar construir_invoice, construir_incoming_payment y fulfillments_facturados sin tocar SAP.

Decisiones de negocio abiertas

• Pedidos de prueba: hoy se marcan a mano como ignored (#8019). Definir si se detectan automáticamente (por etiqueta, monto o cliente) para que no lleguen a SAP de QA. #8020 (1.000 CLP) se integró y podría ser de prueba.
• Costo de envío: toda orden con total_shipping_price_set > 0 queda en error (no se definió cómo reflejar el flete en la Invoice). En septiembre fue 1 de 1.160 órdenes en on-chile (#CL10169).
• Reembolsos o anulaciones posteriores a integrar: integrated es terminal; SAP queda con la venta completa, sin nota de crédito ni devolución. Hoy el reembolso se trata como interno de comercial.
• Envío real de la notificación de errores: generar_reporte_errores_html() solo guarda el HTML en notifications/. Falta definir a quién, con qué frecuencia y qué contenido.
• Instalación como servicio de Windows: falta empaquetarlo (ej. NSSM) en el equipo de destino.

Datos que quedaron abiertos en la BD de desarrollo

• on-chile — carga inicial: 1.159 órdenes pending desde el 01/09 (1.049 elegibles, 73 sin despachar, 22 anuladas, 15 con pago pendiente, 1 con envío). Artículos y stock ya creados en SBODemoCL y gateways configurados; falta integrarlas (en tandas, deteniéndose ante el primer error) y revisar #CL10851 (volvió a entrar como pending).
• snobbycl — #7863: queda en error (Delivery: documento base cerrado) y se reintenta en cada ciclo sin resolverse.
• snobbycl — #8055: pagada, sin despachar; se integra sola al despacharse.
• Clientes: integrar las órdenes de on-chile crea ~977 BusinessPartners nuevos en SAP (casi todas traen RUT).

Operación

• Respaldo y retención de la BD SQLite (data/shopify_sap.db) y de logs/ (hoy solo hay rotación de logs).
• docs/analisis_tiempos.md mide ~4-5 s por orden; en las pruebas de hoy fue ~5 s (CD) a ~7 s (tienda, con 5 documentos). Actualizar la estimación de capacidad (max_orders_per_cycle).

Pruebas pendientes

• Fulfillment parcial real (in_progress que se completa en un ciclo posterior). Nunca se probó de punta a punta con una orden real (hay órdenes partial en on-chile).
• Desincronización SQLite/SAP: la adopción de documentos existentes (ver abajo) está probada con la BD bloqueada para escrituras; falta observarla en un ciclo real.
• Volumen: ~7 s por orden. La carga inicial de on-chile desde el 01/09 son ~1.150 órdenes (~2 horas).

Ya resuelto (no repetir)

• Pipeline completo en ambas tiendas: Invoice, pago con tarjeta por transacción (incluye pagos divididos), ITR, StockTransfer y Delivery; camino de tienda y de CD.
• Descarga real de cabeceras en ambas tiendas (scope read_orders aprobado en on-chile).
• Idempotencia contra SAP: antes de crear Invoice, ITR, StockTransfer o Delivery se busca un documento existente de la orden (U_ShopifyOrderId, U_ShopifyStore, mismas líneas) y se adopta; una Invoice ya pagada no genera otro pago.
• Reintentos de red en ShopifyClient (4 intentos con espera creciente).
• Invoice igual a lo cobrado (líneas canceladas o devueltas, reembolsos), fulfillments limitados a lo facturado, órdenes anuladas (cancelled), pedidos ignorados (ignored), despachadas y luego reembolsadas se integran.
• Cursor con piso initial_since_id; corte de on-chile en el 01/09/2026.
• Secretos en .env (core/config.py), .gitignore, requirements.txt fijado.
• Fallback de órdenes manuales retirado (solo se usó mientras no se podía conectar a on-chile).
• Herramientas: consultar, integrar_ordenes, probar_pago, descargar_ordenes_especiales, entrada_mercancia_ordenes, cargar_items_faltantes.