イントロダクション
よくある光景を想像してください。営業は金曜納品を確約しているのに、実際に日程を調整する計画担当は木曜の夜に初めてその注文を知る。しかも購買や入荷はOdooの仕組みに登録されておらず、情報はメールやチャットの会話の中に埋もれている──このガイドはそんな現場の“見えない穴”を埋めることを目標にしています。
シンプルなテーブルのBOM作成から、あえて難易度を上げた“レベル10”の生産オペレーションまで、10の典型シナリオを用意しました。それぞれに、Odoo上で実際に押すべきボタンや操作順をわかりやすく示します。
Odooの購買モジュールは、倉庫の在庫やロット、入出庫、製造といった“現場の実際”と、営業や経理が求める数字をつなぐ接点です。うまく回れば二度手間が減り、失敗するとERPが責められる――この境界線を明確にします。
多くの工場や倉庫は経験やWhatsApp、最終版と名付けられたExcelで業務を回しています。それでしのげるのは小規模のうちだけで、拠点が増えたりトレーサビリティや監査が必要になると脆弱さが露呈します。
購買はOdooのモジュール群の一部です。チームが購買を導入するのは、責任の所在を明確にし、繰り返せる手順と検索可能な履歴を持ちたいとき。リクエスト、見積り、仕入請求、入庫の状態管理が利害関係者の予算承認フローを支えます。
購買で実際のモノの流れをモデル化します:受領、保管、ピッキング、製造、出荷、廃棄、補充。各工程が記録されることで、将来の自分や監査対応のときに感謝されるデータが残ります。
この記事では、初回のBOM作成から現場でのバーコード活用まで、具体的な企業例を交えた10のユースケースを読めます。
主な読者はオペレーション責任者、倉庫リーダー、生産計画担当者です。開発者は後から参加しても問題ありません。まずは業務視点で理解できるように書いています。
このガイドは難易度順のTop10で構成されています。レベル1は導入が簡単なもの、レベル10は高度な実装です。各レベルには番号付きの操作手順(Odoo上で実際にクリックする流れ)を用意しました。
目標は自分の現状から始めることです。見栄えだけでレベル10から始める必要はありません。
まずは「直面する課題」セクションを読み、自社の状況に近いレベルを開いてください。
このガイドで分かること:
- 一般的な企業のITスタックの中でOdoo購買が担う役割
- 現場で最も摩擦が生まれやすいポイント(原因も合わせて)
- 初心者レベルの運用ルールから高度な戦略までの10個のユースケース
- 自動化や外部連携でパートナーを入れるべき判断基準
直面する課題
営業が金曜納品を約束した。けれどその注文はメールに埋もれていて、プランナーが木曜夜に初めて知る。急ぎの輸送費で利益が圧迫され、経理は月末の精査で初めて在庫の齟齬に気づく──こんな痛い経験は多くの現場で繰り返されています。
倉庫や工場は“経験”で回ることが多い一方、在庫や製造の実態がOdoo外にあるケースが珍しくありません。その結果、欠品や緊急調達、月次で判明する不整合が頻発します。
もし心当たりがあるなら、典型的に直面する壁は次の通りです:
- 営業の約束と実在庫が合致していない在庫台帳
- リアルタイム数量を見ないまま立てた生産や購買計画
- 顧客や監査で問われたときに説明できないトレーサビリティの欠落
良い知らせは、すべてを一度に変えなくても良いということです。以下のユースケースのいずれかを30日間だけOdooで運用してみて、効果を測ることから始めてください。
購買で使えるトップ10ユースケース
ここではOdoo購買でまず実装すべき10のケースを、Level 1(今日できる簡単な勝ち取り)からLevel 10(専門家レベル)までランク付けしました。各ケースで「何を作るのか」「Odooでのクリック手順」は具体的に示します。
Level 1はすぐに効果が出る日常的な取り組み。最上位はあえて極端な例にしています。これは同じアプリが設計とデータが整えばどれほど拡張できるかを示すためです。
自社に合うレベルを選び、テスト環境で手順どおりに操作してみてください。慣れたら上のレベルに挑戦しましょう。
1. 単一仕入先に最初の見積依頼(RFQ)を送る Level 1 — 簡単
レベル1は最もシンプルな購買操作です。購買担当者1名、仕入先1社、品目1つ。契約や承認フローはなく、ただメールでRFQを送るだけの流れを確立します。
Odooでの手順(概要):
- Purchaseアプリをインストールし、Purchase → Vendors → Newで仕入先を作成。名称、連絡先メール、支払条件を入力します。
- Purchase → Requests for Quotation → Newで新規RFQを作成。仕入先を選び、必要な製品と数量を1行で追加します。
- Order Deadline(期限)とDelivery Address(納品先)を確認し、Send by EmailでRFQのPDFを送信します。
- 仕入先が価格を確定したら必要に応じて値を編集し、Confirm OrderでRFQをPOに確定します。
- チャッター(履歴)を開けば誰がRFQを送ったか、いつ承認されたかが残っています。
得られる効果:各購買に番号と日付、仕入先の確認記録が付き、経理が発注元を探し回る手間がなくなります。
2. 注文確定後、ドックで商品を受領する Level 2 — 簡単
レベル2では“受領”が加わります。購買担当から倉庫へ引き継ぎ、倉庫側がPOと実際の受領数量を照合して一クリックで記録します。
Odooでの手順(概要):
- 確定済みのPurchase Orderを開き、Receiptのスマートボタンをクリックして紐づく入庫伝票に移動します。
- ドックでは倉庫担当がInventory → Operations → Transfers → To Processで該当の転送を選びます。
- 各行に実際に届いた数量を入力します。例えば80のはずが78なら78と入力し、チャッターに内部メモを残します。
- Validateをクリックすると在庫数量が更新され、入庫がPOへ自動的にリンクされます。
- 再度POを開くと各行のReceived数量が更新され、次の仕入請求照合がスムーズになります。
得られる効果:倉庫と購買が同じ数字を見ているため、欠品や部分納品がすぐに明らかになります。月末まで埋もれません。
3. POからそのまま仕入請求(Vendor Bill)を作成する Level 3 — 簡単
レベル3は仕入請求の統合です。経理はPOのデータを再入力せず、同じ行・価格・税区分で請求書を即時作成できます。
Odooでの手順(概要):
- 確定済みのPurchase Orderを開き、画面上部のCreate Billをクリックします。
- OdooはPOの明細を元に下書きのVendor Billを作成します:製品、数量、単価、税が自動で入ります。
- Bill Date、Bill Reference(仕入先請求番号)、Due Dateを設定し、受領したPDFを添付します。
- Confirmを押すと請求書が仕訳に反映され、買掛金と該当の費用/在庫口座に計上されます。
- 支払期日になったらRegister Paymentで銀行振込を記録して会計処理を完結させます。
得られる効果:請求書は短時間で登録でき、PDFから手入力する必要がなくなり、払出が誰の承認したPOに紐付くか明確になります。
4. 仕入先ごとに数量別単価を設定した仕入価格表を作る Level 4 — 中級
レベル4は仕入価格の管理です。価格が担当者の頭の中や見えないスプレッドシートにあるのではなく、製品と仕入先に結びついてOdoo上で自動適用されます。
Odooでの手順(概要):
- 製品を開き、Purchaseタブへ移動。VendorsでAddをクリックして仕入先と価格、MOQ、リードタイム、通貨を登録します。
- 同じ仕入先行内で数量ブレイクを設定します:1個以上は単価A、50個以上は単価B、100個以上は単価Cといった形です。
- 供給可能な他の仕入先についても同様に登録し、優先順位を付けます。
- その製品で新規RFQを作成すると、選んだ仕入先と発注数量に応じて単価が自動反映されます。
- Purchase → Reporting → Purchase AnalysisでVendorとProductで集計すれば、実際の支払額と交渉済み価格の比較ができます。
得られる効果:交渉した単価が常にRFQに反映され、年度交渉のベースに“実績ボリューム”を使えるようになります。
5. 承認アプリで社員からの購買要求を集約する Level 5 — 中級
レベル5は購買リクエストの正式化です。社内の誰もが必要なものを申請し、購買担当が何をRFQにするか判断。全てのやり取りがOdooに残ります。
Odooでの手順(概要):
- Approvalsアプリをインストールし、Approvals → Configuration → Approval Types → NewでPurchase Requestタイプを作成します。
- Has ProductとHas Quantityを有効にして、申請者が具体的な品目と必要数量、希望納期を記入できるようにします。
- 承認ルールを設定します:まず直属の上司、その後購買マネージャー。一定金額以上は経理承認も入るようにします。
- 社員はApprovals → NewでPurchase Requestを選択し、フォームを記入して提出します。関係者にアクティビティ通知が届きます。
- 承認後、購買担当はPurchase → Requests for Quotation → Newで申請内容をコピーして実際のRFQを発行します。
得られる効果:Slackやメールで飛び交う要求が減り、発注候補がログとして残るため優先順位付けと発注作業が効率化します。
6. 3社から見積りを取り、Call for Tendersで比較する Level 6 — 中級
レベル6は購買合意(Purchase Agreements)を使った競争入札です。複数のRFQの回答を並べて比較し、記録を残して判断できます。
Odooでの手順(概要):
- Purchase → Orders → Purchase Agreements → Newで新規合意を作成し、TypeをCall for Tenders、締切を設定します。
- 複数の製品ラインに対してターゲット数量を入力し、競争見積りを取る対象を明示します。
- New Quotationをクリックして仕入先を選ぶと、Odooは合意に紐づく下書きRFQを作成します。
- これを仕入先2社目、3社目についても繰り返すと、合意画面上で各社の見積りが行ごとに並びます。
- 勝者を選び、そのRFQをPO確定する。落選分はアーカイブされ、Lost Reasonが合意に残ります。
得られる効果:調達決定の根拠が残り、半年後に誰かが見返しても「誰がいくらで提示したか」「なぜ選ばれたか」が分かります。
7. 受領と請求を突合して仕入先の過請求を防ぐ(三方一致) Level 7 — 難しい
レベル7はPO・受領・請求の三者一致を強制する設定です。これにより経理は受領実績に基づかない支払いを防げます。
Odooでの手順(概要):
- Purchase → Configuration → SettingsでBill ControlをReceived Quantitiesに設定して保存します。
- 例えばPOで80個発注し、倉庫がドックで78個を受領・部分処理したとします。
- 経理がPOから仕入請求を作成すると、Odooは受領数量78をデフォルトに入れます(80ではなく78)。
- もし仕入先が80で請求してきたら、その差異は即座に分かり、購買担当がクレジットノートを要求するなど是正措置を取れます。
- 請求書が受領と一致して初めてConfirmが可能になり、支払スケジュールが正しく処理されます。
得られる効果:過剰請求が野放しにならず、支払う金額は必ずPOと受領に裏付けられるため監査対応性が高まります。
8. 再発注ルール、MTO、スケジューラで需要駆動の調達を回す Level 8 — 難しい
レベル8では購買を販売と在庫の“需要シグナル”に連動させます。Odooが適切なタイミングでRFQを提案するため、購買は火消し業務から解放されます。
Odooでの手順(概要):
- 売れ筋にはInventory → Operations → Reordering Rules → NewでMin/Max、仕入先、リードタイムを設定します。
- 受注生産品には製品のPurchaseタブでRouteをMake To Orderに設定すれば、受注確定で自動的にRFQが起票されます。
- Inventory → Operations → Run Schedulerを毎日実行するか、サーバーアクションで定期起動すると提案が朝一に現れます。
- Purchase → Orders → Requests for QuotationでDraft Autoフィルタを使い、提案されたRFQを一括で実行に移します。
- Purchase → Reporting → Vendor On-Time Deliveryを見て四半期ごとにリードタイムを実績に合わせて調整します。
得られる効果:重要SKUの欠品が激減し、購買は交渉など価値の高い業務に時間を割けるようになります。営業の約束も現場で守れる頻度が上がります。
9. 年間のブランケット注文を確約し、主要仕入先にベンダーポータルを開放する Level 9 — 難しい
レベル9は調達のスケール化です。年間枠を一度交渉しておき、週次で必要量を引き出す(call-off)運用にし、主要仕入先には専用ポータルで自己管理してもらいます。
Odooでの手順(概要):
- Purchase → Orders → Purchase Agreements → NewでTypeをBlanket Order、期間を年間、有効価格とコミット数量を設定します。
- 毎週、合意を開きNew Purchase Orderで必要量を呼び出すと、Odooは残りコミット量を減算します。
- Settings → General SettingsでCustomer and Vendor Portalを有効にし、該当する戦略的仕入先にポータルアクセスを付与します。
- 仕入先は/my/purchaseでログインし、RFQを確認/応答、請求書をアップロードし、支払状況を自分で追跡できます。メール依存が減ります。
- Purchase Reportingでベンダーパフォーマンススコアカード(納期遵守、価格変動、欠陥率)を作り、四半期ごとにQBRで更新します。
- ブランケット注文の消費が年間目標の80%を超えたら購買に自動通知が行くようサーバーアクションを設定します。
得られる効果:上位20%の仕入先に対する定型調達が自己完結し、購買はソーシングやリスク対応に集中できます。
ブランケット注文のルール設計、ベンダーポータルのアクセス権、クロスアプリのスコアカード設計は、まさにDasoloがパートナーとして支援する領域です。
10. OCR請求、EDI、自動異常検知、ライブダッシュボードでAI化された調達OSを構築する Level 10 — エキスパート
レベル10は文字どおりのオペレーティングシステムです。AIが請求書を読み、主要仕入先とはEDIで機械間連携、異常検知がリスクを知らせ、全社コミットメントがリアルタイムで見える化されます。
Odooでの手順(概要):
- AccountingでBill Digitizationを有効にすると、仕入先の請求書PDFがOCRで自動解析され、明細・税・POリンクが下書きに反映されます。
- 上位5社にはEDI(XML、EDIFACT、Peppolなど)を導入し、PO、ASN、InvoiceがOdooと仕入先ERP間で自動で流れるようにします。
- サプライヤー契約、ブランケット注文、カタログをナレッジベース化してAIアシスタントに学習させ、購買担当の問い合わせに多言語で自動応答させます。
- Studioの自動化機能とAIによる異常ルールで、価格の急上昇(例:8%以上)、リードタイムの異常増、唯一供給依存、MOQの急変といった事象をフラグ化します。
- PurchaseをSales、Inventory、Accounting、Projectと連携させ、例えば請求支払が発生したらプロジェクトのコストに反映し、ダッシュボードを即時更新します。
- RFQ、遅延PO、三者不一致、基準比での節約額、ベンダー別納期遵守率などを一枚のスプレッドシート風コックピットにまとめ、リアルタイムで表示します。
- 重要なイベント(上位顧客向け受注の遅延、一定額を超える請求差異、ブランケット枯渇)をSlackやTeamsに通知する仕組みを組み込みます。
得られる効果:調達が単なるコストセンターでなく、ライブデータと予測アラート、AIコパイロットを備えた戦略部門に変わります。
AIコパイロット、EDI連携、異常検知ルール、ライブコックピットの設計と配線は、Dasoloがパートナーとしてまとめて支援するアーキテクチャ領域です。これにより、試行錯誤にかかる数四半期を短縮できます。
専門家の支援が有効な場面
もしレベル1〜6が自社の範囲なら、標準のOdoo購買と社内の責任者、そして試せるサンドボックス環境があれば十分に成功できます。
ただしレベル7以上になるとリスクが上がります:誤った自動メールが顧客に届いたり、Studioで作ったカスタムフィールドがバージョンアップを妨げたり、API連携が夜中に同期を止めてしまうことがあります。
これはチームの失敗ではなく、システム設計やテスト、ガバナンスが重要だというサインです。
複数アプリの横断設計、国別コンプライアンス、複雑な統合、あるいは取締役会が既にゴーライブ日を決めている場合はパートナーを迎え入れてください。
Dasoloと一緒に進める理由
Dasoloは、実際の業務に即したOdoo導入を支援します:カスタムアプリ、きれいな統合、そしてコンサルタントが去った後でも現場が覚えて使えるトレーニングを提供します。
購買のロードマップが本ガイドの上位ユースケースを含むなら、我々は段階的な計画を描けます。まずは短期の勝ちを確実にし、その後自動化・連携に移行。オーナーとテストスクリプトを明確にします。
お客様はスコープと予算をコントロールしたまま、我々はOdooの深い知見を提供します。現場で高くつく失敗を回避できます。
無料相談を予約する: