既に番号が変わっていて古い報告になりますが、
ドトールコーヒーショップ 福岡空港国内線ゲート内店
が、nimocaで報告されていました。
しかし再検証すると番号帯がおかしく、SUGOCA契約の番号帯ではないかと予測される結果が出ました。
この店は本当にnimoca契約だったのでしょうか?
番号帯から予測されるのは、他の店と同様に空港管理会社からリースされる決済端末を利用していたものと思われ、周辺他店と近い番号のようです。
既に番号が変わっていて古い報告になりますが、
ドトールコーヒーショップ 福岡空港国内線ゲート内店
が、nimocaで報告されていました。
しかし再検証すると番号帯がおかしく、SUGOCA契約の番号帯ではないかと予測される結果が出ました。
この店は本当にnimoca契約だったのでしょうか?
番号帯から予測されるのは、他の店と同様に空港管理会社からリースされる決済端末を利用していたものと思われ、周辺他店と近い番号のようです。
2年前に、
ドトールコーヒーショップ 久留米大学病院店 (久留米大学病院 総合診療棟1階) [福岡県久留米市]
4年前に、
SOLAE 南到着店 (福岡空港 国内線ターミナルビル1階 南到着出口外) [福岡市博多区]
が、それぞれnimocaで報告されております。
しかし再検証すると番号帯がおかしく、SUGOCA契約の番号帯ではないかと予測される結果が出ました。
これらの店は本当にnimoca契約だったのでしょうか?
またSOLAEについては、他の店と同様に空港管理会社からリースされる決済端末を利用していたものと思われ、周辺他店と近い番号のようです。
再確認が可能でしたら、再確認をいただければ幸いです。
駅ナカのセブンイレブンなど、SuicaなのかPASMOなのか微妙な店も、発見された上位4ビットの番号帯により概ね判定が付くようです。
駅ナカでPASMOと概ね断定できそうな不明情報については、PASMOに変更しておきます。
#ICカードこれひとつ
交通系電子マネーで、新たに発見された4ビット(16進数1桁ぶん)の情報の追記作業を鋭意実施しており、まずは弊社で確認した情報についての追記作業をある程度終え、全体の2割程度が完了しています。
全部への追記作業と、DBの仕様変更およびアプリ対応をもって本事案を完成させるまでは当分かかる見込みです。
その間、大規模な物販登録作業は実施されない見込みですので、あしからずご了承願います。
なお、登録作業について外部への委託を計画しておりますが、現時点では全てで断わられております。
@NagisaTakayama 以前からそういった報告はありましたが、不思議ですね
交通系とWAONの契約は別とはいえ、順序は合わせた方が管理しやすいと思うのですが
このアカウントは、notestockで公開設定になっていません。
交通系SPRWID
全部で32ビット(ビットは情報処理の単位)程度と書きましたが、少し過小評価しすぎかなと思ったので訂正します
頭の2文字(JEやJWなど)を除いた数字11桁部分は2つの部位に分かれていると予想され、それぞれを合わせて、35〜38ビット程度の情報を持つと予想されます。
実際の仕様書は見たことがないので正確なところは分かりませんが、現状では、そう判断できます。
バスの乗り方の不統一はバス停調査に行くにもかなりの支障になっているので、統一して欲しいですね。
以前にも書きましたが、バスは、
「後ろ(中)乗り、前降り」
として、
「(均一区間でも)乗降双方でICカードタッチ」
に統一するのが良いのではないかと考えております。
均一区間なら整理券は要らないと思いますがICの場合は乗降両方タッチとすると、需要のある区間をバス会社は把握できるようになり、系統の改廃の際には重要な情報として利用できます。
西日本でも、最近では神戸市バスがその理由で1タッチ(降車時)から2タッチ(乗車時と降車時)に変更されていますね。
このアカウントは、notestockで公開設定になっていません。
バスの乗り方シリーズ
・前乗り均一運賃
・後ろ乗り整理券制
・後ろ乗り均一運賃
・前乗り整理券制
--邪悪の壁
・前乗り申し出制
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
物販における交通系電子マネーについての重要なお知らせ
これまで、C7〜CAの区別のほか、番号の一部がカードに書かれていることを確認していました。
全部で32ビット(ビットは情報処理の単位)程度あると思われる番号帯のうち、番号の下位16ビットが記録されていることが既知でした。
しかしこのたび、別の領域に追加で4ビット記録されていることが分かりました。つまり、合計下位20ビットが記録されていることが判明しています。
これに正式対応すると、従来より番号の衝突が1/16になるメリットがあるため、本アプリではこの対応の準備を開始しました。これに伴って、詳細画面でのIDも仕様が変わり、
C8-12345
のように-の後の桁が5桁に増えます。
このうち1の桁が新規で判明した桁になります。登録済み情報もこの追加桁を網羅する必要がありますが、今さら膨大な量の情報に書き足すのは至難の業であるため、データが残っておらず検証不能な古い情報は抹消処分とせざるを得なくなる可能性が高いです。
以上ご了承願います。
1ビットというか可能性としては全体としてみて4ビットが足りない可能性が高い
DBの構造を今のうちに変えていく必要がある
未知の情報として1欄用意していたが、これを2欄にするか、1欄を暫定的に記号で分割しておいて後で一気に処理するか迷うところ
DBの欄を増やすのは難しいので記号で分離することを想定
記録が期待より1ビットたりない
現状仕様での想定から外れすぎていてかなり難しい
データが揃ったところで大規模なDB仕様変更が必要になることは確か
#ICカードこれひとつ
交通系電子マネーで、これまで想定していない新事実が発覚しました。
3万件を超えるDB情報を手作業で調整して改良していけるか分かりませんが、次のバージョンまでに改良のための準備処理を加える計画です。
#ICカードこれひとつ
セブン‐イレブン ひたちなか大成町店
同じ番号C7-1541から1/2と2/2が報告されております。
どちらかが間違っているものと思われますので、ご確認いただければ幸いです。
#ICカードこれひとつ
セブン‐イレブン 水戸見和2丁目店
「ふりがな」は正しく登録されていたはずですが、「みとみわちょうにちょうめてん」と誤った報告になっていました。
また、JE10710495816 という交通系SPRWIDが記載されていました。
これは記録されているカード内番号と矛盾はないのですが、しかしセブンイレブンで交通系SPRWIDを確認する術や根拠はあるのでしょうか?
確認の術がない情報であれば、削除対応とさせていただきます。
とりあえず、「レーベンシュタイン距離アルゴリズム」に代えて、速度が速いらしい「O(NP)アルゴリズム」に変えてみました。かなり高速になっています。
検索語が短いほど遅くなる傾向にあるようなので試しに短めの店名「ファミリーマート」「北品川店」で検索するテストを実施
現レーベンシュタイン距離アルゴリズム
3回平均64.624秒
新O(NP)距離アルゴリズム
3回平均5.125秒
どうやら当社比12倍以上の高速化に成功したようです。
従来とアルゴリズムが違うので近似かどうかの成績もだいぶ違うとは思いますが、耐えられるくらいの速度にはなったかと思います。
色々なパターンで確認中ですが、概ね10秒以内には結果が出てくれるようではあります。
まさかアルゴリズムを切り替えて使いたいという方はおられないと思うので、現「レーベンシュタイン距離アルゴリズム」の処理は廃止し、O(NP)アルゴリズムに処理を置き換える方向で対応を進めます
@yukipsn 現行の版では、?/2 となっていて ? が存在するのでレジ階層で推定扱いとなります
本来この台数と筐体位置は、レシートのレジ番号などとは無関係に報告者が判断し付番することを想定していますが、どうやらそれは難しいようですので次のバージョンからはATM番号が書かれていれば番号未知にチェックが入っていても推定扱いにはしないように条件が緩和されています
ちなみに、ATM番号が若いほうが先に設置された可能性が高いので、若い方が1/2、そうでない方が2/2となるのが弊社の想定です
レーベンシュタイン距離アルゴリズムが遅いのは事実
しかし考えられる対策はあまりない
1 他のアルゴリズムに変える
若干の高速化は期待できるが、劇的な高速化になるかは不明。費用対効果が出るかどうか
2 完全一致検索とする
大手では新店以外は大体登録されているので、一致しない店は報告できないようにし、店名を再確認させ再入力させる?
これはかなり無理がある
3 大手の場合、店名は決め打ちとして、支店名のみで検索を掛ける
現在は屋号+支店名の全体から距離を求めているが、屋号はSQLレベルで決め打ちにする。
検索候補数が少なくなるので、その分高速化が見込まれる
しかし、ローソン+ポプラのようなコラボ店は期待通りに検索できなくなると思われる
@djnemo2 SQL文で単純に検索しているわけではなく、全項目を対象にレーベンシュタイン距離アルゴリズムで計算しているので時間が掛かります
@djnemo2 速度はほぼCPU速度に依存していますが、もう少し速くできないかは鋭意検討しています
#ICカードこれひとつ
セブン銀行 セブン‐イレブン 朝霞台駅南口店 共同出張所
2台あるうち、両方とも「左側」と報告されているようです。
確認のうえ再報告いただければ幸いです。
ちなみに元々は1台で、いつの頃からか2台に増台されているようです。元々あった方がどちらかもし分かれば、併せて報告をいただければ幸いです。
@yukipsn ありがとうございます。
店番とレジ番は確認できるようなので、それぞれの部位をアプリ画面に出すよう対応を加えたいと思います。
バーコードについては、年月日の8桁と、左下の12桁の数字から前後2桁ずつ削った中間8桁、の計16桁がTEXTとして記録されているようですが、JR名古屋駅 新幹線南ラチ内店はその中間8桁の頭の方が少し違っていました。
中央下にある6桁の数字の意味は不明ですがバーコードにもないことを考えるとさして重要ではない何かだろうとは思います。
JR名古屋駅 新幹線南ラチ内店については今のところ報告が確認できていませんが番号の推定ができるので余裕があれば登録するかもしれません
このアカウントは、notestockで公開設定になっていません。
#ICカードこれひとつ
昨今の物販報告に関する問題メモ
セブンイレブンやセブン銀行など、恐らく店名または座標から検索していないか、あるいは違う店を選択した上で記載内容を書き換えて報告する例が多々あり、報告内容が壊滅的崩壊をしていて登録前の修正が困難となっている。
対策方法については、店名入力後は強制的に検索することと、選択後にダイアログで良いかどうか確認する1クッションを置くことなどが想定される。
またセブン銀行で、DBにある座標はかなりずれているにもかかわらず、精度5mなどを選択して報告される方がおられる。対策方法については現時点で良い案はないが、5mを選択した場合はダイアログで確認するなど1クッションを置くことなどが想定される。
このアカウントは、notestockで公開設定になっていません。
@NagisaTakayama 端末の共有は色々な店であってどう対応するかは確定していませんが、POSとIC R/Wの結びつきをもう少し減らしたDB設計にする必要はあるのかもしれません
また、そうなった場合、「箱」番号が恐らく不要になりますが「端」番号は継続して必要だろうと思いますので、情報は集めておいて損はないかなとは思っております
三田・神戸市北区エリアの阪神バス運行便で、7月11日からNicoPaが利用可能になっているそうです
https://www.shinkibus.co.jp/sysfiles/wtn/1550/20220723_shinkibus.pdf
詳細は不明ですが、この時刻表にある阪神バスの運行が対象になるのだろうと予想されます
https://www.shinkibus.co.jp/sysfiles/wtn/1539/sandaosaka0723.pdf
バス停番号について、神姫バスと同じ番号になるのか別番号になるのか含めて不明で、調査が必要かと考えております。
このアカウントは、notestockで公開設定になっていません。
@jp_kasuga 確かにそうですが、実際に決済しなくても押すだけで分かる可能性がある、ということですね
普段は上下に点灯位置が動くランプも、契約がないところを押しても無視されますが契約があるボタンを押したときは停止しますので、契約の有効無効を判断するのは簡単そうです。
シールで隠してあっても使える場合は止まりますので
@yukipsn ATMはセブン銀行やイオン銀行だと思いますが、こちらで動作確認した範囲では特に❓が付くことはありませんでした。
それ以外でもATM/ACMを設定できるようにはなっていますが、これは新しく登場する場合を想定して念のため用意されているもので、基本的には使わないものだと判断しています。
@yukipsn 後からレジ台数を入力しても再計算されない不具合がありました。修正致します。
@yukipsn 確認しましたが、有効期限が切れている端末が検索対象になっているため、そうなっているようです。
(店などの階層と違って端末の階層は有効期限が切れていても×は出していません)
やはり有効期限が切れているものは検索対象に含めるべきではない気はしますね。
せめて、報告日ではなくその店を利用した日付として有効期間内を検索する仕様くらいが現実的ではないかと思います
@yukipsn レシートパターンは数種類あるらしいので、報告する店がどのパターンなのかをどう判断するかがカギになるのかとは思っています。
@yukipsn スタバに行く機会がないものでレシートも手元になく状況の確認ができずにおりましたが、レシート写真などいただけましたらアプリ画面に貼り付けるなどの対応を加えられるかもしれません
@miraicorp
スタバのレジ番号は、レシートに明示的な記載がありませんが、レシート(下の広告などは除く)の左下の12桁の番号の、先頭2桁(および末尾2桁)がレジ番号なのではないかと思います。
手元でチェックした範囲では、以下のようなことがわかりました。
・先頭2桁と末尾2桁は常に同じ
・番号はレジの台数以下(ほとんどの店舗は2台なので、01か02)
・北の丸スクエア店(千代田区)で、左のレジで01、右のレジで02を確認
・3台の店舗(JR東海品川駅店)で03、4台の店舗(二子玉川蔦屋家電店)で04を確認
・番号とレジの位置(左右)には関係が見られない
・1台の大家端末を2台のレジで共有している店舗で02となる例があり、決済端末ではなくレジを示していると考えられる
・ルミネの場合、交通系IC伝票のCT端末番号と同じ(01と02を確認)
・Suicaでもモバイルスターバックスでも同じ
お手元にスタバのレシートがありましたらご確認ください。
@yukipsn POS階層、IC R/W階層で、それぞれ切り替わるように調整を加えました
この複雑な動きをアプリの報告から自動化するのは非常に難しいため、どうするべきか考えています
#ICカードこれひとつ
IC R/W端末の管理用番号
具体的には店がそれぞれのIC R/Wに適当に番号を振っていたり(場合によっては名前を付けていたり?)、テナントビルのオーナーが振っている端末番号
これは現在POSの階層で記載されPOSのDBに格納されていますが、端末DBに領域を用意してそちらに移す必要があるのかなと考えています。
こういった情報がどういった種類、数、あるのか現時点ではまだ何とも言えませんが、とりあえず「端末番号」「(予備)」の2欄くらいを、オーナー、地域本部、本部、テナントビル運営元でそれぞれ用意する必要があろうかとは思っております。
かなり大がかりになるので現時点で着手日は未定ですが、後方互換は用意されるため実施されても現在報告履歴にある情報が消えることはありません(情報自体は現行の記載位置にそのまま残ります)
@yukipsn スターバックスコーヒー JR東海品川駅店については、2019/11で端末およびSPRWIDが切り替わるよう有効期限を設定しました
#ICカードこれひとつ
郵便局の報告で、次のいずれか
端N00箱00
端P00箱00
がレジ欄に記載されていない場合、現時点ではPOSの階層(将来的にはIC R/Wの階層になるかもしれませんが)で、推定対応❓のマークを付ける必要があるかなと考えています
アプリでは今後入力しやすくする予定ですが、現時点では特に記載を促していないこともあって、未記載が多いです。
こういった報告は手作業にて推定扱いに変更する対応とさせていただいております。
#ICカードこれひとつ
富士薬品グループのドラッグストア
昨年3月末までがTMNゲートウェイ、4月以降(?)はシンカクラウドに変わっているようです。
昨年3月以前の報告で登録されているもの(BT2やUT1-Neoなど)については、TMNゲートウェイだったのかどうかは未知のため特に追記はしませんが、端末とSPRWIDのDB階層で昨年3月末の有効期限を設定しました。
対象は以下2種のブランドの店です
アメリカンドラッグ
ドラッグセイムス
なお、京都のドラッグユタカについては昨年5月時点でCARDNETであることを確認していますが現在でもそうなのかは未確認です。
また、ドラッグストアスマイルは時期は不明ですが登録されている3店(三軒茶屋店、初台店、永福町店)は現存しないようです。富士薬品への吸収合併で店名変更や店の整理があったのかもしれませんが詳細は不明です。暫定的に株式会社スマイルドラッグだった頃の昨年2月末で全DB階層にて有効期限を設定しました。
このアカウントは、notestockで公開設定になっていません。
#ICカードこれひとつ
イオングループ店でのTID
TID: xxxxxZZZZZZZZ
WAON yyyyyZZZZZZZZ
の関係があることが分かっています。
xxxxxとyyyyyの関係は不明ですが1:1では対応しないようです。
もしかするとこの法則の例外はあるかもしれませんが、今のところは見つかっていません
13桁も間違えず入力するのは大変なので、WAONの報告の場合は、下8桁はWAON SPRWIDから持ってきて、上5桁だけ入力すれば良いようにすることも検討しています。
決済するときは端末のTIDの上5桁だけ覚えれば良いので、かなり楽になる可能性はあります(法則の例外があると問題が出ますが)。
#ICカードこれひとつ
WAON SPRWIDメモ
昨年7月開店の「喫茶珈琲店 ピノキオ イオンタウン富雄南店」
このWAON SPRWIDは、その3年前に閉店した、奈良交通のパン屋さん、シーカくんのパン屋さん 100円ベーカリーと同じ
3年の間にIC R/W端末(おそらくJT-R700CR)がイオンタウン富雄南の中を点々としながらピノキオに行き着いたものと思われます
#ICカードこれひとつ
コカ・コーラ自販機
WAONのみ契約で交通系未対応の自販機、あるいはその逆の時、パネルに上からシールを貼ってマークを隠していることがあります。
しかし、このシール部分を押してみると正常に反応することがあり、普通に決済できることもあります。
なのでシールが貼られてる=未対応とは必ずしも言えないようです。
従来型(JT-R381)も右丸タイプはシール関係なく押しても反応しないことが多いですが、そうでないものは押して契約があれば反応します。契約がないと音がするだけで動きはありません。新型(JT-R383CR)も同様です。
弊社が確認したのは「自動販売機|パラカ京都市東桜町第1|河原町通」として登録しているこの自販機です
https://goo.gl/maps/zZnCy9gPDwe9a2Gz6
ストリートビューでも辛うじて分かりますが、新型(JT-R383CR)でICOCA部分にシールを貼ってあるのですが、実は押して反応しますし決済もできました。何のためのシール封印なのか不明です。
とりあえずシールは信用できないため、貼られていたらまず押してみるのが良さそうです。
@NagisaTakayama なるほど
とりあえず、店名は近商ストア西大寺店とした上で、本部欄にファミリーマートとその店番を書いておくという扱いにしようかと考えています
@NagisaTakayama レシートはファミリーマートのものではないようです。ファミリーマートのレジではないので、これはそうかなとは思います。
入口にファミリーマートの店番があるのかは不明ですが、先にトゥートした公式サイトのURL
https://as.chizumaru.com/famima/detailMap?account=famima&bid=37988
によれば、店番は 37988 とのことです。
ファミリーマート扱いするべきかどうかは迷うところですね
@NagisaTakayama それでもファミリーマートの店番があるので扱いに困るんですよね
公式サイトには掲載されていますが、決済手段は現在も怪しげな記述のままのようです
https://as.chizumaru.com/famima/detailMap?account=famima&bid=37988
このアカウントは、notestockで公開設定になっていません。
@NagisaTakayama ファミリーマート近商ストア西大寺店ですが、いつの間にか交通系電子マネーに対応しているようです。
食品レジ?4台、サービスカウンターレジ2台(うち1台はCV-9300)の全てにICカードリーダーが付いて稼働状態のようです。
近商POSでは、ローソンと同型JT-R600CRでクレジットカードを扱い、ICOCAはなぜか別端末UT1-Neoを繋いでいるようです。
なお、食品レジについては4台中左から2番目、レジ0002がICOCAで報告されています
レジ的にはファミマ要素がほぼないので、アプリとして登録店名をファミリーマート近商ストア西大寺店とすべきなのか、KINSHO西大寺店とすべきなのかは迷うところです。
@yukipsn 報告を確認すると2台が20220607迄、1台共有が20220608からと設定されていたようなので、これで登録をさせていただきます
続き
「売場」については今後は常に1件以上必須とし、売場階層で履歴管理をする仕様として、売場の履歴管理を報告者にてしていただく必要があるのかと考えております。
この場合、売場情報がない場合は売場情報を作り、登録済みの売場の状況が変化した場合はその売場情報に有効期限を設定した上で新しい売場情報を作る、そして今回報告する売場情報を選択した上で、以降のレジ等タブを記載していく、という手順になるのかと思われます。
もう少し綺麗な設計にするならDBを増やし、売場は売場で1件用意して、売場履歴DBを間に挟んでここで履歴管理するという方法もあるかとは考えております。
この方法の利点は、同じ売場はDBのIDが維持され変遷を理解しやすくなることですが、欠点は従来と互換性がなくなるので報告履歴は無慈悲に全消しになることです。
#ICカードこれひとつ
物販報告の「売場」について
売場が一つの店が殆どですので、DBの容量圧縮のため、売場が一つの場合は原則として売場DBに登録しない運用をしています
しかしサブウェイ 渋谷マークシティ店で、
1 先に会計、レジ2台で1台のIC R/Wを共有
2 IC R/Wが2台に増えた
3 後での会計に変わり、IC R/Wが1台に減った
という変遷を遂げているそうで、こういった遍歴がある場合、DBにもそういった情報を記録しないと正確にレジやIC R/Wの動きを把握できません。
従来は弊社側でそれを把握し、レジDBの階層で履歴処理していました。
しかし今後は弊社は可能な限り手を付けず、報告者にその履歴管理を委ねる「(弊社にとっての)自動化」を進めるために、もう少し簡単な方法とする必要があります。
そこで上位となる「売場」DBで履歴管理しようかと考えています。
続く
@yukipsn なるほど、分かりました
その切り替わりの時期などは分かりますでしょうか
また、そういった事情がある場合、何かしらメモをいただかないと正確に登録することができないので、ご協力をいただければ幸いです
@nobudora01 報告いただきありがとうございます。
左側・右側と言った場合、2台しかないのであれば問題ありませんが、3台以上ある場合のひとかたまりの左右の場合は何らかの「基準」を書いた上で左右を表記しないと、他の人が見たときに分からないと思われます。
例えば、
(入口)1 ■■■■■ 2 3 (奥)
のように並ぶコンビニは多いですが、この場合、奥右側・奥左側のように、基準を明記する必要があろうかと思われます。