＿お待たせしました。前回記事の予告のように、鬼のように大変な思いをしてMFFマクロをGnuCashとのインポート／エクスポートのデータ変換に対応させることができました。バージョンナンバーも、現行のV2.23からV2.25にする予定が、さらにV2.27にまで飛びました。その理由は、プログラムをGnuCashからのエクスポート（GnuCash2MFF）で1回、GnuCashへのインポート（MFF2GnuCash）で2回、全面的に書き直したためです。
＿当Blogでは、MFFマクロを公開後、解説記事を執筆中に改良点や不具合を発見してさらにバージョンアップすることがよくあります。GnuCashへの対応については絶対にそうなることが判っていたので、プログラム公開を延ばしておりました。…が、当該サブルーチンだけでなく、周辺のサブルーチンまで改修しなければならなくなったのは誤算でした。
＿一連のバージョンアップ作業の中で、MFFマクロの大きな問題点も見えてまいりました。今回のGnuCashへの対応の中で最も足を引っ張ったのが、振替取引のデータに対して「反対取引をでっちあげる」というMFF形式の仕様です。
＿もともと、この仕様は、マイクロソフトマネーにデータをOFXでインポートする際「1口座ずつしかインポートできず、振替取引を認識させることもできない」という制約に対応し、MFF形式の家計簿データを「口座名」で絞り込んでOFXファイルを出力する、という運用を想定したものです。つまり、口座A→口座Bの振替取引に対し、口座Aからの振替支出のデータはあっても、口座Bへの振替収入のデータは無い（口座Bの出納を正しく認識できない）…という事態を回避するための仕組みです。
＿ところが、GnuCashは複式簿記を強く意識した造りになっているため、「口座A→口座B」の取引データと「口座B←口座A」の取引データの両方があると…データ変換処理の中で「口座Bを借方、口座Aを貸方とするX円の資金移動」と「口座Aを借方、口座Bを貸方とするマイナスX円の資金移動」という二つの表現が両立してしまい、特にスプリット取引のように「主軸とする口座名をデータから特定する」という処理を記述する際に大混乱を起こすのです。GnuCashが負の金額を取り扱える仕様になっているのが事態をさらに厄介にする…。このあたりの頭の整理のためにサブルーチンを全面的に書き直しする羽目になった、というわけです。
＿幸いであったのは、直前に、複式簿記を基本設計としたDARUMA家計簿への対応を経験していたことでした（例えば2021/07/19 DARUMA家計簿からのデータエクスポートの方法も新しくなりました）。これが無かったら労苦はさらにキツいものになったでしょう。
＿また、MFF形式のもう一つの難点が「取引先欄」が収入・支出取引と振替取引でデータの意味が異なる、という仕様です。これも、毎度毎度の処理において、取引データがどちらの取引を意味しているのかを判断しなければならず、プログラムが非常に冗長になる原因になっています。
＿このように、MFFマクロも次の大幅改良をそろそろ考えなければならないようです。いつになるかは判りませんが…