API Portas — Móvil

1. Qué es esta API

El sistema viejo de Portas tiene una aplicación móvil (Symfony 1.4, app smatphone) con 18 módulos y tres perfiles de usuario distintos. Esta API expone esa misma funcionalidad como endpoints REST para que la reimplemente importas.com.ar.

Convive con la API Web (escritorio) en el mismo servicio y con la misma API key. Hay solapamiento deliberado: movimientos y comprobantes existen en las dos, porque en el sistema viejo también son pantallas distintas con filtros distintos.

2. Autenticación: API key + id_usuario

Son dos cosas separadas y hacen falta las dos:

Desde el 2026-09-08 id_usuario es el id_usuario de freewaynet.usuarios, el padrón de FreeWayNet (el mismo id que queda en id_usuario_alta de cada tabla). Importas mantiene un diccionario de sus usuarios contra ese padrón y es responsable de mandar el id correcto. La tabla del móvil viejo, web_clientes_usuarios, queda solo para el Symfony viejo mientras siga en uso. Portas no valida la clave: el login lo hace importas contra sus propias tablas.

Los endpoints exigen scope movil:read o movil:write según el caso. Por ahora también se aceptan web:read / web:write, para que la key que importas ya tiene en producción sirva sin cambios.

Errores propios de id_usuario

3. Personas y qué ve cada una

Qué ve la llamada no sale del usuario sino de los parámetros, igual que en la API Web. Importas decide qué parámetro manda para cada usuario suyo:

Si vienen los dos parámetros manda id_transportista. La persona proveedor del viejo no tiene equivalente todavía.

4. GET /v1/movil/usuario

Quién es el usuario y qué menú mostrarle. Es el equivalente de "abrir la sesión" del móvil viejo: se llama una vez al entrar.

{
  "ok": true,
  "usuario": {
    "id_usuario_web": 123,
    "id_cliente": 1167,
    "persona": "cliente",
    "usuario": "operaciones@ferrero.com",
    "nombre": "Juan Perez",
    "cargo": "Comercio Exterior",
    "razon_social": "FERRERO ARGENTINA S.A.",
    "web_carpeta": "ferrero",
    "id_proveedor_cliente": 0,
    "id_transportista": 0,
    "interno": null,
    "notificaciones": { "impo": true, "expo": false }
  },
  "credenciales": ["Movil", "Cliente"],
  "notificaciones": {
    "impo": true, "expo": false, "oficializacion": true,
    "finalizacion_carga": true, "permiso_cumplido": false,
    "arribo_mercaderia": true, "facturacion": true, "reclamo": false,
    "vencimiento_simi_djai": false, "vencimiento_temporal": false,
    "vencimiento_forzoso": false, "digitalizacion": true,
    "reintegro_aprobado": false, "coordinacion_transporte": false
  }
}

credenciales viene con los nombres que usan los security.yml del sistema viejo, para que el menú se pueda armar con el mismo criterio.

5. PATCH /v1/movil/usuario

La pantalla "Perfil": casillas de notificación y cambio de clave. Las dos partes son opcionales — se manda lo que se quiere cambiar.

{
  "id_usuario": 123,
  "notificaciones": { "facturacion": false, "arribo_mercaderia": true },
  "clave_actual": "laDeAhora",
  "clave_nueva": "unaNuevaDe8+"
}

Es un PATCH de verdad: las casillas que no se mandan quedan como estaban. (El formulario viejo apagaba todo lo que no viniera, que es correcto para un form completo y peligroso para una API.)

6. Notificaciones por evento

La grilla de eventos de la pantalla "Perfil": una columna para importación y otra para exportación.

{
  "ok": true,
  "eventos": {
    "importacion": [
      { "id_evento": 12, "nombre": "Arribo de mercadería", "sector": "Operaciones",
        "categoria": "", "color": "#3498db", "suscripto": true }
    ],
    "exportacion": [ ... ]
  }
}

