私たちが従事しているスウェーデン企業ITABのキャッシュデスクの現金を受け取るための主要な複合体は、日本の企業Gloryと哀れな名前Cash Infinity 10の複合体です。
これは、コントローラーに接続された紙幣アクセプターとコインアクセプターの2つの別個のデバイスで構成されています。
コインアクセプターは、 コインの入力および出力ポイント、コンベヤー、バリデーター、8つの同一のコインボックスを備えたデバイスです。 コインは受け入れられた後、コンベヤーを介してバリデータに送られ、バリデータは額面を決定し、それに対応するコインボックスに送ります。 額面が定義されていない場合、コインはコイン出力のポイントを通して戻されます。 同様に、ゴミ、紙クリップ、キーが返されます。 コイン自体は安全に一握りで持ち込むことができます-コインアクセプターは、さまざまな金種のコインを非常に静かに処理します。 コインはそれぞれ入力と出力の両方で機能し、以前の顧客がキャッシュデスクに預けたのと同じコインで購入者に変更が発行されます。
請求書受領者の配置は異なります。 紙幣は薄い紙であり、どこかに折り畳まれている場合、それを拾うことは機能しません。つまり、紙幣の入出力システムを実装することはより困難です。 より困難ですが、可能です。 このために、特別なドラムが紙幣受け入れ装置に配置されます。認識された紙幣はそのようなドラムに巻き付けられ、配達のために同じ方法で取り外すことができます。 唯一の問題は、デバイス内のスペースが限られていることです。そのため、ドラムは3つしか配置されておらず、その上に最も人気のある請求書をインストールするのが論理的です。 他のすべての請求書（および対応するドラムがいっぱいになった場合の旅行請求書）はカセットに落下し、従業員はいつでも閉じた形で取り出して、そのすべての内容をメインのレジに持ち込むことができます。
コントローラーに接続するのは私たち次第です.2つの独立したデバイスの作業を組み合わせ、そのAPIを介して外部システム（この場合はセルフサービスチェックアウトから）からコマンドを受信し、要求された操作と現在の状態のステータスを返します。 かなり理解しやすいように思えますが、ある時点で、すべての作業を担当する1台のユニットを現金で接続することは、銀行のターミナルを接続するよりもそれほど複雑ではないと個人的に考えました。 もちろん、これは単なる幻想であり、作業の最初にすでに多くの大きな課題に直面していました。
1.支払い用の購入者インターフェース
氷山の一角（そして、後に最も理解しやすいタスクの1つであることが判明したため）は、現金を受け取るための顧客インターフェースを作成することでした。 支払い方法として現金を選択すると、デバイスがスリープモード（IDLE）から現金受け取りモード（WAIT INTSERTATION）に移行し、入力されたすべての額面に関する情報が現金プログラムに送信されます。
困難に直面しました-入金額が小切手金額よりも大きくなった瞬間、必要な金額の変更配送コマンドを送信できませんでした。APIにはそのようなコマンドはありません。 これは、導入された請求書の処理と外部システムへの転送が長いプロセスであるため、外部システムが金額の十分性について学習した時点で、紙幣または硬貨の一部を処理できるためです。 したがって、CASH REQUESTコマンドをコントローラーに送信します。このコマンドは、すべての紙幣が預けられて処理されると、変更に進むことができることをコントローラーに伝えます。 また、コントローラー自体が「変更の待機」イベントを返し、その後、変更配信画面を表示します。
2.すべての評価のタンク設定
コインでは、すべてがシンプルに見えます。8個の容器と、使用中の8種類のコインだけです。 確かに、栄光のペニーは、10ルーブルの大きなコインを受け入れません。 残りの容量は、現在の金種のいずれかの下で与えられるか、過剰なコインの下で与えられます。 2番目のオプションを選択しました。 余剰またはミキサーは、容器がいっぱいになった場合に、異なる金種のコインを収集します。 音符のすべてが少しシンプルになりました。ドラムに配置する3つの顔の値を選択する必要がありました。 クライアントと相談した後、50、100、500ルーブルの紙幣を選びました。 したがって、レジ係は千分の請求書の変更を行いません。
チューニングに関する重要な質問の1つ：セルフサービスチェックアウトで現金の支払いをブロックする値は何ですか？ もう一度CASH REQUESTコマンドをコントローラーに送信する状況を許可したくありません。また、必要な値が不足しているため、コントローラーは変更を発行できません。 支払いを事前にあまりブロックしたくありませんでしたが、問題の状況にこれ以上近づきたくありませんでした。 その結果、恐れとより簡単な実装オプションのために、より高度なソリューションを選択しました。少なくとも1つの額面について、次の値を作成するときに変更を発行できなくなった場合、現金支払いはブロックされます。 つまり、ドラム上の500ルーブル紙幣が9枚未満（つまり、5千紙幣を作るときに小額の購入で変更を発行するのに必要な紙幣の数）または100ルーブル紙幣が4枚未満の場合、現金支払いは自動的にブロックされ、購入者に通知されますこれについては、開始画面と支払い方法を選択する画面で確認してください。
さらに、現金または過剰なコインでカセットオーバーフローが発生すると、現金支払いは自動的にブロックされます。
3.紙幣または硬貨の不足または過剰の表示
表示システムの目的は、差し迫った問題状況を店舗の従業員に通知することです。 通知メカニズムには2つあります。レジの上にある懐中電灯インジケータと、店の従業員インターフェイスのレジにある現金ステータス表示です。 ロジックは次のとおりです。アシスタントがチェックアウト時の購入の間に懐中電灯が緑色に点滅し始めたら、すぐに現金のステータスを確認する必要があります。 彼は、キャッシュモードでより詳細な情報を見ることができます。
表示システムでは、注意を必要としない状態は灰色で表示され、問題のある状態に近い状態はピンク色で表示され、重大な状態（結果として現金支払いがブロックされます）は赤色で表示されます。 緑、黄、赤の状態の信号機が思い浮かんだように見えますが、この雑多な組み合わせでは、最も重要なものを分離することはより困難です。
色はコンテナの種類にも依存します。 たとえば、コインボックスが溢れるのは悪いことです。これは、すべてのコインが過剰に注ぎ込まれ、その容量が非常に小さいためです。 したがって、10ルーブルのコインボックスはピンク色で強調表示されます。 逆にドラムをオーバーフローさせることは、変化をもたらす何かがあるため、非常に良い状況です。 はい、追加の紙幣はカセットに送られますが、カセットの容量はそれらを収容するのに十分です。
境界線を設定するときに多くの個人的な質問がありました。たとえば、カセットのどの程度にピンクで強調表示する必要がありますか？ いくつかのブレーンストーミングセッションの後、これを75％に設定しました。 したがって、同時に、チェックアウトの上のランタンが点滅し始めます。 紙幣と硬貨のすべての容量について、同様の決定を行う必要がありました。
4.現金規律に関する膨大な作業ブロック
これらの機器機能の導入および撤回は、単純な作業ではありませんでした。 導入と撤回は当社のすべての現金決定に含まれていますが、原則の多くはここで完全に再考する必要がありました。
デポジットでは、全体がすべて明確になります。デポジットモードに入った後、現金とコインを受け取る人は現金を受け取る準備ができています。 入力されたすべての紙幣と硬貨の額面は、対応するコンテナの横に表示されます。 そして、すべてが入金された後、従業員は「入金を完了」をクリックして、このトランザクションを会計レジストラに渡し、入金時に書類を印刷します。
いくつかの機能がありますが、それらは次のとおりです。千分の五分音符と五千分の五分音符を作ることは意味をなしません-これらの請求書はバイヤーに発行できないカセットになります。 これは、この状況には個別の指示が必要であることを意味します。
ほとんどの場合、従業員がそのような額面を作ることはありませんが、別の状況がある可能性があります。リールの1つがいっぱいで、そこからのすべての請求書がカセットに落ち始めます。 この場合、これは非常に便利です。従業員は、この額面を追加しても意味がないことがすぐにわかります。 コインの余剰がある状況も同様です。
私は免除をいじらなければなりませんでした。 次の4種類の発作があります（原則として、通常のキャッシュデスクではできません）。
- 特定の金種の硬貨の引き出し
- 余剰コインの引き出し
- ドラムからメモを取る
- メモ付きのカートリッジの取り外し
それらのそれぞれについて、さまざまな動作が必要でした。
- コインボックスの1つからコインを引き出す場合、引き出し額は額面の倍数になります。
- 過剰なコインは、その全体だけが引き出されます;一定量のコインの一部を引き出す方法はありません、その中のすべてのコインは混合されているからです
コインボックスからのお金はすぐには返されませんが、[完全な引き出し]ボタンをクリックした後です。 免除文書も同時に印刷されます。
- 紙幣と硬貨の場合、引き出し額はドラムの額面の倍数ですが、相談後、この金額を紙幣受け入れ機ではなくカセットに送ることにしました。 したがって、この場合、出金書類は印刷されません。これは、お金が興行所に残っていたためです。
- カートリッジが取り外されると、ほとんどの一連のアクションはメーカーによって設定されます。 カートリッジを取り外すコマンドを送信し、請求書受領装置でドアがロック解除され、ロックされます。 従業員はドアを開け、カセットを取り出します。 空のカートリッジを挿入し直す必要があります。そうしないと、コントローラーは初期IDLE状態に戻りますが、カートリッジインベントリイベントを返しません。 したがって、キャッシュレジスタモジュールは引き出し文書を印刷できず、カートリッジの状態を検出できないため、この場合、現金での支払いをブロックし、空のカートリッジを挿入するよう要求することにしました。 これは理にかなっています。なぜなら、彼は引き出し後にカセットにどれだけ残っているかを知る機会が絶対にないからです。
カートリッジの取り外しの場合の選択は、取り外しのドキュメントを印刷する時点でのみでした。 最初は、空のカセットを戻すときに印刷することを決めましたが、店舗のプロセスを分析した後、カセットを取り外した直後にドキュメントの印刷を開始しました。 理由は、お金を稼いだ後、ドキュメントがメインのキャッシュデスクに残っているためです。 メインのチケットオフィスはセルフサービスのチェックアウトからはほど遠く、従業員は2回実行しなければなりませんでした。最初はお金で、次にドキュメントで。 彼らの仕事を最適化しました。
5.エラー処理
それは非常に多くの誤った境界線の状況であることが判明したため、このすべてのタイタニックな作業を1点にまとめるのは少し間違っています。 私は、開発者とテスターの両方が答える必要があったいくつかの質問と、インターフェイスデザイナーとしての私だけを提供します。
- コインジャム/ビルジャムはどのように処理されますか？ キャッシャーはバイヤーモードとアシスタントモードでどのように動作しますか？
- アシスタントが「Finish depositing」をクリックした後、彼がその後さらに数個のコインをレシーバーに投げるとどうなりますか？
- kopecksの欠如は、マークを残します：kopecksで合計金額を取得する場合（たとえば、小切手の丸めの割引が機能しなかった場合）にどうするか？
- コントローラー自体は、IDLE、WAIT INSERTATION、およびWAIT FOR CHANGE状態になるにはほど遠い場合があります。 状態は各アクションから変化します：入金をカウントするときに含まれるCOUNTINGがあり、変更額を計算するときに変更がカウントされます-変更をカウントするときに一瞬オンになり、出金時にいつでもオンになるDISPENSINGがあります。 もちろん、ERROR状態があり、発生したエラーの詳細が含まれています。 そして、そのような状態は正確に30あり、それぞれの機能は利用可能またはアクセス不能になります。 これらはすべてプログラムするだけでなく、テストする必要があります。
さて、ここで主なことについて話しましょう：行われた作業の最良の特徴はその説明ではなく、結果が使用されてその機能を実行するという事実です。
ちょうど1か月前、サンクトペテルブルクのギャラリーショッピングコンプレックスの店舗の1つに、キャッシュインモジュールを備えた4つのキャッシュデスクからセルフサービスアイランドを立ち上げました。
過度の謙modeがなければ、打ち上げは突然行われたと言えます。 バイヤーは新製品に興味を持ちました。 すでに運用の最初の週に、セルフサービスキャッシュレジスターはかなりの割合の顧客を引き受けました。 しかし、私たちは停止しません-キャッシュデスクの作業を改善および最適化するための計画には多くのアイデアがあります。
一度見た方がいいのですが、まだ試した方が良いでしょう。 ピーターズバーグに来て、私たちの決定を評価してください。
私はすべての開発者が重要な詳細に勤勉で注意を払うことを望みます。 まず最初に、ハードウェアとインターフェースの両方がユーザーを支援することを忘れないでください。