Bienvenido a AutoCompraMod¶

Si recién entrás al equipo, esta es tu puerta de entrada. AutoCompraMod es el ecosistema de autoservicio (autopago) de Tipre para retail: una terminal donde el cliente del supermercado escanea sus productos, gestiona envases y vales, paga y se lleva su ticket, sin pasar por una caja con cajero. Detrás de esa terminal hay un único backend que orquesta catálogo, pagos, promociones y envases, y un panel de operación para monitorear el parque de terminales. Antes de leer una línea de código, conviene entender qué problema resuelve el sistema, quiénes lo usan y cómo encajan las piezas.

Ver toda la documentación en PDF

Qué problema resuelve y para quién¶

En un supermercado, cada caja con cajero es costo y es cola. El autoservicio mueve parte de ese flujo a una terminal donde el propio cliente arma su compra y paga solo. Pero eso solo funciona si la terminal es rápida, confiable y no se cuelga: si el catálogo no responde, si el pago queda en un estado indeterminado o si la impresora falla en silencio, el cliente abandona la compra y se genera un problema operativo.

AutoCompraMod ataca eso en dos frentes:

• La terminal (TiprePOS) corre el flujo completo de autopago — escaneo, envases/vales, medios de pago (QR, tarjeta, Point Smart), impresión — y está pensada para operar en desktop (la terminal física) con reconexión automática ante caídas de red.
• El backend (AutoCompraMod) consolida en un solo deployable lo que antes eran 5 microservicios separados. Una terminal ya no tiene que hablar con cinco servicios distintos: habla con uno.

Los componentes del ecosistema¶

AutoCompraMod no es una sola aplicación, sino un backend, su panel y una terminal cliente:

Diagrama de alto nivel del ecosistema¶

graph TD
    subgraph Terminal["Terminal de autoservicio"]
        POS["TiprePOS<br/>Flutter · BLoC · Isar<br/>(desktop)"]
    end

    subgraph Backend["AutoCompraMod — backend único"]
        TICKETS["tickets<br/>(orquestador · REST)<br/>+ fiscalización (CAE/CAEA)"]
        CAT["catalogo"]
        PAG["pagos"]
        PRO["promos"]
        ENV["envases"]
        TICKETS --> CAT
        TICKETS --> PAG
        TICKETS --> PRO
        TICKETS --> ENV
    end

    COCKPIT["Cockpit<br/>React · Vite<br/>(operación)"]

    POS -->|"REST<br/>/autocompras/v1"| TICKETS
    COCKPIT -->|"REST<br/>/monitoring/*"| TICKETS

    PAG -.->|"red externa"| MP["MercadoPago<br/>(QR · Point Smart)"]
    POS -.->|"daemon local"| AC["ApiCard<br/>(tarjeta)"]
    TICKETS -.->|"SOAP · red externa"| AFIP["AFIP<br/>(CAE online / CAEA anticipado)"]

Cómo leer esta documentación¶

El onboarding está pensado como un recorrido en tres tramos. No saltees el primero por más que quieras tocar código ya.

1. Entender el sistema (estás acá). Empezá por esta página y seguí con Arquitectura para captar por qué hay un backend único y una terminal cliente. El Monolito modular explica el corazón del backend; la Migración strangler, cómo se llegó hasta acá desde los 5 microservicios. Cuando aparezca un término que no conozcas — ticket, envase, promo, intent de pago, Point Smart — está definido en el Glosario.

2. Referencia técnica. Acá vive el corazón del negocio: cómo se computa un ticket (El agregado Ticket), el núcleo impositivo, las promociones, los envases y vales y la facturación fiscal AFIP. Más los módulos del backend, la API REST y la terminal Flutter. El cómputo del ticket y la facturación fiscal son lo más delicado: leelos enteros antes de tocar nada que los roce.

3. Empezar a programar. Recién entonces levantás el backend en local, corrés la terminal contra él y empezás a contribuir. Cada repo tiene su material de setup en Setup del entorno.