倉庫

倉庫セクションでは、食材や商品の在庫を管理します。基本の考え方はシンプルです。料理の構成（レシピ）を一度登録しておけば、あとは注文の実行時に構成材料が自動で消費されるため、手作業で管理しなくても在庫は常に最新の状態に保たれます。

開くには：管理パネル → 倉庫。タブは在庫、仕入れ、予測、ロス、書類、サプライヤーです（ロシアの店舗ではマーキング、『メルクリ』に対応するための受信VSD、およびEGAISが追加されます）。

店舗には複数の倉庫を持たせることができます。たとえばメイン、バー、キッチンなどです。倉庫の切り替えはページ上部にあります。そのうち1つが販売用倉庫として指定され、販売された料理はそこから消費されます。

在庫#

• 商品＝食材または管理対象のアイテムです。名称、単位、現在の在庫を持ちます。
• 原価は自動で計算されます。入庫に基づく移動平均で、直近の仕入れ価格もヒントに表示されます。テーブルの上には**「倉庫の価値」**パネルがあり、今この瞬間に棚にある金額がわかります。
• 最小在庫を下回ると行が強調表示され、仕入れどきであることがわかります。オーナーには在庫不足のプッシュ通知が届きます。
• バーコードは1つの商品に複数設定できます。商品カードはスキャナーで呼び出せます。各アイテムには移動履歴があり、どこから入ってどこへ出たかを確認できます。
• 在庫はマイナスになることもあります。販売はブロックされず、行が赤くなるだけで、次の入庫時に「借りが帳消し」になります。
• 商品はアーカイブできます。一覧からは非表示になりますが、書類の履歴には残ります。

レシピ：注文による自動消費#

料理のカード（「メニュー」セクション）で構成を設定します。どの商品が1人前にどれだけ使われるかを指定します。注文が実行されると：

• 注文のすべてのアイテムの構成材料が、それぞれのレシピに従って消費されます。
• コンボセットの場合、消費はコンボ内の各料理の構成を展開します。
• 移動は書類タブで確認できます。

商品と料理をすばやく紐付けるにはAIサジェストがあります。システムがメニューを分析し、その商品がどの料理に使われているかを提案します。あとは確認するだけです。

半製品#

仕込み（ソース、生地、ブイヨンなど）には、商品に独自のレシピを設定します。**「製造」**ボタンで製造書類が作成されます。半製品が入庫され、その構成材料が消費されます。料理のレシピでは、半製品は通常の商品として使用されます。

商品の入庫#

入庫を登録する方法は2つあります：

1. 手動 — 「入庫」ボタンで、商品、数量、価格、サプライヤーを選択します。新しい商品は入庫画面を離れずに書類の行で直接登録できます。
2. 納品書の写真から — 納品書を撮影すると、AIがアイテム、数量、価格を認識し、既存の商品と照合します。判断に迷う行はシステムが黙って推測せず、選択肢とともに確認を求めます。新しい商品や新しいサプライヤーは、認識された納品書から直接作成できます。同じ名前の商品がすでに台帳にある場合、その行はどの商品に紐付くかを表示し、その商品の単位に数量を換算します（「2 kg」→ 2000 g）。「3 箱 × 12 L」のような梱包単位もシステムが認識し、リットルやミリリットルへの換算を提案します。数量と価格が変わるのは**「適用」**を押したときだけです。

3つ目の別のシナリオとして、個人からの仕入れがあります。売り手の情報を含む仕入れ証書、開いている現金シフトからの支払いまたは後払い、印刷用のPDF証書です。個別に有効化します。

各入庫はサプライヤーに紐付いた書類として保存され、仕入れは財務（フードコスト、売上総利益）に反映されます。

受領時の仕入れ価格チェック#

受領時、各行は過去30日間および90日間のその商品の価格中央値と比較されます。価格が明らかに高い場合、行の横に**「中央値比 +N %」**バッジが点灯します。倉庫担当者は値上がりを、1か月後のレポートではなく受領の瞬間に把握できます。

重要なポイントがいくつかあります：

• 抽出の単位は納品書であり、行ではありません。納品を5行に分割したサプライヤーが、中央値を正直な場合の5倍も動かすことはありません。
• 仕入れが3件未満の場合は抽出対象外で、バッジは表示されません。
• 倉庫担当者が確認した差異はサプライヤーのジャーナルに記録されます。取引先ごとに価格変動の履歴が確認でき、「サプライヤー」タブにマークが表示されます。
• 同じ中央値がリスクルール**「仕入れ価格の急騰」**にも使われます。オーナーは「レジリスク」ブロックでこれを確認できます。ロス管理を参照してください。倉庫担当者とオーナーの数値は一致します。サーバー上で一度だけ計算されるためです。

