Usuarios, roles y permisos

Mosce ERP combina tres conceptos: usuarios (las personas), roles (paquetes de permisos) y permisos individuales (módulo:acción). Esta guía explica cómo invitar, qué rol darle a cada quien y cómo armar roles a medida.

Tiempo de lectura: ~8 min

Cuándo usar esto

• Vas a sumar a alguien al tenant (vendedor, cajero, contador, socio).
• Necesitas que un usuario pueda hacer una acción puntual y no sabes qué permiso activarle.
• Quieres crear un rol personalizado que no calza con los roles del sistema.
• Tienes que dar de baja a alguien que ya no trabaja contigo.

Antes de empezar

• Necesitas alguno de estos permisos según la acción:
  • users:invite para invitar.
  • users:update para activar/desactivar.
  • users:assign-role para cambiar el rol de membresía (ADMIN/MEMBER).
  • roles:manage para crear, editar o borrar roles personalizados.
• El proveedor de email del tenant tiene que estar configurado, porque la invitación se envía por correo. Si no lo está, verás un toast de Integración no configurada; ve a Ajustes › Integraciones primero.

Conceptos clave

Usuarios

Una persona con cuenta en Mosce ERP que pertenece a tu tenant a través de una membresía. Cada membresía tiene:

• Un rol de membresía a nivel tenant: OWNER, ADMIN o MEMBER.
• Cero o más roles (los que aparecen en Ajustes › Roles) que aportan permisos finos.
• Un estado activo / inactivo. Inactivo = no puede iniciar sesión, pero la cuenta y su historial se conservan.

OWNER salta todas las verificaciones de permiso: tiene acceso total a tu cuenta, sin importar qué permisos tenga su rol. ADMIN no hace bypass: solo puede hacer lo que sus roles le concedan, exactamente igual que MEMBER. La diferencia entre ambos está en la administración de la membresía, no en un acceso privilegiado a los datos.

Roles

Un rol es un paquete con nombre. Hay dos tipos:

• Roles del sistema - se crean automáticamente cuando se provisiona el tenant. No se pueden editar ni borrar; los reconoces por la etiqueta Sistema.
• Roles personalizados - los creas tú. Puedes editarlos y borrarlos. Si un rol personalizado tiene usuarios asignados, no puedes eliminarlo: primero quítalo de esos usuarios.

Roles del sistema

Cada rol de fábrica trae lo que sus propias tareas necesitan

Un rol de fábrica llega listo para hacer su trabajo de punta a punta. El Vendedor puede cotizar, crear el pedido, facturarlo y ver los impuestos que llevan esas facturas; el Cajero puede cobrar y cerrar su caja. No tienes que recomponerlos permiso a permiso antes de que alguien pueda trabajar.

Esto no siempre fue así, y el motivo del cambio vale la pena conocerlo porque explica qué mirar si algo sale raro: un rol al que le falta un permiso no siempre da un error. A veces simplemente produce un resultado incompleto. El caso que lo destapó fue un Vendedor que no podía leer los impuestos configurados: facturaba sin problema aparente, y las facturas salían sin ITBIS, sin un solo aviso.

• Propietario funciona con acceso total y no necesita permisos asignados.
• Administrador, Gerente, Vendedor, Cajero y Visualizador traen cubiertas sus operaciones, y siguen siendo auditables permiso a permiso en Ajustes › Roles.
• Los roles de fábrica se completan solos cuando la aplicación incorpora permisos nuevos. No tienes que recrear roles ni reasignar usuarios.
• Lo que concedas de más sigue siendo decisión tuya. Un Vendedor no ve reportes financieros ni ajustes de la empresa porque no los necesita para vender; si en tu negocio sí los necesita, se los concedes tú.

Un rol personalizado es responsabilidad de quien lo crea. Lo anterior vale para los roles de fábrica. Si construyes uno a medida, conviene recordar que un permiso que falta puede no dar error, solo un resultado a medias, así que merece la pena probar el flujo completo con una cuenta que tenga ese rol antes de repartirlo.

