Arquitectura de extensiones
Algunas capacidades son inherentemente locales o específicas del proveedor: los mandatos gubernamentales de facturación electrónica, los feeds de datos bancarios. REDA Financials las gestiona con una arquitectura de extensiones: el núcleo permanece independiente del proveedor, y los paquetes de extensión conectables aportan las conexiones específicas de cada país o proveedor.
El modelo
- El núcleo aporta los conectores: objetos de configuración que describen dónde se conecta un proveedor —una configuración de facturación electrónica por entidad, una configuración de feed bancario por cuenta bancaria— más los objetos de auditoría que registran lo que fluye a través de ellos.
- Las extensiones aportan los enchufes: un paquete de extensión de proveedor implementa la conexión real (una cámara de compensación nacional de facturación electrónica, un servicio de agregación bancaria) y se registra a sí mismo en esa configuración.
- Tus documentos nunca cambian: las facturas, los recibos y los extractos permanecen idénticos sea cual sea el proveedor detrás de ellos. Cambia de proveedor y la contabilidad no lo percibe.
Quién aporta qué
Vale la pena detallar la división de tareas entre conector y enchufe, porque determina a quién llamas cuando algo necesita cambiar:
| Pieza | Aportada por | Ejemplos |
|---|---|---|
| Los conectores — la configuración que describe dónde se conecta un proveedor | El núcleo de REDA Financials | Una configuración de facturación electrónica por entidad; una configuración de feed bancario por cuenta bancaria |
| Los objetos de auditoría — el registro de lo que fluye a través de ellos | El núcleo | El rastro de envío adjunto a cada documento facturado electrónicamente |
| Los enchufes — la conexión real con un proveedor | Un paquete de extensión | Una conexión con una cámara de compensación nacional de facturación electrónica; un servicio de agregación bancaria |
| La elección del proveedor — qué enchufe ocupa qué conector | Tú, en la configuración | Apuntar la configuración de facturación electrónica de una entidad al proveedor instalado |
Qué significa para cada rol
| Rol | Qué cambia con una extensión | Qué nunca cambia |
|---|---|---|
| Administrador | Instala el paquete de extensión del proveedor y lo registra en la configuración correspondiente: por entidad o por cuenta bancaria. | La Consola de administración, la configuración del núcleo, el calendario de actualizaciones del núcleo contable. |
| Usuario de contabilidad | Nada. Las facturas, los recibos y los extractos se crean y se contabilizan exactamente como antes. | Cada pantalla, cada hábito: los documentos permanecen idénticos sea cual sea el proveedor detrás de ellos. |
| Auditor / revisor | Obtiene un rastro por documento de lo que pasó por el punto de extensión. | La cadena de evidencia del núcleo: Registro de auditoría, historial de campos, libro mayor inmutable. |
Los dos puntos de extensión de hoy
| Punto de extensión | Qué habilita | Detalles |
|---|---|---|
| Facturación electrónica | Enviar facturas a las plataformas gubernamentales donde la ley lo exige, con un rastro de envío completo por documento. | Extensiones de facturación electrónica |
| Feeds bancarios | Entrega automática de extractos bancarios desde proveedores de agregación, que alimenta la importación de extractos bancarios sin archivos CSV. | Extensiones de feeds bancarios |
Por qué está construido así
Los mandatos y los proveedores cambian constantemente: los países implementan la facturación electrónica por fases, los bancos cambian de agregador. Mantener esas integraciones en paquetes separados significa que tu núcleo contable se actualiza según su propio calendario, las extensiones según el suyo, y una regulación del otro lado del mundo nunca desestabiliza tu cierre. También significa extensibilidad basada en configuración en todas partes: las extensiones pueden agregar sus campos a los documentos y a los PDF sin cambios de código en el núcleo.
Un ejemplo práctico: los dos enchufes de Meridian
La organización de Meridian Properties Group muestra ambos puntos de extensión en uso, y el patrón sosteniéndose en ambos casos:
Brasil necesita facturación electrónica gubernamental
Brasil opera un régimen de compensación de facturas, así que el administrador instala el paquete de extensión del proveedor y apunta hacia él la configuración de facturación electrónica de la entidad brasileña. A partir de entonces, el envío de cada factura contabilizada —enviada, aceptada o rechazada, con la respuesta de la autoridad— queda registrado en el rastro de la factura. El flujo de trabajo del equipo de cuentas por cobrar no cambió ni un solo clic.
El banco de EE. UU. ofrece un feed
El administrador instala la extensión de un proveedor de feeds y la registra en la configuración de feed de la cuenta bancaria operativa. Los extractos ahora llegan por sí solos como extractos bancarios y líneas ordinarios, idénticos a las importaciones CSV que la entidad del Reino Unido sigue haciendo a mano, de modo que la conciliación se lee igual en ambos países.
Un proveedor cambia; la contabilidad no
Si alguna vez se reemplaza el proveedor de Brasil, el nuevo enchufe ocupa el mismo conector: los documentos, los rastros y la contabilidad permanecen idénticos. Ese cambio sin retrabajo es todo el argumento a favor de la arquitectura.
Errores comunes que evitar
| Error | Por qué perjudica | Haz esto en su lugar |
|---|---|---|
| Construir una integración personalizada donde ya existe un punto de extensión | Vuelves a implementar el conector que el núcleo ya aporta, y asumes su mantenimiento para siempre | Usa el punto de extensión; pregunta a REDA qué paquetes de proveedor existen para tus países y bancos |
| Esperar a una extensión antes de configurar el núcleo | Nada de la configuración del núcleo necesita retrabajo cuando llega una extensión; esperar solo retrasa la contabilidad | Configura las entidades, los bancos y los documentos ahora; conecta los proveedores cuando estés listo |
| Esperar que los usuarios aprendan pasos nuevos cuando una extensión entra en funcionamiento | No deberían: las extensiones se apoyan en la contabilización y en la llegada de los extractos, no en nuevos hábitos | Si un plan de despliegue incluye volver a capacitar en la captura de documentos, cuestiona el plan |
| Acoplar tu calendario de cierre a la actualización de una extensión | El núcleo y las extensiones se actualizan deliberadamente en calendarios separados | Trata las actualizaciones de extensiones como sus propios eventos pequeños, no como bloqueadores del cierre |
| Suponer que un solo proveedor cubre todos los países o bancos | Los mandatos y la cobertura son regionales por naturaleza | Verifica la disponibilidad por país y por banco: los dos artículos de detalle explican cómo |
Qué sigue
- Extensiones de facturación electrónica · Extensiones de feeds bancarios: los dos puntos en la práctica.
- Paquetes de extensión (vista para desarrolladores): para los equipos que construyen una.
Preguntas frecuentes
No: esa es la promesa central del diseño. Los documentos permanecen idénticos sea cual sea el proveedor detrás de ellos; las extensiones cambian lo que ocurre alrededor de la contabilización y de la llegada de los extractos, nunca los documentos en sí.
La nueva extensión se registra en el mismo conector de configuración, y tus documentos y rastros de auditoría continúan sin cambios: la contabilidad no percibe el cambio.
No, de forma deliberada. El núcleo se actualiza según su propio calendario y cada extensión según el suyo, de modo que un cambio de proveedor o de mandato nunca desestabiliza tu cierre.
Sí: el diseño basado en configuración permite que las extensiones agreguen sus campos a los documentos y a los formatos de PDF sin cambios de código en la configuración del núcleo que ya tienes.
Dos puntos hoy: facturación electrónica y feeds bancarios. La disponibilidad de proveedores evoluciona según el país y la región; consulta a REDA sobre la tuya.
¿Te resultó útil?