Login Radius — credenciales que autorizan al cliente a usar internet
El Login del Cliente es el conjunto usuario+contraseña que el equipo del cliente usa para autenticar en el servidor Radius de la red. Sin Radius autorizando, cliente queda sin internet — incluso con contrato activo.
1 Listado de Logins
Cliente → Login de contrato
2 Consumo
Cliente → Login consumo
Historial de consumo de banda por login.
3 Login en Degustación
Cliente → Login degustación
Login configurado como trial.
4 Equipo
Cliente → Login equipo
5 Historial de Login
Cliente → Login historial
6 Reply Atributos (Radius)
Cliente → Login reply
Atributos Radius retornados al equipo durante la autenticación.
Cómo funciona el Radius en el Quaza
| Etapa |
Qué pasa |
| 1. Authentication Request |
Equipo del cliente envía user/pass al servidor Radius. |
| 2. Lookup |
Radius consulta el banco del Quaza. |
| 3. Validación |
¿Contraseña bate? ¿Contrato activo? ¿Login no bloqueado? |
| 4. Reply |
Si OK: retorna IP + atributos. Si no: rechaza. |
| 5. Accounting |
Equipo envía consumo periódico. |
PADRÓN OPERACIONAL — FLUJO COMÚN
─────────────────────────────────
1. Cadastro inicial / configuración
│
▼
2. Permisos definidos por rol
│
▼
3. Operación normal:
┌──────────────────────────────────┐
│ - input del operador / cron │
│ - validación automática │
│ - persistencia en la BD │
│ - log de auditoría │
│ - notificación (si aplica) │
└──────────────┬───────────────────┘
│
▼
4. Revisión / supervisión
│
┌──────┴──────┐
▼ ▼
OK normal Desvío detectado
│ │
▼ ▼
Histórico Acción correctiva +
alerta al supervisor
Documentos relacionados
Glosario
| Término |
Significado |
| Quaza |
Sistema ERP/BSS para ISP — gestión integrada de cliente, financiero, fiscal, técnico. |
| Contrato |
Vínculo formal entre cliente y empresa. |
| Factura |
Documento de cobranza generado a partir del contrato. |
| Auditoría |
Revisión sistemática para detectar inconsistencias. |
| Permiso |
Derecho de acceso/edición vinculado a rol o usuario. |
| API REST |
Interfaz programática para integración con sistemas externos. |
| Cron / crontab |
Agendador de tareas que ejecuta en horarios definidos. |
| Webhook |
Notificación automática que sistema externo recibe. |
| Centro de costo |
Dimensión transversal — filial, proyecto, sector. |
| Conciliación |
Proceso de garantizar que extracto bancario coteja con Quaza. |
Trampas frecuentes
1. Falta de validación post-configuración. Cadastro hecho sin teste real = atrapa el error en producción. Siempre teste con dato dummy antes.
2. Permisos mal definidos. Operador con acceso de admin = riesgo. Defina roles claros.
3. No entrenar equipo nuevo.
4. Cambiar configuración sin registrar. Quién cambió, cuándo, por qué — se pierde rastro.
5. Ignorar alertas/notificaciones.
6. Operaciones masivas sin dry-run. Antes de aplicar a 1000 registros, teste con 5.
Preguntas frecuentes
¿Cómo empezar a usar este módulo?
Configure los pre-requisitos listados arriba, haga un teste en ambiente seguro (o con pocos registros), valide con el equipo, y solo después active en producción.
¿Necesito permiso especial para acceder?
Sí. Cada rol (operador/supervisor/admin) tiene permisos distintos. Confirme con el administrador del Quaza.
¿Puedo integrar con sistemas externos?
Vía API REST del Quaza. Webhooks notifican eventos importantes. Consulte el equipo técnico para credenciales.
¿Qué pasa si hay error?
Los logs quedan en el panel de tareas/auditoría. Configure alertas (email/Slack) para fallas críticas — no confíe en nadie mirando log manualmente.
¿Cómo acompañar cambios?
Cada registro tiene histórico (timestamp, usuario, acción). Use el filtro de auditoría para rastrear modificaciones sospechosas.
¿El módulo funciona multi-filial?
Sí — vía centro de costo (filial) atribuido al asiento. Reportes filtran por filial.
Buenas prácticas operacionales
Esta sección reúne hábitos que proveedores experimentados adoptan para evitar problemas recurrentes en este módulo. Aplicación consistente hace diferencia grande en el largo plazo — diferencia entre operación caótica y operación previsible.
Revisión periódica
Reserve 30 minutos por semana para revisar el estado del módulo: lo que corrió, lo que falló, lo que quedó pendiente. Anomalía detectada temprano cuesta 10× menos que descubierta tarde.
Documentación de procedimientos
Cree checklists internos para operaciones recurrentes — apertura/cierre del mes, procesamiento en lote, corrección de inconsistencias. No dependa de quien "sabe de memoria" — funcionario puede salir, enfermar, tener día malo.
Backup antes de operaciones masivas
Cualquier cambio que afecte 100+ registros debe ser precedido de backup o export. Restaurar una alteración masiva equivocada es caro; prevenir es simple.
Comunicación con cliente
Cambios que impactan al cliente (precio, cobranza, regla) deben comunicarse con antelación. Cliente sorprendido reclama; cliente avisado entiende.
Indicadores acompañados
Defina 2-3 indicadores que miden la salud del módulo. Acompañe semanalmente. Cuando alguno sale del rango esperado, investigue antes de volverse problema visible.