Sistema de gestión · En producción · Revisado el 26 de octubre de 2026
Inteligencia artificial para Dragonfish, con un caso andando
Esta ficha no describe Dragonfish de lejos. Sale de leerlo todos los días en una cadena de indumentaria de ocho locales: qué guarda, por dónde se conecta, qué conviene preguntarle y qué todavía no hace.
leídos en producción desde junio de 2026
hasta la copia verificada al centavo
de venta perdida por quiebres, detectada
Lo que esta ficha tiene y otras no: un caso. Todo lo que sigue lo hicimos sobre un Dragonfish real, que hoy corre en producción. El cliente pidió no asociar su nombre a sus números, así que no lo nombramos; el rubro, el tamaño y los resultados son los suyos.
Qué es Dragonfish y quién lo usa
Dragonfish es el sistema de gestión de Zoo Logic pensado para el comercio de indumentaria y calzado. Lo usan marcas y cadenas que venden en varios locales, muchas veces también por mayor y en una tienda online, y que necesitan seguir cada prenda por artículo, color y talle.
Su forma más común en una cadena es una base de datos por local: cada sucursal factura y mueve stock en la suya, y la administración consolida después. Esa arquitectura es la que decide cómo se lo conecta y qué tan frescos llegan los datos.
Qué datos guarda
Mucho más de lo que se mira en el día a día. Los que usamos en el caso:
- Ventas por renglón: cada comprobante con fecha y hora, local, vendedor, artículo, color, talle, precio y descuento.
- Cómo se cobró cada venta: medio de pago, tarjeta, cuotas y, si el punto de venta lo carga, cupón y lote. Es lo que permite cruzar cada operación contra lo que liquidó la procesadora.
- Stock por local y variante, y los movimientos entre locales.
- Precios y listas, con sus cambios.
- Compras y proveedores: comprobantes de compra, órdenes de pago y valores entregados.
- Clientes y sus cuentas, cuando se vende con cuenta corriente.
Lo que Dragonfish no guarda, porque no le corresponde: lo que la procesadora te descontó al liquidar, ni lo que efectivamente entró al banco. Eso viene de otras fuentes, y es justo donde se pierde dinero.
Cómo se conecta: tres vías, y lo que hicimos con cada una
Hay tres formas de leer Dragonfish, y una de ellas, la API, también sirve para escribirle. No dan lo mismo, y conviene saber cuál se usa para qué antes de firmar con cualquier proveedor.
1. La base de datos, con un usuario de solo lectura
Es la vía que usamos en producción y la única que trae todo, con historia y al detalle del comprobante. Pide tres cosas: un usuario que no pueda escribir ni una fila, una máquina o un túnel dentro de la red del cliente, y saber qué versión corre.
Lo que hicimos: leemos cada una de las bases por separado, las copiamos a un almacén aparte y verificamos la copia contra Dragonfish antes de usar un solo número. En el caso, esa copia cuadró al centavo el día 19 del proyecto.
2. La API de Zoo Logic
Más fácil de instalar, porque no pide una máquina en el local. Da lo que el proveedor decide exponer, que no es todo: para el cruce de tarjetas, la base sigue haciendo falta. Las credenciales las entrega Zoo Logic a pedido.
Lo que hicimos para leer: la probamos contra el Dragonfish del caso para consultas puntuales sobre una venta, como el comprobante fiscal que la respalda. Para el trabajo de todos los días seguimos con la base.
La API es, además, la única vía correcta para que un agente cargue algo en Dragonfish: nunca escribiendo directo en la base, que se saltea las validaciones del sistema.
Lo que hicimos para escribir: cargamos facturas de compra en la base de prueba de Dragonfish, no en la de un cliente. En producción no escribimos todavía, y no lo vamos a hacer sin cuatro condiciones: un usuario propio, una persona que pide cada operación, la lectura de vuelta de lo que quedó grabado, y siempre primero en la base de prueba.
3. Las exportaciones a planilla
Un reporte bajado a mano. Sirve para una prueba de concepto antes de conectar nada, y para nada más: es una foto, no se actualiza sola y nadie avisa si faltó un día.
Lo que hicimos: no la usamos en producción, a propósito.
Datos del día, no del día anterior
En una cadena con una base por local, lo habitual es consolidar de noche: la administración mira a la mañana lo que pasó ayer. Para un informe alcanza; para reaccionar, no. Si un talle se agota a las once, mañana a las nueve ya se perdieron las ventas de la tarde.
Por eso no esperamos a la consolidación: leemos las bases de los locales varias veces por día, y lo que se pregunta a la tarde se contesta con lo vendido a la tarde.
Las sugerencias del caso salen de noche, cuando ya cerró el día. Los datos sobre los que se pregunta, en cambio, son los de hoy.
El caso: una cadena de indumentaria de ocho locales
Una cadena de indumentaria de Mendoza, con ocho sucursales y Dragonfish repartido en una base por local. El problema que nos trajeron: «sabemos que perdemos ventas, no sabemos dónde». Un local se quedaba sin un talle mientras otro tenía la misma prenda parada.
Lo que armamos: un agente que cada noche revisa ventas, stock y precios por color y talle, y cada mañana sugiere por Telegram qué mover de un local a otro. Quien decide contesta con un toque.
- 74.000 USD de venta perdida por quiebres, detectada.
- 65.000 USD recuperables moviendo stock que ya existe.
- 176.000 USD de dinero parado, sin rotación.
- 5.300 USD ya vendidos con 107 unidades sugeridas.
- En 26 días, al 24/07/2026: 178 sugerencias, 66 % respondidas, 56 aceptadas y 40 órdenes ejecutadas por el depósito.
Pesos al cambio de julio de 2026. Los números y su contexto están en la página principal, y la línea de tiempo de la conexión, día por día, en cuánto tarda de verdad conectar un sistema de gestión.
La misma conexión sirve para cruzar los cobros con tarjeta: cada venta de Dragonfish contra lo que liquidó la procesadora y lo que llegó al banco. El método está en por qué la conciliación de cobros con tarjeta casi nunca cierra.
Qué le podés preguntar
Preguntas en palabras simples, por Telegram o en un chat, contestadas con los datos de tu Dragonfish:
- ¿Cuánto vendió cada local ayer, y cómo viene hoy?
- ¿Qué talles se agotaron y en qué locales, de lo que más se vende?
- ¿Qué tengo en un local que en otro se vendería, y cuánto conviene mover?
- ¿Qué artículos no se movieron en el último mes, y cuánto dinero tengo ahí?
- ¿Cómo me pagaron esta semana: cuánto en efectivo, cuánto con cada tarjeta y en cuántas cuotas?
- ¿Qué ventas con tarjeta todavía no aparecen liquidadas por la procesadora?
- ¿Alguna procesadora me descontó un arancel más alto que el acordado?
- ¿Cuánto me van a liquidar las tarjetas la semana que viene, sumando todas?
Cada respuesta sale de consultas que solo leen, con tope de filas y tiempo límite. Cómo se acota ese acceso está en qué mira exactamente un sistema con IA sobre tu ERP.
Lo que todavía no hace
- No escribe en Dragonfish en producción. La carga de facturas está probada en la base de prueba; en un cliente, recién con las cuatro condiciones de arriba.
- No carga órdenes de pago. Las probamos y todavía no quedan completas; hasta que queden, no lo ofrecemos.
- No reemplaza a nadie que decide. Sugiere y pregunta; la transferencia, la compra o el reclamo los aprueba una persona.
Preguntas frecuentes
¿Tengo que tocar o reemplazar mi Dragonfish?
No. Dragonfish sigue siendo el sistema donde tu equipo vende, compra y mueve stock. Nosotros leemos con un usuario que no puede escribir, copiamos a una base aparte y trabajamos sobre esa copia.
¿Cada cuánto se actualizan los datos?
Varias veces por día, local por local, sin esperar al cierre de la noche.
¿Hace falta pedirle algo a Zoo Logic?
Para leer la base, no: alcanza con quien administra tu servidor, que crea un usuario de solo lectura. Para usar la API sí, porque las credenciales las entrega Zoo Logic.
¿Puede cargar comprobantes en Dragonfish?
Todavía no en producción. La carga de facturas de compra por la API está probada en la base de prueba, y no la vamos a activar en un cliente hasta tener un usuario propio, una persona que apruebe cada carga, la lectura de vuelta de lo que quedó grabado, y cada cambio probado primero en la base de prueba.
¿Cuánto tarda en estar andando?
En el caso de esta página, cuatro días hasta el primer dato copiado, diecinueve hasta tener la copia verificada contra Dragonfish, y veintinueve hasta la primera sugerencia útil. Lo que más demora es conseguir el acceso, no la parte técnica.
¿Tenés Dragonfish?
En una llamada de 20 minutos miramos cuántos locales y bases tenés, quién administra el servidor y con qué procesadoras cobrás. Con eso te decimos qué se puede leer desde el primer día y qué no. Gratis y sin venta.
Seguí leyendo
Caso de uso
Stock entre sucursales: por qué el mismo producto sobra y falta al mismo tiempo
Las cuatro trampas que hacen que una sugerencia de transferencia salga mal, empezando por mirar el producto y no el color y el talle.
Caso de uso
Cuánto tarda de verdad conectar un sistema de gestión
La conexión de este mismo caso, hito por hito: cuatro días hasta el primer dato, quince más hasta poder confiar en él.
Caso de uso
Por qué la conciliación de cobros con tarjeta casi nunca cierra
Las tres fuentes que deberían decir lo mismo y no lo dicen, y qué tiene que estar en su lugar para que el cruce cierre.
Servicio
Integraciones que terminan diciendo lo mismo
Tu sistema de gestión, tu tienda online, las procesadoras, los bancos y ARCA en un solo almacén de datos.