Odoo 구매 가이드: 요청서·RFQ·거래처 청구서·수령 처리 방법

들어가며

한 장면을 떠올려 보자: 영업이 금요일 납품을 약속했는데 계획 담당자는 목요일 밤에야 이메일로 알게 된다. 발주와 입고는 회의에 없었고, Odoo Purchase는 대화에 끼어들지 못했다. 이 가이드는 바로 그런 ‘정보의 비어 있음’을 메우기 위해 썼다.

간단한 테이블용 BOM 작성부터, 의도적으로 과장된 레벨10 생산 퍼즐 운영까지 열 가지 시나리오를 우선순위로 정해, 각 사례마다 Odoo에서 실제로 클릭해야 할 체크리스트를 제공한다.

Odoo Purchase는 현실(재고, 배치, 입출고, 생산)과 고객·회계의 기대를 연결하는 접점이다. 제대로 작동하면 수량을 다시 입력할 필요가 없다. 흐트러지면 모두가 ERP 탓을 한다.

많은 공장과 창고가 경험, 카카오톡, FINAL_v3 같은 엑셀 탭으로 굴러간다. 그 상태로 버티다 확장하거나 추가 사이트가 생기거나 추적감사가 들어오면 문제들이 솟아오른다.

Purchase는 Odoo 모듈식 ERP의 한 축이다. 명확한 역할 분담, 반복 가능한 워크플로, 검색 가능한 이력이 필요할 때 팀이 선택한다. ‘요청 → RFQ → 공급사 청구서 → 입고’라는 스토리라인이 예산 승인자들에게 신뢰를 준다.

Purchase로 실제 물류 흐름을 모델링하라: 수령→보관→차출→제조→출하→폐기→보충. 각 단계가 기록으로 남아 미래의 당신이 고맙게 여길 것이다.

이 글에서는 첫 BOM 작성에서부터 현장 바코드 적용까지, 실제 기업 사례를 곁들여 열 가지 활용 사례를 설명한다.

주 대상은 운영 이사, 창고 책임자, 생산 계획자다. 개발자는 이후에 합류해도 된다 — 우선 언어는 비즈니스 관점이다.

이 문서는 난이도별로 1단계(쉬움)부터 10단계(전문가)까지 순위를 매긴 Top 10이다. 각 레벨에는 Odoo에서 실제로 클릭할 번호 매긴 단계들이 포함되어 있다.

인상 때문에 10단계부터 시작하지 말고, 현재 편한 단계부터 시작하라.

다음으로 ‘직면한 문제’ 섹션을 읽고, 팀 현실에 맞는 레벨을 열어보라.

이 가이드에서 확인할 내용:

• 일반적인 회사 기술 스택에서 Odoo Purchase가 맡는 역할
• 현재 팀들이 가장 많이 겪는 마찰 지점(그리고 그 이유)
• 초급 규율에서 고급 전략까지의 열 가지 우선순위 활용 사례
• 자동화나 시스템 연동 때문에 파트너가 필요해지는 시점

직면한 문제

영업이 금요일 납기 약속을 잡는다. 그런데 계획 담당자는 목요일 저녁에야 이메일에서 그 주문을 발견한다 — 이메일 안에만 있었고 Odoo Purchase에는 기록이 없었다. 급행 수수료가 마진을 갉아먹고, 회계는 월말에야 재고 차이를 발견한다.

현장에서는 경험으로 버티지만 재고와 생산 정보가 Odoo 밖에 흩어져 있으면 품절·긴급 발주·월말 깜짝 손실이 자주 발생한다.

익숙한가? 보통 팀들은 이런 벽에 부딪힌다:

• 영업이 약속한 수치와 일치하지 않는 재고 파일
• 실시간 수량 없이 세운 생산 또는 구매 계획
• 고객이나 감사인이 물어볼 때 드러나는 추적 불일치

좋은 소식은 모든 것을 한 번에 바꿀 필요가 없다는 것이다. 아래 활용 사례 중 하나를 골라 30일간 Odoo Purchase로 운영해보고 변화를 측정해라.

상위 10가지 Purchase 활용 사례

