NECモバイルPOSには、商品が売り切れた時にその商品を販売できないようにする「販売ステータス」の切り替え機能があります。
POSでは、商品を素早く見つけ出すために、部門別に分類された商品選択画面が用意されています。タッチパネルで商品を選んで、販売することができます。
ここで、本日用意していた「おでん」が売り切れたとします。これから先は、おでんの注文を受けられない状態ですので、商品選択画面に表示せず選択されないように設定することができます。
販売ステータスを「販売停止」にすることで商品選択画面で表示されなくなります。
詳しくはこちらの動画をご覧ください。
店舗で商品を販売している時に、特別割引などで定価とは異なる売価で販売することがあります。NECモバイルPOSではその販売価格の変更をワンタッチで行うことができます。
まず初めに、加盟店ポータルで、商品マスタを登録するときに、特別売価を３種類登録できるので、事前に登録します。
そして、実際に販売する際に、売価をワンタッチで変更することができます。
dPackが最初に開発された時は、売上分析機能からスタートしました。POSで蓄積されたデータを有効活用しようというのがその最初の設計ポリシーだったからです。
ですが、POSにも集計機能や分析機能があります。ここではdPackの分析機能との役割分担についてご説明します。
（１）POSの売上分析
POSでは、クラウド上のサーバーに売上レシートデータを７年分保管するように設計されています。これは、税務上の証憑書類の保存期間に対応しているためです。このデータ保存があるので、レシート控えを紙で保存するという必要がなくなりました。
つまり、最も細かいレシートデータが取り出せるようになっているのです。
一方、大量のデータを蓄積しているということは、それを集計するのにとても時間がかかります。
ですから、すぐに取り出せるデータは直近の31日間に限定することで、集計スピードを上げています。
これは、POSの分析機能が、直近の売上データを検索して、修正したり入力間違いを探し当てたりすることを主たる目的にしていて、お客様からの問い合わせにすぐに対応できるようにしているからなのです。
（２）dPackの売上分析
それとは逆に、dPackの売上分析は、事業者の会計期間（12ヶ月）において経営成績を分析できるようにすることを目的に開発されました。
ほとんどの事業者は１年毎に決算を行い、前年度と比較しながら経営成績を評価しています。
ですので、dPackでは売上データは標準で過去24ヶ月をデータとして保存し、それよりも古いデータは自動的に削除して集計スピードを早めています。（別料金で25ヶ月以上の保管をすることも可能です）
dPackは集計スピードを早めるために、画面上に表示される集計データについては、集計テーブルを使って事前に集計して保持しています。売上データが５分毎にPOSから送信されてくるたびに、再計算して集計しています。
そのため、すでに集計したデータを表示するだけなので、分析帳票の画面表示が数秒で可能になるのです。
このように、POSとdPackは分析機能について役割分担をしています。
dPackの分析機能についてはこちらにサンプルをご用意しています。
dPackを導入すると、POSで登録した商品マスタはdPackにも２重で登録する必要はありません。それは、dPackの開発にいたった経緯から、必ずデータ連携することを実現してきたからです。
dPackにはPOSの機能がありません。これは、お店ですでに導入されているPOSレジがそのまま使えるよう、他社のPOSとデータ連携することを最初から目指したからです。
dPackの開発当時はまだ1台で100万円以上するPOSが主流でした。それを買い替えてもらうわけにはいきませんよね。
ですので、過去にたくさんの他社メーカーのPOSとのデータ連携を実現してきました。
そうしているうちに、POSについてもiPadで動作するクラウド型のサービスが始まりました。dPackは開発当時からブラウザで動くクラウドサービスでしたので、ようやくPOSが追いついてきたというわけです。
ここでは、最も導入実績の多いNECモバイルPOSとdPackのデータ連携を事例に、商品マスタの自動連携について説明します。
（１）自動データ連携の説明動画
まず、POSで登録された商品マスタからdPackにデータ連携するまでの説明動画をご覧ください。
（２）POSのポータルサイト（クラウド）
クラウド型サービスは、インターネットブラウザを通じてサーバーに接続して使用します。POSで使用する商品マスタの登録は、そのサーバーに登録することになります。
この画面は、NECモバイルPOSの「加盟店ポータル」サイトといって、POSの設定を行う画面です。SafariやEdgeなどインターネットブラウザを使ってアクセスします。
店舗と本部が離れている場合や、店舗が複数ある場合でも、店舗まで行かなくてもPOSの設定を変更できるように、クラウド上のサーバーでPOSの設定ができるようになっています。
ちなみに、この時点でdPackの商品マスタにもコピーされています。（後述）
（３）iPadで動作するPOS（アプリ）
店舗で使用するPOSは、iPad上で動作します。POSシステムはアプリで作られていて、Apple Storeなどからダウンロードしてインストールします。
POSシステムを起動すると、最初にサーバーからデータダウンロードするかどうかを確認されます。
これは、サーバー側にある商品マスタなどのデータが変更されているので、最新のデータに置き換えることをお知らせしてくれています。
ところで、POSシステムはどうしてアプリで作られているのでしょうか？
それは、インターネット接続が切れてしまっても、POS機能が使えるようにするためです。
インターネットが使えないからといって、お客様に注文やお会計ができませんなんて言えませんよね。
つまり、POSシステムは、アプリとしてiPadの中だけで動作するようにして、インターネット（主にWiFi）が再接続されたときに、サーバーに売上データを送信するように設計されているのです。
ですので、もし停電になってもお会計は可能というわけです。
（４）dPackとのデータ連携（クラウド）
dPackはPOSのサーバーと直接データ連携しています。POSで設定されている情報は、売上や商品だけでなく、部門や分類、消費税設定にいたるまで、すべてのデータをdPackサーバーにコピーしてきているのです。
ですので、POSのデータで集計したり分析したりする機能は、すべてdPackでも実現可能です。さらに、そのデータを使って在庫管理や売上分析に活用していくわけです。
完全なリアルタイムでサーバー接続するとサーバーに負荷がかかりますので、おおよそ５分毎にデータ連携しています。ですので、正確に言うと「ほぼリアルタイム」です。
例えば、POSで売上データが登録されると、POSサーバーに送信され、５分後にはdPackにコピーされて、ブラウザから売上分析ができるということです。
上記（２）でNECポータルで登録された商品は、それよりも前にdPackにデータ連携されています。
店舗や施設の中に複数の売り場が分散していて、それぞれにPOSが設置されているケースではその売り場ごとに「店舗」として運営するのではなく、施設全体を「店舗」として運営されていることがあります。その場合、NECモバイルPOSでは標準料金で３台までPOSを設置でき、さらに別途有償にて台数の追加も可能です。
このような場合、dPackも同様に施設全体を１店舗（＝１拠点）としてご利用いただけますが、その場合は在庫管理は「拠点ごと」になってしまうので、商品の在庫数量は全売り場の合計つまり施設全体の合計数になってしまいます。ですので、そのままでは売り場ごとの在庫数量を別々に把握することはできません。
ただし、次の条件のどちらかに当てはまる場合には在庫管理が可能になります。
（条件１）POSの「部門」が売り場ごとに分けられていて、その取り扱い商品が異なる場合
（条件２）同じ商品であっても「部門」ごとに別商品としてPOSに登録されている場合
それでは、その２つの条件を詳細に見ていきます。
dPackの商品マスタは原則としてPOSの商品マスタと自動連携していますから、POSに登録された商品がそのままdPackの商品マスタに自動的に連携されます。そのとき、POSで登録された「部門」を在庫管理に使用することができますので、上記の条件を満たせば部門ごとの在庫管理を行うことが、結果的に売り場ごとの在庫管理と同じになります。
上記の（条件１）の場合には、そもそも各売り場で取り扱っている商品が全て異なっており、同じ商品を複数の売り場で販売することが無いのですから、施設内の商品在庫数を合計したとしても、dPackでは部門ごとにそれぞれの商品在庫数がわかるので問題ありません。
少し手間がかかるのが上記の（条件２）の場合になります。その理由は、仕入れた商品と販売する商品のコードが異なる状態で使用するためです。
例えば、POSの商品マスタの設定が次のようになっていたとしましょう。
| POS商品マスタ | ||
|---|---|---|
| POS部門 | POS商品コード(JAN) | POS商品名 |
| 売り場X | 2 900001 000001 | 商品A（売り場X用） |
| 売り場Y | 2 900002 000002 | 商品A（売り場Y用） |
POSでは「部門」ごとに商品を登録する必要がありますので、上記の「商品A」は同じものであっても、POSでは商品コードが異なる別の商品として登録しなければなりません。（※ 29から始まる14桁のPOS商品コードは社内だけで使用するインストアコードを表しています。インストアコードはJANコードの無い商品の管理に便利です。詳しくはこちらをご覧ください）
POSとのマスタ自動連携を選ばれた場合（当社が初期設定にて登録します）は、自動的にdPack側でも次のように商品マスタがコピーされます。
| dPack商品マスタ | |||
|---|---|---|---|
| dPack部門 | dPackPLUコード(JAN) | dPack商品コード | dPack商品名 |
| 売り場X | 2 900001 000001 | 00000 00001 | 商品A（売り場X用） |
| 売り場Y | 2 900002 000002 | 00000 00002 | 商品A（売り場Y用） |
上記のように、「部門」もJANコード（＝PLUコード）も、商品名もすべてPOSとまったく同じデータがコピーされるようになっています。（※ dPack商品コードは自動的に採番されます）
さて、商品Aが仕入された時の仕入先商品コードが「S-12345678」だったとしましょう。この商品を仕入する場合には、材料マスタに次のように登録します。
| dPack材料マスタ | ||
|---|---|---|
| dPack部門 | dPack材料コード | dPack材料名 |
| 物流倉庫 | S-12345678 | 商品A（仕入状態） |
（dPackでは仕入商品を「材料」と呼んでいます。詳しくはこちらをご覧ください）
さて、この状態で商品Aを100個仕入たとしましょう。在庫が増減したときは必ず移動伝票を入力します。移動伝票を仕入区分で入力すると、在庫照会の画面は次のように表示されます。
| dPack在庫照会 | ||||||
|---|---|---|---|---|---|---|
| dPack部門 | dPackPLUコード | dPackコード | dPack品名 | 仕入 | 売上 | 在庫 |
| 物流倉庫 | （なし） | S-12345678 | 商品A（仕入状態） | 100 | 0 | 100 |
この状態でPOSで売り上げたとしましょう。例えば売り場Xで20個、売り場Yで10個の売上があったとします。
商品Aは外部の仕入先から仕入したときには商品コード「S-12345678」で仕入していますが、この施設内では売り場に応じて部門を分けて管理しているので、社内専用のコード（インストアコードと言います）で商品登録しています。ですので、このままでは、次のように在庫数がマイナスになってしまいます。
| dPack在庫照会 | ||||||
|---|---|---|---|---|---|---|
| dPack部門 | dPackPLUコード | dPackコード | dPack品名 | 仕入 | 売上 | 在庫 |
| 売り場X | 2 900001 000001 | 00000 00001 | 商品A（売り場X用） | 0 | 20 | -20 |
| 売り場Y | 2 900002 000002 | 00000 00002 | 商品A（売り場Y用） | 0 | 10 | -20 |
| 物流倉庫 | （なし） | S-12345678 | 商品A（仕入状態） | 100 | 0 | 100 |
これを解決するために、物流倉庫から売り場に商品Aを補充するときに「移動伝票」を使って名前を変換してあげなければなりません。具体的には、店舗に補充したタイミングで次のように在庫移動の入力をします。（在庫移動画面で下記の３行を３回に分けて入力します）
| dPack在庫移動 | ||||
|---|---|---|---|---|
| 移動区分 | dPack 部門 | dPack材料コード | dPack品名 | 移動数 |
| 補充出庫 | 物流倉庫 | S-12345678 | 商品A（仕入状態） | 30(-) |
| 補充入庫 | 売り場X | 00000 00001 | 商品A（売り場X用） | 20(+) |
| 補充入庫 | 売り場Y | 00000 00002 | 商品A（売り場Y用） | 10(+) |
ここで、移動区分として使用している「補充出庫」「補充入庫」は、事前に移動区分として独自に登録し、わかりやすく表示した例になっています。（このように、dPackでは入庫と出庫などのグループ別にそれぞれ10種類の独自区分を登録することができます。）
その結果、次のように正しい在庫数量が表示されました。
| dPack在庫照会 | ||||||||
|---|---|---|---|---|---|---|---|---|
| dPack 部門 | dPack PLUコード | dPackコード | dPack品名 | 仕入 | 補充 入庫 | 補充 出庫 | 売上 | 在庫 |
| 売り場X | 2 900001 000001 | 00000 00001 | 商品A（売り場X用） | 0 | 20 | 0 | 20 | 0 |
| 売り場Y | 2 900002 000002 | 00000 00002 | 商品A（売り場Y用） | 0 | 10 | 0 | 10 | 0 |
| 物流倉庫 | （なし） | S-12345678 | 商品A（仕入状態） | 100 | 0 | 30 | 0 | 70 |
つまり、物流倉庫から店舗に補充されたときに、在庫移動によって商品をPOS用に変換していると考えていただけるとわかりやすいです。このように設定すると、売り場（＝部門）ごとの在庫管理が実現できます。
なお、棚卸についても同様に、部門別に棚卸しをカウントすることが可能です。詳しくはこちらをご覧ください。
上記の設例では、仕入品「商品A（仕入状態）」を「商品A（売り場X用）」と「商品A（売り場Y用）」のように売り場別に分けて商品登録し、売り場ごとの在庫数量を管理できるようにしましたが、これとは反対に売り場で異なる商品を販売してもひとつの仕入品の在庫数量として合計して管理したい場合にもdPackは対応しています。詳しくはこちらをご覧ください
また、POSに登録した商品を部門ごとに別商品として登録したものの、売上高はやっぱりひとつの商品として売上合計で見たいという場合にも、dPackの売上分析機能を駆使して実現することができます。詳しくはこちらをご覧ください。