Conversation
Walkthrough대리점과 창고 요청 유형을 구분해 처리하도록 변경: 대리점은 출고 요청을, 창고는 수신 노트 생성으로 분기. 관련 DTO명·필드 변경, 창고 클라이언트 오버로드 추가, 컨트롤러 테스트 엔드포인트 제거 및 일부 API 요약·메서드 시그니처 업데이트. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant Controller as PurchaseOrderController
participant Service as PurchaseOrderServiceImpl
participant Warehouse as WarehouseClient
User->>Controller: approveOrder(orderId)
Controller->>Service: approveOrder(orderId)
rect rgb(235,245,255)
Note over Service: requesterCode 검사
alt requesterCode contains "대리점"
Service->>Service: assignWarehouse(), createShipmentCommand()
Service->>Warehouse: create(WarehouseShippingRequest)
else requesterCode contains "창고"
Service->>Service: build ReceivingCreateNoteRequest
Service->>Warehouse: create(ReceivingCreateNoteRequest)
end
end
Warehouse-->>Service: 응답(성공/오류)
Service-->>Controller: 처리 결과
Controller-->>User: HTTP 응답
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes
Possibly related PRs
Suggested reviewers
Pre-merge checks and finishing touches❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (1 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: Path: .coderabbit.yml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
src/main/java/com/gearfirst/backend/api/order/controller/PurchaseOrderController.java(2 hunks)src/main/java/com/gearfirst/backend/api/order/infra/client/WarehouseClient.java(2 hunks)src/main/java/com/gearfirst/backend/api/order/infra/dto/ReceivingCreateNoteRequest.java(1 hunks)src/main/java/com/gearfirst/backend/api/order/infra/dto/WarehouseLineRequest.java(1 hunks)src/main/java/com/gearfirst/backend/api/order/infra/dto/WarehouseShippingRequest.java(1 hunks)src/main/java/com/gearfirst/backend/api/order/service/PurchaseOrderService.java(3 hunks)src/main/java/com/gearfirst/backend/api/order/service/PurchaseOrderServiceImpl.java(5 hunks)
🧰 Additional context used
🧠 Learnings (3)
📓 Common learnings
Learnt from: ksoheee
Repo: Gear-First/gearfirst-order-BE PR: 26
File: src/main/java/com/gearfirst/backend/api/order/controller/PurchaseOrderController.java:93-98
Timestamp: 2025-10-28T05:05:49.715Z
Learning: In the Gear-First order backend (gearfirst-order-BE) Java Spring Boot project, when an endpoint performs state changes on the PurchaseOrder entity (such as calling order.completeRepair()), ensure the endpoint's Operation summary and description clearly document that state modification occurs, and use appropriate HTTP methods (POST/PATCH/PUT) rather than GET, even if the endpoint also returns data.
📚 Learning: 2025-10-28T05:05:49.715Z
Learnt from: ksoheee
Repo: Gear-First/gearfirst-order-BE PR: 26
File: src/main/java/com/gearfirst/backend/api/order/controller/PurchaseOrderController.java:93-98
Timestamp: 2025-10-28T05:05:49.715Z
Learning: In the Gear-First order backend (gearfirst-order-BE) Java Spring Boot project, when an endpoint performs state changes on the PurchaseOrder entity (such as calling order.completeRepair()), ensure the endpoint's Operation summary and description clearly document that state modification occurs, and use appropriate HTTP methods (POST/PATCH/PUT) rather than GET, even if the endpoint also returns data.
Applied to files:
src/main/java/com/gearfirst/backend/api/order/controller/PurchaseOrderController.javasrc/main/java/com/gearfirst/backend/api/order/service/PurchaseOrderService.javasrc/main/java/com/gearfirst/backend/api/order/service/PurchaseOrderServiceImpl.java
📚 Learning: 2025-10-30T09:27:59.696Z
Learnt from: ksoheee
Repo: Gear-First/gearfirst-order-BE PR: 28
File: src/main/java/com/gearfirst/backend/api/order/service/PurchaseOrderServiceImpl.java:146-148
Timestamp: 2025-10-30T09:27:59.696Z
Learning: In the gearfirst-order-BE project, the `completeRepairAndGetParts` method in `PurchaseOrderServiceImpl` is called exclusively from the repair reception page, ensuring that the `receiptNum` parameter is always present and does not require null validation.
Applied to files:
src/main/java/com/gearfirst/backend/api/order/service/PurchaseOrderService.javasrc/main/java/com/gearfirst/backend/api/order/service/PurchaseOrderServiceImpl.java
🧬 Code graph analysis (1)
src/main/java/com/gearfirst/backend/api/order/infra/dto/ReceivingCreateNoteRequest.java (2)
src/main/java/com/gearfirst/backend/api/order/infra/dto/WarehouseLineRequest.java (1)
Getter(7-14)src/main/java/com/gearfirst/backend/api/order/infra/dto/WarehouseShippingRequest.java (1)
Getter(12-43)
src/main/java/com/gearfirst/backend/api/order/infra/dto/ReceivingCreateNoteRequest.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
src/main/java/com/gearfirst/backend/api/order/infra/dto/ReceivingCreateNoteRequest.java (1)
24-30: 라인 매핑 로직 중복을 고려해 보세요.이 매핑 로직은
WarehouseShippingRequest.from()메서드와 동일합니다. 공통 유틸리티 메서드로 추출하면 유지보수성이 향상됩니다.예시 구조:
// 새로운 유틸리티 클래스 public class WarehouseRequestMapper { public static List<WarehouseLineRequest> mapOrderItemsToLines(List<OrderItem> items) { return items.stream() .map(item -> new WarehouseLineRequest( item.getPartId(), item.getQuantity(), null )) .toList(); } }그런 다음 두 DTO에서 활용:
- List<WarehouseLineRequest> lines = items.stream() - .map(item -> new WarehouseLineRequest( - item.getPartId(), // productId - item.getQuantity(), // orderedQty - null // lineRemark (필요하면 order.note로 대체 가능) - )) - .toList(); + List<WarehouseLineRequest> lines = WarehouseRequestMapper.mapOrderItemsToLines(items);
📜 Review details
Configuration used: Path: .coderabbit.yml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/main/java/com/gearfirst/backend/api/order/infra/dto/ReceivingCreateNoteRequest.java(1 hunks)
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-10-30T09:27:59.696Z
Learnt from: ksoheee
Repo: Gear-First/gearfirst-order-BE PR: 28
File: src/main/java/com/gearfirst/backend/api/order/service/PurchaseOrderServiceImpl.java:146-148
Timestamp: 2025-10-30T09:27:59.696Z
Learning: In the gearfirst-order-BE project, the `completeRepairAndGetParts` method in `PurchaseOrderServiceImpl` is called exclusively from the repair reception page, ensuring that the `receiptNum` parameter is always present and does not require null validation.
Applied to files:
src/main/java/com/gearfirst/backend/api/order/infra/dto/ReceivingCreateNoteRequest.java
🧬 Code graph analysis (1)
src/main/java/com/gearfirst/backend/api/order/infra/dto/ReceivingCreateNoteRequest.java (2)
src/main/java/com/gearfirst/backend/api/order/infra/dto/WarehouseLineRequest.java (1)
Getter(7-14)src/main/java/com/gearfirst/backend/api/order/infra/dto/WarehouseShippingRequest.java (1)
Getter(12-43)
🔇 Additional comments (4)
src/main/java/com/gearfirst/backend/api/order/infra/dto/ReceivingCreateNoteRequest.java (4)
1-15: 임포트와 클래스 선언이 적절합니다.Lombok 어노테이션과 필요한 임포트가 올바르게 구성되어 있습니다.
32-34: requesterCode 사용으로 이전 이슈가 해결되었습니다.과거 리뷰에서 지적된 대로, 창고 발주에서는
destinationCode가 null일 수 있습니다. Line 34에서order.getRequesterCode()를 사용하여 창고 코드를 올바르게 설정하고 있습니다. 창고 사용자가 생성한 발주의 경우 요청자가 곧 창고이므로 이 접근 방식이 적절합니다.
16-21: 입고요청 DTO의 orderId 필드 설계는 의도된 것으로 보입니다.
WarehouseShippingRequest와ReceivingCreateNoteRequest는 서로 다른 WMS 엔드포인트(/api/v1/shipping,/api/v1/receiving)로 전송되며, 각각의 필드 구조가 의도적으로 다릅니다:
- WarehouseShippingRequest: 출고 관리용 - orderId 포함, branchName 사용
- ReceivingCreateNoteRequest: 입고 관리용 - orderId 미포함, requesterName 사용
현재 구조는 WMS 시스템의 입고 엔드포인트가 orderId를 필요로 하지 않는 것으로 설계되어 있습니다. 만약 실제로 필요하다면, WMS 담당팀의 API 명세 확인 후 수정하시기 바랍니다.
35-36: 발주 승인 플로우에서 processedDate는 안전합니다.코드 검증 결과,
approveOrder()메서드의 실행 순서상 NPE 위험은 없습니다:
- Line 375에서
order.decide(OrderStatus.APPROVED)호출decide()메서드 내 Line 110에서this.processedDate = LocalDateTime.now();설정- Line 388에서
ReceivingCreateNoteRequest.from(order, items)호출즉,
from()메서드가 실행될 때는 이미processedDate가 설정된 상태이므로 NPE가 발생하지 않습니다.그러나 방어적 프로그래밍 관점에서,
ReceivingCreateNoteRequest.from()메서드의 Line 36에 null 체크를 추가하는 것이 좋습니다. 이렇게 하면 향후 다른 코드 경로에서 이 메서드가 호출될 경우에도 안전합니다:order.getProcessedDate().atOffset(ZoneOffset.ofHours(9)).toString() ↓ order.getProcessedDate() != null ? order.getProcessedDate().atOffset(ZoneOffset.ofHours(9)).toString() : null
📝 Summary
Summary by CodeRabbit
릴리스 노트
새로운 기능
개선 사항
유지보수