Odoo Purchase용 10가지 활용 사례를 난이도별로 정리했다. 각 항목은 ‘무엇을 구축할 것인가’와 ‘Odoo에서 실제로 무엇을 클릭할 것인가’를 답한다.

1단계는 오늘 오후에 바로 실행 가능한 단기 승리다. 마지막 레벨은 일부러 극단적으로 설정해 동일한 앱이 깔끔한 아키텍처와 데이터로 얼마나 확장 가능한지 보여준다.

자신의 수준을 골라 테스트 DB에서 번호 매긴 단계를 따라해 보고, 이전 레벨이 지루해지면 다음 단계로 올라가라.

1. 단일 공급사에 첫 RFQ 보내기 Level 1 — 쉬움

레벨 1은 가능한 한 단순한 구매 행동이다: 구매자 한 명, 공급사 한 곳, 제품 한 줄. 계약·승인·재고 규칙은 없이 RFQ를 이메일로 깔끔하게 발송하는 것에 집중한다.

Odoo에서 실제로 하는 법:

1. Purchase 앱을 설치한 뒤 Purchase → Vendors → New로 가서 공급사 이름·이메일·결제조건을 등록한다.
2. Purchase → Requests for Quotation → New에서 공급사를 선택하고 필요한 수량의 제품 한 줄을 추가한다.
3. Order Deadline을 설정하고 배송 주소를 확인한 뒤 Send by Email을 눌러 공급사에 RFQ PDF를 전송한다.
4. 공급사가 가격을 확인하면 라인을 수정한 뒤 Confirm Order를 눌러 RFQ를 주문서로 전환한다.
5. 채터(chatter)를 열어 누가 RFQ를 보냈고 누가 확인했으며 언제 PO가 생성됐는지 타임라인을 확인한다.

얻는 것: 모든 구매에 번호·날짜·공급사 확인·추적 가능한 이메일 기록이 남아 회계가 주문 출처를 다시 묻지 않는다.

2. PO 확정 후 도크에서 물량 수령하기 Level 2 — 쉬움

레벨 2는 ‘입고’ 개념을 도입한다. 구매자가 창고에 넘기면 창고는 PO와 실제 도착 수량을 한 번의 클릭으로 확인한다.

Odoo에서 실제로 하는 법:

1. 확정된 Purchase Order를 열고 Receipt 스마트 버튼을 눌러 연결된 입고 전표로 이동한다.
2. 도크에서 창고 사용자는 Inventory → Operations → Transfers → To Process로 가서 해당 전표를 선택한다.
3. 라인별로 실제 입고 수량을 입력한다. 예: 80 대신 78개 도착하면 78을 입력하고 채터에 내부 메모를 남긴다.
4. Validate를 클릭하면 Odoo가 재고를 갱신하고 입고를 PO에 자동으로 연결한다.
5. PO를 다시 열면 각 라인의 Received 수량이 업데이트되어 다음 단계인 공급사 청구서 확인 준비가 된다.

얻는 것: 창고와 구매자가 동일한 수치를 읽는다. 부분 납품이나 미달이 즉시 드러나 월말까지 묻히지 않는다.

3. PO에서 바로 공급사 청구서(Vendor Bill) 등록하기 Level 3 — 쉬움

레벨 3은 청구서 처리이다. 회계는 PO 데이터를 재사용해 청구서를 재입력할 필요가 없어, 동일한 라인·단가·세금으로 빠르게 청구서를 올릴 수 있다.

Odoo에서 실제로 하는 법:

1. 확정된 Purchase Order를 열고 상단의 Create Bill을 클릭한다.
2. Odoo가 PO의 모든 라인을 미리 채운 초안 Vendor Bill을 연다: 제품·수량·단가·세금.
3. Bill Date, Bill Reference(공급사 인보이스 번호), Due Date를 설정하고 이메일로 받은 PDF를 첨부한다.
4. Confirm을 눌러 청구서를 게시하면 분개가 매입채무와 적절한 비용 혹은 재고 계정으로 기록된다.
5. 지급 기일에 Register Payment를 눌러 은행이체를 기록하면 회계 루프가 닫힌다.

