kintone受注管理の設計方法｜受注・発注・出荷・請求をつなぐ構成

kintoneで受注管理を作るとき、最初に考えやすいのは受注一覧です。

受注日、顧客名、商品名、数量、単価、金額、納期、担当者、ステータス。

これをアプリに入れて、ステータス別に一覧を作れば、受注管理らしい画面は作れます。

ただし、実務で困るのは、受注一覧が作れないことではありません。

本当に崩れやすいのは、次のような状態です。

• 1つの受注に複数商品があるのに、受注と明細を同じ行で管理している
• 顧客名、商品名、単価が自由入力で、請求や集計の軸がぶれる
• 受注日、納期、出荷日、請求日、入金予定日が混ざっている
• 在庫が足りるのか、発注が必要なのかが受注画面から分からない
• 部分出荷、分納、キャンセル、数量変更の履歴が残らない
• 発注先、倉庫、出荷担当、請求担当の責任範囲が曖昧になる
• Webフォーム、メール、電話、ECなど注文入口が複数ある
• 請求書発行や会計ソフト連携の正本が決まっていない
• 顧客への確認連絡や変更履歴が、チャットやメールに散らばる

kintoneで受注管理を作るなら、最初に設計すべきなのは「受注一覧」ではありません。

受注ヘッダー、受注明細、顧客、商品、在庫、発注、出荷、請求、顧客連絡をどこで分けるかです。

kintone受注管理で最初に決めるべきなのは、受注ステータス名ではなく、「受注・明細・在庫・請求のうち、どれをkintoneの正本にするか」です。

この記事では、kintoneで受注管理を崩れにくい業務システムとして設計する方法を整理します。

kintone在庫管理の設計方法はこちら
kintone売上管理の設計方法はこちら

先に結論：受注管理は「受注」「明細」「在庫」「請求」を分ける

kintoneで受注管理を作るとき、受注アプリ1つだけでも始めることはできます。

ただし、受注後に発注、出荷、請求までつなげるなら、最初から次の情報を分けて考えます。

分けるもの	1レコードの意味	役割
顧客・取引先	1社、1店舗、1請求先	顧客情報、請求先、納品先、取引条件を持つ
商品マスタ	1商品、1SKU、1サービス	商品名、単価、税区分、在庫管理有無を統一する
受注ヘッダー	1つの注文、1回の受注	注文番号、顧客、納期、状態、担当を持つ
受注明細	1受注の1商品行	商品、数量、単価、金額、出荷対象を持つ
在庫・引当	1商品、1倉庫、1受注分の押さえ	出荷できる数量、不足数量を判断する
発注依頼	1つの仕入・手配依頼	不足分を仕入先や製造へ渡す
出荷指示	1回の出荷単位	出荷日、納品先、出荷数量、検品状態を扱う
請求予定	1回の請求対象	締め、請求日、請求金額、請求書番号を扱う
顧客連絡	1回の確認・変更・連絡	納期回答、変更依頼、キャンセルを残す
連携ログ	1回の外部連携	Webフォーム、倉庫、会計、帳票出力の成否を追う

このうち、すべてをkintoneで完結させる必要はありません。

むしろ、在庫、出荷、請求、会計は、専用システムや会計ソフトを正本にした方がよいケースもあります。

kintoneは、受注後の状態、確認事項、部門間の引き渡し、例外対応を見えるようにする場所として使うと強いです。

サイボウズ公式の受発注管理用途ページでも、Webフォーム連携、請求書発行、プロセス管理、メール履歴、グラフ、アプリ同士の連携などが紹介されています。

kintone公式：受発注管理にkintone

重要なのは、これらの機能を受注一覧に詰め込むことではありません。

受注後の業務を、どのデータに分けて、どの順番で渡すかです。

kintone受注管理が向く業務と向かない業務

kintoneは、受注管理に使えます。

特に、メール、FAX、Excel、Webフォーム、電話などで受注が散らばっていて、受注後の確認や引き渡しが属人化している会社には向いています。

kintoneに向く受注管理	理由
BtoBの受注受付	顧客、商品、納期、担当、状態をチームで共有しやすい
受注後の社内確認	在庫、発注、出荷、請求の確認状況を追える
Webフォームからの注文取込	注文情報をkintoneレコードに集約しやすい
小規模な受発注管理	Excelより履歴、権限、通知、コメントを整えやすい
既存基幹の周辺管理	基幹に入る前後の確認、例外、顧客連絡を補える
部分出荷や納期確認	出荷状態、未出荷、顧客回答を一覧化しやすい

