Zoho CRMで在庫管理する落とし穴｜請求書で在庫数（Qty in Stock）が減る仕様と実在庫の持ち方

Zoho CRMの在庫管理で使う標準項目「在庫数（Qty in Stock）」とは、商品モジュールにある項目で、請求書や発注書の操作に合わせてZohoが自動で増減させる数量です。便利な仕組みですが、会社の在庫の動かし方と合わないと、知らないうちに在庫がずれていきます。

当社は、東海地方の雑貨卸（小規模）で、受注から発注・入庫・出庫・締め請求までをZoho CRMで回す仕組みを設計・構築しています。その動作確認の途中で、請求書を作っただけで商品の在庫数が減ることに気づきました。

この記事では、Zohoの公式仕様と当社の実測、そして「実在庫をどう持てば二重に減らないか」の設計を、手順とコードでまとめます。なお、記事中の数値はすべてテスト用の架空データです。

Zoho CRMの在庫数はいつ減るのか：標準の在庫数は「請求書」で動く

Zohoの公式ヘルプには、在庫まわりの3つの数量がどの操作で動くかが書かれています。

数量	増える操作	減る操作
在庫数（Qty in Stock）	発注書が納品済みになったとき／請求書を取り消したとき	請求書を作成したとき（見積書・受注書から請求書へ変換した場合も含む）／納品済みの発注書を取り消したとき
需要数量（Qty in Demand）	受注書を作成したとき	受注書が納品済み・取り消しになったとき／受注書を請求書へ変換したとき
発注数量（Qty Ordered）	発注書を作成したとき	発注書が納品済み・取り消しになったとき

出典：Zoho CRM ヘルプ「Working with Products」「FAQs: Inventory Management」（2026年10月時点）

ポイントは、在庫数が物の出荷ではなく、請求書の作成で減ることです。請求書を「物が出ていった記録」として使う会社なら、この仕組みはそのまま役に立ちます。一方で、請求書と出荷のタイミングがずれる会社では、在庫数が実際の棚の数と合わなくなります。

当社の実測：請求書20個で在庫が150→130

テスト環境で、次の順に確かめました。

商品「グラス」の在庫数を150にする
受注書を作る → 在庫数は150のまま
同じ商品を20個載せた請求書を作る → 在庫数が130になる
その請求書を削除する → 在庫数が150に戻る

公式ヘルプにある「請求書の取り消しで戻る」は、当社の環境では請求書の削除でも同じように戻りました。

なぜ困るのか：締め請求で在庫が二重に減る

この卸の業務では、物は受注ごと、あるいは受注に紐づかない「フリー出荷」で日々出ていきます。請求は月末などで締めて、取引先ごとにまとめて請求書を出します（締め請求）。

当初の設計では、実在庫を標準の在庫数に割り当てていました。そして出荷を登録する画面（ウィジェット）から、出荷のたびに在庫数を減らす作りにしていました。ここにZohoの自動連動が重なると、次のようになります。

タイミング	自前の出荷処理	Zohoの自動連動	在庫数
開始時	—	—	150
20個を出荷	−20	—	130
月末に20個分の請求書を作成	—	−20	110

棚には130個あるのに、CRM上は110個です。請求書を作り直したり、分割して出し直したりすると、ずれ方はさらに読みにくくなります。

逆に「請求書で減るなら、出荷では減らさなければよい」と考えることもできます。しかしその場合、出荷してから請求書を作るまでの間、CRM上の在庫は実際より多く見えます。サンプル出荷や破損のように請求書を作らない減り方も、在庫数に反映できません。

そこで、標準の在庫数は使わないことにしました。

実在庫・引当済在庫・有効在庫はどう持つか

商品の在庫を実在庫・引当済在庫・有効在庫の3つに分け、実在庫から引当済を引いた残りが有効在庫になる関係を棒の長さで示した図

実在庫を分けるついでに、在庫の持ち方そのものを整理しました。ここで役に立ったのが、当社が支援している別の製造業の設計でも使った「在庫を3つに分ける」考え方です。

区分	意味	持ち方
実在庫	倉庫に実際にある数	カスタム項目（整数）
引当済在庫	受注に割り当てたが、まだ出荷していない数	カスタム項目（整数）
有効在庫	新しい受注に使える数（実在庫−引当済在庫）	数式項目

「引当（ひきあて）」とは、受注に対して在庫を予約しておくことです。引当済在庫を別に持つと、同じ在庫を2つの受注に約束してしまう「二重引当」を防げます。

各操作で、どの数を動かすかを決めておきます。

操作	実在庫	引当済在庫	有効在庫（数式）
入庫	増やす	—	自動で増える
受注を確定して引当	—	増やす	自動で減る
受注分を出荷	減らす	減らす（引当の消し込み）	変わらない
フリー出荷（受注なし）	減らす	—	自動で減る
引当の解除（受注キャンセル）	—	減らす	自動で増える
破損・廃棄	減らす	—	自動で減る
請求書の作成	—	—	—

最後の行が大事です。請求書を作っても、どの数も動かしません。 在庫は物の動き（入庫・出庫・引当）だけで変わり、お金の動き（請求）とは切り離されます。

