# ERP·업무 프로세스 설계

## 운영 메뉴

운영 대시보드 → 입점업체 심사 → 상품 실물 검수 → 외부 구매/발주 → 배송/설치 → 취소/환불 → 축의금 송금 → 업체 정산/대사 → 템플릿 → 카테고리 → 권한/감사.

## 상태 전이

| 업무 | 정상 흐름 | 예외 처리 |
|---|---|---|
| 업체 | 신청→서류 검토→계약 확인→승인 | 보완/반려/판매중지 |
| 상품 | 초안→제출→실물 도착→검수→승인→노출 | 반려/수정 재검수/품절/중지 |
| 모임 | 준비→인증→모집→금액달성→주문준비 | 기한 만료/미달/결제승인지연/취소 |
| 주문 | 재고·가격 확인→외부 구매 또는 발주→출고→배송/설치→완료 | 가격변동/품절/설치불가/파손 |
| 환불 | 요청→단계·실비 검토→배분 확정→원결제 환불→대사 | 부분환불/외부몰 지연/PG 실패 |
| 축의금 | 승인→수령인 검증→행사종료→3영업일 수령→10영업일 미지급 자동입금 | 계좌불일치/행사변경/차지백/송금실패 |
| 업체 정산 | 판매/배송 기준 수집→8%수수료→환불 조정→대사→확정→지급 | 불일치/보류/지급실패 |

## 실물 검수 화면 구성

좌측 목록은 업체·상품·접수일·실물 도착·보완 여부로 검색한다. 상세는 제출 정보, 실제 상품 사진, 구성품, 품질·포장, 배송·설치, 반품 조건, 검수 이력으로 나눈다. 승인 버튼은 실물 확인·필수 검수 메모·권한을 만족해야 활성화된다. 승인은 product_revision에 연결되고 이후 수정으로 기존 검수 이력을 덮어쓰지 않는다.

## 외부 구매→업체 출고 전환

Order.fulfillment_mode를 external_purchase/vendor로 둔다. 초기에는 구매 담당자, 외부몰 주문번호·구매금액·증빙·예상배송을 기록한다. 공급업체 출고 시 vendor_order_id·출고지·송장·설치 예약으로 처리한다. 고객 주문과 참여자 결제 구조는 전환 때문에 바꾸지 않는다. 사유 없는 추가금 자동 청구는 금지하고 가격 변동 시 동의/환불 경로로 보낸다.

## 결제·환불·송금 원장

PaymentIntent→PaymentAttempt→PaymentEvent를 분리한다. 승인 금액·통화·상품스냅샷은 서버 생성값과 대사한다. 환불은 원결제 기준 배분하고 RefundAttempt와 결과를 남긴다. Payout은 recipient_id·행사·미지급 잔액·due_business_date·idempotency_key를 가진다. 송금 성공과 회계 반영을 같은 상태 전이로 묶고 실패 큐는 성공 지급키를 다시 실행하지 않는다.

상품 판매가1,000,000원의8%수수료80,000원, 배송비·세금·환불 조정 전 기준액920,000원. 축의금100,000원은 발신자106,000원 승인, 수령원금100,000원, 수수료6,000원. 두 원장 유형의 수수료를 합산해서 주최자에게 차감하면 안 된다.

## 권한·감사

판매자는 자사 상품/발주만, 주최자는 본인 행사만, 참여자는 본인 결제만 조회한다. 검수 담당자는 실물 승인, 출고 담당자는 목적상 필요한 배송지, 정산 담당자는 송금/환불/정산 정보에 접근한다. 최고관리자는 역할 설정을 담당하되 역할 변경 자체도 감사한다. 민감정보 조회, 환불 확정, 송금 재처리, 검수 승인, 상품 중지는 담당자·시각·사유·전후 상태를 기록한다.

## 스케줄러·운영 예외

모집 만료 worker, 결제 승인 대사, 배송 상태 동기화,3/10영업일 지급 후보 생성, 지급 결과 대사, 업체 정산 후보 생성, 실패 알림을 분리한다. 각 작업에 재시도 한도·멱등키·작업 잠금·실패 큐가 필요하다. 결제/송금 성공 여부는 UI 타이머나 클라이언트 계산으로 확정하지 않는다.

## ERP 수용 시나리오

미인증 업체 접근 거부; 검수 메모 없는 승인 거부; 다른업체 상품 조작 거부; 같은상품 다중분류 성공; 주문달성/만료 동시실행 한쪽만처리;4/5 잔액결제 인원보존; 외부몰 구매완료후 1인취소 분배검토;3일차 지급후10일차 잔액만 지급; 송금응답타임아웃 재조회후처리; 감사이력 없이 수동조정불가.