거래처 통합 관리(Partner) 개편 및 탭 분리 구현 계획

Goal Description

기존 Supplier(공급사) 모델 중심의 구조를 Partner(거래처) 통합 모델로 개편합니다. 이 과정에서 내부적으로 공급사(SUPPLIER)와 고객사(CUSTOMER)를 type으로 구분하여 관리하고, '거래처 관리' 메뉴 하위에 공급사 | 고객사 탭을 두어 별도의 페이지처럼 작동하도록 구성합니다. 또한 사용자가 요청하신 비밀번호(로그인용) 항목 추가와 주소(기본주소, 나머지주소) 분리를 반영합니다.

Proposed Changes

1. Database Migrations

• 새로운 partners 테이블 생성:
  • type (enum: 'SUPPLIER', 'CUSTOMER') - 공급사/고객사 구분
  • name (string) - 거래처명
  • contact_name (string, nullable) - 담당자명
  • password (string, nullable) - 로그인용 비밀번호 (해시 암호화 처리)
  • email (string, nullable) - 이메일
  • phone (string, nullable) - 전화번호
  • address (string, nullable) - 기본주소
  • address_detail (string, nullable) - 나머지 주소
  • is_active (boolean, default true)
• 데이터 마이그레이션:
  • 기존 suppliers 테이블의 데이터를 partners 로 복제 (단, type은 'SUPPLIER'로 지정)
• 외래키 및 컬럼 수정 (purchase_orders 등):
  • 발주서(purchase_orders) 테이블 등이 참조하던 supplier_id 컬럼을 partner_id 로 이름 변경 및 외래키 재설정
• 기존 suppliers 테이블 및 제약조건 삭제

2. Models

• [NEW] App\Domains\Purchasing\Models\Partner 모델 생성:
  • 통합 거래처 데이터 매핑. 비밀번호 필드 캐스팅(hashed 적용 고려)
• [DELETE] App\Domains\Purchasing\Models\Supplier 모델 및 팩토리 삭제
• [MODIFY] PurchaseOrder 모델:
  • supplier_id 매핑 로직을 partner_id 와 partner() 릴레이션으로 변경

3. Filament Resources (UI/UX)

• [NEW] PartnerResource 생성:
  • 네비게이션: "환경 설정" 그룹 > "거래처 관리" 라벨 (정렬 3번)
  • ListPartners 페이지에 getTabs() 메소드를 적용하여 '공급사', '고객사' 탭으로 분리
  • 폼 구성(Form): 비밀번호 필드(생성 시 필수 아님, 수정 시 비워두면 유지), 주소/상세주소 필드 구분 배치
  • 기본적으로 공급사(Supplier) 템플릿에 준하는 리스트/필터 적용
• [DELETE] SupplierResource 전체 삭제 (기존 컨트롤러 및 파일 정리)

4. Tests & Seeders

• PurchaseOrderTest, InboundHistoryTest, ScenarioTestSeeder 등 Supplier를 참조하던 기존 테스트/시더 코드를 Partner 구조에 맞추어 partner_id 형식으로 리팩터링 및 통과 확인.

---

Verification Plan

Automated Tests

• 관련된 전체 Feature Test(php artisan test --compact) 실행하여 기존 발주(Purchase Order) 및 입고 이력에서 Supplier를 Partner로 완전히 교체 후 문제가 없는지 검증합니다.

Manual Verification

1. 환경 설정 > 거래처 관리 메뉴 접근
2. 공급사 | 고객사 탭 정상 분리 및 데이터 필터링 검증
3. 신규 거래처 등록 시 '주소/나머지 주소' 작성 및 '비밀번호' 저장 정상 확인
4. 기존에 생성된 바슈롬, 쿠퍼비전 등의 발주 데이터가 유실 없이 잘 연동되는지 확인

---

[기획] 향후 옴니채널 재고 할당(OMS) 상세 설계안

Goal Description

향후 상품 정보 대폭 수정 시 반영될 **[채널별 재고 할당 및 예약 주문 고도화]**에 대한 아키텍처 초안.

✔️ 현행 할당(/admin/allocations) 시스템의 한계점 분석 현재 시스템의 InventoryAllocation은 특정 위치(Warehouse)의 물리적 재고(Inventory) 레코드에 1:1로 결합된 allocated_qty(할당량) 방식을 띄고 있습니다. 이는 오프라인 창고 이동이나 재고 차감 시 락(Lock) 경합을 유발하고 수불 기록이 남지 않아 오류 추적이 불가능한 구조입니다.

따라서 기존의 복잡한 물리재고 종속형 누적 할당량을 완전히 폐기하고, 은행 통장 잔고(Running Balance) 모델과 수불부(Audit Trail) 개념을 도입하여 '일반 할당 재고(stock)'와 '예약 할당 재고(preorder_stock)' 모두를 완벽한 무결성으로 보장하는 새로운 재고 관리를 구현합니다.

Proposed Changes

1. 재고 모델: "통장 잔고(Running Balance)" 구조

채널별 재고 할당 테이블(channel_stocks)에는 증감 과정의 복잡한 내역 없이 오직 2개의 '현재 잔액(Balance)' 필드만 유지하여 직관성을 극대화합니다.

• stock (integer) : 일반 주문 가능 잔여량
• preorder_stock (integer) : 예약 주문(Backorder) 가능 잔여량

2. 수불부 모델: "거래 내역(Stock History)" 구조

사용자의 수기 조정, 주문에 의한 자동 차감, 취소에 의한 복구 등 **잔고가 변하는 모든 이벤트는 1원 단위까지 무조건 ChannelStockHistory 테이블에 기록(Insert Only)**됩니다.

• 발생 시각 / 작업자(또는 시스템) / 관련 채널 / 이전 잔고 / 변경 후 잔고 / 변경량(+,-) / 변경 사유 (예: 수기 리필, 주문 #1234 발생)

3. API 및 Frontend 응답 제어 로직 (주문 상태 자동화)

• stock > 0 : [바로 구매] 활성화
• stock = 0 && preorder_stock > 0 : [예약 구매] 활성화 (결제 및 상태 분리)
• stock = 0 && preorder_stock = 0 : [품절] 처리

4. 예약 주문(Pre-order) 처리 프로세스

• 예약 주문으로 수집된 건은 일반 배송 대기열과 섞이지 않도록 주문(Order) 테이블의 status나 플래그로 격리.
• 향후 창고에 실물 재고(WMS) 입고 시, 관리자가 '예약 주문' 리스트를 필터링하여 일괄 출고(송장 출력) 지시를 내릴 수 있는 UI 제공.

Verification Plan

이 구조는 **기록의 영구성(수불부)**과 **동시성 제어(LockForUpdate)**를 통해 다중 채널 쇼핑몰 동시 주문 폭주 상황에서도 '초과 판매(Overselling)' 및 데이터 꼬임을 원천 차단하는 가장 무결한 아키텍처로 기능하게 됩니다.