K-Master Sales Data (DB) 테이블 명세 및 데이터 카탈로그
Update (2026-08-28) — David 인터뷰로 §3 KPI 규칙 확정 + State 컬럼 분리 반영
2026-08-27 최초 작성 시점에는 §3의 KPI 규칙이 “TAB과 동일 구조라는 가정하의 추정”이었으나, K-Master Dashboard(오늘의 현황·실적종합·연도별비교·순위) 구축을 위해 David와 2차례 인터뷰를 진행해 아래를 확정했다:
- State/Branch 분리: David가 KM_Database의 DB 테이블을 직접 수정하여 TAB과 동일하게
State와Branch를 별도 컬럼으로 분리했다(§1·§2에 반영, 과거 “State 컬럼 없음”은 더 이상 사실이 아님).- KPI 규칙은 TAB과 완전히 동일: “TAB 규칙과 동일하게 진행해줘” — 매출액은
Status ∈ {Credit, Invoiced, Confirmed}를Inv_Date기준 합산, 수주건수는Cancelled/Hold/공백 제외 전체(Restocked 포함)를Order_date기준 카운트.KM$/KM$_Exc는 TAB의TA$/TA$_Exc와 동일한 리베이트 개념으로 확정(“TA와 동일하게 KM를 리베이트로 계산”).- 2026-08-28 시점 총 23행이 진짜 완결된 데이터(신규 브랜드라 지금까지 23개 제품만 판매 완료 — WIP 아님, David 확인).
Stock/Today/Dealer/OrderItems/Orders/Quote/Quote Data탭은 “현재 개발 중”이라 대시보드 대상에서 제외(David 확인).- 이 확정 내용을 바탕으로 K-Master Dashboard가 실제로 만들어졌다 — §5 참고.
1. 배경 — TAB Sales Data와의 관계
K-Master는 Turbo Air 산하 신규 브랜드로, 판매 데이터를 **별도의 Google Sheet(KM_Database, KM Drive 공유 드라이브)**로 관리한다. David 확인: “KM_Database의 Sales Data 시트 DB 테이블은 TAB 구글시트와 형태·구성이 동일”. 실제로 컬럼을 대조하면 핵심 부분이 일치한다:
TAB Sales Data 컬럼 | K-Master DB 컬럼 | 동일 여부 |
|---|---|---|
| State | State | ✅ (2026-08-28 David가 직접 추가 — 최초 작성 시점엔 없었음, §“Update” 참고) |
| Branch | Branch | ✅ |
| Status | Status | ✅ (enum 재확인 필요) |
| Order date | Order_date | ✅ |
| Company | Company | ✅ |
| Salesman | Salesman | ✅ |
| Model | Model | ✅ |
| Inv Date | Inv_Date | ✅ |
| Inv No | Inv_No | ✅ |
| Delivery | Delivery | ✅ |
| TA$ Exc | KM$_Exc | ✅ (브랜드명만 치환) |
| RRP | RRP | ✅ |
| DC rate | DC_rate | ✅ |
| Sales | Sales | ✅ |
| Freight Cost | Freight_Cost | ✅ |
| Freight | Freight | ✅ |
| Extra | Extra | ✅ |
| TA$ | KM$ | ✅ (브랜드명만 치환) |
| Damaged | Damaged | ✅ |
| Clearance | Clearance | ✅ |
| (없음) | Order_No, P/O_No, Invalid_Check, Required_by, Order_Note, SN, Duplicate, Sales_Note, None_1/2, Photo_S/N, Photo_1~4, Consignment, ID, Inv_Check, No | K-Master 전용 추가 컬럼 |
결론: TAB 파이프라인(scripts/pull-sales-data.mjs의 COLUMN_MAP 패턴, functions/api/_google-sheets.js의 헤더-이름 기반 조회 방식)을 그대로 재사용할 수 있는 구조 — 실제로 scripts/pull-km-sales-data.mjs가 이 패턴 그대로 구현되었다(§“Update” 참고). State도 이제 TAB과 동일하게 분리되어 있어 구조적 차이는 사진/시리얼넘버 등 K-Master 전용 컬럼뿐이다.
2. 컬럼 명세 (DB 테이블, 총 38개 — State 컬럼 추가로 37→38)
No, State, Branch, Status, Order_date, Order_No, P/O_No, Company, Invalid_Check, Salesman, Required_by, Order_Note, Model, SN, Duplicate, Damaged, Clearance, Inv_Date, Inv_No, Delivery, RRP, KM$_Exc, DC_rate, Sales, Freight_Cost, Freight, Extra, KM$, Sales_Note, None_1, None_2, Photo_S/N, Photo_1, Photo_2, Photo_3, Photo_4, Consignment, ID, Inv_Check
| # | 컬럼명 | 추정 타입 | 샘플 값 | 설명(추정) |
|---|---|---|---|---|
| 1 | No | 정수 | 1, 2, 20 | 행 번호(시트 내 순번, 데이터 키 아님) |
| — | State | 텍스트(enum) | NSW | 2026-08-28 David가 TAB과 동일하게 추가한 컬럼 — 관측된 값은 전부 NSW(현재 데이터가 NSW뿐이라 VIC/QLD 값은 미관측) |
| 2 | Branch | 텍스트(enum) | NSW, VIC, QLD | 판매 지역/브랜치 — TAB의 Branch와 동일 개념 |
| 3 | Status | 텍스트(enum) | Invoiced, Credit, Restocked | 주문 상태 — 2026-08-28 기준 관측된 값은 Invoiced/Credit/Restocked뿐(Confirmed 미관측). KPI 규칙은 TAB과 동일하게 Credit/Invoiced/Confirmed를 매출 인식 상태로 취급하도록 확정(§3) — Confirmed가 실제로 나타나면 자동으로 매출에 포함됨 |
| 4 | Order_date | 날짜 | ”6 May 2026” | 주문 접수일(TAB과 다른 날짜 표기 형식 — D Mon YYYY, TAB은 YYYY-MM-DD) |
| 5 | Order_No | 텍스트 | E360294S | 주문번호(TAB의 Order No 대응, K-Master는 “S” 접미사 패턴 관측) |
| 6 | P/O_No | 텍스트 | ”6/5 Chef’s Buffet Sydney / K-master”, “PO-104272 / K-Master” | 구매주문번호 — 자유서식(딜러 PO 번호 + 메모가 혼합된 것으로 보임), 일부는 “S0-” 접두사(온라인 주문 추정) |
| 7 | Company | 텍스트 | Chef’s Buffet Sydney, Genuine Hospitality Solutions GHS | 거래처명 — TAB과 일부 거래처명 중복 관측(GHS 등, 동일 딜러가 TAB·K-Master 양쪽 취급 가능성) |
| 8 | Invalid_Check | 불리언 | FALSE, TRUE | 무효 처리 체크(TRUE 관측: “Walk in Customers” 행, Restocked 상태와 연관 추정) |
| 9 | Salesman | 텍스트 | None, Jacky | 담당 영업사원 — 다수 행이 “None”(미배정 또는 온라인 자동주문 추정) |
| 10 | Required_by | 날짜 | (대부분 공백) | 요청 납기일 |
| 11 | Order_Note | 텍스트(자유서식) | “시리얼 넘버 등록이 안되어 있어…”, “이미 출고 되었던 제품 수리 불가로 무상교체 진행” | 주문 관련 메모(한국어 운영 메모 다수) |
| 12 | Model | 텍스트 | HT65-3F-N, HS12-2R-N | 모델명(H-Series 코드 체계 — HS=Undercounter, HT=Upright) |
| 13 | SN | 텍스트 | H2H65F3K2002 | 시리얼번호 — SN 탭(입고 대장)과 연동되는 키로 추정 |
| 14 | Duplicate | 텍스트 | No | 중복 SN 여부(TAB의 Duplicate Check와 유사 개념 추정) |
| 15 | Damaged | 불리언 | FALSE | 손상 여부 |
| 16 | Clearance | 불리언 | FALSE | 클리어런스(재고 정리) 판매 여부 |
| 17 | Inv_Date | 날짜 | ”07/05/2026” | 인보이스(출고) 발행일 — DD/MM/YYYY 형식(Order_date와 표기 형식이 다름에 주의) |
| 18 | Inv_No | 텍스트 | E063729 | 인보이스 번호 — TAB의 Inv No와 같은 채번 계열로 보임(“E0639xx”대 “E0640xx” 등, TAB·K-Master가 인보이스 번호를 공유 채번하는 것으로 추정 — 확인 필요) |
| 19 | Delivery | 텍스트(enum) | EasyRoad, Pick-up, Border Express | 배송 방법 — TAB과 동일 값 체계 |
| 20 | RRP | 통화 | $4,518.00 | 권장소비자가(GST 제외 추정) |
| 21 | KM$_Exc | 불리언? | FALSE | TAB의 TA$ Exc와 동일 위치 — 체크박스형(불리언)으로 추정, 의미 미확인 |
| 22 | DC_rate | 백분율 | 0.000%, 25.000%, 100.000% | 할인율(딜러 계약상 30% off가 표준이나 개별 거래는 상이 — 0%부터 100%까지 관측) |
| 23 | Sales | 통화 | 4,518.00, 1,960.50 | 실제 판매금액 — RRP × (1 - DC_rate)와 대략 일치(예: 2,614 × 0.75 = 1,960.50 ✓) |
| 24 | Freight_Cost | 통화 | $0.00 | 배송 원가 |
| 25 | Freight | 통화 | 0.00, 370.00 | 배송비(청구) |
| 26 | Extra | 통화 | $0.00 | 추가 비용 |
| 27 | KM$ | 통화 | $0.00 | TAB의 TA$와 동일 위치 — 관계사간 정산액 등으로 추정(TAB 가이드의 TA QLD 개념과 유사할 가능성, 미확인) |
| 28 | Sales_Note | 텍스트 | ”EZroad/FIS(Free of Charge)“ | 매출 관련 메모 |
| 29-30 | None_1, None_2 | 미상 | (대부분 공백) | 용도 미상 — 원본 시트에 헤더명이 실제로 “None”으로 돼 있음(미사용 예비 컬럼으로 추정) |
| 31-35 | Photo_S/N, Photo_1~4 | 미상(URL/이미지 참조 추정) | (대부분 공백) | 사진 첨부 참조 — TAB에는 없는 K-Master 전용 컬럼(불량/클레임 사진 기록용으로 추정) |
| 36 | Consignment | 미상 | (대부분 공백) | 위탁판매 여부로 추정 |
| 37 | ID | 텍스트(UUID) | TA-8fca5e20-808e-4067-9964-0bc67303496b | 행 고유 식별자 — “TA-” 접두사 사용(K-Master 데이터인데도) → TAB과 백엔드 시스템(주문관리 시스템)을 공유할 가능성 시사, 미확인 |
| — | Inv_Check | 텍스트/기호 | ✓ | 인보이스 확인 완료 표시 |
3. KPI 계산 규칙 (David 확인 완료, 2026-08-28 — TAB과 완전 동일)
Sales Data 테이블 명세 및 KPI 정의 §“매출액”·“수주건수” 규칙을 그대로 적용하도록 David가 확정했다(“TAB 규칙과 동일하게 진행해줘”):
- 매출액:
Status ∈ {Credit, Invoiced, Confirmed}인 행을Inv_Date기준으로Sales합산. - 수주건수:
Cancelled/Hold/공백을 제외한 모든 행(Restocked 포함)을Order_date기준으로 카운트. - 리베이트:
KM$_Exc/KM$는 TAB의TA$ Exc/TA$와 동일한 개념(“TA와 동일하게 KM를 리베이트로 계산”) — 리베이트 차감 후 매출/리베이트 합계 KPI 카드에 그대로 사용. - 참고: 2026-08-28 시점 샘플에는
Confirmed상태가 관측되지 않았지만(Invoiced/Credit/Restocked만 존재), 규칙 자체는 TAB과 동일하게Confirmed도 화이트리스트에 포함해두었다 — 향후Confirmed행이 생기면 별도 코드 변경 없이 자동으로 매출에 반영된다. - 적용 범위: NSW/VIC/QLD 전체 포함, QLD는 TAB의 “TA QLD”와 같은 관계사(별도 소유·최대 고객사) 구조로 동일하게 처리(David 확인).
- 구현체:
scripts/pull-km-sales-data.mjs— TAB의pull-sales-data.mjs와 동일한 헤더-이름 기반COLUMN_MAP패턴으로 위 §1 표를 그대로 정규화.
4. 데이터 품질 관찰
Order_date(D Mon YYYY, 예 “6 May 2026”)와Inv_Date(DD/MM/YYYY, 예 “07/05/2026”)의 날짜 표기 형식이 서로 다름 — 대시보드 파싱 시 컬럼별로 별도 처리 필요(TAB pull 스크립트의DATE_COLUMNS정규화 로직 참고, 형식만 컬럼별로 조정).P/O_No필드가 자유서식이라 “PO번호”와 “메모”가 혼재 — 구조화된 PO 번호 추출이 필요하면 별도 파싱 규칙 필요.ID컬럼의TA-접두사,Inv_No의E063xxx~E064xxx채번대가 TAB의 Inv_No 채번대와 겹치는지 여부는 이번 스냅샷만으로 결론 낼 수 없음 — 별도 확인 시 두 브랜드의 재고/인보이스 시스템이 실제로 통합 운영되는지 알 수 있는 단서.- 2026-08-27 시점 데이터 볼륨이 작음(수십 건 규모) — 초기 브랜드 런칭 단계 데이터로, 향후 대시보드는 이 볼륨 성장을 함께 추적할 필요.
5. K-Master Dashboard 구축 결과 (2026-08-28, staging 배포 완료)
위 §1~4의 명세를 바탕으로 K-Master Dashboard가 실제로 구축되었다:
- 범위: 오늘의 현황·실적종합·연도별 비교·순위 4개 탭만 포함(TAB의 딜러별·리베이트 탭은 K-Master에 해당 데이터 구조가 없어 제외 — David 확인 “생략 권장”).
- 구현체:
quartz-site/scripts/pull-km-sales-data.mjs(데이터 파이프라인) +quartz-site/static-pages/KM_Dashboard.html(TAB_Dashboard.html을 원본으로 복제 후 K-Master 브랜딩/탭 구성으로 수정) →rebuild-site.ps1에서 매시간 자동 갱신. - 연도 범위: 2026년만 표시(실제 거래기록이 2026년만 존재 — David 확인).
- 재고/클리어런스 현황 섹션: 생략(TAB의 손상재고 수기 관리 테이블에 대응하는 K-Master 자료가 아직 없음).
- 접근 경로: Dashboard 목록 페이지(
/dashboard)에 카드 추가 완료 →/dashboard/k-master. - 배포 상태: 2026-08-28 David 리뷰 승인 후 production 배포 완료(
https://turboairbrain.uk/dashboard/k-master/) — staging 전용 게이트 제거. - 연도범위 디폴트: 실적종합·연도별비교 탭 모두 “오늘 날짜 기준 올해”(현재 2026년
2026년)로 디폴트 — TAB에서 물려받은 다년치(20242026) 디폴트를 그대로 뒀다면 연도별비교 차트에 데이터 없는 2024/2025 라인이 같이 그려지는 문제가 있어 David 요청으로 수정(리베이트/딜러 탭과 동일한 “오늘 날짜 기준” 동적 패턴 재사용, 하드코딩 아님). - 참고한 원본 파이프라인: Google Sheets 연동 실시간 대시보드 구축 가이드 (TAB Dashboard 사례) — TAB Dashboard의 서비스 계정 인증 → 자동 갱신 → Cloudflare 배포 패턴을 그대로 재사용.