静岡市内の本店と焼津・藤枝の支店で、同じ表を見ているのに月末の売上が合わない。多店舗のシステム相談では、そんな話をよく聞きます。
原因は入力ミスだけではありません。誰がどこまで見て直せるか、何をもって一日の売上とするか。この二つが曖昧なまま共有を始めると、便利なはずの仕組みが確認作業を増やします。
全店共有の前に「見える範囲」と「直せる範囲」を分ける
権限は、役職名だけで決めるとうまくいきません。同じ店長でも、売上承認は必要だが顧客情報の一括出力までは不要、ということがあるからです。私はまず、閲覧・登録・修正・承認・出力・削除を別々に書き出します。
現場で使いやすい権限の切り方
- 店舗スタッフは自店の当日取引を登録し、担当した顧客の必要項目だけを見る
- 店長は自店の締め処理と修正申請を行い、他店は合計値だけ確認する
- 本部担当は全店を集計するが、顧客情報の持ち出しは担当者を限定する
- 経理担当は入金と売上の照合に必要な数字を見て、接客メモは見ない
- 管理者は権限設定を扱い、日々の売上修正は通常行わない
大事なのは「見られる人を増やす」ことより、仕事に不要な情報を見せないこと。退職や異動の日に停止する手順、誰がいつ出力したかを残す記録も、最初から運用に含めます。
売上日はレジ時刻ではなく、営業日の定義でそろえる
飲食店や夜間営業の店舗では、午前1時の会計を暦どおり翌日へ入れると、店長が見ている日報と本部集計がずれます。そこで「営業日の切り替えは午前3時」など、実態に合う締め時刻を全店で決めます。時刻は業態ごとに違うため、これはあくまで設定例です。
売上額も、税込か税抜か、値引き前か後か、返品や取消を元の日へ戻すか処理日に載せるかを決めておかないと比較できません。キャッシュレス決済の手数料を売上から引く店と、経費へ分ける店が混在するのも典型的なずれです。
集計表に先に書いておく定義
- 売上日と締め時刻
- 税込・税抜、値引き、返品、取消の扱い
- 受注時・提供時・入金時のどこで売上にするか
- 店舗別売上の帰属と本部売上の範囲
- 修正できる期限と承認者
あとから数字を上書きするのではなく、元の記録と修正記録を両方残す。これだけで「誰が変えたか分からない」がかなり減ります。
顧客は電話番号だけで名寄せしない
静岡駅周辺の店と郊外店を同じお客様が利用すると、表記ゆれで二人として登録されがちです。ただし、同じ電話番号だから同一人物とも限りません。家族の共用番号や法人の代表番号もあります。
候補は氏名、電話番号、メールアドレスなど複数項目で出し、統合は権限を持つ担当者が確認する形が安全です。各店には接客に必要な範囲を表示し、住所や全店履歴を常に開示する必要があるかは別に考えます。利用目的の案内や同意の取り方も、実際の会員制度に合わせて整理が必要です。
店舗間の在庫移動を売上にも仕入れにも数えない
在庫で多いのは、清水店から駿河区の店へ商品を送った瞬間、送り元で減り、受け取り先ではまだ増えていない状態です。ここを無理に即時反映すると、配送中の商品が消えたり、両店にあるように見えたりします。
移動申請、出庫、移動中、入庫完了という状態を持たせ、受け取り側が数量を確認して完了させます。店舗間移動は販売ではありません。全社在庫には含めつつ、店舗在庫では「移動中」と分ける設計が実務向きです。
棚卸差異も黙って現在数へ合わせず、破損、廃棄、数え間違いなど理由を選び、店長承認を残します。本部が見るべきなのは在庫数だけでなく、差異がどの店で繰り返しているかという流れです。
最初から全店一斉に変えず、二店舗で締めまで通す
導入時は、本部と性格の違う二店舗を選び、一般的には二週間から一か月ほど試すのが目安です。繁華街の店と郊外店、営業時間の長い店と短い店を組み合わせると、例外が早めに出ます。
- 開店前のログインから日次締めまで一連の操作を試す
- 返品、顧客統合、店舗間移動をテストデータで再現する
- 旧帳票と新集計の差額を日ごとに確認し、理由を記録する
- 締め後に直す場合の申請と承認を、実際の担当者で通す
画面の使いやすさだけで合格にせず、月次集計まで数字がつながるかを見るのが肝です。エラーで取得できなかった店舗を売上ゼロと表示しない設計も欠かせません。「未取得」と「本当にゼロ」は、経営判断ではまったく別物です。
自社の店舗運用に合わせて整理したい方へ
既製の仕組みをそのまま入れるより、今の締め方、承認経路、帳票を一度並べたほうが、残す業務と変える業務を判断しやすくなります。NIRでは、導入前の整理から権限表、集計定義、運用後の見直しまで、静岡の現場に合わせて支援しています。
店舗数や現在の管理方法がまだ固まっていなくても構いません。まず困っている確認作業から、システム導入・開発を無料で相談するでお聞かせください。