MaissyPOS
Sistema de gestión para negocios de distribución y producción (rutas de venta,
despacho, liquidación, inventario, cartera, nómina, facturación) construido
sobre Next.js 16 (App Router) y Supabase (Postgres + Auth + Storage).
Nació para Distri Maissy SAS (distribución de arepas/lácteos por rutas) y
Arepas Maissy (producción). Ambas empresas viven en la misma base de datos,
aisladas por Row Level Security — el objetivo de largo plazo es que cualquier
negocio nuevo pueda configurarse a su medida sin tocar código.
Arquitectura multiempresa
- Cada fila de negocio tiene
empresa_id. El aislamiento entre empresas se
hace con RLS en Postgres, no en la aplicación: cada política compara
empresa_id contra los empresa_ids del JWT de la sesión (ver
supabase/migrations/0001_auth_empresa_claims.sql y 0004_rls_jwt_rollout.sql).
Un usuario puede pertenecer a varias empresas (usuarios.empresas) y las
cambia desde el selector del sidebar (lib/empresa.js guarda la empresa
activa en localStorage).
- Cada empresa tiene uno o más modelos de negocio (
empresas.modelos):
distribucion (rutas, despacho, liquidación) y/o produccion (fórmulas,
costeo). Un módulo del sidebar sin modelos es "core" y se ve siempre; uno
con modelos solo aparece si la empresa activa tiene alguno de esos
modelos activos. Ver MODULOS y MODELOS_NEGOCIO en
components/Sidebar.js.
- El acceso por módulo se resuelve con
lib/permisos.js
(puedeVerModulo): si el usuario tiene usuario.modulos (override
granular por persona) se usa eso; si no, se cae al rol (admin,
auxiliar, vendedor). Un tercer eje, requierePermiso, gatea módulos
puntuales por un booleano propio del usuario (ej. puede_aprobar_inventario
para Ajustes de Inventario), independiente del rol.
Módulos
Operación diaria — Conteo Diario, Despacho, Liquidación, Devoluciones,
Cambios, Ventas, Producción.
Control y ajustes — Compras, Gastos Admin, Fórmulas, Costeo, Inventario,
Ajustes de Inventario (aprobación de divergencias de conteo con segregación
de funciones y auditoría), Cartera, Imprimir Despacho, Transferencias,
Historial de Liquidaciones.
Administración — Maestros (productos, categorías, clientes, cuentas),
Vehículos, Vista Grupo (consolidado entre empresas), Reportes, Financiero,
Nómina, Configuración.
El Resumen Ejecutivo (/ejecutivo) es el tablero de entrada para admin:
centraliza en un "Centro de alertas" todo lo que requiere acción hoy —
ajustes de inventario pendientes, cartera vencida, rutas sin despachar,
conteo del día pendiente, descuadres de caja, transferencias sin confirmar,
documentos de vehículo por vencer — cada alerta real (alertas_admin) se
puede descartar una vez atendida.
Seguridad
- Autenticación real con Supabase Auth. El hook
custom_access_token_hook
(0001_auth_empresa_claims.sql) inyecta empresa_ids y rol como claims
del JWT en cada sesión.
- Toda tabla con
empresa_id tiene RLS con el patrón
empresa_id = any (jwt_empresa_ids()) para select/insert/update (y delete
donde aplica). No hay una capa de autorización de datos en el código de la
app — si falta una política RLS, ese hueco es real independientemente de lo
que filtre el frontend.
usuarios y sesiones_activas tienen su propio patrón de RLS (cruzan
usuarios.empresas contra el JWT via el helper jsonb_a_uuids).
Stack técnico
- Next.js 16 (App Router) + React 19 + Tailwind CSS 4.
- Supabase: Postgres, Auth, Storage (bucket
facturas para evidencia de
facturación electrónica).
recharts para gráficos, jspdf/html2canvas para PDFs imprimibles.
Variables de entorno
NEXT_PUBLIC_SUPABASE_URL=
NEXT_PUBLIC_SUPABASE_ANON_KEY=
SUPABASE_SERVICE_ROLE_KEY= # solo usado server-side en app/api/* (admin-usuarios, sesion)
WHATSAPP_ACCESS_TOKEN= # alertas por WhatsApp (app/api/whatsapp-alerta)
WHATSAPP_PHONE_NUMBER_ID=
WHATSAPP_ALERTA_DESTINO=
SIIGO_USERNAME= # integracion de solo lectura con Siigo (app/api/siigo)
SIIGO_ACCESS_KEY=
SIIGO_PARTNER_ID=
Migraciones
Viven en supabase/migrations/, numeradas y en español, y se corren a mano
en el SQL Editor de Supabase (no hay CLI/CI de migraciones conectado). Cada
archivo explica en un comentario por qué existe. Antes de escribir una
migración nueva, revisar si la tabla que se necesita ya existe con un
esquema distinto al esperado — ha pasado más de una vez en este proyecto.
Empezar en local
npm install
npm run dev
Abrir http://localhost:3000. Necesitas un
.env.local con al menos NEXT_PUBLIC_SUPABASE_URL y
NEXT_PUBLIC_SUPABASE_ANON_KEY apuntando a un proyecto de Supabase con las
migraciones de supabase/migrations/ aplicadas en orden.
npm run build # build de produccion + chequeo de tipos/lint
npm run lint
