marcos
95b63f32b5
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>
38 lines
2.7 KiB
Markdown
38 lines
2.7 KiB
Markdown
# 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.)
|