Skip to content

Rates & Salaries — Workflow

Overview

Rates & Salaries follows a replacement lifecycle: instead of editing existing records, each change creates a new active record and deactivates all previous ones. This preserves a complete, immutable history of compensation values and enables time-accurate lookups by any downstream module that needs to know what rate applied on a specific date.

Note

For the standard catalog lifecycle pattern, see: Workflows & Pipelines

Status lifecycle

Salary records use two statuses stored in collaborator_sensitive.status:

Status value Badge Meaning
1 ACT (green) The current active record for this collaborator
2 INA (red) A historical record, superseded by a newer entry

Info

For system-wide status guidance, see: Status

At any point in time, each collaborator has exactly one ACT record. All others are INA.

Record creation flow

stateDiagram-v2
    [*] --> Filling_form : User clicks + New salary
    Filling_form --> Confirmation : Submit form
    Confirmation --> Saved : User clicks Continue
    Confirmation --> Filling_form : User cancels
    Saved --> All_previous_deactivated : System sets status=2 on all prior records
    All_previous_deactivated --> New_record_active : New record inserted with status=1
    New_record_active --> [*]
  1. Select collaborator — form pre-fills with the last record's values as a starting point.
  2. Edit fields — all nine fields can be modified independently.
  3. Submit — the system compares the submitted values with the last record. If anything changed, a confirmation dialog lists the differences.
  4. Confirm — on confirmation, all prior records for that collaborator are set to status=2 (INA), and the new record is inserted with status=1 (ACT).

Temporal rate validity

The created_at field on each salary record is the effective start date of that record. There is no explicit end-date column. The effective period of any record spans from its created_at date up to (but not including) the created_at date of the next newer record.

This design means the rates table is a point-in-time log: to find what rate applied on any given date, query:

WHERE id_collaborator = X
  AND created_at <= [target_date]
ORDER BY created_at DESC
LIMIT 1

This pattern is used consistently across all downstream modules:

Module Usage
Timesheets Looks up the salary/rate valid on the timesheet's start date when computing collaborator cost
Department Cost Center Retrieves the rate valid on the work date to calculate departmental labor spend
Project Cost Center Uses the cc_hours and cc_salary DB views, which join collaborator_sensitive with timesheet hours using date matching
Quotations Looks up rate_hour valid on the quoted day to price collaborator time in proposals
Projects Calendar Applies date-matched rates when calculating project hours cost

Retroactive changes are not possible

The module does not support editing historical records or setting a custom effective date. The effective date is always the moment the record is created (created_at = today). If a rate should have been different on a past date, existing calculated data (timesheets, cost center reports) will not be updated automatically.

Lifecycle notes

  • One active record per collaborator at a time. Creating a new record always deactivates all prior records — not just the most recent one.
  • Currency is tied to the internal company. Changing the internal company on a new record changes the currency for all monetary fields going forward.
  • Records are never deleted. History is permanently preserved and accessible via the History modal.
  • The "From" date in History = created_at. This is set automatically at save time and cannot be edited.

Permissions

Permissions

Access and actions are permission-driven. See: Permissions