Web受発注システムの機能一覧｜注文の流れ別に必要な機能と選び方

◆監修・編集責任者　小園 将隆　2026年11月11日

B2B EC-COLUMN

注文の転記・確認・問い合わせは、受発注のどこで発生しているのか

FAXや電話で届いた注文を基幹システムへ打ち直し、受け付けたことを取引先へ連絡し、数量の変更が来ればまた直す。
受注の担当者の時間は、この転記と確認の繰り返しに取られています。
Web受発注システムの機能は、数の多さではなく、注文の流れのどの作業を置き換えるかで選べます。
注文入力、受注確認、履歴、CSV取込、納期確認はその代表例です。
取引先別の価格や基幹システムとの連携は、取引条件と製品の仕様で必要性が変わります。
取引先が実際に使えるか、取引データを法令に沿って保存できるかも、導入前に確かめておきたい点です。

受注側で挙がる課題

食品の小売・卸売の受注業務担当者を対象にした2023年のネット調査（ハンモック調べ）では、FAX・メール・電話で注文を受けている回答者に、受注業務の課題を複数回答で尋ねています²。
最も多く挙がったのは注文書の手入力で、注文確認の連絡、注文変更への対応が続きました²。
担当者しか処理の仕方が分からない属人化や、注文書の保管も課題として挙がっています²。
この調査は食品の小売・卸売で注文を受ける側の回答なので、他の業種や発注する側の負担の大きさをそのまま表すものではありません。

並んだ課題を一つずつ見ると別々の問題に見えますが、実際には一件の注文の中でつながっています。
FAXが届くと、担当者は注文書を見ながら商品と数量を基幹システムや表計算に打ち込みます。
次に、受け付けたことや納期を電話やFAXで取引先へ返します。
その後に数量の追加や納品日の変更が届けば、元の注文を探し出して打ち直し、もう一度連絡します。
最後に、紙の注文書を綴じて保管します。
手入力、確認の連絡、変更対応、保管は、この一巡の中の別々の場面です。

この構図は食品に限った話ではありません。
中小企業庁のミラサポplusでも、取引の階層の下位にある企業では電話やFAXでのやり取りが多く、手入力による転記ミスや書類紛失のリスクがあると説明されています¹。
注文が紙や音声で届く限り、誰かがそれを読み取り、データに直す作業が必ず挟まります。

自社の滞留点を見つける

機能を比べる前に、自社ではこの一巡のどこに時間がかかっているのかをつかんでおくと、後の判断がぶれにくくなります。
たとえば一定期間、届いた注文ごとに、どの手段で届いたか、誰が何に打ち直したか、確認の連絡をしたか、変更が来たかを簡単に書き留める方法があります。
正確な時間を測ることが目的ではなく、作業がどこに偏っているかを見るための記録です。

記録の結果によって、優先すべき機能は変わります。
注文書の打ち直しに追われているなら、取引先に画面から注文を入れてもらう仕組みが中心になります。
「注文は届いているか」「いつ届くのか」という電話が多いなら、受付の状況や納期を取引先が自分で見られる仕組みの方が効きます。
変更の連絡が多いなら、過去の注文をすぐ探せる履歴と、変更をどこで受け付けるかの決めごとが要になります。

属人化が課題に挙がっている場合は、もう一つ見ておきたいことがあります。
ベテランの担当者は、取引先ごとの商品の呼び方や、取引先ごとに違う単価を頭の中で読み替えていることが少なくありません。
この読み替えはシステムが自動で覚えてくれるものではないため、商品や取引先の情報としてあらかじめ登録できる形に書き出す必要があります。
記録を取る段階で、担当者がどこで読み替えをしているかにも印を付けておくと、導入時の準備がはっきりします。

▼ 図の内容を文字で読む

1. FAXや電話で注文が届く
2. 基幹システムや表計算へ打ち直す
3. 受け付けと納期を取引先へ連絡する
4. 数量や納品日の変更が届く

注文の流れの各段階で、Web受発注システムのどの機能が何を置き換えるのか

