## 구현 내용 ### 1. 백엔드 (app.py) - 수동 로트 배분 지원 (lot_assignments 배열 처리) - 각 로트별 지정 수량만큼 재고 차감 - 검증: 배분 합계 확인, 재고 충분 확인 - compound_consumptions 테이블에 각 로트별 소비 기록 ### 2. 프론트엔드 (app.js, index.html) - 로트 배분 모달 UI 구현 - 로트별 재고, 단가 표시 - 수동 입력 및 자동 배분 기능 - 실시간 합계 계산 및 검증 - 원산지 선택에 "수동 배분" 옵션 추가 (로트 2개 이상 시) - 조제 저장 시 lot_assignments 포함 ### 3. 테스트 - 테스트용 당귀 로트 추가 (한국산) - E2E 테스트 성공 - 당귀 100g을 2개 로트(중국산 60g + 한국산 40g)로 배분 - 각 로트별 재고 정확히 차감 - 소비 내역 올바르게 기록 ## 장점 - DB 스키마 변경 없음 - 기존 자동 선택과 호환 - 재고 부족 시 여러 로트 조합 가능 - 원가 최적화 가능 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
167 lines
4.9 KiB
Markdown
167 lines
4.9 KiB
Markdown
# 복합 로트 사용 기능 구현 분석
|
|
|
|
## 1. 현재 시스템 구조
|
|
|
|
### 1.1 좋은 소식 - 이미 지원 가능한 구조
|
|
현재 `compound_consumptions` 테이블은 **이미 복합 로트를 지원할 수 있는 구조**입니다:
|
|
|
|
```sql
|
|
compound_consumptions (
|
|
consumption_id INTEGER PRIMARY KEY,
|
|
compound_id INTEGER,
|
|
herb_item_id INTEGER,
|
|
lot_id INTEGER,
|
|
quantity_used REAL,
|
|
unit_cost_per_g REAL,
|
|
cost_amount REAL
|
|
)
|
|
```
|
|
|
|
**핵심 포인트:**
|
|
- 한 조제(`compound_id`)에서 같은 약재(`herb_item_id`)에 대해 여러 레코드 생성 가능
|
|
- 각 레코드는 다른 `lot_id`를 가질 수 있음
|
|
- 즉, **DB 구조 변경 없이** 복합 로트 사용 가능
|
|
|
|
### 1.2 현재 백엔드 로직
|
|
`app.py`의 조제 생성 로직을 보면:
|
|
```python
|
|
# 이미 FIFO 방식으로 여러 로트를 순차 소비하는 로직이 구현되어 있음
|
|
for lot in available_lots:
|
|
lot_id = lot[0]
|
|
available = lot[1]
|
|
unit_price = lot[2]
|
|
|
|
used = min(remaining_qty, available)
|
|
|
|
# 각 로트별로 별도의 소비 레코드 생성
|
|
cursor.execute("""
|
|
INSERT INTO compound_consumptions (compound_id, herb_item_id, lot_id,
|
|
quantity_used, unit_cost_per_g, cost_amount)
|
|
VALUES (?, ?, ?, ?, ?, ?)
|
|
""", (compound_id, herb_item_id, lot_id, used, unit_price, cost))
|
|
```
|
|
|
|
**즉, 백엔드는 이미 복합 로트를 지원하고 있습니다!**
|
|
|
|
## 2. 필요한 개선 사항
|
|
|
|
### 2.1 프론트엔드 UI/UX 개선
|
|
현재 문제는 **프론트엔드에서 복합 로트 선택을 지원하지 않는 것**입니다.
|
|
|
|
#### 현재 상태:
|
|
- 약재별로 "자동 선택" 또는 단일 원산지/로트만 선택 가능
|
|
- 수동으로 여러 로트를 조합할 수 없음
|
|
|
|
#### 개선 방안:
|
|
1. **자동 모드 (현재 구현됨)**
|
|
- FIFO 방식으로 자동 할당
|
|
- 재고가 부족하면 다음 로트에서 자동 보충
|
|
|
|
2. **수동 모드 (구현 필요)**
|
|
- 약재별로 "로트 배분" 버튼 추가
|
|
- 모달 창에서 사용 가능한 로트 목록 표시
|
|
- 각 로트별 사용량 수동 입력
|
|
- 예: 로트A 40g + 로트B 60g = 총 100g
|
|
|
|
### 2.2 API 개선
|
|
현재 API 구조:
|
|
```javascript
|
|
{
|
|
"herb_item_id": 52,
|
|
"grams_per_cheop": 4.8,
|
|
"origin": "auto", // 또는 특정 원산지
|
|
"lot_assignments": [] // 현재 미사용
|
|
}
|
|
```
|
|
|
|
개선된 API 구조:
|
|
```javascript
|
|
{
|
|
"herb_item_id": 52,
|
|
"grams_per_cheop": 4.8,
|
|
"origin": "auto" | "manual",
|
|
"lot_assignments": [ // manual일 때 사용
|
|
{"lot_id": 123, "quantity": 40},
|
|
{"lot_id": 124, "quantity": 60}
|
|
]
|
|
}
|
|
```
|
|
|
|
## 3. 구현 방안
|
|
|
|
### 3.1 최소 변경 방안 (권장)
|
|
**DB 스키마 변경 없이** 프론트엔드와 백엔드 로직만 개선:
|
|
|
|
1. **백엔드 (app.py)**
|
|
- `origin: "manual"`일 때 `lot_assignments` 배열 처리
|
|
- 지정된 로트별로 소비 처리
|
|
- 검증: 총량 일치 확인, 재고 충분 확인
|
|
|
|
2. **프론트엔드 (app.js)**
|
|
- 로트 배분 모달 추가
|
|
- 사용 가능 로트 목록 표시 (재고, 단가, 원산지 정보)
|
|
- 로트별 사용량 입력 UI
|
|
- 실시간 합계 및 검증
|
|
|
|
### 3.2 영향도 분석
|
|
|
|
#### 영향 없는 부분:
|
|
- ✅ DB 스키마 (변경 불필요)
|
|
- ✅ 재고 관리 로직
|
|
- ✅ 원가 계산 로직
|
|
- ✅ 입출고 원장
|
|
- ✅ 조제 내역 조회
|
|
|
|
#### 수정 필요한 부분:
|
|
- ⚠️ 조제 생성 API (`/api/compounds` POST)
|
|
- ⚠️ 프론트엔드 조제 화면
|
|
- ⚠️ 로트 가용성 확인 API (수동 모드 지원)
|
|
|
|
## 4. 구현 우선순위
|
|
|
|
### Phase 1: 백엔드 지원 (필수)
|
|
1. API에서 `lot_assignments` 처리 로직 추가
|
|
2. 수동 로트 배분 검증 로직
|
|
3. 트랜잭션 안전성 확보
|
|
|
|
### Phase 2: 프론트엔드 기본 (필수)
|
|
1. 로트 배분 모달 UI
|
|
2. 수동 입력 폼
|
|
3. 실시간 검증 및 피드백
|
|
|
|
### Phase 3: UX 개선 (선택)
|
|
1. 드래그 앤 드롭으로 로트 배분
|
|
2. 자동 최적화 제안 (단가 최소화, FIFO 등)
|
|
3. 로트 배분 히스토리 저장 및 재사용
|
|
|
|
## 5. 예상 시나리오
|
|
|
|
### 시나리오 1: 재고 부족으로 인한 복합 사용
|
|
- 감초 100g 필요
|
|
- 로트A(한국산): 40g 재고, 20원/g
|
|
- 로트B(중국산): 70g 재고, 15원/g
|
|
- 수동 배분: 로트A 40g + 로트B 60g
|
|
|
|
### 시나리오 2: 원가 최적화
|
|
- 당귀 100g 필요
|
|
- 로트A(구재고): 80g, 10원/g
|
|
- 로트B(신재고): 50g, 15원/g
|
|
- 원가 최적화: 로트A 80g + 로트B 20g
|
|
|
|
### 시나리오 3: 품질 균일성
|
|
- 인삼 100g 필요
|
|
- 같은 원산지의 다른 로트들 조합
|
|
- 품질 일관성 유지
|
|
|
|
## 6. 결론
|
|
|
|
**좋은 소식: 현재 시스템은 이미 복합 로트를 지원할 수 있는 구조입니다!**
|
|
|
|
- DB 스키마 변경 불필요
|
|
- 백엔드는 일부 로직 추가만 필요
|
|
- 주로 프론트엔드 UI/UX 개선이 필요
|
|
|
|
**구현 난이도: 중간**
|
|
- 기존 시스템에 미치는 영향 최소
|
|
- 점진적 구현 가능 (자동 모드는 이미 작동 중)
|
|
- 수동 모드는 선택적 기능으로 추가 가능 |