질문: 앞으로는 구글시트에 거래내역을 중복으로 기재하지 않고, Dear System API에서 데이터를 받아서 활용할 생각이야. 이럴 때 생길 수 있는 문제점이나 데이터 누락이 발생할 수 있는지 점검해줘. 질문자: David 일시: 2026-09-23
Answer
결론
전환은 가능하지만, 지금 상태로 수기 입력을 끊으면 안 된다. 두 시스템을 필드 단위로 실측 대조한 결과 영구히 사라지는 데이터 4종과 핵심 수치가 달라지는 지점 3곳이 확인됐다. 특히 Status 체계가 1:1로 매핑되지 않아 현재 대시보드·주간동향·/ask 봇의 모든 KPI 정의를 다시 세워야 한다. 반대로 Branch는 완전히 파생 가능하고 이력은 오히려 2년 더 깊다.
점검 방법
구글시트 Sales Data(42컬럼·17,267행, 2021-01-04~)와 Cin7 Core API를 필드 단위로 실제 대조했다. 추정이 아니라 양쪽 데이터를 직접 읽어 채움률·고유값·건수를 집계한 결과다.
1. 영구히 사라지는 데이터 — Cin7에 대응물이 없음
시트 항목
채움률
상태
Order Note
47.6% (8,211행)
Cin7 Note 필드는 표본 12건 전부 공란. “BX without tailgate/FIS(무상), ETA:10월 중순” 같은 운영 메모가 통째로 소실
Freight Cost (운임 원가)
9.1% (1,572행)
Cin7엔 운임 수익(계정 260 Freight & Handling)만 있고 원가 필드 자체가 없음 → 운임 마진 산출 불가
Damaged / Clearance
0.1% / 0.5%
대응 필드 없음. 다만 희소하고 재고 탭은 Stock 시트의 ND/VD를 쓰므로 실제 영향은 제한적
1:1 매핑이 불가능하다. 현재 모든 KPI가 시트 어휘 위에 정의돼 있다 — 매출액 = Status ∈ {Credit, Invoiced, Confirmed}, 수주건수 = {Cancelled, Hold, 공백} 제외, Restocked는 매출 제외·수주 포함(Sales Data 테이블 명세 및 KPI 정의).
이 규칙 위에 TAB 대시보드 전체 · 주간 동향 보고서 · /ask 봇이 모두 얹혀 있다. 소스를 바꾸면 세 곳 전부 재검증해야 한다.
② 그냥 세면 건수가 부풀려진다
2026년 동일 기준 비교:
기준
건수
시트 — 인보이스 발행 라인
2,284
Cin7 — 제품 라인(계정 200)
2,778 (+21.6%)
Cin7 — 전체 라인(운임 260 1,476건 포함)
4,254 (+86%)
Cin7은 운임을 별도 라인으로 기록한다(시트는 제품 라인의 컬럼). 필터 없이 라인을 세면 출고건수·수주건수가 즉시 왜곡된다.
③ 범위 경계가 무너진다
초과 494건의 정체: Walk-in 카운터 판매·부품 판매 — 시트가 의도적으로 제외하던 것. 현재는 TAB Sales Data(완제품)와 TA Service Parts Sales(부품)가 깔끔히 분리돼 있으나, Cin7은 한 원장에 담는다(Products 탭도 49%가 Spare parts).
K-Master가 섞인다: Cin7 판매원장 2026년 매출라인 중 K-master SKU 21건 / $50,132 확인. 현재 K-Master는 별도 원장(KM_Database)이며 CLAUDE.md의 브랜드 disambiguation 규칙상 합산 금지 대상이다.
3. 오히려 좋아지는 것
항목
내용
Branch 파생
완전히 가능. Branch=QLD ↔ 거래처 Turbo Air Queensland TA QLD 5,225건 정확히 1:1(양방향 예외 0건), Branch=NSW/VIC ↔ State불일치 0건(12,042행)
이력 깊이
Cin7 2019-06-17~ vs 시트 2021-01-04~ → 2년 더 깊다
대응되는 필드
P/O No ↔ CustomerReference, Delivery ↔ Carrier, 배송지 ↔ ShippingAddress
새로 생기는 것
첨부파일(프로포마 인보이스 PDF, 표본 12/12), 회계정보(GL 계정·GST·COGS·입금계좌) — 시트엔 아예 없던 데이터
4. 운영 리스크
재구축에 3.5시간 — 라인 상세는 주문당 1회 호출(60 calls/min 제한). 스키마를 바꾸거나 캐시가 깨지면 재백필 비용이 크다.
단일 장애점 — API 키 만료·Cin7 장애·API 애드온 구독 종료 시 전면 중단. 지금은 사람이 유지하는 시트라 언제든 읽을 수 있다.
되돌릴 수 없다 — 수기 입력을 멈춘 순간부터 그 기간의 시트 데이터는 영구 공백이다. 나중에 “역시 시트가 필요하다”가 되어도 소급 복원이 불가능하다.
시리얼번호 커버리지 미확인 — 시트 SN 94.3% vs Cin7 BatchSN 표본 7/12. 재고품만 추적되는 구조일 수 있어 확인 필요.
5. 권고 — 4단계 전환
단계
할 일
산출물
0. 지금
병행 유지. 이미 구축된 cin7-reconcile-sales.mjs로 불일치 일일 모니터링
일별 불일치 리포트
1.
Status 매핑표 확정 + KPI 재정의 — “Cin7 기준으로 계산하면 매출/수주가 몇 % 달라지는가”를 숫자로 제시하고 승인받기
매핑표 + 차이 검증 리포트
2.
사라지는 항목 대책 — Order Note를 Cin7 Note 필드에 입력하도록 업무 절차 변경, Freight Cost 별도 관리 방안 확정
업무 절차 변경
3.
대시보드 소스 전환, 시트는 읽기전용 아카이브로 동결
전환 완료
1단계가 선행 조건이다
Status 매핑이 정해지지 않으면 “Cin7로 바꾸면 매출 숫자가 어떻게 달라지는지”를 말할 수 없다. 그 상태로 전환하면 경영 보고 수치가 소리 없이 바뀐다 — 가장 피해야 할 시나리오다.
LIVE 대조: 구글시트 Sales Data 42컬럼 17,267행 + Cin7 saleList/sale?ID=/product 실시간 조회(2026-09-23)
Referenced Pages
(답변 본문의 “참고 문서” 섹션 참고)
Gaps Identified
Knowledge Gap
(1) Status 매핑은 아직 없다 — 이 문서는 “매핑이 불가능하다”가 아니라 “자동으로는 안 되니 사람이 정의해야 한다”를 말한다. 실제 매핑표는 1단계 산출물이다. (2) 시리얼번호 커버리지는 표본 12건 기준이라 전수 확인이 필요하다. (3) Order Note 소실 판정도 표본 12건에서 Cin7 Note가 전부 비어 있던 것에 근거하므로, 일부 주문엔 값이 있을 수 있다. (4) 초과 494 라인의 성격(Walk-in·부품)은 2026-08 표본에서 확인한 패턴을 근거로 한 추정이며 전수 분류는 하지 않았다.
ℹ️ 提问问题:앞으로는 구글시트에 거래내역을 중복으로 기재하지 않고, Dear System API에서 데이터를 받아서 활용할 생각이야. 이럴 때 생길 수 있는 문제점이나 데이터 누락이 발생할 수 있는지 점검해줘.
提问者: David时间:2026-09-23
ℹ️ QueryQuestion: 앞으로는 구글시트에 거래내역을 중복으로 기재하지 않고, Dear System API에서 데이터를 받아서 활용할 생각이야. 이럴 때 생길 수 있는 문제점이나 데이터 누락이 발생할 수 있는지 점검해줘.
Asked by: DavidDate: 2026-09-23
Answer
💡 Bottom lineThe migration is feasible, but the hand-keying must not be switched off in the current state. A field-by-field comparison of both systems found 4 kinds of data that would be lost permanently and 3 places where headline numbers would change. Most importantly, the Status vocabularies do not map 1:1, so every KPI definition behind the dashboard, the weekly digest and the /ask bot would have to be rebuilt. On the positive side, Branch is fully derivable and the history actually goes back two years further.
How this was checked
The Google Sheet Sales Data (42 columns, 17,267 rows, from 2021-01-04) was compared field by field against the Cin7 Core API. These are not estimates — both datasets were read directly and fill rates, distinct values and counts were measured.
1. Data that would be lost permanently — no Cin7 equivalent
Sheet field
Fill rate
Status
Order Note
47.6% (8,211 rows)
Cin7's Note field was empty in all 12 sampled orders. Operational notes like "BX without tailgate/FIS(Free of Charge), ETA: mid Oct" disappear entirely
Freight Cost
9.1% (1,572 rows)
Cin7 has freight revenue (account 260 Freight & Handling) but no cost field at all → freight margin becomes uncomputable
Damaged / Clearance
0.1% / 0.5%
No equivalent field. Sparse, and the stock tab uses the Stock sheet's ND/VD columns anyway, so real impact is limited
Salesman
3.6% (613 rows)
Cin7's SalesRepresentative is a customer-master default ("TA Sales", "Sales VIC"), not the actual rep on each order
⚠️ Order Note is the painful one
8,211 rows of human-entered delivery conditions, ETAs and exceptions. None of it exists anywhere in Cin7, and the moment hand-keying stops it also stops accumulating.
2. Where the headline numbers would change
① The Status vocabularies are completely different — every KPI needs redefining ⚠️ biggest risk
A 1:1 mapping is not possible. Every current KPI is defined on the sheet's vocabulary — revenue = Status ∈ {Credit, Invoiced, Confirmed}, order count = excluding {Cancelled, Hold, blank}, and Restocked excluded from revenue but included in order count (see Sales Data Table Spec & KPI Definitions).
The entire TAB dashboard, the weekly digest and the /ask bot all sit on top of those rules. Changing the source means re-validating all three.
② Counting rows naively inflates the totals
Like-for-like comparison for 2026:
Basis
Count
Sheet — invoiced lines
2,284
Cin7 — product lines (account 200)
2,778 (+21.6%)
Cin7 — all lines (including 1,476 freight lines on 260)
4,254 (+86%)
Cin7 records freight as its own line, where the sheet keeps it as a column on the product line. Counting lines without filtering immediately distorts dispatch and order counts.
③ The scope boundary collapses
What the extra 494 lines are: walk-in counter sales and spare-parts sales — exactly what the sheet deliberately excludes. Today TAB Sales Data (finished goods) and TA Service Parts Sales (parts) are cleanly separated; Cin7 keeps them in one ledger (its Products tab is 49% Spare parts).
K-Master gets mixed in: the 2026 Cin7 invoice lines include 21 K-master SKU lines / $50,132. K-Master currently has its own ledger (KM_Database) and CLAUDE.md's brand disambiguation rule forbids combining the two.
3. What actually gets better
Item
Detail
Deriving Branch
Fully possible.Branch=QLD ↔ customer Turbo Air Queensland TA QLD is an exact 1:1 across 5,225 rows (zero exceptions in either direction); Branch=NSW/VIC ↔ State has zero mismatches across 12,042 rows
History depth
Cin7 goes back to 2019-06-17 vs the sheet's 2021-01-04 → two years deeper
Attachments (proforma invoice PDFs, 12/12 in the sample) and accounting detail (GL account, GST, COGS, receiving bank account) — none of which the sheet ever had
4. Operational risks
A full rebuild takes 3.5 hours — line detail is one API call per order against a 60-calls/min ceiling. Changing the schema or losing the cache is expensive to recover from.
Single point of failure — an expired API key, a Cin7 outage, or a lapsed API add-on subscription means a complete stop. Today the sheet is human-maintained and always readable.
It cannot be undone — from the moment hand-keying stops, the sheet is permanently blank for that period. If the decision is later reversed, the gap cannot be backfilled.
Serial-number coverage unverified — the sheet's SN is 94.3% filled vs Cin7's BatchSN at 7 of 12 sampled orders. Stock-tracked items only, possibly — needs checking.
5. Recommendation — a four-phase transition
Phase
What to do
Deliverable
0. Now
Keep both running. Use the already-built cin7-reconcile-sales.mjs for daily discrepancy monitoring
Daily discrepancy report
1.
Lock in a Status mapping and redefine the KPIs — quantify "how much do revenue and order count move if calculated from Cin7" and get that signed off
Mapping table + variance report
2.
Handle what would be lost — change the process so Order Note is entered into Cin7's Note field, and decide how Freight Cost will be tracked
Process change
3.
Switch the dashboard's source; freeze the sheet as a read-only archive
Migration complete
📌 Phase 1 is the precondition
Without a Status mapping there is no way to say how the numbers move when the source changes. Migrating in that state means management reporting figures shift silently — the one outcome to avoid.
Referenced Pages
Cin7 Core (Dear Systems) API Integration Review — API structure, join keys, scope of accounting data
Cin7 Core Data Table Specification & Data Catalog — full spec of all 10 mirrored tabs
Sales Data Table Spec & KPI Definitions — the current KPI definitions (to be rewritten on migration)
LIVE comparison: Google Sheet Sales Data 42 columns / 17,267 rows + live queries against Cin7 saleList / sale?ID= / product (2026-09-23)
Referenced Pages
(see the "Referenced Pages" section in the answer body above)
Gaps Identified
⚠️ Knowledge Gap
(1) There is no Status mapping yet — this document says the mapping cannot be done automatically, not that it is impossible; producing it is the Phase 1 deliverable. (2) Serial-number coverage rests on a 12-order sample and needs a full check. (3) The Order Note loss verdict likewise rests on Cin7's Note being empty across those same 12 orders, so some orders may in fact carry a value. (4) The nature of the extra 494 lines (walk-in / parts) is inferred from a 2026-08 sample pattern; they were not classified exhaustively.