入力と受付

機能の名前は製品ごとに違うため、名前ではなく、置き換わる作業で見ていくと比べやすくなります。
一つの例として、日立システムズがSAP向けに提供するWeb受注テンプレートでは、見積（カート・履歴・回答）と、注文（ご注文、注文カート、受注確認、履歴、CSV取込、CSVマッピング）の機能が挙げられ、得意先が納期を確認できるとされています³。
これは特定の基幹システムを前提にした1製品の構成で、すべてのWeb受発注システムが同じ機能を備えているという意味ではありません。

注文カートやご注文の機能は、取引先が画面で商品を選び、数量を入れて送る部分です。
これまで受注担当者がFAXの注文書を見て打ち込んでいた作業が、取引先自身の入力に置き換わります。
ミラサポplusでも、取引データを一元管理でき、手入力のミスも減るとされています¹。

ただし、入力の手間がなくなるのではなく、入力する人が受注側から取引先へ移るという点は押さえておきたいところです。
受注側には、届いた注文の数量が妥当か、出荷できるかを判断する確認が残ります。
取引先には、これまでFAX用紙に書いていた手間の代わりに画面操作の手間が生まれます。
この移った負担を取引先が受け入れてくれるかどうかが、後で触れる定着の問題につながります。

見積の機能は、見積を依頼され、回答し、それが注文へ進む取引で意味を持ちます。
見積の回答から注文までを同じ画面でたどれれば、見積書と注文書を突き合わせる作業が減ります。
一方で、定番品を決まった単価で繰り返し注文してもらう取引が中心なら、見積の機能を使う場面は少なく、優先度は下がります。

確認・履歴・納期回答

受注確認の機能は、注文を受け付けたことを取引先が確かめられる部分です。
注文を受けるたびに「承りました」と電話やFAXで返していた作業が、この機能で置き換わる対象になります。
受け付けたことをメールなどで知らせる形なのか、取引先が画面を見に行く形なのかは製品によって違うため、取引先がどちらなら気づきやすいかを考えて確かめておくとよいでしょう。

履歴の機能は、受注側と取引先の両方の手間に関わります。
取引先は過去の注文を呼び出して同じ内容で注文し直せますし、「先週の注文と同じでいいか」という問い合わせに、受注側が記録を探す手間も減ります。
注意したいのは、履歴が見えることと、画面から変更を受け付けられることは別だという点です。
注文後の数量変更や取り消しを画面で受け付けられない製品であれば、変更は引き続き電話やFAXで届き、受注側が手で直すことになります。

納期確認は、「いつ届くのか」という問い合わせを減らすための機能です。
先の製品の例では、販売管理システムと連携して得意先が納期を確認できるとされています³。
裏返すと、取引先に納期を見せるには、自社の販売管理や基幹システムに納期の情報があり、それがWeb受発注システムへ渡る必要があります。
納期を担当者が都度調べて答えている会社では、機能があっても表示する元の情報がないため、まず社内で納期の情報をどこに持つかを決めることになります。

CSV取込とマッピング

CSV取込は、先の製品では注文の機能の一つとして挙げられています³。
注文の機能の中に並んでいることから、取引先が自社の発注システムや表計算から出した注文データを、画面で一件ずつ入れずにまとめて取り込む場面を想定したものと読めます。
品目数の多い注文を表計算で作っている取引先にとっては、画面で一品ずつ選ぶより手間が少なく、移行してもらいやすくなります。

CSVマッピングは、取引先ごとに違うファイルの列の並びや項目名を、システム側の項目に対応づける機能です。
ここで確かめておきたいのが、対応づけの範囲です。
取引先が自社の品番で注文してくる場合、列の対応がとれても、品番を自社の商品コードに読み替える作業が残ります。
マッピングが列の対応までなのか、商品コードの読み替えまで含むのかで、受注側の確認の手間は大きく変わります。

▼ 図の内容を文字で読む

