Integración Viajes

Web services para la integración con la plataforma de la agencia de viajes: consulta y creación de terceros proveedores, y registro de reservas (tiquetes, hospedajes y conceptos administrativos) contra una solicitud de viaje (travel.business) ya existente en DrivErp.

Requests

Todas las peticiones se realizan bajo el prefijo /travel:

https://<instancia>/travel/...

Importante: estos endpoints usan el mecanismo estándar de rutas type="json" de Odoo y no leen el cuerpo JSON de forma directa, por lo que el cuerpo debe ser el envoltorio JSON-RPC 2.0 completo, con los datos de la petición dentro de la llave params:

curl -X POST 'https://<instancia>/travel/partner-info' \
  -H 'Content-Type: application/json' \
  -d '{
    "jsonrpc": "2.0",
    "method": "call",
    "id": null,
    "params": {
      "user": "<usuario>",
      "passwd": "<contraseña>",
      "reference": "900123456"
    }
  }'

Enviar los campos en el nivel superior del JSON, sin envolver en params, resulta en parámetros faltantes y la petición falla.

Las rutas tienen habilitado CORS (Access-Control-Allow-Origin: *) y CSRF deshabilitado, pensado para que la plataforma de la agencia de viajes pueda invocarlas directamente desde su propia aplicación web sin pasar por un backend intermedio.

Vea la guía Autenticación para las credenciales requeridas y Estructura de las respuestas para el formato de la respuesta, que varía por endpoint.

Autenticación

Esta integración no usa token de sesión: las credenciales se envían en params en cada petición, en los campos user y passwd.

• Las credenciales son un par fijo por entorno, definido en el código del módulo (controllers/utils.py) — no se configuran desde Ajustes ni varían por compañía.
• passwd se compara en texto plano, sin ningún hash.
• El mismo par de credenciales aplica a los tres endpoints (/partner-info, /supplier-create, /reserve).

curl -X POST 'https://<instancia>/travel/partner-info' \
  -H 'Content-Type: application/json' \
  -d '{
    "jsonrpc": "2.0",
    "method": "call",
    "id": null,
    "params": {
      "user": "<usuario>",
      "passwd": "<contraseña>",
      "reference": "900123456"
    }
  }'

Si user/passwd no coinciden, la petición no llega a construir la respuesta habitual del endpoint: result llega directamente como el texto de la excepción HTTP, con el estado HTTP de la respuesta en 200 (ver guía Estructura de las respuestas):

{
  "jsonrpc": "2.0",
  "id": null,
  "result": "401 Unauthorized: The server could not verify that you are authorized to access the URL requested. You either supplied the wrong credentials (e.g. a bad password), or your browser doesn't understand how to supply the credentials required."
}

Solicite a su consultor funcional o técnico de DrivErp el usuario y la contraseña habilitados para su instancia.

Estructura de las respuestas

Toda petición devuelve el envoltorio JSON-RPC estándar (jsonrpc, id, result) con estado HTTP 200. La forma de result no es uniforme: cada endpoint tiene su propio formato de éxito, y las validaciones básicas (credenciales, campos vacíos o con palabras no permitidas) devuelven directamente el texto de la excepción en lugar de un objeto — ver guía Autenticación.

/partner-info

Es el único endpoint que no usa el patrón status_code/novelty. Si el tercero existe, result es directamente el objeto con sus datos:

{
  "jsonrpc": "2.0",
  "id": null,
  "result": {
    "partner_ref": "900123456",
    "partner_name": "Proveedor de ejemplo S.A.S"
  }
}

Si no existe, result es el texto de un error 404:

{
  "jsonrpc": "2.0",
  "id": null,
  "result": "404 Not Found: partner 900123456 not found"
}

/supplier-create y /reserve

Estos sí siguen el patrón {status_code, novelty, ...}: aquí solo existen los estados "00" (éxito) y "99" (rechazado), no existe un estado intermedio de "éxito con novedad".

{
  "jsonrpc": "2.0",
  "id": null,
  "result": {
    "supplier_ref": "900123456",
    "supplier_name": "Proveedor de ejemplo S.A.S",
    "status_code": "00",
    "novelty": {}
  }
}

En /supplier-create, algunas validaciones son independientes entre sí y pueden acumularse en un mismo novelty (por ejemplo, tercero ya existente junto con ciudad no encontrada):

{
  "jsonrpc": "2.0",
  "id": null,
  "result": {
    "supplier_ref": "900123456",
    "supplier_name": "Proveedor de ejemplo S.A.S",
    "status_code": "99",
    "novelty": {
      "E04": "error on creation supplier 900123456 already on ERP",
      "N05": "city code not found res.country.city()"
    }
  }
}

Nótese el texto de N05 en el ejemplo: por una particularidad del código, al construir ese mensaje la variable ya fue reemplazada por el resultado (vacío) de la búsqueda de la ciudad, así que el mensaje real no repite el código de ciudad enviado — muestra la representación de un recordset vacío en su lugar.

Códigos de novedad

Los códigos de novedad se agrupan por prefijo (fuente: controllers/utils.py, NOVELTY_CODES):