← Home

Sales Data 테이블 명세 및 KPI 정의

AI·에이전트 필독 — 매출/영업 계산 전 이 문서를 최우선 참조

Turbo Air Australia의 매출·수주·영업 실적을 계산할 때는 반드시 이 문서의 컬럼 정의와 KPI 규칙을 그대로 따른다. 임의로 컬럼을 해석하거나 계산식을 바꾸지 않는다. 실제 조회 절차(라이브 커넥터/서비스 계정)는 영업판매실적 조회 절차를, 이 데이터가 무엇을 의미하는지는 이 문서를 본다.

원천: Google Sheets “Turbo Air” > Sales Data 시트 (파일 ID 1VOpjK9aDUuVmwkAouzGu-X_mZvGRlyhKbTDP1D6FU3Q). 2026-08-12 기준 16,857행 · 38컬럼. 컬럼 정의는 담당자(David) 인터뷰와 시트 실측 + 영업판매실적 조회 절차를 종합했으며, 아직 확정되지 않은 소수 항목은 아래 확인 필요 항목 (미확정)에 정리했다.


1. 테이블의 기본 구조

  • 1행 = 주문 1라인(line item). 주문이 들어오면 작성되며, 한 주문(Order No)에 여러 제품(모델) 라인이 달릴 수 있다(평균 약 2.1행/주문).
  • 두 개의 날짜 기준을 절대 혼동하지 않는다.
    • Order date = 주문 접수일 → 수주(주문) 관련 KPI의 날짜 기준.
    • Inv Date = 제품 출고(인보이스 발행)일 → 매출 관련 KPI의 날짜 기준.
  • 통화는 모두 AUD. 금액을 표기할 때는 숫자 앞에 $를 붙인다(예: $12,345). 건수·연도·퍼센트·모델번호는 $를 붙이지 않는다.

2. 주문 상태(Status) 생애주기

Status는 해당 주문의 현재 시점 상태다. 이상적으로 모든 주문은 Confirmed로 마무리된다.

flowchart LR
	O["Ordered 수주"] --> P["Picking 출고준비"]
	P --> R["Released 출고완료"]
	R --> I["Invoiced 인보이스+입금완료"]
	R --> C["Credit 인보이스+입금전"]
	I --> CF["Confirmed 최종확정"]
	C --> CF
	O -.->|"주문 취소"| X["Cancelled 계산제외"]
	O -.->|"재고 선점"| H["Hold 계산제외"]
	R -.->|"반품 재입고"| RS["Restocked 매출제외/수주포함"]
Status의미인보이스 발행?매출액 포함?수주건수 포함?
Ordered주문을 수주한 상태아니오✗✓
Picking웨어하우스에서 출고 준비 중(아직 미출고)아니오✗✓
Released웨어하우스에서 출고됨. 인보이스 발행됐거나 작성 중(Invoiced 직전 단계)진행 중일 수 있음✗✓
Credit출고+텍스인보이스 발행 완료, 대금 미처리(Credit 계좌 딜러는 선배송 가능)예✓✓
Invoiced대금 처리 완료 + 출고 + 텍스인보이스 발행 완료예✓✓
ConfirmedInvoiced 이후 매니저가 최종 확인한 최종 마무리 상태(모든 주문의 이상적 종착점)예✓✓
Restocked제품/딜러 문제로 출고됐다가 웨어하우스로 재입고된 건(되돌림)✗✓
Hold딜러·영업사원이 근미래에 쓸 재고를 미리 확보해 둔 상태아니오✗✗
Cancelled주문이 취소된 상태아니오✗✗

상태별 취급의 핵심 3가지

  1. 매출액은 오직 Credit·Invoiced·Confirmed (=텍스인보이스가 발행된 상태)만 포함한다.
  2. Cancelled·Hold는 수주건수를 포함한 어떤 계산에도 넣지 않는다.
  3. Restocked는 매출액에서는 제외, 수주건수에는 포함한다 — 한때 접수·출고된 실제 주문이기 때문. (매출·수주에서 Restocked 취급이 반대이므로 특히 주의.)

