Lic. Carlos Enrique Loria Beeche
En muchos de los sistemas administrativos que he desarrollado, el tipo de cambio de referencia del Banco Central de Costa Rica es un dato fundamental.
No necesariamente porque todas las operaciones deban realizarse exactamente a ese tipo de cambio.
De hecho, nuestros sistemas permiten registrar un tipo de cambio específico para una transacción cuando la operación bancaria realmente se realizó a una cotización diferente. Esto ocurre con frecuencia: una transferencia, una compra de dólares, un pago, un depósito o cualquier otra operación puede haberse efectuado utilizando el tipo de cambio particular de una entidad financiera.
Pero para una enorme cantidad de operaciones necesitamos primero un valor de referencia.
Y para ese valor predeterminado —el default de muchas transacciones— utilizamos normalmente el tipo de cambio oficial de referencia publicado por el Banco Central de Costa Rica.
Un dato pequeño que termina apareciendo en todas partes
A primera vista estamos hablando solamente de dos números:
- tipo de cambio de compra;
- tipo de cambio de venta.
Pero en un sistema administrativo esos números pueden intervenir en muchísimas operaciones.
Conversión de saldos, facturas en dólares, pagos, cuentas por cobrar, cuentas por pagar, cajas, bancos, inventarios, reportes financieros y numerosos procesos internos necesitan alguna referencia para convertir dólares y colones.
Por eso resulta importante distinguir dos conceptos.
El sistema puede tener un:
Tipo de cambio de referencia
que utiliza automáticamente como valor inicial de una operación.
Y puede permitir además un:
Tipo de cambio específico
cuando el documento, pago o movimiento bancario se realizó realmente con otra cotización.
No se trata de imponer el tipo de cambio del BCCR a todas las operaciones. Se trata de disponer de una referencia confiable y automática, dejando al usuario la posibilidad de registrar el valor real cuando corresponda.
El problema de pedirle a una persona que copie el dato
Aquí aparece una situación que durante años ha sido perfectamente normal.
Pensemos en un hotel.
Al comenzar determinadas operaciones del día, un auditor nocturno puede necesitar conocer el tipo de cambio vigente. Abre la página del Banco Central, localiza el valor de compra o venta, lo lee y lo digita en el sistema.
Es un procedimiento sencillo.
Pero también es extraordinariamente fácil equivocarse.
Puede seleccionar la columna incorrecta.
Puede confundir Compra con Venta.
Puede copiar el dato correspondiente a otra fecha.
Puede invertir dos números.
Puede introducir un decimal incorrectamente.
O simplemente puede cometer un error de digitación a las dos o tres de la mañana después de muchas horas de trabajo.
El problema no es la capacidad del auditor.
El problema es que estamos utilizando a una persona como interfaz entre dos sistemas informáticos.
El Banco Central ya tiene el dato en un sistema.
Nuestra aplicación necesita ese mismo dato en otro sistema.
¿Por qué obligar a una persona a leerlo de una pantalla y escribirlo nuevamente en otra?
Una base central cambia completamente el escenario
Si nuestras aplicaciones utilizan una base de datos central para almacenar los tipos de cambio, podemos cambiar el proceso.
En lugar de esto:
Banco Central
↓
Página Web
↓
Persona lee el dato
↓
Persona lo digita
↓
Aplicación
podemos tener:
Banco Central
↓
Servicio de integración
↓
Base de datos central
↓
Aplicaciones
↓
Usuarios
La diferencia parece pequeña, pero operativamente es enorme.
Una sola rutina obtiene el tipo de cambio.
Una sola fuente interna lo almacena.
Todas las aplicaciones utilizan la misma referencia.
Los usuarios dejan de digitar repetidamente el mismo dato.
Y eliminamos una categoría completa de errores humanos perfectamente evitables.
El valor de referencia ya está disponible cuando el usuario lo necesita
Esta es probablemente una de las ventajas que más me interesa.
El usuario no debería tener que preocuparse por actualizar el tipo de cambio.
Cuando abre la aplicación para iniciar una operación, el valor de referencia debería estar ya disponible.
Un proceso independiente puede consultar periódicamente la fuente oficial del Banco Central y mantener actualizada nuestra base de datos.
De esta forma, cuando una aplicación necesita crear una factura, registrar un movimiento, abrir una caja o realizar cualquier operación que utilice dólares y colones, simplemente pregunta a nuestra base:
¿Cuál es el tipo de cambio de referencia correspondiente?
Y obtiene la respuesta.
Si la operación concreta utilizó otro tipo de cambio, el usuario puede modificarlo.
Pero ya no comienza con una casilla vacía ni necesita ir a buscar manualmente la información.
La referencia oficial y el precio real de una operación no son lo mismo
Esta diferencia es importante.
El Banco Central publica el tipo de cambio de referencia, que nuestros sistemas pueden utilizar como punto de partida.
Pero las entidades financieras ofrecen sus propios precios de compra y venta.
Por eso también resulta muy útil otra página que mis amigos y yo consultamos frecuentemente: la lista de tipos de cambio vigentes de ventanilla de los intermediarios cambiarios autorizados.
[Aquí incluiría la captura de la página de tipos de cambio de ventanilla.]
Allí podemos comparar bancos, mutuales, cooperativas, financieras y casas de cambio.
Y eso responde a otra necesidad completamente distinta.
Si tengo dólares y quiero venderlos, me interesa encontrar quién ofrece la Compra más alta.
Si necesito dólares, me interesa encontrar quién ofrece la Venta más baja.
El diferencial también puede convertirse en una oportunidad
Supongamos que un banco publica:
Compra: ₡446
Venta: ₡460
Si yo tengo dólares y quiero venderlos, el banco me paga ₡446.
Si otra persona necesita comprar esos dólares, el banco se los vende a ₡460.
Existe un diferencial de ₡14.
Si ambas personas se conocen, podrían ponerse de acuerdo —por ejemplo— en ₡453.
Quien vende obtiene ₡7 más por dólar.
Quien compra paga ₡7 menos por dólar.
Ambos mejoran respecto de realizar las dos operaciones independientemente con la entidad financiera.
Es un ejemplo sencillo de ganar–ganar, pero también demuestra por qué disponer de información actualizada y comparable tiene valor.
Dos problemas diferentes que podemos automatizar
Tenemos entonces dos necesidades.
La primera es operativa:
mantener automáticamente en nuestros sistemas el tipo de cambio oficial de referencia del Banco Central.
La segunda es informativa y analítica:
comparar los tipos de cambio anunciados por diferentes intermediarios para saber dónde conviene comprar o vender dólares.
Ambas comienzan en datos publicados por el Banco Central.
Y ambas pueden aprovechar la modernización tecnológica que el BCCR ha realizado en sus mecanismos de divulgación.
Del antiguo Web Service al nuevo SDDE
Durante muchos años nuestras aplicaciones podían obtener automáticamente algunos indicadores económicos mediante el conocido Web Service del Banco Central, construido utilizando las tecnologías SOAP y XML características de aquella generación de servicios.
Ese mecanismo permitió automatizar procesos que anteriormente dependían de consultas manuales.
Pero las tecnologías de integración han evolucionado.
El nuevo Sistema de Divulgación de Datos Económicos —SDDE— ofrece una arquitectura mucho más cercana a las aplicaciones actuales: HTTPS, servicios RESTful, JSON y autenticación mediante token.
Aquí es donde el cambio tecnológico resulta verdaderamente interesante.
No porque REST sea una palabra más moderna que SOAP.
Sino porque facilita construir integraciones sencillas desde aplicaciones Web, servicios de Windows, procesos Linux, programas .NET, Python, JavaScript y muchas otras plataformas.
No consultar al BCCR innecesariamente
Que dispongamos de una API tampoco significa que debamos consultarla cada vez que un usuario abre una pantalla.
Una buena arquitectura puede utilizar una base de datos central como repositorio local.
¿Ya tengo el dato?
│
├── Sí → utilizarlo
│
└── No → consultar BCCR
↓
almacenar
↓
utilizar
También podemos revisar periódicamente una pequeña ventana de fechas recientes para detectar alguna eventual corrección realizada por la fuente oficial.
Así obtenemos una solución eficiente y respetuosa con el servicio externo.
Automatizar no significa perder control
Hay otra ventaja importante.
Eliminar la digitación manual del valor de referencia no significa impedir que el usuario intervenga.
Un buen sistema puede hacer ambas cosas:
- proponer automáticamente el tipo de cambio oficial como valor inicial;
- permitir sustituirlo por el tipo de cambio real cuando una operación particular así lo requiera.
Eso permite automatizar lo repetitivo sin sacrificar la realidad contable de cada transacción.
De un pequeño dato a una infraestructura común
Cuando varias aplicaciones utilizan una misma base de datos de tipos de cambio aparecen beneficios adicionales.
Todos los sistemas utilizan la misma referencia.
Podemos conservar historia.
Podemos saber cuándo se obtuvo un valor.
Podemos detectar diferencias.
Podemos auditar cambios.
Podemos alimentar reportes.
Podemos construir nuevas aplicaciones sin volver a resolver el mismo problema.
Y podemos utilizar los datos de ventanilla para construir herramientas de comparación que indiquen, por ejemplo, dónde nos compran mejor nuestros dólares o dónde podemos adquirirlos a menor precio.
El dato deja de estar aislado dentro de una pantalla.
Se convierte en un servicio común para nuestras aplicaciones.
Una API bien documentada permite construir rápidamente
La documentación que ha publicado el Banco Central para el nuevo SDDE me ha parecido particularmente completa y útil. A partir de ella, en aproximadamente tres días he podido desarrollar una aplicación que cumple dos funciones diferentes pero complementarias.
Por una parte, mantiene actualizadas automáticamente mis bases de datos con los tipos de cambio oficiales que utilizan mis sistemas como referencia.
Por otra, ofrece un servicio centralizado para consultar esa misma información, incluyendo tanto el tipo de cambio oficial como las cotizaciones de ventanilla que resultan útiles para comparar dónde conviene comprar o vender dólares.
Esto demuestra una de las ventajas más importantes de disponer de una API moderna y bien documentada: cada desarrollador puede utilizar las fuentes oficiales del BCCR para construir la solución que mejor responda a sus propias necesidades.
Al final del artículo incluiré precisamente la documentación y las fuentes oficiales que utilicé, de manera que quien tenga interés en desarrollar una integración similar pueda partir directamente de la información publicada por el Banco Central.
La verdadera modernización
A veces una modernización tecnológica parece simplemente una molestia.
Un servicio que utilizábamos cambia.
Hay que modificar código.
Hay que volver a probar aplicaciones que llevaban años funcionando.
Pero también es una oportunidad para revisar procesos que habíamos dado por normales.
Tal vez durante años fue normal que un auditor nocturno abriera la página del Banco Central, leyera un número y lo digitara en nuestro sistema.
Hoy podemos preguntarnos algo mucho más sencillo:
si el Banco Central ya tiene el dato y nuestra aplicación lo necesita, ¿por qué debería una persona escribirlo nuevamente?
Automatizar esa pequeña tarea puede parecer insignificante.
Pero cuando eliminamos errores, centralizamos información y hacemos que varias aplicaciones compartan una fuente confiable, estamos haciendo algo bastante más importante que cambiar SOAP por REST.
Estamos utilizando mejor la información.
Para quien solamente quiere consultar la información
Si lo que necesita es simplemente consultar el tipo de cambio sin desarrollar ninguna integración, he dejado disponible una consulta centralizada en:
MonitoreoTC
https://nhcr.net/MonitoreoTC/
Desde allí se puede consultar la información disponible tanto desde una computadora como desde el navegador del teléfono.
La intención es precisamente que el usuario no tenga que preocuparse por cómo obtener los datos, qué servicio utilizar o cómo mantenerlos actualizados. El sistema se encarga de centralizar la información y presentarla de una forma sencilla para su consulta.
Para quien quiera desarrollar su propia integración
Para los desarrolladores, el Banco Central de Costa Rica ha publicado una documentación técnica muy completa del nuevo Sistema de Divulgación de Datos Económicos (SDDE).
El documento principal es el Estándar electrónico para usar el nuevo SDDE, donde se explican la arquitectura REST, las respuestas JSON, los endpoints, parámetros, autenticación mediante token y códigos de respuesta HTTP. El estándar también identifica la ruta base oficial de la API. (gee.bccr.fi.cr)
Consultar el estándar oficial de la API SDDE del BCCR
Registro como usuario
Para utilizar los servicios autenticados del BCCR es necesario registrarse como suscriptor.
El Banco Central mantiene un formulario oficial de registro donde se solicita nombre, correo electrónico, contraseña y algunos datos básicos del usuario.
Registrarse como usuario de Indicadores Económicos del BCCR
Si ya se dispone de una cuenta, el BCCR mantiene también su página de acceso para suscriptores.
Ingresar como suscriptor del BCCR
En mi caso, la calidad de esta documentación ha permitido que en aproximadamente tres días pudiera construir una solución con dos objetivos complementarios: mantener actualizadas automáticamente mis bases de datos con los tipos de cambio que utilizan mis sistemas y, al mismo tiempo, ofrecer una consulta centralizada para quien simplemente necesite acceder a esa información.
Esa es, a mi juicio, una de las mejores consecuencias de esta modernización: el Banco Central publica los datos y la documentación necesaria; a partir de allí, cada desarrollador puede construir la solución que mejor responda a sus necesidades.