Skip to main content

Salary Component Storage

Summary​

Persistence for salary components, statutory settings, adjustments, and overtime inputs.

Audience​

Payroll developers, QA and support engineers, solution and security architects, and implementation partners.

Reference Content​

The sections below describe the confirmed logical storage contract and its implementation boundaries.

Purpose​

Describe configurable and employee/period input records used by Payroll calculation.

Ownership​

Payroll owns SalaryComponent, StatutorySetting, PayrollAdjustment, and OvertimeEntry records.

Lifecycle​

Components can be created, updated, deactivated, scoped to an employee, and bounded by effective dates. Statutory settings are tenant/component records. Adjustments and overtime are period/date inputs consumed during calculation.

Persisted fields​

Components store identity, tenant, name/category/basis, default value, recurrence, optional employee scope, effective window, and active state. Settings store component configuration and enablement. Adjustments and overtime store employee/time scope, type/source, value, and supporting metadata.

Relationships​

Employee and period association is represented by scalar identifiers and dates; no foreign keys are configured.

Constraints​

Statutory settings are unique per tenant/component. Salary component names are indexed with optional employee scope but are not unique.

Indexes​

Component lookup uses tenant/name/employee. Adjustments use tenant/employee/year/month. Overtime uses tenant/employee/date. Statutory settings use a unique tenant/component index.

Tenant behavior​

All four types have global tenant filters; compatibility methods commonly use filter bypass plus explicit tenant predicates.

Audit behavior​

Audit coverage is operation-specific. A database-wide change history for these records is not implemented.

Integration usage​

Backfill can upsert components and statutory settings. Compatibility APIs write components, adjustments, and overtime into the same context.

Known limitations​

Component duplicate prevention beyond the configured indexes is not database enforced. No temporal history or concurrency token is configured.

Requires confirmation​

  • Configuration approval/versioning and historical correction policy.
  • Uniqueness semantics for tenant-wide and employee-scoped component names.

Source References​

  • microservices/src/payroll-service/Infrastructure/PayrollDbContext.cs
  • microservices/src/payroll-service/Domain/PayrollEntities.cs
  • microservices/src/payroll-service/Infrastructure/Migrations/PayrollDbContextModelSnapshot.cs
  • microservices/src/payroll-service/Application/PayrollCompatService.cs
  • microservices/src/payroll-service/Backfill/SalaryComponentBackfill.cs
  • microservices/src/payroll-service/Backfill/StatutoryBackfill.cs

See Also​

Keywords​

  • Payroll database
  • Salary Component Storage
  • Payroll persistence

Revision Information​

  • Status: Draft
  • Last reviewed: 2026-07-15
  • Review cycle: Quarterly