@yukipsn JR東日本の改札は良く分かっていないのですが、3番と4番に付けられている赤と黒の装置がいずれQRリーダーとして機能する部位ということで良いのでしょうか

#ICカードこれひとつ
実名を出してよいのかわからないため伏せますが、介護老人福祉施設のセキュリティカードのダンプデータが届いています。

FeliCa Lite-Sですが、データ領域にデータは書かれていませんでした。
カードNo.や職員No.はカード内に記載はなく、FeliCaのID(IDm)のみを用いて認証をしているものと思われます。

Googleマップ
なにかの炎上事件が発生したとき、デタラメな更新でデタラメな内容になったりすることが多々ありますからねえ

OSMでもデタラメな更新は可能でしょうが、誰かが気づいた時点でリバート&アカウントBANは確実なので大きく乱れないという優位点はありそうですね。

それ以前に、炎上するような不人気な店はそもそもOSMに記載されていない可能性が高そうという問題はありますが

続き

以下は必ず対応するのでメモ

一つのPOSに複数のIC R/Wがある場合の登録作業を容易にする(全国交通系、地域交通系、WAONで端末が異なるような場合)

一つのIC R/Wを複数のPOSで共有している場合に対応する(レジ2台でIC R/Wが1台のような場合)

一つのIC R/Wで複数の契約がある(交通系とWAONで契約が異なり、同じCARDNETでも番号が異なるような事例)に対応する

交通系の報告でもWAON対応レジがある場合、WAON SPRWID DBまで仮作成できるようにする。その逆も同様。発見!イイお店での表示で見栄えがよくなる

コンビニの場合、セブンイレブン・ファミリーマート・ローソンは店番の入力から始まり、店番不明は原則として報告できないようにする。

続き

店舗なら、同じ店番をもつ中で履歴がある場合はその全レコードが表示され編集できる。有効期限内の店舗DBに紐づけるよう、下層と紐づけて編集する

売場が複数ある場合、1つ以上の売場のレコードを作成または更新する。過去まで含めるかは要検討
その売場にPOSレジが複数ある場合、全台のレコードを作成できるようにする。過去まで含めるかは要検討
IC R/Wが複数ある場合、全台のレコードを作成できるようにする。過去まで含めるかは要検討

最上位となる店舗DBから、最下位となる交通系またはWAON SPRWIDのDBまで、一貫としてDBを用意し、それを弊社に提出する仕組みとなる。

現在、何度も細かく修正して再報告される事例があるため、報告前に内容を表示し、問題があれば戻って修正できるようにする。

報告履歴保存機能は仕様を変更し、同じ交通系・WAON SPRWIDであれば他の利用でも表示できるようにする。表示速度も高速化される。過去の報告履歴を引用して報告する機能は廃止する。
従来の履歴も履歴表示に限り利用可能とするが、機能は制限される。また表示速度は早くならない。

続く

#ICカードこれひとつ

今後開発する物販報告機能に関する覚え書き

現在は各種情報を記載して「報告」し、弊社がチェック、修正、データベースを作成して登録する

今後は報告者が「データベースを作成」して弊社がチェック、修正、登録する

と方向性を変える。

登録作業で既に弊社では手に負えない量になっているため、弊社がやっている作業の大部分を報告者に委ねることで登録作業を高速化することを見込む。
報告者の、1件報告あたりに要する作業時間は5〜10分あるいはそれ以上になると見込まれ、確実に現在の数倍の作業時間を要する。その分、弊社での作業量が減ることが期待される。

現在よりデータベースが細かく分かれるため、各DBに対応するよう画面を用意する
報告者は、アプリ画面の中でデータベースのレコードを作成する仕組みとする

各レコード編集画面において、最新情報はアプリ内ではなく、発見!イイお店で用いるサーバーに置かれるDBから引用する。既に登録されている店の更新の場合、サーバーから受信して表示される。

続く