3. 컬럼 명세 (데이터 사전)

채움률은 2026-08-12 실측.

3.1 식별·상태

컬럼채움설명계산 사용
No.100%함수 기반 자동 넘버링. 수시로 바뀜 — 라인 확인용일 뿐❌ 사용 금지
ID100%재정렬돼도 바뀌지 않는 안정적 고유 행 ID행 식별용(계산 아님)
State100%주문 처리 주. NSW 또는 VIC만 사용(QLD는 세팅상 선택 가능하나 미사용)지역 분해
Status100%주문 현재 상태(위 §2의 9종)✅ 핵심 필터
Check94%Inv No 입력 여부(=인보이스 발행 여부) 확인용 ✓. 사용 편의 컬럼❌ 계산 영향 없음
Invalid Check100%참고용 True/False 플래그❌ 계산 영향 없음(포함)
Duplicate Check82%시리얼번호(SN) 중복 여부 확인 컬럼. 재입고 재출고·TA QLD 재매입 등으로 SN이 중복될 수 있으나 실제 별개 주문임❌ 제외하지 않음

3.2 날짜

컬럼채움설명계산 사용
Order date100%주문 접수일✅ 수주 KPI 날짜 기준
Inv Date94%제품 출고(인보이스 발행)일✅ 매출 KPI 날짜 기준
Required by78%고객 납기 희망일납기 분석

3.3 거래처·주문 식별

컬럼채움설명계산 사용
Order No100%주문번호. 주문관리 프로그램 Dear System에서 PI 발행 시 TA-SO#E360859S 형식으로 생성되며 뒷부분(E360859S)만 사용. 1행=1제품이라 한 주문에 여러 제품이 있으면 번호가 중복된다(고유 7,971)주문 단위 집계 키
P/O No99%딜러/거래처의 발주번호(Purchase Order)참조용
Company100%거래처(딜러·고객)명(고유 332). TA QLD 식별에 사용 — 확정 규칙: Company에 “Turbo Air Queensland” 또는 “TA QLD” 포함 시 TA QLD(추정 아님)딜러 분해
Salesman3%고객사(딜러) HWD의 영업사원별 매출을 구분하기 위한 컬럼(HWD가 자사 영업사원 실적에 따라 베네핏을 지급해 구분 필요). 우리 영업사원이 아님(대부분 공란, HWD 건에만 입력)HWD 영업사원별 분해

3.4 제품

컬럼채움설명계산 사용
Model100%제품 모델번호(고유 340)제품 분해
SN94%제품 시리얼번호(단위 고유)개별 추적
Damaged42%결함(파손 등)이 있는 제품이 출고된 경우 체크. 보통 추가 할인을 적용해 판매(True/False)품질·할인 분석
Clearance43%오래된 재고 등을 추가 할인으로 판매하는 경우 체크(True/False)재고정리·할인 분석

3.5 금액·리베이트

컬럼채움설명계산 사용
Sales93%실제 판매금액(라인별, AUD)✅ 매출액 합산 대상
RRP89%권장소비자가(Recommended Retail Price). 리베이트 산정 기준액가격/리베이트 기준
DC rate89%할인율(RRP 대비, 0~1 소수)할인 분석
TA$19%리베이트로 적립되는 Turbo Air Credit(TA$) 금액 — 연간 판매수량 구간에 따라 총 RRP의 4~13%. 다음 해 주문 시 크레딧으로 사용(단일 인보이스의 10% 한도)리베이트
TA$ Exc60%체크(True) 시 해당 주문은 리베이트의 수량 tier 판정(판매대수)에는 포함되나 판매금액(RRP)은 리베이트 산정에서 제외된다. 보통 추후 받을 리베이트만큼을 딜러에게 미리 할인으로 제공한 경우 체크리베이트 금액 제외 판정
Freight Cost9%우리 부담 운송원가원가 분석
Freight27%고객에게 청구한 운송비부대수익
Extra21%고객 요청으로 추가부품·팔렛제거 등을 제공하고 고객에게 청구해 받은 금액부대수익
Tax1%GST 세액(대부분 공란 — 별도 산정 추정)세무(결측 많음)