• 注文の受付
  • 置き換わる作業：FAXの注文書を見て打ち込む（ご注文・注文カート）
  • 残る確認：数量の妥当性と出荷できるか
• 受付の連絡
  • 置き換わる作業：承りましたと電話やFAXで返す（受注確認）
  • 残る確認：メールなどの通知か、画面を見に行く形か
• 過去の注文の照会
  • 置き換わる作業：問い合わせに答えて記録を探す（履歴）
  • 残る確認：数量変更や取り消しを画面で受け付けられるか
• 納期の問い合わせ
  • 置き換わる作業：納期を都度調べて答える（納期確認）
  • 残る確認：基幹側に納期の情報があるか

取引先別の価格・掲載商品や在庫・納期表示は、どんな取引条件で必要になるのか

必要性が変わる条件

取引先ごとに価格や商品を出し分ける機能、在庫を見せる機能は、機能一覧でよく目にする項目です。
ただ、これらは誰にとっても必須というより、自社の取引条件によって必要性が決まる機能だと考えると判断しやすくなります。

価格については、取引先ごとに単価を決めているかどうかが分かれ目です。
たとえば同じ商品でも取引先Aと取引先Bで単価が違う場合、画面に一つの価格しか出せないと、取引先が画面で見た金額と請求の金額が食い違います。
その食い違いを説明する連絡や、請求の段階での手直しが新たに生まれ、システムで減らしたかった確認がかえって増えてしまいます。
全取引先に同じ価格表を使っているなら、取引先ごとの価格設定がなくても困る場面は少ないはずです。

掲載商品も同じように考えられます。
取引先ごとに扱える商品が決まっている、特定の取引先専用の品がある、といった取引では、全商品を一律に見せると、本来は受けられない商品の注文が届き、断りの連絡が必要になります。
どの取引先にも同じ品ぞろえを出しているなら、出し分けの優先度は下がります。

在庫や納期の表示は、欠品や入荷待ちが多く、「在庫はあるか」「いつ出せるか」という問い合わせが多い会社で効果が見込めます。
ここで区別しておきたいのは、在庫のデータが社内の基幹システムにあることと、それを取引先向けの画面に表示する機能があることは別だという点です。
先に挙げた製品の公開ページでは、納期は販売管理システムと連携して得意先が確認できるとされる一方、取引先別の価格や在庫表示についての記載は見当たりません³。
こうした機能の有無や設定できる範囲は、製品ごとに違うものとして扱う方が安全です。

提供元に確認する項目

取引先別の価格や在庫表示が必要だと判断した場合は、機能が「ある」かどうかだけでなく、どの単位で設定できるかを聞いておくと、導入後のずれを防ぎやすくなります。

• 価格を設定できる単位（取引先ごと、取引先のグループごと、数量に応じた単価など）
• 掲載商品を絞り込める単位（取引先ごと、グループごとなど）
• 在庫・納期の表示がどこの情報を元にしているか（基幹システムから取り込むのか、画面で手入力して更新するのか）と、更新されるタイミング
• 単価や掲載商品を変えるとき、誰がどの画面で変更するのか

最後の項目は見落とされやすいところです。
単価を基幹システムで管理していて、Web受発注システムにも別に単価を登録する形になると、単価を変えるたびに二か所を直すことになります。
どちらか一方を直し忘れれば、画面の価格と請求の価格がずれます。
注文の転記を減らすつもりが、価格表の転記という別の手作業を生むことになるため、価格の情報をどちらで持ち、どう反映させるかは連携の話と一緒に考えておく必要があります。

基幹システム・会計・EDIとの連携は、どこまで必要か

連携の方式と前提

取引先が画面から注文を入れてくれるようになっても、その受注データを受注担当者が基幹システムへ手で打ち直していれば、転記する場所が変わっただけです。
連携が必要かどうかは、Web受発注システムで受けた注文が、打ち直しなしに出荷や請求の処理までつながるかという点で判断します。

