Files
georgeandClaude Sonnet 5.5 38b152d6b5 SAP: una sesión por conexión, reutilizada y renovada solo ante un 401
Antes se abría un login por orden (un cliente por orden, con la sesión
guardada solo en la instancia) y nunca se cerraba. Ahora el B1SESSION se
guarda por conexión (URL + base + usuario) en un caché del proceso, se
renueva solo si SAP responde 401 y se cierra con Logout al terminar el
proceso (SAPServiceLayerClient.cerrar_sesiones).

Probado contra SAP: 6 clientes de ambas tiendas hacen 1 login; una sesión
inválida provoca 1 login tras el 401; la integración de 3 órdenes con SAP
bloqueado para escrituras hace 1 login.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
2026-09-30 19:49:49 -05:00

6.4 KiB

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.
  • Sesiones de SAP: una por conexión, reutilizada y renovada solo ante un 401; Logout al cerrar el proceso (antes: un login por orden, sin cierre).
  • 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.