소개
Odoo에서 ‘모델’은 데이터가 데이터베이스에 어떻게 저장되고 조직되는지를 규정하는 설계도입니다. 구매 주문, 송장, 재고 같은 모든 비즈니스 정보는 각각의 모델 안에서 구조화되어 관리됩니다.
모델을 이해하는 것은 개발자와 컨설턴트 모두에게 필수입니다. 모델은 필드 구조, 관계, 그리고 비즈니스 규칙을 정의해 시스템 동작의 기초가 됩니다.
이 글은 Odoo에서 핵심적인 모델 중 하나인 purchase.order에 초점을 맞춥니다. 맞춤 모듈을 개발하거나 외부 시스템과 연결하거나 조달 프로세스를 설정할 때 이 모델을 자주 마주하게 됩니다.
purchase.order 모델이란 무엇인가
purchase.order 모델은 Odoo에서 구매 요청(RFQ)과 구매주문(PO)을 표현합니다. 입고나 매입청구서 생성 전 모든 조달 거래가 이 모델에 기록됩니다.
구매 모듈을 통해 사용됩니다. 구매 담당자가 RFQ를 작성하면 purchase.order 레코드가 생성되고, 공급사가 확인하거나 구매자가 승인하면 상태가 draft에서 confirmed로 바뀝니다. 같은 모델이 초안 RFQ와 확정된 PO를 모두 담고 있으며 state 필드로 생명주기를 관리합니다.
다른 모듈들은 Odoo의 모델 상속을 통해 이 모델을 확장합니다. 재고 모듈은 입고·송장 처리 로직을 추가하고, 회계는 매입청구서 관련 필드를 더하며, 제조는 자재소요에 따라 주문을 생성합니다. 핵심 구조는 중복 없이 확장됩니다.
모델의 주요 필드
다음은 purchase.order 모델에서 특히 자주 사용하는 핵심 필드들입니다. 이들을 이해하면 구매 업무와 개발 모두에서 효율적으로 작업할 수 있습니다.
1. name
형식: Char. 주문 참조(예: PO00042)를 저장합니다. 보통 자동 생성되어 목록과 문서에 표시되며, 주문 식별자로 널리 사용됩니다.
2. state
형식: Selection. 주문의 단계(생명주기)를 관리합니다. 주요 값: draft(RFQ), sent(공급사에 전송), to approve(승인 대기), purchase(확정), done(입고·청구 완료), cancel(취소). 상태에 따라 가능한 액션이 달라집니다.
3. partner_id
형식: Many2one(res.partner). 공급업체(벤더)를 가리키는 필수 필드입니다. 주문 관련 연락처와 회사 정보를 연결해 보고 및 로직에 사용됩니다.
4. partner_ref
형식: Char. 공급사가 제공한 참조번호(벤더 PO 번호)입니다. 문서에 표시되어 입고·청구서 매칭에 도움을 줍니다.
5. date_order
형식: Datetime. 주문 일자입니다. 초안인 경우 생성일, 확정되면 확정일로 사용되며 리포팅·정렬·예상 납기 기본값 등에 활용됩니다.
6. date_approve
형식: Datetime. 승인 또는 확정 일시를 기록합니다. 주문이 purchase 상태로 변경될 때 설정되며 읽기 전용으로 감사 추적에 사용됩니다.
7. order_line
형식: One2many(purchase.order.line). 주문행들입니다. 각 행에는 제품, 수량, 단가, 세금 정보가 있고, 구매 주문의 핵심 상세 정보를 담고 있습니다.
8. amount_untaxed
형식: Float. 세금 제외 소계입니다. 주문행에서 계산되며 리포팅과 화면 표시용으로 사용됩니다.
9. amount_tax
형식: Float. 총 세액입니다. 세금 설정에 따라 주문행에서 계산되어 주문과 매입청구서에 표시됩니다.
10. amount_total
형식: Float. 세금 포함 총액으로 청구·회계 리포트의 주요 금액입니다.
11. currency_id
형식: Many2one(res.currency). 통화입니다. 보통 회사나 공급사에서 물려받으며 금액 필드 전부에 적용됩니다.
12. origin
형식: Char. 주문의 출처 문서입니다. 예를 들어 판매 주문(드롭쉽)이나 제조 오더에서 생성된 경우 원본 이름이 저장되어 추적에 사용됩니다.
13. dest_address_id
형식: Many2one(res.partner). 배송지 주소입니다. 설정되지 않으면 회사 주소가 기본이며, 드롭쉽 시 고객 주소로 설정되어 공급사가 직접 배송하도록 합니다.
14. priority
형식: Selection. 주문 우선순위(보통 Normal 또는 Urgent). 정렬·강조 표시용이며 우선순위에 따라 워크플로우 처리 방식이 달라질 수 있습니다.
15. invoice_status
형식: Selection. 청구 진행 상태를 나타냅니다: no(미청구), to invoice(청구 대상), invoiced(완전 청구). 매입청구서 생성 버튼 노출 여부에 영향합니다.
16. invoice_count
형식: Integer. 관련 매입청구서 수를 계산해 보여줍니다. 클릭하면 청구서 목록으로 이동할 수 있습니다.
17. invoice_ids
형식: One2many(account.move). 연결된 매입청구서들입니다. 구매와 회계를 연결해 삼자대조 및 결제 추적에 사용됩니다.
18. picking_ids
형식: One2many(stock.picking). 입고·출고 관련 운송문서(송장)들입니다. 재고 모듈과 함께 사용될 때 연결됩니다.
19. picking_count
형식: Integer. 관련 픽킹 수를 계산해 표시합니다. 클릭하면 입고 목록으로 이동합니다.
20. create_date
형식: Datetime. 레코드 생성 시각을 자동으로 저장합니다. 리포팅·감사 추적에 유용합니다.
21. write_date
형식: Datetime. 마지막 수정 시각을 자동으로 저장합니다. 데이터 갱신 시점을 추적하는 데 쓰입니다.
22. notes
형식: Text. 공급사에 전달할 약관이나 내부 메모를 저장합니다. 특별 지시사항을 문서에 표시할 때 사용됩니다.
23. company_id
형식: Many2one(res.company). 멀티컴퍼니 환경에서 이 주문이 속한 회사를 가리킵니다. 가시성과 접근 권한에 영향을 줍니다.
24. user_id
형식: Many2one(res.users). 구매 담당자 또는 담당 사용자입니다. 승인 흐름과 활동 할당에 사용됩니다.
25. fiscal_position_id
형식: Many2one(account.fiscal.position). 세금 매핑을 위한 회계적 포지션입니다. 국경 간 거래나 특수 과세 대상인 경우 적용됩니다.
26. payment_term_id
형식: Many2one(account.payment.term). 결제 조건(예: Net 30, 선금 50%)으로 매입청구서 생성 시 반영됩니다.
27. display_name
형식: Char. 계산된 표시 이름으로 주문 참조와 공급사 정보를 결합하여 many2one 드롭다운과 검색 결과에 읽기 전용으로 표시됩니다.
28. active
형식: Boolean. 소프트 삭제 플래그입니다. False이면 아카이브되어 기본 뷰에서 숨겨집니다. 기록 보존을 위해 물리적 삭제 대신 아카이브를 권장합니다.
업무 흐름에서 이 모델의 활용 방식
1. RFQ에서 구매주문으로 전환되는 흐름
구매 담당자는 RFQ(초안)를 생성해 주문행을 추가하고 공급사에 전송합니다. 공급사가 확인하거나 내부 승인 절차를 거치면 상태가 확정(purchase)으로 전환되고 이후 입고와 매입청구서를 생성할 수 있습니다.
2. 공급사로부터의 입고 처리
상품이 도착하면 purchase.order에서 입고 문서를 생성합니다. 관련 picking_ids가 연결되고 수취 수량은 재고에 반영됩니다. 또한 제품 원가는 구매 단가로 업데이트됩니다.
3. 매입청구서 처리
확정된 주문에서 매입청구서를 생성하면 주문행의 항목들이 청구서로 옮겨집니다. 결제조건과 회계 포지션도 주문에서 가져오며 invoice_status는 청구 진행 상황을 관리합니다.
4. 드롭쉽(직송) 시나리오
판매 주문이 구매를 촉발할 경우 origin 필드에 판매 주문이 남아 추적이 가능하고 dest_address_id는 고객 주소로 설정되어 공급사가 직접 고객에게 발송합니다. purchase.order는 영업과 조달을 연결하는 다리 역할을 합니다.
5. 제조(MRP)와의 연계
제조 오더에 필요한 자재가 부족하면 구매 주문을 생성해 원자재를 조달합니다. 이때 origin에 제조 오더가 기록되어 procure-to-pay(조달-지급) 사이클을 완성합니다.
개발자가 이 모델을 확장하는 방법
개발자는 여러 패턴으로 purchase.order를 확장합니다. 가장 기본적인 방법은 Odoo의 모델 상속을 활용하는 것입니다.
모델 상속 방식
_inherit = 'purchase.order'를 사용해 모델을 확장합니다. 새로운 필드를 추가하거나 메서드를 재정의하고 제약을 걸 수 있습니다. 별도 모듈로 변경사항을 관리하면 향후 업그레이드가 수월합니다.
필드 추가
상속한 모델에 필요한 필드를 선언합니다. Char, Many2one, Boolean, Integer, Text, Selection 등 적절한 타입을 선택하고 멀티컴퍼니 환경에서는 company-dependent 필드를 고려하세요.
파이썬 확장
button_confirm, create, write 같은 핵심 메서드를 오버라이드해 비즈니스 로직을 넣을 수 있습니다. 이때 기존 동작을 유지하려면 super()로 원본 호출을 잊지 말고, 계산 필드의 의존성도 신경 써야 합니다.
Odoo Studio 사용
Odoo Studio로는 코드 없이 필드를 추가할 수 있어 빠른 커스터마이징에 유리합니다. 그러나 복잡한 로직이나 버전 업그레이드를 고려한다면 커스텀 모듈로 관리하는 편이 유지보수에 안전합니다. purchase.order 모델은 XML-RPC와 JSON-RPC로 API가 완전히 노출되어 통합에 활용할 수 있습니다.
모범 사례
- 각 단계에 맞는 올바른 state를 사용하세요. 상태를 건너뛰거나 확인 절차를 우회하지 마십시오.
- 공급사가 준 참조번호가 있다면 partner_ref를 설정하세요. 입고와 청구서 매칭에 큰 도움이 됩니다.
- origin 필드를 활용해 주문의 출처를 추적하세요. 드롭쉽이나 제조 연동에서 필수적입니다.
- API 통합을 할 때는 XML-RPC 또는 JSON-RPC를 사용하세요. purchase.order 모델은 외부와의 맵핑에 적합하며 외부 ID를 신중히 관리해야 합니다.
- 커스텀 필드는
x_접두사 또는 모듈 접두사를 써서 향후 Odoo 버전과 충돌을 피하세요.
자주 범하는 실수
- 확정된 주문을 상태 확인 없이 임의로 수정하지 마세요. 확정된 주문은 특정 필드가 잠기므로 새 주문을 만들거나 올바른 워크플로우를 따르세요.
- partner_id와 dest_address_id를 혼동하지 마세요. partner_id는 공급사, dest_address_id는 (드롭쉽의 경우) 물건이 도착할 장소입니다.
- button_confirm를 오버라이드할 때 super() 호출을 빠뜨리면 다른 모듈과 충돌하거나 향후 업그레이드 시 문제가 생길 수 있습니다.
- 필수로 만든 커스텀 필드에 기본값을 주지 않으면 기존 레코드가 유효성 검사에서 실패할 수 있습니다. 마이그레이션 시 주의하세요.
- 멀티통화 거래 시 currency_id를 설정하지 않으면 비용과 청구 계산이 틀어질 수 있습니다. 올바른 통화를 항상 명시하세요.
맺음말
purchase.order 모델은 Odoo 구매의 중심입니다. RFQ와 확정된 구매주문을 저장하고, 필드와 확장 방식을 이해하면 설정, 커스터마이징, 통합 작업을 더 안전하고 빠르게 수행할 수 있습니다.
프로세스를 설계하는 컨설턴트든 확장 모듈을 만드는 개발자든, purchase.order를 제대로 이해하면 시행착오를 줄이고 시간을 절약할 수 있습니다.
Odoo 도입 지원이 필요하신가요?
Dasolo는 기업의 Odoo 도입·커스터마이징·최적화를 지원합니다. 특히 API 통합과 개발을 전문으로 하며, purchase.order 같은 핵심 모델을 다룬 풍부한 경험을 보유하고 있습니다.
Odoo 구현, 맞춤 모듈 개발 또는 통합이 필요하시면 저희가 도와드리겠습니다. 데모 예약하기 프로젝트에 대해 상담해 보세요.