一方で、次の領域はkintoneだけで完結させない方がよいです。

kintoneだけでは重い受注管理	理由
ECのリアルタイム注文処理	同時注文、決済、キャンセル、在庫引当が高速に動く
大量明細のEDI処理	データ量、取引先フォーマット、エラー処理が重い
厳密な在庫引当	有効在庫、ロット、期限、倉庫、同時更新が絡む
倉庫作業の実行管理	ピッキング、検品、梱包、送り状、端末UIが必要
正式な請求・売掛・入金消込	会計ソフトや販売管理システムの正本性が重要
複雑な与信・価格・契約条件	基幹、販売管理、CRMとの整合が必要

サイボウズの受注・発注・請求業務向けページでも、受注から請求書作成までの一元管理、Webフォーム、帳票出力、プロセス管理、リマインダーなどが紹介されています。

サイボウズ：受注・発注・請求業務ならキントーン

ただし、受注から請求までを一元管理できることと、すべてをkintoneの正本にすることは別です。

受注の受付・確認はkintone。

在庫の正本は在庫管理システム。

請求・売掛・入金はfreeeなどの会計ソフト。

このように責任範囲を分ける方が、後から運用しやすくなります。

kintone受注管理は、販売管理システムを丸ごと置き換えるためではなく、受注後に発生する確認・引き渡し・例外対応を整理するために使うと強いです。

受注管理で混ぜてはいけないデータ

受注管理で最初に分けるべきなのは、注文の親情報と明細情報です。

1つの注文に、複数の商品が入ることがあります。

納品先は1つでも、商品ごとに納期や出荷状態が違うことがあります。

一部の商品だけ欠品し、一部だけ先に出荷することもあります。

このとき、受注ヘッダーと受注明細を同じレコードに詰め込むと、すぐに崩れます。

情報	置き場所	理由
注文番号	受注ヘッダー	注文全体を識別する
顧客・請求先・納品先	受注ヘッダー	注文全体に関わる
受注日・希望納期	受注ヘッダー	注文全体の基準になる
商品・数量・単価	受注明細	商品行ごとに変わる
出荷数量・未出荷数	受注明細、出荷指示	商品行ごとに変わる
発注要否	受注明細、発注依頼	欠品商品だけが対象になる
請求対象	受注ヘッダー、請求予定	締めや請求先単位で変わる
顧客への連絡	顧客連絡	変更や確認履歴を残す

日付も分けます。

日付	意味
受注日	注文を受けた日
希望納期	顧客が希望する納期
回答納期	自社が回答した納期
出荷予定日	出荷する予定日
出荷日	実際に出荷した日
納品日	顧客に届いた日、または納品扱いの日
請求日	請求書を発行する日
入金予定日	入金される予定日

金額も分けます。

金額	意味
商品単価	商品マスタや契約条件から取得する単価
明細金額	商品単価 x 数量
値引き	明細または注文全体の調整
送料・手数料	受注全体に関わる費用
請求金額	請求書に載せる金額
売上計上額	管理上の売上実績として見る金額

kintone売上管理の設計方法でも触れたように、受注、売上計上、請求、入金は違う数字です。

受注管理では、注文を受けた後にどこまで進んだかを見ることが目的です。

売上や会計処理まで同じ項目に混ぜない方がよいです。

受注・明細・商品・顧客を分ける

受注管理では、最初から巨大な1アプリにしない方がよいです。

まず、顧客、商品、受注、受注明細を分けます。

アプリ	1レコードの単位	主な項目
顧客・取引先アプリ	1社、1店舗、1請求先	顧客コード、請求先、納品先、取引条件
商品マスタアプリ	1商品、1SKU、1サービス	商品コード、商品名、単価、在庫管理有無
受注アプリ	1注文、1受注	注文番号、顧客、受注日、納期、状態
受注明細アプリ	1注文内の1商品行	商品、数量、単価、金額、出荷状態
顧客連絡アプリ	1回の連絡・確認	納期回答、変更、キャンセル、確認履歴

顧客・取引先アプリに持たせる項目

顧客・取引先アプリは、受注の入口で使うマスタです。

フィールド	型	設計意図
顧客コード	文字列	他システムと照合するキーにする
顧客名	文字列	表示名
請求先	文字列、関連レコード	顧客と請求先が違う場合に対応する
納品先	テーブル、別アプリ	複数納品先を扱う
取引条件	ドロップダウン	締め日、支払条件、配送条件
与信・注意事項	文字列複数行	出荷前確認や特記事項
担当者	ユーザー選択	営業・受注担当を明確にする

