ワークフローサンプル

エクセル向け CSV としてダウンロードできるボタンを設置する。（前回記事）

会計システムにデータ投入しなければならない人の視点に立てば、その『Download ボタン』は極めて有効だ。いわゆる「仕訳伝票」のデータを Excel ファイル上に、サクサク追記していくことができる。「アル」と「ナイ」とでは、業務効率が大きく違う。日々の売掛金が、５分で入力されるか、１時間かけて入力されるか、運命の分かれ道・・・。

しかしそれでも、「Excel ファイルに追記する」という作業であるが故に、非常にクローズドな工程のままだ。たとえば、「最新ファイルは何処にあるのか？」、「その作業におけるコツはあるのか？」、「微修正が必要な場合のテクニックは？」などなど、工程に紐づくべきノウハウは俗人的なものになる可能性が高い。（ヌケモレ・コピーミス・不正といった事象発生リスクも気になる）

以下のワークフロー定義は、自動生成された複数の仕訳伝票データが Google SpreadSheets に自動追記される仕組みだ。（「MFクラウド会計」であれ、「Freee」であれ）、どんなクラウド型会計システムにデータ投入するにしても、『仕訳伝票』がクラウドで一元管理されていれば非常に便利だ。

ちなみに、そもそも、ワークフローに沢山の案件が流れ、それらの集計を行うべきは、ワークフローシステム側の仕事といえる。たとえば『案件一覧』は、各プロパティの総計や平均が集計される。しかし、各案件が「不定数の伝票」を生成するようなケースにおいては、その「伝票」を集計したい、といったニーズにはナカナカ応えづらい。その様な場合には『伝票一覧』というテーブルが別途用意されるべきだろう。

ここでは2016年5月に登場した「Sheets API v4」を使う。

[販売報告プロセス-スプレッドシート連携]

「伝票データ」は、どうやって連携させるの？

前回記事では、受注報告があった際に何枚かの「振替伝票データ」を自動生成させることに成功した。しかし、そのデータも『会計ソフト』に入力されなければ意味がない。

ん？。。。これからの時代、『会計ソフト』というより『クラウド型会計システム』（会計クラウド）というべきか？？

ただ残念ながら、「外部からの API 接続」を許可しているクラウド型会計システムは、2016年現在ほとんどないのが実情だ。そこで、どのサービスでもサポートされている「ファイルインポート」を効率よく行う事を考えてみたい。

（もっとも、あと1～2年もすれば、どのサービスも REST API over OAuth をサボートしているのだろう）

なお、業務プロセスは前回記事とほぼ同じだが、より実用に耐えるよう、「上司承認」の工程が追加されている。

[販売報告プロセス-CSVダウンロード]

「借方？、貸方？、、、ナニそれ？？、おいしいの？！」

たしかに『財務会計用語』に対して "アレルギー反応" を示すプログラマは少なくない。

しかし、社会人なら是非とも知っておきたい単語だ。基本的なITスキルを問う『情報処理技術者試験』ですら、頻出の用語となっている。もっとも「かりかた・かしかた」という、似たような訳語を当てた福沢諭吉の罪も、それなりに悪い。。。

ちなみに実務上は「左列・右列」と呼んでも何ら問題ない。どちらの列も、単に「資産内訳表」に過ぎない。どうしても具体的に言いたければ、「左列：現金資産と現金的資産の内訳」、「右列：返す必要がある資産（借金）と返す必要が無い資産の内訳」と考えれば十分だ。

では、、、クラウドサービス提供会社が

12か月分のクラウド利用権を販売した
12万円で4月1日に一年契約した
5月30日に入金される

という場合に、それぞれの「資産内訳表」（貸借対照表）はどのように変化していくのだろうか？

たとえば、、、

4月には、（まだ何も入金されてないものの）、すでにサービスを提供している訳で、「1か月分（１万円）の資産は増えている」とみなすことができる。「ツケで売る」とか「掛け売り」とか言われる（売掛金）。そして5月以降も毎月変化していく。。。

[販売報告プロセス]

「カタログ郵送、、、意外とミスが多いんデス」

公開Webフォームで受け付けた「資料請求」には素早く対応したいものだ。しかし、お客様に入力していただいた『住所』や『会社名』を間違えるとサムイ。。。たとえば「Word送付状」にコピペする時に、参照すべきレコードが一件ずれてしまい、

