# 제품 계층·MD 판매추이·SCM 출고 이관 — 최신 설계 판단

> 2026-09-09 사용자 추가 정렬 반영 · 초안 설계는 진행 승인. 고객의 상세 정책·조직 이관 완료·시스템 변경 승인은 미확정.

> 추가 기술 방향(같은 날): 사용자는 Supabase를 사용하지 않고 AWS 기반 RDB로 갈 가능성이 높다고 명시했다. **AWS RDB 우선**으로 구현을 준비한다. 엔진·인증·배포 서비스는 미확정이며 제품·채널·LOT의 논리 모델은 유지한다. [구현 준비](../구현준비/README.md) · [AWS 전환 설계](../구현준비/ERP-Core/04_AWS-RDB_전환설계.md).

## 최신 범위 정렬 — 기존 제출 파일과 ERP 실행 경계

기존 부서의 가공·제출 파일을 등록·검증·축적하여 경영진 대시보드로 연결하는 것이 먼저다. 이미 있는 API·자동화 결과는 재사용하고 미수집 구간은 제출 파일로 보완한다. 신규 RAW/API 자동화는 후속이며 자동화 구축 완료를 선행조건으로 삼지 않는다. 아래 초기 파일럿·갱신주기 후보는 이 최신 범위에 맞춰 해석한다.

| 판매 축 | 원천·의미 | 보존할 구분 |
|---|---|---|
| 판매계획 | 목표·계획 양식 | 기간·팀·채널·제품·계획 버전 |
| 구매일 기준 판매추이 | 실적·고객 주문내역 | 구매일·주문행·취소/반품 이력 |
| 실제 마감완료 정산내역 | 배송·취소·반품·쿠폰 반영 정산 | 채널 기준일·마감 확정 상태·정정 버전 |

잠정 가마감은 마감완료 정산과 다르다. 완료 정산으로 구매일 기준 주문실적을 덮어쓰지 않는다. 채널별 미수령·주문 원천 부재는 별도로 표시한다.

통합재고 조회는 원천 기준시각과 ERP-WMS 상태 매핑을 맞춘 범위에서 검토한다. 현업이 WMS/채널창고에서 먼저 실행하고 ERP에 나중에 반영하는 경우가 있으므로 ERP를 최신 실물재고 정본으로 가정하지 않는다. [원천별 조회·갱신 근거표](CMSLAB_원천별_갱신주기_근거표_CURRENT.md)에 사이트·화면/파일·거점·재고범위·담당·ERP 반영 지연을 연결한다.

재고락·예약·할당·가상창고·부서재고 분리/이동은 ERP 기존 기능에서 실행해야 할 수 있다. 기능·설정·권한 확인 전 확정하지 않는다. 이번 프로젝트에서 ERP 사용방법 안내와 운영설계는 가능하지만 ERP 자체 수정·확장은 범위 밖이다. 기존 기능이 불가능하면 조회·경고·업무절차로 남으며 신규 플랫폼의 락 표시만으로 실출고 잠금을 보장할 수 없다. AWS 내부 업무원장에 쓰는 권한과 ERP/WMS 실행 권한은 별개다.

## 1. 권장 구조: 기본 3계층 + 포장 버전·채널 구성의 별도 축

**분류군 → 출시제품 → 실물 품목**을 최소 3계층으로 둔다. 분류군은 고정 1단계가 아니라 필요에 따라 브랜드/라인/기능/카테고리를 여러 단계로 둘 수 있다. 포장 사양과 채널 판매구성을 이 계층 밑에 일렬로 붙이면 중복이 생기므로 별도로 연결한다.

