이번 단계는 재고 원장(StockTx)을 단순 기록 테이블이 아닌, 실제 운영 및 감사(Audit)에 활용 가능한 수준으로 고도화하였다.
1. 이번 단계의 핵심 목표
- 원장에 작업 직후 재고량(balance_after) 기록
- 작업자(created_by) 정보 추가
- 원장 이력 조회 API 구현
- 쓰기(StockService)와 읽기(StockTxQueryService) 분리
이로써 재고 엔진이 단순 CRUD를 넘어 운영 기준에 가까워졌다.
2. balance_after 컬럼 추가
기존에는 qty_delta(변동 수량)만 존재했다. 그러나 실무에서는 “해당 시점의 최종 재고량”이 매우 중요하다.
balance_after를 추가함으로써 다음이 가능해졌다.
- 과거 시점 재고를 즉시 확인
- 합산 계산 없이 재고 검증 가능
- 데이터 불일치 여부 빠른 점검
stockTxRepository.save(
StockTx.builder()
.item(item)
.warehouse(warehouse)
.txType(TxType.OUTBOUND)
.qtyDelta(-line.qty())
.balanceAfter(inventory.getCurrentQty())
.createdBy(null)
.refType("OUTBOUND")
.refId(outbound.getOutboundId())
.build()
);3. created_by 컬럼 추가
재고 변경은 반드시 “누가 했는지” 추적 가능해야 한다.
- 수동 조정(ADJUST) 기록
- 관리자 책임 추적
- 향후 권한 시스템 확장 기반
현재는 요청값으로 전달받는 방식이며, 향후 Spring Security 연동 시 자동 주입으로 확장할 수 있다.
4. 읽기/쓰기 서비스 분리
이번 단계에서 구조적으로 가장 중요한 개선은 Command와 Query의 분리이다.
- StockService → 재고 변경 (쓰기)
- StockTxQueryService → 이력 조회 (읽기)
이 구조는 CQRS 패턴의 간단한 형태로, 확장성과 유지보수성을 크게 향상시킨다.
5. 재고 이력 조회 API
Endpoint: GET /api/stock/tx
지원 파라미터:
- warehouseId
- itemId
- txType
- from
- to
- limit
최신순 정렬로 반환하며, 기본 limit은 100건이다.
6. 현재 시스템 구조 상태
- 입고 확정 → 재고 증가 + 원장 기록
- 출고 확정 → 재고 감소 + 원장 기록
- 조정(ADJUST) → 수동 변경 + 원장 기록
- balance_after 기록으로 시점 재고 보존
- created_by로 작업자 추적 가능
- 이력 조회 API 제공
이 시점에서 CoreERP 재고 엔진은 단순 CRUD 시스템을 넘어, 트랜잭션 기반 재고 관리 구조를 완성했다.
7. 이번 단계의 의미
“재고를 기록한다” 수준을 넘어 “재고를 운영한다” 단계로 전환된 시점이다.
이제 원장은 단순 로그가 아니라, 실제 의사결정과 감사 대응에 사용 가능한 데이터가 되었다.
8. 다음 단계
- 재고 불일치 검증 API
- StockTx 페이징 처리(Pageable)
- Reason Code 체계 설계
- Transfer(창고이동) 구현
Develop