まず、自社がどんな仕組みで受注から出荷・請求を管理しているかで前提が分かれます。
基幹システムを使わず、表計算で受注を管理しているなら、Web受発注システムの中で受注や出荷の状況まで管理できるかが論点になります。
販売管理などの基幹システムを使っているなら、受注データをどう渡すかが論点です。
渡し方としては、ファイルを書き出して基幹システムに取り込む方法と、システム同士を直接つなぐ方法があります。

直接つなぐ方法の一例として、先の日立システムズの製品はSAPとの連携が組み込み済みで、新たなインターフェース開発は不要とされています³。
同時に、標準の導入期間や費用はカスタマイズをしないことなどが条件で、変更には別途プログラムの修正が必要とされています³。
この例から読み取れるのは、自社の基幹システムに合わせて連携が用意されている製品なら追加の開発を抑えやすく、標準から外れる変更を加えると期間と費用が増えるという関係です。
この製品の条件は特定の基幹システムを前提にしたもので、Web受発注システム全般の相場を示すものではありません。

ファイルの書き出しと取り込みで済ませる場合は、誰がどの頻度で取り込むのか、取り込んだ後に注文の変更が来たらどちらを直すのかを決めておく必要があります。
変更をWeb受発注システムで受けたのに、基幹システム側だけが古い内容のままになると、二つの仕組みで注文の内容が食い違います。
会計システムとの関係は、売上や請求のデータがすでに基幹システムから会計へ流れているなら、Web受発注システムを会計と直接つながなくても足りる場合があります。
受注から会計までのデータがどの順にどこを通るかを書き出すと、どこをつなぐ必要があるかが見えてきます。

共通EDI標準とは

EDIは、企業同士が注文などの取引データを、決められた形式で電子的にやり取りする仕組みです。
取引先がすでに自社のシステムから発注データを出せる場合、Web画面に入力し直してもらうより、データのまま受け取る方が取引先の手間は少なくなります。

中小企業向けには、中小企業共通EDI標準が2018年に初版として公開されています¹。
国連CEFACTという国際的な取引データの共通辞書に準拠し、仕様書、メッセージガイドライン、実装ガイドラインで構成されています¹。
仕様書では、注文メッセージの項目と、業務アプリケーションに最低限求める項目が定められています¹。
ここでの説明は公開当初の初版についてのもので、その後の改訂の状況や対応する製品は、公開元の最新の情報で確かめる必要があります。

この標準が意味を持つのは、データの形式を取引先ごとにそろえ直す手間を減らせるからです。
取引先ごとに独自の形式でデータを受けると、取引先が増えるたびに対応づけの作業が増えます。
ただし、ミラサポplusでは、EDIは1社だけでは効果が出ず、取引先の状況を考慮して連携して導入する必要があると説明されています¹。
受け手の自社だけが準備しても、取引先の側がデータを出せなければ使われません。
データでの受け取りを考えるときも、結局は取引先ごとの事情に戻ってくることになります。

▼ 図の内容を文字で読む

1. 取引先の注文入力
   • 画面から注文する
   • CSVやEDIでデータのまま渡す
2. Web受発注システム
   • 基幹システムと未連携なら受注の打ち直しが残る
3. 基幹システム
   • 連携していれば納期の情報を返せる
   • 変更をどちらで直すかを決めておく
4. 会計
   • 売上や請求のデータが基幹から流れていれば直接つながなくても足りる場合がある

取引先に使い続けてもらうには、FAX・電話との併存をどう考えるか

併存の実態

先の食品の小売・卸売の受注担当者への調査では、受注方法を複数回答で尋ねたところ、FAXが最も多く、受発注システム、メール、電話が続いています²。
受発注システムを使っている会社でも、FAXや電話での注文が同時に届いている様子がうかがえます。
この結果は食品の小売・卸売の受注側の回答で、システムの導入率や、導入後にどれだけ使われているかを示すものではありません。
それでも、Web受発注システムを入れた時点で注文の窓口が一本になるとは考えにくいことは読み取れます。

