Cuando una factura está vencida y nadie hace seguimiento
Abre su bandeja: varias confirmaciones sin respuesta, una factura vencida, recordatorios enviados demasiado tarde – y nadie puede decir con rapidez si ha entrado un pago. Estas situaciones cotidianas cuestan tiempo y afectan al flujo de caja. Una manera sencilla de cambiar eso es una conexión directa on‑premise entre su sistema Debentra y la contabilidad financiera interna (FiBu), totalmente sin proveedores de servicios en la nube.
¿Por qué un conector local?
Un conector on‑prem conecta Debentra y su FiBu a través de la red interna (LAN). Ventajas en resumen:
- Soberanía total de los datos: sin terceros, sin almacenamiento intermedio en la nube.
- Intercambio de datos directo: detección de pagos más rápida y menos trabajo manual.
- Control fino: conserva el mando sobre aprobaciones, p. ej. en avisos de pago.
Opciones de arquitectura – tres patrones prácticos
Elija la variante adecuada según la infraestructura existente y las políticas de seguridad:
1) Exportación de archivos basada en SFTP
Debentra exporta archivos CSV/JSON periódicos a un servidor SFTP interno; el software de la FiBu importa estos archivos de forma automatizada.
- Ventajas: fácil de implementar, compatible con muchas herramientas de FiBu.
- Desventajas: latencia por procesamiento por lotes (p. ej. cada 5–15 minutos).
2) Webhook interno sobre LAN
Debentra envía, ante eventos (p. ej. nuevas partidas pendientes, recibo de pago), HTTP‑POSTs a una dirección interna y protegida que su FiBu recibe.
- Ventajas: notificaciones en tiempo real, menor retardo.
- Desventajas: requiere un endpoint permanentemente accesible y una capa de autenticación.
3) Puente API local (middleware)
Una pequeña bridge autoalojada lee exportaciones de Debentra o puntos de API y transforma los datos al formato de la FiBu; habitualmente se ejecuta en un contenedor Docker.
- Ventajas: máxima flexibilidad en el mapeo y en las reglas de validación.
- Desventajas: mayor esfuerzo de desarrollo, pero adaptable a largo plazo.
Preparación: requisitos y comprobaciones
Antes de empezar, aclare estos puntos:
- ¿Qué opciones de exportación ofrece su sistema Debentra? (exportación de archivos, webhook de eventos, API local)
- ¿Qué métodos de importación acepta su FiBu? (ingest SFTP, API HTTP, importes manuales de archivos)
- Políticas de seguridad: segregación VLAN, reglas de firewall, procedimientos de autenticación (clave SSH, mTLS, API‑Keys).
- Responsabilidades: ¿quién autoriza los avisos de pago? ¿quién revisa las transferencias fallidas?
Implementación práctica: paso a paso
1. Definir el caso de uso y el mapeo de datos
Defina qué eventos y campos deben transferirse. Campos típicos:
- ID de la factura, número de cliente
- Fecha de la factura, fecha de vencimiento
- Importe pendiente, pagos parciales / estado de cuotas
- Estado de pago y referencia contable
- IDs de documentos o ruta del PDF (para archivado en la FiBu)
Elabore un documento de mapeo: campo Debentra → campo FiBu. Añada reglas de validación (p. ej., campos obligatorios, valores permitidos para códigos de estado).
2. Ejemplo: configuración SFTP (exportación basada en ficheros)
Pasos en resumen:
- Crear en el servidor SFTP interno un usuario de sistema dedicado (p. ej., debentra_sync), forzar autenticación por clave SSH.
- Configurar Debentra para que periódicamente (p. ej., cada 5 minutos) coloque CSV/JSON con partidas abiertas en una carpeta definida en el SFTP.
- En la FiBu, crear un job de importación que consuma nuevos ficheros, los valide y los contabilice. Los ficheros fallidos se mueven a una carpeta de cuarentena y se notifica por correo al equipo.
Notas prácticas:
- Generar la clave SSH en el host de Debentra: ssh-keygen -t ed25519 -f /var/lib/debentra/keys/debentra_sync
- Agregar la clave pública en el servidor SFTP en ~/.ssh/authorized_keys del usuario debentra_sync.
- Permisos: la carpeta destino debe ser escribible solo por debentra_sync, con permiso de lectura para el proceso de importación de la FiBu.
3. Ejemplo: Webhook interno (tiempo real sobre LAN)
Pasos:
- La FiBu expone un endpoint a través de una interfaz interna (p. ej., http://fibu-internal.local/api/sync).
- Configurar en Debentra un webhook que envíe payloads a ese endpoint para los eventos definidos.
- Asegure el canal: mTLS o una API‑Key fuerte, lista de IPs permitidas y vida breve de los tokens.
Consejo de diseño: implemente en la FiBu un procesamiento idempotente (p. ej., basado en la ID de factura) para que llamadas webhook repetidas no generen duplicados.
4. Ejemplo: API‑Bridge local (middleware)
Concepto:
- Despliegue una pequeña app puente (p. ej., Node.js, Python) en su LAN como contenedor Docker.
- La bridge obtiene exportaciones o endpoints API de Debentra, mapea campos y llama a la API de la FiBu o deja ficheros en disco.
- Incorpore logging, reintentos y una cola de mensajes muertos (Dead‑Letter‑Queue, DLQ) para casos de error.
Componentes de ejemplo:
- Scheduler / listener de eventos
- Módulo mapper con validación
- Módulo de transporte (cliente SFTP, cliente HTTP con mTLS)
- Monitorización: estadísticas de exportación y alertas de error por e‑mail/Teams
Seguridad y operación
- Red: Permita solo IPs internas, aplique reglas de firewall en puntos críticos.
- Autenticación: Claves SSH, mTLS, tokens API de corta duración.
- Registro y retención: Conserve los registros de exportación y los protocolos de transferencia al menos durante el periodo que exijan sus políticas internas.
- Copias de seguridad: Versione configuraciones y plantillas de mapeo, archive los contenedores puente como imagen.
- Supervisión: Health checks de los componentes del conector y notificación automatizada en caso de errores.
Integración de procesos: Mantener aprobaciones y control
Incluso con automatización, el control permanece en manos del usuario. Establezca reglas que exijan una aprobación manual antes de enviar recordatorios de pago (por ejemplo, para importes elevados o partidas en disputa). Debentra permite preparar recordatorios y enviarlos para su aprobación a las personas responsables; su solución de conector debería reenviar y respetar esta información de aprobación.
Casos de error y recuperación
Planifique para problemas típicos:
- Fallo de red: Cola en la exportación de Debentra o en la bridge, reintento automático.
- Errores de mapeo: Cuarentena con notificación al equipo de contabilidad.
- Duplicados: Procesamiento idempotente basado en IDs únicas.
Ejemplo práctico breve
Una empresa mediana utiliza Debentra. Eligen la variante SFTP: Debentra exporta cada 10 minutos las partidas abiertas como JSON a /outgoing/openitems/. Un systemd‑timer en el servidor de contabilidad recupera los archivos nuevos, los valida y contabiliza automáticamente o los marca para revisión manual. En partidas en disputa, el archivo se mueve a una carpeta de cuarentena y se asigna al equipo mediante ticket. Así disminuye el trabajo manual de asignación y la contabilidad mantiene el control total de los datos.
Conclusión
Una conexión de contabilidad on‑prem entre Debentra y su sistema de contabilidad es técnicamente viable y mejora la transparencia y la seguridad de los procesos, sin ceder datos a nubes ajenas. Elija la arquitectura (SFTP, webhook interno, bridge de API local) acorde a sus requisitos y documente el mapeo, las reglas de seguridad y los escenarios de fallo. Importante: automatice, pero mantenga puntos de aprobación para acciones críticas.
¿Interesado en una solución que combine vista central, control de procesos y soberanía de datos? Debentra está disponible como software self‑hosted en las ediciones BASIS, PRO y PREMIUM — PRO reduce las asignaciones manuales, PREMIUM ofrece integración contable adicional. Edition wählen
Siguiente paso
Probar Debentra por sí mismo
Vista central y control de procesos para partidas abiertas y pagos con soberanía total de los datos; reduce el trabajo manual de asignación (PRO) y permite contabilidad integrada (PREMIUM); modelos de instalación y licenciamiento seleccionables.