호텔 계산기 정책 v2 — 계산기 3종 + 정책 갈래

정본 = 03_설계/호텔_계산기_정책_v0.md · 2026-08-12 · 이 표가 곧 계산기 테스트 케이스 원장

A. 선결제(견적) 계산기

입력 = 룸·박수 구간, 예정 입퇴실, 마리 수, 등원 계획 → 출력 = 선결제액

B. 취소→환불 계산기

입력 = 예약 + 취소 요청 시각(고객 발신) + 사유 → 출력 = 환불액 + 박별 판정 근거

C. 후정산·재정산 계산기

입력 = 예약 + 실제 입퇴실 + 투숙 중 발생분 + 기결제액 → 출력 = 퇴실 시 추가 청구액

D. 정책 갈래 (돈 안 움직임)

변경·지각·절차 — 가능/불가만 판정하고, 돈이 생기면 A·B·C로 위임

핵심 모델

"N박 결제 = 예약 입실 시각부터 24시간×N의 이용 한도 구매". 퇴실이 한도를 넘으면 그 룸 레스팅 시간당 단가로 추가 과금(실무 용어 "추가금" ①) + 부가서비스 퇴실 후불(② ). 덜 써도 환불 없음. 계산은 러너(결정론 코드)가 하고 헤르메스는 "어떤 계산인가"부터 갈래를 탄 뒤 입출력만 말로 푼다. 예약 메모 어휘 대응: "추가금정산필" = C 대기 · "멤차필"(멤버십 차감 필수) = C에서 전액 정산.

E. 예약변경 프로세스 (취소 6단계 준용 초안)

원형 = Hana의 예약취소 프로세스(아지트 댓글 워크플로우). 차이 = 환불액 산정 대신 변경 가능 판정+차액 산출, 마스터 DB는 "예약 갱신".
  1. 담당자 등록 — "예약변경" 상태 · 문의 채널 · 반려견명(견종)뒤4자리 · 문의 일시(48h 기준점) · 변경 요청 내용(날짜/박수/입실시각/퇴실시각/룸) 기재 후 @헤르메스 호출
  2. 헤르메스 댓글 — DB 조회 → D갈래로 가능/불가 판정 → 돈이 움직이면 위임(박수 늘림 = A 추가 견적 / 줄임 = B 환불액 / 시각 변경 = 필요 시 C 재견적) → 판정 근거 + 변경 전후 대비 + 차액 + 수단 댓글 → 담당자 확인 요청(리마인드)
  3. 담당자 변경 확정 — 확정 댓글(차액 안내·수납 계획 포함)
  4. 헤르메스 변경 스테이징 — 변경안 스테이징(마스터 DB는 차액 처리 완료까지 대기) · 추가 결제 필요 시 결제 완료 후 댓글 안내(결제 전 확정 금지) · 환불 발생 시 취소 프로세스 4–6단계 동일(현금영수증 = @로레나)
  5. 담당자 처리 완료 — 완료 댓글 → 헤르메스 마스터 DB 예약 갱신(새 일시·박수·금액 + 이력 보존) · 취소 기한은 새 일시 기준 재계산(H-S10 확정 전까지 확정 대기 표시)
  6. 후속 — 새 예약으로 리마인드·서류 게이트 재확인(입실일 당겨지면 D-2 서류 크론 재판정)

H. 질문 원장 (발송·답 수신 반영 — 8/12)

🟢 답 수신 (8/12 — 답 정본 = _raw/독핏답변/호텔_정책_추가_질문_260812.md)

🟢 발송 안 함 — 자체 해소

🟡 적립 — 다음 전달 때 합류(발송하지 않음 · 완전성 리뷰 발굴 포함)

I. 검산 원장 (계산기별 테스트 셋)

✓ = 정본 규칙 재계산 = 실제 청구액 일치(8/11 검산). ⏳ = 구현 시 수치 고정할 합성 케이스(완전성 리뷰 반영 신설). "갈래" = 어느 계산기의 테스트인가.
#갈래케이스내용금액판정
출처 축약: [요금정산 N행] = _raw/워크플로우_히스토리/호텔_요금정산/요금_정책_및_정산_기준.md · [정의서] = 03_설계/정책_정의서_v0.md · [판독 §N] = 핸드오프/원자료_이미지_전수판독_2026-08-11.md · [리뷰 cN·aN] = crossval/2026-08-11_계산기정책_완전성/(codex·Gemini finding). 충돌 시 정의서·카탈로그가 정본. v1(타임라인 구성)은 git 2f6f832 보존.