kintone顧客管理の設計方法でも整理したように、顧客マスタは自由入力にしない方がよいです。

顧客名がぶれると、受注、請求、出荷、売上集計がすべて崩れます。

商品マスタに持たせる項目

商品マスタは、受注明細の軸になります。

フィールド	型	設計意図
商品コード	文字列	商品を一意に識別する
商品名	文字列	明細に表示する
SKU・型番	文字列	在庫や倉庫とつなぐ
標準単価	数値	明細単価の初期値にする
税区分	ドロップダウン	請求・会計連携に使う
在庫管理対象	チェックボックス	在庫引当が必要か分ける
発注対象	チェックボックス	不足時に発注するか分ける
出荷区分	ドロップダウン	物品、サービス、直送、納品不要など

商品名や単価を受注明細に自由入力すると、集計と請求が崩れます。

標準単価は商品マスタから取得し、値引きや特別単価は明細側で理由を残します。

受注アプリに持たせる項目

受注アプリは、注文全体を管理します。

フィールド	型	設計意図
注文番号	文字列、採番	受注全体のキーにする
顧客	ルックアップ、関連レコード	顧客マスタとつなぐ
受注日	日付	受注件数や処理期限を見る
希望納期	日付	顧客要望を残す
回答納期	日付	自社として回答した納期
受注経路	ドロップダウン	Webフォーム、メール、電話、ECなど
受注担当	ユーザー選択	受付責任を持つ
受注状態	ステータス	受付、確認中、手配中、出荷待ち、完了など
請求先	ルックアップ、文字列	顧客と請求先が違う場合に使う
納品先	ルックアップ、文字列	出荷指示へ渡す
備考・注意事項	文字列複数行	顧客指定や例外を残す

受注明細アプリに持たせる項目

受注明細アプリは、商品行を管理します。

フィールド	型	設計意図
関連受注	ルックアップ、関連レコード	どの注文の明細か
明細番号	数値	行番号を持つ
商品	ルックアップ	商品マスタから取得する
数量	数値	受注数量
単価	数値	商品マスタや契約から取得する
明細金額	計算	数量 x 単価
出荷対象	チェックボックス	物品か、サービスかを分ける
引当状態	ドロップダウン	未確認、引当済み、不足、対象外
発注要否	ドロップダウン	不要、必要、発注済み
出荷状態	ドロップダウン	未出荷、一部出荷、出荷済み
請求状態	ドロップダウン	未請求、請求予定、請求済み

受注明細を別アプリにすると、少し複雑になります。

しかし、複数商品、部分出荷、欠品、値引き、発注、請求状態を扱うなら分ける価値があります。

1受注1商品だけの小さな運用なら、受注アプリ内のテーブルから始めることもできます。

ただし、後から明細別に出荷や請求を追いたくなったら、別アプリ化を検討します。

受注ステータスとプロセス管理

受注管理では、ステータスを増やしすぎない方がよいです。

ただし、受注後の引き渡しが見えるように、状態は業務の境目で分けます。

ステータス	意味	次に必要な行動
受付	注文を受けた	顧客、商品、数量、納期を確認する
確認中	内容確認中	不明点、在庫、納期を確認する
手配中	在庫引当や発注を進めている	発注、入荷、出荷準備を進める
出荷待ち	出荷できる状態	倉庫や出荷担当へ渡す
一部出荷	一部だけ出荷済み	残数と納期を追う
請求待ち	出荷・納品後、請求対象	請求予定へ渡す
完了	出荷・請求まで完了	履歴として残す
保留	顧客確認、欠品、与信などで止まっている	保留理由と再開条件を決める
取消	キャンセルされた	取消理由と在庫・請求への影響を確認する

kintoneのプロセス管理では、レコードにステータスを持たせ、作業者やアクションを設定できます。

kintoneヘルプ：プロセス管理

受注管理でプロセス管理を使う場合は、承認フローのように重くしすぎない方がよいです。

受注は件数が多くなりやすいため、状態変更が重いと現場が更新しなくなります。

おすすめは、次の境目だけをステータスで持つことです。

境目	ステータスで見る理由
受付から確認中	注文内容の不足を拾う
確認中から手配中	在庫・発注へ渡してよいか判断する
手配中から出荷待ち	出荷担当へ渡す
出荷待ちから請求待ち	請求対象にしてよいか判断する
保留・取消	例外を一覧で拾う

