# 채널별 키 연결·테이블 구성·ERP/WMS 업로드 책임


> **최신 정렬:** [분류군→출시제품→실물 ITEM, MD 주문기준 판매추이, SCM 출고 이관](CMSLAB_제품계층·판매추이·SCM이관_판단근거_2026-09-09.md). 분류군은 가변 깊이이며 포장사양·채널 구성·LOT는 별도 축. 이관은 목표이며 완료되지 않음.

> 2026-09-09 · Proposed. 사용자의 제품 중심 설계 방향을 반영한 협의안이다. 원본의 컬럼 존재와 시스템 입력 가능 필드는 서로 다르다. 업로드 담당의 실명·승인권은 확정 전이다.

[제품·BOM·LOT 설계](CMSLAB_데이터·시스템아키텍처_인터뷰반영_2026-09-09_v0.2.md) · [현재 제품마스터 협의본](../../00_프로젝트작업실/10_제품·원료마스터/참고_ITEM_BOM_LOT_합성예시_v0.1.xlsx) · [현재 ITEM–WMS–채널 설계표](../../00_프로젝트작업실/09_CURRENT_ITEM-WMS-채널_설계초안.xlsx) · [업로드 책임표](../../00_프로젝트작업실/15_CURRENT_ERP-WMS_업로드책임표.xlsx)

## 1. 결합키를 세 가지로 구분

| 목적 | 내부 키 | 외부 키 후보 | 연결 테이블 |
|---|---|---|---|
| 무엇을 팔거나 보관하는가 | item_id / revision_id / offer_version_id | SKU, 바코드, 판매자상품코드, 옵션코드, 고객사관리번호 | EXTERNAL_IDENTIFIER + IDENTIFIER_MAPPING, SALES_BOM |
| 어떤 주문·납품·정산 건인가 | order_line_id / fulfillment_id / settlement_line_id | 주문번호, 상품주문번호, 수주/전표번호+행, 출고문서번호+아이템번호 | BUSINESS_DOCUMENT + DOCUMENT_LINE + TRANSACTION_LINK |
| 어떤 실물과 상태인가 | lot_id / stock_unit_id / inventory_event_id | 제조사+품목+LOT, 창고+셀+상품+LOT+등급 | LOT_MAP + INVENTORY_SNAPSHOT/EVENT + ALLOCATION |

주문번호를 제품 식별자로 사용하지 않는다. 상품코드·주문번호를 문자열 하나로 합쳐 저장하지 않고, 각 구성 열과 키 규칙 버전을 보존한다. 기술 PK는 안정적인 내부 ID, 복합키는 원천 범위의 유일성을 검증하는 별도 제약이다.

## 2. 키/교차표 테이블

| 테이블 | 필드 후보 | 제약·의미 |
|---|---|---|
| SOURCE_ACCOUNT | source_id, tenant/legal_entity, account_id, channel_id, store_id | 같은 코드가 다른 브랜드 계정·화주에서 재사용될 수 있음 |
| KEY_RULE_VERSION | key_rule_id, source_id, object_type, key_parts, normalization, valid_from/to | 키 구성/정규화/자료형을 버전관리, 원문 별도 보존 |
| EXTERNAL_IDENTIFIER | identifier_id, source_id, account_id, owner_id, namespace, raw_value, normalized_value, unit_level | SKU·바코드·옵션·고객사코드의 종류를 명시; 포장단위 EA/BOX와 구분 |
| IDENTIFIER_MAPPING | mapping_id, identifier_id, item_id 또는 offer_version_id, revision_id, valid_from/to, status, evidence_id | 대상 item/offer 중 정확히 하나; 복합 식별이 필요하면 KEY_COMPONENT에서 전체 문맥 연결 |
| KEY_COMPONENT | key_instance_id, key_rule_id, ordinal, field_name, raw_value, normalized_value | 구분자 충돌 없는 형식으로 직렬화·hash 가능, hash는 유일성 증거가 아님 |
| BUSINESS_DOCUMENT / DOCUMENT_LINE | document_id, source_doc_type, source_doc_no, account, line_id, source_line_no, version | 헤더와 라인 분리. 같은 주문에 같은 상품이 여러 줄 있어도 보존 |
| TRANSACTION_LINK | link_id, from_line_id, to_line_id, relation_type, allocated_qty, allocated_amount, status | 1:N 부분출고·N:1 합배송·다회정산·반품 연결. 수량/금액 조인 증폭 검증 |
| OUTBOUND_REFERENCE_MAP | export_batch_id, internal_line_id, target_doc_no, target_line_no, external_ref_value, status | 대상 사용자정의코드/참조란 가능 시 사용. 불가하면 sidecar 매핑과 대상 결과로 연결 |
| CHANNEL_ITEM_EXTENSION | channel/account, item/offer, local_name, local_category, owner, team_attributes_version | 공통 ITEM을 복사하지 않고 채널 전용 속성만 보관 |
| CHANNEL_PRICE/PROMOTION/PLAN | channel/account, offer/item, period, effective_from/to, version | 가격·쿠폰·계획을 키 맵이나 제품 고정 속성에 넣지 않음 |