{
  "id_usuario": 123,
  "eventos": [
    { "id_evento": 12, "operacion": 1, "suscripto": false },
    { "id_evento": 15, "operacion": 2, "suscripto": true }
  ]
}

operacion: 1 = importación, 2 = exportación. Es idempotente: se puede repetir el mismo PUT sin efectos raros.

7. Dispositivos (push)

Registro del token de notificaciones push. Reemplaza /registrar_movil.

{ "id_usuario": 123, "token": "fcm-token-del-dispositivo", "so": "android" }

so: android, ios o web. Se escriben las dos cosas que escribe el viejo: el token vigente en web_clientes_usuarios (que es el que lee FreeWayNet para mandar el aviso) y el historial en web_clientes_usuarios_token.

Lista los dispositivos registrados. El token se devuelve parcial (abc123…xyz789): alcanza para reconocerlo y no sirve para mandar push.

{ "id_usuario": 123, "token": "fcm-token-del-dispositivo" }

Da de baja el dispositivo. Si era el vigente, también lo apaga en el usuario — si no, FreeWayNet le seguiría mandando avisos a un teléfono desvinculado.

8. GET /v1/movil/movimientos

Módulo ultimos_mov: la cronología de hitos y eventos de las operaciones que el usuario puede ver.

{
  "ok": true,
  "items": [
    {
      "id_carpeta": "2026.04.94961",
      "legajo": 94961,
      "referencia": "PO-88213",
      "factura": "A-0001-00012345",
      "fecha": "2026-08-20 14:32:00",
      "id_hito": 4,
      "hito": "Oficialización",
      "evento": "Despacho oficializado",
      "observacion": ""
    }
  ],
  "paginado": { "pagina": 1, "limite": 25, "total": 412, "paginas": 17 }
}

Acepta todos los filtros comunes. limit va de 1 a 200 (25 por defecto).

9. GET /v1/movil/comprobantes-adeudados

Módulo comp_adeudados: lo que el cliente todavía debe.

estado: todos (default), vencidos, a_vencer. Más todos los filtros comunes.

{
  "ok": true,
  "items": [
    {
      "id_comprobante": "A-0001-00012345",
      "legajo": 94961,
      "id_carpeta": "2026.04.94961",
      "operacion": "22001EC01030375C",
      "referencia": "PO-88213",
      "mercaderia": "Chocolate",
      "factura_proveedor": "INV-2210",
      "fecha": "2026-07-15",
      "vencimiento": "2026-08-14",
      "total": 154320.55,
      "total_comprobante": 480000.00,
      "vencido": true,
      "dias_vencido": 10,
      "cliente": ""
    }
  ],
  "estado": "vencidos",
  "resumen": {
    "comprobantes": 12, "monto": 1854320.55,
    "vencidos": 5, "monto_vencido": 640210.00, "mas_antiguo": "2026-05-02"
  },
  "paginado": { "pagina": 1, "limite": 25, "total": 12, "paginas": 1 }
}

cliente viene con la razón social solo cuando la llamada es de un empleado (que ve varios clientes); para un cliente siempre es la propia y va vacío.

10. Circulares y newsletters

Los dos tablones de novedades. Misma forma para los dos.

El listado no trae el cuerpo (son textos largos con HTML): solo título, fecha, link y palabras clave. El detalle agrega texto y texto_html. q busca en título y palabras clave.

11. POST /v1/movil/legajos/{id}/fotos

Reemplaza las tres pantallas de fotos del móvil viejo (Foto Precinto, Inspección Mercadería y Subir Remito del transportista). Una sola llamada hace lo que antes eran dos pasos (subir y "Notificar"): crea el evento en la operación, guarda las fotos y deja la notificación al cliente pendiente.

curl -X POST "https://api.portascloud.ar/v1/movil/legajos/2026.04.94979/fotos?id_usuario=123" \
     -H "Authorization: Bearer $API_KEY" \
     -F tipo=precinto \
     -F "fotos[]=@IMG_20260828_110608.jpg" \
     -F "fotos[]=@IMG_20260828_110612.jpg"