受注ステータスは、注文全体の状態です。

明細ごとの引当状態、出荷状態、請求状態は、明細側に持たせます。

注文全体は「手配中」でも、A商品は引当済み、B商品は欠品、C商品は発注済みということがあります。

ここを分けないと、部分出荷や分納に対応できません。

発注・在庫・出荷とのつなぎ方

受注管理は、在庫や出荷と強くつながります。

ただし、受注アプリに在庫数を直接持たせすぎると、正本が曖昧になります。

領域	受注管理で見ること	正本にしやすい場所
在庫	出荷できるか、不足しているか	在庫管理アプリ、WMS、販売管理
引当	この受注分を押さえたか	在庫管理、受注明細、引当アプリ
発注	不足分を仕入先へ手配したか	発注管理、購買、基幹
入荷	発注分が入ったか	在庫管理、購買、WMS
出荷	いつ、何を、いくつ出したか	出荷管理、WMS、配送システム
納品	顧客に届いたか、納品扱いか	出荷管理、受注管理

kintone在庫管理の設計方法でも整理したように、在庫は現在庫だけでなく、入出庫履歴、引当、有効在庫を分けます。

受注管理では、在庫の全履歴を持つ必要はありません。

受注に必要なのは、出荷できるか、不足しているか、発注が必要か、出荷が終わったかです。

発注依頼の設計

発注依頼は、受注明細から発生します。

フィールド	型	設計意図
関連受注明細	ルックアップ、関連レコード	どの注文の不足分か
商品	ルックアップ	何を発注するか
発注数量	数値	必要数量
仕入先	ルックアップ	どこへ発注するか
希望入荷日	日付	いつまでに必要か
回答入荷日	日付	仕入先からの回答
発注状態	ステータス	未発注、発注済み、入荷待ち、入荷済み
受注影響	ドロップダウン	納期影響あり、影響なし、要確認

受注から発注を起こす場合、発注は受注とは別の業務です。

受注担当、購買担当、仕入先、入荷担当が違うことがあります。

そのため、発注状態を受注レコードのメモだけで管理しない方がよいです。

出荷指示の設計

出荷指示は、出荷する単位で作ります。

フィールド	型	設計意図
関連受注	ルックアップ、関連レコード	どの注文の出荷か
関連明細	関連レコード、テーブル	どの商品を出すか
出荷予定日	日付	出荷準備の期限にする
出荷日	日付	実際の出荷日
納品先	ルックアップ、文字列	どこへ送るか
出荷数量	数値	出荷した数量
配送方法	ドロップダウン	便、配送会社、直送など
送り状番号	文字列	配送追跡に使う
出荷状態	ステータス	未指示、準備中、出荷済み、差し戻し

部分出荷があるなら、出荷指示は受注とは別にします。

1つの受注に対して、複数回出荷することがあるためです。

出荷指示を別にしておくと、未出荷数、出荷済み数、残数、納品予定を追いやすくなります。

請求・入金・会計連携の境界

受注管理と請求管理は近いですが、同じではありません。

受注は、注文を受けた状態です。

請求は、請求してよい条件を満たした状態です。

入金は、実際にお金が入った状態です。

情報	kintone受注管理で持ちやすい	会計ソフトを正本にしやすい
請求予定	請求対象、締め、請求先、金額	必要に応じて参照
請求書	帳票番号、発行状態の確認	正式な請求書、控え、送付履歴
売掛金	未請求・請求済みの確認	売掛金残高、消込
入金	入金予定、未入金確認	入金消込、銀行明細、仕訳
仕訳	原則持たない	会計ソフト

受注管理から請求へ渡す条件を決めます。

請求条件	例
出荷基準	出荷済みになったら請求対象
納品基準	納品確認後に請求対象
月末締め	月内出荷分を月末にまとめる
前払い	受注時点で請求対象
分割請求	着手金、中間金、完了金に分ける
サービス提供	物品出荷ではなく提供完了で請求

freeeなどの会計ソフトと連携する場合は、kintone側で請求書の正式な正本を持つのか、会計ソフト側を正本にするのかを決めます。

多くの場合、請求書、売掛、入金消込、仕訳は会計ソフト側を正本にした方が安全です。

kintone側は、請求予定、請求前確認、請求書番号、請求済み状態、連携エラーを持ちます。

kintone売上管理の設計方法の売上・請求・入金の分け方も、この受注管理とつながります。

