kintone在庫管理の設計方法｜入出庫・引当・棚卸差異まで崩れない業務アプリ構成

kintoneで在庫管理を作る相談では、「今のExcelをアプリに移せばよいか」「商品マスタに現在庫を持たせればよいか」という話になりがちです。

小規模な備品や販促物なら、それでも始められます。

ただし、販売、出荷、購買、棚卸し、会計まで関わる在庫管理では、Excelの列をそのままkintoneアプリに移しても長く持ちません。

在庫管理で本当に困るのは、画面に在庫数を表示できないことではなく、次のような状態です。

• 在庫数はあるが、なぜその数量になったか説明できない
• 出荷予定で押さえた数量と、自由に使える数量が混ざっている
• 拠点、棚番、ロット、有効期限のどこまで管理すべきか決まっていない
• 棚卸し差異を現在庫の上書きで消してしまう
• EC、WMS、販売管理、会計ソフトのどれが正本か分からない
• 連携エラーが起きたとき、どの数字を信じるべきか判断できない

kintoneで在庫管理を作るなら、最初に設計すべきなのは「在庫管理アプリ」ではありません。

商品、保管場所、入出庫、引当、棚卸し、発注、外部連携を、どの単位のデータとして分けるかです。

kintone在庫管理で最初に決めるべきなのは、アプリ名やフィールドではなく、「どのデータを正本にするか」と「数量が変わる業務イベントをどう残すか」です。

この記事では、サンプルアプリの作り方ではなく、在庫業務をkintone上でどう分解し、どこまでkintoneで持ち、どこから専用システムや外部連携に逃がすべきかを整理します。

Excelからkintoneへ移行する考え方はこちら

先に結論：在庫数ではなく、在庫が動いた理由を正本にする

kintoneで在庫管理を作るとき、商品アプリに「現在庫」という数値フィールドを置きたくなります。

これは画面としては分かりやすいです。

しかし、現在庫を人が直接編集できる設計にすると、実務ではすぐに崩れます。

たとえば、ある商品の在庫が50個から37個に減ったとします。

この13個の減少は、販売出荷なのか、社内利用なのか、破損廃棄なのか、棚卸し差異の調整なのか、別倉庫への移動なのか。

ここが分からない在庫管理は、数字が合っているように見えても信用できません。

基本方針は次です。

考えるもの	正本にするデータ	目的
商品の定義	商品マスタ	SKU、単位、カテゴリ、管理責任者をそろえる
数量の変化	入出庫履歴	なぜ増減したかを説明できるようにする
現在の見え方	在庫残高	現場が今見る数量を出す
売れる数量	引当・出荷予定	すでに押さえた数量を現在庫から分ける
実物とのズレ	棚卸し	帳簿在庫、実棚数、差異理由を残す
外部との責任範囲	連携ログ	EC、WMS、会計とのズレを追う

在庫残高は大事です。

ただし、在庫残高は「結果」です。正本にすべきなのは、入庫、出庫、返品、移動、破損、棚卸調整のような、在庫が動いた理由です。

kintone在庫管理が向く業務と向かない業務

kintoneは、すべての在庫管理を置き換えるツールではありません。

向いているのは、現場の確認、入力、承認、例外処理、周辺業務とのつながりが重要な在庫管理です。

kintoneに向く在庫管理	理由
社内備品	保管場所、利用者、補充タイミングを部門横断で見たい
販促物・展示会用品	案件、イベント、担当者と入出庫を紐づけたい
サンプル品・貸出品	顧客、貸出、返却、破損、担当者を追いたい
小規模な部材・資材	Excelより履歴、権限、通知を整えたい
既存WMSの例外管理	本体在庫ではなく、問い合わせ、調整、承認だけを持ちたい
多拠点の見える化	各拠点の在庫状況や発注候補を同じ画面で確認したい

一方で、次の条件が強いなら、kintoneだけで完結させるのは重くなります。

kintoneだけでは重い在庫管理	理由
EC公開在庫をリアルタイムに制御する	同時注文、キャンセル、出荷、返品が秒単位で反映される
倉庫作業端末やバーコード検品が中心	入力速度、端末UI、検品フローの専用性が必要
ロット、期限、シリアル番号を厳密に追う	追跡粒度が細かく、誤登録の影響が大きい
原価、粗利、棚卸評価、売上原価まで扱う	会計・税務上の正式処理が必要
大量出荷、大量入荷がある	手入力や単純なレコード更新では追いつかない
生産計画やMRPと連動する	所要量計算、工程、仕掛品、原価まで絡む

ここで無理に「全部kintoneでやる」と決めない方がよいです。

kintoneは、在庫管理の周辺にある現場業務を整えるには強いです。

ただし、物流、EC、会計の中核まで抱え込むと、責任範囲が曖昧になります。

kintoneを在庫の正本にするか、在庫業務の入力・確認・例外処理の窓口にするかを先に分ける ことが重要です。

最初に分けるアプリ構成

kintoneで在庫管理を作るなら、最初から巨大な1アプリにしない方がよいです。

Excelで横に長い表を使っていた会社ほど、次の項目を1アプリに詰め込みがちです。

• 商品名
• 商品コード
• 現在庫
• 入庫日
• 出庫日
• 発注先
• 棚卸日
• 棚卸差異
• 備考

これでは、商品情報、入出庫履歴、棚卸し、発注が混ざります。

kintoneでは、最低でも次の単位に分けます。

アプリ	1レコードの意味	主なプロパティ
商品マスタ	1商品、または1SKU	商品コード、商品名、単位、カテゴリ、管理責任者、利用状態
保管場所マスタ	1拠点、1倉庫、1棚	拠点、倉庫、棚番、利用可否、担当者
入出庫履歴	1回の在庫増減	商品、保管場所、区分、数量、日付、理由、関連伝票
在庫残高	1商品 x 1保管場所	現在庫、引当済み、有効在庫、発注中、最終更新日
引当・出荷予定	1注文、1出荷予定	商品、数量、顧客、納期、出荷状態
棚卸し	1回の棚卸明細	帳簿在庫、実棚数、差異、差異理由、確認者
発注・入荷予定	1発注、1入荷予定	仕入先、発注数、入荷予定日、入荷済み数
連携ログ	1回の外部連携	連携先、対象レコード、結果、エラー、再実行状態

小さく始める場合でも、商品マスタと入出庫履歴は分けます。

現在庫を商品マスタに置く場合も、直接編集するためではなく、在庫残高から反映された確認用の値として扱う方が安全です。

商品マスタは「名前の一覧」ではなく、在庫の粒度を決める場所

商品マスタで最初に決めるべきなのは、商品名ではありません。

「何を1商品として扱うか」です。

同じ商品でも、サイズ、色、ロット、期限、単位、保管場所によって、在庫管理上は別物として扱う必要があります。

論点	例	設計判断
SKU	同じ商品でも色・サイズが違う	SKU単位で商品マスタを分ける
単位	個、箱、kg、m	入出庫と棚卸しで同じ単位にする
保管場所	本社、倉庫、店舗、棚番	在庫残高は商品 x 保管場所で持つ
ロット	食品、薬品、部材ロット	ロット管理が必要なら残高粒度を増やす
有効期限	期限切れが業務リスクになる	期限別在庫や専用システムを検討する
廃番	もう使わない商品	削除せず利用状態で止める

商品マスタに置く項目は、次のように分けると考えやすいです。

項目	用途
商品コード	表記揺れと重複を防ぐ
商品名	現場が識別する名称
SKU	色、サイズ、型番などの管理単位
単位	入出庫と棚卸しの単位をそろえる
カテゴリ	備品、商品、部材、販促物などを分ける
標準保管場所	通常置く場所を示す
発注点	補充判断の基準にする
標準発注数	発注候補を作るときの目安にする
仕入先	発注先候補を紐づける
管理責任者	棚卸しや補充の責任者を決める
利用状態	利用中、停止予定、廃番を分ける

