CarniApp: el punto de venta de una carnicería

Una carnicería no vende piezas: vende kilos.

El producto se vende por peso, llega como animal entero y muchas veces se fía a clientes de confianza. Con una libreta o un punto de venta genérico es difícil saber cuánto queda de cada corte, cuánto debe cada cliente y si la caja cuadra al cerrar el turno.

Un sistema hecho para el mostrador.

Una API en ASP.NET Core 8 con SQL Server y una aplicación Flutter que corre en escritorio, web y Android. La barra lateral solo muestra los módulos que los permisos de cada usuario permiten.

• Venta FácilRegistra un animal (tipo, peso y costo), estima el reparto por corte y lo mete al inventario. Con el tiempo aprende los rendimientos reales.
• Punto de ventaHasta 8 ventas abiertas en pestañas, búsqueda por nombre o código de barras y cobro mixto: efectivo, tarjeta, transferencia y crédito.
• Caja y corteApertura de turno, gastos y retiros, aviso al llegar a la meta de efectivo, cierre con diferencia, historial y reapertura.
• Clientes y créditoSaldo y abonos por cliente, que se encuentra por nombre o por los últimos 4 dígitos de su teléfono.
• InventarioExistencias por corte, kardex de movimientos, ajustes manuales y aviso de existencias bajas.
• Usuarios y permisosRoles propios con los permisos que el dueño elija, restablecer contraseñas y desbloquear cuentas.

Clean Architecture, de afuera hacia adentro.

La API está dividida en cuatro proyectos y las dependencias apuntan hacia el dominio. Las reglas del negocio no saben nada de la base de datos ni de HTTP.

Cada capa depende solo de las que están más adentro; el dominio no depende de nada.

La base de datos no usa migraciones de EF: el esquema vive en scripts T-SQL escritos a mano e idempotentes. Una prueba, SchemaContractTests, falla si una entidad usa una columna que los scripts no crean.

Seguridad que se comprueba con pruebas.

• Sesión. Token de acceso JWT de 20 minutos y token de renovación que rota en cada uso. Si alguien presenta uno ya usado, se cierran todas las sesiones de esa persona.
• Contraseñas. Hash con BCrypt; 5 intentos fallidos bloquean la cuenta 15 minutos.
• Permisos por endpoint. Cada escritura exige un permiso, por ejemplo pos.vender o caja.cortar. La prueba ContratoApiTests falla si algún endpoint queda sin protección.
• Sin pasos olvidados. Al arrancar, la API crea los permisos nuevos que exige el código y se los asigna al Super Administrador.

Del mostrador a la impresora térmica.

El ticket se envía en ESC/POS a impresoras de 58 u 80 mm, con el logo del negocio. El cajón se abre al cobrar en efectivo y el lector de código de barras funciona como teclado.

Pruebas y entrega continua.

• Pruebas con xUnit sobre SQLite en memoria, sin necesidad de SQL Server.
• Una prueba recorre un día completo de operación: caja, lotes, ventas, abono, gasto, anulación y corte.
• En la app, pruebas de cada módulo, de la barra lateral por permisos, del ticket y del diseño en pantallas angostas.
• GitHub Actions corre las pruebas de la API y de la app, y flutter analyze, con cada git push.

Mi participación.

• Diseño de la base de datos con scripts T-SQL repetibles.
• Desarrollo de la API en ASP.NET Core 8 con Clean Architecture, EF Core y JWT.
• Desarrollo de la app en Flutter para macOS, Windows, Linux, web y Android.
• Integración con impresoras térmicas, cajón de dinero y lector de código de barras.
• Pruebas automatizadas e integración continua.

Capturas.

El nombre y los datos del cliente y de sus compradores se omiten por confidencialidad.