複数の窓口が残ると、別の手間が生まれます。
FAXで届いた注文とWebで届いた注文が別々の場所にたまると、「あの取引先の注文はどこにあるか」を探す作業が増えます。
取引先が念のためFAXでも同じ注文を送ってくれば、二重に受けてしまうおそれもあります。
そこで、窓口は複数でも、注文の記録はどこに集めるのかを先に決めておくことが大切です。
FAXや電話で受けた注文を、受注側が代わりにWeb受発注システムへ登録できるかは、製品を選ぶ段階で確かめておきたい点です。
登録できれば、窓口が混在していても履歴は一か所で追えます。

取引先ごとの移行順序

全取引先に一度にWeb受発注へ切り替えてもらおうとすると、操作に慣れない取引先からの問い合わせが一度に集中し、受注側の負担がかえって増えかねません。
取引先ごとに順番を決め、少しずつ移っていく進め方の方が、受注側の手間を見ながら調整できます。

順番を決める手掛かりとしては、注文の頻度、一回の品目数、変更の多さ、取引先の担当者がパソコンで作業できる環境かどうかが考えられます。
たとえば、定番品をほぼ毎日FAXで注文してくる取引先は、履歴から同じ注文を呼び出せる画面の便利さを感じてもらいやすく、受注側の転記も多く減ります。
反対に、注文がまれで、発注担当者が現場作業と兼務していて画面操作の時間を取りにくい取引先は、無理に移さずFAXを続けてもらう判断もありえます。

取引先に移行をお願いするときは、取引先の側で何が楽になるのかを具体的に伝えることが助けになります。
受付の状況や納期が画面で見られれば、取引先は確認の電話をかけずに済みます。
一方で、取引先は複数の仕入先とやり取りしていることが多く、仕入先ごとに別の画面やIDを覚える負担が重なることもあります。
取引先が自社の発注システムからデータを出せるなら、画面入力ではなく、前の節で触れたCSVやEDIでの受け取りを選ぶ方が、取引先にとっての負担は小さくなります。

Web受発注システムで受け渡すデータは、電子帳簿保存法の保存対象になるのか

電子取引の範囲

機能を選ぶときに、法令の観点も一つ加えておく必要があります。
国税庁の電子帳簿保存法一問一答（電子取引関係）では、電子取引の具体例として、EDI取引や、インターネット上のサイトを通じた取引情報の授受などが挙げられています⁴。
そして、電子取引の取引情報は電磁的記録などで保存する制度とされています⁴。

Web受発注システムは、取引先が画面から注文を送り、受注側が受注確認を返す、まさにサイトを通じた取引情報のやり取りです。
そのため、システムで受け取った注文や、返した受注確認のデータは、電子取引の取引情報として保存を考える対象になりえます。
FAXや電話の窓口が併存している場合は、同じ取引先の注文でも受け取り方が違うため、それぞれの保存の扱いを確かめておくと後で慌てずに済みます。

システムに確認すること

どのような条件で保存すればよいかという細かな要件や、経過的な取り扱いについては、本記事では断定しません。
国税庁の電子取引関係の一問一答で最新の版を確認し、必要に応じて税理士や社内の経理担当と整理することをおすすめします。
そのうえで、システムの側に何ができるかを提供元に聞いておくと、要件と照らし合わせやすくなります。

実務として確かめておきたいのは、次のような点です。

• 注文や受注確認のデータを、どの期間システムに残せるか
• 取引先、日付、金額などで、後から目的の取引を取り出せるか
• データを書き出して自社で保存できるか
• 注文の変更や取り消しをしたとき、元の内容と変更の記録が残るか
• 契約を終えるときや別の製品へ移るときに、過去のデータを持ち出せるか

とくに最後の点は、導入時には意識されにくいものです。
システムの中にデータが残っているだけで足りるのか、自社でも保存しておく必要があるのかは、要件を確かめた上で決める事柄です。
データを書き出せない製品だと、その判断の選択肢が狭まります。

必須機能と後回しにできる機能は、どう仕分けるか

判断の順序

