SOLUTION 09

FAX・電話・Excelで
受けている注文を、
取引先がWebで
入れる形に。

受注・在庫・出荷・請求のデータを、ひとつの仕組みでつなぎます。既製のサービスで足りる業務はそれを使い、合わない部分は専用のWebアプリとして作ります。卸・メーカー・商社など、取引先から注文を受けて出荷する業務が対象です。

受注管理在庫管理出荷管理請求データ出力取引先の注文画面会計・販売管理との連携
Web注文取引先がスマホ・PCでFAX担当者が一覧に入力電話担当者が一覧に入力受注一覧取引先経路在庫出荷A社B社C社D社E社WebFAX電話WebFAX引当済引当済引当済不足引当済出荷待ち出荷済出荷待ち入荷待ち出荷済FAX・電話の注文も、同じ一覧で扱います受注在庫の引き当て出荷請求データ

取引先はWebで注文し、FAXや電話の注文も同じ一覧に入ります。在庫の引き当てから請求データまで、同じデータで進みます。

※ 画面はイメージです

Interactive demo

触って確かめる、4本のデモ

どれも架空の会社・データで作った、操作できるモックです。スマホでもPCでも開けます。入力した内容はそのページの中だけで使い、どこにも送信しません。

1注文(A社)K-10210M-2105S-0152注文を確定する2受注一覧A社Web受付B社FAX在庫引当済C社電話出荷待ちA社Web出荷済D社Web在庫不足3在庫・出荷在庫引当残り品番K-10266660M-210918S-015012−12ピッキング・出荷4請求データ9月分・月末締めA社B社C社CSVを出力請求書
01 取引先の注文から、請求データまで
A社として注文を入れ、受注一覧・在庫の引き当て・出荷・請求データの出力まで、同じデータで進めます。足りない品目が出たときの分納も試せます。
Excel版(いま)探す転記転記アプリ版(仕組み化後)自動自動操作自動自動
02 同じ注文を、Excelとアプリで比べる
電話で届いた1件を両方のやり方で月末の請求まで処理し、人の手に残る作業と自動になる作業を見比べます。
受注の記録受注日10/9出荷予定日10/15自動次回の締め日10/30自動2026年10月日月火水木金土123456789受注101112131415出荷161718192021222324252627282930締め31
03 締め日と出荷予定日の自動計算
受注日を入れると、土日・祝日を除いたN営業日後の出荷予定日と、取引先ごとの締め日が入ります(kintoneプラグインの例)。
123456
04 注文書の読み取り
メールで届いた注文書(PDF)から品番・数量・単価を抜き出し、マスタや価格表と合わない項目だけを人が確かめて確定します。
デモを見ながら、相談できます
今の注文の受け方と取引先ごとの違いを伺い、既製のサービスで足りる部分と、作る部分を一緒に切り分けます。

※ デモの会社名・品目・数量・金額はすべて架空で、実在の企業・取引先・商品とは関係ありません。実際のシステムの画面をそのまま再現したものではなく、形と流れを伝えるためのイメージです。注文書の読み取りのデモは、画像の読み取りを実際には行わず、用意した読み取り結果を段階ごとに表示しています。

Challenges

対象は、こうした手作業が残っている受発注・在庫です

受注・在庫・出荷・請求のあいだを人の手でつないでいる限り、取引が増えるほど手間も人も増えていきます。一つでも当てはまる業務から始められます。

FAXの注文を、
Excelに打ち直している
届いたFAXを見ながら、品番・数量・納期を手で入力している。読み違いや入力漏れは、出荷の段階まで見つけにくい。
電話で受けた注文が、
メモのまま回っている
受けた人のメモと記憶が頼りで、誰がいつ何を受けたかを後から確かめられない。
取引先ごとに、注文の形が違うFAX、メール添付のExcel、電話と、取引先ごとに書式も項目も違い、そろえる作業が毎回発生する。
在庫数が、現物と合わない出荷や入荷の反映が後回しになり、表の在庫と棚の数がずれる。棚卸しのたびに差を埋めている。
出荷漏れに気づくのが遅い受注と出荷を別々の表で管理していて、出したかどうかの確認が人の目に頼っている。
担当者しか触れないマクロがある受注表や在庫表のマクロを作った人しか直せず、その人が不在だと作業が止まる。
月末の請求で、
突き合わせに追われる
受注・出荷・請求が別々の表にあり、月末に一件ずつ照らし合わせて請求書を作っている。
在庫の問い合わせに、
すぐ答えられない
取引先から在庫を聞かれるたびに、倉庫や担当者に確かめてから折り返している。

Selection

どの作り方を勧めるかは、業務と取引先の事情で決めます

