Encashment Storage

Summary

Encashments persists an aggregate foundation, but no employee application, approval workflow, public API, or Payroll handoff is implemented.

Audience

Backend developers, QA, architects, Payroll boundary reviewers, and support.

Reference Content

The record stores integer identity, tenant, user, Leave-type string, year, units, optional amount, status, requester, requested time, and optional processed time. A non-unique tenant/user/type/year index supports lookup. Required type/status lengths and numeric precision are mapped, but there are no foreign keys, status check constraints, uniqueness constraints, or concurrency tokens.

The current factory validates positive identifiers and units, constructs a terminal-looking stored state, and raises a domain event. LeaveBalance separately validates availability in its encash method. No application service was found that atomically creates EncashmentRecord, updates LeaveBalance, persists audit/timeline, and performs a Payroll handoff. Consequently end-to-end maturity is Foundation, and the meaning of a stored status outside that factory requires confirmation.

The optional amount is internal persistence metadata; formulas and payroll values are intentionally excluded.

Source References

• microservices/src/leave-service/Domain/Leave/LeaveExtras.cs
• microservices/src/leave-service/Domain/Leave/LeaveBalance.cs
• microservices/src/leave-service/Infrastructure/LeaveDbContext.cs
• microservices/src/leave-service/Infrastructure/Persistence.cs

Related Articles

• Leave balance storage
• Data integrity and transactions

See Also

• Encashment business boundary

Keywords

• Encashment
• Foundation
• Balance effect

Revision Information

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