3.6 물류·첨부·기타

컬럼채움설명계산 사용
Delivery94%배송 방법/운송사(Northline·Pick-up·TNT 등 22종)물류 분석
Order Note / Sales Note47% / 2%자유 메모(연락처·배송지·특이사항)참조용
Photo S/N, Photo #1~#5≤13%제품/시리얼 증빙 사진 링크(첨부)증빙
KK boucher0%미사용 컬럼(값 거의 없음, 폐기 가능)❌ 사용 안 함

4. KPI 정의

읽는 법

각 KPI는 ① 정의(무엇을 재나) · ② 포함/제외 조건 · ③ 날짜 기준 · ④ 집계식 · ⑤ 해석으로 구성된다. “포함 조건”에 없는 상태·행은 모두 제외한다.

4.1 핵심 KPI

매출액 (Sales Revenue)

항목내용
정의실제로 출고되어 텍스인보이스가 발행된 확정 매출의 총합
포함Inv No가 발행됨 그리고 Status ∈ {Credit, Invoiced, Confirmed}
제외그 외 모든 상태(Ordered·Picking·Released·Hold·Cancelled·Restocked·공백) 및 Inv No 미발행 행
날짜 기준Inv Date (해당 월/연에 귀속)
집계식Σ Sales
해석회사가 실제로 인식하는 매출. 경영 판단·보고의 기본 숫자. Credit(반품·크레딧노트)은 Sales가 음수라 합산하면 자연스럽게 순매출(net)이 된다.

수주건수 (Order Count / Bookings)

항목내용
정의접수된 주문의 라인(품목) 수 — 수요 유입의 선행지표
포함Status가 Cancelled/Hold/공백이 아닌 모든 행 (Restocked 포함)
제외Cancelled, Hold, 공백 상태
날짜 기준Order date
집계식행(라인) 수 카운트 (고유 Order No가 아니라 행 수)
해석”주문이 얼마나 들어왔나”. 아직 인보이스되지 않은 주문(Ordered/Picking/Released)도 포함하므로 매출보다 앞선 신호다. 매출건수(Inv Date, 인보이스 완료)와 시점·기준이 달라 한 표에 섞지 않는다.

매출액 vs 수주건수 — 절대 혼동 금지

  • 날짜: 매출액=Inv Date / 수주건수=Order date
  • Restocked: 매출액=제외 / 수주건수=포함
  • 상태 필터: 매출액=화이트리스트(Credit/Invoiced/Confirmed) / 수주건수=블랙리스트(Cancelled/Hold/공백 제외)

4.2 단가·규모 KPI

평균 판매단가 (Average Selling Price, ASP)

  • 정의/집계: 매출액 ÷ 매출 인식 라인 수(매출액과 동일 조건·Inv Date).
  • 해석: 품목(라인)당 평균 판매금액. 가격 인상·제품 믹스 변화를 감지한다. (예: 2026-02-01 가격 인상 시 ASP 상승.)

평균 주문규모 (Average Order Value, AOV)

  • 정의/집계: 매출액 ÷ 고유 Inv No 수(또는 고유 Order No).
  • 해석: 주문 1건당 평균 매출. 상승하면 소수 대형 딜 의존(집중 리스크) 신호일 수 있다.

4.3 파이프라인·전환 KPI

수주금액 (Order Intake Value) — 참고 지표 (한계 있음)

  • 포함/날짜: 수주건수와 동일 조건, Order date 기준. 집계: Σ Sales.
  • ⚠️ 중요한 한계: Sales는 인보이스 발행 후에만 입력된다(미인보이스 주문 Ordered/Picking/Released는 공란). 따라서 Order date 기준 ΣSales는 “이미 인보이스된 주문”만 잡혀, 아직 대기 중인 최근 주문을 과소집계한다 → 진정한 “주문 유입액”이 아니다. 수요 선행지표로는 금액이 아니라 수주건수(건수)를 사용하고, 굳이 금액이 필요하면 RRP×(1−DC rate) 추정을 쓰되 한계를 명시한다.

