134 lines
4.8 KiB
Markdown
134 lines
4.8 KiB
Markdown
|
# 요구사항 정의 및 제어/데이터 흐름·UML (노션 정리)
|
|||
|
|
|
|||
|
|
> 출처: 차장님 노션. 간략 요구사항, 고정 가상계좌 제어 흐름, 데이터 흐름, UML(클래스·시퀀스), 핵심 기술 사양.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 1. 요구사항 정의 (Requirements Definition)
|
|||
|
|
|
|||
|
|
### 1.1 기본 정보 및 판매소 관리
|
|||
|
|
|
|||
|
|
- **고정 가상계좌 관리**: 지정 판매소 등록 시, 미리 확보된 가상계좌 풀에서 전용 계좌를 1:1로 매핑하여 저장.
|
|||
|
|
- **단가 및 포장 단위**: 규격별 단가(발주/도매/소매)와 박스/팩/낱장 단위의 수량을 체계적으로 관리.
|
|||
|
|
- **업체/담당자 체계**: 제작업체, 협회, 구군청 담당자의 권한과 연락처를 연동 관리.
|
|||
|
|
|
|||
|
|
### 1.2 발주 및 물류 관리
|
|||
|
|
|
|||
|
|
- **바코드 추적성**: PDF417 바코드를 활용하여 생산 LOT 번호부터 최종 불출까지의 전 과정을 추적.
|
|||
|
|
- **실시간 수불**: 스캐너를 통한 입고 처리 시 장부 재고와 실물 재고를 실시간 동기화.
|
|||
|
|
|
|||
|
|
### 1.3 주문 및 자동 정산
|
|||
|
|
|
|||
|
|
- **주문 접수**: 판매소가 웹/모바일을 통해 주문 시, 이미 할당된 판매소 전용 가상계좌를 안내.
|
|||
|
|
- **자동 입금 매칭**: 해당 전용 계좌로 주문 금액과 일치하는 금액이 입금되면, 시스템이 Webhook을 수신하여 즉시 결제 완료 처리.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 2. 제어 흐름 (Control Flow)
|
|||
|
|
|
|||
|
|
### 2.1 고정 가상계좌 기반 주문 제어 흐름
|
|||
|
|
|
|||
|
|
판매소별로 고정된 계좌가 존재하므로, 주문 시 외부 통신 없이 즉시 계좌 정보를 표시함.
|
|||
|
|
|
|||
|
|
```mermaid
|
|||
|
|
graph TD
|
|||
|
|
A[판매소: 주문 등록] --> B{재고 확인}
|
|||
|
|
B -- 재고 부족 --> C[주문 불가 안내]
|
|||
|
|
B -- 재고 있음 --> D[주문 정보 저장 및 계좌 안내]
|
|||
|
|
D --> E[입금 대기]
|
|||
|
|
E --> F{입금 확인 Webhook 수신}
|
|||
|
|
F -- 계좌번호/금액 검증 --> G{금액 일치 여부}
|
|||
|
|
G -- 불일치 --> H[입금 오류 로그 생성]
|
|||
|
|
G -- 일치 --> I[결제 완료 처리 및 출고 지시]
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 3. 데이터 흐름 (Data Flow)
|
|||
|
|
|
|||
|
|
### 3.1 결제 데이터 흐름 (Data Flow Diagram)
|
|||
|
|
|
|||
|
|
고정 계좌 모델에서의 데이터 흐름은 판매소와 계좌번호 간의 매핑.
|
|||
|
|
|
|||
|
|
```mermaid
|
|||
|
|
graph LR
|
|||
|
|
Retailer((지정판매소)) -- 1. 주문 생성 --> Server
|
|||
|
|
DB -- 2. 전용 계좌정보 반환 --> Server
|
|||
|
|
Server -- 3. 주문정보/계좌번호 안내 --> Retailer
|
|||
|
|
Retailer -- 4. 전용 계좌로 입금 --> Bank((은행/금융망))
|
|||
|
|
Bank -- 5. 입금 통보/계좌번호 포함 --> Server
|
|||
|
|
Server -- 6. 주문-계좌 매칭 및 상태갱신 --> DB
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 4. UML 상세 설계 (UML Modeling)
|
|||
|
|
|
|||
|
|
### 4.1 클래스 다이어그램 (Entity Relationship)
|
|||
|
|
|
|||
|
|
`Retailer` 엔티티가 `virtualAccountNumber`를 직접 속성으로 보유하는 구조.
|
|||
|
|
|
|||
|
|
```mermaid
|
|||
|
|
classDiagram
|
|||
|
|
class Retailer {
|
|||
|
|
+String retailerId
|
|||
|
|
+String name
|
|||
|
|
+String virtualAccountNumber
|
|||
|
|
+String bankCode
|
|||
|
|
+Boolean isActive
|
|||
|
|
}
|
|||
|
|
class Order {
|
|||
|
|
+String orderNo
|
|||
|
|
+String retailerId
|
|||
|
|
+Integer totalAmount
|
|||
|
|
+Enum status
|
|||
|
|
+DateTime orderDate
|
|||
|
|
}
|
|||
|
|
class StockTransaction {
|
|||
|
|
+Long transId
|
|||
|
|
+String prodId
|
|||
|
|
+Integer qty
|
|||
|
|
+Enum type
|
|||
|
|
}
|
|||
|
|
|
|||
|
|
Retailer "1" -- "*" Order : 주문수행
|
|||
|
|
Order "1" -- "1" StockTransaction : 재고변동기록
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 4.2 시퀀스 다이어그램 (결제 프로세스)
|
|||
|
|
|
|||
|
|
```mermaid
|
|||
|
|
sequenceDiagram
|
|||
|
|
participant R as 지정 판매소
|
|||
|
|
participant S as Server
|
|||
|
|
participant D as 데이터베이스
|
|||
|
|
participant B as PG
|
|||
|
|
|
|||
|
|
R->>S: 종량제 봉투 주문 요청
|
|||
|
|
S->>D: 판매소 정보(고정 가상계좌) 조회
|
|||
|
|
D-->>S: 계좌번호 반환
|
|||
|
|
S->>D: 주문 데이터 생성 (상태: 입금대기)
|
|||
|
|
S-->>R: 주문 완료 및 할당된 전용 계좌 안내
|
|||
|
|
Note over R,B: 판매소가 ATM/모바일로 입금
|
|||
|
|
B->>S: 실시간 입금 통보 (Webhook: 계좌번호, 금액)
|
|||
|
|
S->>D: 해당 계좌번호를 소유한 판매소의 입금대기 주문 조회
|
|||
|
|
S->>S: 입금액과 주문액 검증
|
|||
|
|
S->>D: 주문 상태 변경 (결제완료) 및 재고 차감 예약
|
|||
|
|
S-->>R: 결제 완료 알림 발송
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 5. 핵심 기술 사양
|
|||
|
|
|
|||
|
|
### 5.1 고정 가상계좌 매칭 로직
|
|||
|
|
|
|||
|
|
- **식별자**: 입금 통보 시 수신되는 `VirtualAccountNo`가 고유 식별자 역할을 함.
|
|||
|
|
- **입금 기한**: 배송 전일 23:00까지 입금되지 않은 주문은 시스템에 의해 자동 취소되거나 다음 회차로 이월됨.
|
|||
|
|
- **금액 검증**: 가상계좌 특성상 설정된 금액과 다를 경우 은행 단계에서 입금이 거부되나, 시스템 내부에서 2차 검증을 수행함.
|
|||
|
|
|
|||
|
|
### 5.2 바코드 설계 (PDF417)
|
|||
|
|
|
|||
|
|
- **데이터 구조**: 지자체(5) + 규격(3) + 연도(2) + LOT(6) + 일련번호(10).
|
|||
|
|
- **인쇄 규격**: 55mm × 20mm 사이즈 내외, Reed-Solomon 오류 정정 적용.
|