9月の経営会議で、8月の粗利率が報告されました。翌週、社長が試算表を開くと、粗利率が先週聞いた数字から1ポイント下がっています。8月28日付の仕入請求が、締めた後に追加されていたのです。どの数字が正しいのか。会議の議論はそこで止まります。
こうした数字のずれは、Odoo（オドゥー）の仕組みで、入ってくる場所から止められます。Odooは、販売・在庫・会計などをひとつにつなぐERPです。ERPとは、会社全体の業務データをひとつのシステムで管理する仕組みを指します。数字が狂う入口は、たいてい3つ。入力のときの漏れ、確定した後に紛れ込む異常値、締めた後の修正です。
たとえば8月31日でロック日付を設定すれば、遅れて届いた8月28日付の請求は、9月1日の会計日で入ります（ロック日付で過去を閉じる）。3つの入口に仕組みを置くと、次のことが変わります。
- 配送時間帯が空欄の受注を、確定ボタンを押したときに止められる
- 桁ミスや原価割れの受注を、翌朝の知らせとして担当者に届けられる
- 締めた月を開けたときは、いつ・誰が・なぜ開けたかが記録に残る
- 会計に関わる変更を、日時・変更者・変更前後の値で追える
良い点と注意点は、数字の入口を守るメリットとデメリットにまとめました。
ただし、どの仕組みも人が決めた基準で動きます。上場の準備で内部統制まで求められる規模なら、要件はもう一段重くなります。では、何を止めて、何を人が判断するのか。架空の食品卸「さくら商事（従業員30名）」を例に、仕組みに任せず人が決めることで線を引きます。
Community版とEnterprise版について
この記事で使う自動化ルール・スケジュールアクション・購買の承認・監査証跡は、無料のCommunity版にもあります（Odoo 19のソースコードで確認）。項目の必須設定や承認ルールを画面から付けるStudioは、有償のEnterprise版の機能です。ロック日付は、公式ドキュメントでは会計アプリの画面から設定する手順が案内されています。OCA（Odooの有志団体）のモジュールは、Odoo Onlineには入れられません。
ERPの「数字が合わない」は、どこから入ってくるか
数字が信頼されない会社では、入力の仕方より先に、止める場所が決まっていません。誤りは次の3か所から入ってきます。
| 入口 | さくら商事で起きたこと | 気づいた時点 |
|---|---|---|
| 入力漏れ | 受注の配送時間帯が空欄のまま確定 | 出荷の当日 |
| 異常値 | 数量20のつもりが200で受注 | 請求書を送った後 |
| 締め後の修正 | 8月28日付の仕入請求を9月に追加 | 翌週の会議 |
3つとも、気づくのが遅いほど直す手間が増えます。出荷の当日なら電話1本で済む話が、請求の後なら赤伝票と謝罪が必要になる。締めた月の数字が変われば、会議で話した前提が崩れます。
稲盛和夫氏は、経営の原則に「売上を最大限に伸ばし、経費を最小限に抑える」を挙げました（出典：稲盛和夫オフィシャルサイト）。ベンチャーネットは、これを日々実現する仕組みをAIクラウドERPと呼んでいます。その第一歩が、売上と経費を正しく計測することです。全体の考え方はブルシットジョブを消し去るにまとめています。
数字をグラフや画面にする「見える化」は、この後の段階です。入口が整わないまま画面を作っても、出てくる数字は信用されません。見える化の進め方は、経営の「見える化」とはで扱っています。
Odooで数字の入口を守るメリットとデメリット
3つの入口をOdooの仕組みで守るときの良い点と注意点は、次のとおりです。使える版は、機能ごとに添えています。
メリット
- 入力漏れを確定の瞬間に止められる：自動化ルールで、受注を確定するときだけ空欄を確かめる。自動化ルールはCommunity版にもある。Studioで項目を必須にする方法はEnterprise版
- 異常値を夜のうちに洗い出せる：スケジュールアクションで、桁ミスや原価割れの受注を探し、担当者に活動で知らせる。Community版にもある
- 締めた月の数字が動かない：ロック日付以前の会計日には転記できず、遅れた請求はロック日付の翌日に寄る。項目と例外の仕組みはCommunity版のソースにある
- 誰が何を変えたかを追える：監査証跡は、Community版の会計モジュールのソースにも含まれる。マスターの変更は、OCAの「auditlog」で記録できる
- 会議で数字の意味を話せる：締めた月が動かなければ、会議の数字は1回で確定する
デメリット・注意点
- 止めすぎると抜け道を探される：条件の広いルールは、確定済みの受注の請求書作成まで止めた。止めるのは、空欄だと後工程が止まる項目だけにする
- コードは保守の対象になる：コードの保守はOdooのスタンダード・カスタムプランに含まれず、別料金。バージョンアップのたびに確かめる対象も増える
- OCAのモジュールは自社運用が前提：「sale_exception」や「auditlog」は、Odoo Onlineには入れられない。オンプレミスかOdoo.shで使う
- 外から入るデータで止まるかは試す：Studioの必須設定は画面ごとの設定。「On UI change」も手で変えたときにしか動かない
両方を並べると、次の図のとおりです。
止める・知らせる・記録するの選び方は仕組みに任せず人が決めることで、試す順番は進め方で扱います。
入力漏れ・入力ミスの防止：確定の瞬間に止める
入力漏れは、入力する画面ではなく、伝票を確定する瞬間に止めるのが効果的です。下書きの段階で空欄があっても、業務は困りません。困るのは、空欄のまま次の工程に進んだときです。
項目そのものを必須にする
いちばん単純なのは、項目を必須にする方法です。Enterprise版のStudioでは、項目の設定で「Required（必須）」を有効にすると、入力しないと先に進めなくなります。条件を付けて、特定のレコードだけ必須にすることもできます（出典：Odoo公式ドキュメント「Fields and widgets」、2026年10月確認）。
ただし、この設定は画面（ビュー）ごとに付けるものです。インポートや外部連携から入るデータも同じように止まるかは、テスト用のデータベースで試してください。
確定のときだけ止める：自動化ルール
「見積の段階では空欄でよいが、受注を確定するときは必ず入れてほしい」。現場の要望は、たいていこの形です。これには自動化ルールを使います。
自動化ルールは、決めたきっかけで決めた処理を動かす機能です。Community版にもあり、開発者モードの設定画面から作れます。
さくら商事では、受注に「配送時間帯」の項目を足しました。ところが、最初に作ったルールは止めすぎました。
最初のルール（止める条件が広い）
| 操作 | 受注 | 配送時間帯 | 結果 |
|---|---|---|---|
| 確定ボタン | S00201 | 空欄 | 止まる（正しい） |
| 確定ボタン | S00202 | 午前 | 通る |
| 請求書の作成 | S00150（項目を足す前に確定） | 空欄 | 止まる（誤り） |
原因は、きっかけを「作成・更新したとき」にし、条件を「状態が販売オーダー」にしたことです。これだと、確定済みの受注が更新されるたびに空欄チェックが動きます。公式ドキュメントも、更新のきっかけには注意を促しています。監視する項目を選ばないと、1件に何度も動くことがあります（出典：Odoo公式ドキュメント「Automation rules」、2026年10月確認）。
直したルール（確定の瞬間だけ）
| 操作 | 受注 | 結果 |
|---|---|---|
| 確定ボタン | S00201 | 止まる：「配送時間帯を入力してください」 |
| 確定ボタン | S00202 | 通る |
| 請求書の作成 | S00150 | 通る |
きっかけを「State is set to（状態が次に変わったとき）」にして、値を「販売オーダー」にしました。Odoo 19のソースコードでは、このきっかけは状態の項目が変わったレコードだけを対象にします。請求書を作っても受注の状態は変わらないので、S00150は止まりません。ベンチャーネットは、この判定をPythonで再現し、上の表のとおりに分かれることを確かめました。
処理の中身は「コードの実行」で、空欄ならエラーを出して確定を止めます。
if not record.x_delivery_slot:
raise UserError("配送時間帯を入力してください")項目名（x_delivery_slot）は自社の環境に合わせます。このくらいの短いコードなら、ClaudeやChatGPTに下書きさせてかまいません。
次の条件でOdoo 19の自動化ルールの「コードの実行」を書いてください。
・対象は販売オーダー。受注が確定されたときだけ動く
・配送時間帯（x_delivery_slot）が空ならUserErrorで止める
・請求書の作成など、確定済みの受注の更新では動かないこと
・テストで試す操作の一覧も付けて
コードの保守は、Odooのスタンダード・カスタムプランには含まれず、別料金になります（出典：同上）。コードを足すほど、バージョンアップのたびに確かめる対象も増えます。止める項目は、本当に後工程が止まるものだけに絞ってください。
自動化ルールで入力そのものを減らす方法は、Odooの自動化ルールとAIで入力を減らすで扱っています。
止めずに、気づかせるだけの警告
止めるほどではない注意もあります。販売の設定には「Sale Warnings」があります。特定の得意先や商品の受注で、警告を出す機能です（出典：Odoo公式ドキュメント「Create quotations」、2026年10月確認）。「この得意先は配送先が2か所ある」など、担当者が忘れやすい注意を書いておく使い方です。
異常値の検知：夜のうちに洗い出す
入力漏れは機械的に判定できます。異常値はそうはいきません。数量200が誤りか、本当に大口の注文かは、システムには分からないからです。
そこで異常値は、止めずに洗い出して人に知らせます。
毎晩の定期処理で、桁ミスと原価割れを探す
さくら商事のある日の受注です（数字は架空）。
| 受注 | 得意先 | 数量 | 単価 | 原価 |
|---|---|---|---|---|
| S00101 | みどりスーパー | 20 | 1,800 | 1,400 |
| S00103 | みどりスーパー | 200 | 1,800 | 1,400 |
| S00104 | あおば物産 | 25 | 1,200 | 1,400 |
| S00106 | ひかり食堂 | 24 | 18,000 | 1,400 |
ベンチャーネットは、異常の条件を3つ決めてPythonで試しました。
- 数量が、得意先ごとにいつもの量（直近の中央値）と比べて3倍を超える
- 単価が原価を下回る
- 単価が、その商品のふだんの単価から50%を超えて外れている
結果、引っかかったのは3件だけでした。翌朝7時、担当者には次の活動（Odooのやること通知）が届きます。
- S00103：数量200が、いつもの量（約21）の3倍を超えています。桁ミス？
- S00104：単価1,200円が原価1,400円を下回っています（粗利 −5,000円）
- S00106：単価18,000円が、ふだんの1,800円から大きく外れています
仕組みはスケジュールアクションです。決めた間隔でコードを動かす定期処理で、Community版にもあります。開発者モードで「設定 → テクニカル → 自動化：スケジュールアクション」から作ります（出典：Odoo公式ドキュメント、2026年10月確認）。対象を販売オーダー、間隔を毎日1回にして、条件に合う受注の担当者に活動を作るコードを書きます。
このコードもAIに下書きさせれば早くできますが、そのまま本番には入れません。人が読み、複製したデータベースで試してから使うのが決まりです。
一括で取り込んだ受注は「例外」として止める
ECやExcelから受注をまとめて取り込む会社では、不備のある受注が紛れ込みます。
| 取り込んだ受注 | 問題 | 気づいた時点 |
|---|---|---|
| S00501 | 配送先の郵便番号がない | 配送業者からの差し戻し |
| S00502 | 在庫が足りない | 出荷の当日 |
OCAの「sale_exception」というモジュールは、こうした受注に例外の印を付け、確定を止めます。郵便番号がない、在庫が足りないといった条件が用意されていて、使うものを有効にする形です。止まった受注は「Blocked in draft」の絞り込みで探し、1件ずつ直せます。Odoo 19版も公開されています（出典：OCA sale-workflow、2026年10月確認）。
日本の住所なら、都道府県の欠けなども条件に足すとよいでしょう。自社でサーバーを運用する形（オンプレミス・Odoo.sh）が前提で、選び方はOCAとは？Odooコミュニティモジュールの活用が参考になります。
例外を解くのは人です。AIに例外の一括解除を任せると、止めた意味がなくなります。在庫や放置案件など、毎朝の確認を自動にする方法は在庫・営業・購買の「毎朝の確認」を自動化するで扱っています。経費側の異常は経費の異常を人が探さないが担当です。
締め後の修正を防ぐ：Odooのロック日付で過去を閉じる
冒頭の会議の場面は、締めた月に後から伝票が入ったことが原因でした。これを止めるのがロック日付です。
8月を締めたら、8月31日でロックする
| 日付 | 操作 | ロックなし | ロック日付＝8月31日 |
|---|---|---|---|
| 9月5日 | 8月28日付の仕入請求を転記 | 8月の数字が変わる | 会計日が9月1日になる |
| 9月5日 | 9月2日付の仕入請求を転記 | 通常どおり | 通常どおり |
Odoo 19では、ロック日付以前の会計日で、転記済みの仕訳は直せず、新しい転記もできません。新しく転記すると、会計日はロック日付の翌日に寄せられます（出典：Odoo公式ドキュメント「Year-end closing」、2026年10月確認）。8月の数字は変わらず、遅れて届いた請求は9月の費用として入ります。
ベンチャーネットは、8月31日でロックしたときに8月28日付だけが9月1日に寄る動きを、Pythonで試算して確かめました。経理責任者がすることは、月次の締めのたびにロック日付を月末日に更新するだけです。
ロックの種類と、外せないロック
公式ドキュメントが案内するロックは次のとおりです。
| ロック | 止めるもの | 外せるか |
|---|---|---|
| Lock Everything | その日以前のすべての仕訳 | 例外を作れば外せる |
| Lock Tax Return | 税（消費税など）に関わる仕訳 | 例外を作れば外せる |
| Hard Lock | その日以前のすべての仕訳 | 外せない |
Odoo 19のソースコードには、販売だけ・購買だけをロックする日付の項目もあります。決算を監査に出す前は、前の期の最終日でLock Everythingを設定するのがよい進め方だと、公式ドキュメントも勧めています。
Hard Lockは、一度設定すると取り消せません。改ざんできないことを求める国の要件に合わせた仕組みです。日本の中小企業が月次で使うなら、まずはLock Everythingで十分です。
どうしても直すときは「例外」に理由を残す
締めた月に誤りが見つかることはあります。そのときは、会計アプリの管理者が例外を作ります。
- 自分だけか、全員か
- いつまで有効か
- 理由（任意）
この3つを決めて保存すると、内容が会社のレコードのチャター（記録欄）に残ります（出典：同上）。「いつ、誰が、なぜ締めた月を開けたか」が、後から分かる状態です。
受注や発注そのものを、確定後に直させない設定もあります。販売の設定にある「Lock Confirmed Sales」です。有効にすると、確定した受注は編集できなくなります（出典：Odoo公式ドキュメント「Create quotations」、2026年10月確認）。購買にも、確定した発注をロックする設定がOdoo 19のソースコードにあります。
月次決算の流れそのものは、製品を問わない解説として月次決算とは？が参考になります。
誰が何を変えたか：記録と承認で追える状態にする
止める仕組みだけでは足りません。正しい修正も、後から起きるからです。数字が変わったときに理由を追えれば、関係者に聞いて回る作業がなくなります。
会計に関わる変更は、監査証跡で追う
Odoo 19の会計には、監査証跡（Audit Trail）のレポートがあります。会計に関わる項目の変更を、日時・変更者・変更前後の値つきで記録します（出典：Odoo公式ドキュメント「Reporting」、2026年10月確認）。設定で「Restrictive Audit Trail」を有効にすると、記録の対象は削除できず、取り消しかアーカイブだけになります。
監査証跡の仕組みは、Community版の会計モジュールのソースコードにも含まれています。電子帳簿保存法との関係を整理したのが、Odooと電子帳簿保存法です。
取引先や商品の変更は、監査ログで残す
会計の外にあるマスターの変更も、数字を狂わせます。取引先の支払条件が30日から60日に変われば、資金繰りの予定がずれます。
| 日時 | ユーザー | 対象 | 変更内容 |
|---|---|---|---|
| 2026-09-10 14:02 | ai_bot（AI連携用） | 取引先 | 支払条件：30日→60日 |
OCAの「auditlog」は、モデルごとにルールを作り、作成・読み取り・更新・削除を記録するモジュールです。Odoo 19版があり、180日より古い記録を消す定期処理も付いています（出典：OCA server-tools、2026年10月確認）。読み取りの記録は、一部のモデルでは動かないと注記されています。
AI連携用のユーザーを分けておけば、AIが何を変えたかを絞り込めます。保存期間は社内規程に合わせ、こちらも自社でサーバーを運用する形が前提です。
金額の大きい取引は、確定の前に人を通す
止めるか通すかを、人が判断したい取引もあります。購買の設定にある「Purchase Order Approval」は、決めた金額以上の発注に管理者の承認を求める機能です。Odoo 19のソースコードで、Community版の購買モジュールにあることを確かめました。
Enterprise版なら、Studioの承認ルールを使えます。確定などのボタンに承認の段階を付け、承認者と条件を決めます（出典：Odoo公式ドキュメント「Approval rules」、2026年10月確認）。承認の記録は、レコードのチャターに残ります。承認の設計はOdooの承認ワークフロー、AIが作った発注案の扱いはAIに任せてはいけない範囲で扱っています。
仕組みに任せず、人が決めること
ここまでの仕組みは、どれも人が決めた基準で動くものです。ベンチャーネットは、次の3つを仕組みやAIに任せないよう勧めています。
- 基準を決めること：「いつもの量の3倍」「単価の50%」といった線は、業種や得意先で変わる。最初は営業と経理が話し合って決め、月に一度見直す
- 止めたものを解くこと：例外の解除、ロック日付の例外、承認。理由が説明できる人が行う
- 権限を渡しすぎないこと：AI連携用のユーザーには、会計の管理者権限を付けない。ロック日付を変えられる人を増やさない
迷ったときの選び方は、図「止める・知らせる・記録するの使い分け」のとおりです。誤りと言い切れるものだけを止め、判断が要るものは知らせて人が決める。止めすぎると、現場は止まらない抜け道を探し始めます。
正しい数字が、見える化と正のループの土台になる
入口で数字が守られると、Odooの使われ方が変わります。
確定の瞬間に漏れが止まれば、出荷や請求の差し戻しが減る。夜のうちに異常が見つかれば、請求の前に直せる。締めた月が動かなければ、会議の数字は1回で確定します。
ここから、「入力が楽→データがそろう→数字が信頼される→もっと使われる」という正のループが回り始めます。経営会議で数字の正しさを議論しなくてよくなり、数字の意味を話せるようになるからです。
逆に入口が開いたままだと、担当者は毎月、締めた月の数字が変わっていないかを見直すことになります。それ自体が、売上を1円も増やさない仕事です。
正しく計測された数字を、社長が毎朝見る画面にする方法は社長のコックピットをOdooで作るで扱っています。数字を経営に使う考え方は、NBEの「会計がわからんで経営ができるか」が参考になります。
自社の数字の入口を点検するチェックリスト
社内の会議で、次の項目に印を付けてみてください。3つ以上当てはまるなら、入口の仕組みを先に整える効果が大きい会社です。
- □ 確定した伝票に空欄があり、後工程から差し戻されたことがある
- □ 数量や単価の桁ミスに、請求の後で気づいたことがある
- □ 原価を下回る単価の受注が、だれにも気づかれずに通っていた
- □ 締めた月の数字が、翌月に変わったことがある
- □ ロック日付（またはそれに当たる設定）を、月次の締めの手順に入れていない
- □ 取引先の支払条件や単価を、だれが変えたか分からなかったことがある
- □ AIや外部連携のユーザーが、管理者と同じ権限を持っている
- □ 大きな金額の発注が、承認なしで確定できる
数字を正しく計測する仕組みにするまでの進め方
ベンチャーネットが、数字の入口を仕組みにするときの順番です。
- 数字が狂った事例を集める：過去3か月の差し戻し・赤伝票・締め後の修正を並べ、3つの入口のどこから入ったかを分ける
- 入口ごとに止め方を決める：「誤りと言い切れるか」の問いで、止める・知らせる・記録するのどれにするかを、経理と現場で決める
- ルールとコードを作り、複製したデータベースで試す：確定・請求書の作成・取引先の更新など、ふだんの操作が止まらないかまで試す。AIに書かせたコードは人が読む
- 締めの手順にロック日付を入れる：月次の締めのたびに更新する人と、例外を作れる人を決める
- 月に一度、引っかかった件数を見て基準を直す：知らせる件数が多すぎれば基準を緩め、見逃しがあれば厳しくする
最初は、困りごとがいちばん大きい入口を1つ選び、1か月回してから次に進みます。
上場の準備で内部統制まで求められる規模なら、要件はもう一段重くなります。上場に向けた内部統制の考え方は、NetSuiteの教科書のNetSuiteでIPOの内部統制を実現する方法が参考です。
バージョンと機能の更新について
この記事の内容は、2026年10月時点のOdoo 19の公式ドキュメントとソースコードにもとづいています。ロック日付の種類と例外の仕組みは、以前のバージョンから大きく変わりました。古い解説記事にある「アドバイザー以外のロック日付」は、Odoo 19のソースコードにはありません。
自動化ルールのきっかけやコードの書き方も、バージョンアップで変わることがあります。バージョンを上げたら、確定の瞬間に止めるルールと夜間の洗い出しを、複製したデータベースで試し直してください。
よくある質問
Community版でも、この仕組みは作れますか？
大部分は作れます。自動化ルール、スケジュールアクション、購買の承認、監査証跡は、どれもCommunity版のソースコードに含まれる機能です。ロック日付も項目と例外の仕組みはCommunity版にありますが、公式ドキュメントの設定手順は会計アプリの画面で案内されています。Studioでの必須設定と承認ルールはEnterprise版です。
必須項目を増やすと、現場の入力が重くなりませんか？
増やしすぎると重くなります。そのため、常に必須にするより、確定の瞬間だけ止める方法を勧めています。止めるのは、空欄だと後工程が止まる項目だけ。迷う項目は、警告や夜間の洗い出しで知らせます。
締めた後で、締めた月の誤りに気づいたらどうしますか？
会計アプリの管理者がロック日付の例外を作り、理由を残して直します。例外は期間を区切れるため、短くしておけば直した後は元のロックに戻る。例外を使わず、当月に訂正の仕訳を入れる会社もあります。どちらにするかは、顧問税理士と決めておいてください。
Odooで数字の入口を守る仕組みのメリットとデメリットは？
誤りを早く止められる一方で止めすぎには注意が要ります。入力漏れは確定の瞬間に、異常値は夜間の洗い出しで、締め後の修正はロック日付で止められます。自動化ルール・スケジュールアクション・監査証跡は、Community版にもある機能です。一方、コードの保守は別料金で、OCAのモジュールは自社でサーバーを運用する形が前提です（メリットとデメリット）。
AIや外部連携から入るデータも、同じように止まりますか？
ロック日付は、例外を持たないすべてのユーザーに効き、AI連携用のユーザーも同じです。一方、自動化ルールの「On UI change（画面で値を変えたとき）」は、手で変えたときにしか動きません。外部から入る経路で止まるかは、本番の前に試してください。
まとめ：見える化の前に、入口を守る
数字が狂う入口は、入力漏れ・異常値・締め後の修正の3つです。入力漏れは確定の瞬間に止め、異常値は夜のうちに洗い出して人に知らせる。締めた月はロック日付で閉じ、どうしても直すときは理由を残します。
どの仕組みも、Odooの標準機能か、広く使われているモジュールで作れます。難しいのは設定よりも、何を止めて何を人が判断するかの線引きです。その線を経理と現場で決めることが、仕組みづくりの中心になります。
1年後、さくら商事の経営会議では、先月の数字が会議の後に変わることはなくなっているはずです。担当者は朝届いた数件の知らせを確かめるだけで、数字の正しさを疑う時間は消えている。浮いた時間で、粗利の下がった得意先の話ができるようになります。
もう少し詳しく知りたい方へ
締めた月の数字が後から変わる、入力漏れの差し戻しが多いといった悩みがあれば、いまの業務の流れを見ながら、どこで止めるかを一緒に整理します。
あわせて読みたい記事
- ブルシットジョブを消し去る｜国産SaaS×Odoo×AIの組み合わせ術
- 経営の「見える化」とは｜できていない会社に起きる問題と、Odooで社長のコックピットを持つ手順
- Odooの自動化ルールとAIで入力を減らす｜AIフィールド・Ask AI・スマホ・音声の実例
- 予実・資金・売掛金をOdooに見張らせる｜月末に慌てないためのアラート設計
- 経費の異常を人が探さない｜重複請求・単価の値上がりをOdoo×AIで見つける（売上最大・経費最小の実践）
- AIに任せてはいけない範囲｜Odoo×AIの権限・承認・情報漏えい対策
- Odooに入れる前の下ごしらえをAIに任せる｜CSVの文字化け・和暦・「▲」・半角カナをまとめて直す
- Odooの会計機能でできること｜Accountingアプリ解説
- Odoo Studioとは？ノーコードカスタマイズの範囲
- Odoo Community版とEnterprise版の違い｜アプリ別の機能一覧つき