受注管理で請求まで扱う場合でも、請求書・売掛・入金消込・仕訳の正本をどこに置くかは、実装前に決める必要があります。

Webフォームと外部取引先入力

受注管理では、注文の入口が複数あります。

メール、FAX、電話、Webフォーム、EC、取引先ポータル、営業担当の代理入力。

入口を増やすと便利ですが、受注データの正本がぶれやすくなります。

入力方法	向いているケース	注意点
kintoneへ直接入力	社内担当が受け付ける	入力責任と必須項目を決める
Webフォーム	取引先や社外から注文を受ける	本人確認、重複注文、入力ミスを設計する
CSV取込	既存ExcelやEDIの移行初期	重複、文字コード、商品コード不一致に注意
EC連携	EC注文を取り込む	在庫、決済、キャンセルとの責任分担が必要
メール転記	件数が少ない初期運用	転記漏れと担当属人化が残る

公式ページでも、Webフォーム入力が可能なkintone連携サービスを使うことで、必要事項を入力するとkintoneアプリに反映できる例が紹介されています。

ただし、Webフォームを作るだけでは受注管理は完成しません。

フォームから入った注文を、次の状態へ進める設計が必要です。

フォーム入力後に見ること	理由
顧客が既存顧客か	顧客マスタと紐づけるため
商品コードが正しいか	商品マスタと照合するため
数量や納期に不備がないか	確認中に回すため
重複注文ではないか	二重受注を防ぐため
在庫や発注が必要か	手配へ進めるため
顧客への回答が必要か	納期確認や変更確認を行うため

外部取引先に入力してもらう場合は、権限も重要です。

注文者に社内の受注一覧や他社情報を見せてはいけません。

外部フォームやポータルを使う場合は、入力、修正、閲覧、通知の範囲を分けます。

アプリ同士のつなぎ方

受注管理では、複数アプリをどうつなぐかが重要です。

主な選択肢は、ルックアップ、関連レコード一覧、アプリアクション、API連携です。

機能	向いている使い方
ルックアップ	顧客、商品、単価、取引条件を入力時に取得する
関連レコード一覧	顧客から受注一覧、受注から明細・出荷・請求を見る
アプリアクション	受注から発注依頼、出荷指示、請求予定を作る
API連携	Webフォーム、EC、会計、倉庫システムと連携する

kintoneヘルプでも、アプリアクション、ルックアップ、関連レコード一覧は、複数アプリ間の連携機能として使い分けられると説明されています。

kintoneヘルプ：アプリアクションでできること

受注管理では、次のように使い分けます。

つなぎ方	例
顧客を選ぶ	ルックアップで請求先、納品先、取引条件を取得
商品を選ぶ	ルックアップで商品名、単価、税区分を取得
受注から明細を見る	関連レコード一覧で明細を表示
受注明細から出荷指示を作る	アプリアクション、または自動処理
受注から請求予定を作る	アプリアクション、または締め処理
Webフォームから受注を作る	連携サービス、API、CSV取込
会計ソフトへ請求情報を渡す	API、CSV、連携ツール

アプリを分けるほど、つなぎ方の設計が重要になります。

ただし、アプリを1つにまとめすぎると、受注、明細、在庫、出荷、請求、連絡履歴が混ざります。

まずレコード単位を分け、その上でつなぎ方を選びます。

よくある失敗パターン

kintone受注管理でよくある失敗は、Excelの受注表をそのまま再現することです。

失敗	起きること	対策
受注と明細を同じレコードに詰める	複数商品、部分出荷、分納に弱くなる	受注ヘッダーと明細を分ける
顧客名・商品名を自由入力にする	請求や集計の軸がぶれる	顧客マスタ、商品マスタを使う
日付を1つだけにする	受注、出荷、請求、入金が混ざる	日付の意味を分ける
ステータスを増やしすぎる	更新されなくなる	業務の境目だけに絞る
在庫数を受注アプリに手入力する	在庫正本とズレる	在庫管理や引当と分ける
発注状態をメモで管理する	購買担当への引き渡しが漏れる	発注依頼を別レコードにする
出荷完了と請求完了を同じ扱いにする	未請求や未入金が見えない	出荷、請求、入金を分ける
Webフォームだけ作る	受注後の確認や手配が残る	受付後の状態遷移を設計する
会計ソフトとの正本を決めない	請求書や売掛が二重管理になる	請求・入金・仕訳の責任範囲を決める

特に避けたいのは、「受注ステータスを細かく作れば管理できる」と考えることです。