# remito firmado por el transportista
curl -X POST "https://api.portascloud.ar/v1/movil/legajos/2026.04.94979/fotos?id_usuario=1022&id_transportista=240"      -H "Authorization: Bearer $API_KEY"      -F tipo=remito      -F "fotos[]=@remito_firmado.jpg"

Respuesta 201:

{
  "ok": true,
  "id_carpeta": "2026.04.94979",
  "tipo": "precinto",
  "id_evento": 176,
  "id_registro": 812345,
  "evento_nuevo": true,
  "observacion": "FOTO PRECINTO (94979) - 7381ST",
  "fotos": [
    { "id_archivo": 601234, "nombre_archivo": "IMG_20260828_110608.jpg",
      "tamanio_bytes": 190935, "download_url": "https://api.portascloud.ar/v1/d/<token>",
      "ya_existia": false }
  ],
  "notificacion": "pendiente"
}

Qué pasa después. Las fotos quedan en el storage de Portas (descargables ya por download_url), el Sincronizador las lleva a la red de Portas a la carpeta del evento (FreeWayNet las muestra con el clip) y el circuito de notificaciones le avisa al cliente con las fotos, respetando sus preferencias por evento — igual que cuando se cargaban desde el móvil viejo.

12. GET /v1/movil/instalacion — id_usuario del teléfono

La app no tiene login. Al instalarse genera un identificador propio (un UUID v4) y lo guarda en el teléfono. En cada arranque lo consulta acá y recibe el id_usuario vinculado a ese teléfono, que es el que después manda en el resto de los endpoints (por ejemplo, las posiciones de la sección 13).

No lleva id_usuario. Sirve la misma API key de la app que se usa para las posiciones GPS.

Respuestas

// Primera vez que arranca: el UUID no existía y se registró
{ "ok": true, "id_instalacion": "b1f6c0e2-7a41-4c1d-9a55-0d3e8f2a6c11", "id_usuario": null, "nuevo": true }

// Registrado pero Portas todavía no lo vinculó a un usuario
{ "ok": true, "id_instalacion": "b1f6c0e2-7a41-4c1d-9a55-0d3e8f2a6c11", "id_usuario": null, "nuevo": false }

// Vinculado: la app ya puede trabajar
{ "ok": true, "id_instalacion": "b1f6c0e2-7a41-4c1d-9a55-0d3e8f2a6c11", "id_usuario": 123, "nuevo": false }

Errores

13. Posiciones GPS del personal en la calle

La app captura la posición del teléfono y la envía para poder ver en un mapa, en tiempo real, dónde está el personal de Portas que trabaja en el puerto. Cada teléfono es de un solo usuario: id_usuario va una vez, en la raíz. Solo para personal de Portas (sin id_cliente ni id_transportista).

{
  "id_usuario": 123,
  "id_dispositivo": "b1f6c0e2-7a41-4c1d-9a55-0d3e8f2a6c11",
  "version_app": "1.0.3",
  "puntos": [
    {
      "lat": -34.581234,
      "lng": -58.370456,
      "fecha_hora": "2026-09-21T10:15:00-03:00",
      "precision_m": 8.5,
      "velocidad_kmh": 4.2,
      "rumbo": 270,
      "altitud_m": 12.0,
      "bateria": 76,
      "origen": "gps",
      "es_simulada": false,
      "id_carpeta": "2026.04.94961"
    }
  ]
}

{
  "ok": true,
  "recibidos": 3,
  "insertados": 2,
  "duplicados": 0,
  "rechazados": [ { "indice": 1, "motivo": "'fecha_hora' esta en el futuro" } ]
}

