Case Files (Expedientes): Lifecycle and Document Management

An Expediente is the central dossier that ties an adolescent to a specific infraction and the resulting socio-educational measure. It records the assigned UZDI, the measure start and end dates, the current workflow state, and any attached documents. Every adolescent may have multiple expedientes over time — one per distinct judicial event.

Accessing the Module

Route: /app/expedientes
Sidebar group: Gestión
Access: All authenticated roles can view, search, create, edit, and delete case files.

Table Features

The view loads the full expediente list from GET /api/v1/expediente on mount. Filtering and pagination are applied client-side.

Feature	Detail
Rows per page	7 (`PAGE_SIZE = 7`)
Search	Matches on adolescent name, expediente code (`EXP-YYYY-NNNN`), or infraction name
Filter — Estado	Dropdown: Todos / En proceso / Atraso / Incomparecencia
Columns	N.º Expediente · Adolescente (name + cédula) · Infracción · Medida · UZDI · Inicio medida · Estado · Acciones

The Estado filter values are constrained by a DDL CHECK constraint on the expediente table. Only three values are valid: 'En proceso', 'Atraso', and 'Incomparecencia'. No other string will pass backend validation.

Auto-Generated Expediente Numbering

Expediente codes are not stored in the database. They are computed client-side by expedienteService.getAll() from the record’s numeric id and the year of fecha_inicio_medida:

// expediente.service.ts — getAll()
codigo: `EXP-${anio}-${String(e.id!).padStart(4, '0')}`
// e.g. EXP-2024-0042

Segment	Source	Example
`EXP`	Literal prefix	`EXP`
`YYYY`	`fecha_inicio_medida.substring(0, 4)`	`2024`
`NNNN`	Database `id` zero-padded to 4 digits	`0042`

If no fecha_inicio_medida is set the year defaults to the current calendar year. The code is display-only — search, filter, and sorting use it but the API receives the raw id.

Status Lifecycle

           ┌─────────────┐
           │  En proceso │  ← initial state on creation
           └──────┬──────┘
         ┌────────┴────────┐
         ▼                 ▼
    ┌─────────┐   ┌──────────────────┐
    │ Atraso  │   │ Incomparecencia  │
    └─────────┘   └──────────────────┘

Estado	Badge color	Meaning
`En proceso`	`.badge.green`	Measure is active and on track
`Atraso`	`.badge.amber`	Adolescent is behind the schedule defined by the measure
`Incomparecencia`	`.badge.red`	Adolescent failed to appear at a required appointment

State transitions are made manually by editing the expediente and selecting a new estado value from the dropdown.

Creating an Expediente

Click 'Nuevo expediente'

Click the Nuevo expediente button (top-right toolbar). A md-size modal opens with two sections: Vínculos del expediente and Fechas de medida.

Fill the form

Section 1 — Vínculos del expediente

Field	Type	Required	Notes
Adolescente	Select	✅	Loaded from `adolescenteService.getAll()`; shows name + cédula (`adlc_id`)
Estado	Select	✅	En proceso / Atraso / Incomparecencia (`estado`)
UZDI	Select	✅	Loaded from `GET /api/v1/uzdi` catalogue (`uzdi_id`)
Infracción	Select	✅	Loaded from `GET /api/v1/infraccion` catalogue (`infc_id`)
Medida socioeducativa	Select	✅	Loaded from `GET /api/v1/medida-socioeducativa` catalogue (`mdso_id`)

Section 2 — Fechas de medida

Field	Type	Required	Notes
Fecha inicio	Date picker	✅	Start of the measure period (`fecha_inicio_medida`)
Fecha fin	Date picker	❌	End date; leave blank if open-ended (`fecha_fin_medida`)

The Crear expediente button is disabled while any required field (adlc_id, uzdi_id, infc_id, mdso_id, estado, fecha_inicio_medida) has a falsy value.

Submit

Click Crear expediente. The service sends:

POST /api/v1/expediente
Content-Type: application/json

{
  "adlc_id": 7,
  "uzdi_id": 2,
  "infc_id": 5,
  "mdso_id": 3,
  "estado": "En proceso",
  "fecha_inicio_medida": "2024-03-01",
  "fecha_fin_medida": "2025-03-01"
}

On success the modal closes and expedienteService.getAll() is called to refresh the table.

Editing an Expediente

Click the edit icon

Click the pencil icon in the Acciones column. The modal opens pre-filled with the existing values extracted from row._raw.

Modify fields

All form fields are editable, including estado. Use this to transition the workflow state (e.g., from En proceso → Atraso).

Save

Click Guardar cambios. The service sends:

PATCH /api/v1/expediente/:id
Content-Type: application/json

{ ...same payload shape as POST... }

Document Management

The ExpedienteForm standalone component (used outside the main table view) includes a drag-and-drop document attachment zone:

<div class="attach-area">
  <!-- drag-and-drop or file selector -->
  Arrastre documentos aquí o
  <button type="button" class="attach-link">seleccione archivos</button>
</div>

Accepted document types and maximum file size are controlled by backend validation. Contact your system administrator if an upload is rejected.

Closing an Expediente

To close a case file, edit the expediente and change estado to the appropriate terminal state. There is currently no dedicated “Close” button — the state transition is performed through the standard edit modal.

A future release will add a dedicated Cerrar expediente confirmation modal that sets estado to a closed value and stamps a fecha_cierre timestamp. For now, use the edit flow to update the state manually.

Deleting an Expediente

Click the delete icon

Click the ban icon in the Acciones column. A small confirmation modal opens showing the adolescent name and expediente code.

Confirm

Click Eliminar registro. The service calls:

DELETE /api/v1/expediente/:id

The table refreshes on success.

Deleting an expediente is permanent and cannot be undone. All associated documents linked to this expediente will also be removed from the database.

Service Layer Reference

All HTTP calls are delegated to expedienteService (src/services/expediente.service.ts):

// expediente.service.ts
export const expedienteService = {
  // GET /api/v1/expediente
  async getAll(): Promise<ExpedienteRow[]>,

  // POST /api/v1/expediente
  async create(payload: ExpedientePayload): Promise<ExpedienteDto>,

  // PATCH /api/v1/expediente/:id
  async update(id: number, payload: Partial<ExpedientePayload>): Promise<ExpedienteDto>,

  // DELETE /api/v1/expediente/:id
  async remove(id: number): Promise<void>,
}

getAll() maps raw DTOs into display rows and computes:

codigo — the EXP-YYYY-NNNN display code
adol — full adolescent name (nombre + apellido)
tono — badge color class derived from estado
inicio / fin — dates formatted as DD/MM/YYYY

The full raw DTO is kept in _raw for the edit pre-fill logic and the upcoming-reviews sort in the Dashboard.

Valid Estado Values (DDL Constraint)

-- expediente table DDL (PostgreSQL)
CONSTRAINT chk_expediente_estado
  CHECK (estado IN ('En proceso', 'Atraso', 'Incomparecencia'))

Any value outside these three strings will be rejected by the backend’s ValidationPipe with a 400 Bad Request response.

Using the Application

Reporting & Administration

Accessing the Module

Table Features

Auto-Generated Expediente Numbering

Status Lifecycle

Creating an Expediente

Editing an Expediente

Document Management

Closing an Expediente

Deleting an Expediente

Service Layer Reference

Valid Estado Values (DDL Constraint)

Build docs developers (and LLMs) love

Using the Application

Reporting & Administration

Documentation Index

​Accessing the Module

​Table Features

​Auto-Generated Expediente Numbering

​Status Lifecycle

​Creating an Expediente

​Editing an Expediente

​Document Management

​Closing an Expediente

​Deleting an Expediente

​Service Layer Reference

​Valid Estado Values (DDL Constraint)

Build docs developers (and LLMs) love

Accessing the Module

Table Features

Auto-Generated Expediente Numbering

Status Lifecycle

Creating an Expediente

Editing an Expediente

Document Management

Closing an Expediente

Deleting an Expediente

Service Layer Reference

Valid Estado Values (DDL Constraint)