미인보이스 백로그 (Uninvoiced Backlog / Open Orders)

  • 포함: Status ∈ {Ordered, Picking, Released} 이면서 Inv No 미발행(=아직 매출 미인식).
  • 집계: 행 수(및 참고로 Σ Sales가 있으면).
  • 해석: 아직 매출로 잡히지 않은 대기 주문 = 향후 매출 파이프라인.

확정 완료율 (Confirmation Rate) — 프로세스 품질

  • 집계: Confirmed 행 ÷ (Credit+Invoiced+Confirmed) 행, Inv Date 기준.
  • 해석: 최종 확정 단계까지 마무리된 비율. 이상적으로 100%에 가까워야 한다(낮으면 매니저 확정 지연).

4.4 리스크·품질 KPI

취소율 (Cancellation Rate)

  • 집계: Cancelled 행 ÷ 전체 주문 행(공백 제외), Order date 기준.
  • 해석: 주문 취소 빈도. 급등 시 딜러·재고·가격 이슈 점검.

재입고율 (Restock / Return Rate)

  • 집계: Restocked 행 ÷ 출고 이상 행(Released·Credit·Invoiced·Confirmed·Restocked), 기간.
  • 해석: 출고 후 반품/재입고 빈도. 제품 품질·딜러 문제의 신호.

4.5 분해(Breakdown) KPI

지역별 매출 (Revenue by State)

  • 매출액을 State(NSW/VIC)로 분해.

딜러별 매출 (Revenue by Dealer) + TA QLD 포함/제외

  • 매출액을 Company로 분해. 사이트 /ask 라이브 블록은 연도별 딜러 Top 5(TA QLD 제외)를 [표5]로 자동 산출한다.
  • TA QLD(확정 식별: Company에 “Turbo Air Queensland” 또는 “TA QLD” 포함)는 딜러가 아니라 QLD 관계사(별도 오너십, 컨테이너 대량 구매). 매출이 해상운송 도착 시점에 출렁이므로, 경영 판단은 항상 TA QLD 제외(exQLD) 기준으로 보고 포함/제외 두 버전을 함께 산출한다. 딜러 순위에서는 TA QLD를 제외하되 별도 라인으로 병기한다. (근거: 2026-07_회사소개서, 영업판매실적 조회 절차)

제품별 매출 (Revenue by Model)

  • 매출액을 Model로 분해. Top 제품·부진 제품 파악.

평균 할인율 (Average Discount Rate)

  • mean(DC rate) — 가급적 RRP 가중 평균 권장.

리베이트 (Rebate, TA$)

Turbo Air가 딜러에게 제공하는 연간 판매수량 기반 리베이트(적립: TA$ = Turbo Air Credit) 프로그램.

적립 구조 — 연간 판매수량 구간에 따라 총 RRP의 다음 비율을 적립:

연간 판매수량리베이트율
1–20 대0%
21–50 대4%
51–100 대7%
101–150 대10%
151+ 대13%
  • 적립액: 해당 구간율 × 리베이트 대상 RRP 합계. 단, TA$ Exc = True인 주문은 수량 tier 판정에는 포함되나 그 RRP는 리베이트 금액 계산에서 제외한다(미리 할인 제공분).
  • 사용: 적립된 TA$는 다음 해 주문의 크레딧으로 사용. 단일 인보이스 금액의 10%를 초과해 사용할 수 없다.
  • 집계: 실제 기록된 리베이트는 Σ TA$. (딜러별 스킴 배정 등 Power BI 모델 관점은 영업판매실적 조회 절차 “리베이트 스킴 구조”도 참고. 이 배정·지급·잔여 현황이 실제로 어디에 원장으로 기록되는지는 아래 §6을 본다, 2026-08-21 확인.)

5. 계산 시 반드시 지킬 규칙 (요약 체크리스트)