ウチ、そんな社名じゃないよ
ウチに、そんな社員はいないよ

などというクレームにつながれば、場合によっては「個人情報漏洩事件」とすら言われる可能性がある。

以下の業務プロセス定義は、『受付担当者』が

入力途中で送信してしまった様な未完成な住所だったりしないか？
イタズラ目的のデタラメ住所になってないか？
省略表記や無用なスペースなどが混ざっていないか？

などをチェックした後に「送付状PDF」は自動生成され、『郵送担当者』はそのPDFを印刷して資料を封入流れとなっている。そこに人手は介在しない。

秀逸な点は、この業務において「リスト」が作られることもない点だ。情報漏洩リスクは極めて低くなる。そして封入作業が完了し次第、「会社名」や「電話番号」などのデータは自動的にクラウド型データベースに追加される。（一目瞭然ではあるが、「あわせて見積も欲しい」などの書き込みがあった場合に『営業担当者』に依頼する流れも想定されている）

[資料請求対応業務]

前回記事では、

> kintone API から JSON レスポンスを受け取り、ワークフロー環境共通の「顧客マスタ」を更新する

という全自動ワークフローを紹介した。今回の記事では

> kintone API に JSON データを送信して、kintone 上の「顧客マスタ」を更新する
を紹介する！

具体的には、「与信管理ワークフロー」において取引開始が承認された瞬間、 kintone 上の「顧客マスター」に取引先（顧客コードと顧客名）が追加される仕組みだ。

つまるところ、当該ワークフローの下流で

{
  "app": "3",
  "record": {
    "customerCode": {
      "value": "9999999999999#www.example.com"
    },
    "customerName": {
      "value": "XYZ Inc"
    }
  }
}

という JSON テキストが kintone API に POST される設定となっているのだ！（←説明する気、あんのか？！？）

※ JSON: JavaScript Object Notation （「キー」と「値」のペアが列挙されたデータのかたまり）

[与信管理フロー]

『顧客リスト』は、代表的な「データベース」だ。（紙管理にせよ、コンピュータ管理にせよ）

そもそも「データベース」に格納されるデータは、

(A) マスター情報　（マスター系データ）

商品マスター
顧客マスター
価格表、など

(B) ログ情報　（トランザクション系データ）

支払履歴
受注記録
アクセスログ、など

に大別されるが、日常業務において「(A)マスター系データ」に属するデータを参照したくなる機会は多い。

以下の業務プロセスは、クラウド型データベース『kintone』で管理されている顧客マスター情報を、ワークフロー環境の『顧客マスター』として日次同期させる仕組みだ。（バッチ処理と言っても良い）。全工程が自動化されているだけでなく、任意の時刻に手動で同期させることも可能な点が秀逸といえる。

つまるところ、「見積提出プロセス」「受注報告プロセス」「請求プロセス」など、様々な業務において、最新の『顧客マスター』を参照できるようになる。いわゆる「ユラギ」や「ナヨセ」と決別できるかも知れない。（更には kintone データの自動バックアップという意味もある）

[顧客マスタ同期プロセス]

「12か月後の今日、保守契約更新のリマインド通知を行う」

たとえば「契約プロセス」を設計していると『12か月後に通知』というアラート・メール（リマインド・メール）が欲しくなる。つまるところ、メール送信イベントを業務フローの最下流に配置したくなる。「プロセスモデリング」の専門用語（BPMN用語）で言えば［メッセージ送信中間イベント（メール）］と呼ばれるアレだ。

しかし、その設定をすると、「全工程の完了」までに１年間を要する業務プロセスとになってしまう。
（契約締結までの作業工程はすべて完了しているのに。。。）

やや個人の趣向に依存する話になるが、、、この「リマインド・メール」が送信されていないがために、案件ステータスが「Running」のママとなってしまうのは、何とも気持ち悪い。もし「全工程が完了するまでの時間」を KPI として計測しているような組織であれば、非常に「邪魔な存在」と言えるだろう。

以下のワークフローは、この「リマインド・メール」の部分だけを独立させた業務プロセスだ。（業務プロセスと言うには、あまりにもシンプルすぎるが）　要するに、様々な業務プロセスから「メッセージ」を預かり、「リマインド日時」にメール送信するだけの仕組みとなっている。

[リマインド通知プロセス]