### Requirement: Advance Payment Data Classification
The system SHALL distinguish legacy advance-pay (见费出单) data from new advance-pay data using `is_history_advance_pay` on `TInsuranceDetail`, synchronized to EKP as `fd_new_data` (`1`历史→`0`, `0`新→`1`;EKP 默认 `1`).
The system SHALL distinguish legacy advance-pay (见费出单) data from new advance-pay data using `is_new_data` on `TInsuranceDetail` (`1`=new, `0`=legacy), synchronized to EKP as `fd_new_data` with identical values. Legacy via migration; new dispatches after release write `isNewData=1` (no launchTime config).
#### Scenario: Legacy data identification
-**WHEN**`isJfcd=0` and (`isHistoryAdvancePay` is `1` or NULL)
-**WHEN**`isJfcd=0` and (`isNewData` is `0` or NULL)
-**THEN** the record MUST follow legacy advance-pay workflow unchanged from pre-release behavior
-**AND** EKP pushes for estimate/actual/difference MUST set `fd_new_data=0`
#### Scenario: New data identification after launch time
#### Scenario: New data identification on dispatch after release
-**WHEN**`isJfcd=0`, `isHistoryAdvancePay=0`, and record created at or after `advance-pay.new-data-launch-time`
-**THEN** the record MUST follow new advance-pay workflow defined in this change
-**WHEN**`isJfcd=0`, advance-pay conditions are met on add or batch add after application release
-**THEN** the system MUST set `isNewData=1` on dispatch
-**AND** EKP actual-premium pushes MUST set `fd_new_data=1`
#### Scenario: Stock data migration
-**WHEN** existing records have `is_jfcd=0` before release
-**THEN** migration MUST set `is_history_advance_pay=1`
-**THEN** migration MUST set `is_new_data=0` (legacy)
-**AND** behavior MUST remain identical to pre-migration legacy advance-pay
### Requirement: New Advance-Pay Dispatch Workflow
For new advance-pay data (`isHistoryAdvancePay=0`), the system SHALL skip pending-payment state and EKP estimate push on dispatch.
For new advance-pay data (`isNewData=1`), the system SHALL skip pending-payment state and EKP estimate push on dispatch.
#### Scenario: Dispatch directly to pending insurance
...
...
@@ -114,7 +114,7 @@ EKP payment callbacks and manual payment pull MUST NOT alter state for new advan
### Requirement: Insurance Purchase Processing
The system SHALL manage commercial insurance purchase from application through handling success, including add, batch add, replace, and rollback. For advance-pay (`isJfcd=0`) records, behavior MUST branch on `isHistoryAdvancePay` between legacy and new workflows.
The system SHALL manage commercial insurance purchase from application through handling success, including add, batch add, replace, and rollback. For advance-pay (`isJfcd=0`) records, behavior MUST branch on `isNewData` between legacy and new workflows.
#### Scenario: Create insurance application
...
...
@@ -122,7 +122,7 @@ The system SHALL manage commercial insurance purchase from application through h
- WHEN a purchase is submitted via `/insuranceDetail` add or batch-add endpoints
- THEN TInsuranceDetail records are created with pending handling status
- AND operation history is recorded in TInsuranceOperate
- AND advance-pay records MUST set `isHistoryAdvancePay` per launch-time rules
- AND advance-pay records MUST set `isNewData=1` on dispatch when advance-pay conditions are met
#### Scenario: Complete insurance handling
...
...
@@ -179,5 +179,5 @@ The insurances module SHALL integrate with EKP for settlement push/retry and run
- GIVEN an advance-pay push to EKP with `fd_jfcd=是`
- WHEN `initValues` builds the push payload
- THEN `fd_new_data` MUST reflect HRO `isHistoryAdvancePay` via standardized conversion
- THEN `fd_new_data` MUST equal HRO `isNewData` (same value, no inversion)
- AND new advance-pay actual push MUST set `有无预估=否` while legacy MUST retain existing estimate flag rules
### Requirement: Advance Payment Data Classification
The system SHALL distinguish legacy advance-pay (见费出单) data from new advance-pay data using `is_new_data` on `TInsuranceDetail` (`1`=new, `0`=legacy), synchronized to EKP as `fd_new_data` with identical values. **Legacy records MUST be marked by database migration** (`is_jfcd=0` → `is_new_data=0`); **new dispatches after release MUST write `isNewData=1`** when advance-pay conditions are met, without a runtime launch-time configuration.
#### Scenario: Legacy data identification
-**WHEN**`isJfcd=0` and (`isNewData` is `0` or NULL)
-**THEN** the record MUST follow legacy advance-pay workflow unchanged from pre-release behavior
-**AND** EKP pushes for estimate/actual/difference MUST set `fd_new_data=0`
#### Scenario: New data identification on dispatch after release
-**WHEN**`isJfcd=0`, advance-pay conditions are met on add or batch add, and the application version includes post-optimization dispatch logic
-**THEN** the system MUST set `isNewData=1` on dispatch
-**AND** EKP actual-premium pushes MUST set `fd_new_data=1`
#### Scenario: Stock data migration
-**WHEN** existing records have `is_jfcd=0` before release
-**THEN** migration MUST set `is_new_data=0` (legacy)
-**AND** behavior MUST remain identical to pre-migration legacy advance-pay
### Requirement: Premium and Policy Registration
The system SHALL support registration of policy premiums, invoice numbers, and policy period maintenance. For new advance-pay data, validation MUST tolerate absence of estimate `defaultSettleId`, and MUST NOT block registration based on **estimate settlement status** when an actual-premium settle exists; **expenditure status (`payStatus`)** blocking MUST still apply.
#### Scenario: Register policy premium
- GIVEN a handled insurance record
- WHEN premium registration is submitted
- THEN premium amount and billing metadata are persisted on TInsuranceDetail
- AND invoice number can be registered separately
- AND new advance-pay registration MUST apply BPO/non-BPO EKP amount rules and skip difference generation
#### Scenario: New advance-pay skip estimate settle blocking
-**WHEN** new advance-pay record has `defaultSettleId` pointing to actual premium and EKP estimate settle status is settling or settled
-**THEN** registration MUST NOT be rejected solely for estimate `settleStatus`
-**AND** registration MUST still be rejected when EKP `payStatus` is expenditure-in-progress or expenditure-completed
### Requirement: EKP Payment Callback Isolation for New Data
EKP payment callbacks and manual payment pull MUST NOT alter purchase workflow state for new advance-pay records that never enter pending payment. Per-record skip in `DoJointInsuranceTask` is sufficient; controller-level batch short-circuit is not required.
#### Scenario: Skip EKP settle callback for new data
-**WHEN**`updateInsuranceSettleStatus` processes a callback row for new advance-pay detail
-**THEN** the row MUST be skipped without updating `buyHandleStatus`, `paymentStatus`, or pre-task status
#### Scenario: Exclude new data from manual payment pull
-**WHEN**`pullPaymentStatus` runs
-**THEN** new advance-pay records MUST be excluded from pull list
-**AND** direct pull by new-data ID MUST be skipped without side effects
@@ -166,6 +166,33 @@ The insurances module SHALL integrate with EKP for settlement push/retry and run
- THEN overdue insurance records and renewal triggers are refreshed
- AND related pre-tasks or warnings are updated
### Requirement: Advance Payment Data Classification
The system SHALL distinguish legacy advance-pay (见费出单) data from new advance-pay data using `is_new_data` on `TInsuranceDetail` (`1`=new, `0`=legacy), synchronized to EKP as `fd_new_data` with identical values. Legacy records MUST be marked by database migration (`is_jfcd=0` → `is_new_data=0`); new dispatches after release MUST write `isNewData=1` when advance-pay conditions are met.
#### Scenario: Legacy data identification
-**WHEN**`isJfcd=0` and (`isNewData` is `0` or NULL)
-**THEN** the record MUST follow legacy advance-pay workflow (pending payment, EKP estimate, difference)
-**AND** EKP pushes MUST set `fd_new_data=0`
#### Scenario: New data on dispatch after release
-**WHEN**`isJfcd=0` and advance-pay conditions are met on add or batch add
-**THEN** the system MUST set `isNewData=1` and skip pending payment and EKP estimate on dispatch
#### Scenario: EKP callback skip for new data
-**WHEN** EKP payment callback processes a new advance-pay detail
-**THEN**`DoJointInsuranceTask.updateInsuranceSettleStatus` MUST skip the row without updating purchase workflow state
-**AND** controller-level batch short-circuit is not required
#### Scenario: New advance-pay skip estimate settle blocking on registration
-**WHEN** new advance-pay record has actual premium settle and EKP estimate `settleStatus` is settling or settled
-**THEN**`registeredPolicyPremium` MUST NOT be rejected solely for estimate settlement status
-**AND** registration MUST still be rejected when EKP `payStatus` is expenditure-in-progress or expenditure-completed
### Requirement: Cross-Module Integration
The insurances module SHALL consume employee and onboarding context from yifu-archives and yifu-csp, and expose data to salary risk views where applicable.