「請求書+銀行送金」って、、、やっぱ、古い。。。
『紙で請求書を郵送したら、入金期限に入金される。』 たしかに数年前までは「それが当たり前」と思ってたんだが、、、やっぱり古い。
2. オンライン・バンキング
3. 決済までの全自動化
4. 技術サポートとの会話(フィクション)
5. 実用例
1. 紙の請求書
たとえば、紙の請求書を2枚・3枚と郵送すれば、後日「合算」して入金される。
当然ながら、その入金内訳をヒトが解読する。って、どんだけアナログやねん! ヒトが介在している時点で、「給料は、茶封筒に、現金で、1円単位で」みたいな『昭和の臭い』が漂う。
(せめて、請求書の送付はPDFで。。。できれば、請求書PDFは自動生成で。。。)

2. オンライン・バンキング
世間では「フィンテック」とか叫ばれているが、実態はマダマダだ。。。『国策としての銀行API』も、やっとこさ「参照系API」が部分解禁されただけだ。。。しかも、連携されているデータは
- “キヨウトダイガクガクチヨウ ヤマギワジユイチ”
- “カ)リクル-トホ-ルデイングス”
などのレスポンス(ホントは半角カナ)。。。貴様、コンピュータのクセに、、、まずは「カタカナ」を勉強しなおしてこい!、と。。。(特に拗音と長音がヒドイ)

3. 決済までの全自動化
やはり、「請求から入金決済まで」の業務は、ヒトを介さずに処理したい。
そうだ! 「昭和40年代生まれ」こそが、これまでの「悪しき伝統」との決別を実践すべきだ。(?)
そこでここでは、(【銀行】が「マダマダ」なので/来たるべき「銀行API時代」の無人業務を夢見ながら)、【決済代行会社】(資金移動業者)を使おうと思う!
- 決済代行会社に「電子請求書」を登録して、
- リクエストして、決済代行会社から「顧客」にメールしてもらって、
- 決済代行会社に「顧客」からの入金があれば報告を受ける
という流れであれば、今日でも、全て無人のワークフローでいけるハズだ。

4. 技術サポートとの会話(フィクション)
某「ペ〇パル社」のテクニカルサポートと、 API についての会話。。。(フィクション!!←ココ大事)
筆者:「ねぇ、ねぇ、テンプレートIDを指定しても、請求書に反映されなくない?」
(1か月後)
担当者:「オー、ホントウデスネ。開発者ニ聞イテミタラ、反映シナイノガ仕様デース。ドキュメント、マチガッテマース!」
筆者:(なんやと…)「…でさ。。。 請求日とかのタイムゾーンに日本時間 JST とかセットしても反映しないみたいだけど?」
(1か月後)
担当者:「アー、ソレ、何ヲ指定シテモ、アメリカ西海岸時間 PST ニナル仕様デェ~ッス!」
筆者:(ほへ?)「…あと、、、請求元の電話番号も、請求書に反映されなくない??」
(1か月後)
担当者:「アー、ソレー。ドキュメント、マチガッテマァーッス。phone object ハ、address object ノ、子 object トシテ Request スルト、動イチャウヨ!! ドキュメントデハ、兄弟 object ッテ書カレテルケドネ!!」
筆者:(殺す・・・) [下のサンプル code キャプチャは address と phone の関係が間違っている]
まぁ、決済代行会社(資金移動業者)が設計している API は実に合理的だ。「ペ〇パル社」の『REST Invoicing API』についても、流石だと思う。(海外送金などでは、銀行はタチウチできそうにない)
しかし、まぁ、現状においては、、、色々と問題もある。。。特にサポート。。。

5. 実用例
ちなみに、『超交流会2017』(2017-06-17)というオープンイベントでは、参加費徴収に電子請求書(PayPal請求書)が実運用されている。
その挑戦心たるやスバラシイ! 興味ある人は、是非、「参加エントリ」してみよう(!?)
すぐさま「電子請求書」のメールが届く、、、ハズだ!
PS:
- 第527話:自動工程で PayPal Invoicing API を呼ぶ
- 第528話:自動工程で PayPal ステータスの自動確認
- 第529話:PayPal業務のサブルーチン化
- 第530話:「更新系API」で支払業務の自動化
ピンバック: 自動化は RPA だけじゃない!クラウド型ワークフローでの自動化事例いろいろ - Questetra