- 다음 비즈니스 요구사항을 충족하는 API를 자유롭게 구현해 주세요.
- 모든 규칙을 정의하지 않았습니다. 생략된 부분이 있다고 생각하고 유연하게 작성해 주시면 됩니다.
- 큰 틀은 유지한 채 세부적 요구사항은 변경하셔도 됩니다.
- 변경하셨다면 변경된 부분을 기록해서 알려주세요.
- 요구사항 추가도 당연히 가능합니다.
- 별도의 개인 github 비공개 repository를 생성하고 비공개로 리뷰어 email 주소를 초대 해주시길 바랍니다.
- 리뷰가 끝나면 해당 repository는 삭제 해주시면 감사하겠습니다.
- 시험 도중 급한 사정이 생기면 알려주시길 바랍니다. 경우에 따라 일정 조정이 가능합니다.
- Test code는 작성해 주시길 바랍니다.
- 우리는 식품 유통사들에게 식자재 주문 관리 서비스를 제공하는 API 서버를 구현할려고 한다.
- 결제, 알림 같은 인프라적 부분은 구현하지 않으셔도 됩니다. 설계와 로직 구현에 집중해주세요.
- 유통사는 결제를 통해 우리 서비스를 이용할 수 있으며, 한 번의 결제에 대해 하나의 회원아이디를 만들어 준다고 가정
- 회원은 회원명, 휴대폰번호, 로그인아이디 등의 정보를 가진다.
- 회원은 로그인을 통해 우리 서비스가 제공하는 모든 기능을 이용할 수 있다.
- 회원가입 API : 초기 데이터 생성으로 대체 가능 합니다.
- 로그인 API : 스프링 시큐리티 안 쓰셔도 됩니다.
- 매입 : 상품을 가져오는 것, 물건을 사는 것
- 매출 : 상품을 보내는 것, 물건을 파는 것
- 발주 : 상품을 매입하기 위해 다른 거래처로부터 주문을 넣는 것
- 수주 : 상품을 매출하기 위해 다른 거래처로부터 주문을 받는 것
- 서비스를 사용하기 위해 유통사가 운영하는 사업자에 대한 정보를 등록해야 한다.
- 회원은 여러 사업자를 가질 수 있다.
- 사업자는 사업자명, 사업자코드, 사업자번호, 대표전화번호, 사업장주소 등의 정보를 가진다.
- 사업자명은 20자 이내의 문자열이어야 한다.
- 사업자코드는 10자 이내의 문자열이어야 한다.
- 하나의 회원 내에서 사업자코드는 유일해야 한다.
- 사업자코드는 수정이 불가능하다.
- 사업자번호는
000-00-00000형식을 가진다.
- 회원은 사업자 정보에 대한 조회/생성/수정/삭제가 가능하다.
- 사업자가 주문을 통해 상품을 거래하는 곳을 거래처라고 한다.
- 사업자는 여러 거래처를 가질 수 있다.
- 발주를 넣어서 상품을 살 수 있는 거래처를 매입처라고 한다.
- 수주를 받아서 상품을 팔 수 있는 거래처를 매출처라고 한다.
- 거래처는 거래처명, 거래처코드, 연락처 등의 정보를 가진다.
- 거래처명은 20자 이내의 문자열이어야 한다.
- 거래처코드는 8자 이내의 문자열이어야 한다.
- 거래처코드는 수정이 불가능하다.
- 하나의 사업자 내에서 거래처코드는 유일해야 한다.
- 회원은 거래처에 대한 조회/생성/수정/삭제가 가능하다.
- 주문을 하기 위한 상품에 대한 정보를 등록해야 한다.
- 사업자는 여러 상품을 가질 수 있다.
- 상품은 상품명, 상품코드 등의 정보를 가진다.
- 회원은 상품에 대한 조회/생성/수정/삭제가 가능하다.
- 사업자는 거래처에게 상품을 매입/매출하기 위해 주문을 할 수 있다.
-
주문은 (사업자, 대상거래처, 배송요청일, 접수번호)로 식별된다.
- 접수번호는 사업자, 대상거래처, 배송요청일 기준으로 등록된 순서대로 1,2,3.. 순으로 채번된다
-
주문은 수주/발주 두 종류가 있다.
- 대상거래처가 매입처이면 발주, 매출처이면 수주로 분류된다.
-
하나의 주문은 매입/매출해야 할 여러 상품을 가지는데, 이를 주문상세라 한다.
- 각 주문상세는 주문수량, 단가를 가진다.
-
수/발주 등록하기 기능 : 회원은 사업자, 대상거래처, 배송요청일을 선택해 주문을 생성할 수 있다.
- 생성된 주문을 조회/수정/삭제할 수 있다.
-
유통사 수/발주 업무 설명 예시
- A 유통사는 B 거래처로부터 주문을 전화, 메세지 등을 통해 수기로 받는다.
- 받은 주문을 우리 서비스의
수주 등록하기를 통해 등록한다. - 유통사는 수주 받은 상품을 팔기 위해 매입처로부터 발주를 넣어서 상품을 가져와야 한다(매입)
- 유통사는 자신의 상품을 직접 만들지 않고 무조건 발주를 통해 물건을 공급한다고 가정한다.
- 우리 서비스의
발주 등록하기를 통해 발주를 등록하면 거래처에 등록된 연락처로 메세지, 카카오톡 등의 알림이 전송되고, 링크를 통해 등록된 발주를 조회할 수 있게 된다.- 알림을 받은 거래처는 상품을 우리에게 준다.
- 위 발주 과정을 통해 매입된 상품으로 수주에 등록된 상품을 대상거래처에 매출한다.
-
- 회원은 각 상품에 대해 날짜별로 재고를 확인할 수 있다.
- 화면에서 사업자와 날짜를 선택하면, 사업자에 속한 상품과 상품의 날짜별재고량을 보여주는 기능
- 수주된 상품 수량은 -로, 발주된 상품 수량은 +로 계산한다.
<예시>
- 상품 A에 대한 날짜별 수주, 발주량에 따른 재고량
| 날짜 | 발주수량 | 수주수량 | 날짜별재고량 (전날재고량 + 당일발주수량 - 당일수주수량 ) |
|---|---|---|---|
| 2021-01-01 이전 | 0 | 0 | 0 |
| 2021-01-01 | 10 | 0 | 10 (0 + 10 - 0) |
| 2021-01-02 | 10 | 10 | 10 (10 + 10 - 10) |
| 2021-01-03 | 10 | 15 | 5 (10 + 10 - 15) |
| 2021-01-04 | 5 | 25 | -15 (5 + 5 - 25) |
| 2021-01-05 | 100 | 10 | 75 (-15 + 100 - 10) |
- 개략적 평가 기준
- 요구사항을 만족하는 기능을 모두 정의했는가?
- 기능을 구현하기 위한 올바른 코드 작성을 했는가?
- 구현된 기능이 정상 작동 하는가?
- 기능에 대한 테스트 코드를 잘 작성 했는가?