| 영역 | 상태 | 내용 |
|---|---|---|
| 제때센터 FC 뱃지 (정상 매핑) | 닫힘 | "내일 도착" → 실제 배송일 절대날짜 표기 반영 |
| 비-제때(지방권) 센터 FC 뱃지 | 남음 | 지방 리드타임이 제때와 다르게 동작 → 날짜 부정확 가능 · 티켓2 |
| 배송요일 데이터 정합성 | 남음 | 완전 불일치 2쌍·부분겹침 16쌍 → 배송예정일 미성립/밀림 · 티켓1 |
| 자동발주 로직 | 미사용·리스크 | 켜면 상품 리드타임 기준으로 조기 발주 → 켜기 전 조정 필요 · 티켓3 |
전체 붙여넣기 본문 → PLD-784-후속티켓.md 열기/다운로드. 각 티켓은 PLD-784의 하위작업/연결항목으로 링크 권장.
lead_time 컬럼 부재 → 센터 물류 소요일이 코드에 암묵 존재. 마감시각도 16시 비통일.center_code 기반 공통화. 센터·마감 하드코딩 금지, 미정의 센터는 방어 표시(문서2).티켓 2의 선행 산출물. "제때만 맞는" 현 상태를 전 센터 공통 규칙으로 끌어올리기 위한 기준 정의.
배송예정일은 아래 세 데이터만으로 계산된다. 독립적인 리드타임(주행일수) 컬럼은 존재하지 않는다(DB 전수 확인, lead 키워드 0건).
| 요소 | 테이블 / 필드 | 의미 |
|---|---|---|
| 셀러 배송 가능요일 | seller_weekly_delivery (요일 boolean) | 셀러가 배송/도착 가능한 요일 |
| 매장 배송지정일 | member_weekly_delivery (요일 boolean) | 매장이 받기로 지정한 요일 |
| 요일별 발주 마감 | seller_weekly_deadline (요일 HH:MM) | 주문마감=발주마감 시각. 요일마다 다름 |
| 공휴일/휴무 override | seller_custom_schedule (event_date, delivery) | 특정일 배송 스킵·마감 변경 |
| 배송예정일 산출 | ScheduleUtil | 셀러 요일 ∩ 매장 지정일 교집합 → 마감 전/후로 다음 유효일 선택 |
→ 리드타임이 데이터화되지 않았기 때문에, 제때 외 센터의 물류 소요일은 코드에 흩어져 제때 기준으로만 맞고 지방권은 어긋난다. 이 문서의 목표는 그 소요일을 명시적 규칙으로 끌어내는 것.
seller_weekly_deadline 분포 상위 — "16시 하드코딩"이 왜 위험한지의 근거.
| 평일 | 토 | 금 | 셀러 수 | 비고 |
|---|---|---|---|---|
| 16:00 | 13:00 | 16:00 | 64 | 최다 패턴 |
| 16:00 | 16:00 | 16:00 | 47 | |
| 16:00 | NONE | 16:00 | 47 | 토 미배송 |
| 16:00 | NONE | 12:00 | 23 | 금 마감 빠름 |
| 21:00 | 21:00 | 21:00 | 13 | 야간 마감 |
| 10:00 | NONE | NONE | 13 | 오전 마감 |
결론: 마감시각은 반드시 seller_weekly_deadline 실값을 참조. 뱃지·자동발주 어디서도 16:00 상수 금지.
아래는 골격이다. 센터별 실제 소요일은 개발·물류 확인 후 확정. 센터 마스터는 center 테이블(활성 34) 기준.
| 센터 그룹 | 예시 센터 | 마감 → 배송예정일 규칙 | 소요일(리드타임) | 상태 |
|---|---|---|---|---|
| 제때 (기준) | 제때(가수동) 계열 | 마감 전 = 지정 요일, 마감 후 = 다음 지정 요일 | 0~1일 (현행 반영됨) | 확정 |
| 수도권 MFC | 논현·광진·구리·송파·마포 | 확인 필요 | ? | 미정 |
| 지방 MFC (이천) | 이천(samcheongdang) | 확인 필요 — 지방 주행 가산 | ? | 미정 |
| 지방 광역 | 경남·전남·익산 등 | 확인 필요 | ? | 미정 |
| etc (직배송) | 9찬김치찌개(본사) | 셀러 직배송, 허브DC 경유 여부 | ? | 불일치 동반 |
seller_custom_schedule로 특정일 스킵/마감변경 처리 — 장치는 존재. 현재 81건 중 75건이 휴무 지정, 셀러 27개, 최신 입력 2026-05."내일 도착" 재발을 막는 표시 규칙의 단일 진실 소스. 티켓 1·2 공통 참조.
| 케이스 | 조건 | 표시 | 예시 |
|---|---|---|---|
| 일반 매장 | 배송요일 미설정, D-1/D-2 상품속성 | 현행 유지 ("내일 도착"/"모레 도착") | 내일 도착 |
| FC · 제때 정상 | 센터=제때, 교집합 성립 | 절대날짜 (배정일 그대로) | 07/07(화) 도착 |
| FC · 지방권 정상 | 센터=비제때, 리드타임 규칙 정의됨 | 절대날짜 (리드타임 반영) | 07/09(목) 도착 |
| FC · 규칙 미정의 | 센터 리드타임 규칙 없음 | 방어 표시 (내일 도착 금지) | 배송일 확인 중 |
| FC · 완전 불일치 | 교집합 0 (배송예정일 미성립) | 방어 표시 + 운영 알림 | 배송일 확인 필요 |
| FC · 부분 겹침 | 지정일 일부만 셀러 가능 | 겹치는 요일 기준 절대날짜 (밀림 반영) | 07/07(화) 도착 |
MM/DD(요일) 도착 형식.방어 문구 최종 카피("배송일 확인 중" vs "확인 필요" 등)는 UX 확정 필요 — 티켓1 논의사항.
현재 미사용. 켜기 전 반드시 확정해야 하는 규칙과 게이트. 티켓 3 산출물.
자동발주가 켜지면 상품 리드타임 기준으로 발주가 자동 생성되어, 현행 수동발주보다 훨씬 이른 시점에 발주가 나간다(Brown·Morty 확인). 매장·센터가 인지하지 못한 채 조기 발주 → 재고·정산 리스크.
| 항목 | 질문 | 기본 권고 |
|---|---|---|
| 리드타임 기준 | 발주 산정을 "상품 속성" vs "센터+매장 배송요일" 중 무엇으로? | 뱃지 로직과 동일 기준(센터+요일) 권장 — 표시·발주 정합 |
| 발주 시점 | 마감 몇 시간 전에 자동 발주가 생성되는가? | seller_weekly_deadline 실값 기준, 16시 상수 금지 |
| 현행 대비 차이 | 수동 대비 며칠 앞당겨지나? 매장별 편차는? | 파일럿 매장으로 실측 후 문서화 |
| 대상 범위 | 제때 전체 vs 파일럿 매장? | 파일럿 → 단계 확대 |
근거: Brown 코멘트(7/10 09:31), Morty 코멘트 — "자동발주 설정하실 거라면 운영에 바로 하기 전에 안내 부탁, 조정 필요".