바코드가 하나여도 포장 리뉴얼을 구분하지 못할 수 있다. 바코드만 입력 가능한 시스템은 `시스템+화주/계정+바코드+포장단위+유효기간`의 실제 구분가능성을 먼저 검사한다. 같은 바코드·동일 시점에 서로 다른 물품이 존재하면 사람 확인·별도 source SKU/LOT 증빙 없이 자동 매핑하지 않는다.

라인 식별자가 없으면 원천 재수령·정정의 동일 라인을 확실하게 식별할 수 없는 경우가 있다. 파일행 번호는 **수령 배치 안에서만** 유일하다. 값 hash가 같은 두 줄도 실제 중복 주문일 수 있으므로 임의 삭제하지 않는다. 이 경우 스냅샷 교체 단위·중복 판정 후보·담당자 확인을 설계하고 외부 쓰기를 보류한다.

## 3. 현재 자료에서 출발하는 채널별 전략

근거 W=[WMS 컬럼사전](../discovery/_materials/files/wms-data.md), S=[영업 샘플 실측](../discovery/_materials/files/sales-channel-samples-20260907.md). 아래는 기존 실측 문서와 전사록의 근거이며 모든 후보 키의 실제 유일성을 이번에 검증한 것은 아니다.

| 원천 | 품목 연결 후보 | 거래 연결 후보 | 별도 관리/제약·다음 확인 |
|---|---|---|---|
| ERP-U | 외부 ERP 품목코드→내부 item_id | 실제 수주/전표 PK+행; DB 확인 후 | 플랫폼 family/revision 유지. ERP 코드의 법인·유효기간/재사용 확인 |
| 가온/한익 | 화주+자사상품코드/고객사상품코드; EA/BOX 바코드 별도 | 고객전표NO+고객전표행, 전표번호; 출입고번호+상세행/LOT 후보 | W: 재고 센터+셀+상품+LOT+등급. 입출고번호+상품+LOT의 라인 중복 가능성 확인 |
| 품고 | 고객사+SKU번호, 고객사_관리번호, 바코드, 옵션 | 주문번호·원주문번호·보조주문번호 + 실제 상품/라인 ID | W/S: SKU목록과 재고·주문 간 공통 필드 확인. 판매자코드가 SKU목록 어느 열에 보존되는지 확인 |
| HGLIS | 화주+품목코드, 품목바코드/2 | 출고문서번호+출고문서아이템번호, 입고문서번호+순번, 고객주문번호 | W: 재고표는 센터+화주+품목 집계. 거래 LOT로 현재 LOT재고를 임의 추정 금지 |
| 올리브영 | OY 상품코드+판매범위, 외부 바코드와 내부 ITEM 교차표 | 납품확인서 문서/행 후보; 일자+매장+상품+실적종류 | S: 현 보유 월별 파일과 전사 상세화면 구분. 최상세 추출과 등록 양식 확보 |
| 롯데 면세 | 사업자+점포+외부 SKU/Ref No+단위 | 보고월+점포+상품+수불항목, 가능 시 실제 문서/행 | S: 약정가격·수불·세트 구성 별도. 월 집계로 주문번호 생성 금지 |
| 신라/HDC신라 | 사업자+점포+외부 SKU/Ref No | 누적 기준일/월+점포+상품+범위 | S/전사: HDC 별도 사업자, 온·오프 합산 범위·정정 확인 |
| 신세계/현대 면세 | 사업자+점포+상품코드/Ref No | 보고월+점포+상품+수불종류 | S: 유사 양식이어도 사업자·점포 namespace 유지 |
| 다이소 | 상품 item코드+직영/가맹/센터 범위 후보 | 제공기간+상품+범위; 상세행 미확인 | S/메모: 실제 포털 raw 미수령. OTP·누적·추산 분리 |
| 네이버 | 스토어+상품코드+옵션/판매자상품코드→offer→구성 item | 상품주문/원주문번호+라인 후보, 품고 번호 교차표 | 전사/W/S: 10일 갱신 매핑을 효력일 버전으로 전환. 주문과 정산 연결 별도 |
| 지그재그 | 브랜드 스토어+상품코드·옵션 후보 | 주문번호+상품주문번호+정산유형/회차 | S: 실제 정산 파일 존재, 쿠폰 부호·세전 확인 |
| 무신사/에이블리 | 계정+상품/옵션코드 후보 | 주문라인 ID와 정산행 ID 별도, 1P/3P 구분 | 전사: 실제 양식 확인 필요. 누적금액만 있으면 집계 fact |
| 카카오/CJ/임직원몰 | 서비스+계정+상품/옵션코드 후보 | 톡스토어/선물하기 구분, 주문·정산번호/행 후보 | 전사: 계정권한·인증, CJ 공급가·광고비 상계 |
| 컬리/비마트/화해 직매입 | 거래처+납품상품코드→item | 발주번호+발주행·입고문서 후보 | S: 비마트 헤더만, 컬리 1행; 확정 설계 전 추가 표본 |
| Amazon JP | 계정/marketplace+seller SKU 또는 child ASIN | order_id+order_item_id는 신규 확인 후보 | S: ASIN/SKU 스냅샷 보유. parent ASIN은 실물 item 키 아님 |
| Rakuten/Qoo10/일본 오프라인 | 점포+SKU/JAN/EDI 코드 | 실제 주문/행 또는 일자+점포+JAN 집계 | S: LOFT 일자×점포×JAN, Qoo10 실제 표본 미확인 |
| TikTok/해외 기타 | shop+product_id+sku_id 후보 | order/line ID 후보; 기존 BigQuery 필드 대조 | 채널별 별도 namespace, 접근 확인 후 상세화 |
| 자사몰/PG | 몰+상품/옵션, 원천 ERP양식외 필드 | 몰 주문번호+주문라인; PG 결제/취소/정산번호 | S: 결제·주문은 N:M 가능. 배송 PII를 공통 매핑키에 사용하지 않음 |

