Transformation rule "dateerayearmonthdayjp"に関するまとめ

XBRL

dateerayearmonthdayjpに関する問題まとめ。（2013/8/21時点）

Transformation ruleとは？

Inline XBRLに記述されたファクトをインスタンスに変換するルール。
次世代EDINETでは、提出者がInline XBRLで作成し、EDINETがインスタンスを作成して公開される。このインスタンスを作成する過程で使用される。

dateerayearmonthdayjpとは？

いわゆる「和暦西暦変換」のルール。例えば、Inline XBRL上で「平成２５年８月２１日」なら、インスタンスでは「2013-08-21」と変換する。
Transformation Registry Version 2に登録されている。

なお、本文には変換の具体的なルールは記載されていない。具体的なルールは、reference transforms(xsltによる実装例)の方にある。

問題点は？

問題は２つある。
・第１に、明治・大正・昭和・平成だけしか定義されていないので、明治より前の元号が使えない。
・第２に、明治元年から明治５年末までの変換ルールが間違っている。（明治５年末までは、旧暦（太陰暦）が使用されていた(wikipedia)が、その考慮がなされていない。）

影響は？

次世代EDINETでは、大量保有報告書もInline XBRLで提出することになっているが、その中に「設立年月日」という要素があって、明治５年以前の日付を記述しなくてはいけないケースがある。
明治より前であれば、dateerayearmonthdayjpは使えないし、明治元年〜明治５年であれば、dateerayearmonthdayjpを使うと正しく変換されない。（ルールが間違っているのだが、その間違ったルールの通りに変換してしまう）

実際、RT(総合運転試験)では、ある会社の設立年月日が「明治2年5月4日」と記載されていて、インスタンスでは「1869-05-04」となっていた。（“明治2年5月4日”は西暦1869年6月13日だから、明らかにおかしい）

金融庁の対応は？

金融庁はこの問題を正しく認識している。

RTのQAにおいて明治より前の日付については、dateerayearmonthdayjpを使わずに、dateyearmonthdaycjk（「YYYY年M月D日」形式の西暦）を使うことを推奨している。

さらに、旧暦について個別に確認したところ「明治5年以前の日付を記載して詳細タグ付けする場合は、西暦での記載」するようにQ&Aに記載されるとの回答があったそうだ。

しかし、利便性の問題は残る。
大量保有報告書のWEB入力フォームでは和暦入力しかできない。EXCELツールでは、そもそもEXCELが1900年（明治３３年）以降しか対応していない。そのため、西暦を使うにしても、ツールで（昭和などで仮の日付を入れておいて）作成したデータを、直接エディタなどを使って修正しなければならない。

どうすべきか

提出者は、金融庁の指示通り、明治５年以前の日付はdateerayearmonthdayjp（西暦）を使うようにすべき。

データ利用者は、インスタンスを利用する場合には、日付型の項目で値が「1868-01-01」〜「1872-12-31」の場合には、誤って変換された値かもしれないと疑う必要がある。（Inline XBRLのファクトのTransformation ruleがdateerayearmonthdayjpで、Inline XBRLのファクトが「明治元年〜明治５年」だったら不正な変換が行われている可能性が高い）

金融庁は、大量保有報告書のWEB入力フォームを西暦入力ができるように修正すべきだろう。（EXCELのツールはそもそもEXCELの制限なので修正は難しいと思われる）

そして、Transformation ruleは、dateerayearmonthdayjpが明治５年以前は無効であるように修正されるべきだ。（正しく旧暦から西暦に変換されるルールが実装できればよいが、それは複雑になりすぎると思われる）

(2013/8/22 修正)
(2013/8/21 初稿)