Un permiso concedido se aplica en cuanto la persona recarga la pantalla. No hace falta que cierre sesión: los permisos ya no viajan dentro de la sesión, se consultan al servidor, y concederlos o quitarlos surte efecto de inmediato. Si alguien dice "me lo diste y no lo veo", pídele que recargue la página. Lo que sí necesita volver a entrar es un cambio de módulos o de plan, porque esos sí viajan en la sesión.

Los dos permisos del cierre de caja

cash-register:view-close-amounts decide si al cerrar se ve el monto que el sistema espera. Quien no lo tiene cuenta a ciegas. No es desconfianza gratuita: si el esperado está a la vista, nadie declara un número distinto al que tiene delante, y el arqueo deja de medir nada. Lo que se oculta es lo que el sistema espera, nunca lo que la persona contó.

cash-register:authorize-close permite aprobar el cierre de un turno ajeno y los retiros de gaveta, cuando la empresa activa esa exigencia. Nadie puede autorizarse a sí mismo, ni aun teniendo el permiso.

Ninguno de los dos viene en el rol de Cajero, que es justo el sentido de que existan. Ver Caja registradora.

Permisos

Un permiso es una capacidad atómica con formato recurso:acción. Por ejemplo:

• invoices:create - crear facturas.
• inventory:adjust - hacer ajustes de inventario.
• fiscal:read / fiscal:manage - ver o gestionar el módulo fiscal.
• roles:manage, users:invite, modules:manage - administración del tenant.

El catálogo completo está agrupado por recurso (facturas, productos, inventario, contabilidad, fiscal, reportes, etc.) y se ve dentro del formulario de un rol personalizado.

Permisos de compras - granulares por acción

El módulo de compras separa cada acción en su propio permiso, para que puedas, por ejemplo, dejar que un almacenista reciba mercancía sin poder enviar órdenes al proveedor, o que un comprador cree y envíe órdenes pero no las cancele.

El permiso purchases:manage se mantiene como permiso heredado para no romper roles antiguos que lo tuvieran: agrupa la capacidad de enviar y cancelar. Los roles nuevos deben usar los permisos granulares (purchases:send, purchases:cancel). El rol Gerente ya incluye los nuevos permisos, así que los gerentes existentes conservan su capacidad sin cambios.

Ver el flujo completo en Compras.

Permisos de caja y punto de venta

El rol Cajero de fábrica ya puede operar una caja de principio a fin. Un cajero recién creado abre su turno, vende en el mostrador, cobra los documentos que llegan a caja, registra movimientos e imprime sus recibos, sin que le configures nada.

Dónde está la línea. Devolver dinero en la caja y dentro del turno sí es trabajo de cajero: entra en el cuadre del turno y queda cuadrado al cierre. Mover ese mismo dinero desde la administración y fuera del turno, no.

Cobrar y anular un cobro son dos permisos distintos

Anular un pago ya registrado tiene su propio permiso, payments:void, separado del permiso de cobrar (invoices:pay). Antes bastaba con poder cobrar: quien registraba un cobro podía deshacer uno ya asentado.

La razón es de control interno: registrar un cobro es trabajo de mostrador; deshacer un cobro ya asentado reabre el saldo del documento y afecta al cuadre del turno. De fábrica lo llevan Administrador y Gerente; el Cajero no. Si en tu negocio el cajero debe poder anular pagos, concédeselo explícitamente desde Ajustes › Roles.

Ver Cobros y métodos de pago.

Aplicar saldo a favor y aplicar nota de crédito son dos permisos distintos

invoices:apply-customer-credit y invoices:apply-credit-note cubren dinero distinto, con orígenes distintos: uno paga con el saldo que le quedó a un cliente de una devolución o de un anticipo, el otro paga consumiendo una nota de crédito, que es un comprobante fiscal electrónico. Que un rol pueda usar uno no significa que pueda usar el otro. Ninguno de los dos viene de fábrica en el rol Cajero.