얻는 것: 청구서는 1분 내에 입력되고 PDF를 다시 타이핑할 필요가 없으며, 모든 지출이 승인된 PO 라인과 연결된다.

4. 제품별 수량별 할인 단가표 만들기 Level 4 — 중간

레벨 4는 구매 전용 기능을 도입한다: 가격이 제품과 공급사에 따라 자동으로 따라다니도록 설정해 누군가의 기억이나 잊힌 스프레드시트에 의존하지 않는다.

Odoo에서 실제로 하는 법:

1. 제품을 열고 Purchase 탭에서 Vendors → Add로 가서 공급사를 추가하고 가격·최소주문수량·리드타임·통화를 입력한다.
2. 같은 공급사 라인에서 수량 브레이크를 추가한다: 1+는 가격 A, 50+는 가격 B, 100+는 가격 C 같은 식으로.
3. 이 제품을 공급할 다른 공급사 2~3곳에도 동일하게 추가하고 우선순위를 정한다.
4. 새 RFQ를 열면 공급사와 주문 수량에 따라 단가가 자동으로 채워진다.
5. Purchase → Reporting → Purchase Analysis에서 Vendor와 Product로 그룹화해 실제 지불액과 협상가격을 비교한다.

얻는 것: 협상한 가격이 모든 RFQ에 자동 반영되며 연간 재협상은 추정치 대신 실제 거래량 데이터를 기반으로 시작된다.

5. Approvals 앱으로 직원 구매요청 접수하기 Level 5 — 중간

레벨 5는 구매 요청의 첫 축을 설명한다: 조직 내 누구나 필요를 요청하면 구매 담당자가 RFQ로 전환할지를 결정하고 모든 감사 흔적은 Odoo에 남는다.

Odoo에서 실제로 하는 법:

1. Approvals를 설치한 뒤 Approvals → Configuration → Approval Types → New로 들어가 Purchase Request 타입을 만든다.
2. Has Product와 Has Quantity를 활성화해 요청자가 필요한 항목과 희망 납기를 명확히 적게 한다.
3. 승인자는 직속 관리자, 그다음 구매팀장 순으로 설정하고, 일정 금액 이상이면 재무 승인도 거치게 한다.
4. 직원이 Approvals → New → Purchase Request를 선택해 양식을 작성·제출하면 지정된 승인자들에게 알림이 간다.
5. 승인되면 구매 담당자는 Purchase → Requests for Quotation → New를 열어 요청 라인을 붙여 실제 RFQ를 발행한다.

얻는 것: 흩어진 슬랙 메시지와 이메일 요청이 사라지고, 모든 수요가 기록·우선순위화되어 재작업 없이 PO로 전환된다.

6. 세 공급사 견적을 비교하는 Call for Tenders 협정 만들기 Level 6 — 중간

레벨 6은 Purchase Agreements로 조달 결정을 문서화한다. 세 곳에 RFQ를 보내고 돌아온 답변을 나란히 놓고 데이터 기반으로 낙찰자를 선택한다.

Odoo에서 실제로 하는 법:

1. Purchase → Orders → Purchase Agreements → New로 가서 Type을 Call for Tenders로 설정하고 마감일을 지정한다.
2. 경쟁 견적을 받고 싶은 목표 수량을 제품 라인으로 추가한다.
3. New Quotation을 클릭하면 공급사를 선택해 해당 협정과 연결된 초안 RFQ가 생성된다.
4. 다른 공급사에 대해서도 반복하면 협정 화면에 공급사별 가격이 라인별로 나란히 표시된다.
5. 낙찰자를 골라 그 RFQ를 PO로 전환하고, 나머지는 Lost Reason과 함께 보관한다.

얻는 것: 조달 결정이 근거 있게 남는다. 6개월 뒤 누군가 다시 열어보면 누가 얼마를 제시했고 왜 특정 공급사가 선택됐는지 알 수 있다.

7. 3자 대조(PO·입고·청구서)로 공급사 과청구 막기 Level 7 — 어려움

레벨 7은 네 가지 축을 연결한다: PO, 입고, 청구서가 일치해야만 지급된다. 회계팀이 실질적으로 비용을 절감하는 지점이다.

