見積書は、どこにありますか。
多くの会社で、答えは「営業担当のパソコンの中」です。Excelのテンプレートをコピーして、金額を書き換えて、PDFにして送る。
このやり方でも、見積書は作れます。問題はそこではありません。
その見積書が、会社の資産になっていないことです。
いくらで出したのか。値引きはどれくらいしたのか。受注できたのか、失注したのか。それが分かるのは、本人だけです。
この記事では、Odoo（オドゥー：オープンソース由来の統合業務アプリ群）の販売管理を、機能の各論として整理します。
販売管理でできること
Odoo公式サイトによれば、販売アプリでは次のようなことができるとされています（2026年8月確認）。
見積から受注まで
- 販売オーダ、カスタマーサービス、eコマースショップを一つのプラットフォームで管理できる
- 顧客ごとに適正価格と税金を自動適用できる
- 見積書にオプション商品を追加してアップセルができる
- オンライン決済や電子署名を活用して取引を成立させられる
- サイズ・色・仕上げなど、複数の属性やバリエーションで商品を扱える
顧客とのやり取り
- 顧客ポータルから、顧客自身が見積書・オーダー・配送オーダーにアクセスできる
- 顧客はポータルを通じて、自分の見積書にオプション商品を追加できる
- すべてのメールでのやり取りが、関連する顧客オーダーに自動的に添付される
- 重要な見積書や案件をフォローし、対応が必要になると通知を受け取れる
- 商品ごとのメールテンプレートを作成し、購入時に関連情報を提供できる
請求へのつなぎ
Odoo公式によれば、請求書の発行基準は複数から選べるとされています。
- 前払い
- 見積送状
- 納品
- 発注数量ベース
- 時間と材料ベース
- プロジェクトのマイルストーン
オンライン決済が確認されると、自動的に請求書が作成されるとも案内されています。
その他
- 国内外の配送業者と連携できる
- 複数の会社間で受注書と発注書を自動的に反映させられる（グループ会社間の取引で効く機能です）
「見積が個人のものになる」問題
機能一覧より先に、構造の話をします。
左側の状態で本当に困るのは、担当者が辞めたときです。
「この顧客にはいつも何%引いていたか」「前回いくらで出したか」が、誰にも分かりません。次の担当者は、ゼロから関係を作り直すことになります。
右側では、条件を持っているのが人ではなく 価格表と顧客マスタです。担当が変わっても、出てくる見積は同じになります。
価格表の設計が、この機能の肝です
ここが、この記事でいちばん実務的な部分です。
Odooでは、顧客ごとに適正な価格と税金を自動適用できます。これを実現しているのが価格表という仕組みです。
価格表を設計するときの考え方
価格表は、次のような条件を組み合わせて作ります。
| 条件の例 | 使いどころ |
|---|---|
| 顧客の区分ごと | 代理店価格、直販価格 |
| 数量ごと | まとめ買いの割引 |
| 期間ごと | 期間限定のキャンペーン |
| 通貨ごと | 海外向けの取引 |
⚠️ 設計を複雑にしすぎない
ここは正直にお伝えします。価格表は、作り込もうと思えばいくらでも複雑にできます。
そして複雑にするほど、「なぜこの金額になったのか」を誰も説明できなくなります。
現実的な進め方は、次のとおりです。
- まず、いまの値引きルールを 紙に書き出す
- そのうち「明文化できるもの」だけを価格表にする
- 明文化できない例外は、手動の値引きとして残す
すべてを自動化しようとしないでください。8割が自動で決まれば、営業の手間は十分に減ります。
この考え方は OdooとFit to Standard にも通じます。
顧客ポータルという発想
Odooの販売管理で、日本ではまだ馴染みが薄いものの、効果が大きいのが顧客ポータルです。
顧客が自分でログインし、見積書・注文内容・配送状況を確認できます。オプション商品を自分で追加することもできます。
なぜ効くのか
「あの見積、どうなりました？」という電話が減ります。
「注文した分、いつ届きますか？」という問い合わせも減ります。
つまり、営業事務の割り込み作業が減るということです。これは人数の少ない会社ほど効きます。
ただし、日本では慎重に
一方で、顧客側の慣れという問題があります。
取引先によっては、「ポータルにログインして確認してください」が受け入れられないこともあります。従来どおりPDFをメールで送ってほしい、という声も現実にはあります。
全顧客に一律で使わせようとしないでください。 使ってくれる顧客から順に広げるのが現実的です。
日本の商習慣で確認すべきこと
正直にお伝えします。販売管理は、日本の商習慣が濃く出る領域です。
(1) 見積書・注文書の様式
自社指定の様式がある場合、標準の帳票レイアウトをどこまで寄せられるかを確認してください。
押印欄、部門名、自社ロゴの位置など、細かい要望が出やすい部分です。
(2) 締め日と請求のタイミング
「月末締め翌月末払い」のような取引条件をどう表現するか。ここは請求の設計と一体で考える必要があります。
詳しくは Odooの請求書発行（Invoicing） をご覧ください。
(3) 適格請求書（インボイス制度）の要件
請求書に必要な記載事項は制度で決まっています。標準の帳票が要件を満たすかは、必ず事前に確認してください。
考え方は Odooのインボイス制度（適格請求書）対応 にまとめています。
(4) 消費税の端数処理
税の計算方法と丸めの設定は、取引先との取り決めに影響します。詳しくは Odooの消費税設定と日本の税制 をご覧ください。
この4点は、要件定義の段階で洗い出してください。 稼働直前に出てくると、帳票の作り直しになります。進め方は Odoo導入の要件定義の進め方 にまとめています。
CRMとの境界をどこに引くか
よくいただく質問です。「販売管理とCRMは何が違うのか」。
役割は明確に分かれています。
| アプリ | 扱うもの |
|---|---|
| CRM | まだ受注していない見込み客と商談。確度、次のアクション、失注理由 |
| 販売 | 見積書という形になったもの以降。受注、納品、請求 |
CRMで商談を追いかけ、条件が固まったら見積を作る。この時点で販売アプリの領域に入ります。
CRMの詳細は OdooのCRMでできること をご覧ください。
なお、CRMを使わずに販売アプリだけを使うこともできます。 商談管理の必要がない事業（受注生産、リピート中心の卸売など）では、そのほうがシンプルです。
他のアプリとのつながり
| アプリ | つながり方 |
|---|---|
| CRM | 商談から見積の作成へ |
| 在庫 | 受注に応じた引き当て、納品、配送 |
| 購買 | 受注に応じた仕入れ（取り寄せ型の販売） |
| 請求／会計 | 請求書の発行と入金の管理 |
| プロジェクト | 受注から案件を作成し、工数を採算に紐づける |
| eコマース | オンラインの注文を同じ販売データとして扱う |
在庫は Odooの在庫管理（Inventory） をご覧ください。購買は Odooの購買管理（Purchase）、案件管理は Odooのプロジェクト管理（Project） にまとめています。
Community版とEnterprise版の違い
Odooには、無料の Community版 と有償の Enterprise版 があります。
Community版はオープンソースとして無料で使えます。ただし、サーバの用意・アップデート・障害対応は自社の責任になり、公式サポートの対象外です。
販売アプリの基本的な機能は、Community版でも利用できるとされています。ただし、どの機能がどちらの版で使えるかはバージョンによって変わります。 検討時には必ず対象バージョンで確認してください。
詳しくは Odoo Community版とEnterprise版の違い をご覧ください。
Odooの販売管理が合わないケースもあります
正直に書きます。
ベンチャーネットは、SAP・NetSuite・Odoo・AIスクラッチ開発という4つの選択肢を扱っています。販売管理では、次のように整理できます。
| 状況 | 検討したい選択肢 |
|---|---|
| 見積書を作るだけで、在庫も請求も別で回っている | 見積作成の専用ツールで足りることがある |
| 見積・在庫・請求をつなげたい中小〜中堅企業 | Odoo が現実的な選択肢 |
| 多国籍・多通貨・複雑な収益認識が必要な規模 | OdooとNetSuiteの違い を参照 |
| 販売の条件設定が固有すぎて、価格表で表現できない | AIスクラッチ開発という選択肢 |
1行目を強調しておきます。見積書を作ることだけが目的なら、ERPは重すぎます。
Odooの価値は、その見積が受注・納品・請求へとつながることにあります。そこに価値を感じない場合は、無理に選ぶ必要はありません。
AIスクラッチ開発は、ライセンス費用がかからない代わりに開発費と保守費がかかります。判断材料は パッケージERPかスクラッチ開発か に整理しました。
よくある質問
Q1. いまの見積書のレイアウトを再現できますか？
標準の帳票をどこまで寄せられるかは、要件次第です。ロゴや項目の追加は比較的容易ですが、細かい様式の完全再現には作り込みが必要になることがあります。
「今と同じ見た目」を最優先にすると、費用と保守負担が増えます。 どこまで必要かを先に決めてください。
Q2. 顧客ごとの特別価格は設定できますか？
できます。Odoo公式は、顧客ごとに適正価格と税金を自動適用できると案内しています。顧客区分・数量・期間・通貨などの条件を組み合わせて価格表を作ります。
ただし、条件を複雑にしすぎると「なぜこの金額か」が説明できなくなります。明文化できるものだけをルール化してください。
Q3. 受注したら在庫は自動で引き当てられますか？
在庫アプリと組み合わせることで、受注に応じた引き当てと納品の処理につながります。
在庫を持たないサービス業の場合は、この部分を使わない構成も可能です。
Q4. CRMも一緒に入れる必要がありますか？
必要ありません。商談管理が不要な事業では、販売アプリだけを使うほうがシンプルです。
見込み客の管理や商談の確度を追いかけたい場合に、CRMを追加してください。
Q5. 請求書の発行タイミングは選べますか？
Odoo公式によれば、前払い、見積送状、納品、発注数量ベース、時間と材料ベース、マイルストーンなどから選べるとされています。
日本の「月末締め」の運用をどう表現するかは、請求の設計とあわせて検討してください。
まとめ
見積書をExcelで作ること自体は、悪いことではありません。速いですし、自由が利きます。
問題は、その見積が会社の資産にならないことです。いくらで出したか、どれだけ値引きしたか、受注できたか。それが本人の中にしかありません。
Odooの販売管理では、条件を持つのが人ではなく 価格表と顧客マスタになります。担当が変わっても、同じ条件の見積が出ます。
そして見積は、受注・納品・請求へとそのままつながります。転記がないので、途中で止まりません。
一方で、価格表の設計には注意が必要です。すべてを自動化しようとしないでください。 明文化できるルールだけを載せ、例外は手動で残す。この割り切りが、結果的に早く動き始めます。
日本の商習慣（帳票様式・締め日・適格請求書・端数処理）は、要件定義の段階で必ず洗い出してください。
もう少し詳しく知りたい方へ
ベンチャーネットは、ERP導入支援を手がける会社です。SAP・NetSuite・Odoo・AIスクラッチ開発という4つの選択肢を扱っているため、特定の製品に偏らない立場でご提案できます。
「うちの値引きルールと帳票要件が、標準にどこまで乗るのか」という切り分けからご相談を承っています。
あわせて読みたい記事
