Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/ariellukezz/admision-web/llms.txt

Use this file to discover all available pages before exploring further.

The Sistema de Admisión Web models the full university admissions lifecycle as a series of connected stages, each handled by a dedicated module and user role. An admission process (Proceso) is the central record that ties everything together: it defines the academic year, the participating programs, their vacancies and modalities, the applicable fees, and the document requirements that applicants must satisfy. Every other entity in the system — pre-inscriptions, documents, scores, certificates — belongs to one process, and the active process for any session is tracked per-user through the id_proceso field and exposed to every Vue page via the proceso_actual shared Inertia prop.
The system supports multiple concurrent admission processes. An admin can have several active processes simultaneously (for example, an Admisión Ordinaria and a Segundas Especialidades running in parallel). Each user is assigned a current process (id_proceso), and admins can switch a user’s current process at any time via POST /admin/cambiar_proceso.

​
Admission Lifecycle

1

Admin creates the admission process

An administrator navigates to /admin/procesos and creates a new Proceso record, setting the name, year, and type (ordinary, segundas, CEPRE, etc.). Once the process shell exists, the admin configures:
  • Programs and vacancies — each ProgramaProceso links a study program to the process and sets vacancy counts per modality (/admin/vacantes, /admin/proceso-configuracion-programa)
  • Modalities — active admission pathways (e.g., exam, direct entry, transfer) are enabled via /admin/modalidad
  • Fees (tarifas) — payment amounts per modality are saved through /admin/tarifas
  • Document requirements — the admin defines which document types (TipoDocumento) are required for each modality via /admin/requisitos, optionally importing a template with POST /admin/requisitos/importar
  • Regulations — the official reglamento PDF is uploaded and linked at /admin/reglamentos
The process becomes visible to applicants once its status is active.
2

Applicant self-registers (5-step form)

Applicants visit /{proceso_slug}/preinscripcion — the ProcesoController@getFormulario method resolves the process slug and renders the public registration form. From there, authenticated applicants work through five guided steps under /postulante/paso-{n}:
StepRouteData collected
1/postulante/paso-1Personal data: DNI, full name, date of birth, gender, nationality
2/postulante/paso-2Contact information: phone, email, address, ubigeo (department/province/district)
3/postulante/paso-3School of origin: institution name, ubigeo, type (public/private), graduation year
4/postulante/paso-4Guardian (apoderado) information: name, relationship, phone
5/postulante/paso-5Summary review and confirmation — POST /postulante/paso-5 calls confirmarDatos()
At step 1, the system optionally pre-fills data from RENIEC via GET /postulante/api/reniec/{dni}. Real-time validation checks for duplicate email (POST /postulante/api/validar-correo) and phone (POST /postulante/api/validar-celular) before allowing submission. A CAPTCHA challenge (GET /generar-captcha) is presented to prevent automated submissions. On completion, the applicant lands at /postulante/confirmacion/{dni}.
3

Documents submitted and reviewed

After registration, the applicant accesses /postulante/documentos to upload each required document. The PostulanteDocumentoController manages the full document lifecycle:
  • GET /postulante/mis-requisitos — fetches the document requirements for the applicant’s modality
  • POST /postulante/subir-documento — uploads a file (stored per-document type)
  • POST /postulante/solicitar-revision — sends a review request to the reviewer queue
When the applicant submits a review request, a Firebase Cloud Messaging (FCM) push notification is dispatched to all online reviewers. The Revisor (id_rol = 2) receives the request in their dashboard at /revisor and reviews each document:
  • POST /revisor/documento/verify/{id} — approve or reject with a comment
  • The applicant receives an FCM notification when their document status changes
  • Unread notification counts are reflected in real time via the notificacionesNoLeidas shared prop
Admins can perform bulk validation at /admin/validacion-masiva using POST /admin/api/validacion-masiva.
4

Identity verified via RENIEC and biometric data captured

Before the exam, applicants’ identities are cross-referenced against the RENIEC national registry. Admins run batch verification from /admin/consulta-reniec — the ReniecController@consultarLista endpoint processes a list of DNIs and flags discrepancies.Biometric data (fingerprint + photograph) is then captured:
  • Photo: stored via POST /admin/guardar-foto-inscripcion (inscription photo) and POST /admin/guardar-foto-biometrico (biometric photo)
  • Fingerprint: managed by HuellaController
  • Admins can view the biometric control list at /admin/control-biometrico and download a biometric PDF for any applicant via GET /admin/pdf-biometrio/{dni} (dompdf)
Photo verification for simulacro participants is handled separately at GET /verificacion-fotos, protected by the simulacro middleware.
5

Exam simulation (simulacro) conducted and payments verified

The Simulacro module (id_rol = 6) manages practice exam sessions held before the official exam. The Simulacro operator works under /simulacro/*:
  • Registers participants in a simulacro batch
  • Uploads answer sheets and IDE files for automated scoring
  • Manages payment records for simulacro fees via PagoSimulacroController
Payment verification against the Banco de la Nación runs through GET /get-pago-BN/{dni} (PagosController@getPagosBN_OTI). Admin payment oversight is available at /admin/pagos-banco. The system also integrates with an internal treasury service to cross-check cash payments (/get-pago-caja/{dni}).
6

Scores recorded by the Calificador

After the official exam, Calificadores (id_rol = 7) enter scores under /calificacion/*. The scoring workflow:
  1. The Calificador loads their assigned exam area
  2. Scores (puntajes) are entered per applicant and program
  3. The PuntajeController manages maximum score retrieval (GET /get-puntajes-maximos-proceso/{p})
  4. Vocational test results are handled separately by DetalleExamenVocacionalController
Admins can view ponderación (weighting) settings via PonderacionController and cross-check results before publication.
7

Results published and certificates generated

Once scores are finalised, the admin publishes results. Applicants can view their own results at /{proceso_slug}/resultados (public page rendered by ProcesoController@getViewResultados) and at /postulante/mis-resultados (authenticated, with detailed performance breakdown from PostulanteResultadoController@getMiRendimiento).Result documents are uploaded by admins at POST /save-documento-resultado and become available for download in the public results section.Certificates are generated on demand:
  • POST /save-certificado — creates a certificate record for the applicant
  • GET /certificado — renders the certificate page (Vue component)
  • Certificate PDFs can be digitally signed; signature verification is available at GET /verificar/{codigo} and GET /verificacion/{codigo}
Admins manage the certificate signing infrastructure at /admin/certificados-firma (CertificadoFirmaController).
8

Admitted students receive their ingreso credential

Applicants who meet the admission score threshold are processed as ingresantes. The IngresoController handles:
  • GET /admin/pdf-biometrio/{dni} — generates the ingreso biometric card PDF (mPDF)
  • GET /admin/pdf-biometrio-manual/{dni} — manual re-generation for corrections
  • GET /carreras-previas/{dni} — retrieves prior academic history for transfer cases
The ingreso record ties back to the applicant’s pre-inscription and program selection, providing a complete audit trail from initial registration to admitted status. All actions are logged to the audit trail (activity_log) and visible to admins at /admin/trazabilidad and to applicants themselves at /postulante/mis-acciones.

Roles & Permissions

Understand which role controls each stage of the admission process and how middleware protects every route.

Platform Architecture

See how Laravel, Inertia.js, and Vue 3 work together to deliver the admissions platform.

Revisor Module

Deep-dive into the document review workflow, notification system, and audit features for Revisores.

Admin Process Management

Step-by-step guide to creating and configuring an admission process from the admin panel.

Build docs developers (and LLMs) love

Get started for freeTalk to us