Odoo에서 실제로 하는 법:

1. Purchase → Configuration → Settings로 가서 Bill Control을 Received Quantities로 설정하고 저장한다.
2. 80개 주문을 확정했는데 창고에서 78개만 수령해 부분 입고를 검증한다.
3. 회계는 PO에서 청구서를 생성하면 Odoo가 수령된 78개로 초안을 채운다(80이 아니라).
4. 공급사가 80개 청구서를 보내면 불일치가 즉시 보이고, 구매 담당자는 크레딧 노트를 요청한 뒤 청구서를 게시한다.
5. 입고와 청구가 일치하고 나서야 Confirm 버튼이 활성화되고, 지급 스케줄러가 만기 시점을 잡아 지급을 진행한다.

얻는 것: 공급사 과청구가 은밀히 흡수되지 않는다. 지급된 모든 금액은 PO 라인과 입고로 뒷받침되어 감사 준비가 된다.

8. 재주문 규칙, MTO, 스케줄러로 수요 주도 조달 운영하기 Level 8 — 어려움

레벨 8은 Purchase를 Sales·Inventory의 실제 수요 신호와 연결한다. Odoo가 재고 소진 전에 적절한 RFQ를 제안해 구매자의 소방수 역할을 줄인다.

Odoo에서 실제로 하는 법:

1. 베스트셀러 제품에 대해 Inventory → Operations → Reordering Rules → New로 가서 Min·Max·Vendor·Lead Time을 설정한다.
2. 주문 제작(ETO) 제품에는 제품의 Purchase 탭에서 Route를 Make To Order로 설정해 확정된 판매가 RFQ를 자동으로 트리거하게 한다.
3. Inventory → Operations → Run Scheduler를 매일 수동 실행하거나 서버 액션으로 예약해 매일 아침 제안이 뜨게 한다.
4. Purchase → Orders → Requests for Quotation에서 Draft Auto 필터를 걸어 제안된 RFQ를 일괄로 실제 주문으로 전환한다.
5. Purchase → Reporting → Vendor On-Time Delivery를 활용해 분기별로 리드타임을 조정한다(실제 퍼포먼스 기반).

얻는 것: 핵심 SKU의 품절이 급감하고, 구매자는 협상에 집중하며 영업은 운영이 감당할 수 없는 납기를 잘 약속하지 않는다.

9. 연간 블랭킷 오더(Blanket) 고정 및 전략적 공급사를 위한 벤더 포털 열기 Level 9 — 어려움

레벨 9는 조달을 확장한다: 연간 약정은 한 번 협상하고 주차별로 소진하며, 주요 공급사들은 자체 포털에서 RFQ를 확인하고 청구서를 업로드한다.

Odoo에서 실제로 하는 법:

1. Purchase → Orders → Purchase Agreements → New로 가서 Type을 Blanket Order로, 연간 유효기간·협상 가격·총 약정 수량을 설정한다.
2. 매주 해당 협정을 열어 New Purchase Order를 클릭해 필요한 수량을 호출하면 Odoo가 남은 약정을 차감한다.
3. Settings → General Settings에서 고객·공급사 포털 액세스를 활성화하고 전략적 공급사들에 포털 권한을 부여한다.
4. 공급사는 /my/purchase로 로그인해 RFQ를 승인·거절하고 서명 청구서를 업로드하며 결제 상태를 실시간으로 확인한다 — 구매자에게 이메일할 필요가 없다.
5. Purchase Reporting에서 벤더 성과 점수표를 만들어 정시납품·가격변동·불량률을 분기별로 갱신해 QBR(분기 비즈니스 리뷰)에 활용한다.
6. 블랭킷 오더의 연간 소비가 80%를 넘으면 서버 액션으로 조달팀에 자동 이메일을 보내 소진을 알린다.

얻는 것: 주요 20% 공급사에 대한 반복 조달은 자동화되어 구매자는 소싱·협상·공급 리스크 관리에 시간을 재투자할 수 있다.

블랭킷 오더 규칙 설계, 포털 권한 설정, 크로스앱 성과대시보드 구성은 다솔로가 파트너로서 수행하는 전형적인 교차 기능 프로젝트다.

