Inspiration

En un taller de reparación de equipo industrial (husillos, motores eléctricos), cada equipo que entra se inspecciona y genera una lista de piezas: cuáles están bien, cuáles dañadas y cuáles faltan. Compras recibe material, pero nadie sabe qué hay en el almacén: cada pieza se busca a mano y se pide tarde, cuando el equipo ya está detenido esperándola. Quisimos cerrar ese ciclo: que el almacén se entere solo de lo que pasa en el taller y responda en tiempo real qué hay, qué está apartado y qué falta comprar.

What it does

Es un servicio de inventario que escucha los eventos del taller y lleva el almacén solo:

  • Reserva automáticamente las piezas cuando el supervisor aprueba una inspección. Lo que no alcanza queda como faltante y genera una sugerencia de compra con las órdenes que la piden.
  • Relaciona las compras que llegan con el catálogo, aunque el número de parte venga escrito distinto. La entrada surte primero los faltantes de la orden que la pidió. Lo que no coincide va a revisión manual.
  • Cuatro pantallas:
    • Almacén: existencias por ubicación, faltantes, sugerencias y recepciones por relacionar.
    • Orden de trabajo: reservado, entregado y pendiente por pieza, actualizado en vivo.
    • Piso: pensada para manejar las piezas en cada piso y retirar hacia una orden que las necesite, transferirlas o contarlas aquellas que se encuentran ahí
    • Kardex: Registra los movimientos de cada pieza con su saldo corrido, mínimo y máximo.
  • Reglas del taller real:
    • Las piezas a reparar del cliente no se reservan.
    • Las compras para reventa no entran al almacén.
    • Una orden dada de baja o una inspección anulada liberan sus reservas.
    • Una segunda aprobación reemplaza lo pedido, no lo suma.

How we built it

  • Python 3.12 con FastAPI para la API y confluent-kafka para consumir los tópicos del taller desde Redpanda, compatible con Kafka.
  • PostgreSQL como libro mayor: el stock nunca se edita, siempre es la suma de movimientos inmutables, protegidos por un trigger.
  • Idempotencia guardando el event_id de cada evento en la misma transacción que sus efectos. Los eventos de salida se publican con el patrón outbox.
  • Un candado de PostgreSQL por escritura, para que dos aprobaciones simultáneas nunca se lleven la misma última pieza.
  • Una bitácora propia en Kafka que anota en orden todo lo aplicado. Si se borra la base, el agente la recrea idéntica.
  • Pantallas en HTML, CSS y JavaScript sin frameworks. Escaneo de etiquetas Code 128 con la cámara mediante html5-qrcode, y un túnel cloudflared para abrirlas en el celular con HTTPS.

Challenges we ran into

  • El desorden de los eventos. Entre tópicos no hay orden: una compra podía llegar antes que su pieza y una inspección antes que su orden. Lo resolvimos leyendo el catálogo primero, dejando en espera lo que aún no se conoce y dando unos segundos de gracia antes de mandar una compra a revisión manual.
  • Reconstruir la base de forma exacta. Releer los tópicos recuperaba lo que vino del taller, pero no las salidas, transferencias ni conteos hechos en piso. Agregamos una bitácora ordenada que lo guarda todo, y hicimos que la API no muestre la base a medias mientras se reconstruye.
  • Los datos reales: piezas sin identificar, renglones sin cantidad, SKU duplicados o con comas y diagonales, kits que cambian de nombre, órdenes dadas de baja con reservas vivas.

Accomplishments that we're proud of

  • 50 de 50 en las pruebas automáticas de contrato, corridas en Docker como las corre el jurado.
  • Reconstrucción exacta: borramos la base completa y el agente la dejó idéntica tabla por tabla y renglón por renglón, no solo en saldos.
  • Todos los eventos de salida cumplen el contrato: 0 errores en más de 14,000 eventos validados.
  • Las 22 etiquetas impresas de la demo se leen bien, incluidas las difíciles como TOR, CAB, BAJA y 7014 CTA/P4.
  • Un retiro en piso toma pocos toques: escanear la ubicación, escanear la pieza y confirmar. La cantidad se propone sola.

What we learned

  • En sistemas basados en eventos, "al menos una vez" significa que todo debe poder repetirse sin efectos dobles, y que el orden no se puede dar por hecho.
  • Guardar el estado como libro mayor de movimientos hace el inventario auditable y facilita reconstruirlo.
  • Las garantías se ganan en la misma transacción: el efecto, la marca de procesado y el evento de salida se guardan juntos o no se guarda nada.
  • Probar con los datos "sucios" del taller real enseña más que cualquier caso ideal.

What's next for Almacen Inteligente Para Taller

  • Pronóstico de demanda por modelo, a partir de las listas de partes y las inspecciones históricas, para comprar antes de que falte.
  • Valuación del inventario a costo promedio, con compras en MXN y USD.
  • Tablero de rotación: piezas críticas y piezas sin movimiento.

Built With

Share this project:

Updates

Submission history