ここまで見てきた機能を、導入前の判断として並べ直します。
機能一覧を上から順に「あるか、ないか」で見ていくと、多機能な製品ほど良く見えますが、取引先に使われない機能や、自社の取引条件では出番のない機能まで選ぶことになりがちです。
そこで、次の順に絞り込む方法を提案します。

1. 自社の負担が大きい作業はどこか（転記、確認の連絡、変更対応、問い合わせ）
2. 移行の初めに使ってもらう取引先が、どの入力方法なら使えるか（画面、CSV、EDI）
3. 基幹システムとの連携と、取引データの保存をどこまで満たす必要があるか

この三つの問いに答えていくと、機能は大きく三つに分かれます。
負担の大きい作業を置き換え、最初に移る取引先が使う機能は必須です。
今の取引条件では使う場面が少ない機能は後回しにできます。
取引条件や製品の仕様で答えが変わる機能、法令の確認が要る項目は要確認として残し、提供元や経理との確認に回します。

後回しにする機能については、後から追加できるかどうかも聞いておくとよいでしょう。
先の製品の例のように、標準から外れる変更には別途プログラムの修正が必要とされている場合³、後から機能を足すことが設定の変更で済むのか、追加の開発になるのかで、期間も費用も変わります。

たとえば、定番品をFAXで毎日のように受け、単価を取引先ごとに決めている卸売の会社を考えてみます。
この場合、注文入力、受注確認、履歴は必須になり、単価が取引先ごとに違うので取引先別の価格設定も必須に入ります。
見積から注文へ進む取引が少なければ見積の機能は後回しにでき、欠品の問い合わせがどれだけあるか次第で在庫表示は要確認になります。
同じ機能でも、取引条件が違えば仕分けの結果は変わります。

仕分け表

機能ごとに、必須に寄せる場面と後回しにできる場面、連携や保存の面で確かめることを整理すると次のようになります。
表は編集上の整理で、各製品に機能があるかどうかや費用は、提供元への確認が前提です。

表の中で判断が最も分かれるのは、取引先別の価格・掲載商品と基幹システム連携です。
どちらも、自社の取引条件や使っている仕組みによって、必須にも後回しにもなります。
反対に、注文入力と受注確認は、転記と確認の連絡という負担の中心に直接当たるため、後回しにする理由が見つかりにくい機能です。
迷ったときは、最初に洗い出した自社の滞留点に戻り、その機能がどの作業を減らすのかを一つずつ言葉にしてみると、必要かどうかの答えが出やすくなります。

▼ 図の内容を文字で読む

1. 自社の負担が大きい作業を確かめる
   • 転記・確認の連絡・変更対応・問い合わせ
2. 最初に移る取引先の入力方法を確かめる
   • 画面・CSV・EDI
3. 連携と取引データの保存の要否を確かめる
   • 基幹システムとの連携
   • 取引データの保存
4. 機能を仕分ける
   • 必須：負担の大きい作業を置き換え、最初に移る取引先が使う機能
   • 後回し：今の取引条件では使う場面が少ない機能
   • 要確認：取引条件や製品の仕様、法令の確認で答えが変わる機能

自社の負担がどの作業にあり、どの取引先から移ってもらうかは、社内の記録や取引先ごとの事情を並べてみないと判断しにくく、機能一覧だけでは絞り込めません。

今の注文の受け方と取引先の状況をもとに、どの機能を必須にし、どれを後回しや要確認にするかを一緒に整理できます。無料相談で要件を整理する

要点の整理

軸	基準
自社の負担	転記・確認の連絡・変更対応・問い合わせのどこに時間がかかっているかで、必須の機能を決める
取引先の対応	最初に移ってもらう取引先が、画面・CSV・EDIのどれなら使えるかで入力方法を選ぶ
取引条件	取引先ごとに単価や品目が違うか、欠品の問い合わせが多いかで、出し分けや在庫表示の要否を決める
基幹連携	受注を基幹へ打ち直しているか、注文変更をどちらで直すかで、連携の方式を判断する
データ保存	国税庁の資料で要件を確かめ、データの保持期間・取り出し・書き出しを提供元に確認する

