EFC/microservice
5
0
Fork 0
Code Issues 1 Pull Requests 1 Actions Packages Projects Releases Wiki Activity
Files
95b63f32b52b9dac1a775857d7ad4eb80f0bc1e1
microservice/CHANGELOG.md
marcos 95b63f32b5 fix: peticiones.py usa pedimento_app + post_or_update_document (T2025-09-004) 
El stack viejo de descarga (utils/peticiones.py, via api_v1 + signal en backend)
armaba el nombre con campos crudos en vez de pedimento_app (vu_EDC, app 042_240_...)
y posteaba con post_document (sin reemplazar) -> documentos sin ligar la FK y
partidas duplicadas.

Las 8 funciones get_soap_* (pedimento_completo, remesas, partidas, acuse,
acuseCOVE, estado, edocument, cove) ahora arman el nombre con pedimento_app
(identico a api_v2) y postean con post_or_update_document + identifier.
Corrige tambien el prefijo vu_EDC -> vu_ED.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-24 16:01:23 -06:00

2.7 KiB
Raw Blame History

Changelog — EFC Microservice

Historial de cambios por ticket (más reciente arriba). Reglas del flujo en ../CLAUDE.md.

T2025-09-004 — Nomenclatura/dedup de descargas (stack legacy peticiones.py)

  • Fecha: 2026-06-24
  • Tipo: fix
  • Repos: microservice (lo dispara un signal en backend; ver backend/CHANGELOG.md)
  • Branch: feature/T2025-09-004 · PR: (pendiente de aceptación manual)
  • Rastreo (root cause):
    • Dos stacks de descarga corrían en paralelo. El NUEVO api/api_v2/modules/* usa pedimento_app + post_or_update_document (liga la FK y reemplaza, no duplica). El VIEJO utils/peticiones.py armaba el nombre con campos crudos {remesas}{no_partidas}{tipo_operacion}_{aduana}_{patente}_{pedimento} (≠ pedimento_app), usaba prefijo vu_EDC (no vu_ED) y posteaba con post_document (sin reemplazar → duplicaba).
    • Disparador: el backend, al crear Pedimento/Cove/EDocument (p.ej. al cargar un datastage), ejecuta el signal api/customs/signals/procesamiento.py (post_save) → tareas de api.customs.tasks.microservice → api_v1 → peticiones.py. En paralelo, el Celery beat microservice_v2.process_all_organizations corre el stack v2.
    • Síntoma observado (pedimento 5d9c6fb1..., hoy): cada partida con 2 docs (uno por stack); los edoc/acuse del stack viejo con app anómalo (042_240_3452_6000382) y vu_EDC → no ligaban la FK; partidas "descargadas dos veces".
  • Fix: utils/peticiones.py — las 8 funciones de descarga (get_soap_pedimento_completo, get_soap_remesas, get_soap_partidas, get_soap_acuse, get_soap_acuseCOVE, get_estado_pedimento, get_soap_edocument, get_soap_cove) arman el nombre con pedimento_app (idéntico a api_v2) y postean con post_or_update_document (con identifier para partida/cove/edoc/acuses) → nombres correctos, FK ligada en Document.save(), sin duplicar. Corrige también el prefijo vu_EDC → vu_ED. Como peticiones.py usa el APIController (que no tenía ese método), se agregó post_or_update_document a APIController en controllers/RESTController.py.
  • Diseño / no-duplicidad: el alcance del beat v2 (ejecutar_basicos_organizacion: solo coves/edocs/acuses) es intencional; partidas/remesas/PC se procesan por el signal. La no-duplicidad NO depende de unificar los stacks: con ambos flujos usando el MISMO nombre (pedimento_app) + post_or_update_document con el mismo identifier, el segundo flujo en correr reemplaza el documento del primero → no quedan filas duplicadas. (Residual: doble descarga de coves/edocs por los dos flujos —perf, no duplicidad—; y una carrera de concurrencia exacta se auto-corrige en la siguiente corrida del beat.)