# 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.)