仕入先#

仕入先タブは、単なる取引先情報の台帳ではなく、取引先を管理するミニCRMです。

• 取引先情報と連絡先 — 法人名、INN、銀行と口座、住所。担当者は複数登録でき、それぞれに役割と連絡チャネルがあり、1人をメインに設定します。各担当者ごとに、注文をどこへ送るかを選択します —「送信方法」フィールドで、メール、WhatsApp、Telegramから選べます。一覧にはその担当者に入力済みのチャネルだけが表示されるため、「宛先なし」で送信することはできません。選択したチャネルはシステムが送信画面の先頭に表示して星印を付けますが、自動で送信するのはメールのみです（後述の「仕入先への注文自動送信」を参照）。
• 納品条件 — 最低注文金額、納品期間、注文締め時間、支払猶予、配送日。注文作成時、システムはこれらから入庫予定日を計算します。
• タイムライン — 担当者のメモと自動イベント（注文、入庫、記録された値上げ）。
• 仕入先の価格表 — 4つのソースのいずれかから取り込む価格付きカタログです。ファイル（xlsx、xls、docx、pdf、または価格表の写真）、インターネットショップのリンク、別のCenaly店舗のカタログ（その店舗が「仕入先の店舗」モードを有効にしている場合 — マーケットを参照）、アイテムの手動追加があります。カタログには「前回から値上がりしたもの」の差分が表示され、価格履歴を保持し、カタログから直接注文したり、直前の注文を繰り返したりできます。価格表に梱包単位（「箱 12 × 0.5 L」「1.5 kg × 6個」など）が記載されている場合、インポート時に専用セクションとして提案されます — 正しい行にチェックを入れてください。チェックを入れない場合、梱包単位は変更されません。

仕入先は入庫を登録する際に選択するため、取引先ごとに仕入れ履歴を確認できます。アーカイブされた仕入先は一覧から非表示になりますが、書類には残ります。

仕入れ#

仕入れタブは「在庫が減った — 発注した — 受け取った」というサイクルを完結させます。各商品に一度パラメータを設定すれば、あとはシステムが発注すべきタイミングを自動で監視します。

商品のパラメータ#

商品エディタ（「仕入れ」セクション）では3つの項目を設定します：

• 発注点 — この在庫を下回ると、商品が「発注が必要」リストに追加される最小在庫数。
• 目標在庫 — 発注時に補充すべき水準。推奨数量は目標在庫と現在庫の差として自動計算されます。
• 既定の仕入先 — 発注の作成時に、システムが商品を仕入先ごとにグループ化します。

「発注が必要」セクション#

1つでも商品が発注点を下回ると、「仕入れ」タブに件数付きのバッジが表示されます。「在庫」タブには同時に、仕入れへ移動する警告バナーが表示されます。

「発注が必要」セクションでは、商品は仕入先ごとにグループ化されています。各行には現在庫、発注点、推奨数量が表示されます。数量は修正でき、アイテムはチェックを外して除外できます。**「発注を作成」ボタンは選択したグループについて仕入先への発注を作成し、ブロック上部の⚡「発注を一括作成」**ボタンはすべてのグループについて一度に作成します。

通知#

タブ上部の**「通知」**ブロックでは、仕入れのタイミングをどのように知るかを設定します：

• 在庫低下時のプッシュ — オーナーの携帯電話への通知（注文を表示するのと同じアプリ）。
• 「何を発注すべきか」のメールダイジェスト — 発注点を下回ったアイテムのリストを記載した毎日のメール。チャネルは個別に有効化し、アドレスは**「ダイジェスト用メール」**欄に設定します。空欄の場合、メールはオーナーのアドレスに送信されます。
• 値上げアラートのしきい値 — 再インポート時に仕入先の価格表が何パーセント値上がりしたらシステムが警告するか。仕入先のカート全体で計算され、既定値は**10 %**です。
• 仕入先への発注のメール自動送信 — 1日1回、システムが発注点を下回ったアイテムについての発注を自動で作成します。発注には**「優先仕入先」**欄が入力されている商品のみが含まれ、さらに未完了の発注がないものだけが対象です — 仕入先が重複したメールを受け取ることはありません。発注の送信先は、仕入先の連絡先で選択されているチャネルによって決まります：
  • メール — システムがメールを自動送信します。発注は「仕入先への発注」セクションにすでに「送信済み」ステータスで表示され（備考にauto-orderのマーク）、仕入先のカードには送信イベントが残ります；
  • WhatsAppまたはTelegram — メッセンジャーで最初にメッセージを送れるのは人間だけなので、システムは作業を最後まで進め、「仕入先への発注」セクションに完成した発注の下書きを残します。あとは「送信」を押すだけで、必要なチャネルはすでに選択されています。 仕入先に連絡チャネルが1つも入力されていない場合、その仕入先への発注は作成されません — トグルスイッチの下に、そのような仕入先の数と、下書きとして送信される発注の数が表示されます。

