業務の隙間を埋める技術メモ。

「それ、作れるか？」より 「それ、作って大丈夫か？」を考えたい。 業務で“ちゃんと使える”かどうかを、 実際に手を動かして確かめたログを残しています。

「注文と発注の違い」がNetSuiteでバグる理由 ― 業務を知らないエンジニアが必ずハマる罠

netsuite 発注業務 収益認識 電帳法 J-SOX 受注業務 受注 インボイス

この記事の要点

  • 「注文」は買う側の行為、「発注」は買う側が売る側に正式に注文を出す行為。「受注」はその逆で、売る側が注文を受ける行為
  • NetSuiteのトランザクション「注文書」(Sales Order) は、業務でいう 受注 のこと
  • 翻訳の都合で「注文書」というラベルが付いているだけで、世間一般の「注文書」とは意味が違う
  • 業務知識ゼロのエンジニアが画面ラベルだけ見て実装すると、PDFに自社ロゴが入る悲劇が起きる

「注文と発注の違いって何？」「NetSuiteの注文書ってなんで自社が出してるの？」――こういう疑問を持ったあなたは、まさにこの記事のターゲットです。NetSuiteを触っていて、画面に書かれている「注文書」「発注書」というラベルに違和感を覚えたなら、それは正しい感覚です。NetSuiteの日本語訳には罠があります。

「注文書のPDFイメージ作りました！どうです、完璧でしょ？」

業務を知らないNetSuiteエンジニアと仕事をすると、わりと高確率でこの会話が発生します。

エンジニア「注文書のPDFイメージ作りました！どうです、完璧でしょ？」

私（PDFを開く）

私（絶句）

そこには、宛名が顧客の会社名になっていて、発行元のロゴが堂々と自社になっている「注文書」 が刷り上がっていました。

……いや、これ、誰が誰に出してるPDFなんですか？

自社が、自社のロゴ入りで、顧客に向けて、「あなたから注文します！」って書いた書類を送りつけてるんですよ。意味わからないでしょう。意味わからないものを作ってきたエンジニア本人も、何がおかしいのかピンと来ていません。だってNetSuiteの画面に「注文書」って書いてあるんだから、注文書を作ったつもりなのです。

これは本人だけが悪いんじゃなくて、NetSuiteの日本語訳がそもそも罠を仕掛けてくるんです。今日はその話をします。

まず「注文」「発注」「受注」の違いを整理する

NetSuiteの話に入る前に、業務上の用語を整理しておきます。ここがブレているとNetSuite側の話も理解できないので、念のため。

用語 意味 主体 関連する文書
注文 商品やサービスを買うために依頼すること 買う側 （会話・打診段階）
発注 注文を正式に出すこと。書面で依頼する 買う側 発注書（注文書）を発行
受注 顧客から注文を受けること 売る側 注文請書を発行

「注文」と「発注」は、買う側から見た同じ行為のグラデーションです。カジュアルに言えば「注文」、正式には「発注」。一方「受注」は売る側から見た行為で、注文を受ける側の視点になります。

つまり、1つの取引には常に「発注」と「受注」がペアで存在します。買う側が発注すれば、売る側がそれを受注する。同じ取引を買う側の目線で言えば「発注」、売る側の目線で言えば「受注」というだけの話です。

NetSuiteを使う「自社」は、取引によってこの両側の役割を行き来します。顧客に物を売るときは「受注」する側、仕入先から物を買うときは「発注」する側。NetSuiteはこの両方を同じシステムで扱うので、両者を別のトランザクションタイプとして区別する必要があるわけです。

結論：NetSuiteの「注文書」は「受注」のこと

NetSuiteのトランザクションメニューにある「注文書」は、世間一般で言う「注文書」ではありません。

正しくは「受注」です。

NetSuiteの表記 内部名（英語） 業務上の正しい呼び方 誰が起票するか
注文書 Sales Order 受注 自社（注文を受けた側）
発注書 Purchase Order 発注 自社（注文を出す側）

冒頭の図をもう一回見てください。矢印の向きが真逆になっているところがミソです。同じ「自社」というハコなのに、Sales Orderの世界では自社は受け手で、Purchase Orderの世界では自社は出し手。NetSuiteはこの両方を同じ「自社」のシステム上で扱うので、sales_order と purchase_order という対称的なネーミングで両者を区別しています。

英語ならまあ、わからなくもありません。sales と purchase はきれいに対になっています。

問題は、これを日本語に翻訳した人です。

なぜ「sales_order = 注文書」になってしまったのか

ここからは推測混じりの考察です。

