API Portas — Web (Escritorio)

2. Autenticación: dos niveles

Hay dos credenciales distintas, con roles distintos:

Credencial	Va en	Identifica a	Quién la tiene
API key	`Authorization: Bearer <key>`	La aplicación	El servidor de la app (en su `.env`). Nunca el navegador.
Token de sesión	`X-Sesion: <token>`	El usuario final	Se emite en el login y vive en la sesión del servidor de la app.

La sesión dejó de ser obligatoria (2026-08-11). Hasta esa fecha los endpoints de datos exigían sesión y la API imponia el filtro por cliente. Ahora un integrador que maneja sus propios usuarios — y decide por su cuenta qué cliente puede ver cada uno — puede llamar solo con la API key y acotar con el parámetro id_cliente (ver la sección siguiente).

Consecuencia directa: la API key pasa a ser la credencial crítica. Quien la tenga puede leer datos de cualquier cliente. Tiene que vivir en el backend del integrador, nunca en el navegador. Si el token de sesión se manda pero está vencido, la respuesta sigue siendo 401: un problema de sesión no se disfraza de resultado vacío.

Scopes

Scope	Habilita
`web:read`	Lectura: `GET /v1/web/sesion` y futuros listados
`web:write`	Escritura: login, logout y futuras acciones del usuario

Se mantienen separados de datos:read / datos:write (que usa FreeWayNet) para que una filtración de la key del escritorio no habilite el alta de legajos.

Escritura sobre la LAN. La API no envía mails ni push (no tiene ninguna capacidad de envío). La única escritura de esta API sobre la base de Portas es POST /v1/web/notificaciones/{id}/visto, gobernada por WEB_LAN_ESCRITURA en el .env: estuvo en modo solo lectura (respondía 503 modo_solo_lectura) hasta que se habilitó en producción el 2026-09-03 para que importas marque leídas las notificaciones al mostrarlas.

Cabecera adicional recomendada

X-Cliente-Ip: 200.45.12.33

Como la app puede correr en el mismo servidor que la API, sin esta cabecera el log de accesos registraría siempre la IP del propio servidor. La app reenvía acá la IP real del visitante.

2b. Filtrar por cliente: `id_cliente`

