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>
6.4 KiB
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
- Correr
main.pysolo varios ciclos seguidos (el loop real del scheduler, no las herramientas): lock, cursor, estados nuevos (cancelled,ignored), rotación de reintentos. - 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. - Datos provisorios de tarjeta (
domain/payment.py): últimos dígitos1234y vencimiento2030-12-31. Confirmar con contabilidad. - Secretos: ya están fuera del JSON (
.env/ variables de entorno). Falta definirlos en el equipo de QA, y evaluarverify_ssl: trueensap_connection. - Zona horaria: el QA está en UTC-3 (America/Santiago) y el desarrollo en UTC-5. La BD guarda UTC y
tools/consultarmuestra hora local (APP_TIMEZONE).main.pyusa la hora local del equipo para las ventanas descheduler.json; hay que confirmar que el servidor de QA tenga su zona correcta o fijar la zona en el scheduler. - Limpieza de artefactos de prueba:
download/, respaldos de la BD endata/, artículos y entradas de mercancía de prueba (precio 5000, cuenta1-1-080-40-000) deSBODemoCL. - Repositorio git: el proyecto no es un repositorio (no hay
.git); el.gitignoreya existe. Faltagit init, primer commit y definir el remoto. Antes de subir, verificar quegit statusno incluya.env,data/*.db,logs/nidownload/. Fallback de órdenes manuales: retirado (carpetaordenes_manuales/ypipeline/manual_orders.py); un error de la API vuelve a verse como error de tienda.- Gateways nuevos: un gateway que no esté en
sap.payment_methodssolo se detecta al crear el pago (la Invoice ya existe y la orden queda enerror). Conviene validar los gateways de la orden antes de crear la Invoice, o alertar apenas aparezca uno nuevo (hoy:Venti/Transbanken on-chile,PayPalconfigurado sin uso). - Tests automáticos: no hay carpeta de tests. Los JSON reales de
download/sirven de datos para probarconstruir_invoice,construir_incoming_paymentyfulfillments_facturadossin 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 > 0queda enerror(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:
integratedes 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 ennotifications/. 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
pendingdesde 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 enSBODemoCLy gateways configurados; falta integrarlas (en tandas, deteniéndose ante el primer error) y revisar #CL10851 (volvió a entrar comopending). - 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 delogs/(hoy solo hay rotación de logs). docs/analisis_tiempos.mdmide ~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_progressque se completa en un ciclo posterior). Nunca se probó de punta a punta con una orden real (hay órdenespartialen 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_ordersaprobado 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;
Logoutal 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.txtfijado. - 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.