| 층/축 | 예시 | 식별자·테이블 | 구분 이유 |
|---|---|---|---|
| 분류군(가변 깊이) | 쿨링, 선케어, 스킨케어 등 — 예시이며 분류체계 미승인 | TAXONOMY_NODE(node_id, taxonomy_id, parent_node_id, node_type), PRODUCT_CLASSIFICATION | 쿨링은 여러 출시제품을 포함할 수 있음. 기능과 제형처럼 교차 분류는 다른 taxonomy/태그로 관리 |
| 출시제품 정체성 | 하나의 제품으로 출시·운영하는 제품 | PRODUCT(product_id, name, owner, identity_policy_version) | 포장·채널·ERP 코드가 바뀌어도 같은 제품의 판매추이 추적 |
| 실물 품목 | 용량·판매단위·실물구성 차이를 관리하는 ITEM | ITEM(item_id), PRODUCT_ITEM_MEMBERSHIP | 재고/출고/구매에서 구분해야 하는 단위. 운영 코드와 내부 키 분리 |
| 포장·라벨 사양축 | 구포장/신포장, 표시문안 변경 | ITEM_REVISION, PACKAGING_BOM | 같은 ITEM 안의 사양 변경 또는 별도 ITEM 생성 여부를 정책으로 판정 |
| 채널 판매축 | 네이버 2개+증정, 올영 기획 구성, 채널 옵션 | CHANNEL_OFFER, SALES_BOM_VERSION, OFFER_COMPONENT | 한 판매상품이 여러 ITEM을 포함하고 한 ITEM이 여러 채널에서 팔림 |
| 생산·품질·재고축 | 제조 LOT, 포장작업, 창고·보류·예약 | LOT, PACKAGING_RUN, QC_DECISION, INVENTORY_EVENT | 분석 제품 분류와 실물 추적을 분리 |

`쿨링→특정 출시제품→실물 ITEM`은 계층이고, `ITEM↔채널 판매상품`은 구성관계다. `제품군`이라는 단어로 분류군과 출시제품을 동시에 부르지 않는다. 이전 v0.2 초안의 PRODUCT_FAMILY는 **출시제품 PRODUCT** 의미로 정리하고 상위 분류체계를 추가했다.

분류 노드는 사이클 금지, taxonomy 내 부모 일관성, 효력기간·승인 이력을 관리한다. 주분류는 시점별 한 개로 제한할 수 있고 다중 기능 태그는 별도 브리지로 허용한다. 포장 BOM에 들어가는 부자재는 소비자용 출시제품 소속을 강제하지 않는다.

### 실제 자료가 보여주는 근거

현재 SCM 품목 수집본에는 동일 데일리트러블케어폼클렌저의 130ml 본품, 50ml 증정, 130ml+50ml 기획 구성처럼 품목이 나뉜 사례가 있다. `품목분류`에는 종료 같은 운영상태와 제품 명칭이 섞여 있어, 현재 분류 열을 완성된 제품 계층으로 그대로 채택하기 어렵다. 별도 WMS 확인 대장에도 용량·리뉴얼·단상자 차이를 검토하는 항목이 존재한다. 이름이 비슷하다는 이유만으로 자동 통합하지 않는다. [현재 SCM 기반 제품마스터](../../00_프로젝트작업실/08_CURRENT_제품마스터_고객협의본.xlsx)

따라서 지금부터 내용물 기준 변형(variant)을 필수 4번째 계층으로 추가하기보다는 PRODUCT–ITEM 사이의 필요 속성을 우선 명시한다. 추후 용량/제형/색상 조합별 공통 속성이 반복되고 여러 실물 포장 ITEM이 하나의 규격을 공유한다는 표본이 확인되면 `PRODUCT_VARIANT`를 승격할 수 있다. **기본 3계층은 최소 골격이고, 분류 깊이는 가변이며 사양/채널/LOT 축은 분리**하는 안이다.

### 표준 대조와 적용 한계