Todos los endpoints /v1/web/* que devuelven datos aceptan el parámetro id_cliente. Acepta uno o varios separados por coma (?id_cliente=84,1167). Por compatibilidad también se acepta cliente, que es como se llamaba en los ocho reportes.

GET /v1/web/comprobantes?id_cliente=84
  Authorization: Bearer <api-key>

Si no se manda, no hay error

La respuesta trae todos los clientes. Es deliberado: cuando el integrador tiene su propia tabla de usuarios y sus propias reglas de quién ve qué, el recorte es responsabilidad suya y la API no puede adivinarlo. No devolvemos 422 por un parámetro ausente.

El parámetro ACOTA, nunca amplía

Se combina con el alcance de la sesión mediante AND. Un usuario con sesión de cliente que mande el id_cliente de otro no ve nada — su propio alcance ya lo encierra:

Quién llama	Sin `id_cliente`	Con `id_cliente=84`
Sin sesión (solo API key)	todos los clientes	solo el 84
Sesión delegada por `id_cliente`	todos los clientes	solo el 84
Personal de Portas	todos los clientes	solo el 84
Usuario del cliente 84	solo el 84	solo el 84
Usuario del cliente 12	solo el 12	nada

Documentos y descargas

En /v1/web/legajos/{id_carpeta}/documentos el parámetro se usa para verificar que el legajo sea de ese cliente: si no lo es, 404. Sin id_cliente se sirve igual, con el mismo criterio que el resto. Conviene mandarlo: los id_carpeta son predecibles (anio.despachante.nro_orden) y es la única barrera que evita que uno adivinado devuelva documentación ajena.

Quedó registrado quién consulta qué. Cada llamada se guarda con el endpoint, el id_cliente efectivo y el nombre del usuario final. Ese nombre se toma del parámetro usuario de la request, o de la sesión si se abrió con /v1/web/sesion-delegada. Los dos son opcionales, pero mandarlos es lo que permite responder después "quién consultó los comprobantes de tal cliente".

Campo	Tipo	Obligatorio	Descripción
`usuario`	string	SÍ	Normalmente el email del usuario
`clave`	string	SÍ	Contraseña

`persona`	Condición	Alcance de los datos
`cliente`	existe la fila en `clientes` (no alcanza con que `id_cliente` tenga valor)	`carpetas.id_cliente`
`proveedor`	tiene `id_proveedor_cliente`	el viejo le fuerza `id_cliente = 0`, asi que las pantallas de cliente le salen vacías. Su pantalla propia es `/clientes_oficios`
`transportista`	tiene `id_transportista`	su menú solo tiene `/transp_oficios`
`empleado`	ninguna de las anteriores — personal de Portas	sin filtro: ve todas las operaciones, de todos los clientes

3b. Sesión delegada — para trazabilidad

POST/v1/web/sesion-delegada — scope web:write

Para un sistema que tiene su propia tabla de usuarios y autentica por su cuenta — hoy, importas.com.ar. Registra quién va a consultar y devuelve un token igual al del login.

Es opcional, y su valor hoy es el seguimiento. Desde que la sesión dejó de ser obligatoria y el filtrado se hace con id_cliente por parámetro, este endpoint no hace falta para consultar datos: se puede llamar a todo solo con la API key. Lo que aporta es que cada llamada posterior quede atribuida a un usuario sin repetir el dato en cada request. La alternativa liviana es mandar usuario como parámetro en cada llamada.

El id_cliente de la sesión es informativo: queda en el log pero no filtra. Quien filtra es el parámetro de cada llamada. Así una misma sesión sirve para consultar varios clientes.

Modo A — por usuario de Portas

Si el sistema externo autentica contra los mismos usuarios de Portas (web_clientes_usuarios, la tabla de la LAN), lo único que hay que mandar es cuál es. Portas resuelve el resto contra su propia base: es el login sin el chequeo de la clave, porque esa ya la validó el sistema externo.

curl -X POST https://api.portascloud.ar/v1/web/sesion-delegada \
  -H "Authorization: Bearer <api-key>" \
  -H "Content-Type: application/json" \
  -d '{"usuario":"jperez@empresa.com"}'

Devuelve lo mismo que el login — sesion + el objeto usuario completo — y la sesión es idéntica a la de un login propio: mismo id_usuario_web, misma persona, mismo alcance.

Cuándo conviene este modo. Cuando los usuarios del sistema externo son los de Portas. Ahí el alcance lo decide Portas contra su propia tabla y la sesión encierra de verdad: quien llama no puede elegir a qué cliente entrar ni convertir a un usuario de cliente en interno. Es el único modo en que la sesión sigue imponiendo un límite; en el modo B es puramente informativa.

Resuelve además el caso del personal de Portas, que no tiene un cliente asignado: sale persona: "empleado" con id_cliente: 0 y alcance a todas las operaciones, sin que el integrador tenga que pedirlo ni saber distinguirlo.

Errores del modo A

Código	Cuándo
`404 usuario_inexistente`	ese usuario no existe en Portas
`403 usuario_inactivo`	existe pero está dado de baja

Modo B — por cliente (el que usa importas)

Para cuando los usuarios del sistema externo no existen en Portas. Se manda el nombre del usuario — tal cual lo tenga en su base, no hace falta que signifique nada acá — y opcionalmente un id_cliente de referencia.

Recordar que ese id_cliente queda para el log y no filtra: lo que decide qué datos vuelven es el parámetro id_cliente de cada llamada. Una misma sesión sirve para consultar cualquier cliente.

Campo	Tipo	Obligatorio	Descripción
`usuario`	string	—	Modo A. Si viene, se ignoran los demás campos
`id_cliente`	int	SÍ (modo B)	Cliente de Portas al que va a ver esta sesión
`persona`	string	No	`cliente` (default) o `empleado`. Con `empleado` la sesión ve todos los clientes y `id_cliente` no se pide (si viene, se ignora)
`usuario_externo`	string	No	Identificador del usuario en el sistema que llama. Se guarda para auditoría: sin él, la sesión queda trazada solo a nivel aplicación

curl -X POST https://api.portascloud.ar/v1/web/sesion-delegada \
  -H "Authorization: Bearer <api-key>" \
  -H "Content-Type: application/json" \
  -d '{"id_cliente":84,"usuario_externo":"jperez@empresa.com"}'

# personal de Portas (ve todos los clientes):
  -d '{"persona":"empleado","usuario_externo":"jperez@empresa.com"}'

Respuesta 200

{
  "ok": true,
  "sesion": {
    "token": "0a7d...<64 hex>",
    "vence": "2026-08-11 07:26:11"
  },
  "persona": "cliente",
  "cliente": {
    "id_cliente": 84,
    "razon_social": "EMPRESA S.A."
  }
}

De acá en adelante, los dos modos son iguales

El token es el mismo tipo que devuelve el login: se manda en X-Sesion y no cambia nada más. Dura 12 horas, se cierra con POST /v1/web/logout y GET /v1/web/sesion lo responde igual que a un login propio, con origen: "delegada" en el bloque sesion.

La API key pasa a ser la credencial crítica. Portas no pide la clave del usuario final: confía en la key. En el modo B, además, quien la tenga puede abrir sesión para cualquier cliente. Así que la key no puede salir del backend del integrador — nunca en el navegador ni en código del lado del cliente. Cada sesión queda registrada con qué aplicación la abrió y con qué usuario.

Errores comunes

Código	Cuándo
`422 parametro_faltante`	modo B sin `id_cliente`
`422 parametro_invalido`	`persona` distinta de `cliente` / `empleado`
`404 cliente_inexistente`	ese `id_cliente` no existe en FreeWayNet. Se valida para que no se abran sesiones que después no devuelven nada y parecen un error de la API — no es un control de permisos
`403 cliente_inactivo`	el cliente está dado de baja
`403 missing_scope`	la key no tiene `web:write`

6. Listado de operaciones

GET/v1/web/oficios — scope web:read (sesión opcional)

Reemplaza /oficios, /oficio_traer_pag y /historial del sistema viejo. El cliente sale de la sesión, nunca del request: un usuario no puede pedir los legajos de otro cliente.

Parámetros (todos opcionales, por query string)

Parámetro	Tipo	Descripción
`historial`	0 \| 1	Sin él: operaciones en curso (oculta anuladas y cobradas). Con `1`: historial completo
`page`	int	Página, base 1 (default 1)
`limit`	int	Filas por página (default 25, máximo 200)
`legajo`	string	Número de legajo (`94961`) o id completo (`2026.04.94961`)
`referencia`	string	Búsqueda parcial
`mercaderia`	string	Búsqueda parcial
`tipo`	impo \| expo	Importación o exportación
`desde` / `hasta`	fecha	Rango de oficialización. Acepta `AAAA-MM-DD` o `DD-MM-AAAA`

Igual que el sistema viejo: los estados cerrados se ocultan solo si no hay filtros activos. Si el usuario busca algo puntual, lo encuentra aunque esté anulado o cobrado.

Respuesta 200

{
  "ok": true,
  "items": [
    {
      "id_carpeta": "2026.04.94961",
      "legajo": 94961,
      "referencia": "5186PT",
      "mercaderia": "NUT + KINDER + ROCHER",
      "tipo": "Importación",
      "via": "Maritima",
      "fecha_oficializacion": "2026-07-27",
      "nro_despacho_completo": "26001IC05015473Z",
      "factura_proveedor": "...",
      "responsable": "...",
      "tipo_mercaderia": "PRODUCTO TERMINADO",
      "unidad_negocio": "COMERCIAL",
      "estado": "Carga Liberada",
      "estado_pago": null,
      "canal": "verde",
      "documentos": { "total": 1, "hay": true, "completo": false }
    }
  ],
  "paginado": { "pagina": 1, "limite": 25, "total": 7809, "paginas": 313 },
  "listado": "en_curso"
}

Campos derivados

Campo	Cómo se calcula
`estado`	Estado del legajo, pisado por la autorización de pago si existe: 0 = Pago Visto COMEX, 1 = Pago Contabilizado, 2 = Pago Autorizado
`canal`	Canal aduanero: `verde` (1), `naranja` (2), `rojo` (3, 4, 6), o `null`
`documentos.completo`	`true` si están los 3 documentos del paquete (despacho AFIP, factura Portas y gastos)
`documentos.total`	Cantidad de documentos publicados (items 1, 9, 11, 12, 17, 18)

Rendimiento: por qué esta consulta va en dos pasos

Antes de "simplificar" esta consulta, leer esto. La columna estado de view_consulta_caratula_resumen no es una columna: es la función almacenada GetEstadoCliente(id_carpeta), que se ejecuta una vez por fila. Filtrar u ordenar por ella obliga a materializar la vista completa del cliente. Medido: 5,8 s.

Paso	Qué hace	Costo
1	Pagina sobre la tabla `carpetas` (indexada por cliente, fecha y anulada)	0,13 s
2	Trae el detalle solo de los ids de esa página: la función corre 25 veces, no 10.891	0,07 s
—	El `COUNT` total se cachea 5 minutos (cambia de a un legajo por vez)	0,00 s con hit

Equivalencia verificada: estado NOT IN ('Anulada','Anulada Aduana','Cobrada') devuelve 7797 legajos y anulada=0 AND anulada_aduana=0 devuelve 7809; la diferencia de 12 son exactamente los "Cobrada", que se descartan en el paso 2.

Además, el template viejo dispara 4 consultas por fila (resumen, dos conteos de documentos y autorización de pago): 80 round-trips para 20 filas. Acá son dos consultas fijas, independientemente del tamaño de la página.

7. Documentos y descargas

GET/v1/web/legajos/{id_carpeta}/documentos

GET/v1/web/legajos/{id_carpeta}/documentos/{familia}.{pdf|zip}

Ambos con scope web:read (sesión opcional). Reemplazan /oficios/descargas, bajar_pdf, bajar_factura y bajar_zip del sistema viejo.

Se apoyan en los entregables que la API ya genera (PDF consolidado o ZIP por familia): son exactamente los archivos que el cliente quiere bajar, ya unificados. No se listan los archivos sueltos del storage — el cliente nunca vio eso en el sistema viejo, y ahí hay documentación interna (los escaneos crudos Scan000NN.pdf).

Respuesta del listado

{
  "ok": true,
  "id_carpeta": "2026.04.94961",
  "documentos": [
    {
      "familia": "pdf_provisorio",
      "nombre": "Despacho provisorio",
      "formatos": [
        { "tipo": "pdf", "nombre": "...", "tamanio_bytes": 205824,
          "documentos": 1, "generado_en": "...",
          "url": "/v1/web/legajos/2026.04.94961/documentos/pdf_provisorio.pdf" }
      ]
    }
  ],
  "historico_en_sistema_anterior": false
}

Familias

Familia	Nombre presentable	Formatos	Equivale en el viejo a
`f3101`	Despacho / F3101	pdf	Despacho AFIP (item 1)
`pdf_provisorio`	Despacho provisorio	pdf	item 17
`factura_portas`	Factura Portas	pdf	item 11
`gastos`	Gastos de terceros	pdf, zip	item 9
`bcra`	Presentación BCRA	pdf	item 18
`djai`	DJAI / SIMI	pdf	item 12
`cert_importacion`	Certificado de Importación	pdf	—

Seguridad de las descargas

Diferencia importante con el sistema viejo. El escritorio Symfony arma el link de descarga con el path del archivo encriptado con una clave fija que está en el código fuente: quien conozca esa clave puede construir el link de cualquier archivo de cualquier cliente. Acá cada descarga valida que el legajo pertenezca al cliente de la sesión, y un legajo ajeno responde 404 (no 403: responder "prohibido" confirmaría que existe). Verificado: dueño 200 / ajeno 404 / sin sesión 401.

Cada descarga queda registrada en web_descargas (usuario, legajo, familia, IP, fecha). El sistema viejo no las registra en ningún lado.

Cobertura histórica

El campo historico_en_sistema_anterior vale true cuando el legajo no tiene entregables y es anterior a 2022, que es desde cuando el storage nuevo tiene contenido. No significa que el legajo no tenga documentos: significa que están en el sistema anterior.

Año	Legajos con documento (viejo)	Con entregable (nuevo)	Cobertura
2026	1.640	1.662	100%
2025	2.981	2.980	100%
2024	3.361	3.344	99,5%
2023	3.752	3.736	99,6%
2022	3.772	3.758	99,6%
2011–2021	~38.000	0	0% — falta backfill

8. Movimientos y notificaciones

Últimos movimientos

GET/v1/web/movimientos — scope web:read (sesión opcional)

Cronología de hitos y eventos de las operaciones del cliente. Reemplaza /ultimos_mov y /movimiento_traer_pag.

Parámetro	Descripción
`legajo`	Número de legajo
`desde` / `hasta`	Rango de fechas (`AAAA-MM-DD` o `DD-MM-AAAA`)
`page` / `limit`	Paginado (default 25, máx 200)

{
  "ok": true,
  "items": [
    { "id_carpeta": "2026.04.94961", "legajo": 94961, "referencia": "5186PT",
      "factura": "...", "fecha": "2026-07-27 00:00:00", "id_hito": 3,
      "hito": "OFICIALIZACION", "evento": "", "observacion": "" }
  ],
  "paginado": { "pagina": 1, "limite": 25, "total": 16734, "paginas": 670 }
}

El total se cachea 5 minutos, igual que en el listado de oficios: contar 16.734 movimientos cuesta 0,55 s y traer la página 0,29 s.

Notificaciones

GET/v1/web/notificaciones — scope web:read (sesión opcional)

POST/v1/web/notificaciones/{id}/visto — scope web:write (sesión opcional)

Es lo que el sistema viejo muestra en el sobre de la barra superior y en la pantalla /default/notificaciones: resumen.sin_ver es el número del badge. El viejo marca todo como visto al abrir la pantalla; acá eso lo hace el integrador con un POST .../visto por cada ítem que vino con "vista": false.

Las notificaciones son por usuario (notificaciones.id_usuario_web), no por cliente: dos personas de la misma empresa no ven lo mismo. De quién son (desde 2026-09-03):

Con sesión de usuario real (login propio o delegada por usuario): manda la sesión. Si además viene id_usuario_web y no coincide, 403 usuario_ajeno.
Sin sesión, o con sesión de integrador (abierta por id_cliente): hace falta id_usuario_web (alias id_usuario), el id de web_clientes_usuarios. Sin él, 422 parametro_faltante; inexistente 404 usuario_inexistente; inactivo 403 usuario_inactivo.

Es el mismo modelo de confianza que el id_cliente por parámetro del resto de la API: la barrera es la API key, y el integrador decide qué usuario suyo ve qué. Marcar una notificación de otro usuario devuelve 404 y la deja sin marcar.

Parámetro	Descripción
`id_usuario_web`	Usuario cuyas notificaciones se leen o marcan (ver arriba). En el `POST` se acepta por query string o en el cuerpo JSON
`sin_ver`	`1` para traer solo las no leídas
`page` / `limit`	Paginado (default 20, máx 100)

GET  /v1/web/notificaciones?id_usuario_web=727&sin_ver=1
POST /v1/web/notificaciones/2003624/visto?id_usuario_web=727

{
  "ok": true,
  "items": [
    { "id": 2003624, "tipo": "D", "titulo": "DIGITALIZACION PROVISORIA (93347)",
      "texto": "...", "id_carpeta": "2026.04.93347",
      "fecha": "2026-02-03 17:00:18", "vista": true, "fecha_vista": "..." }
  ],
  "resumen": { "total": 2, "sin_ver": 0 },
  "paginado": { "pagina": 1, "limite": 20 }
}

Se devuelve texto (plano) y no texto_html: el HTML viene de plantillas de mail del sistema viejo y no es seguro inyectarlo tal cual en la página.

POST .../visto es idempotente: marcar una ya leída responde 200.

Cliente	Sin caché	Con caché
Ferrero (7.809 operaciones)	0,63 s	0,09 s
Coca Cola FEMSA (10.651)	2,78 s	0,08 s

9b. Indicadores: Exportaciones / Importaciones

GET/v1/web/operaciones?tipo=expo|impo — scope web:read (sesión opcional)

Réplica de /dashboard_expo y /dashboard_impo: el estado actual de las operaciones activas, con las fechas del ciclo logístico y los semáforos.

Qué se considera "activa"

Condición	Detalle
Cliente	el de la sesión
Despachante	`NOT IN (40, 97, 96)`
Operación	2 = exportación, 1 = importación
Carga	sin finalizar, o finalizada hace menos de 30 días — esto es lo que hace que sea "estado actual" y no el historial completo
Estado	sin anuladas ni cobradas

Semáforos

Cada fila trae transito y liberacion con esta forma:

{ "dias": 12, "estado": "ok", "umbral": 30, "porcentaje": 100 }

estado	Significado
`ok`	dentro del plazo de referencia
`alerta`	hasta 3 días de exceso
`excedido`	más de 3 días de exceso
`en_curso`	todavía no terminó (cuenta desde el inicio hasta hoy)
`sin_datos`	falta la fecha de inicio

Umbrales de tránsito por vía (los del sistema viejo): aéreo 4 días, marítimo 30, terrestre y ferrocarril 10. Liberación: 7 días.

Corrección respecto del original: el sistema viejo pinta amarillo solo cuando el exceso es exactamente de 3 días (== 3), asi que un exceso de 1 o 2 días se veía rojo igual que uno de 40. Acá amarillo es "hasta 3 días de exceso" (<= 3), que es lo que la regla evidentemente quiso decir.

Rendimiento

El template viejo dispara seis consultas por fila (resumen, digitalizaciones, clientes, embarques, cargas y evento de ingreso a depósito). Acá son dos consultas fijas.

Además se fuerza IGNORE INDEX (oficializacion): sin eso MySQL resuelve el ORDER BY escaneando el índice de fecha hacia atrás hasta juntar la página, y con un filtro selectivo (25 exportaciones entre miles de carpetas) recorre medio índice — 4,0 s medidos, 2,0 s forzando el índice por cliente. La lista de ids y el total se cachean 5 minutos: la carga siguiente es de 0,06 s.

Verificado contra el sistema viejo: mismas operaciones, mismo orden y mismos valores (comparado fila por fila con la respuesta AJAX de dashboard_traer_pag).

9c. Cronograma de arribos

GET/v1/web/arribos?mes=AAAA-MM — scope web:read (sesión opcional)

Arribos del mes agrupados por día, listos para pintar un calendario. Réplica de /dashboard_calendario_proximos_arribos.

{
  "ok": true,
  "mes": "2026-07",
  "desde": "2026-06-24", "hasta": "2026-08-07",
  "dias": {
    "2026-07-25": [
      { "id_carpeta": "2026.04.94629", "legajo": 94629, "fecha": "2026-07-25",
        "estimada": false, "tipo": "Impo", "via": "Maritima", "vapor": "MAERSK ...",
        "canal": "Verde", "id_canal": 1, "terminal": "TERMINAL 1, 2 Y 3",
        "bl": "MAEU2601...", "referencia": "5148PT", "mercaderia": "...",
        "hora": "10:14", "etapa": "finalizada", "abierta": false,
        "detalle": {
          "tipo_operacion": "DESPACHO", "unidad_negocio": "...", "tipo_mercaderia": "...",
          "despacho": "26001IC04132920M", "fecha_oficializacion": "2026-07-13",
          "fecha_salida": "2026-07-05", "fecha_llegada": "2026-07-25", "fecha_esperada": null,
          "contenedores": "MSKU1234567", "contenedores_cant": 1,
          "kilos": 2.88, "bultos": 1,
          "control_documentacion": "2026-07-22 09:00:00", "verificacion": null,
          "coordinacion_carga": "2026-07-23 08:00:00", "aviso_carga": null,
          "inicio_carga": "2026-07-23 08:00:00", "finalizacion_carga": "2026-07-23 10:14:00",
          "responsable_documental": "...", "responsable_carga": "..."
        } }
    ]
  },
  "total": 94,
  "resumen": { "abiertas": 46, "estimadas": 0, "demoradas": 3 },
  "filtros_aplicados": { "solo_importacion": true, "solo_despachante": "04" }
}

Campo	Significado
`fecha`	`COALESCE(fecha_llegada, fecha_esperada_buque)`
`estimada`	`true` si no hay llegada real y se usó la esperada del buque
`abierta`	carga sin finalizar
`hora`	hora del hito de carga más avanzado que ya tenga fecha: finalización → inicio → coordinación. Misma prioridad que el sistema viejo
`etapa`	`finalizada` \| `demorada` \| `programada` \| `sin_coordinar`. Ver abajo
`detalle`	todo lo que el viejo mostraba sólo al hacer clic (popover)

Etapa	Condición
`finalizada`	hay `fecha_finalizacion_carga`
`demorada`	sin finalizar y la fecha prevista de carga (inicio → coordinación → aviso) ya pasó. Es la «sirena» del sistema viejo
`programada`	sin finalizar, con fecha prevista futura
`sin_coordinar`	sin ninguna fecha de carga cargada

El detalle no usa view_consulta_caratula_resumen. El viejo arma su popover con esa vista, que ejecuta GetEstadoCliente() por fila. Acá los mismos campos se leen de las tablas base (carpetas, carpetas_embarques, carpetas_cargas, carpetas_clientes) sin ese costo.

Restricciones heredadas del sistema viejo. El calendario original muestra solo importaciones (operacion = 1) y solo del despachante 04, ambas fijas en el código. Se conservaron para no cambiar lo que el usuario ve, pero quedan explícitas en filtros_aplicados por si se decide ampliarlas.

El rango incluye una semana antes y después del mes, porque la grilla del calendario muestra semanas completas. El resultado se cachea 5 minutos; la clave lleva un v con la versión del payload, que hay que subir cada vez que se le agregan campos.

El «0» del sistema viejo no era un número. Cada tarjeta del calendario original termina con (<b>responsable</b>), donde responsable es carpetas_cargas.id_empleado_carga2. Cuando no hay segundo responsable asignado —lo habitual— la línea queda en (), que al tamaño de la tarjeta se lee como un cero. No es una cantidad ni un cálculo: son paréntesis vacíos.

Rendimiento: el viejo tarda 1,92 s en cargar la página y después pide los datos por AJAX aparte; acá la pantalla completa sale en 0,07 s.

Concepto	Cómo se calcula
Inicio	`fecha_llegada`, o `fecha_esperada_buque` si no hay real
Fin	`fecha_finalizacion_carga`, o `fecha_inicio_carga`, o HOY (en curso)
Tope	10 días hábiles si la carga es suelta, 7 en contenedor
Días hábiles	del intervalo, descontando lo que figure en `freewaynet.feriados`

9e. Cronograma operativo

GET/v1/web/cronograma?mes=AAAA-MM — scope web:read (sesión opcional)

Los hitos de trabajo del mes agrupados por día. Réplica de /dashboard_cronograma (que se alimenta de calendario_actualizar_dashboard).

No confundir con /v1/web/arribos. Aquel ubica la carpeta por la fecha en que llega la mercadería; éste la ubica por las fechas de trabajo, y por eso una misma carpeta puede aparecer hasta tres veces en el mes. Además, el de arribos muestra sólo importaciones del despachante 04; éste no filtra: trae impo y expo, todos los despachantes.

Hito	`etiqueta`	Fecha en la que se ubica
`control_documentacion`	C.Doc.	`fecha_control_documentacion`
`verificacion`	Verif.	`fecha_verificacion`
`carga`	Carga	`COALESCE(finalizacion, inicio, coordinacion)`

Son exactamente los tres list_data.push() del template viejo. El COALESCE original tiene siete fechas, pero el viejo sólo dibuja la tarjeta de carga cuando hay finalización, inicio o coordinación (su variable $tiene_carga), asi que las otras cuatro nunca llegan a usarse: las tres de acá son equivalentes.

{
  "ok": true,
  "mes": "2026-07",
  "dias": {
    "2026-07-23": [
      { "id_carpeta": "2026.04.94424", "legajo": 94424,
        "hito": "carga", "etiqueta": "Carga",
        "fecha": "2026-07-23 10:14:00", "dia": "2026-07-23", "hora": "10:14",
        "etapa": "finalizada", "tipo": "Impo", "via": "Maritima",
        "canal": "Verde", "terminal": "TERMINAL 1, 2 Y 3",
        "referencia": "E-3024", "mercaderia": "...", "despacho": "26001IC04...",
        "peligrosa": false,
        "detalle": { "...": "igual que en /v1/web/arribos, más destinacion e ingreso_deposito" } }
    ]
  },
  "total": 12,
  "total_rango": 13,
  "resumen": { "carpetas": 11, "carga": 11, "verificacion": 0,
               "control_documentacion": 1, "demoradas": 0 },
  "filtros_aplicados": { "solo_importacion": false, "solo_despachante": null }
}

Campo	Significado
`etapa`	en el hito `carga`: `finalizada` / `demorada` / `programada` / `sin_coordinar`. En los otros dos hitos siempre `cumplido`: el registro de la fecha ya es el hecho
`peligrosa`	la carpeta tiene el evento 207 — CARGA PELIGROSA (IMO)
`total`	hitos del mes pedido (lo que muestra el encabezado)
`total_rango`	incluye la semana extra a cada lado que la grilla usa para completar las semanas

Diferencia de fondo: datos vivos

El viejo lee del espejo, no de la base. Esta pantalla consulta carpetas_cache, carpetas_cargas_cache, usuarios_cache, clientes_cache y view_consulta_caratula_resumen_cache: el espejo que se refresca por cron y que existe sólo para tapar la latencia contra Canadá. Acá se lee la base viva. Además, cuando una carpeta no está en el espejo, el viejo cae a la vista real fila por fila — una consulta a Argentina por cada una, que es de dónde sale buena parte de sus 2,2 s.

Fragilidad del original (no replicada). En el template viejo los tres list_data.push() están dentro de if(isset($cliente)), donde $cliente sale de clientes_cache. Si un cliente todavía no está en el espejo, su calendario sale vacío sin ningún mensaje. Un par de líneas más arriba, $terminal = $resumen->getTerminal() queda fuera de su if(isset($resumen)): una carpeta sin fila en la vista resumen tumba la pantalla entera.

	Viejo	Nuevo
Ver el calendario	2,18 s la página + 0,71 s el AJAX = 2,89 s	0,086 s
Origen	espejo `portas_cache` (+ fallback fila por fila)	base viva

Verificado: con ANDINA EMPAQUES en julio 2026, los dos sistemas devuelven los mismos 13 eventos — mismos legajos, mismos hitos, mismas horas.

Personal de Portas

El cronograma es de las pocas pantallas que el viejo muestra en las dos ramas del menú: la del cliente y la del empleado interno. Para el empleado no hay filtro de cliente, y cada tarjeta agrega la razón social (el campo cliente, que a un cliente se le manda vacío porque sería siempre el mismo).

Dos diferencias deliberadas con el viejo en la vista interna. (1) El viejo trae having fecha >= HOY - 10 dias: en julio 2026 eso son 86 cargas desde el 18, y navegar a un mes anterior no muestra nada. Acá se trae el mes completo (212 operaciones). (2) El viejo dibuja sólo el hito Carga para el interno — los push de Verif. y C.Doc. están detrás de hasCredential('Cliente'). Acá las tres personas ven los tres hitos (346 en total). Verificado: filtrando por carga y desde el 18, el nuevo da exactamente las mismas 86.

La página del interno son ~1,3 MB de HTML (386 tarjetas con su panel de detalle). Con mod_deflate viajan 57 KB y carga en 0,13 s.

9f. Comprobantes adeudados

GET/v1/web/comprobantes?page=&limit=&estado=todos|vencidos|a_vencer — scope web:read (sesión opcional)

Réplica de /comp_adeudados, que el sistema viejo pagina de a 10 por AJAX.

La tabla no se llama como el modelo. Los datos salen de la vista freewaynet.view_cli_comprobantes_adeudados. El modelo Symfony se llama CliComprobantesAdeudados y esa tabla no existe: el nombre real está en BaseCliComprobantesAdeudadosPeer::TABLE_NAME. Vale como regla general para todo el Symfony viejo.

Los importes son saldos, no totales de comprobante (desde 2026-08-10). total trae lo que queda por cobrar, ya descontadas las imputaciones; el valor original del comprobante viaja aparte en total_comprobante. Hasta esa fecha la vista devolvía el total del comprobante y los pagos parciales no se descontaban: la deuda salía 39 % más alta ($3.782 M contra $2.721 M reales, 548 de 2.509 comprobantes inflados). Se agregó la columna saldo a la vista, calculada igual que FreeWayNet (total_comprobante − ABS(SUM(importe)) de cli_comprobantes_imputaciones donde el comprobante figura como id_comprobante_afectado, excluyendo imputaciones de comprobantes anulados).

Consecuencia al comparar: contra el sistema viejo de portas.com.ar los montos no van a coincidir cuando hay cobros parciales — el viejo muestra el total. La referencia correcta es la consulta de cuentas corrientes de FreeWayNet.

Campo del item	Significado
`total`	saldo pendiente del comprobante (N/C en negativo). Es el que cuadra con FreeWayNet y el que suma `resumen.monto`
`total_comprobante`	total original del comprobante, sin descontar imputaciones. Sirve para mostrar «facturado vs adeudado»; es lo que informaba el sistema viejo
`vencido` / `dias_vencido`	calculados contra `CURDATE()`; el viejo los deja a ojo del lector
`cliente`	solo se manda al personal de Portas

"resumen": {
  "comprobantes": 113, "monto": 124380345.99,
  "vencidos": 27, "monto_vencido": 23531589.27,
  "mas_antiguo": "2026-07-22"
}

El resumen es del conjunto completo, no de la página: el viejo lista los comprobantes pero no dice cuánto suman ni cuáles vencieron. monto y monto_vencido suman saldos.

Verificado: Escandinavia, 22 comprobantes en los dos sistemas; los saldos contra FreeWayNet, 2.513 comprobantes sin una sola diferencia (2026-08-10). Rendimiento: viejo ~2 s la página + 7,7 s el AJAX; nuevo 0,99 s en frío y 0,08 s cacheado (se cachean por separado los totales y cada página).

9g. Tracking marítimo

GET/v1/web/tracking?estado=en_viaje|todos — scope web:read (sesión opcional)

Contenedores del cliente en seguimiento. Réplica de /tracking_maritimo. Sale de eta_contenedores + eta_contenedores_carpetas, la misma fuente que /v1/legajos/{id}/eta, y comparte con ese endpoint el parseo del json_completo (EtaGet::armarParaWeb()): posición, locaciones, eventos y trayectoria salen idénticos, sin duplicar la lógica.

Hoy no hay coordenadas. La posición GPS y la ruta las alimenta Searates vía el proceso Actualizar_Contenedores_ETA de FreeWayNet, y esa API key está vencida desde 2025-12. Las 52 filas de la tabla tienen json_completo vacío y ultima_pos_latitud/longitud en NULL. Lo que sí está actualizado es el eta (del 16-07 al 07-09 de 2026).

El endpoint está escrito para los dos escenarios: hoy devuelve la lista con ETA y posicion: null, y el día que vuelva la key empieza a devolver posición y trayectoria sin tocar una línea. tracking_disponible le dice a la pantalla si puede dibujar el mapa o si tiene que explicar por qué no hay.

Campo	Significado
`legajos[]`	un contenedor puede venir en más de una carpeta; se agrupa por contenedor y se acumulan los legajos, igual que el viejo, que indexa su lista por número de contenedor
`posicion`	`{lat, lng}` o `null`
`trayectoria`	pares `[lat, lng]` del viaje completo
`tracking_disponible`	`true` si al menos un contenedor tiene posición

Verificado: Ferrero, 52 contenedores — los 52 de la tabla, sin repetir (el JOIN por carpeta devolvía 64 filas).

9h. Reportes (Excel)

GET/v1/web/reportes/operaciones?formato=json|xlsx&… — scope web:read (sesión opcional)

Primer reporte del submenú Reportes. Una fila por ítem de despacho, con los datos declarados en María. Réplica de default/reportesOperaciones + generar_reporte_operaciones.

Parámetro	Valores
`cliente`	uno o varios `id_cliente` por comas (o `cliente[]=` repetido). Vale para los ocho reportes. Se suma al alcance de la sesión, no lo reemplaza
`tipo`	`impo` \| `expo`
`destinacion`	código exacto (IC04, EC01…)
`of_desde` / `of_hasta`	fecha de oficialización, AAAA-MM-DD
`carga_desde` / `carga_hasta`	finalización de carga, AAAA-MM-DD
`via`	lista por comas: Aerea, Maritima, Terrestre, Ferrocarril
`canal`	lista por comas: verde, naranja, rojo (rojo agrupa 3, 4 y 6)
`incluir_anuladas`	`1` para traerlas; por defecto se excluyen
`formato`	`json` (vista previa, 200 filas) o `xlsx` (hasta 20.000)

El Excel del sistema viejo no es un Excel

Lo que baja el viejo es un .xls que en realidad es MHTML: una página web con cabecera multipart/related y un armazón de «Excel single file web page» pegado en el template. Excel lo abre avisando que el formato no coincide con la extensión, y otras herramientas lo leen mal o no lo leen. Acá se genera OOXML de verdad con src/Xlsx.php: un ZIP con las piezas mínimas, sin dependencias, con encabezado en negrita y panel congelado. Validado con openpyxl sin advertencias.

Dos diferencias con el viejo

1. Las anuladas. El reporte viejo incluye las operaciones anuladas sin distinguirlas: entran en los totales sin avisar. Acá se excluyen por defecto, hay filtro para traerlas y una columna Anulada que las marca.

2. Datos vivos vs espejo. El viejo lee maria_caratula_cache y compañía. Comparando el mismo rango (Ferrero, julio 2026): con incluir_anuladas=1 el nuevo devuelve 77 despachos y el viejo 74, y no falta ninguno — los 3 de diferencia son los que el espejo todavía no tiene. Dos se oficializaron ese mismo día, pero uno es del 1 de julio: el espejo lo seguía sin tener 27 días después.

La pantalla, además, muestra el resultado antes de bajarlo: la del viejo es solo un formulario con un botón «Bajar Excel», sin forma de ver si el filtro quedó bien sin abrir el archivo.

Los otros reportes

Endpoint	Pantalla vieja	Fuente	Columnas
`/v1/web/reportes/status?tipo=impo\|expo`	Operaciones Status Impo / Expo	`view_operaciones_status`	56
`/v1/web/reportes/liquidaciones`	Liquidaciones	`view_consulta_liquidaciones`	27
`/v1/web/reportes/facturacion`	Facturacion x Items	`cli_comprobantes` + `cli_comprobantes_carpetas`	14
`/v1/web/reportes/bcra`	BCRA comunicacion A7466	`view_items_categoria_bcra`	44
`/v1/web/reportes/desvios`	Reporte Desvios Maritimos (Ferrero)	`view_cargas_maritimas_costos`	—
`/v1/web/reportes/comercial`	Reporte Comercial (Ferrero)	`view_consulta_items_comercial`	—
`/v1/web/reportes/items`	Items de Exp/Impo (Ferrero)	`view_consulta_items_expo`	43

«Liquidaciones x Area» (Ferrero) es el mismo endpoint de liquidaciones con area=1: agrega la columna Doc Transporte, única diferencia entre los dos reportes del viejo. El reporte de Desvíos del viejo no filtra por cliente (Where true); el nuevo filtra siempre por la sesión.

En el viejo Status Impo y Status Expo son dos pantallas con dos acciones; acá es un endpoint con un parámetro, porque la consulta es la misma.

El filtro por cliente

GET/v1/web/clientes — scope web:read + sesión

Es uno de los pocos que sigue exigiendo sesión, porque decide qué devolver según quién pregunta. Un integrador la obtiene con /v1/web/sesion-delegada y recibe la lista completa, que es lo que necesita para poblar su propio selector de clientes.

Devuelve id_cliente y razon_social para poblar el selector Cliente de los reportes, que acepta varios a la vez. Es el equivalente del cambiar_cliente del escritorio viejo, que la migración no había trasladado: hasta ahora el personal de Portas veía todas las operaciones sin forma de acotar el reporte a un cliente.

Solo el personal de Portas recibe la lista completa. A un usuario externo se le devuelve únicamente su propio cliente — la nómina de clientes de Portas no es información que le corresponda, y para él el filtro no tiene nada que elegir.

El filtro se suma al alcance, no lo reemplaza. El viejo concatena los ids crudos al SQL, sin placeholders y sin contrastarlos contra el alcance del usuario. Acá los ids que no son enteros se descartan, van como parámetros, y la condición de alcance sigue en el WHERE: un usuario cliente que mande el id de otro sigue sin ver nada.

La vista de Status no se puede filtrar desde afuera. view_operaciones_status termina en GROUP BY c.id_carpeta, y una vista con GROUP BY no se fusiona con la consulta que la usa: MySQL la materializa entera (95.000 filas, 27 LEFT JOIN y una subconsulta correlacionada) y recién después aplica el WHERE. Medido: 37 s filtrando por cliente y mes, y 43 s incluso pasándole la lista exacta de 59 id_carpeta — el truco de dos pasos que sirve en oficios acá no hace nada.

La solución es inyectar el filtro adentro, antes del GROUP BY: los mismos datos salen en 0,15 s. El cuerpo de la vista se lee en caliente con SHOW CREATE VIEW (en vez de copiar 6,6 KB de SQL que quedaría desactualizado) y si la vista cambiara de forma se cae a consultarla normalmente.

El sistema viejo convive con el problema: su template pone max_execution_time = 18000. Medido de punta a punta: 42,4 s contra 0,29 s.

«Illegal mix of collations». Filtrar por tipo en la vista de Status fallaba: no es una columna sino una expresión (IF(operacion = 1,'Impo','Expo')), asi que su collation es COERCIBLE igual que la del parámetro — ninguna gana y MySQL corta. Por el camino rápido el filtro pasa a ser operacion = 1|2 (un entero) y el problema desaparece; en el camino de respaldo se resuelve con un COLLATE explícito.

Verificado contra el sistema viejo

Reporte	Viejo	Nuevo	Resultado
Operaciones	74 despachos	77	ninguno falta; los 3 extra no están en el espejo
Status Impo	59 legajos / 42,4 s	59 / 0,29 s	idéntico
Liquidaciones	895 filas / 73 despachos	928 / 75	ninguno falta; los 2 extra son los mismos que faltan en el espejo
Facturacion x Items	94 filas / 47 legajos	94 / 47	idéntico
BCRA A7466	126 filas (Ferrero, jun 2026)	126	idéntico: 5.292 celdas comparadas una a una, 0 diferencias

BCRA comunicación A7466

Misma enfermedad que Status, otra causa. view_items_categoria_bcra no tiene GROUP BY, pero lleva una subconsulta correlacionada en el SELECT (nro_lna) y eso también impide fusionarla: filtrarla desde afuera materializa las ~670.000 filas (16 LEFT JOIN más un join por LEFT(POSICION_ARANCELARIA,14) sin índice). Medido: 40 s hasta pasándole la lista exacta de id_carpeta. Se aplica el mismo remedio — el cuerpo se lee con SHOW CREATE VIEW y las condiciones se agregan a su WHERE (acá van al final: no hay GROUP BY) —: un mes de Ferrero pasa de 40 s a 0,72 s; su historial completo (9.546 filas), 4,2 s.

Correcciones sobre el Excel viejo. (1) El viejo hacía dos consultas SQL por fila (fecha factura proveedor y fecha conocimiento de embarque); ahora son subconsultas del SELECT, una sola pasada. (2) Tenía las columnas geográficas corridas: bajo «Origen» iba la procedencia, bajo «Procedencia/Destino» el país destino y bajo «Pais Destino»… la razón social del destinatario. Cada dato va ahora bajo su rótulo y el destinatario tiene columna propia. (3) Anuladas excluidas por defecto, con filtro y columna, como en Operaciones. Al alcance global del interno se le impone of_desde (último año y medio) para no materializar el universo entero. Solo importaciones: la vista fija operacion = 1.

Endpoint	Pantalla	Parámetros	Notas
`GET /v1/web/rutas`	Rutas	—	rutas terrestres del cliente y sus hitos
`GET /v1/web/temporales`	Operaciones Temporales (Ferrero y Andina)	`estado`, `temporal`, `con_saldo`	base `portasco_moa_tagui` (mismo servidor MySQL, otro esquema). El proceso que la alimenta está congelado desde marzo 2025: la pantalla lo avisa con `ultima_actualizacion`; el viejo lo oculta.
`GET /v1/web/comercial`	Operaciones de Comercial (Ferrero)	`tipo`, `legajo`, `referencia`, `proveedor`, `producto`, `codigo`, `page`, `limit`	`view_consulta_items_comercial`, paginado por carpeta (12,3 s → 1,1 s)

9j. Menú interno (personal de Portas)

Pantallas de la persona empleado: sin filtro por cliente (WebAlcance global). Un cliente que pruebe estas URLs ve sus propios datos o nada, según la pantalla.

Endpoint	Pantalla	Parámetros	Notas
`GET /v1/web/arribos-internos`	Proximos Arribos / Sin Fecha Arribos	`vista=por_llegar\|sin_fecha`, `dias`	la del viejo estaba muerta desde 2022 (rango 2020–2022 fijo en el código)
`GET /v1/web/checklist`	Check List Impo / Expo	`tipo=impo\|expo`, `legajo`, `responsable`, `dias`	panel operativo completo; marca FC/BL/PL faltantes (el viejo listaba sin decir cuáles faltan y filtraba fijo 2022). SIMI/SIRA no se replicaron: sin vigencia.
`GET /v1/web/oficializaciones`	Oficializaciones x Cliente / Diarias / Mensuales	`vista=cliente\|diaria\|mensual`, `desde`, `hasta`	agrega directo contra `carpetas` (las vistas del viejo materializan por su GROUP BY interno); «x Cliente» excluye IDA4, las otras dos no — igual que el viejo, y ahora lo dice en pantalla
`GET /v1/web/rendiciones`	Rendiciones	`desde`, `hasta`, `evento`, `solo_excedidas`	corte por evento agregado: hoy el 62% excede su tope (topes desactualizados). Bug del viejo corregido: comparaba todo contra el tope de exportación.
`GET /v1/web/vacaciones`	Cronograma Vacaciones	`mes`	grilla persona × día (el viejo traía las 1.227 solicitudes por un `HAVING` mal puesto)
`GET /v1/web/carpetas`	Operaciones en Curso (interno)	`tipo`, `via`, `page`, `limit`	NO es `/v1/web/oficios`: no filtra por cliente y agrega filtro POR cliente

Persona	Pantalla vieja	Criterio
proveedor	`/clientes_oficios` («Operaciones del Clientes»)	`carpetas_clientes.id_proveedor_cliente` de la sesión
transportista	`/transp_oficios` (su única pantalla)	carpetas con remitos: `cli_comprobantes` tipo `N/E` + `cli_comprobantes_remitos.id_transportista`

HTTP	error	Cuándo
401	`missing_auth`	Falta el header Authorization
401	`invalid_key`	API key inexistente
401	`credenciales_invalidas`	Usuario o clave incorrectos
401	`usuario_inactivo`	El usuario existe pero está dado de baja
401	`sesion_invalida`	Token inexistente, vencido o cerrado
403	`inactive_key`	API key dada de baja
403	`missing_scope`	La key no tiene el scope necesario
422	`parametro_faltante`	Falta `usuario` o `clave`
502	`db_unreachable`	No responde la MySQL de FreeWayNet (red Portas)

Aspecto	Sistema viejo (Symfony)	Esta API
Token "recordarme"	`md5(usuario . password)` — derivable de las credenciales	32 bytes aleatorios, sin relación con la clave
Guardado del token	En claro	Solo el hash SHA-256
Cierre remoto	No existe	Sí: `cerrada = 1` en `web_sesiones`
Log de ingresos fallidos	No se registran	Sí, en `web_ingresos`
Comparación de clave	Igualdad simple	`hash_equals` (tiempo constante)

12. Endpoints previstos

Se agregan por fase, en orden de uso real medido sobre los accesos del sistema viejo. Esta página se actualiza con cada fase.

Fase	Endpoint	Reemplaza a	Estado
1	`POST /v1/web/login`	`/ingresar`	✔ disponible
1	`GET /v1/web/sesion`	sesión de Symfony	✔ disponible
1	`POST /v1/web/logout`	`/salir`	✔ disponible
2	`GET /v1/web/oficios`	`/oficios` + `oficio_traer_pag`	✔ disponible
2	`GET /v1/web/oficios?historial=1`	`/historial`	✔ disponible
3	`GET /v1/web/legajos/{id}/documentos`	listado de PDF	✔ disponible
3	`GET /v1/web/legajos/{id}/documentos/{familia}.{tipo}`	`bajar_pdf`, `bajar_factura`, `bajar_zip`	✔ disponible
4	`GET /v1/web/notificaciones` + `POST .../visto`	`/default/notificaciones`	✔ disponible
4	`GET /v1/web/movimientos`	`/ultimos_mov`	✔ disponible
5	`GET /v1/web/dashboard`	home del sistema viejo	✔ disponible
6	`POST /v1/web/no-migrada`	— (registra pantallas pedidas y ausentes)	✔ disponible
7	indicadores, cronogramas, comprobantes, tracking, reportes (9b–9h)	menú del cliente	✔ disponible
8	menú interno completo (9j)	pantallas del empleado	✔ disponible
9	`GET /v1/web/oficios-externos` (9k)	`/clientes_oficios` + `/transp_oficios`	✔ disponible
—	Mi Perfil	`/perfil`	pospuesto: define la política de escrituras
—	Tracking Terrestre (Ferrero)	`/tracking_terrestre`	bloqueado: requiere Remote MySQL en WnPower
—	Cash Flow / Lista Cash Flow	`/cashflow` + `/lista_cashflow`	no se migra: sin uso desde 2024-04, módulo de escritura
—	Tablero Materia Prima (Ferrero)	`/dashboard_kpi_diario`	no se migra: el del viejo es una maqueta con datos fijos de 2021
—	Proyectos / Trámites	`/proyectos`, `/tramites`	no se migra: base local de WnPower, 5 filas de prueba, cero accesos

1. Qué es esta API

2. Autenticación: dos niveles

Scopes

Cabecera adicional recomendada

2b. Filtrar por cliente: id_cliente

Si no se manda, no hay error

El parámetro ACOTA, nunca amplía

Documentos y descargas

3. Iniciar sesión

Cuerpo

Ejemplo

Respuesta 200

Las cuatro personas

Respuesta 401

Duración

3b. Sesión delegada — para trazabilidad

Modo A — por usuario de Portas

Errores del modo A

Modo B — por cliente (el que usa importas)

Respuesta 200

De acá en adelante, los dos modos son iguales

Errores comunes

4. Consultar la sesión vigente

Respuesta 200

Respuesta 401

5. Cerrar sesión

6. Listado de operaciones

Parámetros (todos opcionales, por query string)

Respuesta 200

Campos derivados

Rendimiento: por qué esta consulta va en dos pasos

7. Documentos y descargas

Respuesta del listado

Familias

Seguridad de las descargas

Cobertura histórica

8. Movimientos y notificaciones

Últimos movimientos

Notificaciones

9. Home (dashboard)

Caché

9b. Indicadores: Exportaciones / Importaciones

Qué se considera "activa"

Semáforos

Rendimiento

9c. Cronograma de arribos

9d. Tiempo de liberación (importación)

Tres correcciones respecto del original

9e. Cronograma operativo

Diferencia de fondo: datos vivos

Personal de Portas

9f. Comprobantes adeudados

9g. Tracking marítimo

9h. Reportes (Excel)

El Excel del sistema viejo no es un Excel

Dos diferencias con el viejo

Los otros reportes

El filtro por cliente

Verificado contra el sistema viejo

BCRA comunicación A7466

9i. Otras pantallas del cliente

9j. Menú interno (personal de Portas)

9k. Personas externas: proveedor y transportista

10. Errores

11. Notas de seguridad

12. Endpoints previstos

2b. Filtrar por cliente: `id_cliente`