소개
Odoo에서 '모델'은 데이터베이스 안의 데이터 구조를 정의하는 설계도입니다. 거래, 고객, 제품 같은 모든 비즈니스 데이터는 각기 대응되는 모델에 저장되고, 모델 정의는 필드와 관계, 저장 방식과 기본 동작을 결정합니다.
모델을 이해하는 것은 개발자와 기능 컨설턴트 모두에게 필수적입니다. 모델이야말로 Odoo 데이터 아키텍처의 기반이며, 필드 정의와 관계 설정, 그리고 비즈니스 로직의 위치를 규정합니다.
이 글은 Odoo에서 가장 중요한 모델 가운데 하나인 sales.order를 집중적으로 다룹니다. 맞춤 모듈을 개발하거나 외부 시스템을 연동하거나 영업 프로세스를 구성할 때 이 모델을 자주 접하게 됩니다.
sales.order 모델이란 무엇인가
sales.order는 견적과 판매주문을 담는 모델입니다. 고객과의 거래 내역이 청구나 출고 전 단계까지 이곳에 기록되며, 주문의 핵심 정보가 모두 이 모델 안에서 관리됩니다.
이 모델은 Odoo의 Sales(판매) 모듈에서 핵심적으로 사용됩니다.
영업 담당자가 견적서를 만들면 sales.order 레코드가 생성됩니다. 고객이 수락하면 상태가 draft에서 sale(확정)로 바뀝니다. 견적과 확정 주문은 같은 모델로 관리되며, state 필드는 주문의 생애주기를 추적합니다.
다른 모듈들은 Odoo의 모델 상속을 통해 sales.order를 확장합니다. CRM은 영업기회와 주문을 연결하고, 회계는 청구 관련 필드를 추가하며, 재고는 출고 일정과 약속일을 다룹니다. 각 모듈은 핵심 구조를 복제하지 않고 필요한 기능만 덧붙입니다.
모델의 핵심 필드
아래는 sales.order에서 특히 자주 쓰이는 주요 필드들입니다. 이들 필드를 이해하면 견적과 주문을 다루는 업무나 개발이 훨씬 수월해집니다.
1. name
유형: Char. 주문 참조번호나 견적 번호를 저장합니다. 보통 자동생성되며(예: S00042), 목록과 서류에 표시되는 기본 식별자 역할을 합니다.
2. state
유형: Selection. 주문의 상태를 나타냅니다. 주요 값: draft(견적), sent(견적 발송), sale(확정 주문), done(완료 — 출고·청구 모두 완료), cancel(취소). 상태에 따라 가능한 작업이 달라집니다.
3. partner_id
유형: Many2one(res.partner). 고객(회사 또는 개인)을 가리키는 필수 필드입니다. 모든 고객 관련 로직과 리포팅의 기준이 됩니다.
4. partner_invoice_id
유형: Many2one(res.partner). 청구지 주소. 설정하지 않으면 partner_id를 기본으로 사용합니다. 본사 청구 등 별도 청구처가 있을 때 활용합니다.
5. partner_shipping_id
유형: Many2one(res.partner). 배송지 주소. 설정하지 않으면 partner_id가 기본입니다. 출고와 배송비 계산에 사용됩니다.
6. user_id
유형: Many2one(res.users). 담당 영업자 또는 책임자. CRM, 커미션, 활동 배정 등에 쓰이며 보통 영업팀이나 기회에서 설정됩니다.
7. team_id
유형: Many2one(crm.team). 영업팀을 가리킵니다. 영업 담당자 그룹화와 팀 단위 분석·쿼터 관리에 사용됩니다.
8. date_order
유형: Datetime. 주문 날짜입니다. 견적 단계에서는 생성일, 확정 시에는 확정일로 활용되며 리포팅과 정렬에 중요합니다.
9. validity_date
유형: Date. 견적 유효기간의 종료일입니다. 기간 제한 프로모션이나 가격 유효성 관리를 위해 사용됩니다.
10. commitment_date
유형: Datetime. 약속된 납품일입니다. 설정하면 재고 출고 일정은 제품 리드타임 대신 이 날짜를 기준으로 계획됩니다. 고객 약속 관리에 중요합니다.
11. order_line
유형: One2many(sale.order.line). 주문 행들입니다. 각 행에는 제품, 수량, 단가, 세금 등이 들어가며 주문의 실제 항목을 구성합니다.
12. amount_untaxed
유형: Float. 세금 제외 소계입니다. 주문 행에서 계산되며 화면 표시와 리포팅에 사용됩니다.
13. amount_tax
유형: Float. 총 세금 금액입니다. 세금 설정에 따라 주문 행에서 계산되어 주문서와 청구서에 표시됩니다.
14. amount_total
유형: Float. 세금을 포함한 총액입니다. 청구와 회계 리포팅의 주요 금액입니다.
15. currency_id
유형: Many2one(res.currency). 통화입니다. 보통 회사 설정이나 가격목록에서 상속되며, 모든 금전 필드는 이 통화를 기준으로 합니다.
16. pricelist_id
유형: Many2one(product.pricelist). 주문에 적용되는 가격목록입니다. 주문 행의 단가 결정을 좌우하며, 거래처 설정이나 수동으로 변경할 수 있습니다.
17. payment_term_id
유형: Many2one(account.payment.term). 결제 조건(예: 30일 후 결제, 선금 50%). 청구서를 생성할 때 참조됩니다.
18. fiscal_position_id
유형: Many2one(account.fiscal.position). 세금 매핑을 위한 회계 포지션입니다. 해외 거래나 특수 과세 대상일 때 적용됩니다.
19. client_order_ref
유형: Char. 고객 참조번호(P.O. 번호 등). 고객이 제공한 주문 번호를 기록해 문서와 리포트에 표시합니다.
20. origin
유형: Char. 주문의 출처 문서(예: 기회명). 추적성 확보를 위해 관련 기록의 이름을 저장합니다.
21. create_date
유형: Datetime. 레코드가 생성된 시점입니다. Odoo가 자동으로 채우며 리포팅과 감사에 유용합니다.
22. write_date
유형: Datetime. 마지막 수정 시각입니다. 역시 자동 관리되며 최근 변경 시점을 파악할 때 사용됩니다.
23. note
유형: Text. 견적·주문서에 표시되는 약관이나 내부 메모를 넣습니다. 법적 문구나 특이사항 안내에 사용됩니다.
24. require_signature
유형: Boolean. True이면 고객의 전자서명이 필요해야 주문이 확정됩니다. 전자상거래나 고객 포털 흐름에서 활용됩니다.
25. require_payment
유형: Boolean. True이면 확정 전 결제가 요구됩니다. 선불 또는 보증금 기반 주문에 사용됩니다.
26. invoice_status
유형: Selection. 청구 진행 상황을 추적합니다: no(청구 없음), to invoice(청구 준비됨), invoiced(전액 청구됨), upsell(추가 청구 항목 있음).
27. locked
유형: Boolean. True이면 주문을 수정할 수 없습니다. 확정되거나 관련 문서가 게시되면 자동으로 잠깁니다.
28. company_id
유형: Many2one(res.company). 멀티컴퍼니 환경에서 해당 주문이 속한 회사를 나타냅니다. 가시성과 권한에 영향을 줍니다.
29. tag_ids
유형: Many2many(crm.tag). 필터링·리포팅·세분화용 태그입니다. 유연한 워크플로 분류에 유용합니다.
30. signed_by
유형: Char. require_signature가 사용될 때 주문에 서명한 사람의 이름을 저장합니다. 감사용으로 기록됩니다.
31. signed_on
유형: Datetime. 서명 시각입니다. 서명이 필요한 확인 절차에서 사용됩니다.
32. prepayment_percent
유형: Float. 선결제 비율(%)입니다. require_payment와 함께 보증금·선금 기반 주문에 활용됩니다.
업무 흐름에서의 활용 방식
1. 견적에서 주문으로
영업 담당자가 견적(임시)을 만들고 품목과 가격을 입력해 고객에게 보냅니다. 고객이 동의하면 주문 상태가 확정(sale)으로 바뀌고 이후 청구서 생성과 출고 처리가 진행됩니다.
2. 전자상거래와 포털 주문
웹사이트에서 고객이 주문하면 sales.order 레코드가 자동 생성됩니다. require_signature나 require_payment 설정으로 온라인 결제나 서명을 필수화할 수 있습니다.
3. CRM에서 Sales로 전환
기회(opportunity)가 성사되면 해당 기회에서 견적이 생성되고 origin 필드에 기회명이 남습니다. user_id와 team_id는 보고서와 커미션 계산에 반영됩니다.
4. 청구 처리
확정된 주문에서 청구서를 작성하면 주문 행의 내용이 청구서로 복사됩니다. 결제 조건과 회계 포지션도 주문에서 상속되며 invoice_status로 진행 상황을 추적합니다.
5. 출고 일정과 약속일
commitment_date를 설정하면 출고는 이 날짜를 기준으로 계획됩니다. 배송지는 partner_shipping_id를 참고합니다.
개발자가 이 모델을 확장하는 방법
개발자는 여러 패턴으로 sales.order를 확장합니다. Odoo 모델 상속이 기본 수단입니다.
모델 상속
확장을 위해 _inherit = 'sale.order'를 사용합니다. 새로운 필드를 추가하거나 메서드를 재정의하고 제약 조건을 넣을 수 있습니다. 이렇게 하면 변경 사항을 별도 모듈에 보관해 향후 업그레이드가 쉬워집니다.
필드 추가
상속한 모델에 새 필드를 정의하세요. 적절한 타입(Char, Many2one, Boolean, Integer, Text, Selection 등)을 사용하고, 멀티컴퍼니 환경인 경우 회사 종속 필드를 고려하세요.
파이썬 확장
추가 로직이 필요하면 action_confirm, create, write 등을 오버라이드하세요. 기존 동작을 유지하려면 super()로 원본 호출을 잊지 말고, 계산 필드의 의존성은 신중히 관리하세요.
Odoo Studio
Odoo Studio로 코드 없이도 필드를 추가할 수 있어 빠른 커스터마이징에 적합합니다. 다만 복잡한 로직이나 장기 유지보수가 필요한 경우에는 커스텀 모듈 방식이 더 바람직합니다.
권장 실무(모범 사례)
- 각 단계에 맞는 적절한 상태를 사용하세요. 상태를 건너뛰거나 확인 로직을 우회하지 마십시오.
- 고객에게 약속한 납품일이 있다면 commitment_date를 설정하세요. 배송 계획과 고객 약속 관리를 크게 개선합니다.
- 신용 관리나 리포팅에서 상위 법인 기준이 필요하면 commercial_partner_id를 사용하세요. 고객 그룹화를 위한 기준으로 유용합니다.
- API 연동 시에는 XML-RPC 또는 JSON-RPC를 사용하세요. sales.order는 API로 완전히 노출되어 있으므로 외부 시스템의 ID 매핑을 신중히 설계해야 합니다.
- 커스텀 필드는 충돌을 피하기 위해
x_접두사나 모듈별 접두사를 사용하는 것이 안전합니다.
자주 발생하는 실수
- 확정된 주문을 수정할 때는 locked 플래그를 확인하세요. 잠긴 주문을 임의로 변경하면 데이터 무결성이 깨질 수 있으므로 적절한 이력(리비전)을 만들거나 올바른 워크플로로 처리하세요.
- partner_id, partner_invoice_id, partner_shipping_id를 혼동하지 마세요. 각 필드는 목적이 다르며, 주소가 다를 경우 세 필드를 모두 정확히 설정해야 합니다.
- action_confirm를 오버라이드하면서 super()를 호출하지 않으면 다른 모듈과 충돌하거나 향후 업그레이드 시 문제가 발생할 수 있습니다.
- 필수 커스텀 필드를 추가하면서 기본값을 지정하지 않으면 기존 주문이 유효성 검사에 실패할 수 있습니다. 마이그레이션을 고려해 기본값을 마련하세요.
- currency나 가격이 기본과 다를 때 pricelist_id를 설정하지 않으면 잘못된 가격으로 청구될 위험이 있습니다. 가격 정책을 명확히 하세요.
마무리
sales.order 모델은 Odoo 판매 프로세스의 핵심입니다. 견적과 확정 주문을 저장하는 중심 영역이며, 필드와 확장 방식에 대한 이해는 구성·커스터마이징·연동 작업을 원활하게 합니다.
기능 컨설턴트가 영업 프로세스를 설계하든 개발자가 맞춤 모듈을 만들든, sales.order를 잘 알면 시간과 비용을 절약하고 오류를 줄일 수 있습니다.
Odoo 도입 지원이 필요하신가요?
Dasolo는 기업의 Odoo 도입, 커스터마이징, 최적화를 돕습니다. 특히 API 연동과 Odoo 개발에 강점을 가지고 있으며, sales.order 같은 핵심 모델에 대한 실무 경험이 풍부합니다.
Odoo 도입, 커스텀 모듈 개발 또는 연동이 필요하시면 언제든 도와드리겠습니다. 데모 신청 하여 프로젝트를 논의해 보세요.