2024/03/23 GnuCashからエクスポートしたデータをMFF形式に変換する機能を修正中 で予告しましたように、GnuCashは、V5.0以降で、エクスポートした取引データの形式が変更されたようで、従来のMFFマクロではMFF形式へのデータ変換がうまくできなくなっておりました。そこで、今回MFFマクロをV2.54に更新してこの問題に対処しました。
1．GnuCashの仕様変更とは？
GnuCashV5シリーズからの取引データのエクスポートは、V4シリーズと同じで、2021/11/17 GnuCashからエクスポートしたデータをMFF形式に変換する（前篇）でご紹介した方法で行えます。
GnuCashV4シリーズからエクスポートした取引データの例を↓に示します。
V4シリーズのGnuCashは、通常、複式簿記の貸方・借方に相当する2行で1データを構成します（貸方・借方の順序は決まっていない）。また「スプリット取引」（1回の取引で複数の貸方・借方を記帳する、いわゆる複合仕訳）では、取引の1行目に相当する「親取引」にのみ日付～アクションの8列に情報が入り、2行目以降（当Blogでは便宜的に「子取引」と呼びます）はこの8列は空欄となります。
このデータ構造は、データ変換のうえでは結構面倒臭そうに思えますが、「取引データの境界がはっきりする」というメリットがあるのです。
ところが、GnuCashV5シリーズからエクスポートした取引データ↑は、全部のデータ行に日付～アクションの8列にデータが入ります（少なくとも日付欄と商品・通貨欄は必ず入る）。そのため、V2.53以前のMFFマクロでMFF形式に変換しようとすると、親取引と子取引の整合チェックに引っかかって停止してしまいます。子取引を見つけることが出来ないからです。
正直、このGnuCashの仕様変更は筆者にはかなり迷惑なものでした。なお、↑の画面例では、N・O列が追加されているのが判りますが、こちらは即座に削除してしまえば良いのでさして障害にはなりません（何のために追加されたのかさっぱりわからん）。
2．MFFマクロV2.54における対処とは？
そこで、MFFマクロV2.54では、GnuCashからエクスポートした取引データであると判断した場合、まずN・O列が追加されているかどうかを判定し、追加されていればV5シリーズのデータであるとして真っ先に削除します。また、日付・取引ID・説明欄に同じデータが続いている場合は、最初の行以外の行の日付～アクションの8列をクリアします。
つまり、GnuCashV4シリーズのデータ形式に戻してしまい、その後、従来と同じ処理をするのです（そのため、V4シリーズからエクスポートした取引データにも対応しています）。
ただし、この処理方法では、たとえ異なる取引であっても、たまたま日付・取引ID・説明欄が同じになっている取引が続いているケースでは、それぞれの取引の境界を検出できず、MFF形式に変換する処理がうまくいかなくなります。そこで「1組の通常取引およびスプリット取引は最終行において金額数値欄の総和が0になるはずである」（GnuCashでは貸方・借方の金額が一致しない「貸借不一致」という状況が有り得るが、もちこんこれは好ましいものではない）、という性質を利用して、取引データの境界をダブルチェックで検出しています。
ということで、GnuCashV5からエクスポートした取引データをMFF形式に変換したところを↓に示します。V4からエクスポートしたデータでも変換結果は同じになります。
ところで、MFFマクロV2.54では、それまでのバージョンに存在していたバグも修正しました。そのバグとは、「説明欄」に入力されているMFF書式＝(品名)(@店名)(※備考)の情報のうち、品名と備考の文字列を無視してしまう、というものです。ただ、2021/11/19 GnuCashからエクスポートしたデータをMFF形式に変換する（後篇）でマクロの動作を解説したときにはこのバグは無かったんですよね…どうしてこうなってしまったのか、は謎です。
とにかく…GnuCashV5シリーズの仕様変更には対応することが出来ました。なお、V5シリーズへのデータインポートについては従来のMFFマクロで出力したインポート用CSVファイルで可能ですので、マクロの処理は変更していません。