商品マスタで避けたいのは、現場が自由入力で商品名を増やせる状態です。

「USBケーブル」「USB ケーブル」「USB-Cケーブル」「type-cケーブル」のような揺れが出ると、在庫数以前に集計が壊れます。

商品マスタは、在庫管理の辞書です。

辞書が揺れると、入出庫履歴も棚卸しも発注も揺れます。

入出庫履歴はイベントとして持つ

在庫数が変わる操作は、すべて入出庫履歴として残します。

ここで重要なのは、入庫アプリと出庫アプリを分けるかどうかではありません。

重要なのは、在庫が動いた「イベント」を構造化して残すことです。

フィールド	型	設計意図
履歴番号	自動採番、文字列	問い合わせや監査で参照できるようにする
商品	ルックアップ、関連レコード	商品マスタとつなぐ
保管場所	ルックアップ、関連レコード	どこで増減したかを残す
発生日	日付、日時	入庫日、出庫日、調整日を残す
区分	ドロップダウン	入庫、出庫、移動、返品、破損、棚卸調整
数量	数値	実際に動いた数量
増減方向	計算、または区分で判定	入庫はプラス、出庫はマイナス
関連元	関連レコード	注文、発注、棚卸、案件、顧客など
理由	ドロップダウン、文字列	なぜ在庫が動いたか
登録者	作成者、ユーザー選択	誰が入力したか
確認状態	プロセス管理、ステータス	下書き、確認待ち、確認済み、取消

入出庫履歴で一番やってはいけないのは、過去の履歴を後から上書きして帳尻を合わせることです。

誤登録があった場合は、原則として削除ではなく、取消履歴や逆方向の調整履歴を残します。

起きたこと	悪い処理	よい処理
出庫数を10個で登録すべきところ1個で登録した	元レコードを9個に直す	追加出庫9個の履歴を登録する
誤って別商品で入庫した	履歴を削除する	誤入庫取消と正しい入庫を残す
棚卸しで5個少なかった	現在庫だけ5個減らす	棚卸調整の出庫履歴を作る
倉庫Aから倉庫Bへ移動した	倉庫名を書き換える	Aからの出庫、Bへの入庫として残す

在庫管理では、間違いが起きる前提で戻し方を設計します。

入出庫履歴は、きれいな数字を作るためではなく、あとで在庫差異の理由をたどるために残す と考えるべきです。

現在庫・引当済み・有効在庫を分ける

在庫管理で混同されやすいのが、現在庫と有効在庫です。

現在庫が100個あっても、すでに80個が注文や社内利用予定で押さえられていれば、自由に使える数量は20個です。

この20個が有効在庫です。

数量	意味	主な用途
現在庫	倉庫や棚にある数量	実物の把握、棚卸し
引当済み	注文、出荷予定、利用予定で押さえた数量	欠品防止、納期回答
有効在庫	現在庫 - 引当済み	販売可否、利用可否
発注中	まだ入荷していない発注数量	補充予定の確認
入荷予定後在庫	有効在庫 + 発注中	将来の在庫見込み

kintoneで引当を扱うなら、注文アプリや出荷予定アプリを在庫残高とつなぎます。

アプリ	役割
注文・受注アプリ	顧客、商品、数量、希望納期を管理する
出荷予定アプリ	いつ、どこから、何個出すかを管理する
引当アプリ	商品、保管場所、数量、解除条件を管理する
在庫残高アプリ	現在庫、引当済み、有効在庫を表示する

小規模なら、注文アプリのステータスが「出荷待ち」になったものを引当済みに含める設計でも十分です。

ただし、ECやWMSとつなぐ場合は注意が必要です。