仕入先への発注の送信#

作成された発注は**「仕入先への発注」セクションに「下書き」ステータスで表示されます。「送信」**ボタンは発注テキスト付きのモーダルを開きます — テキストは編集でき、その後いずれかのチャネルで送信できます。仕入先の連絡先が複数ある場合、上部で宛先を選択します。そのカードで選択されているチャネルが最初に表示され、星印が付きます：

• WhatsApp — 仕入先の番号とのチャットが開きます；
• Email — メール本文が入力されたメールクライアントが開きます；
• Telegram — 仕入先のアカウントとのチャットが開きます；
• テキストをコピー — その他の方法で送信できます；
• 「Cenalyで送信」 — 仕入先もプラットフォームを利用している場合、発注はメッセンジャーを介さずシステム内で送信されます。

送信後、ステータスは「送信済み」に変わります。システム外で送信した場合は、手動で「送信済み」を押せます。その後、発注は「確認済み」→「一部受領」→「受領済み」のステータスを経ます。予定日を過ぎたものは強調表示されます。

発注の受領#

**「受領」ボタンは、発注の商品と数量が事前入力された標準の入庫フォームを開きます。実際の数量と価格は修正でき、仕入先のカタログも更新されます。すべてが届かなかった場合は、一部を受領し、後で残りに対して「さらに受領」**を押します。完全に受領すると、発注のステータスは「受領済み」になります。発注はキャンセルでき、ステータスは「キャンセル済み」に変わります。

拡張倉庫操作#

倉庫に関するすべての手動操作は、ページ右上のメニュー**「+ 操作」**から利用できます。

廃棄#

「操作」→「廃棄」 — 在庫を手動で減らす操作です。1回の操作で複数の商品を指定できます。廃棄理由は必須です：

仕入先への返品#

「操作」→「仕入先への返品」 — 以前に受け入れた商品の返品を処理します。仕入先を選択し、商品と数量を指定します。在庫が減少し、取引先に紐づけて伝票が保存されます。

店舗間の移動#

「操作」→「移動」 — 別の倉庫へ商品を移す操作です。同一店舗内の倉庫間（キッチンからバーへ）でも、店舗間でも可能です。受け取り先を選択し、商品と数量の行を追加します。システムは送り側の出庫と受け取り側の入庫の2つの伝票を自動で作成します。

棚卸し#

「操作」→「棚卸し」 — 3ステップのウィザードで在庫を数え直します：

1. 対象範囲 — 何を数えるか：倉庫全体、販売用商品のみ、原材料のみ。未完了の明細は後から続けられます。
2. 実数の入力 — 各アイテムごとに想定数量が表示され、実際の数量を入力すると差異がすぐに表示されます。名称、バーコード、PLUで検索でき、下書きは自動保存されるため、何回かに分けて数えられます。
3. 差異明細 — 結果：余剰と不足を、アルファベット順ではなく金額順に並べたもの。

**「確定」**ボタン（オーナーとマネージャーが利用可能）で1つの修正伝票を確定し、在庫を調整します。

再評価とラベル#

**「操作」→「再評価」は、カタログの販売価格を仕入価格と指定の掛け率から再計算し、端数を丸めます。入庫時に自動再評価を有効にすることもできます。「ラベル印刷」**は値札と倉庫ラベルを出力します — プリンターへのシート印刷、またはハードウェアブリッジ経由でサーマルプリンターへ出力できます。