매출/영업 계산 전 확인

  • 매출액인가? → Inv No 발행 + Status ∈ {Credit, Invoiced, Confirmed} + Inv Date 기준 + ΣSales
  • 수주건수인가? → Cancelled/Hold/공백 제외(Restocked 포함) + Order date 기준 + 행 수
  • Restocked를 매출과 수주에서 반대로 취급했는가?
  • No.를 계산에 쓰지 않았는가?(자동 넘버링) — 식별이 필요하면 ID 사용
  • 부분 연도를 전체 연도와 비교하지 않았는가?(완전월 like-for-like)
  • TA QLD를 제외(exQLD)한 버전으로 판단했는가?
  • 매출 추세를 해석할 때 **가격(RRP) 변화와 물량(수주)**을 함께 봤는가?(가격 인상이 물량 둔화를 가릴 수 있음)
  • 금액에 $를 붙였는가?(건수·%·연도·톤 제외)
  • 전체 행을 읽었는가? 라이브 조회 시 행 범위 상한 금지(예: A1:AA25000 금지) — open-ended Sales Data!A:AZ(행 무제한)를 쓴다.
  • 날짜를 로케일 모호성 없이 파싱했는가? 시트의 Inv Date/Order date는 호주식 DD/MM/YYYY로 표시된다. 문자열 그대로 new Date("25/07/2026") 하면 Invalid 라 해당 매출행이 통째로 스킵된다(day>12 대부분 탈락 → 실제의 ~1/3만 집계). 반드시 Google Sheets API를 valueRenderOption=UNFORMATTED_VALUE&dateTimeRenderOption=SERIAL_NUMBER로 호출해 시리얼 숫자로 받아 결정론적으로 변환한다.
  • 이전 답변 숫자를 재사용하지 않았는가? 과거 /ask Q&A(위키 컨텍스트에 남을 수 있음)의 매출/수주 수치는 스냅샷이다. 항상 이번 라이브 데이터로 재계산한다(그래서 site-ask Q&A는 KV 컨텍스트 번들에서 제외한다).

(2026-08-14: 위 세 원인 — ① new Date DD/MM 파싱 실패로 매출행 스킵 ② 이전 오답 Q&A가 번들에 실려 LLM이 그 숫자를 복사 — 이 겹쳐 2026년 1~7월 매출이 5.40M 대신 1.24M로 반복 오집계된 사고가 있었음. A1:AA25000 행상한도 함께 제거.)


6. TADollar 2026 시트 — TA$ 리베이트 배정·지급 원장 (Ledger)

§4.5와의 관계

§4.5(리베이트 적립 구조, 35%/41% 스킴)가 어떻게 계산되는가의 규칙이라면, 이 섹션은 그 계산 결과가 실제로 어디에 기록·추적되는가를 다룬다. David 확인(2026-08-21): 같은 프로그램이다 — 딜러의 전년도 순 판매건수 구간에 따라 35%/41% 스킴 중 하나가 적용되고, 그 지급율 × 리베이트 대상 RRP 합계가 이 시트의 Final TA$로 기록된다. 단, 어느 딜러가 35%/41% 중 어느 스킴인지는 이 시트를 포함해 어디에도 명시되어 있지 않다 — §4.5의 동일 Open Question이 여기서도 그대로 남아 있다.

원천: 같은 스프레드시트(1VOpjK9aDUuVmwkAouzGu-X_mZvGRlyhKbTDP1D6FU3Q)의 “TADollar 2026” 탭(gid 2044971754). NSW/VIC 딜러 전용 — TA QLD는 딜러가 아니라 별도 오너십 관계사라 이 프로그램 대상이 아니다(David 확인, 2026-08-21).

탭 안에 표 2개, 고정 행 번호 없음

“TADollar 2026” 탭 하나에 위아래로 서로 다른 두 표가 있고, 행이 늘어나며 시작 위치가 계속 밀린다 — 헤더 텍스트(“Company”+“Final TA$” 조합, “Order No”)로 표 시작을 찾아야 한다(고정 행 번호로 자르면 표가 자랄 때 깨진다). 2026-08-21 스냅샷: 거래처 요약 23행, 오더 상세 199행.

6.1 표1 — 거래처별 TA$ 요약