EC側が注文を受けた瞬間に在庫を押さえるなら、引当の正本はECやWMS側に置いた方が安全です。kintone側で同じ引当を別計算すると、キャンセル、返品、出荷分割のタイミングでズレます。

この場合、kintoneは「引当の正本」ではなく、「引当状況を確認する画面」や「例外処理の申請先」に寄せます。

在庫残高はどう更新するか

在庫残高をどう更新するかは、kintone在庫管理の設計でかなり重要です。

選択肢は大きく4つあります。

更新方法	向いているケース	注意点
手動更新	品目数が少ない、備品管理から始める	更新漏れ、二重更新を防ぐ確認ルールが必要
プラグイン	標準的な入出庫集計で足りる	プラグインの仕様に業務を合わせる部分が出る
JavaScriptカスタマイズ	画面上で入力補助や残高反映をしたい	保守担当、テスト、権限との組み合わせが必要
API・外部バッチ	EC、WMS、会計、BIと連携する	連携ログ、再実行、二重登録防止が必要

kintone REST APIには、レコードの取得、登録、更新、削除、ステータス更新などのAPIがあります。

cybozu developer network：レコード API

APIがあるので、外部システムと連携すること自体は可能です。

ただし、API連携を作れば在庫管理が完成するわけではありません。

連携前に決めるべきことがあります。

決めること	例
更新元	入出庫履歴、WMS、EC、販売管理のどれが残高を変えるか
更新タイミング	即時、5分ごと、1日1回、締め後
二重登録防止	外部ID、履歴番号、連携キーを持つ
エラー時の扱い	再実行、手動補正、差戻し、通知先
競合時の扱い	どちらを正にするか、手動確認に回すか
ログ	成功、失敗、再実行、取消を残す

特に在庫残高は、複数の操作が同時に走るとズレやすい領域です。

「入出庫履歴を登録したら残高を更新する」だけなら簡単に見えます。

しかし、同時に2人が出庫を登録した場合、外部ECから注文が入った場合、棚卸し調整が重なった場合に、どの順番で処理するかを決めておかないと、残高が信用できなくなります。

在庫残高の自動更新は、計算式の問題ではなく、更新順序、二重登録防止、エラー時の戻し方の問題 です。

棚卸しは「差異を消す作業」ではない

棚卸しは、帳簿在庫を実物に合わせるためだけの作業ではありません。

本来は、運用のどこが崩れているかを見つける作業です。

kintoneで棚卸しを扱うなら、棚卸しアプリを分けます。

フィールド	型	目的
棚卸し回	文字列、関連レコード	月次、四半期、期末などを分ける
商品	ルックアップ	対象商品を指定する
保管場所	ルックアップ	対象倉庫、棚を指定する
帳簿在庫	数値	kintone上の在庫数を固定する
実棚数	数値	実際に数えた数量を入れる
差異	計算	実棚数 - 帳簿在庫
差異理由	ドロップダウン、文字列	登録漏れ、破損、数え間違いなど
確認者	ユーザー選択	誰が確認したか
調整状態	プロセス管理	未確認、確認待ち、調整済み

棚卸し差異が出たとき、在庫残高を直接上書きして終わらせてはいけません。

差異理由ごとに、次の処理へつなぎます。

差異理由	次の処理
出庫登録漏れ	出庫履歴を追加する
入庫登録漏れ	入庫履歴を追加する
破損、廃棄	破損または廃棄履歴を追加する
倉庫移動漏れ	移動履歴を追加する
数え間違い	再棚卸しする
原因不明	棚卸調整履歴を残し、再発確認に回す

棚卸しアプリで見るべき一覧は、全件一覧ではありません。

次のような例外一覧を作ります。

一覧	条件	見る人
差異あり	差異が0ではない	倉庫担当、管理者
大差異	差異金額、または差異数量が一定以上	管理者
未確認	調整状態が未確認、確認待ち	確認者
原因不明	差異理由が原因不明	業務責任者
調整待ち	差異は確定したが調整履歴未作成	在庫管理担当