Un punto inválido no rechaza el lote: va a rechazados (con su posición en la lista) y el resto se guarda. Con un 200 la app puede borrar todo el lote de su cola local, incluidos los rechazados — reenviarlos daría el mismo resultado. Se rechazan: coordenadas fuera de rango o 0,0, fecha ilegible, fecha a más de 10 minutos en el futuro o de más de 30 días. Los opcionales fuera de rango se guardan vacíos sin rechazar el punto.

Las opciones de captura, para poder cambiarlas sin publicar una versión nueva de la app: cada cuánto capturar y el horario laboral del usuario. Pedirla al iniciar la app y después cada refrescar_config_min minutos; si no hay conexión, seguir con la última que se obtuvo.

{
  "ok": true,
  "id_usuario": 123,
  "rastreo_activo": true,
  "intervalo_movimiento_seg": 300,
  "intervalo_quieto_seg": 300,
  "intervalo_envio_seg": 300,
  "precision_max_m": null,
  "refrescar_config_min": 60,
  "max_puntos_por_envio": 500,
  "zona_horaria": "America/Argentina/Buenos_Aires",
  "fecha_servidor": "2026-09-21T10:16:05-03:00",
  "horario_propio": false,
  "horario": [
    { "dia_semana": 1, "dia": "lunes",  "desde": "08:00", "hasta": "18:00" },
    { "dia_semana": 2, "dia": "martes", "desde": "08:00", "hasta": "18:00" }
  ],
  "en_horario_ahora": true
}

Fuera del horario laboral la app no debe capturar (ni guardar en la lista). Lo que ya estaba en la lista sí se puede enviar fuera de horario. Si igual llega un punto capturado fuera de horario, el POST lo guarda (no es un error ni va a rechazados); el horario se aplica al mostrar: /posiciones/ultimas y /posiciones dejan afuera esos puntos, salvo que se pidan con incluir_fuera_de_horario=1. Cada punto devuelto trae en_horario.

La última posición conocida de cada usuario: lo que dibuja el mapa en vivo. id_usuario es opcional y aquí es el usuario que se busca: con él, items trae solo su última posición (o viene vacío si no reportó o lo último es de fuera de horario); sin él, la de todos. max_minutos (opcional) deja afuera a los que no reportan desde hace más de eso.

{
  "ok": true,
  "fecha_servidor": "2026-09-21T10:16:05-03:00",
  "items": [
    {
      "id_usuario": 123, "nombre": "JUAN PEREZ",
      "lat": -34.581234, "lng": -58.370456,
      "fecha_hora": "2026-09-21T10:15:00-03:00",
      "precision_m": 8.5, "velocidad_kmh": 4.2, "rumbo": 270, "bateria": 76,
      "origen": "gps", "es_simulada": false, "id_carpeta": "2026.04.94961",
      "id_dispositivo": "b1f6c0e2-...", "version_app": "1.0.3",
      "fecha_recepcion": "2026-09-21T10:15:04-03:00",
      "segundos_sin_reportar": 65
    }
  ]
}

El recorrido de un usuario, en orden cronológico. id_usuario es quien consulta; id_usuario_consultado, de quién es el recorrido. Sin fechas devuelve lo que va del día. Rango máximo 31 días y 5000 puntos ("truncado": true si había más). precision_max descarta los puntos con error mayor a esos metros.

14. Rendiciones y pedidos de fondos (empleado)

Reemplaza las pantallas Rendir, Historial Rendiciones, Estado de Rendiciones, Pedir Fondo e Historial Pedido Fondo del menú del empleado. Son solo para personal de Portas, es decir, llamadas sin id_cliente ni id_transportista. Cada empleado ve y carga solo lo suyo.

Hay dos tipos de registro, que la API distingue con tipo:

Forma de un registro

Es la misma en el listado, en el detalle y en la respuesta del alta. Trae todo lo que muestra la tarjeta: el legajo con su operación, vía, canal y cliente; quién aprobó; y los topes. Con eso la app dibuja la tarjeta sin hacer otras llamadas.

