MD-13 재고 마감 — 요일별·특정날짜 수량 제한 스케줄

공급사 물량이 갑자기 부족해지면 특정 상품(히어로)의 주문을 센터별·날짜별로 막아야 한다. 지금 있는 수량 제한은 상시(무기한)뿐이라 날짜·요일 축이 없고, 며칠만 막으려 해도 걸었다가 풀어야 한다. MD-13은 이 빈칸을 채운다 — 요일별 또는 특정 날짜(오늘~+3개월)에만 적용되는 제한 수량을 미리 등록한다.

기존 상시 제한 vs MD-13 (실측 기준)

3뷰 요약

등록 시나리오

1. 진입 — 상품 관리 › 공급사 상품 관리 › 재고 마감. 목록이 뜬다. 우측 상단 [＋ 신규 등록].
2. ① 상품 — [＋ 상품 선택] → 기존 상품 선택 모달에서 히어로 검색 → 라디오 1개 → [추가].
3. ② 방식 — 요일별이면 요일 다중 선택, 특정 날짜면 캘린더에서 날짜 선택(오늘~+3개월).
4. ③ 범위·수량 — 센터별: [＋ 센터 추가]로 센터를 고르고 행마다 제한 수량. 공통: 제한 수량 1개.
5. 저장 — 검증 통과 → 목록으로 복귀, 토스트. 같은 히어로×센터가 이미 있으면 중복 모달 → [기존 설정 열기].
6. 확인 — 목록에서 검색/필터, 또는 캘린더 보기에서 날짜별 확인.

중복 판정 — 히어로 × 센터

항목은 한 가지 방식(요일별 또는 특정날짜)만 가진다. 편집에서 방식을 바꾸면 기존 요일/날짜 행은 새 행으로 교체된다. 이 규칙 덕분에 주문 시점에 (히어로, 센터, 날짜)에 매칭되는 스케줄 행은 최대 1개다 — 우선순위 규칙이 필요 없다(§05).

저장 검증 — 미충족 시 차단 + 가이드 문구

동작: 배너에 미충족 항목을 전부 나열하고 첫 오류로 스크롤·포커스, 필드에 빨간 테두리(입력 중 실시간 해제). 방식·범위 토글을 바꾸면 에러 상태 초기화.

수정 · 삭제 · 만료 (구현 메모)

주문 시점 검사 흐름

1. 매칭 — 주문 라인(히어로 H, 센터 C, 기준일 D·요일 w)에 대해 hero_qty_schedule에서 use_yn='Y'이고 (center_code = C 또는 NULL=공통) 이며 (DATE·target_date = D) 또는 (DOW·dow = w)인 행을 찾는다. §04 중복 규칙상 최대 1행.
2. 없으면 통과 — 기존 상시 제한 검사(order_limit·seller_product_center_limit)는 별개로 그대로 수행.
3. 현재 집계 — member_order_details에서 (H, C, D)의 유효 주문 수량 합 = Σ(quantity − cancel_quantity). 유효 상태 집합은 D-1.
4. 판정 — 집계 + 이번 주문 수량 > limit_qty → 주문 불가(초과 시 처리의 기본값. 변형은 D-2).
5. 자동 복구 — 카운터를 따로 두지 않고 매번 주문 데이터를 집계하므로, 취소·반품(cancel_quantity·CANCEL_COMPLETE)은 다음 검사에서 저절로 빠진다. MD가 손댈 것 없음.

개발 논의 — 화면 미정 아님, 주문 로직 정책

-- 🆕 요일별·특정날짜 제한 수량 스케줄 (1행 = 히어로 × 센터 × 요일 1개 또는 날짜 1개)
CREATE TABLE hero_qty_schedule (
  id                 bigserial     PRIMARY KEY,
  item_id            bigint        NOT NULL,                       -- 같은 등록(목록 1행)에서 만든 행 묶음
  hero_product_code  varchar(100)  NOT NULL REFERENCES seller_product(hero_product_code),
  center_code        varchar(20)   NULL REFERENCES center(center_code),  -- NULL = 전 센터 공통
  schedule_type      varchar(4)    NOT NULL CHECK (schedule_type IN ('DOW','DATE')),
  dow                smallint      NULL CHECK (dow BETWEEN 0 AND 6),      -- 0=월 … 6=일 (프로토와 동일)
  target_date        date          NULL,                            -- 오늘~+3개월은 서비스 검증
  limit_qty          integer       NOT NULL CHECK (limit_qty >= 1),
  deadline_time      time          NOT NULL DEFAULT '16:00',        -- 고정. 입력 UI 없음
  use_yn             char(1)       NOT NULL DEFAULT 'Y',
  reg_id             varchar(100),
  reg_dt             timestamp     NOT NULL DEFAULT now(),
  upd_id             varchar(100),
  upd_dt             timestamp,
  CHECK ((schedule_type = 'DOW'  AND dow IS NOT NULL AND target_date IS NULL)
      OR (schedule_type = 'DATE' AND target_date IS NOT NULL AND dow IS NULL))
);

