食品偽装などの事件をあげるまでもなく、食品の期限については消費者の厳しい目が注がれる ようになってきました。 期限を偽装するのは言うまでもないことですが、 期限切れの商品を並べておくことはお店の信用を失墜させることにつながります。 「わざわざ期限を確認しなくとも安心して買えるお店」であることがお客様の信頼を勝ち取る上で重要ではないでしょうか。
もちろんこれは生鮮食品に限った話ではありません。 ペットボトル等の水物、ペットフード、医薬品にも期限はあります。 ある種のキャラクター物などは季節物とさえ言え、テレビ放送が終われば見向きもされないことがあります。 また、最近の家電は製品寿命が短くなっていますし、 機械工具類にしても年月を重ねればホコリやサビなどが発生し商品価値が低くなることがありえます。
期限管理は困難な課題ですが（理由は後述します）、 本システムではできるだけ簡単な操作で期限管理が行えるよう工夫しています。 商品を「売り切る」ための期限管理を行います。
なお、食品業界では賞味期限と消費期限という二つの別の言葉がありますが、 本システムではこれを「期限」として同じものとして扱います。
期限管理を厳密に行うには、商品の個体を識別しなければなりません。 例えば、同じA商品であっても、半年前に仕入れたものと数日前に仕入れたものでは、 期限までの長さが異なるのは当然です。 バーコードからは「A商品である」ということはわかりますが、 生産日や期限などの情報は一切ありません。 バーコードの桁数が少なすぎるうえ、全商品に同じバーコードを印刷しているのですから当然のことです。
もちろん、バーコードとは別に期限が印刷されていますが、機械的にそれらを読み取ることは困難です。 どうしても目視によって確認する必要がでてきます。
個体を識別し、生産日や期限を自動的に把握する方法の最有力の候補は「ICタグ」です。 しかし、これはまだ高価ですし、現状では期限管理を機械的・自動的に行うことは困難であり、 徹底的に行おうとすればかなりの無駄を生じ、また人海戦術になってしまいます。 本システムでは、言うなれば「適度にあいまい・適度に正確な方式」を採用しています。 これは
本システムの期限管理の方式としては、同じ商品について最も早い期限にのみ着目するということです。 その他の期限は無視します。 下のように、2019/3/31という期限にのみ着目し、他の期限は考慮しません。
例えばいま、A商品について期限管理をしたいとします。
すなわち、A商品について期限の調査を行い、最も早い期限を記録しておき、 その期限が切れたら調査をやり直すという方式です。
このように、商品スタッフIIでは最小限の労力で、確実に期限管理ができるよう工夫しています。
すべての個体について期限を記録することは無駄です。 なぜなら、顧客がそれらの個体のうちのどれを手にとるかわからないからです。 すると今度は、レジを通るたびにどの期限のものかを把握する必要が出てきます。
最も早い期限だけを覚えておくことで、 期限が切れているかもしれないという警告を出すのが本システムの方式です。
上の考え方を発展させ、本システムでは実際には次のような方式をとっています。
これをイメージにすると以下になります。 左側商品は日単位の管理、右側商品は月単位の管理です。 お店と倉庫それぞれの「デポ」における、それぞれの商品について、最も早い日あるいは月を入力しておきます。
※本システムでは、最も早い期限日付のことを「最早日」、期限月のことを「最早月」と呼びます。
期限管理するしないはユーザが自由に選択できるようになっています。 また、期限が比較的長期間の商品の場合には年月しか表示されていない場合もあるので、 月単位での管理もできるようにしています。
ある商品の最早日の記録はシステム内でただ一つではなく、デポごとに記録します。 デポは、顧客によって自由に商品が持ちされる店舗デポや、顧客の干渉を受けない倉庫デポの種類があるので、 デポごとに異なる記録を取ることによって、調査回数を減らすことができるからです。 猶予期間内に特売で商品を売り切る、そのための期限管理を本システムでは提供します。
前項の例では、お店と倉庫に同じ商品が別の期限で保管されているとしました。 では、これらのデポの間で商品を移動した場合はどうなるでしょうか？ 例えば、現在のような状態にあるとします。
この状態で、店頭の商品を補充するために倉庫の商品をお店に移動したとします。 この場合には、お店の商品の期限は変更されません。2019/3/31のままです。 倉庫の商品の方が期限が長いからです。
逆に、何らかの都合によりお店の商品の一部を倉庫に移動したとします。 この場合は倉庫の商品の最早日も2019/3/31となります。 移動された商品には最悪の場合、この期限のものが含まれるからです。
お店のデポから商品が販売等で出庫した場合ですが、お店デポのその商品の期限は変更されません。 たとえ、出庫する商品の期限がまさにその商品を代表する最も早いものであっても、 レジでのバーコードスキャンではわかりませんので、システムとしては何もしません。
例えば、商品の仕入操作と入荷操作によって、例えば10個の商品を入荷し、5個ずつをお店デポと倉庫デポに格納したとします。
この場合、本来であれば、入荷した商品によって各デポの期限日が変更されるべきですが、しかし、 たいていの場合には、「入荷商品の期限は、在庫商品期限より長い」と言えると思います。 そうでないのはかなり特殊なケースと言えます。
したがって、「外部からデポに商品が入庫した場合、期限を変更しない」ことをデフォルトにできます。 もちろんこれは、入荷ごと商品ごとに変更することができます。
詳細は、入荷履歴・入力画面を参照してください。
猶予日数（月数）とは、期限切れになる以前に警告されるべき日数（月数）を逆算するためのものです。 例えば、猶予日数を３０日にした場合で、期限が５月1日のときはその３０日前の４月１日には警告が発生します。 これを使って、賞味・消費期限以前に特売などを行い、期限の近い商品を売り切るということができます。
商品スタッフIIにおいて、期限管理に関する機能は複数の場所にあります。それぞれを簡単に説明していきます。 詳細は各機能のマニュアルを参照してください。
スマートフォンとBluetooth接続のバーコードスキャナを使用して、各商品の期限日（あるいは月）を入力していきます。 あらかじめ期限タイプ（日単位管理か月単位管理か）を設定しなくとも、その場でタイプを決定し、その期限日（月）を指定することができます。
主に、上述のウェブ端末を使用した期限データを入力し、各商品の期限日を決定するものです。
レジ画面にある「期限」タブです。店舗デポについて、猶予期間あるいは期限切れの商品を一覧します。 レジ担当者の手の空いたときに店舗商品の期限チェックを行うことができます。
仕入先からの商品入荷時の処理です。一般に在庫商品よりも期限は長いと考えられますので、デフォルトは「非考慮」となっており、 入荷商品は期限設定に影響を与えません。