GS1은 거래품목 식별과 제품 변경을 다루며, 표시 내용량 변경 및 포장 수량·사전 구성상품 변경 등의 GTIN 판정 규칙을 별도로 둔다. 이는 출시제품의 분석상 연속성과 물류 거래단위 식별을 분리할 필요를 뒷받침한다. 다만 GS1이 CMSLAB에 위 3계층을 요구하는 것은 아니며, 이 계층 수는 내부 자료에 근거한 설계 판단이다. [GS1 GTIN Management Standard 1.1, §§2.3·2.8·2.9](https://ref.gs1.org/standards/gtin-management/)

GTIN 신규 발급 여부를 이번에 결정하지 않는다. 실제 CMSLAB 바코드·채널 코드 사용과 유효기간, 포장 리뉴얼의 실물 구분 필요성을 검토해 내부 item/revision과 연결한다.

## 2. MD가 원하는 것은 ‘주문기준 판매추이’

사용자 정정에 따라 명칭은 **주문기준 판매추이**로 고정한다. 관리회계와 다른 매출액을 새 공식 숫자로 만들자는 기획이 아니다.

| 관점 | 기본 시간축 | 우선 지표 | 담당·의미 |
|---|---|---|---|
| MD 판매추이 | 고객 주문일/시간 | 주문상품수량, 주문건수, 취소수량, 반품수량, 행사 전후 수량 변화, TOP 제품/옵션 | 채널 영업. 수요 흐름 관찰 |
| 물류 실행 | 요청·출고·인수일 | 요청수량, 예약/미출고, 실출고, 반품입고 | SCM·물류. 실행 상태 |
| 정산·관리회계 | 정산일·회계기준일·확정기간 | 정산금액·공제·가마감·확정매출 | 경영관리·재경. 현행 승인된 보고 체계 |

정산액을 주문일로 옮겨 그린 그래프는 MD 판매추이 원천의 대체가 아니다. 주문 원천이 없는 B2B는 **셀인/출고 추이**라고 표시하고 고객 주문 판매추이에 섞지 않는다. 다이소 추산 셀아웃·면세 누적차분은 별도 커버리지와 품질 표시가 필요하다.

### 작은 범위로 시작하는 화면·데이터 기획

- 기본 화면은 기간×출시제품/ITEM/채널·옵션별 **주문수량 추이**와 TOP 제품, 전주 비교, 행사 마커를 보여준다. 금액 지표는 초기 필수에서 제외한다.
- 취소·반품은 원주문 기준 코호트와 발생일 흐름을 구분한다. 최초 주문수량은 보존하며 `조회시점 기준 순주문수량`을 별도 계산한다. 취소·반품이 중복 상태로 들어오면 합산 차감하지 않고 상태/사건 정합성을 먼저 검증한다.
- 가상세트는 고객이 구매한 옵션 수량과 본품 환산수량을 선택할 수 있게 한다. 사은품 수량을 유료 본품 판매수량에 섞지 않는다. 여러 제품이 포함된 세트는 상품별 주문건수를 합산하면 전체 주문건수보다 커질 수 있음을 명시한다.
- 필수 원천은 source/account, order_id, 실제 line_id, 주문일시, offer/item, 주문수량, 상태/취소·반품, 갱신시각이다. 누락 시 가능한 지표만 표시한다.
- 재경 숫자 변경이나 ERP 쓰기를 요구하지 않는 읽기 전용 파일럿으로 시작한다. 권한 허용된 채널 한 곳과 대표 제품으로 업무 효용·추가 작업량·자료 안정성을 확인한다.
- 주문 원천 부재, 매핑 불가, 권한/업무 오너 합의 실패, 유지 공수가 효용을 넘는 경우 보류할 수 있다. 이 기능이 공통 제품마스터와 재고/대사 구축의 선행조건이 되지 않도록 분리한다.

목표는 조직 간 경쟁하는 매출 수치를 만드는 것이 아니라 각 역할이 필요한 시간축을 선택하는 것이다. 현행 정산·관리회계 기준과 공식 보고 경로는 별도 유지하며, 파일럿의 공유 범위·지표명·소유자부터 합의한다. 개인/부서의 정치적 의도는 추정 기록하지 않는다.

## 3. 출고 책임은 AS-IS와 TO-BE를 분리

**사용자 이해(현행):** 채널에서 경영지원에 출고 요청을 전달하고, 물류관리사에 출고 메일을 보내면 출고된다. **사용자 목표:** 가능하면 경영지원이 담당하던 출고 요청 업무를 SCM으로 이관한다. 실제 승인권·ERP 등록권·메일 발신 순서는 아직 확인이 필요하다.

| 단계 | 현행 확인 대상 | 목표 초안 |
|---|---|---|
| 채널 요청·옵션 정보 | 채널→경영지원 출고요청, 물류사 메일 발신자가 누구인지 | 채널→SCM 통합 요청, 원주문/상품/옵션/납기/채널조건 |
| 수량·LOT·조건 검토 | SCM·경영지원·물류사 사이 검토 순서 | SCM 요청 접수·재고/LOT/예약 검토, RM QC 연계 |
| 승인 | 재무·채권·예산·샘플 등 통제가 붙는 범위 | 운영 승인 SCM 후보, 재무성 예외는 기존 권한 오너에 검토 요청; 이관 범위 합의 |
| ERP 등록 | 실제 기존 입력 담당·계정 | 이관 합의·권한/교육 완료 시 SCM 담당 또는 지정 등록 담당. 자동으로 이관 완료 처리하지 않음 |
| WMS 전달/등록 | 채널/경영지원/SCM 메일 및 3PL 입력 경로 | SCM 승인 출고 묶음→지정 발신 경로→물류사 WMS 등록/실행 |
| 대사·완료 | 요청·ERP·물류사 결과를 누가 맞추는지 | SCM 운영 완료 책임, 물류사 실행결과, 채널 진행상태 조회, 재경 회계대사 |

이관 단위별로 적용 채널/업무·전환일·구/신 담당·예외 승인자·등록 권한·양식·교육·정/부 담당을 고정한다. 전환 기간에 옛 메일과 새 플랫폼이 같은 출고를 각각 보내지 않도록 `fulfillment_request_id + execution_route + cutover_version`으로 실행 주체를 한 곳으로 정한다. 미전환 채널은 현행 경로를 명시한다.

전환 완료 기준은 관계 부서 업무 합의, ERP 권한 확보, 예외 승인 흐름 검증, 실제 업로드/물류사 결과 대사, 중복 발송 방지, 부재시 대체 담당 확인이다. 이번 작업은 책임 초안과 인계 체크표를 만드는 단계다.


## 9/9 신규 회의와 기존 설계의 정합성

[Discovery 신규 근거](../discovery/README.md#99-신규-회의-편입)에서 일본의 FBA 보충 시뮬레이션·월 ERP 등록과 글로벌 EC의 수집 한계를 반영했다. 제품계층과 ERP 독립 논리 모델은 유지하며 다음 경계를 명시한다.

- ERP 우선 등록·단방향 전파 의견과 플랫폼 확장정보 관리가 함께 논의됐다. 이는 기존 사용자 지시인 ‘ERP에 무조건 맞추지 않는다’를 취소한 승인 기록이 아니다. 필드/업무별 정본·수정자·외부 반영·대사 경로를 정하고, ERP 읽기 권한만으로 양방향 동기화가 가능하다고 보지 않는다.
- ERP 품목 삭제 시 플랫폼 정보도 모두 삭제하자는 발언은 설계 토론의 예시다. 적용 결정을 내리지 않는다. 비활성화·이력 보존·자산 참조 처리 정책을 별도 검토한다.
- 연구소 원료 중 사급 원료는 ERP에 존재하고 제조사 보유 원료는 연구소 엑셀에서 관리한다는 설명이다(손익 회의 36:26~40:33). 개념 원료 정체성과 소유/재고·ERP품목 매핑 범위를 분리해, 모든 원료에 ERP 코드를 강제하거나 같은 원료의 정본을 중복 생성하지 않는다.
- 판매추이와 확정 관리 실적의 분리, 금액 전망과 수량 공급계획의 분리, 프로모션/판매구성 효력기간을 유지한다. ‘재고-판매’ 단순 추산이나 고정 보정률은 운영 재고·확정 매출의 대체물이 아니다.

회의 원문은 [손익·ERP 전사록](../../03_실행관리/회의록/2026-09-09_손익분석·데이터구조·ERP연동/01_원본전사록.txt) 13:09~20:49, 23:41~25:07, 34:10~34:30, 36:26~40:33 참조. 새 논의는 승인된 전사 R&R·가격정책·삭제정책으로 승격하지 않는다.