ステータスは大事です。

しかし、受注管理で本当に必要なのは、状態だけではありません。

明細ごとの在庫、発注、出荷、請求、顧客連絡が追えることです。

1週間で始めるならこの順番

最初から受注、在庫、発注、出荷、請求をすべて作り込む必要はありません。

ただし、受注と明細の分け方だけは最初に決めます。

日程	やること	成果物
1日目	受注業務の入口を洗い出す	メール、FAX、Webフォーム、EC、電話
2日目	受注ヘッダーと明細を分ける	注文単位、商品行単位の定義
3日目	顧客・商品マスタを整理する	顧客コード、商品コード、単価、税区分
4日目	受注ステータスを決める	受付、確認中、手配中、出荷待ち、請求待ち
5日目	在庫・発注・出荷との境界を決める	引当、不足、発注依頼、出荷指示
6日目	請求・会計連携の方針を決める	請求予定、請求書、会計ソフト正本
7日目	実データで試す	入力負荷、確認漏れ、部分出荷、請求漏れを検証

最初の検証では、受注件数が多い代表商品や、例外が多い取引先を選びます。

そこで、次の確認をします。

• 1受注に複数明細が入っても追えるか
• 顧客や商品が自由入力になっていないか
• 在庫不足や発注要否を拾えるか
• 部分出荷や分納が扱えるか
• 請求対象と未請求を分けられるか
• 顧客への納期回答や変更履歴が残るか
• Webフォームや会計連携でエラーが起きたときに追えるか

この確認で詰まるところが、本格実装前に設計すべき論点です。

実装前チェックリスト

kintone受注管理を実装する前に、次の項目を確認します。

• 受注業務の入口が、メール、FAX、Webフォーム、EC、電話のどれか決まっている
• 受注ヘッダーと受注明細を分けるか決まっている
• 1受注に複数商品が入る場合の扱いが決まっている
• 顧客マスタと商品マスタを使う方針がある
• 顧客名、商品名、単価を自由入力にしすぎていない
• 受注日、希望納期、回答納期、出荷日、請求日を分けている
• 受注ステータスが業務の境目に沿っている
• 明細ごとの引当状態、発注状態、出荷状態、請求状態を扱える
• 在庫管理、発注管理、出荷管理のどこを正本にするか決まっている
• 部分出荷、分納、キャンセル、数量変更の履歴を残せる
• 請求予定をいつ作るか決まっている
• 請求書、売掛、入金消込、仕訳の正本をどこに置くか決まっている
• Webフォーム入力時の本人確認、重複注文、商品コード不一致を確認できる
• 顧客連絡や納期回答の履歴を残す場所がある
• 外部連携の成功、失敗、再実行を連携ログで追える

このチェックリストで詰まるところが、kintoneの設定前に決めるべきことです。

特に、受注ヘッダーと受注明細、在庫引当、出荷、請求の分け方は後から直すと重くなります。

過去の受注データが積み上がる前に決めます。

まとめ

kintoneで受注管理を作ること自体は難しくありません。

顧客名、商品名、数量、金額、納期、ステータスを入れれば、受注一覧は作れます。

しかし、実務で使える受注管理にするには、受注一覧だけでは足りません。

必要なのは、受注ヘッダー、受注明細、顧客、商品、在庫、発注、出荷、請求、顧客連絡、外部連携ログの境界を決めることです。

kintoneは、受注後の確認、在庫や発注への引き渡し、出荷・請求前のチェック、顧客連絡の履歴化に向いています。

一方で、ECのリアルタイム注文処理、厳密な在庫引当、倉庫作業、正式な請求・売掛・入金消込・仕訳は、専用システムや会計ソフトを正本にした方がよい領域です。

受注管理をkintoneで始めるなら、まず次の3つを決めてください。

• 受注ヘッダーと受注明細を、どの単位で分けるか
• 在庫、発注、出荷、請求のどこまでをkintoneで持つか
• Webフォーム、会計、倉庫など外部システムとの正本分担をどうするか

この3つが決まっていれば、kintone受注管理は単なる受注一覧ではなく、受注後の業務を止めないための業務システムになります。

逆に、ここを曖昧にしたまま受注表だけ作ると、注文は見えるのに、在庫が足りるのか、発注したのか、出荷したのか、請求したのかが分からない状態になります。

受注管理は、注文を記録する仕事ではありません。

注文を受けた後に、在庫、発注、出荷、請求、顧客連絡へ正しく渡していく業務です。