Makeで在庫不足を通知する｜商品別の基準と再通知の止め方

完成するものと対象範囲

商品ごとに決めた在庫の下限を下回ったとき、担当者へSlack通知を送ります。在庫数が少ない状態が続く間、毎回同じ通知を送らないように、通知済みの状態と補充後の解除を扱います。複数倉庫がある場合は商品と保管場所の組を一単位にします。

通知対象の在庫数を決める際は、現物数から予約済みや検品中を引くかを運営側で統一します。商品台帳にある数がそのまま販売可能数とは限りません。倉庫別の在庫をまとめて通知する場合も、他の拠点から移動できるかは別の業務判断です。まずは商品と場所の組で正確な通知を作り、拠点間の融通や自動発注は追加の承認が必要な別処理として設計します。

項目と保存先を準備する

入力と保存先に用意する項目は、商品ID、保管場所ID、利用可能数、通知下限、解除基準、通知状態、前回通知時刻、担当先です。元の値と担当者が確認した値は区別し、同じ名前の列を別の意味へ使い回さないようにします。実運用の情報を入れる前に、練習用の識別子で一件を作成し、必要な担当者だけが参照・編集できる保存先を選びます。

初回警告を送った日時と、最後に在庫を確認した日時を分けて保存します。前回の通知が昨日でも、今日の在庫確認が成功しているなら同じ欠品が継続していると分かります。逆に在庫表の更新が止まっている場合は、在庫不足ではなくデータ未更新の警告に分けます。担当者が欠品の補充を急ぐべきか、連携を直すべきかを本文から判断できる情報にします。

設定を順に進める

商品台帳に通知下限を持たせ、売れる数と検品中の数を分けます。Makeでは定期的に対象表を読み、商品IDと場所IDが空欄の行を保留します。古い在庫表を読むと誤通知になるため、更新日時も通知の材料にします。

下限以下かつ未通知の行だけを通知対象にします。通知本文へ商品名、場所、利用可能数、下限、元の行への参照を入れます。Slackの送信結果を受け取った後に通知状態を開き、失敗した行は未送信のまま残します。

補充後に解除基準まで戻った商品だけ通知状態を解除します。下限と解除を同じ値にすると境界で通知が増えやすいため、必要に応じて間を設けます。長期欠品の再通知は初回通知とは別ルールとし、担当者が頻度を決めます。

少数のデータで確かめる

商品Aは下限三個、解除六個と仮定します。在庫が四、三、二、六、三と変わる練習データなら、初回の三と補充後の三で通知します。二の時点は継続中として扱い、同じ欠品の初回通知をもう一度作りません。

運用中の変更を扱う

通知先の変更や担当者交代では、商品マスターを一括変更して終わりにせず、現在開いている警告も一覧にします。新担当へ何件を引き継ぎ、旧チャンネルでの対応をいつ終了するかを記録します。練習では送信失敗を一件だけ発生させ、成功分まで未通知へ戻らないことを確認します。再送した一件に既存の警告IDを結び、同じ欠品に二つの対応履歴ができないようにします。

費用と利用量を見積もる

在庫通知では商品数と確認頻度の積が読み取り量を増やします。通知する件数が少なくても、毎回全商品を取得して状態を検索する構成ならその分の処理が必要です。必要な更新間隔を店舗と決め、通知状態の保存や補充による解除も含めて見積もります。利用枠を減らすために確認を遅くし過ぎると欠品対応に間に合わないため、待てる時間と費用を一緒に判断します。

不具合が出たときの確認

通知が来ない場合は、在庫の型、場所ID、通知状態を確認します。欠品中なのに通知済みだけ消すと、次回に全商品が再通知されます。送信先変更時は既存の警告をどこへ引き継ぐか決め、担当先と状態を一緒に変更します。

運用を始める前の確認

公開・運用前の確認では、通常の一件だけでなく、必須項目が欠けた一件、同じ識別子を再利用した一件、確認後に内容を変更した一件を分けて試します。特に「商品ID」が元の記録へ戻る手掛かりになり、初回警告・継続中・補充済みを分け、境界値の往復で通知が増えないことを確認するという条件を満たすか確認してください。結果を担当者と共有し、どの入力をどの状態へ残すかが説明できてから対象を広げます。

通知を止めたい商品は、在庫を大きな数値へ書き換えるのではなく、監視対象かどうかの設定で除外します。販売終了の商品と、一時的に補充を止めた商品では、再開時の扱いが違います。監視を再開した時点で既に下限以下なら初回警告を出すのか、担当者が確認済みとして継続状態にするのかを決めます。練習データに監視停止と再開を含め、欠品の状態を表す数値と通知の運用設定が混ざらないことを確認します。例外を増やす場合は設定理由と見直し日も残します。

• 表の期限を通知する
• FilterとRouterの使い方
• Makeのエラー対応