＿前々回・前回と「かけ～ぼ」へのデータのインポート方法について解説してまいりました。今回は、その際にMFFマクロがどのような処理を行っているか、について解説します。
１．MFF2KKBサブルーチンの処理について
（１）最初っから愚痴ってしまいますと
＿これまで述べてきましたとおり、「かけ～ぼ」は非常に独特な動作をする家計簿アプリです。一般的な家計簿アプリであれば、銀行口座、電子マネー、クレジットカード等は一つの資産として扱い、通常の取引は、それぞれの資産からの収入・支出・振替として記帳します。ところが「かけ～ぼ」はそうではなく、電子マネーおよびクレジットカードは、”帳簿”からの「支払い方法」として「お金の動きが実際にはいつ発生するか」というキャッシュフローの把握に活用するだけの概念になっています。
＿そのため、「かけ～ぼ」⇒MFF形式の変換では、
- 「ある”帳簿”から電子マネーまたはクレジットカードを使って支払った取引」を→
- 「電子マネーまたはクレジットカードという資産口座から支出した取引」に変換する
＿という処理でよかったのです（これも結構面倒でした）が、逆方向の MFF形式⇒「かけ～ぼ」の変換では、
- 「電子マネーまたはクレジットカードという資産口座から支出した取引」を→
- 「ある”帳簿”から電子マネーまたはクレジットカードを使って支払った取引」に変換する
＿という処理になり、ある"帳簿"という「本来のMFF形式データには無い情報」をユーザーに補完してもらう手順を踏まなければなりません。
＿また、MFF形式では口座の種類という概念が無く、例えば「電子マネーからクレジットカードへ返金する」といった通常ではあり得ない取引であっても表現できるのに対し、「かけ～ぼ」では、アプリで入力できない取引は当然ながらデータとして飲み込ませることもできません（仮に出来たとしてもおそらく不具合の原因になるでしょう）。そこで、「かけ～ぼ」では受け付けられない取引を、事前に排除する処理も必要です。
＿さらに、一般社会ではあり得るが「かけ～ぼ」では記帳できない取引（例えば電子マネーへの収入）もありますので、そのようなデータは特殊な方法で記帳するように変換することになります。
＿このように、今回解説する MFF形式⇒「かけ～ぼ」の変換サブルーチンMFF2KKBの開発は、これまでの家計簿アプリの軽く10倍以上の手間を要しました。ここまでやって、一体何人が使うんだろう…という疑問に苛まれながら。
（２）フローチャート
＿MFF2KKBサブルーチンの概略フローチャートを↓に示します。MFFマクロのサブルーチンのフローチャートを公開するのは当Blogでは旧Blogを含め初めてです。
＿このフローを元に、「かけ～ぼ」へのインポート手順を改めて解説しますと…
- 「かけ～ぼ」のアプリ側で"帳簿"・”電子マネー"・”クレジットカード"、そして費目構成をがっつり設定する（"その他収入"・"その他支出"の追加も忘れずに）。つまり、MFFマクロでは現時点で「かけ～ぼ」に設定していない資産・費目のデータを生成することはできない
- 一度Dropboxへバックアップを行う
- MFF形式データを用意する
- 【MFFマクロ動作】Dropboxへバックアップした情報（card.csv、codeName.csv）を元にして、MFF形式データの口座名や取引の組み合わせが「かけ～ぼ」側で受け付けられるかチェックする（一次チェック）
- 一次チェックで引っかかった組み合わせの取引や口座名をユーザーが修正する
- 【MFFマクロ動作】MFF形式データを「かけ～ぼ」形式に変換する。その際、ユーザーが"帳簿"を指定しなければならない箇所、「かけ～ぼ」側に無い費目の箇所を（items.csvの情報を使って）チェックする（二次チェック）
- 二次チェックで引っかかった「"帳簿"が不定となっているセル」および「費目が間違っているセル」をユーザーが修正する
- 【MFFマクロ動作】ユーザーの修正が完了している場合は、「かけ～ぼ」のcashbook.csvを出力する。その際、従来のデータへの追加とするか、完全な新規データにするかをユーザーが選択する。
- 出力されたcashbook.csvをDropboxの所定のフォルダに上書き保存する
- スマホの「かけ～ぼ」アプリで、Dropboxからのデータの復元を行う
＿このようになります。1.～9.が前々回、10.が前回の記事で操作を解説したところです。
２．支出取引の変換処理
＿ここからは、MFF形式の取引種別ごとの変換処理について解説します。まず支出取引ですが、これが最も簡単なものの、マクロが行っている処理は結構大変です。MFF形式データのD列「口座名」欄に入っている名称が「かけ～ぼ」における
- 帳簿
- クレジットカード（請求日登録型）
- クレジットカード（利用日登録型）
- 電子マネー
３．収入取引の変換処理
＿「かけ～ぼ」は支出管理を主眼としている家計簿アプリであり、収入の記帳については変則的なやり方が必要になります。
（１）"帳簿"への収入取引の場合
＿普通に給与などで収入があった場合のデータです。MFF形式の口座名に入っている名称が「かけ～ぼ」における"帳簿"である、と判断した場合に↓のように変換します。
（２）"電子マネー"への収入取引の場合
＿ポイントが貯まったので電子マネーにチャージしよう、というような場合の取引ですが、残念ながら「かけ～ぼ」は電子マネーに収入を記帳できませんので、一旦、ある"帳簿"に収入があり、同日に、その"帳簿"から同額を電子マネーにチャージした、という2件の取引に変換します。
＿その際、その"帳簿"をどれにするのか をユーザーが指定するわけですが、2箇所の帳簿コードの指定を同じにしないとおかしなことになります。MFFマクロではそこを整合させるようなところまではしていないので十分に注意して操作してください。
（３）"クレジットカード"への収入取引の場合
＿クレジットカードでの買い物をキャンセルした場合にカード会社から返金された、というような取引データですね。「かけ～ぼ」はクレジットカードにも収入を記帳できないので、MFFマクロでは「マイナスの支出」に変換しています（非公式なやり方なので不具合を起こす危険性が皆無ではありませんが…）。その支出の費目として、ユーザーが定義した「その他支出」を使っています。
４．振替取引の変換処理
＿前述の「３．収入取引の変換処理」で触れましたように、「かけ～ぼ」は電子マネーやクレジットカードへの収入取引についてはイレギュラーな方法を採らねばなりません。そこで、MFFマクロでは振替取引については↓のように処理します。クレジットカードを振替先とする取引（通常はあり得ないですよね）は、前述の「一次チェック」の際に弾くようにしています。
（１）"帳簿"→"帳簿"の振替取引の場合
＿MFF形式の「口座名欄」と「取引先欄」の両方が「かけ～ぼ」でいうところの"帳簿"であると判断した場合に↓のように変換します。
（２）"電子マネー"・"クレジットカード"→"帳簿"の振替取引の場合
＿電子マネーおよびクレジットカードから"帳簿"への振り替え、となると…電子マネーの払い戻しや、クレジットカードからのキャッシングが考えられますが、いずれも「かけ～ぼ」では素直に記帳できない取引です。MFFマクロでは「電子マネーおよびクレジットカードからの支出」と「"帳簿"への収入」の同日・同額の取引に変換します。この場合は、電子マネー・クレジットカードの取引に紐づける"帳簿"は確定できるので、ユーザーによる補完入力は発生しません。なお、このデータ変換には「かけ～ぼ」のユーザー定義費目「その他支出」・「その他収入」を使います。
（３）”帳簿"・"電子マネー"・"クレジットカード"→"電子マネー"の振替取引の場合
＿「かけ～ぼ」ではどういうわけか「電子マネーで電子マネーをチャージする」という奇妙な取引が記帳できるので、MFFマクロでも変換処理をしています。
＿いや～大変だったあ！ こんなにも面倒くさい思いをしたのは初めてです。何せ、これだけの変換処理を記述しているということは…Excel VBAで「かけ～ぼ」アプリのデータ処理部分のクローンを作っているのと同じなのです。
＿なお、「かけ～ぼ」については、電子マネーやクレジットカードを全て"帳簿"扱いにしてしまうという使い方もできる、と2020/06/02の記事で述べましたが、MFFマクロは当然そのような使い方にも対応可能です。
次の「かけ～ぼ」関係の記事は2020/09/23「かけ～ぼ」に新バージョンが出現していた…！→