棚卸し差異は、現場の入力漏れ、保管場所の分け方、権限、通知、教育不足を教えてくれます。

差異を消すだけなら、翌月も同じズレが出ます。

拠点・ロケーション・ロット・有効期限をどこまで持つか

在庫管理は、管理粒度を細かくするほど正確になります。

ただし、細かくするほど入力が重くなります。

kintoneで設計するときは、「管理できるか」ではなく「現場が入力し続けられるか」で判断します。

管理粒度	kintoneで持つ判断	注意点
拠点	複数拠点の在庫を見たいなら持つ	拠点間移動の履歴が必要
倉庫	出荷元や棚卸し単位が違うなら持つ	倉庫名の表記揺れを防ぐ
棚番・ロケーション	探す時間や誤出庫が問題なら持つ	現場入力が細かくなる
ロット	品質、期限、回収対応が必要なら持つ	ロット別残高が必要
有効期限	期限切れリスクがあるなら持つ	期限別の先入先出が必要
シリアル番号	個体追跡が必要なら持つ	1個1レコードに近くなる

ロットや有効期限まで必要な場合、在庫残高は「商品 x 保管場所」では足りません。

「商品 x 保管場所 x ロット x 有効期限」のように粒度が増えます。

この段階になると、kintoneだけで頑張るより、専用在庫システムやWMSを正本にして、kintoneは例外申請、棚卸差異、マスタ確認、営業・購買との連携画面に寄せる方が現実的なことがあります。

受注・発注・請求とのつなぎ方

在庫管理は、単独では終わりません。

多くの場合、受注、出荷、発注、入荷、請求、会計とつながります。

ここで大事なのは、kintoneに全部を持たせないことです。

領域	kintoneで持ちやすいもの	別システムを正本にしやすいもの
受注	社内確認、出荷依頼、例外対応	EC注文、販売管理上の正式受注
出荷	出荷予定、出荷依頼、差戻し	WMSの出荷実績、送り状、検品
発注	発注候補、承認、仕入先確認	購買システムの正式発注
入荷	入荷予定、検品結果、差異報告	WMS、販売管理の入荷実績
請求	請求対象の確認、例外メモ	請求書、売上、入金消込
会計	棚卸しメモ、在庫差異確認	棚卸評価、原価、仕訳、税務

freeeなどの会計ソフトと連携する場合も同じです。

kintoneに在庫の状態や業務メモを持たせることはできます。

しかし、会計上の棚卸評価、売上原価、請求、仕訳までkintoneで無理に持つと、責任範囲が曖昧になります。

会計は会計ソフト、出荷はWMS、公開在庫はEC、現場の確認や例外処理はkintone。

このように分ける方が、あとから壊れにくいです。

バーコード・OCR・フォーム入力の使い分け

在庫管理では、入力方法も設計対象です。

「kintoneに入力する」と言っても、PCのフォーム、スマホ、バーコード、OCR、外部フォームでは向いている場面が違います。

入力方法	向いている場面	注意点
PCフォーム	商品登録、発注、棚卸し確認	現場でその場入力しにくい
スマホ入力	倉庫、店舗、外出先での入出庫	画面項目を絞らないと使われない
バーコード	SKUや棚番を素早く特定したい	バーコードマスタ、読み取り端末、例外時の処理が必要
OCR	紙伝票や納品書を一次入力したい	読み取り結果の確認者が必要
外部フォーム	社外メンバーや店舗から入力したい	権限、本人確認、添付ファイルの扱いが必要
CSV取込	初期移行、月次一括反映	重複、文字コード、項目マッピングが必要

入力方法を選ぶときは、入力精度と入力負荷を一緒に見ます。

たとえば棚卸しでスマホ入力を使うなら、画面には商品、保管場所、実棚数、差異メモだけを出す方がよいです。発注点、仕入先、会計メモまで同じ画面に出すと、現場では重くなります。