10. OCR 청구서, EDI, 이상감지, 실시간 대시보드로 AI 기반 조달 운영체계 만들기 Level 10 — 전문가

레벨 10은 완전한 운영체계다: AI가 청구서를 읽고, EDI가 핵심 공급사와 시스템 간 기계 대 기계 연결을 하고, 이상 감지가 리스크 주문을 표시하며, 실시간 대시보드가 회사 전체의 약정을 추적한다.

Odoo에서 실제로 하는 법:

1. Accounting에서 Bill Digitization을 활성화하면 인보이스 PDF가 OCR로 자동 파싱되고 라인·세금·PO 링크가 회계 검토 전에 미리 채워진다.
2. 핵심 5개 공급사에는 EDI 교환(XML, EDIFACT, Peppol 등)을 구축해 PO·ASN·Invoice가 Odoo와 공급사 ERP 간에 자동으로 흐르게 한다.
3. 공급 계약, 블랭킷 오더, 카탈로그 등 지식베이스로 AI 조달 어시스턴트를 학습시켜 구매자 질문에 다국어로 답하도록 한다.
4. Studio Automations와 AI 이상 규칙을 사용해 비정상 주문을 플래그한다: 8% 이상의 가격 급등, 리드타임 급증, 단일 소스 의존, 예상치 못한 MOQ 증가 등.
5. Purchase를 Sales·Inventory·Accounting·Project와 연결해 모든 변경이 전파되게 한다: 공급사 청구서 지급이 프로젝트 비용 업데이트와 대시보드 새로고침을 트리거한다.
6. 스프레드시트형 조달 콕핏을 만들자: RFQ·지연 PO·3자 불일치·절감액 대비 기준·공급사별 정시납품률을 실시간으로 갱신한다.
7. Slack이나 Teams 알림을 연결해 핵심 이벤트 발생 시(상위 고객 주문의 지연, 임계값 초과 청구 불일치, 블랭킷 오더 소진 등) 즉시 통보받는다.

얻는 것: 조달이 단순한 백오피스 비용이 아니라 실시간 데이터, 예측 알림, 구매자별 AI 코파일럿을 가진 전략적 기능으로 바뀐다.

AI 조달 코파일럿, EDI 연결, 이상 감지 규칙, 실시간 콕핏 대시보드를 설계·구현하는 작업은 다솔로가 파트너로서 구성해 다분기 시행착오를 건너뛰게 해준다.

전문가 도움이 필요한 경우

레벨 1~6이 여러분 현실이라면 표준 Odoo Purchase, 인내심 있는 내부 오너, 그리고 사람들이 안전하게 실험할 수 있는 샌드박스만으로도 충분히 성공할 수 있다.

레벨 7 이상부터는 판이 달라진다: 잘못된 고객에게 자동 이메일이 가는 워크플로, 업그레이드를 막는 Studio 필드, 새벽 2시에 재고 동기화가 멈추는 API 같은 자동화 리스크가 커진다.

이것은 팀의 실패가 아니다. 아키텍처·테스트·거버넌스가 중요한 신호다.

멀티앱 설계, 국가별 규정 준수, 복잡한 통합, 혹은 이사회가 정해놓은 런치 데이트가 있고 그 일정에 맞춰야 한다면 파트너의 도움이 필요하다.

다솔로와 함께하기

다솔로는 기업이 실제로 일하는 방식대로 Odoo를 구현한다: 맞춤 앱, 깔끔한 연동, 컨설턴트가 떠난 뒤에도 사람들이 기억하는 교육까지 제공한다.

Purchase 로드맵이 이 가이드의 고급 사용 사례를 포함한다면 단계별 계획을 그려 드린다: 먼저 빠른 성과, 그다음 자동화·연동을 명확한 책임자와 테스트 시나리오로 진행한다.

예산과 범위 관리는 고객이 유지한다. 다솔로는 Odoo 전문성을 제공해 현장 운영에서 값비싼 교훈을 반복하지 않게 한다.

무료 상담 예약:

데모 일정을 잡으세요