## 4. 입력 제약에 따른 전달 전략

| 대상 제약 | 처리 |
|---|---|
| 사용자 정의 참조 열 허용 | 의미가 맞는 전용 참조 필드에 내부 export/line 참조값 기록. 길이·허용문자·유일성·재조회 보존을 샘플로 확인 |
| 수주/주문번호만 허용 | 번호 생성권자가 원천일 수 있으므로 플랫폼 ID로 덮어쓰지 않음. 대상 등록결과의 문서/행을 OUTBOUND_REFERENCE_MAP에 저장 |
| 상품코드 대신 바코드만 허용 | 바코드 종류·포장단위·계정 scope로 승인 매핑. 구별 불가능한 revision은 LOT/별도 표식 증빙 확인 |
| 여러 주문이 합배송/여러 출고로 분할 | TRANSACTION_LINK로 수량 배정. 송장번호만으로 주문을 1:1 조인하지 않음 |
| 등록결과 파일이 없음 | 담당자 등록번호 입력 + 대상 재조회 자료로 대사. 결과미확인은 보류 상태; 완료로 간주하지 않음 |
| 입력 양식이 미수령 | 추측한 ERP/WMS용 파일을 실제 업로드 가능 양식으로 표시하지 않음. 논리 요구 필드표와 샘플 요청을 먼저 준비 |

