Deja de pagar por cargar tipos de cambio en JD Edwards: así lo automaticé con el Orchestrator y la API del BCE

Son las 8:03 de la mañana. Antes del café, antes del primer email, alguien en el departamento financiero de tu empresa ya ha abierto una pestaña del Banco Central, ha copiado diez o doce tipos de cambio, y los ha pegado, uno por uno, en JD Edwards. Lo he visto con mis propios ojos. En más de una empresa. Y no es un caso aislado: hay compañías que llevan años pagando una licencia externa solo para hacer exactamente esto, algo que su propio ERP ya sabe hacer si alguien se sienta a construirlo. Nadie discute si cargar tipos de cambio a mano tiene sentido. Se hace porque siempre se ha hecho así, o porque en su momento alguien compró una herramienta y ahí quedó, generando una factura mensual que ya nadie revisa. El coste real es el tiempo, el riesgo de un dedo torpe cambiando un decimal, y la persona que cada mañana interrumpe lo que estaba haciendo para teclear números en lugar de pensar.

Lo que voy a enseñar en mis próximas formaciones

En las próximas semanas doy formación de Orchestrator a tres empresas distintas, y este año cambio el ejemplo de siempre. Hasta ahora usaba una fuente de datos genérica para mostrar la carga de tipos de cambio. Esta vez uso la API pública y gratuita del Banco Central Europeo, y monto el flujo completo delante de los alumnos, usando prácticamente todos los tipos de UDO que ofrece el Orchestrator en un solo ejemplo. Así queda el flujo, paso a paso:

1. Un Connector que llama a la API del BCE.
2. Un Custom Request tipo “Create Array” que convierte el CSV que devuelve el BCE en un array manejable.
3. Un Data Request que revisa si ya existe una carga previa de tipos de cambio para el día, y devuelve un array con lo que encuentre.
4. Una Rule que pregunta: ¿hay algo cargado ya? Si lo hay, itera y lo elimina con un Form Request, para no duplicar ni dejar basura.
5. Una Rule que itera sobre el array de tipos de cambio nuevos.
6. Un Form Request contra la P0015A que carga cada tipo de cambio, uno a uno.
7. Un Report, el R00151P, filtrado por la fecha del día, que genera el informe con todo lo cargado.
8. Una Notification que envía ese informe a los responsables, confirmando que la carga del día se hizo y que pueden revisarla.

Un Connector, un Custom Request, un Data Request, dos Rules, dos Form Requests, un Report y una Notification. Si quieres enseñarle a alguien de qué es capaz el Orchestrator en un solo ejercicio, cuesta encontrar un ejemplo mejor.

Cómo se llama exactamente a la API del BCE

La parte que más preguntan mis alumnos es cómo se conecta el Connector a la fuente. El Banco Central Europeo publica sus tipos de referencia a través de su API SDMX, y permite pedir directamente el resultado en CSV en lugar del XML por defecto, lo que simplifica mucho el trabajo del Custom Request después. La llamada, para pedir todos los tipos de cambio frente al euro de un día concreto, es así:

GET https://data-api.ecb.europa.eu/service/data/EXR/D..EUR.SP00.A?format=csvdata&startPeriod=2026-08-25&endPeriod=2026-08-25

Un vistazo rápido a la clave D..EUR.SP00.A: la D indica frecuencia diaria, los dos puntos seguidos dejan la divisa sin especificar para traer todas las disponibles, EUR es la divisa base, y SP00.A identifica el tipo de referencia estándar publicado por el BCE. El parámetro format=csvdata es el que hace que la respuesta llegue como CSV en lugar de XML, listo para que el Custom Request “Create Array” lo convierta en algo que el resto del orquestamiento pueda recorrer. Nada de esto pide clave de acceso ni suscripción. Es una API pública, mantenida por un banco central, y probablemente más fiable que la mayoría de fuentes de pago que sigo viendo contratadas.

El impacto real, en números que entiende un director financiero

Aquí es donde toca hablar en el idioma que de verdad importa en un comité de dirección. Una carga manual bien hecha suele llevarse entre 15 y 30 minutos cada mañana, dependiendo de cuántas divisas maneje la empresa. Multiplícalo por los días laborables del año y ya estás hablando de varias jornadas completas dedicadas, en exclusiva, a copiar y pegar números. O sumarle el coste de una herramienta externa que muchas compañías siguen pagando mes a mes por resolver algo que su propio JD Edwards ya puede resolver solo. Y el error humano no es un riesgo teórico. Un decimal mal puesto en un tipo de cambio no se queda en una hoja de Excel: se propaga a facturación intercompañía, a valoraciones de inventario, a resultados financieros. Cuando automatizas esto con el Orchestrator, ese riesgo desaparece del todo, porque la máquina no se distrae ni comete errores de tecleo.

Por qué enseño con problemas reales, no con demos

Cada vez que doy formación, pido a los alumnos que traigan sus propios problemas. No hago el ejercicio de la carga de tipos de cambio porque sea el único caso de uso posible del Orchestrator, lo hago porque es el punto de partida perfecto: en un par de horas, todos entienden Connectors, Custom Requests, Data Requests, Rules, Form Requests, Reports y Notifications trabajando juntos, resolviendo algo que su empresa necesita de verdad. A partir de ahí se genera lo que yo llamo un círculo virtuoso: el alumno presta más atención porque el ejemplo es suyo, se compromete más porque ve el resultado aplicado a su propio sistema, y yo, de paso, me enfrento a problemas reales de negocios distintos que me hacen mejor arquitecto en cada formación. Si tu empresa todavía carga tipos de cambio a mano, o sigue pagando por algo que el Orchestrator resuelve gratis, dímelo. Hay muchas más automatizaciones de este estilo esperando a que alguien se siente a construirlas, y me encantaría que la tuya fuera la próxima que resolvamos juntos, ya sea en una formación, en una arquitectura a medida o en una sesión de consultoría.