{
  "id_registro": 63699,
  "tipo": "rendicion",
  "estado": "I", "estado_texto": "Informado",
  "en_orden_de_pago": false, "id_comprobante": null,
  "concepto": { "id_evento": 114, "nombre": "PESADA" },
  "importe": 90000.00,
  "observacion": "Hablamos con aduana para liberar sin pesar...",
  "fecha": "2026-10-19 12:10:00",
  "posicion_gps": "-34.5981,-58.3702",
  "solicitante": { "id_usuario": 4, "nombre": "MIGUEL SARAVIA" },
  "aprobacion":  { "id_usuario": null, "nombre": null, "fecha": null },
  "legajo": {
    "id_carpeta": "2026.04.95692", "nro_orden": 95692,
    "operacion": "impo", "via": "maritima", "canal": "verde",
    "cliente": "GESTAMP BAIRES S.A."
  },
  "topes": {
    "concepto": 40000.00, "carpeta": 12000.00,
    "rendido_concepto_en_carpeta": 90000.00, "rendido_carpeta": 103000.00,
    "supera_tope_concepto": true, "supera_tope_carpeta": true
  }
}

Devuelve la lista para el combo de concepto al cargar una rendición. Depende del legajo, porque los topes son distintos para importación y exportación. Un vale no la necesita.

{
  "ok": true,
  "legajo": { "id_carpeta": "2026.04.95916", "nro_orden": 95916, "operacion": "impo", "cliente": "MOTOCAR IMPORTS S.A." },
  "conceptos": [
    { "id_evento": 177, "nombre": "VIAJE NICOLAS",        "tope": 0,    "propio": true  },
    { "id_evento": 111, "nombre": "PRESENTACION / CANAL", "tope": 5000, "propio": false },
    { "id_evento": 113, "nombre": "SALIDA",               "tope": 6000, "propio": false }
  ],
  "nota": "El tope solo precarga el importe: no bloquea el alta."
}

tope sirve para precargar el importe al elegir el concepto, como hacía el sistema viejo. El empleado lo puede cambiar, y un importe mayor al tope no se rechaza. Los conceptos con propio: true son los que solo ve ese usuario; van primero en la lista.

{ "ok": true, "vista": "pendientes", "items": [ { ...registro... } ],
  "paginado": { "pagina": 1, "limite": 25, "total": 93, "paginas": 4 } }

Cada pantalla del menú viejo se arma así:

Devuelve un registro: { "ok": true, "rendicion": { ...registro... } }. Si es de otro usuario responde 404, igual que si no existiera.

Devuelve el estado de cuenta del empleado; es la pantalla Estado de Rendiciones.

{ "ok": true, "saldo": {
    "vales_aprobados": 42368670.55, "rendido_aprobado": 41048649.36,
    "saldo": 1320021.19,
    "vales_pendientes": 0, "rendido_pendiente": 1159500,
    "excluye": "MOVILIDAD CABIFY (evento 115)" } }

saldo es lo aprobado en vales menos lo aprobado en rendiciones. Si es positivo, el empleado recibió plata que todavía no rindió. Los campos *_pendientes son lo que todavía espera aprobación. Usa el mismo criterio que el reporte de cuenta corriente de Portas.

// Rendición
{ "id_usuario": 88, "tipo": "rendicion", "id_carpeta": "2026.04.95916", "id_evento": 111,
  "importe": 5000, "observacion": "Canal rojo", "posicion_gps": "-34.5981,-58.3702" }

// Vale (pedido de fondos): sin concepto y con legajo opcional
{ "id_usuario": 4, "tipo": "vale", "importe": 150000, "observacion": "Pesadas y movilidad" }

La fecha la pone el servidor. Responde 201 con el registro, que ya queda en estado I, y con la lista mails: los aprobadores de Portas reciben un mail que les avisa que hay algo nuevo para aprobar.

{ "id_usuario": 88, "importe": 4500, "observacion": "Corrijo el importe" }

Corrige un registro propio mientras espera aprobación.