バーコードを使う場合も、読み取った後の処理が必要です。

商品が見つからない、棚番が違う、数量単位が違う、同じバーコードの商品が複数ある。

こうした例外を考えないままバーコード化すると、結局あとで管理者が手修正する運用になります。

一覧・通知・権限は例外を拾うために作る

kintoneでは、一覧、通知、プロセス管理、アクセス権を組み合わせて運用できます。

kintone公式ヘルプでも、プロセス管理に一覧、通知、アクセス権を組み合わせる考え方が整理されています。

kintoneヘルプ：プロセス管理と組み合わせると便利な設定

在庫管理でも、全件一覧をきれいに作るより、例外を拾う一覧を作る方が有効です。

一覧	条件	見る人
要発注	有効在庫が発注点以下	購買、管理者
引当不足	引当済みが現在庫を超えている	営業、出荷担当
入荷遅延	入荷予定日を過ぎても未入荷	購買
未確認入出庫	確認状態が確認待ち	確認者
棚卸差異あり	差異が0ではない	倉庫、管理者
保管場所未設定	保管場所が空	マスタ管理者
連携エラー	外部連携結果が失敗	システム担当

通知も同じです。

すべての入出庫を通知すると、誰も見なくなります。

通知するのは、行動が必要な状態だけです。

通知する状態	通知しすぎない方がよい状態
有効在庫が発注点を下回った	すべての入庫登録
引当不足が発生した	商品名の軽微な修正
入荷予定日を過ぎた	参考メモの追加
棚卸し差異が大きい	全商品の棚卸し完了
確認待ちが残っている	確認済み履歴の閲覧
外部連携が失敗した	連携成功ログ

権限も後回しにできません。

kintoneは、アプリ、レコード、フィールドの単位でアクセス権を設定できます。

kintoneヘルプ：アクセス権の設定

在庫管理では、特に数量を変えられる人を絞ります。

役割	閲覧	追加	編集	削除
倉庫担当	在庫、入出庫、棚卸し	入出庫、棚卸し	自分の担当範囲	原則不可
営業	有効在庫、引当状況	出荷依頼、引当依頼	自分の依頼	原則不可
購買	発注、入荷、仕入先	発注、入荷予定	発注関連	原則不可
管理者	全体	全体	全体	制限付き
外部連携ユーザー	API対象のみ	API対象のみ	API対象のみ	原則不可

削除権限は慎重に扱います。

入出庫履歴や棚卸し履歴を削除できると、差異の説明ができなくなります。

間違えた場合は、削除ではなく、取消履歴や調整履歴で戻す設計にします。

kintone在庫管理で崩れやすい失敗パターン

kintone在庫管理の失敗は、機能不足より設計不足で起きます。

失敗	起きること	設計で直すこと
商品アプリに現在庫を直接入力する	増減理由が追えない	入出庫履歴を正本にする
入庫と出庫をメモ欄で処理する	集計できない	区分、数量、保管場所を構造化する
商品名を自由入力にする	表記揺れで在庫が分かれる	商品マスタとルックアップにする
保管場所を文字列で入れる	倉庫名、棚名が揺れる	保管場所マスタを作る
引当を持たない	売れると思った在庫が足りない	出荷予定、注文、引当を分ける
棚卸差異を上書きで直す	原因が残らない	棚卸調整履歴を作る
権限を後回しにする	誰でも数量を変えられる	アプリ、レコード、フィールド権限を設計する
API連携だけ先に作る	間違った在庫数が自動で広がる	正本、連携ログ、再実行ルールを決める
通知を増やしすぎる	重要通知まで見られない	例外だけ通知する
全部kintoneで完結させる	EC、WMS、会計との責任範囲が曖昧になる	kintoneに持たない領域を決める

特に危ないのは、在庫残高だけをきれいに見せることです。