**値札の価格はレジで打ち出される価格と同じです：*カタログのアイテム価格（店舗価格が設定されていればその価格）です。この店舗で商品を別の価格にする必要がある場合は、倉庫のカードで「独自の価格を設定…」を押して理由を指定してください — その価格は値札（価格に「」が付きます）にもレジにも使われ、オンラインショーケースはカタログ価格のままです。独自の価格を解除するのも同じ場所の1つのボタンです。カードに以前の項目「値札用価格」の価格が残っている場合、印刷ウィンドウにその数と「整理」ボタンが表示されます：それぞれについてカタログ価格を採用するか、理由を付けて独自の価格を残すか、カタログに書き込むかを選べます。

ロス：差異はどこへ消えたか#

**「ロス」**タブは、売上にも入庫にも見えない疑問に答えます：2回の棚卸しの間に、販売数より多く倉庫から出ていった。サイクル中の消費は3つの部分に分かれます：

まさに3行目がロスです：不正確な技術カード、目分量の盛り付け、未処理の破損、あるいは盗難。これを分析するには最初の2つが必要です。それらがなければ「基準より多く使った」と「破損として廃棄した」を区別できません。

正直な注記：サイクル内の在庫の手動修正は差分ではなく絶対値を保持するため、「未説明」の一部は実際にはオペレーターの手によって説明されています — そのような伝票は別途集計され、並べて表示されます。

ロスが理論消費を指定の割合以上に超えると、**「消費が基準超過」**ルールが発動します — ロス管理をご覧ください。

需要予測と仕込み計画#

**「予測」**タブは販売履歴を明日の計画に変えます：この曜日に何皿売れるか、そのうち何を仕込む必要があるか（技術カードの展開と「何時までに」の期限付き）、仕入先に何を発注するか、そして一日の終わりまでに品切れになるリスクがあるものは何か。

詳細は需要予測をご覧ください。

量り売り商品とラベル#

量り売り商品。商品は個数ではなくキログラム／リットルで測定できます：在庫、技術カード、廃棄も同じ単位で管理されます。ハードウェアブリッジ経由ではかりがレジに接続されている場合、重量は自動で入力されます — 入庫時も、重量あたりの価格の料理（食堂、惣菜）の販売時も同様です。重量あたりの価格の設定は料理のカードで行います。レジ（POS）をご覧ください。

**棚用ラベル。**商品にはバーコード、名称、価格、賞味期限を含む倉庫ラベルが印刷されます：商品に保存日数が設定されている場合、期限日は印刷日と保存日数の合計として計算されます。これは注文用のステッカーとは異なります — そちらはキッチンが印刷します。キッチンとホールの印刷をご覧ください。

「Chestny ZNAK」マーキング（ロシア）#

ロシアの店舗では、倉庫に**「マーキング」**タブがあり、15の対象カテゴリーすべてについて「Chestny ZNAK」のコードを扱えます。タブには5つのセクションがあります：

• 受入 — スキャナーでコードを読み取るか、UPD を XML で電子納品書をアップロードします。システムがそれを解析し、仕入先のアイテムを自社の品目と突き合わせ（突き合わせ結果は記憶されるため、2回目以降の確認は不要）、コードを入庫処理します。納品書にないコードは黙って通さず、差異として正直にマークされます。
• ケグ — コードでケグをタップに接続し、注ぎ出し量で容量を消費し、理由（空、消費、返金）を指定して取り外します。ケグのコードはレシートに差し込まれません。そうしないと、最初の1杯でケグ全体が流通から外れてしまいます。
• コード — すべてのコードの台帳：ステータス、入出庫書類、賞味期限、マーキングシステムでの照会チェック結果。
• タスク — 「Chestny ZNAK」にまだ送信する必要があるもの。提出用書類をダウンロードしてアカウントで申請し、受領番号でタスクをクローズします。未完了タスクの数はセクションのボタン上にバッジで表示されます。
• ジャーナル — すべてのチェック、ダウンロード、申請のフィード。

コードの消滅は手動だけでなく、販売はレシートからミラーリングされ（オフラインにも耐え、接続が戻ったときに送信されます）、マーキング対象原料の料理への消費はテックカードで計算されます。開封済みパッケージは端数で管理され、次を開封する前に使い切るよう調整されます。

このタブは拡張機能ストアの「Chestny ZNAK」カードでオフにできますが、デフォルトでは有効です。マーキングは法律上の義務であり、追加オプションではないからです。

アルコールは隣の**「EGAIS」**タブで管理します：輸送伝票の受入、消費、お使いの UTM のデータに基づく在庫。このモジュールはハードウェアブリッジで通常のデバイスとして接続します。

開始に必要なもの#

