Registro de ventas
Captura rápida por cliente y producto, con cálculo automático del total.
Todos los proyectos
Case StudyEn producción
Distribuidora de Huevos Escobar
Sistema de ventas, inventario y cuentas por cobrar para una distribuidora con reparto en ruta, donde el registro diario dependía de anotaciones a mano.
- Cliente
- Distribuidora de Huevos Escobar
- Año
- 2025
- Rol
- Análisis, desarrollo y despliegue (proyecto individual)
- Stack
- JavaScript · Node.js · Express · SQLite · JWT
01
Overview
Un negocio de distribución vive de dos números: qué salió y qué se cobró. En esta distribuidora ambos se anotaban a mano al final del día, y cuadrarlos era un ejercicio de memoria que se hacía cada noche.
El sistema registra ventas por cliente, descuenta inventario, lleva el saldo de quienes compran al crédito y permite consultar el histórico sin depender de un cuaderno.
02
El problema
El producto salía en ruta y volvía como efectivo, producto no vendido o deuda, sin un registro que uniera las tres cosas.
Las cuentas por cobrar eran el punto más débil: los saldos vivían en notas dispersas, y una deuda olvidada era dinero perdido sin que nadie lo notara.
03
El reto
- El sistema debía ser más rápido que el papel. Si registrar una venta tomaba más tiempo que anotarla, nadie lo iba a usar.
- Los usuarios no eran técnicos: la interfaz tenía que funcionar con el vocabulario del negocio y con la menor cantidad de pasos posible.
- El inventario y las ventas debían mantenerse consistentes incluso cuando se corrigiera un registro anterior.
04
La solución
Desarrollé una aplicación web con backend en Node.js/Express y SQLite, y un frontend en JavaScript modular sin framework, priorizando una carga inmediata y un flujo de captura corto.
El registro de una venta descuenta inventario y actualiza el saldo del cliente en la misma operación, de forma que las tres vistas del negocio siempre coincidan.
La autenticación con JWT y contraseñas cifradas permite separar lo que puede hacer la administración de lo que puede hacer el personal de ruta.
05
Arquitectura
- Navegador — JavaScript modular (ES Modules)
- API REST — Node.js + Express
- Autenticación JWT + bcrypt
- Lógica de ventas, inventario y cobros
- SQLite (better-sqlite3)
06
Tecnologías
| Tecnología | Función |
|---|---|
| JavaScript (ES Modules) | Interfaz sin framework, con carga mínima |
| Node.js + Express | API REST y reglas de negocio |
| SQLite (better-sqlite3) | Base de datos embebida, respaldable como un archivo |
| JWT + bcrypt | Sesiones y credenciales seguras |
| CSS | Interfaz responsiva construida desde cero, sin dependencias |
07
Funcionalidades
Control de inventario
Entradas de producto y descuento automático al vender, con existencias siempre visibles.
Cuentas por cobrar
Saldo por cliente, registro de abonos y consulta del histórico de deuda.
Clientes
Ficha con datos de contacto, historial de compras y estado de cuenta.
Reportes del período
Consulta de ventas y cobros por rango de fechas para cerrar el día o el mes.
Usuarios y accesos
Roles separados para administración y operación diaria.
08
Proceso de desarrollo
- 01
Research — Observé el ciclo real de un día de reparto antes de escribir código.
- 02
Requirements — Reduje el registro de una venta al mínimo de campos posibles.
- 03
Architecture — Backend y base de datos ligeros, pensados para correr en una sola máquina.
- 04
UI/UX — Interfaz sin framework para mantener la carga y la complejidad bajas.
- 05
Development — Construcción por módulos: primero ventas, luego inventario, después cobros.
- 06
Testing — Validación con datos reales del negocio antes de reemplazar el cuaderno.
- 07
Deployment — Puesta en marcha con respaldo del archivo de base de datos.
09
Decisiones y trade-offs
JavaScript sin framework en el frontend
Para un panel administrativo de este tamaño, un framework habría añadido peso y proceso de build sin resolver un problema real. ES Modules y CSS propio dieron una interfaz rápida y fácil de mantener por una sola persona.
Consistencia en la misma operación
Venta, inventario y saldo se actualizan juntos. Separarlos habría sido más flexible, pero abría la puerta a estados inconsistentes: producto descontado sin venta registrada, o venta sin deuda asociada.
SQLite como archivo respaldable
Que toda la base de datos sea un archivo hace que el respaldo sea una copia, no un procedimiento. Para un negocio sin personal técnico, eso es la diferencia entre tener respaldos y hablar de ellos.
10
Resultados
- El cierre del día dejó de depender de reconstruir la jornada de memoria.
- Las deudas de clientes quedaron visibles y consultables en cualquier momento, no solo cuando el cliente regresaba.
- El inventario refleja las ventas del día sin necesidad de un conteo manual para saber qué queda.
11
Qué aprendí
Cuando el sistema compite contra el papel, la velocidad de captura importa más que la cantidad de funciones.
Modelar bien el negocio al inicio —qué es una venta, qué es un abono, qué es una deuda— ahorra semanas de correcciones después.
Empezar por el módulo que más duele (las cuentas por cobrar) hace que el sistema se gane la confianza del usuario desde el primer día.
Siguiente proyecto
ID Inventory — Operación sin conexiónContacto
¿Construimos algo?
Estoy abierto a oportunidades profesionales, colaboraciones y proyectos donde la tecnología resuelva una necesidad concreta.