Limitaciones importantes
Lee con atención antes de habilitar la aplicación automática del cobro para un cliente — el proceso es nuevo (beta) y tiene comportamientos específicos. Se harán nuevas implementaciones en las próximas versiones.
Límites de la API
Rate limit de 3 req/s y 120.000/día
Son 3 solicitudes por segundo y 120.000 por día por cuenta de Bling — Koncili lo controla de su lado. Al superarlo, el ítem espera y vuelve a la cola automáticamente; nunca falla por eso.
Ventana de 1 día por consulta
Cada consulta de documentos por cobrar cubre solo 1 día — pedir un período mayor a 1 año en una única consulta devuelve un error de Bling.
La fecha de inicio de la sincronización es fija
La fecha de inicio de la sincronización (registrada en la conexión) debe ser como máximo de 1 año atrás y no puede modificarse después — queda en solo lectura en la edición.
No existe ambiente de pruebas (sandbox)
Bling no tiene sandbox — incluso en las pruebas, Koncili se comunica con el host de producción.
Cuándo se bloquea la aplicación del cobro
Divergencia de monto
Si el monto del documento por cobrar en Bling no coincide con el monto calculado por Koncili, la aplicación del cobro se bloquea (el ítem queda FAILED) — nunca aplica el cobro por un monto incorrecto. La ocurrencia queda registrada y puede verse en el informe de Smart Report.
Ambigüedad de cuota
Cuando una venta tiene varias cuotas y el emparejamiento por monto resulta ambiguo, el ítem falla en lugar de arriesgarse a aplicar el cobro al documento por cobrar incorrecto (ver Vínculo de documentos por cobrar).
Se acepta la categoría vacía
En la práctica se acepta la categoría vacía, aunque Bling documenta el campo como obligatorio — Koncili simplemente no envía el campo cuando está en blanco.
Cuándo la conexión queda inválida
No existe un estado "expirado" separado
Las cuatro situaciones siguientes se reducen a credencial inválida y exigen una reconexión manual (botón "Reconectar"):
- El
refresh_tokense rechaza después de ~30 días sin uso (la ventana se desplaza: se renueva con cada refresh exitoso). - Falla un intento de reautorización.
- Una aplicación del cobro se aborta por un 401 con un refresh que también falló, o por un 403.
- La credencial se desactiva manualmente.
Lo que todavía no se ha implementado
Sin notificación proactiva de falla
Solo existe el ícono binario "enviado" (ver Consulta y seguimiento) — que no distingue el éxito de la falla.
El botón no se vuelve a habilitar después de una falla
Si la aplicación del cobro falla, el botón "Enviar ao ERP" (Enviar al ERP) queda deshabilitado indefinidamente para esa conciliación — sin reinicio automático. Esta funcionalidad se creará en el futuro.