컬럼설명계산 사용
No순번사용 안 함
State딜러 소재(NSW/VIC만)지역 분해
Company딜러명. 주의: §6.2 Customer와 대소문자가 다를 수 있다(예: “Cafe ideas” vs “Cafe Ideas”) — 조인 시 대소문자 무시 필수조인 키
Final TA$이 딜러에게 확정 배정된 연간 TA$ 리베이트 총액 (35%/41% 스킴 계산 결과로 추정)배정액
Paid지급 완료 + 지급 예정(진행 중 오더 포함) TA$ 누계. 검증됨(§6.3)소진액
Remains잔여 TA = `Final TA−Paid`잔여 리베이트 질문의 근거
Note자유 메모(예: “QCC는 TA$ Credit note로 전액 발행”) — 23개 중 1개만 채움참조용

6.2 표2 — 오더별 TA$ 상세

컬럼설명계산 사용
No순번사용 안 함
Order NoSales Data의 Order No와 동일 값으로 추정(직접 대조 검증은 아직 안 함)조인(추정)
Order date주문일. 시트 시리얼 넘버로 저장됨 — Sales Data와 동일하게 SERIAL_NUMBER 변환 필요(영업판매실적 조회 절차 체크리스트 참고)기간 필터
Customer딜러명(§6.1 Company와 대소문자 다를 수 있음)조인 키
LocationNSW/VIC (Sales Data의 State에 대응하는 것으로 추정)지역 분해
StatusConfirmed/Cancelled/Credit/Ordered/Invoiced 5종 관측(2026-08-21). Sales Data §2의 9종 상태와 이름은 겹치나 1:1 대응 여부는 미검증필터
PI TADPI(Proforma Invoice)에 최초 기록된 TAD 금액. Cancelled여도 원래 값 유지원본 청구액
Confirmed TAD실제 지급되거나 지급 예정인 TAD. Cancelled면 0, 그 외(Ordered 포함, 인보이스 전이라도)는 PI TAD와 동일Paid 집계의 원천
Amount그 오더의 실제 제품 매출액(Sales Data의 Sales에 대응하는 것으로 추정)Rate의 분모
RateConfirmed TAD ÷ Amount. 표본 대부분 약 10% — David 확인(2026-08-21): 10%가 표준, 벗어나는 값은 확인 필요(예: 2026-08-21 스냅샷의 Cafe Ideas 오더 E360881S는 14.27%로 표준을 벗어남 — 회계 확인 대상으로 플래그)검증 지표
Remains⚠️ 오더별 잔액이 아니다 — 그 오더가 속한 딜러의 §6.1 Remains를 그대로 복사해온 값(같은 딜러의 모든 오더 행에서 동일 숫자 반복). 합산·평균 등 집계에 쓰면 안 된다참조용(집계 금지)

6.3 계산 검증 (2026-08-21 실측 대조)

  • Paid(표1) = Σ Confirmed TAD(표2, 해당 딜러 전체 오더) — Cafe ideas로 검증: 13개 오더 Confirmed TAD 합계 5,125.80 = 표1의 `Paid` 5,125.80(일치).
  • Final TA$ − Paid = Remains — 23개 딜러 전원 항등식 일치(전수 확인).
  • 2026-08-21 스냅샷 합계: 딜러 23곳, 오더 199건, Final TA$ 합계 144,499 / `Paid` 합계 ≈98,309 / Remains 합계 ≈$46,190.

6.4 /ask 봇 연동

functions/api/_google-sheets.js의 isRebateQuestion()이 “리베이트”/“TA$”/“TAD”/“잔여” 등 키워드를 감지하면 fetchTadRows() → parseTadData() → formatTadDataForPrompt()가 이 두 표를 실시간 조회해 /ask의 시스템 프롬프트에 “LIVE TAD DATA”로 주입한다(Cloudflare Pages Function + Claude API로 Wiki 기반 Q&A 봇 만들기 참고). Sales Data 조회(isSalesQuestion)와는 독립적으로 게이팅되므로, “리베이트” 같은 sales 키워드가 없는 순수 TAD 질문도 놓치지 않는다.