取引先別の価格や基幹システムとの連携、データの保存は、取引条件と使っている仕組みで答えが変わり、製品の資料だけでは自社に当てはまるかが見えにくい部分です。 自社の取引条件と既存の仕組みに照らして、提供元に何を確認すればよいか、どこで手入力が残りそうかを相談の中で確かめられます。

よくある質問

Web受発注システムを入れたら、FAXや電話の注文は受けられなくなりますか。

システムを入れても、FAXや電話で注文を受けること自体ができなくなるわけではありません。
どの窓口を残すかは運用の決め方次第です。
食品の小売・卸売の受注担当者への調査でも、受注方法としてFAX、受発注システム、メール、電話が併用されている様子がうかがえます²。
併存させる場合は、FAXや電話で受けた注文も同じシステムに登録できるかを確かめ、履歴を一か所に集められるようにしておくと、注文を探す手間や二重受注を防ぎやすくなります。

取引先がシステムを使ってくれないときは、どう進めればよいですか。

全取引先を一度に移すのではなく、注文の頻度が高い取引先や、品目が多く転記の負担が大きい取引先から順に移ってもらう方法があります。
その際は、受付状況や納期を画面で確認でき、確認の電話が不要になるなど、取引先側で楽になる点を具体的に伝えることが助けになります。
取引先が自社のシステムから発注データを出せるなら、画面入力ではなくCSVやEDIでの受け取りを検討する方が、取引先の負担は小さくなります。
EDIは1社だけでは効果が出ず、取引先の状況を考慮して導入する必要があるとも説明されています¹。

注文データをCSVで基幹システムに取り込むだけでも、連携として足りますか。

取り込みの頻度と注文変更の扱いを決められれば、足りる場合もあります。
確かめたいのは、誰がどのタイミングで取り込むのか、取り込んだ後に変更が来たらどちらのシステムを直すのか、取引先の品番と自社の商品コードの読み替えをどこで行うのかという点です。
変更が多い取引で取り込みが一日に一度などに限られると、二つのシステムで注文の内容がずれやすくなります。
ずれを直す作業が多くなるようなら、直接つなぐ方式を検討する理由になります。

受発注システム経由の注文データは、電子帳簿保存法でどう保存すればよいですか。

国税庁は、EDI取引やインターネット上のサイトを通じた取引情報の授受を電子取引の例に挙げ、電子取引の取引情報は電磁的記録などで保存する制度としています⁴。
Web受発注システムで受け取った注文や返した受注確認のデータも、この対象になりえます。
具体的な保存の要件や経過的な取り扱いは、国税庁の電子取引関係の一問一答で最新の版を確認してください。
あわせて、システムでデータをどの期間残せるか、後から取り出せるか、書き出して自社で保存できるかを提供元に確かめておくと、要件と照らし合わせやすくなります。

取引先別の価格設定は、取引先が少なくても必要ですか。

取引先の数より、取引先ごとに単価が違うかどうかで判断します。
取引先が少なくても単価が取引先ごとに違えば、画面に一つの価格しか出せない仕組みでは、取引先が見た金額と請求の金額が食い違い、説明や手直しの連絡が生まれます。
全取引先に同じ価格表を使っているなら、取引先が多くても優先度は下がります。
必要な場合は、価格を設定できる単位と、単価を変えるときにどこで直すのかを提供元に確認しておくと、二か所での価格の更新を避けやすくなります。

1. 1　出典：中小企業庁（ミラサポplus）「中小企業共通EDIの概要」（2018年）
2. 2　出典：株式会社ハンモック「食品業の受注業務に関する実態調査」（2023年）
3. 3　出典：株式会社日立システムズ「Web受注テンプレート（SAPソリューション）」（2026年）
4. 4　出典：国税庁「電子帳簿保存法一問一答【電子取引関係】Ⅰ通則」（2026年）