• Se mandan solo los campos que cambian: id_carpeta, id_evento, importe, observacion o posicion_gps. El tipo no se puede cambiar.
• La API vuelve a avisar a los aprobadores, con el registro marcado «MODIFICADA».
• La fecha pasa a ser la de la corrección, como en el sistema viejo.
• No hay DELETE: lo que se cargó mal lo rechaza el aprobador.

Errores propios

15. Cargas y liberación sin QR (empleado)

Reemplaza Pendientes Liberación y la pantalla Liberar Mercadería del sistema viejo. Sirve para liberar una carga sin escanear el QR de la nota de entrega: el empleado carga el canal, el inicio y el fin de carga. Es solo para personal de Portas, es decir, llamadas sin id_cliente ni id_transportista.

Cuando se carga el fin de carga, el cliente recibe exactamente los mismos avisos que con el QR: la notificación «MERCADERIA LIBERADA» a sus usuarios suscriptos y los mails (incluidos los de recepción y descarga de Ferrero).

Devuelve hasta 100 cargas, cada una con esta forma:

{
  "id_carpeta": "2026.04.95860",
  "legajo": 95860,
  "operacion": "impo",
  "via": "Terrestre",
  "cliente": "...",
  "referencia": "MM091026 4500880866",
  "mercaderia": "RESINA PET",
  "oficializacion": "2026-10-19",
  "despacho": "26001IC05022834P",
  "responsable": "AGUSTIN WUTHRICH",
  "estado": "Carga Liberada",
  "canal": { "id": 1, "nombre": "Verde" },
  "fechas": {
    "control_documentacion": null, "verificacion": null, "aviso_carga": "2026-10-20 09:00:00",
    "inicio_carga": "2026-10-20 10:15:00", "finalizacion_carga": null
  },
  "empleados": [ { "id_usuario": 88, "nombre": "NICOLAS ALVARO ARCE" } ]
}

Una carga, con la misma forma, más un bloque liberacion que dice qué admite hoy, para que la app arme la pantalla sin repetir las reglas:

"liberacion": {
  "liberada": false,
  "puede_elegir_canal": true,
  "canales": ["verde", "naranja", "rojo", "sin_canal"],
  "requiere_canal": true,
  "requiere_inicio": false,
  "ezeiza_impo_aereo": false,
  "fechas_desde": "2026-10-11 15:30",
  "fechas_hasta": "2026-10-21 15:30"
}

{ "id_usuario": 88, "canal": "verde", "inicio": "2026-10-21 10:15", "finalizacion": "2026-10-21 15:20" }

Todos los campos son opcionales, pero hay que mandar al menos uno. Se puede liberar en una sola llamada o en dos (primero el inicio, después el fin).

• Canal: verde, naranja, rojo o sin_canal. Solo se puede cargar si la carpeta no tiene canal o si la vía es aérea (puede_elegir_canal).
• Fechas: AAAA-MM-DD HH:MM, hora de Argentina. Valen hasta 10 días para atrás y no a futuro. Lo que ya estaba cargado no se pisa: un inicio que ya existía se ignora y se informa en ignorados.
• Para finalizar hace falta canal (el de la carpeta, uno elegido en la misma llamada o sin_canal explícito) e inicio de carga. El fin no puede ser anterior al inicio. En Ezeiza impo aéreo, como con el QR, si falta el inicio se toma igual al fin.

Respuesta:

{
  "cambios": ["canal", "finalizacion"],
  "ignorados": [],
  "avisos": { "notificaciones": 3, "mails": [ { "para": "...", "asunto": "MERCADERIA LIBERADA (95860) - ...", "enviado": true, "detalle": "" } ] },
  "carga": { ...la carga actualizada, con su bloque liberacion... }
}

Errores propios

16. Texto del legajo (empleado)

Reemplaza la pantalla Texto de la carátula del sistema viejo: notas libres del personal en puerto sobre un legajo (demoras, problemas en la terminal, lo que pasó en la carga). Cada nota es un evento 154 «OBSERVACIÓN PUERTO» del legajo y se ve en FreeWayNet con su autor. Es un evento interno: el cliente no lo ve ni recibe aviso. Por eso es solo para personal de Portas.