Open Question — 담당자 검토 요청

  • 어느 딜러가 35%/41% 스킴 중 어디에 속하는지 여전히 시트·모델 어디에도 명시되어 있지 않다(§4.5·영업판매실적 조회 절차와 동일한 미해결 질문).
  • §6.2 Order No/Customer/Location이 Sales Data의 Order No/Company/State와 정말 동일 값을 참조하는지 직접 대조 검증은 아직 안 됨(구조상 매우 유력하나 미검증).
  • §6.2 Status 5종이 §2의 9종 상태와 1:1 대응하는지 불명.
  • Rate가 표준 10%를 벗어나는 오더(예: Cafe Ideas E360881S 14.27%)의 원인 — 담당자 확인 필요.
  • 같은 스프레드시트의 “TA 2025"(전년도 완료분으로 추정)·"TAD Edit"(편집용 사본으로 추정) 탭은 아직 조회·검증하지 않음 — `Final TA`가 실제로 전년도 어느 수치에서 산출됐는지 추적하려면 필요할 수 있다.

Bias Check

Counter-argument: Paid=ΣConfirmed TAD 검증은 딜러 1곳(Cafe ideas)만 행 단위로 수동 대조했다 — 23곳 전수의 행 단위 검증은 아니다(다만 Final TA$−Paid=Remains 항등식은 23곳 전수 확인됐고, 이는 Paid가 시트 내부적으로 일관되게 산출됨을 뒷받침한다). Data gap: Final TA$가 정확히 전년도 어떤 순 판매건수 값에서 산출됐는지(원본 스킴 계산 근거)는 아직 조회하지 않았다(“TA$ 2025”/“TAD Edit” 탭에 있을 것으로 추정).


7. 확인 필요 항목 (미확정)

Open Question — 담당자 검토 요청

핵심 컬럼(Status·날짜·매출/수주 관련·TA$·플래그)은 David 인터뷰로 확정됐다. 아래 소수 항목만 아직 미확정이다(이 문서 검토 후 수정 예정).

  • Tax가 대부분 공란인 이유(GST를 별도 시스템에서 산정하는지).
  • Required by·Delivery·Freight·Freight Cost의 세부 업무 정의(현재 추정과 대체로 일치할 것으로 보이나 미확정).
  • ID가 어느 시스템에서 부여되는 고유키인지(현재 “안정적 고유 행 ID”로 추정).

Bias Check

Counter-argument: KPI 정의(특히 매출액 화이트리스트·수주건수 제외목록)는 David 인터뷰로 확정됐으나, 이는 현재 입력 관행을 전제한다 — 담당자가 상태값을 일관되게 입력하지 않으면(예: Confirmed로 넘기지 않고 Invoiced에 방치) 정의가 맞아도 수치가 왜곡될 수 있다. Data gap: 컬럼 채움률은 2026-08-12 단일 스냅샷 기준이며, TA$ Exc·Tax·Freight 등 저채움 컬럼의 입력 규칙 일관성은 검증되지 않았다. 정의서의 KPI가 Power BI 시맨틱 모델(05_SalesReport)과 완전히 일치하는지도 필드 단위 대조가 남아 있다.


Sources

  • Google Sheets “Turbo Air” > Sales Data 탭 (라이브 실측, 2026-08-12: 16,857행·38컬럼)
  • Google Sheets “Turbo Air” > TADollar 2026 탭 (라이브 실측, 2026-08-21: 거래처 23행·오더 199행)
  • David 인터뷰(2026-08-12~13): Status 9종 정의, Invalid Check·Duplicate Check·Check 플래그 취급, 날짜 기준, Order No(Dear System) / Salesman(HWD 영업사원) / Damaged / Clearance / Extra 정의, TA$/TA$ Exc 리베이트 구조, Sales 입력 시점(인보이스 후), KK boucher 미사용
  • David 확인(2026-08-21): TADollar 2026 시트가 §4.5 리베이트(35%/41% 스킴)와 같은 프로그램임, Rate 표준값(10%), TAD 프로그램이 NSW/VIC 딜러 전용(QLD 제외)임
  • 05_SalesReport 볼트 Data Catalog(Power BI 시맨틱 모델 역공학)