fix: 拦截已删除报销进入付款创建(09-04-reimbursement-state-gap-finance-view)
这个提交包含在:
@@ -103,6 +103,17 @@ Wrong: treat a notice count or pending-batch aggregate as the complete finance w
|
||||
- Creation takes source locks, reloads facts, runs the resolver and only then
|
||||
allocates/creates a batch, items, success audit and notifications. Blocked
|
||||
preflight/create must not emit any of those success side effects.
|
||||
- New-payment candidates and `loadEntitySnapshots` both require
|
||||
`deleted_at: null`; an approved status alone is not the deletion guard.
|
||||
A deleted source yields `payment_batch.source_not_found` in readiness and
|
||||
HTTP 404 on creation, including when marked between preflight and source lock.
|
||||
Keep deletion-filter awareness in query test doubles and exercise this
|
||||
defensive fixture even though current deletion only permits draft/rejected.
|
||||
- Do not mechanically apply creation filters to historical batch detail,
|
||||
frozen snapshots or legacy evidence reads. Preserve their existing authority
|
||||
checks and test that retained history remains readable. This does not permit
|
||||
deleting approved/reserved sources; any such future change must also review
|
||||
existing-batch export, review and execution paths, not just creation.
|
||||
- Public blockers contain only reason code and optional source association.
|
||||
Neither decrypted account numbers nor account snapshots enter readiness DTOs.
|
||||
Bank-channel constraints must not silently become constraints on cash or other
|
||||
|
||||
在新工单中引用
屏蔽一个用户