設計で気をつけたいのは、「引当のときに実在庫も減らし、さらに有効在庫を実在庫−引当済で計算する」という組み合わせにしないことです。これだと引当分を二重に差し引いてしまいます。引当で減らすのは引当済在庫の「増加」だけ、実在庫は出荷のときに初めて減らす、と1か所に決めておきます。

手順：実在庫を標準項目から分ける

商品モジュールに、整数のカスタム項目を2つ作る（例：実在庫数 Actual_Stock、引当済在庫数 Allocated_Qty）
数式項目「有効在庫数」を作り、式を 実在庫数 − 引当済在庫数 にする
標準の在庫数のラベルを「在庫量（Zoho標準・使用しない）」のように変え、使わないことを画面で分かるようにする。必要ならページレイアウトからも外す
ウィジェット・Deluge関数・レポートが参照する項目を、すべて新しい実在庫数に切り替える。古い参照が1つでも残ると、画面ごとに在庫の数が違う状態になる
入庫・出庫・引当の登録処理で、上の表のとおりに実在庫数と引当済在庫数を更新する
確認として、テスト用の請求書を作る。標準の在庫数だけが減り、実在庫数が変わらないことを確かめる

当社の環境でも、切り替え後に20個の請求書を作ったところ、標準の在庫数は130になりましたが、実在庫数は150のままでした。

なお、数式項目をAPIで作ると、当社が作成したときは指定したAPI名が反映されず、field（同じモジュールに複数作ると field1 など）になりました。画面での表示名は日本語で付けられるので運用上は困りませんが、Delugeや検索から参照するときは、設定画面で実際のAPI名を確かめてから使ってください。

出荷登録のDeluge例

受注分の出荷とフリー出荷を1つの関数で登録する例です。出庫を独立したモジュール（例 Outbound_Shipment）に1件記録し、商品の実在庫数と引当済在庫数を更新します。項目名は一般的な名前に置き換えています。関数は、設定の関数で種類（カテゴリ）を スタンドアロン にして作る想定です。宣言の standalone. は、このカテゴリを表します。

string standalone.registerShipment(string productId, int shipQty, string salesOrderId)
{
	if(shipQty == null || shipQty <= 0)
	{
		return "出荷数量を1以上で入力してください。";
	}
	product = zoho.crm.getRecordById("Products",productId.toLong());
	actualStock = ifnull(product.get("Actual_Stock"),0).toLong();
	allocatedQty = ifnull(product.get("Allocated_Qty"),0).toLong();
	if(actualStock < shipQty)
	{
		return "実在庫が足りません（実在庫: " + actualStock + "）。";
	}
	releaseQty = 0;
	if(salesOrderId != null && salesOrderId != "")
	{
		releaseQty = shipQty;
		if(allocatedQty < shipQty)
		{
			releaseQty = allocatedQty;
		}
	}
	shipment = Map();
	shipment.put("Name","出庫 " + zoho.currentdate.toString("yyyy-MM-dd") + " " + product.get("Product_Name"));
	shipment.put("Product",productId);
	shipment.put("Shipped_Qty",shipQty);
	if(salesOrderId != null && salesOrderId != "")
	{
		shipment.put("Sales_Order",salesOrderId);
		shipment.put("Shipment_Type","受注紐づき");
	}
	else
	{
		shipment.put("Shipment_Type","フリー出荷");
	}
	created = zoho.crm.createRecord("Outbound_Shipment",shipment);
	if(created.get("id") == null)
	{
		info created;
		return "出庫の登録に失敗しました。在庫は更新していません。";
	}
	update = Map();
	update.put("Actual_Stock",actualStock - shipQty);
	update.put("Allocated_Qty",allocatedQty - releaseQty);
	zoho.crm.updateRecord("Products",productId.toLong(),update);
	return "出庫を登録しました（実在庫: " + (actualStock - shipQty) + "）。";
}

出庫レコードを先に作り、成功したときだけ商品の数を更新しています。失敗したのに在庫だけ減る、という状態を避けるためです。

もう1つ注意したいのは、同じ商品の在庫を2人が同時に更新するケースです。この関数は「読んでから書く」ため、ほぼ同時に2件の出荷を登録すると、片方の更新が上書きされることがあります。少人数で運用する会社では起きにくいものの、受注が集中する会社では、商品にバージョン番号を持たせて「読んだ時点から変わっていたら更新しない」ようにする設計も検討してください。前述の製造業の設計では、この確認を入れる方針としています。

入出庫と引当は「独立したモジュール」に記録する

受注や発注の明細はサブフォーム（1件のレコードの中に表の形で持つ明細）に入れるのが標準です。ただ、在庫の増減の記録まで明細の中に持つと、後から集計しにくくなります。

当社が構築した時点では、COQL（Zoho CRMのSQLに似た検索言語）で受注書を検索しても、サブフォームの明細の列をそのまま取り出して集計することはできませんでした。そこで、次のように「1回の在庫の動き＝1レコード」のフラットなモジュールに分けました。