ダッシュボード上の数字が整っていても、入出庫履歴、引当、棚卸差異、連携ログが説明できなければ、業務では使えません。

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

最初から完全な在庫管理システムを作る必要はありません。

小さく始めるなら、1週間で次の順番で設計します。

日	やること	成果物
1日目	在庫の範囲を決める	対象商品、対象拠点、kintoneに持たない範囲
2日目	商品マスタと保管場所マスタを作る	SKU、単位、カテゴリ、保管場所の定義
3日目	入出庫履歴を作る	区分、数量、理由、確認状態
4日目	在庫残高と一覧を作る	現在庫、有効在庫、要発注、未確認一覧
5日目	棚卸しと差異処理を作る	帳簿在庫、実棚数、差異理由、調整履歴
6日目	権限と通知を設定する	役割別の閲覧・編集、例外通知
7日目	連携と移行判断を整理する	EC、WMS、会計、CSV、APIの境界

この段階で、リアルタイム連携や高度な自動化まで入れなくて構いません。

まず作るべき状態は、次です。

• 商品と保管場所の重複がない
• 入出庫の理由が履歴で追える
• 有効在庫と現在庫を分けて見られる
• 発注点を下回った商品が分かる
• 棚卸し差異の理由が残る
• 数量を変えられる人が限定されている
• どのシステムが正本か説明できる

ここまでできれば、次にプラグイン、JavaScript、API連携、WMS・EC・freee連携へ進めます。

逆に、この状態を作らないまま自動化すると、きれいに間違った在庫数が連携されます。

実装前に決めるチェックリスト

kintoneで在庫管理を作る前に、最低限次の質問に答えます。

質問	決めること
在庫の正本はどこか	kintone、WMS、EC、販売管理、会計ソフトのどれか
商品の管理粒度は何か	SKU、ロット、保管場所、単位、有効期限
数量を変える操作は何か	入庫、出庫、移動、返品、破損、棚卸調整
現在庫はどう更新するか	手動、プラグイン、JS、API、外部バッチ
引当を扱うか	注文、出荷予定、有効在庫の考え方
棚卸し差異をどう処理するか	調整履歴、承認、再発防止
誰が確認するか	倉庫、営業、購買、管理者の役割
誰が削除できるか	原則不可にする範囲、取消履歴の扱い
連携失敗時にどう戻すか	再実行、二重登録防止、エラー通知
何をkintoneに持たないか	会計評価、EC公開在庫、倉庫端末処理など

このチェックリストに答えられない状態でアプリを作ると、あとからフィールド追加、権限変更、運用ルール追加が続きます。

小さく始めることはできます。

ただし、小さく始める範囲と、最初から設計しておく範囲は分けます。

商品コード、保管場所、入出庫区分、履歴の残し方、権限、正本システムは、最初に決めた方がよいです。

まとめ

kintoneで在庫管理を作るときは、「在庫管理アプリを1つ作る」と考えない方がよいです。

商品マスタ、保管場所マスタ、入出庫履歴、在庫残高、引当、棚卸し、発注・入荷、連携ログを分けます。

そのうえで、どのデータを正本にするか、数量が変わる業務イベントをどう残すか、どの外部システムに責任を持たせるかを決めます。

kintone在庫管理の設計で大事なのは、現在庫を表示することではなく、その現在庫がどの履歴、どの引当、どの棚卸差異、どの連携処理から説明できるかです。

備品、販促物、サンプル品、小規模な部材管理なら、kintoneだけでも十分に始められます。

一方で、EC公開在庫、倉庫作業、ロット、有効期限、原価、会計、出荷指示まで含むなら、kintoneは周辺業務と例外処理に寄せ、在庫の正本は専用システムに置く判断も必要です。

テンプレートやプラグインを選ぶ前に、まず業務の流れとデータの責任範囲を決める。

それが、kintone在庫管理を崩れにくくする一番の近道です。