sales_order を素直に訳そうとすると、「販売注文」「販売オーダー」あたりが順当でしょう。実際SAPは「販売伝票」と訳していますし、Oracle EBSは「受注」と訳していました。日本のERPで「販売注文」「受注」と訳されているケースが多数派です。

ところがNetSuiteは「注文書」を選びました。なぜでしょうか。

NetSuiteは、「トランザクション」という一つの「テーブル」に、すべての業務データを種類別に格納しているという特徴があります。受注も発注も、見積も請求書も、入金も支払も、すべて同じ transaction テーブルに type フィールドで区別されて入っている。この設計思想の中で、sales_order と purchase_order はきれいに対になる兄弟概念として扱われます。

その種類の表記でおそらく、purchase_order = 発注書 との対称性を維持したかったのだと思います。sales_order と purchase_order は明確に対の概念なので、訳語も対にしたい。purchase_order を「発注書」と訳した時点で、sales_order は「販売の注文書」になります。これを縮めて「注文書」。対称性は守られた。めでたしめでたし。

……いや、めでたくないです。

「注文書」という日本語は、世間では 「注文する側が発行する書類」 を指す言葉として定着しています。これは商習慣レベルで固まっていて、エンジニアの感覚論ではありません。発注側が「ご注文の品はこれこれです」と書いて取引先に送る、あの紙のことです。

なので、業務経験のあるユーザーや経理担当者は、NetSuiteで「注文書」と書かれていれば「自社が出した発注書類」だと思います。一方、エンジニアは画面に書いてある通りに受け取って「注文書なんだから注文する書類でしょ」と素直に解釈します。両者とも、同じ単語を見て、同じ方向の誤読をします。

そして実際にトランザクションを開いてみると、そこに記録されているのは 顧客から受けた注文の内容 です。「あれ、注文書なのに、なんで自社が売る側になってるんだ？」と混乱が始まります。

「受注」と訳しておいてくれれば何の問題もありませんでした。「注文書」というラベルを選んだ瞬間に、業務知識のあるユーザーと、業務知識のないエンジニアと、その間に挟まれたコンサルタントの三者が、それぞれ別の方向に滑り出すお膳立てが完成してしまったわけです。

📝 COLUMN

日本企業は長らく「受注」をナメてきた

業務知識のないエンジニアが受注と発注を取り違えるのは、確かに本人の勉強不足ではあります。ただ、「日本企業の現場では、そもそも受注業務が長いことちゃんと運用されてこなかった」という構造的な背景もあって、これを知っておくとNetSuite案件で起こりがちなコミュニケーション事故の解像度が上がります。

受注は本来、契約行為である

教科書的に言えば、受注とは 契約行為 です。