受発注の仕組みは、既製の受発注サービスを使う、kintoneなどで組む、専用のWebアプリを作る、の3通りで考えます。当社は特定の製品の販売代理店ではないため、既製のサービスで足りる業務にはそちらをお勧めします。

向いている場合 取引先の注文画面 項目・画面の変更 費用のかかり方
既製の受発注サービス 業務の流れが標準的で、取引先もそのサービスの画面で注文してくれる場合。早く使い始めたい場合。 サービスが用意した画面を使う。 サービスの設定で変えられる範囲まで。 月額の利用料。利用者数や取引の量に応じて増える料金のものがある。
kintoneなどで組む まず社内の受注・在庫の台帳を一つにまとめたい場合。社内で項目や一覧を直しながら使いたい場合。 取引先に入力してもらう画面は、外部公開のためのプラグインや連携サービスを組み合わせて用意する。 項目・一覧・集計の追加は、社内で直せる。 利用人数に応じた月額のライセンスと、構築の費用。
専用のWebアプリ 取引先ごとの品目・単価・締め日・注文の形など例外が多く、既製品に合わせると業務が回らない場合。今の販売管理や会計を残したまま、足りない部分だけ足したい場合。 取引先ごとの品目と単価に合わせた画面を作る。スマホからも入力できる。 業務に合わせて作る。変更の手順と、誰が直すかを最初に決める。 開発の費用と、公開後の保守の費用。人数が増えても、人数分の利用料が増えない作り方にできる。

専用のWebアプリは、AI(Claude Code)を使って作ります。既製のサービスでは業務に合わず、一から作る従来の開発では費用と時間がかさむ、という場合のための作り方です。画面を先に作って触っていただき、使い勝手を確かめながら進めます。

※ 既製のサービスとkintoneの料金・機能は、各提供元の最新の情報をご確認ください。

作り方ごとの詳しいページ

LP業務ツール導入・活用支援既製のサービスやkintone・Salesforceなどを、業務に合うかで比べて選ぶ
LPkintone 導入支援kintoneで受注・在庫の台帳を組む場合の設計・構築・内製化
PRODUCTkintone プラグイン自動採番・バーコード読み取り・締め日計算・CSV取り込みなど、自社開発のプラグイン
LPシステム統合・基幹刷新今の販売管理・会計・基幹システムを残したまま、つなぐ・段階的に移す
CASE紙の点検・報告をkintoneへ設備管理業|紙の点検表とExcelの報告書を、スマホで入力するアプリに
BLOGSaaS×Webアプリの自社実践当社が自社の業務で、SaaSと自社開発のWebアプリをどう組み合わせているか

Features

取引先の注文から請求データまでを、ひとつながりで扱います

受発注の仕組みを作った場合の画面の例です。画面の数や項目は、業務と取引先に合わせて決めます。メーカーでは、部品表(BOM)・在庫・購買をまとめて扱う形にもできます。

ご注文A社 様前回の注文を呼び出すK-102 詰替ボトル12本入 ¥4,80010M-210 保存容器24個入 ¥6,0005S-015 ラベル500枚入 ¥1,5002納品希望日 10月3日注文を確定する取引先の注文画面取引先ごとの品目と単価取り決めた単価で表示スマホ・PCから注文受付時間を気にせず入力前回の注文を呼び出し同じ注文は数量を直すだけ確定すると受注一覧へ社内での打ち直しが要らない
1. 取引先の注文画面
取引先は、自社向けの品目と単価が入った画面から、スマホやPCで注文します。

※ 画面はイメージです

受注一覧経路:すべて ▾すべて未処理出荷待ち出荷済受注番号取引先経路納品希望日品目数状態O-1043O-1042O-1041O-1040O-1039O-1038A社B社C社A社D社E社10/0310/0310/0210/0210/0110/01352416WebFAX電話WebWebFAX受付在庫引当済出荷待ち出荷済在庫不足出荷済FAX・電話の注文は担当者がこの一覧に入力。Webの注文は自動で並びます
2. 受注一覧
Web・FAX・電話の注文が同じ一覧に並び、受付から出荷までの状態が分かります。

※ 画面はイメージです

在庫・出荷引き当てを自動計算在庫(品番ごと)品番品名在庫引当残り状態K-102詰替ボトル66660M-210保存容器918S-015ラベル012−12十分残少不足本日の出荷O-1040 A社出荷済O-1041 C社梱包待ちO-1042 B社ピッキング待ち出荷伝票をまとめて印刷要発注・入荷予定S-015 不足 12入荷予定 10月2日M-210 残り 8発注点を下回っています
3. 在庫・出荷
受注に在庫を引き当て、足りない品目や出荷待ちの注文を一覧で確かめます。

※ 画面はイメージです

