• 特集
  • 番組
  • トピックス
  • 学び
プレミアムを無料で体験

コンビニATM 改元に伴う誤表記トラブル

NHKニュース
120
Picks
このまま本文を読む
本文を読む

コメント


のアイコン

注目のコメント

  • 公認会計士 Fintechコンサルタント

    いつも勘定系システムの落第生としてヤリ玉に上がるみずほ銀行は、昨年秋のシステム変更の際に、元号表記から西暦表記に変わりました。
    システム変更の後に記帳した分から、”以下から西暦表記となります”と書いてあって分かりやすかったです。
    だから、今回は、みずほ銀行は大丈夫ですね👌


  • 複業フリーランス コーポレートITアドバイザー

    エンジニアの立場で言うと、一度失敗した作業に対して次同じミスをしないようにするのは得意な人が多いです。

    ただ、改元なんて滅多にないことです。そういう初物に対して誤りがないよう対応するのはかなり難しいことと思います。
    金融系のシステムは複数のシステムが複雑に絡み合ってるって聞きますし、試験もままならなかったのかもしれません。

    速やかなリカバリー作業を期待しています。


  • 某IT企業 Manager

    ほとんど推測ですが、
    みずほのEBソフトは5/1以降にならないと新元号の設定が出来ないようで、その影響からかみずほのEB系システムは4月に5月振込のデータ(住民税など)を送付する際にも平成31年で送れと指示がありました。こんな対応は私の知っている限りみずほだけです。

    銀行系のデータ送信(全銀フォーマット)は年を送る時は和暦なんですが元号はデータにありません。なのでどの元号ベースで西暦変換するかは、通常日付を元に変換します。つまり5/1以降は令和(西暦=和暦年+1)、4/30以前は平成(西暦=和暦年+1988)で計算するんじゃないかと想像します。

    今回のバグは01年で送られてきたデータを平成ベースで西暦年に換算したから発生したと思われますが、その可能性としては、
    ・みずほが日付を平成ベースで送ってくると思っていたのに令和ベースで送ってきた。
    ・処理日付と同じ元号を別の日付(振込予定日)の年換算にも使ってしまった。

    このどちらかではないかと想像します。


    根拠はほぼありません。


    ちなみにこんな誰も求めていない書き込みをしているのは、我が家の坊が昼に遊びすぎて疲れてしまい夕方から寝てくれているからです。


アプリをダウンロード

NewsPicks について

SNSアカウント


関連サービス


法人・団体向けサービス


その他


© Uzabase, Inc

新しい記事ページ
を表示しています

ご意見・ご要望はこちらまで

マイニュースに代わり
フォローを今後利用しますか