買う側と売る側の間で、「これをこの価格でこの納期で売り買いする」という合意が成立した瞬間、そこに契約が発生します。そしてその契約内容を、双方が後から見返しても齟齬がないように静的に固定しておくための文書が、注文書（買う側発行）と注文請書(売る側発行）です。「言った言わない」を防ぐための装置。これが受注業務の本来の姿です。

ところが、日本の商慣習はこれをわりとサラッと飛ばしてきました。

「お客様は神様です」と「一式」と口頭合意

日本の商慣習の特徴を雑に並べると、こうなります。

  • お客様は神様です：顧客の要望は最大限尊重する。受注後に「やっぱりこう変えて」と言われても、できる限り対応する
  • 口頭合意ベース：発注側と受注側に長年の付き合いがあれば、書面より電話やメールの一言で済ませる
  • 「一式」：見積書や注文書の品名欄に「○○工事 一式」とだけ書く慣習。中身の内訳は「現場で詰めましょう」

この三点セットが揃うと何が起きるかというと、受注時点で内容を確定できません。確定できないから、受注伝票を真面目に入力する動機がない。どうせ後で変わるんだから、項目を細かく分けて入力しても無駄になる。せや、「一式 100万円」って入れとこ。これで受注伝票は「入力した」ことになる。

これを長年やってきた業界では、受注伝票は 「契約内容を記録するための文書」 ではなく、「とりあえず売上を立てるためのキー伝票」 という位置づけに堕ちます。中身は空っぽに近い。本物の合意内容は営業担当者の頭の中とメールフォルダにあります。

NetSuiteのような海外製ERPを導入すると、ここで衝突が起きます。Sales Orderには明細行があり、品目コードがあり、数量があり、単価がある。「一式」を入れる場所がない。営業現場は「なんでこんな細かく入力させるんだ、面倒くせえ」と文句を言い、エンジニアは「いやそれが受注業務でしょ？」と困惑する。両者の前提が違いすぎるのです。

IFRSと収益認識基準が「ちゃんとやれ」と言い始めた

この温い文化に外圧がかかり始めたのが、2010年代以降です。

IFRSと原則主義

国際会計基準（IFRS）は 原則主義 で書かれています。「こうしろ」という細則ではなく、「こういう原則で判断しろ」という考え方を示すスタイル。日本基準が長年取ってきた 細則主義（具体的なルールを羅列する）と対照的です。

原則主義は一見ゆるそうに見えますが、実は逆で、企業側が 「自社のビジネスを原則に照らして自分で判断・説明する」 義務を負います。判断の根拠を文書化して開示しないと、監査で詰められる。「うちは慣習でやってます」は通用しません。

そして2018年にIFRS第15号「顧客との契約から生じる収益」が適用され、日本でもこれと整合する企業会計基準第29号「収益認識に関する会計基準」が2021年4月以降の事業年度から強制適用されました。この基準が要求するのは、ざっくり言うとこういうことです。

  1. 顧客との契約を識別する
  2. 契約の中の 履行義務 を識別する
  3. 取引価格を算定する
  4. 履行義務に取引価格を配分する
  5. 履行義務を充足したときに収益を認識する

ここで「契約」と「履行義務」というワードが容赦なく出てきます。「一式 100万円」では履行義務を識別できません。何を売る約束をしているのか明細レベルで分解されていないと、5ステップが回りません。

つまり制度側から、「受注時点で売る内容を細かく確定させて、書面化しろ」という要請が降ってきたわけです。「お客様は神様です」「口頭合意」「一式」のトリオは、この基準の前ではまったく機能しません。

下請法

もう一つの圧力が、下請代金支払遅延等防止法（下請法）です。

下請法では、親事業者が下請事業者に発注するとき、書面の交付 が義務付けられています（第3条）。発注内容、納期、金額、支払期日などを明記した書面を、発注時点で交付しなければなりません。口頭発注は違法。「あとで変えて」と言って金額を一方的に下げるのも違法（買いたたきの禁止）。

この法律自体は昔からありますが、近年は公正取引委員会と中小企業庁の運用が厳しくなっています。違反企業の名前が公表され、業界に激震が走る、というニュースが定期的に流れるようになりました。

下請法は発注側に書面化を強制する法律ですが、これは裏返せば 受注側にとっても書面が来る ということです。受注した側も、その書面と整合する形で社内の受注伝票を入力せざるを得ません。「一式」では取引先から来た発注書面と整合性が取れず、後で監査や調査が入ったときに説明できなくなります。

時代がやっと「受注をちゃんとやれ」に追いついた

IFRS的な収益認識、下請法の厳格化、インボイス制度、電子帳簿保存法。この10年で、日本企業は 受注時点で取引内容を確定させ、書面化し、システムに正確に記録する ことを、制度から要求されるようになりました。

NetSuiteのような海外製ERPは、もともとこの厳格な世界観を前提に設計されています。Sales Orderには明細が必須で、品目マスタが必須で、単価と数量が必須で、税区分が必須。「一式」を許しません。これを「面倒くせえ」と感じる現場感覚は、日本のかつての温い受注業務の名残でしかなくて、制度側から見れば 本来やるべきことをやっと真面目にやり始めた だけの話なのです。

業務未経験のNetSuiteエンジニアが受注と発注を取り違えるのは、本人の勉強不足だけが原因ではありません。そもそも日本の現場には、明細レベルで規律された受注業務の手本が乏しかった という背景もあります。だからこそ今、NetSuiteのようなシステムを通して、改めて「受注とは何か」を学び直さないといけない局面にあるわけです。

「注文書」というラベルに釣られて適当なPDFを作る前に、その伝票が 契約という重い行為を記録している という事実を、まず思い出してください。

トランザクション名としては「注文書」は正しい、という言い分

さて、コラムでだいぶ寄り道しましたが、本筋に戻ります。

ここまで「NetSuiteの『注文書』という訳語はミスリーディングだ」という話をしてきましたが、実はこの訳語、まったく擁護できないわけでもありません。一方的に翻訳した人を悪者にしてきましたが、彼らにも言い分はあります。最後にその言い分を聞いてあげましょう。

NetSuiteの内部に保持されているデータとして見れば、Sales Orderは確かに 「顧客から受けた注文の内容を記載した書類オブジェクト」 であって、書類としては「注文書」と呼ぶに値します。発行元は顧客であり、その内容を自社が記録している、と理解すれば論理的にはおかしくありません。

つまり、「顧客が発行した注文書を、自社のシステムに転記したもの」 がNetSuiteのSales Orderである、という理屈は通ります。

問題は、このロジックを業務知識ゼロのエンジニアは絶対にたどり着けないことです。普通に画面を開いたら「自社が発行する注文書」だと思う。それが冒頭のPDF事故につながります。

ありがちな実装ミス事例集 ― NetSuiteで受注と発注を取り違えると何が起きるか

業務知識の欠落がコードや成果物に染み出してくるパターンを並べておきます。SuiteScriptでカスタマイズしているとき、自分がこれをやっていないか確認してみてください。

事例1：PDFテンプレートのロゴと宛名が逆

冒頭の話です。Advanced PDF/HTML Templatesで Sales Order の帳票を作るとき、

  • 発行者欄に自社ロゴと自社住所を載せる
  • 宛先欄に顧客名を「御中」付きで載せる

これは 業務的には完全に間違い です。Sales Orderは顧客が発行した注文書という建前なので、本来はそのまま帳票化するなら発行者は顧客、宛先は自社になります。

ただし実務では、Sales Orderを元に「注文請書」あるいは「ご注文確認書」を発行するケースが多いです。この場合は自社が発行元、顧客が宛先で正しい。要は何の書類として出力するかを最初に決める必要があります。

「注文書って書いてあるから注文書のPDF作りました」は、その判断を完全にスキップしています。発注したい人がいないのに発注書が出力される世界。

事例2：項目名のマッピング事故

CSVインポートやRESTlet経由でSales Orderを作るとき、フィールド名で混乱します。

// よくある勘違い
const so = record.create({ type: record.Type.SALES_ORDER });
so.setValue({ fieldId: 'entity', value: vendorId }); // ← 仕入先IDを入れてる

entity フィールドはSales Orderの場合「顧客」を指します。Purchase Orderの場合は「仕入先」を指します。同じ entity というフィールド名が、トランザクションタイプによって参照先テーブルが変わるわけです。これを「注文書だから発注先を入れるんだろ」とやると、そもそもSaved Searchですら結合できない謎レコードができあがります。

事例3：承認ワークフローを発注フローで設計してしまう

Sales Orderに対して「金額が一定以上なら部長承認」みたいなワークフローを組む案件は普通にあります。これ自体は問題ありません。問題は、エンジニアが 「これは自社からの発注だから、購買部門の承認が要る」 という前提で要件を聞いてしまうケースです。

実際は受注なので、承認すべきは営業部門の上長か、あるいは与信判断として経理です。購買部門は1ミリも関係ありません。要件ヒアリング時点で「注文書」を発注書だと誤解していると、関係者の選定からして間違います。

事例4：在庫の動きが逆になる

Sales Orderをフルフィルメント（出荷）すると在庫が減ります。Purchase Orderをレシート（入荷）すると在庫が増えます。

これを取り違えて、「注文書（Sales Order）作ったら在庫増えるはずですよね？だって発注したんだから」と聞いてくるエンジニアがいたら、即座に業務研修に送り込んだほうがいいです。Sales Orderは売る予定の予約なので、在庫は減る方向にしか動きません。

事例5：SuiteQLで transaction テーブルを引くときの取り違え

transaction テーブルを WHERE type = 'SalesOrd' で引くか WHERE type = 'PurchOrd' で引くかで、取れるレコードがまったく別物になります。type 値は内部英語名ベースなので、ここは比較的事故りにくい。事故るとしたらラベル側です。

-- 「注文書の一覧を出して」と言われた場合
-- 業務担当者の意図：受注一覧 → SalesOrd
-- エンジニアの誤解：発注一覧 → PurchOrd
SELECT id, tranid, entity, total
FROM transaction
WHERE type = 'SalesOrd'  -- 受注を出すならこっち
ORDER BY trandate DESC;

要件定義の段階で「注文書」とだけ書かれていると、どちらの意味かわかりません。確認せずに作ると半々の確率で外します。

受注・発注の正しい業務理解チェックリスト

NetSuiteで開発に入る前に、最低限ここは押さえておきたいところです。一個でも自信なかったら業務担当者に聞きにいく案件。

  • 「受注」とは、自社が顧客から注文を受けることであり、商品やサービスを売る側の業務である
  • 「発注」とは、自社が仕入先に注文を出すことであり、商品やサービスを買う側の業務である
  • NetSuiteの「注文書」(Sales Order) は、業務でいう受注を記録するトランザクションである
  • NetSuiteの「発注書」(Purchase Order) は、業務でいう発注を記録するトランザクションである
  • Sales Order の entity フィールドは顧客（Customer）を指す
  • Purchase Order の entity フィールドは仕入先（Vendor）を指す
  • Sales Orderから派生する書類は「注文請書」「請求書」「納品書」など、自社が顧客に対して発行するもの
  • Purchase Orderから派生する書類は「発注書」そのもので、自社が仕入先に対して発行するもの
  • Sales Order作成 → 出荷 → 在庫減 という流れになる
  • Purchase Order作成 → 入荷 → 在庫増 という流れになる
  • 「注文書を作ってください」と業務担当者に言われたら、まずどっちの注文書かを確認する

最後の項目が一番大事です。NetSuiteの画面ラベルと業務上の用語にズレがある以上、エンジニアと業務担当者の間で「注文書」という単語が出てきた瞬間、双方が同じものを指しているか確認する癖をつけたほうがいいです。確認しないで作ると、PDFに自社ロゴが入ります。

よくある質問（FAQ）

Q1. 注文と発注の違いは何ですか？

「注文」は商品やサービスを買うために依頼する行為全般を指す広い言葉です。「発注」はそれを正式に書面で依頼すること、つまり発注書（注文書）を発行して取引先に送る行為を指します。日常会話では「注文」、ビジネス文書では「発注」というニュアンスの違いがあります。両者とも 買う側の行為 であり、売る側の行為である「受注」とは対になる概念です。

Q2. 注文書と発注書はどう違いますか？

実は 注文書と発注書は同じものを指す ことが多いです。買う側が売る側に「これを買います」と通知する書類で、発行するのは買う側です。業界によって呼び方が異なるだけで、製造業や建設業では「注文書」、IT業界やサービス業では「発注書」と呼ばれる傾向があります。法律上はどちらも同じ意味を持ちます。

Q3. NetSuiteの「注文書」はなぜ自社が発行する書類になっているのですか？

NetSuiteの「注文書」(Sales Order) は、世間一般の「注文書」とは意味が違います。これは英語の sales_order を翻訳した結果であり、業務上は「受注」を記録するトランザクション です。顧客から受けた注文の内容を自社のシステムに記録するためのもので、発注書（Purchase Order）の対概念として「販売の注文書」という意味合いで「注文書」という訳が当てられました。

Q4. NetSuiteで「受注」を入力したい場合、どのメニューを使えばいいですか？

トランザクション > 販売 > 注文書（Sales Order）を使います。日本語では「注文書」と表記されていますが、これが業務上の「受注」に相当します。顧客から注文を受けたら、このメニューから新規作成して内容を入力します。

Q5. NetSuiteで顧客に注文請書のPDFを送りたい場合は？

Sales Order を元にAdvanced PDF/HTML Templatesでカスタムテンプレートを作成し、「注文請書」または「ご注文確認書」として出力します。発行元は自社、宛先は顧客で正しい構成になります。NetSuite標準の「Sales Order」帳票テンプレートをベースに、書類タイトルと項目を日本の商習慣に合わせて調整するのが一般的です。

Q6. Sales Order と Purchase Order でフィールド名が同じなのに参照先が違うのはなぜですか？

NetSuiteは transaction という単一のテーブルですべての取引を管理しており、entity のような共通フィールドが、トランザクションタイプによって異なる意味を持つ設計になっています。Sales Orderの entity は顧客（Customer）、Purchase Orderの entity は仕入先（Vendor）を指します。SuiteScriptやSuiteQLで扱うときは、必ずトランザクションタイプを意識する必要があります。

まとめ：NetSuite開発で受注と発注を取り違えないために

  • NetSuiteの「注文書」(Sales Order) は 受注 のこと
  • NetSuiteの「発注書」(Purchase Order) は 発注 のこと
  • 翻訳の都合で「注文書」になっているだけで、業務上の「注文書」とはニュアンスが違う
  • 日本企業は長らく「お客様は神様」「口頭合意」「一式」で受注をナメてきたが、IFRS収益認識基準と下請法強化により、明細レベルで規律された受注業務をやらざるを得なくなった
  • NetSuiteはその規律を前提に作られているので、「面倒くせえ」と感じたら自分の業務感覚のほうを疑うべき
  • 業務知識ゼロで画面ラベルだけ見て実装すると、PDFに自社ロゴが入る悲劇が起きる
  • 困ったら 矢印の向き（誰から誰へのトランザクションか）を確認する

NetSuite開発で一番やっかいなのは、SuiteScriptの構文でも、SuiteQLの方言でもなく、こういう業務用語と画面ラベルのズレだったりします。コードを書く前に、トランザクションの矢印の向きを確認しましょう。