# QA Report - Redmine #4144 (dev)

- Generated: 2026-09-18T19:00:00+09:00
- Redmine: https://itsm.bix.bz/issues/4144
- QA Redmine: https://itsm.bix.bz/issues/4174
- Subject: 테넌트별 연휴 정산시간 조정 및 기존 미지급 정산 일괄 이동 기능
- Workflow Status: 종료
- Status: PASS
- Result JSON: artifacts/result-summary.json
- Roles: ADMIN -> TA
- Route Candidates: artifacts/route-candidates.json

## Scope

개발계 빅스페이먼츠에서 커스텀 정산 일정 OFF/ON, 테넌트·법인·영업점·가맹점 직접 정책 상속/예외/삭제, 일정 경계·검증, 기존 미지급 이동, 승인 취소, 일반정산과 I+0 즉시정산 생성·지급 분리를 ADMIN/TA 계정 범위에서 검증

## Checklist

1. 전체 정책 OFF에서 최신 20개 MID 승인 후 기존 정산주기대로 생성되고 2026-09-29 14:00으로 이동하지 않는지 확인
2. 테넌트 ON에서 제한기간 안의 일반·즉시정산만 2026-09-29 14:00으로 이동하고 기간 밖 및 기존 생성 정산은 변하지 않는지 확인
3. 테넌트 ON + 법인 OFF에서 법인과 직접 설정이 없는 하위 영업점·가맹점이 예외가 되는지 확인
4. 법인 OFF + D+1 가맹점 직접 ON에서 해당 가맹점만 다시 적용되는지 확인
5. 테넌트 ON + D+1 가맹점 직접 OFF에서 해당 가맹점만 예외이고 P+10·I+0 즉시정산은 적용되는지 확인
6. D+1 가맹점 직접 정책 삭제 후 상위 테넌트 일정을 다시 상속하는지 확인
7. 법인 정책 ON을 유지한 채 마지막 일정만 삭제하면 일정 0건으로 동작하고 상위 테넌트 일정을 재상속하지 않으며, 법인 정책 자체 삭제 후에는 재상속하는지 확인
8. 법인·영업점 직접 ON/OFF와 TENANT→CO→BO/VE 계층에서 BO와 VE가 형제로 서로 상속하지 않는 범위를 확인
9. 기존 미지급 정산 이동에서 선택한 대상만 이동하고 동일 시각에도 합산하지 않으며 settlement ID·금액·target 소속을 유지하는지 확인
10. 이동된 승인 거래 취소 후 취소 거래·취소 정산·원거래 연결·금액·예정일을 확인
11. 모든 정책을 다시 OFF로 복원한 후 최초 OFF 결과와 같은지 확인
12. 제한 시작 시각은 포함하고 제한 종료 시각은 제외하며 종료 후 I+0 즉시정산도 기존 주기로 생성되는지 확인
13. 일정 생성·수정·삭제, 기간 겹침, 시작 < 종료 <= 변경 후 정산예정시각 제약, Login ID 표시, 수정·삭제 아이콘을 확인
14. 정책 ON + 일정 0건과 정책 자체 삭제의 상속 결과를 구분해 기록
15. I+0 즉시정산은 정산 생성과 지급 완료를 구분하고 법인 지갑 부재 메시지가 발생하면 지급 결과만 별도 문제 발견/확인 불가로 기록
16. 거래일 기준 ON/OFF에서 늦은 통보 거래의 정책 적용 기준일이 각각 거래일/통보일로 달라지는지 확인
17. 최신 20개 MID의 H/D/M/P/W/I 전체 정산주기와 주말·공휴일 이체 설정 조합을 OFF/ON 결과로 비교
18. 동일 승인 통보를 중복 전송해도 거래와 정산 대상이 중복 생성되지 않는지 확인
19. 부분취소 시 음수 거래·정산금·수수료와 원거래 연결이 보존되는지 확인
20. 동일 부서·예정시각의 합산 대상이 없을 때 생성되고 있을 때 같은 settlement ID에 정확히 합산되는지 확인
21. 미지급 이동 실행 직전 정책 상태를 재검증하고 재실행 시 0건 처리되는지 확인

