TAB-QA-041 · Q&A · 2026-09-23 · David 시스템·IT

Cin7 단일소스 전환 — 데이터 누락·리스크 점검

앞으로는 구글시트에 거래내역을 중복으로 기재하지 않고, Dear System API 에서 데이터를 받아서 활용할 생각이야. 이럴때 생길 수 있는 문제점이나 데이터 누락이 발생할 수 있는지 점검해줘.

문서번호 TAB-QA-041 주제 시스템·IT 일시 2026-09-23질문자 David 원본 30. Queries

2026-09-23 Q&A - David

Query

질문: 앞으로는 구글시트에 거래내역을 중복으로 기재하지 않고, 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 Note47.6% (8,211행)Cin7 Note 필드는 표본 12건 전부 공란. “BX without tailgate/FIS(무상), ETA:10월 중순” 같은 운영 메모가 통째로 소실
Freight Cost (운임 원가)9.1% (1,572행)Cin7엔 운임 수익(계정 260 Freight & Handling)만 있고 원가 필드 자체가 없음 → 운임 마진 산출 불가
Damaged / Clearance0.1% / 0.5%대응 필드 없음. 다만 희소하고 재고 탭은 Stock 시트의 ND/VD를 쓰므로 실제 영향은 제한적
Salesman3.6% (613행)Cin7 SalesRepresentative는 고객 마스터의 기본값(“TA Sales”·“Sales VIC”)이라 주문별 실제 담당자가 아님

Order Note가 가장 아프다

8,211행에 사람이 직접 남긴 배송조건·ETA·특이사항이다. 이 정보는 Cin7 어디에도 없고, 수기 입력을 멈추는 순간부터 새로 쌓이지도 않는다.


2. 핵심 수치가 달라지는 지점

① Status 체계가 완전히 다르다 — 모든 KPI 재정의 필요 ⚠️ 최대 위험

값 분포
구글시트Confirmed 15,333 · Cancelled 612 · Credit 422 · Invoiced 335 · Ordered 324 · Restocked 177 · Hold 30 · Picking 16 · Released 16
Cin7COMPLETED 10,332 · INVOICED 810 · ESTIMATING 786 · ORDERED 214 · ESTIMATED 191 · CREDITED 145 · VOIDED 122 · BACKORDERED 32 … (총 15종)

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. 운영 리스크

  1. 재구축에 3.5시간 — 라인 상세는 주문당 1회 호출(60 calls/min 제한). 스키마를 바꾸거나 캐시가 깨지면 재백필 비용이 크다.
  2. 단일 장애점 — API 키 만료·Cin7 장애·API 애드온 구독 종료 시 전면 중단. 지금은 사람이 유지하는 시트라 언제든 읽을 수 있다.
  3. 되돌릴 수 없다 — 수기 입력을 멈춘 순간부터 그 기간의 시트 데이터는 영구 공백이다. 나중에 “역시 시트가 필요하다”가 되어도 소급 복원이 불가능하다.
  4. 시리얼번호 커버리지 미확인 — 시트 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로 바꾸면 매출 숫자가 어떻게 달라지는지”를 말할 수 없다. 그 상태로 전환하면 경영 보고 수치가 소리 없이 바뀐다 — 가장 피해야 할 시나리오다.


참고 문서


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


回答

💡 结论 迁移是可行的,但以目前的状态直接停止手工录入是不行的。 对两套系统逐字段实测比对后,确认有 4 类数据会永久丢失,以及 3 处核心数字会发生变化。尤其是 Status 体系无法一一对应,看板、周报、/ask 机器人背后的所有 KPI 定义都需要重新制定。 反过来,Branch 完全可以推导,而且历史数据反而多了两年。

核查方式

将 Google 表格 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(Free of Charge), ETA: mid Oct" 这类运营备注将整体消失
Freight Cost(运费成本) 9.1%(1,572 行) Cin7 只有运费收入(科目 260 Freight & Handling),完全没有成本字段 → 无法计算运费毛利
Damaged / Clearance 0.1% / 0.5% 无对应字段。但数据稀疏,且库存页签使用 Stock 表的 ND/VD 列,实际影响有限
Salesman 3.6%(613 行) Cin7 的 SalesRepresentative 是客户主数据的默认值("TA Sales"、"Sales VIC"),并非每笔订单的实际负责人

⚠️ 最痛的是 Order Note 这是 8,211 行由人工录入的配送条件、ETA 与特殊事项。Cin7 中完全不存在这些信息,而且一旦停止手工录入,今后也不会再积累。


2. 核心数字会变化的地方

① Status 体系完全不同 —— 所有 KPI 需重新定义 ⚠️ 最大风险

取值分布
Google 表格 Confirmed 15,333 · Cancelled 612 · Credit 422 · Invoiced 335 · Ordered 324 · Restocked 177 · Hold 30 · Picking 16 · Released 16
Cin7 COMPLETED 10,332 · INVOICED 810 · ESTIMATING 786 · ORDERED 214 · ESTIMATED 191 · CREDITED 145 · VOIDED 122 · BACKORDERED 32 …(共 15 种)