invoices:register-advance es otro permiso aparte: cubre recibir dinero de un cliente antes de que exista una venta (un anticipo), no gastarlo. Tampoco viene de fábrica en ningún rol salvo el Propietario. Ver Clientes y Cobros y métodos de pago.

invoices:withhold-tax-override ("Decidir la Devolución del ITBIS") no da ni quita la capacidad de devolver: quien lo tiene puede cambiar el criterio por defecto de la ventana de 30 días en una devolución concreta, en cualquiera de los dos sentidos. Devolver el ITBIS pasados los 30 días es una decisión con consecuencias fiscales y queda registrado quién la autorizó, por eso va aparte y solo lo trae de fábrica el rol Administrador. Ver Devoluciones y reembolsos.

Permisos que hay que conceder a mano

Estos dos no vienen de fábrica en ningún rol y suelen dar la impresión de que "el botón está roto" cuando en realidad falta concederlos:

Permisos fiscales avanzados - contingencia y reemplazos

Los siguientes permisos son relevantes si tienes usuarios con rol MEMBER que necesitan gestionar episodios de contingencia o emitir e-CFs de reemplazo. OWNER y ADMIN los tienen por defecto.

Para crear un rol de contador externo con acceso a contingencia y reemplazos, por ejemplo, activarías fiscal:read, fiscal:contingency:declare y fiscal:replacement:create. Reservá fiscal:past-sla:decide y fiscal:replacement:override-window para quienes tengan la autoridad fiscal para esas decisiones.

Permisos del panel de control

Los siguientes permisos controlan qué secciones del panel de control principal puede ver cada usuario. Los encontrarás en el formulario de cualquier rol personalizado, igual que el resto del catálogo.

Cada permiso desbloquea exactamente una sección: si el usuario no tiene el permiso, esa sección no aparece en su panel y no genera ninguna solicitud al servidor (no es solo ocultarla visualmente). El panel incluye además un selector de período con cuatro opciones - mes en curso (default), mes pasado, trimestre o año - que aplica a todas las secciones que el usuario tenga autorizadas.

Por defecto, Propietario y Administrador ya los tienen (el primero por acceso total, el segundo porque vienen incluidos en su configuración por defecto). Los roles operativos (Gerente, Vendedor, Cajero, Visualizador) no los traen de fábrica: el administrador de tu cuenta los asigna desde Ajustes › Roles según quién necesite ver cada sección.

Permisos del registro de auditoría

Los siguientes permisos controlan el acceso al visor del registro de auditoría. Están disponibles solo en el plan Inicial o superior; en el plan gratuito el visor no se muestra aunque el usuario tenga el permiso asignado.

Propietario tiene acceso total por diseño. Administrador tiene audit:read incluido en su configuración por defecto. El resto de los roles no los trae de fábrica.

Consulta Registro de auditoría para entender qué contiene el registro y cómo usarlo.

Paso a paso: invitar a un usuario

1. Ve a Ajustes › Usuarios y pulsa Invitar usuario.
2. Completa:
   • Email del invitado.
   • Rol (uno de los del sistema o uno personalizado) - esto le aporta los permisos finos.
   • Rol de membresía: ADMIN (acceso total) o MEMBER (solo lo que el rol permite).
3. Pulsa Enviar. La persona recibe un correo con un enlace para aceptar la invitación y crear su contraseña.
4. Al aceptar, aparece en la tabla de usuarios como activa.

No hace falta configurar el correo antes. Si tu negocio todavía no ha conectado un proveedor propio, la invitación sale igualmente por el correo de la plataforma. El mensaje dice siempre quién invita y a qué empresa, así que el destinatario lo reconoce aunque el remitente no sea el dominio de tu negocio. Si conectas tu proveedor, se usa el tuyo. Ese respaldo es solo para invitaciones: enviar cotizaciones y facturas a clientes sigue exigiendo el tuyo. Ver Ajustes generales.

Paso a paso: cambiar el rol de membresía o desactivar

En la tabla de Ajustes › Usuarios, en la columna Acciones de cada fila tienes:

• Cambiar rol - abre un diálogo para asignarle el rol de permisos que decide lo que esa persona puede hacer: Gerente, Vendedor, Cajero, Visualizador o cualquier rol personalizado tuyo. Requiere el permiso users:assign-role, y el cambio surte efecto en cuanto esa persona recarga la pantalla.
• Sucursales - decide en qué sedes puede trabajar.
• Desactivar / Activar - bloquea o restaura el acceso.

No puedes editarte a ti mismo (verás un marcador Tú en lugar de los botones), y no puedes desactivar al último propietario del tenant: la API responde con el error Último propietario protegido.

Paso a paso: crear un rol personalizado

1. Ve a Ajustes › Roles y pulsa Nuevo rol.
2. Pon un nombre (por ejemplo Contador externo) y opcionalmente una descripción.
3. Marca los permisos en la matriz, agrupada por recurso. Cada permiso muestra su slug y, cuando aplica, una descripción corta.
4. Guarda. El rol aparece en la sección Roles personalizados y ya está disponible en la pantalla de invitación y en Cambiar rol.

Para ajustar permisos después, abre el rol con el icono de lápiz y vuelve a guardar. Para eliminarlo, usa el icono de papelera (no funciona si tiene usuarios asignados).

Resultado esperado

• El invitado recibe un correo y, tras aceptarlo, puede iniciar sesión y ver solo lo que su rol permite.
• En la tabla Usuarios, los miembros activos tienen un punto verde y los inactivos uno gris.
• Los roles personalizados conviven con los del sistema. Un usuario puede tener varios roles a la vez: sus permisos efectivos son la unión de todos.

Errores comunes

• No llega el correo de invitación. Revisa que el proveedor de email del tenant esté configurado en Ajustes › Integraciones y que el destinatario revise spam.
• No puedo desactivar al propietario. Es por diseño: tiene que existir al menos un propietario activo. Promueve a otra persona a propietario primero.
• Borré un permiso del rol y el usuario sigue accediendo. Si tiene asignados otros roles que también incluyen ese permiso, el efecto es la unión. Revisa todos los roles del usuario.
• Concedí un permiso y el usuario sigue sin verlo. Pídele que recargue la página. Los permisos se consultan al servidor en cada carga, así que no hace falta cerrar sesión.
• Mi cajero no puede abrir la caja. El rol Cajero de fábrica ya trae los permisos de turno de caja. Si le asignaste un rol personalizado, concédele cash-session:open y el resto de los permisos de la tabla de caja, y pídele que recargue la página.
• Mi cajero no ve saldo a favor entre los métodos de cobro, ni la opción de registrar un anticipo. Ninguno de los dos viene de fábrica en el rol Cajero. Concede invoices:apply-customer-credit y invoices:register-advance según lo que necesite, y pídele que recargue la página.
• No veo el punto de venta en el menú. Falta pos:orders.read o pos:orders.create en el rol del usuario, o el módulo de punto de venta no está activo para tu plan. Revisa ambos: primero Módulos, después el rol.
• Le di el rol Administrador y no puede hacer casi nada. Es el comportamiento esperado: los roles de fábrica son conservadores y el Administrador arranca con muy pocos permisos. Concédele en Ajustes › Roles los que necesite.
• Borré un rol y dejó usuarios sin permisos. Solo se permite borrar roles personalizados sin usuarios asignados; si llegaste a este estado, vuelve a crear el rol y asignarlo, o asigna otro distinto a esos usuarios.

Relacionados

• Panel de control - descripción de cada sección del panel y cómo interpretar las métricas.
• Módulos - qué módulos están encendidos y, por tanto, qué permisos tienen efecto real.
• Facturación y suscripción - el plan condiciona el número máximo de usuarios.
• Ajustes generales - datos del tenant que ven todos los usuarios.
• Compras - dónde aplican los permisos purchases:*.
• Cobros y métodos de pago - qué implica payments:void frente a invoices:pay.
• Caja registradora - el turno que operan los permisos cash-session:*.
• Punto de venta (POS) - qué necesita un cajero para trabajar.