## 5. 누가 올리는가 — 시스템별 책임 초안

플랫폼 운영자에게 모든 업로드 업무를 모으지 않는다. **채널별 내용 책임, SCM/물류 수량·LOT 검토, ERP 등록권한, 물류사 WMS 실행**을 분리한다. 현재 담당 체계가 있으면 우선 유지하고 인계 구간만 명확히 한다.

| 업무/경로 | 원본·매핑 내용 책임 | 검토·승인 후보 | 대상 업로드/실행 후보 | 완료 확인·예외 책임 |
|---|---|---|---|---|
| 전사 신규 제품·코드 | BM 제품정보, SCM 코드 | BM/SCM 필드 오너; 처방/품질 별도 | ERP 기존 품목등록 담당 / WMS 각 운영사 담당 | SCM 코드맵·채널 담당 전파확인 |
| 일반 온라인 출고 | 채널 담당 상품·옵션·증정 매핑 | SCM/물류 재고/LOT, 현행 경영관리 출고승인 | 기존 ERP 등록 담당; 물류사 WMS 담당 또는 확인된 기존 연동 | SCM 출고대사, 매핑 오류는 해당 채널 |
| 네이버·품고 후행 실적 | 네이버 담당 다운로드·구성검증 | 기존 소희님 협업 역할의 소속/등록권한 확인 | 기존 ERP 등록 담당, 품고 출고는 기존 운영 경로 | 네이버+SCM 품고 실출고/ERP 대사 |
| 올리브영 납품 | 올영 담당 발주·코드·가능수량 | SCM/물류 유효기간·LOT, 현행 승인자 | 올영 담당 포털 예약; 로지 언급 역할 ERP 등록; 3PL WMS 등록 | 올영+SCM 납품/실출고 대사. 로지 소속·실명 미확정 |
| B2B·샘플 출고 | 각 영업 요청, 매출/샘플 분리 | SCM/물류 + 현행 경영관리 승인 | 기존 ERP 등록 담당, 물류사 WMS | SCM 출고대사·영업 인수 확인 |
| 해외 패킹·출고 | 해외영업 요청·패킹 자료 | SCM/물류 LOT·예약, 현행 승인자 | SCM/물류가 요청파일 전달, 기존 ERP 담당 등록, 3PL 실행 | SCM 예약·패킹·이동·실출고 정합성 |
| 구매입고·QC | 구매 입고요청, 물류 실입고, RM 판정 | RM 품질 승인; 구매/SCM 수량 차이 검토 | ERP 구매입고 담당; WMS 물류사. 정상상태 전환 담당 별도 확인 | SCM 장부·실물 대사, RM 판정 미반영 추적 |
| 월매출·정산 | 채널 담당 원본/차감·가격 확인 | 경영관리 가마감·재경 확정 | 기존 ERP 회계 등록 담당(소속/권한 확인) | 재경 최종 대사; 채널에 오류 원인 반환 |
| 반품·교환·계정대체 | CS/영업 사유·원주문 연결 | SCM/물류 실물, 현행 승인 경로 | 기존 ERP 출고/반품 담당 + 물류사 WMS | CS/SCM 사건종결·재경 금액대사 |
| 마스터·채널 매핑 변경 | 해당 필드 오너·채널 담당 | 공통 영향 시 SCM/BM/재경 해당 오너 | 플랫폼 승인 워크플로, 필요한 대상만 기존 등록 담당 | 채널별 변경 전파 확인 |

각 행마다 정/부 담당자, 승인자, 마감시각, 파일 위치, 대상 시스템 권한, 반려 사유, 등록번호 수집 방식이 채워져야 실행 가능한 책임표가 된다. `누군가 올림` 또는 `플랫폼이 자동 완료` 상태로 인계하지 않는다. 업로드 전 담당자에게 확인할 샘플은 **원본 다운로드 → 수기가공 결과 → 실제 입력 양식 → 성공/실패 결과** 한 묶음이다.