ユーザが明細取得期間を指定できない

[hiromu2000]

以前お話したことがありますが、現在、ユーザがDTSTARTとDTENDを指定できず、明細取得期間はプラグイン毎の実装に依存しています。 結果として、みずほ銀行であれば「前々月1日から本日までの明細」、三菱東京UFJ銀行であれば「前月1日から本日」と、バラバラです。 一方、OFXの仕様においては、クライアントがDTSTARTとDTENDを指定できるようになっています。

そこで提案なのですが、server.phpへのPOSTのクエリに、DTSTARTとDTENDを指定できるようにするのはいかがでしょうか？ あくまでserver.phpがDTSTARTとDTENDを受け入れるかどうかであり、index.phpでDTSTARTとDTENDを指定させるかは別です。すなわち、ブラウザでOFXProxyを利用しているユーザのUIは必ずしも変更の必要はないと思っています。

実装上は以下の２点がポイントになります（抜け漏れあればご指摘ください）。 １．server.phpでは、DTSTART <= DTENDを確認 ２．各プラグインでは、何月の明細ページを取得するか判定し、得られた各明細をレスポンスに含めるか否か判定 ２の実装が少し複雑で、クレジットカードの場合（請求月と使用した月が異なる）はより複雑になります。

すぐに答えを出す必要はないと思いますが、まずは議論を始めさせていただきたいです。 検討の結果、やはり実装が困難だ、となった時であっても、代案としてプラグイン間でバラバラとなっている明細取得期間を統一することもありかなと思っています。最悪、銀行、証券、というカテゴリ毎の統一でもよいです。

長文になりましたが、ご検討のほどよろしくお願いいたします。

[outerguy]

ご提案くださりありがとうございます。趣旨は理解いたしました。 （特に銀行は）デフォルトの明細取得期間を指定しているところが多く、それに準じて、または各サイトの仕様や制約に応じて期間指定しているため、ご指摘の通りバラバラとなっています。

かなり前（オープンソース化する前）に、期間の統一を検討し、ソースコードの改修規模を調査したことがありますが、想像以上に大変で断念したという経緯があります。 具体的には、デフォルトの期間を使えば画面遷移が不要なところ、任意で期間を指定すると何画面か遷移しなければならないなどのケースがありました。 とはいえ、期間がバラバラなのは、格好が悪く統一感に欠けるため、せめてカテゴリ毎には揃えたいと、漠然と考えていました。

一方、クライアントより期間を指定するという発想はありませんでした（確かに以前お話しいただいたと思います。忘却しておりすみません…）。 仰る通り、２．の実装は頭が痛いところですが、プラグイン側の実装にかかわらず、ひとまず./server.phpで2変数を受け入れ可能とすること自体は、何ら問題ないと考えます。

各プラグインで受け入れる変数名は、$ofxforms["DTSTART"]と$ofxforms["DTEND"]あたりが無難でしょうか。また、値は「YYYYMMDD」の8文字で差し支えないと考えますが、いかがでしょうか。

[hiromu2000]

ご検討ありがとうございます。 やはり実装が大変ですよね。

各プラグインで受け入れる変数名は、$ofxforms["DTSTART"]と$ofxforms["DTEND"]あたりが無難でしょうか。また、値は「YYYYMMDD」の8文字で差し支えないと考えますが、いかがでしょうか。

はい、その方式でよいと思います。何かのプラグインで実装例を検討してみます。実装例が出来上がった際に、再度ご相談させてください。

[hiromu2000]

楽天証券で実装してみました。証券と銀行は比較的簡単です。DTSTARTとDTENDでフィルタリングすればいいからです。

問題はクレジットカードですね。請求月を考慮に加えると複雑になります。仕様として２案考えてみました。 １．請求月は考慮せず、使用日だけでフィルタリングする。 例：DTSTART=20150101, DTEND=20150331の場合、2015年1月1日から同年3月31日に使用した明細のみを返す。 ２．請求月を考慮し、請求月ベースで処理する。具体的には、DTSTARTとDTENDには「YYYYMM」の入力しか認めない、又は「YYYYMMDD」を認めてもDDは無視する。 例：DTSTART=20150101, DTEND=20150331の場合、DDを無視し、2015年1月、2月、3月が請求月となる明細のみを返す。 個人的には案２がよいと思いますが、いかがでしょうか。

まずは仕様を固めたいと思いますので、マージはしばらくお待ちいただきたいと思います。

[outerguy]

リプライが遅くなりすみません。以下、長くなりますがご容赦ください。

楽天証券の例で、実装方法を明確に理解できました。銀行と前払式帳票（電子マネー）につきましては、対応時に明細取得ロジックの修正は必要なものの、仕様で悩むケースはないと思っています。

一方、（楽天証券を含め）証券は、1点だけ気になりました。持ち高（<INVPOSLIST>）を過去日に遡って取得するのは、実装上、難しいです。少なくとも、SBI証券とカブドットコム証券のサイトでは、時系列データを取得できません。 （株価や基準価額は、外部サイトを参照すれば、実装そのものは可能です。）

おそらく、以下の2案での割り切りが必要だと思います。 案A. 持ち高は明細取得期間の指定にかかわらず、常に現在値を取得・出力する。 案B. 持ち高（<INVPOSLIST>）自体を出力しない。（OFXAnalyzerのチェックは通ります。）

クレジットカードは、ご提示の通り案2が良いと考えます。 主に実装上の都合になりますが、案1の使用日ベースの場合、2か月遅れで明細に載るケース（ガソリンスタンド等）なども考慮しなければならず、明細の取得範囲を事前に確定できないからです。

また、DTSTARTとDTENDですが、YYYYMMDDで実装を統一するのが良さそうに思います。 つまり、ご提示の通り、クレジットカードの場合はDDを無視するほうが無難だと考えます。

または、銀行等・証券・前払式帳票（電子マネー）側もYYYYMMに片寄せし、DTSTARTのDDは01、DTENDのDDは末日とする方法も考えられます。 もっとも、こちらの場合、DTSTART/DTENDは、OFXの定義と異なる値を取るため、名称を変えたほうが良いかもしれません。

[hiromu2000]

強いて言えば案Aですが、個人的には案Aでも案Bでもどちらでもよいです。OFXの仕様ではINVPOSLISTは必須ではないようですし。

YYYYMMDDかYYYYMMのどちらかにするかという問題ですが、YYYYMMDDへの統一がよいと思います。 OFXの定義には出来る限り忠実であったほうがよいと考えます。

[outerguy]

ご意見くださりありがとうございます。

私自身実は未だに案A・Bで悩んでいます。指定するのはあくまでも明細取得期間のため、持ち高はその指定から除かれると考えれば案Aで問題ないですし、持ち高と明細取得期間を合わせるのであれば案Bとなりますし、…で逡巡しています。処理の都合を考えると案Aのほうが楽なのは自明ですが。

YYYYMMDDでの統一は、了解いたしました。