Bitácora (Shift Log) API
The Bitácora API manages shift-based production logging. Each shift (turno) has a dedicated bitácora that tracks production, quality, incidents, and operational data across all production processes.Authentication
All endpoints require authentication via JWT token (header or cookie). Some endpoints require specific permissions:MANAGE_QUALITY- Required for opening/closing shift logsMANAGE_PRODUCTION- Required for saving process data
Core Concepts
Shift Structure:- T1 (Turno 1): 07:00 - 15:00
- T2 (Turno 2): 15:00 - 23:00
- T3 (Turno 3): 23:00 - 07:00 (next day)
ABIERTA- Active shift, data entry allowedREVISION- Closed with deviations requiring reviewCERRADA- Finalized, immutable
Get Current State
Response Fields
Whether there is an active shift log.
Current bitácora details.
Summary of all production processes.
Overall shift state: SIN_TURNO, EN_PROCESO, LISTO_PARA_CIERRE, CERRADO
Recommended next action: ABRIR_TURNO, IR_A_PROCESO, CERRAR_TURNO, etc.
Whether all processes are complete and shift can be closed.
Example Request
cURL
JavaScript
Example Response
Get Active Shift Log
Response
Returns the active bitácora object ornull.
Open Shift Log
MANAGE_QUALITY
Opens a new shift log for the current shift. Automatically determines the shift (T1/T2/T3) based on current time.
Business Rules
- Only one shift log can be active at a time
- Shift and operational date are auto-calculated
- Out-of-hours flag is set if opened outside normal shift time
- Inspector is set from authenticated user
Implementation
Frombitacora.controller.js:127:
Example Request
cURL
Example Response
Error Responses
400 Bad Request
Returned when a shift log is already open:
Close Shift Log
MANAGE_QUALITY
Closes a shift log after validating all processes are complete.
Path Parameters
Bitácora ID to close
Closure Validation
Frombitacora.service.js:106:
- Process Validation: Every process must have quality samples and production data
- Personnel Check: Processes with activity must have assigned personnel
- Downtime Validation: Total downtime cannot exceed programmed time
- Rejection Detection: If quality rejections exist, state moves to REVISION
- Observation Requirement: Deviations require detailed observations
Response
Success or revision message
Final state: CERRADA or REVISION
Example Request
cURL
Example Response
Get Process Data
Query Parameters
Bitácora ID
Process ID (1-9)
If true, retrieve data from the last closed shift for this process (for parameter inheritance)
Response
Whether the process was marked as non-operational this shift
Planned orders and personnel from weekly planning (if available)
Quality samples recorded
Production records by order and machine
Waste/scrap records
Process-specific operational parameters (e.g., temperatures, speeds)
Whether the shift is closed and data is read-only
Save Process Data
MANAGE_PRODUCTION
Saves production and quality data for a process.
Request Body
Target bitácora ID
Process ID (1-9)
Mark process as non-operational (e.g., maintenance, no orders)
Reason for non-operation (required if no_operativo = true)
Production records:
Quality samples:
General observations or notes
Example Request
cURL
Get Time Summary
Query Parameters
Bitácora ID
Process ID
Response
Programmed time in minutes (typically 480 for an 8-hour shift)
Total downtime in minutes
Effective production time = programmed - downtime
Example Response
Best Practices
Audit Trail: All actions are automatically logged with user, timestamp, and changes. This supports regulatory compliance.
Related Endpoints
- Production Orders - Manage production orders
- Incidents - Report shift incidents
- Quality Control - Quality sample management
- Planning - Weekly production planning