-- 행 단위 유일성: 같은 히어로×센터×요일(또는 날짜)에 활성 행 1개. NULL(공통)도 같은 값으로 취급 → PG15+
CREATE UNIQUE INDEX ux_hqs_slot ON hero_qty_schedule
  (hero_product_code, center_code, schedule_type, dow, target_date) NULLS NOT DISTINCT
  WHERE use_yn = 'Y';
-- PG15 미만이면: (hero_product_code, coalesce(center_code,'ALL'), schedule_type, coalesce(dow,-1), coalesce(target_date,'0001-01-01')) 로 대체

CREATE INDEX ix_hqs_lookup ON hero_qty_schedule (hero_product_code, center_code) WHERE use_yn = 'Y';
CREATE INDEX ix_hqs_item   ON hero_qty_schedule (item_id);

-- 기존 상시 제한은 그대로: seller_product.order_limit · seller_product_center_limit (변경 없음)

주문 시점 조회 예시 (D-1 가정: 기준일 = confirm_date)

-- 1) 매칭 스케줄 (최대 1행 — §04 중복 규칙)
SELECT limit_qty
  FROM hero_qty_schedule
 WHERE hero_product_code = :hero
   AND use_yn = 'Y'
   AND (center_code = :center OR center_code IS NULL)
   AND ((schedule_type = 'DATE' AND target_date = :d)
     OR (schedule_type = 'DOW'  AND dow = (EXTRACT(isodow FROM :d::date) - 1)))   -- isodow 1=월 → 0=월
 FOR UPDATE;                                                            -- 동시 주문 직렬화

-- 2) 현재 집계 (상태 집합은 D-1 결정에 따름)
SELECT coalesce(sum(quantity - cancel_quantity), 0) AS used
  FROM member_order_details
 WHERE hero_product_code = :hero
   AND center_code = :center
   AND confirm_date = :d
   AND order_status_id NOT IN ('CANCEL_COMPLETE', 'VIRTUAL_EXPIRY');

-- 3) used + :qty > limit_qty → 주문 불가 (D-2 기본값 = 차단)

• item_id는 목록의 '항목'을 식별한다(같은 등록에서 생긴 요일/날짜×센터 행 묶음). 헤더/디테일 2테이블로 나누는 것과 동치이며, 초안은 단일 테이블 + item_id로 단순하게 간다.
• 삭제는 물리 삭제를 권장한다(설정 데이터, 이력 요구 없음). use_yn은 일시 중지 용도가 생길 때만 의미가 있고, 유니크 인덱스는 use_yn='Y' 조건이라 재등록과 충돌하지 않는다.
• 하나의 항목은 한 방식(DOW 또는 DATE). 편집에서 방식을 바꾸면 그 item_id의 행을 지우고 다시 넣는다.
• 중복 규칙(§04)이 서비스 계층에서 지켜지면 매칭 행은 최대 1개다. 규칙을 완화할 경우에만 우선순위(특정날짜 > 요일, 센터별 > 공통)를 추가한다.

1. 개발 논의 2건 결정 — D-1 확정 시점(상태 집합 + 기준일 컬럼) · D-2 초과 시 처리(차단·유지 기본값 확인). D-3 권한은 1차 제외 여부만.
2. DDL 확정 — 운영·스테이지 PG 버전 확인(NULLS NOT DISTINCT 가능 여부) → hero_qty_schedule 생성. 기존 상시 제한 테이블은 손대지 않음.
3. 주문 시점 검사 — 매칭→집계→판정, 동시성 직렬화, member_order_details 집계 인덱스 추가. 취소/반품 복구는 별도 로직 없음(집계 방식).
4. 화면 구현 — 목록·신규/수정·캘린더 3뷰. 상품 선택은 기존 어드민 모달 호출(단일 선택), 센터 검색 모달은 center.use_flag 기준. 수정 저장에도 중복 검사.
5. 프로토 정리 — 주석 레일 "상시 제한 미정" 삭제·타이틀 v15·[엑셀 업로드] 자리표시자 제거 또는 별도 차수 표기.