Las notas del legajo, de la más nueva a la más vieja (hasta 200), de todos los autores:

{
  "ok": true,
  "id_carpeta": "2026.04.95692",
  "legajo": 95692,
  "textos": [
    { "id_registro": 847210, "fecha": "2026-10-19 13:48:01",
      "texto": "Día 19-10 finalmente se están liberando los últimos contenedores...",
      "autor": { "id_usuario": 4, "nombre": "MIGUEL SARAVIA" } }
  ]
}

{ "id_usuario": 4, "texto": "Se presentaron los camiones a las 9 hs..." }

Responde 201 con la nota creada ("repetido": false). El texto admite hasta 4000 caracteres; la fecha es la del servidor.

Errores propios

17. Comprobantes ODP del empleado

Reemplaza Comprobantes (Cheques) e Historial Comprobantes del sistema viejo: las Órdenes de Pago en las que el usuario figura como empleado, con los cheques y los gastos por legajo. Es solo consulta y solo para personal de Portas: cada empleado ve únicamente sus O/P. El botón «informar» y la carga de gastos sobre la O/P del viejo no se usan, así que no se migran.

{
  "ok": true,
  "vista": "historial",
  "items": [
    { "id_comprobante": "O/P X0001-00048573", "numero": "X0001-00048573",
      "fecha": "2026-10-14", "fecha_rendicion": "2026-10-14", "rendido": true,
      "total": 607560, "beneficiario": "",
      "cheques": ["027-0001-86119430"], "gastos": 1, "legajos": [95822] }
  ],
  "paginado": { "pagina": 1, "limite": 25, "total": 6673, "paginas": 267 }
}

Una O/P completa. En la base el número es O/P X0002-00029330; en la URL va sin el «O/P », como lo devuelve el campo numero: X0002-00029330.

{
  "ok": true,
  "comprobante": {
    "id_comprobante": "O/P X0002-00029330", "numero": "X0002-00029330",
    "fecha": "2026-10-09", "fecha_rendicion": "2026-10-09", "rendido": true,
    "total": 40520, "beneficiario": "",
    "cheques": [ { "nro_cheque": "027-0001-86119430", "fecha": "2026-10-14", "diferido": "2026-10-14",
                   "importe": 607560, "cuenta": "Cta Cte SuperVielle S.A." } ],
    "gastos": [
      { "item": 1, "id_carpeta": "2026.04.94885", "legajo": 94885, "concepto": "MOVILIDAD",
        "importe": 1150, "observacion": "", "id_rendicion": 63273 }
    ]
  }
}

id_rendicion es la rendición de la que salió el gasto (sección 14), o null si se cargó directo en la O/P.

Errores propios

18. Filtros comunes de operación

Los aceptan /movil/movimientos y /movil/comprobantes-adeudados (y los listados de las fases siguientes). Son los mismos catorce filtros que el Symfony viejo repetía en cada módulo.

Las fechas se aceptan como AAAA-MM-DD o DD/MM/AAAA. Un filtro mal escrito se ignora en silencio, igual que en el sistema viejo.

19. Errores

Formato único, igual que el resto de la API:

{ "ok": false, "error": "usuario_inexistente", "message": "No existe el usuario web 999" }

20. Lo que falta: endpoints planificados

Esta tabla recorre el menú del empleado del sistema viejo, punto por punto, con lo que ya existe y lo que falta. Los endpoints planificados todavía no existen: la ruta y los campos son una propuesta y pueden cambiar al implementarlos. El uso que se menciona es el del sistema viejo en las últimas 7 semanas (del 31/08 al 20/10/2026).

A. Viajes (a confirmar con Portas)

Parte de lo que hacían los viajes ya lo cubre el GPS en vivo (sección 13).

Fuera del menú del empleado