請求データの出力締め日:月末対象:9月分(出荷済のみ)取引先:すべてCSVを出力取引先出荷件数税抜金額消費税合計A社18432,00043,200475,200B社9128,40012,840141,240C社12256,80025,680282,480計39817,20081,720898,920出力の形会計ソフト用CSV請求書(PDF)販売管理・会計へ連携締め日・端数の処理は取引先ごとに設定できます
4. 請求データの出力
締め日ごとに出荷済みの明細をまとめ、会計や請求書発行に渡すデータを出します。

※ 画面はイメージです

この4画面は、デモで触れます
A社として注文を入れ、受注一覧・在庫の引き当て・出荷・請求データの出力まで、同じデータで進みます。上の4画面と同じ架空の取引先・品目で試せます。

引き渡すもの(範囲は見積りの段階で決めます)

  • 取引先が使う注文の画面と、社内で使う受注・在庫・出荷の画面
  • 操作の手順(社内の担当者向け・取引先向け)
  • データの定義(項目・マスタ・つなぐ先と受け渡すデータの一覧)
  • 今のExcelや台帳から移した、取引先・品目・在庫のデータ

Case

受注・在庫・発注の情報を、一か所で見られるようにした事例

公開している導入事例から、受発注・在庫に近いものを要約しました。詳しい経緯は各事例ページに掲載しています。

出版系企業|在庫・受注
課題
編集・印刷入稿・在庫・受注が別々のシステムにあり、照合を手作業で行っていた(週に十数時間)。欠品に後から気づくこともあった。
打ち手
既存のERP・在庫・受注システムは残したまま、制作カレンダーの機能を開発してAPIでつなぎ、在庫・受注と一画面で見られるようにした。
変化
制作・在庫・受注を一画面で確認できるようになり、手作業の照合が減った。在庫と受注の連携で、欠品の見落としも減った。
既存ERPとAPI連携段階的な接続在庫・受注
卸売業|請求書・発注書の取り込み
課題
取引先からPDFやメールで届く請求書・発注書を、会計・在庫システムへ手で転記していた。書式は取引先ごとに違い、締め期に作業が集中していた。
打ち手
RPAで書類の読み取りと、会計・在庫システムへの転記を自動化。書式がそろった取引先から順に対象にし、読み取れないものは担当者に回した。
変化
入力工数が約60%減り、ダブルチェックを例外に絞れるようになった。締め期の負荷が軽くなった。
RPAPDF・メールの取り込み会計・在庫システム
建設・工事会社|資材の発注
課題
工程表・シフト・資材発注を現場ごとのExcelで管理し、既存ERPとつながっていなかった。本社が発注状況をつかみにくく、発注漏れや二重発注が起きていた。
打ち手
既存のERP・資材発注システムとAPIでつなぎ、工程表・シフト・資材を一画面に。工程を登録すると、資材の発注予定が示される仕組みも整えた。
変化
現場と本社が同じ画面で状況を見られるようになり、発注漏れや手戻りが減った。現場への確認の電話も減った。
既存ERPとAPI連携工程・資材現場と本社で共有

※ 各事例ページの本文を要約しています。事例ページは実際の導入事例をもとに、企業名を伏せ、表現を調整して構成したものです。

事例ページ

CASE刊行予定と在庫の見落としを解消出版系企業|制作カレンダーとERP・在庫・受注の接続
CASE請求書・発注書をRPAで取り込み卸売業|RPAで会計・在庫システムへ転記
CASE工程表・シフト・資材を一画面に建設・工事|発注漏れと手戻りの削減

Pricing

費用と期間は、画面の数・つなぐ先・使う人数・移すデータで変わります

相場が分からない段階でのご相談も受けています。金額を左右する4つの要素と、最初の見積りまでに伺う内容をまとめました。

SCREENS

画面の数

取引先の注文画面、社内の受注・在庫・出荷の画面、帳票の数。取引先ごとの例外(品目・単価・締め日)が多いほど増えます。

CONNECT

つなぐ先

今の販売管理・会計・倉庫のシステムやECサイトなど、データを受け渡す相手の数と、受け渡しの方法(API・CSVなど)。

USERS

使う人数

社内で使う人数と、注文を入れる取引先の数。既製のサービスやkintoneでは、利用料にも関わります。

DATA

移すデータ

取引先・品目・単価・在庫など、今のExcelや台帳から移すデータの量と、整理が要るかどうか。

最初の見積りまでに伺うこと

  • 今の注文の受け方(FAX・電話・メール・Excel)と、1か月あたりのおおよその件数
  • 取引先の数と、取引先ごとに違う点(品目・単価・締め日・注文の書式)
  • 扱う品目の数と、在庫を置いている場所
  • 今使っている販売管理・会計・在庫の仕組みと、残したいもの
  • いちばん手間のかかっている作業と、いつまでに変えたいか
  • 予算の考え方(決まっていなくても構いません)