• 「倉庫」セクション — デフォルトで有効。商品が30以上になると、システムが自動的にその設定を提案します。
• 単位と梱包形態を設定した食材・商品のカード。
• 料理のテックカード — これがないと、販売時の自動消費が機能しません。
• 仕入価格 — これがないと原価、フードコスト、メニューエンジニアリングが計算されません。
• 権限：棚卸しの実施はオーナーとマネージャーが利用できます。
• ブリッジとラベルプリンター — 仕込みラベルと値札用。

制限事項#

• 倉庫の分析は AWS 上で動作します。 ロシアブランドでは分析データベース上の機能は利用できません — 同等性はタスクとして公開されています。
• マイナス在庫は意図的に許可されています：入庫はマイナスへの逸脱を「許容」し、販売をブロックしません。
• 在庫におけるロット管理と FEFO はありません。 FEFO はマーキング（どの開封済みパッケージを使い切るか）にのみ存在し、数量には影響しません。
• 単位の自動換算はありません — グラムとキログラムはカードの梱包形態で記述され、その場で再計算されません。
• バリエーションとトッピングのテックカードは考慮されません：基本料理の構成が消費されます。
• スマートフォンのスキャナーによるモバイル棚卸しはありません。
• 最小在庫による仕入先への自動発注は未実装です — 需要予測はありますが、自動発注はありません。
• 購買のメールダイジェストは送信されません、通知はチャットとプッシュで届きます。
• EGAIS と「Chestny ZNAK」はロシア固有の機能です：タブは国が「ロシア」の店舗にのみ表示されます。GIS MT との API によるライブ連携は接続されておらず（申請は半手動）、EGAIS の FSRA テスト環境は未通過です。VetIS（Mercury）はモックで動作しています — API へのアクセスキーが取得されていません。

トラブルシューティング#

販売後に在庫が消費されなかった。 料理にテックカードがないか、バリエーション／トッピングが販売されました — それらの構成は消費に含まれません。

在庫がマイナスになった。 これは意図された動作です：システムは販売をブロックせず、マイナスは直近の入庫で解消されます。

原価が空。 食材の仕入価格が設定されていません — これがないとフードコストもメニューエンジニアリングのマトリクスも構築されません。

マーキングまたはアルコールのタブが表示されない。 これらは店舗の所在地がロシアの場合にのみ表示されます。

棚卸しが実施できない。 実施はオーナーとマネージャーが利用でき、その他のロールは閲覧のみです。

購買に関するメールが届かない。 ここにメールダイジェストはありません — 不足や期限に関する通知はワークチャットとプッシュで送信されます。

関連セクション#

• 需要予測 — 仕込み計画、購買ドラフト、「19:00までに売り切れる」リスク
• 損失管理 — 「消費が基準超過」と「仕入価格の急騰」のルール
• メニューエンジニアリング — 原価が判明した料理をどうするか
• 財務 — 購買、フードコスト、売上総利益
• 注文 — 注文の履行が消費を開始します
• QRメニュー — テックカードが紐づく料理とコンボセット
• マルチロケーション — 複数店舗：在庫、書類、移動は店舗ごとに個別に管理
• ショップ — 商品の在庫が店頭で買い手に見えます：「残りわずか」または正確な数

よくある質問#

すべての料理にレシピ原価表を登録する必要はありますか？#

いいえ。まずは最もよく出るアイテムから始め、残りは少しずつ追加してください。レシピ原価表のない料理は在庫を消費しません。

注文がキャンセルされた場合はどうなりますか？#

消費は注文の履行に連動します。キャンセルされた注文は在庫に影響しません。

納品書はどの言語で認識されますか？#

AIは地域の主要言語（ジョージア語、ロシア語、英語など）の一般的な納品書に対応します。認識後は、確定する前に必ず結果を確認してください。

複数の店舗で在庫を管理できますか？#

はい。在庫と書類は店舗ごとに個別に管理されます。ページ上部で店舗を選択してください。

WhatsAppやTelegramを使っていない仕入先に注文を送るには？#

仕入先のカードにメールアドレスを入力すると、送信モーダルでEmailボタンが利用できるようになります。注文のテキストをコピーして、任意の方法で送ることもできます。

一部の商品だけを対象に棚卸しを実施できますか？#

はい。ウィザードの最初のステップで対象範囲を選択します。倉庫全体、販売用の商品のみ、原材料のみから選べ、名前・バーコード・PLUで検索できます。空欄のままにした行は在庫を変更しません。入力した値のみが保存されます。未完了の棚卸表は後から続けられます。下書きは自動的に保存されます。