４次元多様体なんて大上段に構えてしまいましたが、お金、商品（モノ）、情報のそれぞれの流れである「取引」の内容を理解し、これをいかにしてプログラムと言う実体のある形に定式化するか、その方法論を考えることが、今回のポイントです。
あまり抽象的なことを考えていても前に進みませんので、具体的な例を出して検討しましょう。
■通販の支払方法にコンビニ振込と言うのがあるのは、ご存じでしょうか。
バーコードが３つとか４つ印刷されている用紙をコンビニに持って行って支払うものですが、この入金を確認してから商品を発送すると言う販売方法について考えます。
消費者が、あるWebサイトで欲しい商品を見つけました。支払方法の中から「コンビニ（先払い）」を選んで、その場でバーコード付きの振込書を印刷しました。それを持ってコンビニでお金を支払いました（日付は4/10とします）。
この入金情報はコンビニの本部にオンラインで伝送され、2〜3時間後には通販会社に入金があったことが伝えられます。しかし実際にこのお金が、コンビニから収納代行会社経由で通販会社へ支払われるのはずっと後になります（4/25とします）。
4/10時点で通販会社は入金の連絡を受けて直ちに出荷作業に入ります。運送業者が荷物を取りに来る時間に間に合えばその日の内に出荷しますが、間に合わなければ翌日出荷となります（今回は翌日4/11とします）。更にその翌日に消費者の手に届けられました（4/12）。
さて現実に起こった（はずの）この取引の内容を、お金、商品、情報のそれぞれの流れに整理すると次のようになります。
■お金
＜消費者＞(4/10)→＜コンビニ＞(4/25)→＜通販会社＞
■商品
＜通販会社＞(4/11)→＜運送会社＞(4/12)→＜消費者＞
■情報
＜消費者＞(4/10)→＜通販会社＞
＜コンビニ＞(4/10)→＜通販会社＞
ここで、経理の仕訳を行うプログラムを起動すると、以下のような情報操作の機能が必要になることが分かります。
■4/10 （収納代行）未収金／前受金
■4/11 前受金／売上
■4/25 普通預金／未収金（収納代行）
更に、具体的な例を続けます。
■支払方法がコンビニ（後払い）ではどうなるでしょうか。
詳細な説明は省略して結果だけ書きます。
■お金
＜消費者＞(4/15)→＜コンビニ＞(5/10)→＜通販会社＞
■商品
＜通販会社＞(4/11)→＜運送会社＞(4/12)→＜消費者＞
■情報
＜消費者＞(4/10)→＜通販会社＞
＜コンビニ＞(4/15)→＜通販会社＞
仕訳は次の通りです。
■4/11 （消費者）売掛金／売上
■4/15 （収納代行）売掛金／売掛金（消費者）
■5/10 普通預金／売掛金（収納代行）
この二つの例から分かることは、消費者からの入金という「取引」でも、その仕訳方法を見ると、一方は、
■4/10 （収納代行）未収金／前受金
であり、もう一方は、
■4/15 （収納代行）売掛金／売掛金（消費者）
となって、全く異なる仕訳をする必要があると言うことです。
この違いはどこから来ているかというと、「支払方法」と言う概念から来ているのですが、この「支払方法」と言う概念は、「委託販売」や「消化仕入」と言った概念と同じように、取引先との契約内容、やさしく言えば約束、ルールなのです。
このルールとはすなわち、情報と機能と言う関係性で説明すれば「機能」以外何者でもありません。
よく、データこそ重要であって、アプリケーションはその次と言う議論がありますが、筆者がこの論に全く組しない理由はここにあります。 KAI