期間も、同じ4つの要素で変わります。1つの業務から始める場合は、その業務を動かし始めるまでを範囲にして見積もります。

費用は、上の内容を伺ったうえでお見積りします。当社全体の目安は、小規模な自動化なら数万円〜、中規模のシステム統合なら数十万円〜、長期の伴走は月額制です。期間は、小さな1業務の仕組み化で1〜2か月、複数部門にまたがる連携で3〜6か月がひとつの目安です(要件によって変わります)。

Process

業務を1つ選び、画面を先に触っていただいてから広げます

今のFAX・電話・Excelの運用は、切り替えるまで止めません。

1

業務を1つ選ぶ

受注の入口・在庫の引き当て・請求データの作成など、手間の大きい業務を1つ選び、今のやり方と帳票を伺います。

2

画面を先に作って触っていただく

取引先の注文画面と社内の画面を先に作り、いつもの注文を入れて試していただきます。項目や手順はここで直します。

3

今のやり方と並行して動かす

FAX・電話・Excelの運用と並行して動かし、受注・在庫・請求の数字が合うかを確かめます。取引先は移れるところから順に切り替えます。

4

切り替えて、保守を続ける

並行運用で問題がなければ切り替えます。項目の追加などの変更と保守は、最初に決めた範囲で続けます。

FAQ

よくあるご質問

補助金は使えますか?

使える制度があるかは、制度の年度ごとの要件と、会社の条件、導入するものの種類(既製のサービスか、専用に作るものか)で変わります。断定はせず、見積りと並行して、使える制度があるかの確認からご一緒します。

今使っている販売管理や会計ソフトとつなげられますか?

つなぐ先がAPIやCSVでデータを受け渡せるかを、最初に確かめます。今の販売管理や会計を残したまま、注文の入口と在庫・出荷の部分だけを足す形にもできます。例えば、kintoneで受注を管理し、freee会計へ請求・仕訳のデータを渡す連携の型があります。

公開したあとの保守はどうなりますか?

不具合の修正や、項目・画面の追加をどこまで当社が受けるかは、見積りの段階で決めます。社内の担当者が直せる部分と当社が受ける部分を分けて設計し、操作の手順とデータの定義を引き渡します。

社内にシステムの担当者がいなくても進められますか?

進められます。専任の担当者の代わりに、受注や在庫の業務をいちばん知っている方に、画面の確認と試用をお願いします。

他社から出ている見積りを見てもらえますか?

はい。他社の見積りや提案書をもとに、作る範囲と前提(画面の数・つなぐ先・移すデータ)を整理するご相談も受けています。既製のサービスで足りる場合は、そうお伝えします。

取引先がWebで注文してくれない場合はどうなりますか?

FAXや電話で届いた注文も、社内の担当者が同じ受注一覧に入力できる形にします。Webに移れる取引先から順に切り替え、FAXや電話の取引先が残っても、受注・在庫・請求は同じ仕組みで扱えます。

デモと同じものを作ってもらえますか?

デモは、架空の会社・データで形と流れを見ていただくためのモックです。実際には、今の注文の受け方・取引先ごとの違い・お使いの販売管理や会計に合わせて、画面と仕組みを組み立てます。デモの一部だけを使う形でも構いません。

Articles

関係する解説

費用の決まり方、製品を比べる前の取引先の分け方、FAXの注文の扱い方、Excelの在庫表が合わなくなる理由、注文書の読み取りについて、それぞれ記事で詳しく書いています。

BLOG受発注システムの開発費は、取引先と例外の数で決まる見積もりの前に、注文の入口・取引先ごとの条件・つなぐ先を数え、画面と連携の数に置き換える
BLOG受発注システムを比べる前に、取引先の分け方を決める取引先を注文の来方で分け、件数の多い群に合わせて、比べる製品の型(Web受注・販売管理と一体)を決める
BLOGFAXで注文してくる取引先が残っても、受注のシステム化はできる入口はそのままに、受注の置き場と状態の呼び方を一つにする設計と、Webに移ってもらう取引先の順番
BLOGExcelの在庫表が現物と合わなくなる理由入力の時間差・引当・返品・換算・棚卸差異に分けた、ずれの見分け方と直す順番
BLOG注文書のAI-OCRは「読めた後」で決まる取引先の書き方を自社の品番につなぐ対応表、人に回す条件、読めなかった注文の戻し先

要件が固まる前から、ご相談いただけます

今の注文の受け方と、手間のかかっている作業を伺えれば始められます。導入を前提としないご相談や、他社の見積りの確認も承ります。