## Setup Steps

1. [required] 커스텀 정산 일정 정책과 일정 상태 순차 전환 (admin/ADMIN / targets: TA / kind: data-update / mutation: temporary / guard: QA_ALLOW_PERMISSION_MUTATION / restore: required) - 부서설정 관리에서 빅스페이먼츠 테넌트와 최신 엑셀의 법인·영업점·20개 가맹점만 대상으로 정책 OFF/ON, 직접 정책 생성·일정 삭제·정책 삭제를 시나리오 순서대로 수행한다. / spec: 00-admin-custom-settlement-setup.spec.ts
2. [required] #4144 코페이 개발계 거래 생성·취소 (admin/ADMIN / targets: TA / kind: data-create / mutation: persistent / guard: QA_ALLOW_PERMISSION_MUTATION) - 실행 전 미리보기로 개발계 API, korpay-0001~0020, 케이스별 금액을 확인한 뒤 전용 스크립트로 승인·취소를 전송한다.

## Source Text

**[1] QA 요청 배경**

[4144 — 커스텀 정산 일정](https://itsm.bix.bz/issues/4144)

명절 등 특정 기간에 예정된 정산을 지정한 날짜로 미루는 기능입니다.

**처음에는 모든 커스텀 정산 일정 정책을 OFF로 두고 기존 정산이 정상 생성되는지 확인합니다. 그다음 테넌트 정책을 ON으로 변경하고, 법인·가맹별 예외를 순서대로 확인합니다.**

**[2] 테스트 대상 및 준비 자료**

| 구분 | 대상 |
|---|---|
| 테넌트 | 빅스페이먼츠 |
| 법인 | 김경주_법인 / BP100559 |
| 영업점 | 김경주_영업 / BP100564 |
| 가맹점 | 전달한 최신 가맹점 엑셀의 20개 |
| MID | korpay-0001 ~ korpay-0020 |
| 가맹 예외 대상 | 김경주_가맹_D+1(1일 후) / BP100611 |
| 비교 가맹 | 김경주_가맹_P+10(10분) / BP100570 |
| 즉시정산 가맹 | 김경주_가맹_P+1(즉시) / BP100627 |

가맹 예외란 **테넌트에서는 정산을 미루지만, 선택한 가맹만 기존 정산일정대로 처리하도록 제외하는 것**입니다. 법인 예외는 해당 법인과 별도 직접 설정이 없는 하위 부서를 제외하는 것입니다.

전달한 가맹점·법인·영업점·MID·영업라인 엑셀과 실제 화면을 대조해주세요. 상세 설정과 연결 관계는 QA 시작 시 확인합니다. 파일명의 `지급정지`는 자료 구분용입니다.

최신 목록에 없는 `김경주_가맹_루시_단 / BP100560`, `A_주홍석_바움` 등 과거 거래는 이번 결과에 포함하지 않습니다.

**[3] 공통 사용 방법**

**부서 설정 관리**

어드민에서 `시스템메뉴 > 부서설정 관리 > 부서설정 관리`에 접속합니다.

- 커스텀 정산 일정 설정이 있으면 해당 행의 **상세**를 선택합니다.
- 설정이 없으면 **생성**을 선택하고 설정타입 `커스텀 정산 일정`, 빅스페이먼츠 테넌트, 적용할 부서 종류와 부서명을 선택합니다.
- 아래 날짜를 입력하고 테스트별 안내에 따라 **활성화 또는 비활성화**하여 저장합니다.
- 기존 설정의 상세에서는 **일정 생성** 영역에 날짜를 입력합니다. 같은 기간의 일정이 이미 있으면 연필 버튼으로 수정합니다.

| 항목 | 공통 입력값 |
|---|---|
| 변경 대상 시작시각 — 포함 | 2026-09-18 오전 00:00:00 |
| 변경 대상 종료시각 — 미포함 | 2026-09-28 오전 00:00:00 |
| 변경 후 정산예정시각 | 2026-09-29 오후 02:00:00 |

**거래 생성**

SH 파일 3개를 같은 폴더에 두고 실행합니다.

```bash
bash issue-4144-korpay-qa-run.sh
```

```text
실행할 테스트: 1
개발계에 실제 거래를 생성할까요?: y
승인금액: 테스트별 지정 금액
승인일시: now
```

- 전체 MID 20개에 각각 승인 거래가 생성됩니다.
- SH는 RM 설정을 변경하지 않습니다. 먼저 화면에서 설정을 저장해주세요.
- 실행 시각과 출력된 거래번호를 기록합니다. 현재 주문번호는 `QA4144-ALL_APPROVAL-`로 시작합니다.
- 아래 예상 날짜는 **9월 18일 거래 및 전달한 부서 설정 기준**입니다. 다른 날짜에 실행하면 기존 정산예정일을 다시 확인해야 합니다.

**결과 확인**

1. `거래내역`에서 이번 실행 시각으로 조회합니다.
2. 20개 MID에 각각 승인 거래가 1건씩 생성됐는지 확인합니다.
3. `정산관리 > 정산내역`에서 날짜를 **2026-09-18 ~ 2026-12-05**로 지정합니다.
4. 법인·영업점·가맹별로 정산일과 정산금을 확인합니다.

기존 정산에 합산될 수 있으므로 **실행 전 금액과 실행 후 증가액**을 비교합니다. 이전 테스트 정산과 이번 거래를 혼동하지 않도록 거래번호를 함께 기록해주세요.

**[4] 권한 및 확인 화면**

- **어드민:** 아래 전체 테스트 수행
- **테넌트 관리자:** 빅스페이먼츠 계정으로 부여된 권한 내에서 설정 조회·변경 및 결과 확인
- 확인 화면: `부서설정 관리`, `거래내역`, `정산관리 > 정산내역`, 일정 상세의 `미지급 이동`

**[5] 테스트 순서**

**TC01. 전체 OFF — 기존 정산 생성 확인**

1. 부서설정 관리에서 빅스페이먼츠 테넌트와 김경주_법인·김경주_영업·20개 가맹의 커스텀 정산 일정 정책을 조회합니다.
2. 등록된 정책은 모두 **비활성화**합니다. 정책이 없는 부서는 그대로 둡니다.
3. 다른 RM 항목이 아닌 **커스텀 정산 일정 정책**의 상태를 확인합니다.
4. 승인금액 **12,345원**으로 전체 승인합니다.
5. 거래내역과 정산내역을 조회합니다.

확인:

- 승인 거래 20건이 생성됩니다.
- 가맹·영업·법인 정산이 각각 기존 정산주기와 방식대로 생성됩니다.
- 커스텀 일정에 적힌 `9월 29일 14:00`으로 일괄 변경되지 않습니다.
- 금액 누락·중복이 없는지 확인합니다.
- 각 부서의 정산일을 이후 ON 테스트의 비교 기준으로 기록합니다.

전달한 설정과 동일한 경우 대표 비교값은 다음과 같습니다.

| 대상 | OFF 상태의 비교 기준 |
|---|---|
| D+1 가맹 | 9월 21일 16:00 |
| P+10 가맹 | 거래 처리 후 해당 10분 정산 구간 |
| W+7 가맹 | 9월 27일 16:00 |
| 즉시정산 가맹 | 거래 처리 시점에 가까운 정산일 |
| 김경주_영업 | 9월 28일 16:00 |
| 김경주_법인 | 10월 12일 16:00 |

정산 생성과 지급 결과는 별도로 기록합니다. 즉시정산에서 `법인 지갑이 존재하지 않습니다`가 발생하면 **생성 결과는 확인하되 지급 검증은 실패 또는 확인 불가**로 남깁니다.

**TC02. 테넌트 ON — 전체 적용 확인**

1. TC01 결과를 확인한 뒤 진행합니다.
2. 하위 법인·영업점·가맹에 직접 등록된 **커스텀 정산 일정 정책을 삭제**하여 테넌트 설정을 상속할 수 있게 합니다. 삭제 전 설정을 기록합니다.
3. 빅스페이먼츠 테넌트 정책에 공통 일정을 입력하고 **활성화**합니다.
4. 승인금액 **12,346원**으로 전체 승인합니다.
5. 정산내역을 조회합니다.

확인:

- TC01에서 정산일이 제한기간 안이었던 정산은 이번에 **9월 29일 14:00**으로 생성됩니다.
- D+1·P+10·W+7·즉시정산 가맹을 대표로 비교합니다.
- 즉시정산과 P+10도 원래 처리시각에 지급되지 않는지 확인합니다.
- 제한기간 밖인 법인 `10월 12일 16:00`, 영업점 `9월 28일 16:00`은 기존 날짜를 유지합니다.
- TC01에서 이미 생성된 정산은 별도 이동 작업 없이 변경되지 않습니다.

**주의:** 하위 직접 OFF 설정을 남긴 채 테넌트만 ON으로 변경하면 하위가 계속 예외 처리될 수 있습니다. 이 케이스에서는 하위 직접 설정을 삭제해야 합니다.

**TC03. 테넌트 ON + 법인 OFF — 법인 하위 연기 제외**

1. 테넌트 정책은 ON으로 유지합니다.
2. 김경주_법인에 커스텀 정산 일정 정책을 직접 생성합니다.
3. 공통 일정을 입력하고 **비활성화**합니다.
4. 영업점과 가맹에는 직접 설정이 없는지 확인합니다.
5. 승인금액 **12,347원**으로 전체 승인합니다.

확인:

- D+1·P+10·W+7·즉시정산 가맹은 **TC01의 기존 정산일정**으로 생성됩니다.
- 테넌트 ON이어도 법인 직접 OFF로 해당 하위 부서가 연기 대상에서 제외됩니다.
- 이전에 9월 29일로 미뤄진 정산은 그대로 유지됩니다.

**TC04. 법인 OFF + 특정 가맹 ON — 가맹만 다시 연기**

1. 테넌트 ON, 김경주_법인 OFF를 유지합니다.
2. `김경주_가맹_D+1(1일 후)`에 직접 정책을 생성합니다.
3. 공통 일정을 입력하고 **활성화**합니다.
4. 승인금액 **12,348원**으로 전체 승인합니다.

| 확인 대상 | 기대 결과 |
|---|---|
| D+1 가맹 | 직접 ON이므로 **9월 29일 14:00** |
| P+10 가맹 | 법인 OFF를 상속하여 기존 정산일 |
| 즉시정산 가맹 | 법인 OFF를 상속하여 기존 즉시정산 흐름 |

**TC05. 테넌트 ON + 특정 가맹 OFF — 가맹 하나만 연기 제외**

1. 김경주_법인의 직접 정책을 삭제합니다.
2. D+1 가맹의 직접 정책을 **비활성화**합니다.
3. 테넌트는 ON, 다른 부서는 직접 설정 없는 상태로 둡니다.
4. 승인금액 **12,349원**으로 전체 승인합니다.

| 확인 대상 | 기대 결과 |
|---|---|
| D+1 가맹 | 직접 OFF 예외로 기존 `9월 21일 16:00` 유지 |
| P+10 가맹 | 테넌트 ON 상속, **9월 29일 14:00** |
| 즉시정산 가맹 | 테넌트 ON 상속, **9월 29일 14:00** |

이 케이스가 **“테넌트 전체는 정산을 미루지만 특정 가맹은 사용하지 않는다”**는 요구사항입니다.

**TC06. 가맹 예외 삭제 — 테넌트 일정 재상속**

1. D+1 가맹에 직접 등록한 정책 자체를 삭제합니다.
2. 테넌트 정책은 ON으로 유지합니다.
3. 승인금액 **12,350원**으로 전체 승인합니다.
4. D+1 가맹도 다시 **9월 29일 14:00**으로 생성되는지 확인합니다.

정책을 **OFF로 저장하는 것**은 연기 제외이고, **직접 정책을 삭제하는 것**은 상위 설정 재상속입니다.

**TC07. 법인·영업점 자체 정산의 ON/OFF 확인**

법인과 영업점의 원래 정산일도 포함하도록 테넌트 일정을 임시 변경합니다.

| 항목 | 입력값 |
|---|---|
| 시작 | 2026-09-18 00:00:00 |
| 종료 | 2026-10-13 00:00:00 |
| 대체 시각 | 2026-10-14 14:00:00 |

1. 하위 직접 설정이 없는 상태에서 테넌트 정책을 ON으로 설정합니다.
2. 승인금액 **12,351원**으로 전체 승인합니다.
3. 김경주_법인과 김경주_영업 정산이 모두 **10월 14일 14:00**으로 생성되는지 확인합니다.
4. 김경주_법인에 같은 일정의 직접 정책을 만들고 OFF로 설정합니다.
5. 승인금액 **12,352원**으로 전체 승인합니다.
6. 이번 법인 정산은 **10월 12일 16:00**, 영업점 정산은 **9월 28일 16:00**을 유지하는지 확인합니다.
7. 법인 직접 정책을 삭제하고, 김경주_영업에만 직접 OFF 정책을 만듭니다.
8. 승인금액 **12,353원**으로 전체 승인합니다.

마지막 실행에서는:

- 영업점만 기존 `9월 28일 16:00` 유지
- 법인은 `10월 14일 14:00`
- D+1 가맹도 `10월 14일 14:00`

으로 생성되는지 확인합니다. 영업점 설정 변경이 가맹까지 예외 처리하지 않아야 합니다.

**TC08. 기존 미지급 정산 이동**

1. 테넌트 일정을 공통 날짜로 복원하고 ON으로 설정합니다.
2. 하위 직접 정책을 삭제합니다.
3. 정산내역에서 TC01에 생성된 미지급 정산 중 **9월 18일 이상 ~ 9월 28일 미만**인 대상을 기록합니다.
4. `부서설정 관리 > 빅스페이먼츠 커스텀 정산 일정 > 상세 > 미지급 이동`을 선택합니다.
5. 목록에서 테스트 부서와 기존 정산일·금액을 확인합니다.
6. 대상 정산을 선택하여 이동합니다.
7. 정산내역을 다시 조회합니다.

확인:

- 선택한 정산만 `9월 29일 14:00`으로 이동
- 부서·금액·정산방식 유지
- 지급 완료 정산은 이동되지 않음
- 이동 작업 때문에 기존 여러 정산을 하나로 강제 합산하지 않음

법인 직접 OFF 정책을 다시 등록한 후 테넌트의 미지급 이동 목록을 열어, 해당 법인과 직접 설정 없는 하위 부서가 이동 대상에서 제외되는지도 확인합니다.

**TC09. 연기된 거래 취소**

1. 9월 29일로 미뤄진 미지급 거래 하나를 고릅니다.
2. 거래내역에서 원승인 MID·거래번호·승인금액을 확인합니다.
3. SH에서 `2) 전체 취소`를 선택합니다.
4. `y`를 입력하고 해당 MID·원승인금액·취소일시 `now`·원승인 거래번호를 입력합니다.
5. 거래내역에서 취소 반영 여부를 확인합니다.
6. 정산내역에서 취소금이 정상 반영되고 중복 지급할 금액이 남지 않는지 확인합니다.

메뉴의 전체 취소는 **전체 20건 일괄 취소가 아니라 선택한 거래 1건의 전액 취소**입니다.

**TC10. 다시 전체 OFF — 기존 흐름 복귀**

1. 테넌트·법인·영업점·가맹에 등록된 커스텀 정산 일정 정책을 모두 비활성화합니다.
2. 승인금액 **12,354원**으로 전체 승인합니다.
3. 이번 거래의 정산이 TC01처럼 기존 정산일정으로 생성되는지 확인합니다.
4. 이전에 이미 이동한 정산은 기존에 이동된 날짜를 유지하는지 확인합니다.

**[6] 일정 화면 및 종료 시점 확인**

부서설정 관리 상세에서 다음을 확인합니다.

- 시작이 종료보다 늦거나 같으면 저장되지 않고 안내가 표시되는지
- 대체 시각이 종료보다 늦지 않으면 저장되지 않는지
- 같은 정책에서 제한기간이 겹치는 일정을 중복 등록할 수 없는지
- 연필 버튼으로 수정하고 저장·취소할 수 있는지
- 재조회 시 날짜가 유지되고 수정자가 Login ID로 표시되는지
- OFF 상태에서 일정은 관리할 수 있지만 미지급 이동은 실행할 수 없는지

제한 종료 후 복귀는 별도로 짧은 일정으로 확인합니다.

1. 하위 직접 설정을 정리하고 테넌트 정책만 ON으로 설정합니다.
2. 기존 테스트 일정과 겹치지 않도록 정리한 뒤, **현재 시각부터 약 10분 뒤까지**를 제한기간으로 설정합니다.
3. 대체 시각은 제한 종료보다 충분히 뒤로 설정합니다.
4. 제한기간 중 전체 승인하고 즉시정산 가맹이 대체 시각으로 미뤄지는지 확인합니다.
5. 제한 종료 후, 대체 시각이 오기 전에 다시 전체 승인합니다.
6. 이번 즉시정산은 기존 흐름으로 생성되고, 앞서 미뤄진 정산은 대체 시각에 남아 있는지 확인합니다.

각 케이스 결과에는 **정책 ON/OFF 화면, 실행 시각·거래번호, 정산일·금액, 지급 결과**를 남겨주세요. 정산 생성 성공만으로 지급 완료까지 통과 처리하지 않습니다.

## Execution Summary

- Passed: 21
- Failed: 0
- Skipped: 0
- Blocked: 0
- Flaky: 0
- Duration: 350684ms
- Automated Scenarios Passed: 4

## #4144 상세 판정

- 최신 엑셀 기준 대상은 김경주_법인(BP100559) → 김경주_영업(BP100564) → korpay-0001~0020의 20개 가맹점으로 대조했습니다. 최신 목록 밖 BP100560 등은 판정에서 제외했습니다.
- TC01~TC07-E와 TC10은 모두 PASS입니다. D+1·P+10·W+7·I+0 대표 MID의 거래번호, 정산주기, 정산 대상일은 [실행 증적 JSON](artifacts/qa4144-execution-evidence.json)에 기록했습니다.
- 법인 직접 OFF에서는 법인 2026-10-12 16:00, 영업점 2026-09-28 16:00 정산에 각각 `12,352 × 20 = 247,040원`이 증가했습니다. 영업점 직접 OFF에서는 법인 2026-10-14 14:00, 영업점 2026-09-28 16:00 정산에 각각 `12,353 × 20 = 247,060원`이 증가해 BO와 VE의 형제 범위를 확인했습니다.
- 법인 정책 ON + 일정 0건은 상위 테넌트 일정을 재상속하지 않았고, 법인 정책 자체 삭제 후에는 2026-10-14 14:00을 다시 상속했습니다.
- 기존 미지급 D+1 정산은 미리보기 1건, 이동 1건, 제외 0건으로 처리됐습니다. 이동 전후 settlement ID와 대상 부서가 유지됐고, 예정일만 2026-09-29 14:00으로 변경됐습니다. 정산 배치 전후 1분 보호 구간에서는 400과 안내 문구가 반환되며, 보호 구간 밖에서 정상 이동됐습니다.
- 이동된 승인 거래 1건을 전용 러너로 전체 취소해 HTTP 200과 원거래 연결을 확인했습니다.
- 시작=종료, 대체시각=종료, 일정 겹침은 모두 HTTP 400으로 거부됐고, 일정 수정자는 Login ID `bigs_gj`로 기록됐습니다.
- 실시간 경계 검증도 PASS입니다. 17:26:58 이상~17:29:28 미만 일정에서 I+0가 17:42:58로 연기됐고, 종료 후 거래는 기존 흐름으로 복귀했으며 기존 연기 settlement ID는 그대로 유지됐습니다. 상세값은 [경계 증적 JSON](artifacts/qa4144-boundary-evidence.json)에 기록했습니다.
- 최신 20개 MID에서 H/D/M/P/W/I 전체 정산주기와 `weekendTransferEnabled` ON/OFF 조합을 비교했습니다. 기존 계산 정산일이 제한기간 안인 건만 2026-09-29로 치환되고 기간 밖 건은 유지됐습니다. 상세 설정과 거래별 비교값은 [20개 MID 인벤토리 증적](artifacts/qa4144-redmine-inventory.json)에 기록했습니다.
- 거래일 기준 ON에서는 9월 17일 거래가 제한 일정에 포함돼 9월 30일로 이동했고, OFF에서는 9월 18일 통보일 기준 기존 D+1인 9월 21일을 유지했습니다. 늦은 통보, 동일 승인 중복 전송 1건 유지, 4,000원 부분취소의 음수 거래·정산·수수료 및 원거래 연결을 확인했습니다.
- 합산 대상이 없을 때 새 정산을 생성하고 두 번째 승인 시 동일 settlement ID에 `12,407 + 12,408 = 24,815원`으로 합산됨을 확인했습니다. 이동 정책 비활성화 직후 실행은 400으로 차단됐고 재활성화 후 1건 이동, 동일 요청 재실행은 0건으로 종료됐습니다. 상세값은 [Redmine 필수항목 증적](artifacts/qa4144-redmine-mandatory-evidence.json)에 기록했습니다.
- 백엔드 기능 브랜치 `33dd6358fb`에서 지정된 Kotlin 컴파일을 통과했고, 정책 resolver·일괄 이동·거래 backfill 관련 테스트 14건이 모두 통과했습니다. live 거래 이벤트와 기존 거래 backfill이 같은 정책 resolver를 사용하는 것도 확인했습니다. 상세는 [백엔드 회귀 증적](artifacts/qa4144-backend-regression-evidence.json)에 기록했습니다.
- 요청된 계정 범위인 ADMIN·TA에서 부서설정 관리, 거래내역, 정산내역 화면 진입을 확인했습니다. BO/VE는 부서 타입으로만 정산·상속 결과를 검증했으며 로그인 역할 검증 대상이 아닙니다.
- 실제 라우트는 부서설정 `/admin/ta-department-setting`, 거래 `/trade-history-v2`, 정산 `/settlement-history/settlement-details`로 확인했습니다.
- QA 종료 후 테넌트 정책은 OFF·일정 0건, 김경주 법인/영업점/D+1 직접 정책은 0건으로 복원했습니다. 기존 박재민 정책 552/553은 변경 전과 동일한 OFF 상태입니다.


## 한눈에 보는 결과

| 확인한 항목 | 계정 | 화면 | 수행한 동작 | 결과 | 증거 자료 |
|---|---|---|---|---|---|
| ADMIN 정책 상속·예외·일정 0건·미지급 이동·취소·OFF 복귀 | 전체 | [4144][dev] 커스텀 정산 일정 | 전체 계정으로 [4144][dev] 커스텀 정산 일정 항목을 확인 | 기대한 동작과 일치했습니다. | [스크린샷 1](artifacts/screenshots/01-department-policy-final.png) |
| 시작 포함·종료 제외 실시간 경계 | ADMIN | 거래·정산내역 | 제한기간 안/종료 후 I+0 승인 | PASS | [경계 증적](artifacts/qa4144-boundary-evidence.json) |
| 20개 MID 전체 주기·주말이체 조합 | ADMIN | 거래·정산내역 | OFF/ON 거래별 예정일 비교 | PASS | [인벤토리 증적](artifacts/qa4144-redmine-inventory.json) |
| 거래일/통보일·중복·부분취소·합산·이동 멱등성 | ADMIN | API·거래·정산내역 | 독립 거래 생성 및 상태 재검증 | PASS | [필수항목 증적](artifacts/qa4144-redmine-mandatory-evidence.json) |
| 기능 브랜치 컴파일·회귀 | Backend | Gradle | 지정 컴파일 및 3개 테스트 클래스 14건 | PASS | [백엔드 증적](artifacts/qa4144-backend-regression-evidence.json) |

## 실패 또는 확인 불가 상세

- 실패 또는 확인 불가 항목이 없습니다.



## 수동 재현 필요

- 수동 재현이 필요한 항목이 없습니다.

## 스크린샷

- 전체 / [4144][dev] 커스텀 정산 일정 / ADMIN 정책 상속·예외·일정 0건·미지급 이동·취소·OFF 복귀: [스크린샷 1](artifacts/screenshots/01-department-policy-final.png)

## 화면 재현 기록

- 화면 재현 기록 자료가 없습니다.
- 화면 재현 기록은 기본적으로 실패/확인불가 항목에 한해 포함합니다. PASS 항목 trace까지 필요하면 `QA_PUBLISH_TRACE=1 npm run qa:report -- --issue <id> --env <env>`로 내부 제출용 산출물을 생성합니다.

## 실행 기록

- 실행 기록 자료가 없습니다.

## 자동화 원본 결과

| Scenario | Status | Duration | Screenshot | 화면 재현 기록 | Log | Error |
|---|---:|---:|---|---|---|---|
| 4144/dev/00-admin-custom-settlement-setup.spec.ts / [4144][dev] 커스텀 정산 일정 / ADMIN 정책 상속·예외·일정 0건·미지급 이동·취소·OFF 복귀 | PASS | 166486ms | [스크린샷 1](artifacts/screenshots/01-department-policy-final.png) |  |  |  |
| 4144/dev/01-custom-settlement-boundary.spec.ts / 시작 포함·종료 제외 경계 | PASS | 121267ms |  |  | [증적](artifacts/qa4144-boundary-evidence.json) |  |
| 4144/dev/02-redmine-mandatory-coverage.spec.ts / 20개 MID 인벤토리 | PASS | 15188ms |  |  | [증적](artifacts/qa4144-redmine-inventory.json) |  |
| 4144/dev/02-redmine-mandatory-coverage.spec.ts / 거래일·통보일, 중복, 부분취소, 합산, 이동 | PASS | 47743ms |  |  | [증적](artifacts/qa4144-redmine-mandatory-evidence.json) |  |

## Notes

- 로그인 역할 검증 범위는 요청서대로 ADMIN·TA이며, BO/VE는 부서 타입에 대한 정산·상속 검증 대상으로만 다뤘습니다.
- Redmine #4174에 검증 진행 및 정정 내역을 반영했습니다. 최종 리포트·증적 첨부와 PR 연결 후 상태를 갱신합니다.