「電子請求書」は世界を救う、、、ハズ

「請求書＋銀行送金」って、、、やっぱ、古い。。。

『紙で請求書を郵送したら、入金期限に入金される。』　たしかに数年前までは「それが当たり前」と思ってたんだが、、、やっぱり古い。

 

 

たとえば、紙の請求書を２枚・３枚と郵送すれば、後日「合算」して入金される。

当然ながら、その入金内訳をヒトが解読する。って、どんだけアナログやねん！　ヒトが介在している時点で、「給料は、茶封筒に、現金で、１円単位で」みたいな『昭和の臭い』が漂う。

（せめて、請求書の送付はPDFで。。。できれば、請求書PDFは自動生成で。。。）

 

世間では「フィンテック」とか叫ばれているが、実態はマダマダだ。。。『国策としての銀行API』も、やっとこさ「参照系API」が部分解禁されただけだ。。。しかも、連携されているデータは

• “キヨウトダイガクガクチヨウ ヤマギワジユイチ”
• “カ)リクル-トホ-ルデイングス”

などのレスポンス（ホントは半角カナ）。。。貴様、コンピュータのクセに、、、まずは「カタカナ」を勉強しなおしてこい！、と。。。（特に拗音と長音がヒドイ）

 

 

やはり、「請求から入金決済まで」の業務は、ヒトを介さずに処理したい。

そうだ！　「昭和40年代生まれ」こそが、これまでの「悪しき伝統」との決別を実践すべきだ。（？）

 

そこでここでは、（【銀行】が「マダマダ」なので／来たるべき「銀行API時代」の無人業務を夢見ながら）、【決済代行会社】（資金移動業者）を使おうと思う！

1. 決済代行会社に「電子請求書」を登録して、
2. リクエストして、決済代行会社から「顧客」にメールしてもらって、
3. 決済代行会社に「顧客」からの入金があれば報告を受ける

という流れであれば、今日でも、全て無人のワークフローでいけるハズだ。

 

 

某「ペ〇パル社」のテクニカルサポートと、 API についての会話。。。（フィクション！！←ココ大事）

 

筆者：「ねぇ、ねぇ、テンプレートIDを指定しても、請求書に反映されなくない？」

（１か月後）

担当者：「オー、ホントウデスネ。開発者ニ聞イテミタラ、反映シナイノガ仕様デース。ドキュメント、マチガッテマース！」

 

筆者：（なんやと…）「…でさ。。。 請求日とかのタイムゾーンに日本時間 JST とかセットしても反映しないみたいだけど？」

（１か月後）

担当者：「アー、ソレ、何ヲ指定シテモ、アメリカ西海岸時間 PST ニナル仕様デェ～ッス！」

 

筆者：（ほへ？）「…あと、、、請求元の電話番号も、請求書に反映されなくない？？」

（１か月後）

担当者：「アー、ソレー。ドキュメント、マチガッテマァーッス。phone object ハ、address object ノ、子 object トシテ Request スルト、動イチャウヨ！！ ドキュメントデハ、兄弟 object ッテ書カレテルケドネ！！」

 

筆者：（殺す・・・）　［下のサンプル code キャプチャは address と phone の関係が間違っている］

 

まぁ、決済代行会社（資金移動業者）が設計している API は実に合理的だ。「ペ〇パル社」の『REST Invoicing API』についても、流石だと思う。（海外送金などでは、銀行はタチウチできそうにない）

しかし、まぁ、現状においては、、、色々と問題もある。。。特にサポート。。。

 

 

ちなみに、『超交流会2017』（2017-06-17）というオープンイベントでは、参加費徴収に電子請求書（PayPal請求書）が実運用されている。

その挑戦心たるやスバラシイ！　興味ある人は、是非、「参加エントリ」してみよう（！？）

すぐさま「電子請求書」のメールが届く、、、ハズだ！

 

なおソースコードなどの詳細について興味ある方は、以下の関連記事を参照されたい。

• 第527話：自動工程で PayPal Invoicing API を呼ぶ
• 第528話：自動工程で PayPal ステータスの自動確認
• 第529話：PayPal業務のサブルーチン化
• 第530話：「更新系API」で支払業務の自動化