无法做到一一对应。 目前所有 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 行是什么:上门散客销售与配件销售 —— 正是表格有意排除的部分。目前 TAB Sales Data(整机)与 TA Service Parts Sales(配件)是清晰分离的,而 Cin7 将两者放在同一本账上(其 Products 页签中 49% 是 Spare parts)。
  • K-Master 会被混入:2026 年 Cin7 销售行中确认有 K-master SKU 21 行 / $50,132。K-Master 目前使用独立账本(KM_Database),而 CLAUDE.md 的品牌区分规则明确禁止两者合并。

3. 反而会变好的部分

项目 内容
Branch 推导 完全可行。 Branch=QLD ↔ 客户 Turbo Air Queensland TA QLD 在 5,225 行上精确一一对应(双向均无例外);Branch=NSW/VIC ↔ State 在 12,042 行上零不一致
历史深度 Cin7 自 2019-06-17 起,表格自 2021-01-04 起 → 多出两年
可对应的字段 P/O No ↔ CustomerReference、Delivery ↔ Carrier、配送地址 ↔ ShippingAddress
新增获得的数据 附件(形式发票 PDF,抽样 12/12)与会计信息(总账科目、GST、COGS、收款账户)—— 均为表格从未拥有的数据

4. 运营风险

  1. 完整重建需 3.5 小时 —— 行级明细需按订单逐笔调用 API,且受 60 calls/min 限制。一旦变更结构或缓存损坏,恢复成本很高。
  2. 单点故障 —— API 密钥过期、Cin7 服务中断或 API 附加订阅到期,都会导致全面停摆。目前表格由人工维护,任何时候都可读取。
  3. 无法回退 —— 自停止手工录入之时起,该期间的表格数据将永久空白。即便日后改变决定,也无法追溯补录。
  4. 序列号覆盖率未确认 —— 表格 SN 填充率 94.3%,而 Cin7 BatchSN 在抽样 12 笔中仅 7 笔有值。可能仅追踪库存品,需进一步核实。

5. 建议 —— 分四阶段迁移

阶段 要做的事 产出
0. 现在 保持双轨并行。使用已建成的 cin7-reconcile-sales.mjs 进行每日差异监控 每日差异报告
1. 确定 Status 映射表并重新定义 KPI —— 量化"若改用 Cin7 计算,销售额与订单量会变动多少百分比",并取得确认 映射表 + 差异验证报告
2. 针对会丢失的项目制定对策 —— 变更业务流程,将 Order Note 录入 Cin7 的 Note 字段;确定 Freight Cost 的另行管理方案 业务流程变更
3. 切换看板数据源,将表格冻结为只读归档 迁移完成

📌 第 1 阶段是前置条件 若 Status 映射未确定,就无法说明"改用 Cin7 后数字会如何变化"。在那种状态下迁移,会导致经营报告数字悄无声息地改变 —— 这是最应当避免的情形。


参考文档

  • Cin7 Core (Dear Systems) API 连接评估 —— API 结构、关联键、会计数据范围
  • Cin7 Core Data 表结构与数据目录 —— 镜像表 10 个页签的完整规格
  • Sales Data 表结构与 KPI 定义 —— 现行 KPI 定义(迁移时需重写)
  • LIVE 比对:Google 表格 Sales Data 42 列 17,267 行 + Cin7 saleList/sale?ID=/product 实时查询(2026-09-23)

参考页面

  • (请参见上方回答正文中的"参考文档"部分)

已识别的知识空白

⚠️ 知识空白 (1) 目前尚无 Status 映射表 —— 本文档表达的是"无法自动映射,需由人工定义",而非"不可能映射";映射表本身是第 1 阶段的产出。(2) 序列号覆盖率基于 12 笔订单的抽样,需要全量核实。(3) Order Note 丢失的判断同样基于这 12 笔订单中 Cin7 Note 均为空,因此部分订单可能实际存有值。(4) 超出的 494 行的性质(散客/配件)是依据 2026-08 抽样所呈现的模式推断得出,并未进行全量分类。

ℹ️ Query Question: 앞으로는 구글시트에 거래내역을 중복으로 기재하지 않고, Dear System API에서 데이터를 받아서 활용할 생각이야. 이럴 때 생길 수 있는 문제점이나 데이터 누락이 발생할 수 있는지 점검해줘. Asked by: DavidDate: 2026-09-23


Answer

💡 Bottom line The 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

Value distribution
Google Sheet Confirmed 15,333 · Cancelled 612 · Credit 422 · Invoiced 335 · Ordered 324 · Restocked 177 · Hold 30 · Picking 16 · Released 16
Cin7 COMPLETED 10,332 · INVOICED 810 · ESTIMATING 786 · ORDERED 214 · ESTIMATED 191 · CREDITED 145 · VOIDED 122 · BACKORDERED 32 … (15 values in total)

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
Fields that do map P/O No ↔ CustomerReference, Delivery ↔ Carrier, delivery address ↔ ShippingAddress
Genuinely new data 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

  1. 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.
  2. 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.
  3. 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.
  4. 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.