在庫引当：受注書・商品・引当数量・引当時の原価・区分（引当／引当解除）
入庫：発注書・商品・入庫数量・仕入単価
出庫：受注書（任意）・商品・出荷数量・販売単価・出荷区分

この形にすると、次のことがやりやすくなります。

「在庫がどこで増えて、どこで減ったか」を商品ごとに時系列でたどれる
受注ごとの原価を、引当分（在庫から使った分）と仕入分に分けて積み上げられる。粗利の計算にそのまま使える
数がずれたとき、商品の実在庫数を記録の合計から計算し直して突き合わせられる

商品の実在庫数は「いまの値」、入出庫・引当のモジュールは「そこに至るまでの記録」です。両方を持つことで、ずれに気づいたときに原因を探せます。

まとめ：Zoho CRMで在庫を持つ前の確認リスト

自社の請求のタイミングは、出荷と1対1か、締め請求か
標準の在庫数（Qty in Stock）が請求書の作成で減ることを、関係者が知っているか
実在庫・引当済在庫をカスタム項目に分け、有効在庫を数式で出しているか
標準の在庫数を参照している画面・関数・レポートが残っていないか
請求書を作っても実在庫が変わらないことを、テストで確かめたか
入庫・出庫・引当を、1回の動きごとに独立したモジュールへ記録しているか
同時更新で数が上書きされるリスクを、運用の人数に合わせて判断したか

ロット管理や複数倉庫の厳密な管理まで必要な場合は、在庫専用のアプリとの組み合わせも選択肢になります。まずは「在庫は物の動きで変える」「請求とは切り離す」の2点を設計の最初に決めておくと、後からのずれを防げます。

販売管理をどこで持つか（自社構築・クラウド・パッケージ）の考え方は「販売管理システムを見直す際に検討すべきポイント」、受注の入力画面をウィジェットで作るときのテストは「Zoho CRMのWidget（ウィジェット）で作る受注入力画面のテスト項目」で紹介しています。

在庫・受注・請求をCRMで持つ構成のご相談は、販売管理システムとCRMの統合構築サービスでお受けしています。

TL;DR（この記事の要点）

標準の「在庫数（Qty in Stock）」は、請求書の作成で減り、請求書の取り消しで戻る。受注書（Sales Orders）の作成では変わらない（Zoho公式ヘルプ）
当社のテスト環境では、在庫150の商品で20個の請求書を作ると在庫数が130になり、請求書を削除すると150に戻った
出荷時に自前で在庫を減らす仕組みと併用すると、締め請求のたびに在庫が二重に減る
実在庫・引当済在庫はカスタム項目で持ち、有効在庫は「実在庫−引当済」の数式項目で出す。標準の在庫数は使わない
入庫・出庫・引当はサブフォームではなく独立したモジュールに1件ずつ記録すると、集計と原因調査がしやすい

よくある質問

受注書（Sales Orders）を作っただけで在庫数は減りますか？

公式ヘルプでは、受注書の作成で増えるのは「需要数量（Qty in Demand）」で、在庫数（Qty in Stock）は請求書の作成で減ると案内されています。当社のテスト環境でも、受注書の作成では在庫数は変わりませんでした。

標準の在庫数の自動連動をオフにできますか？

当社が確認した時点では、この連動を止める設定は見つけられませんでした。そのため、標準の在庫数を参照しない設計（実在庫を別のカスタム項目で持つ）にしています。

請求書を出荷のタイミングで1件ずつ作る運用なら、標準の在庫数をそのまま使ってもよいですか？

請求書の作成と物の出荷が必ず1対1で一致し、出荷時に別の仕組みで在庫を減らさないなら成り立ちます。ただし、締め請求への切り替え、請求書の作り直し、請求のない出荷（サンプル出荷など）が出た時点で在庫がずれるため、最初から実在庫を分けておくことをおすすめします。

有効在庫を数式項目にするとき、気をつけることはありますか？

当社がAPIで数式項目を作成したときは、指定したAPI名が反映されず「field」という名前になりました。画面の表示名は日本語で付けられますが、Delugeや検索から参照するときは実際のAPI名を確認してから使ってください。

Zoho CRMの在庫数はいつ減るのか：標準の在庫数は「請求書」で動く

当社の実測：請求書20個で在庫が150→130

なぜ困るのか：締め請求で在庫が二重に減る

実在庫・引当済在庫・有効在庫はどう持つか

手順：実在庫を標準項目から分ける

出荷登録のDeluge例

入出庫と引当は「独立したモジュール」に記録する

まとめ：Zoho CRMで在庫を持つ前の確認リスト

よくある質問

関連記事

販売管理システムを見直す際に検討すべきポイント 自社構築？クラウド？パッケージ？どれがいい？

Zoho CRMのWidget（ウィジェット）で作る受注入力画面のテスト項目｜異常系21ケースの実例

Zoho Sign連携で署名依頼が飛ばず請求書が先に届くときの切り分け方｜Zoho CRMワークフローの確認順

基幹システムとCRMの連携をご相談ください。

販売管理システムを見直す際に検討すべきポイント　自社構築？クラウド？パッケージ？どれがいい？

基幹システムとCRMの連携を
ご相談ください。