ワークフローサンプル: 請求書作成

ラベル 請求書作成 の投稿を表示しています。すべての投稿を表示

ラベル 請求書作成 の投稿を表示しています。すべての投稿を表示

前回「第595話：アンケート回答期限、もうひとつの設定方法」では、「タイマー時刻をデータ設定式でセットする方法」について紹介しました。

記事の中で、工程を減らしてワークフロー図の視認性を高める方法として、

「サービスタスク（データ設定）」については、ひとつの工程で、複数のデータ項目に値をセットできるようになっています。「サービスタスク（データ設定）」が連続して配置されている場合、ひとつに統合することを検討ください。

といった内容を案内しました。

「ん？具体的にはどうやってやれば良いの？？」という声が聞こえてきそうなので、実際に過去のワークフロー図を書き換えてみましょう！

[請求＆入金確認フロー１]

[請求＆入金確認フロー１（工程統合）]

続きを読む »

工程の無人化による生産性向上

前々回記事と前回記事では、ワークフローシステムから「PayPal 請求システム」をコントロールする仕組みを紹介しました。

これらの仕組み（ワークフローアプリ）には、フロー図の途中に自動工程（Addonサービス工程）が配置されています。つまり、請求案件がこれらの工程に流れ着く度に、

『PayPal請求書』を生成せよ（PayPal Create）
『PayPal請求書』を送信せよ（PayPal Send）
『PayPal請求書』の決済ステータスは何か？（PayPal Check）

といった「リクエスト」がワークフローシステムから自動的に発信されます。言い換えれば「電子請求書の生成」「電子請求書の送信」「電子請求書のステータス確認」といった経理業務が「無人化」されています。（PayPal Invoicing API との REST/OAuth2 通信）

今日では、この例のような「決済システム」(*1)に限らず、様々な情報システムの操作が自動化され、生産性向上が図られています。たとえば「Storageシステム」(*2)への見積書保存や、「表計算システム・データ管理システム」(*3)での商品マスタ管理などが代表的な例と言えるでしょう。

*1: PayPal, Stripe, etc. *2: Dropbox, Box, Google Drive, etc. *3 Google SpreadSheet, Kintone, etc.

＜設定画面：Paypal Create＞

＜設定画面：Paypal Send＞

＜設定画面：Paypal Check＞

＃プロセスオーナーはAddon自動工程のプロパティを設定するだけで良くなった（プログラミング知識が必要なくなった）という点も普及要因

どの様な状態変化まで無人対応させるべきか

しかし工程の無人化は「メリットばかり」ではありません。

たとえば前回記事では、電子請求書のステータスが『PAID』（支払い済み）になるまで確認し続ける（ループし続ける）という業務フローになっていました。

確かにヒトは介在しないので「確認作業」そのものには人的コストは発生しません。

しかしながら、もし「発注キャンセル」や「他の決済方法での送金」といった事象が発生しているのなら、場合によっては「出荷処理」という業務を止める必要があるかも知れません。場合によっては「売上計上」という処理にも修正が必要になってくるかも知れません。やはり「影響度×発生確率」が大きい状態変化ついては、業務プロセス定義として「想定外」のままにするのではなく、できるだけ「想定の範囲内」にしたい所です。

以下の業務プロセス定義では、比較的発生頻度の高い「CANCELLEDステータス」（キャンセル）について考慮されています。すなわち、支払いが拒否された場合などにアラートメールを発信する、という工夫が追加されています。

[Paypal請求書発行プロセス-キャンセル通知]

続きを読む »

請求を自動化する

前回記事では、「PayPal Create」と「PayPal Send」という2つの自動工程を配置することで、『PayPal請求書』が自動的に送信されるワークフローを構築しました。

すなわちヒューマン工程でのチェックや承認を経た「請求データ」が自動的に PayPal 側に POST され『PayPal請求書』が生成されます。そして指定時刻になると（送信指令が届けられ）メール送信されます。何と言っても、「Addonサービス工程」だけで定義できる為、（＝「スクリプト工程」が使われていない為）、プログラミング知識が無くても、自社の業務フローにあわせた「自動請求システム」を構築できるのが魅力です。

しかし「『PayPal請求書』が決済されたか確認する業務」については対象外（スコープ外）となっていました。

着金確認まで自動化する

以下の業務プロセスでは、更に「PayPal Check」という自動工程（Addonサービス工程）が追加されています。すなわちこのワークフローシステムは、送信させた『PayPal請求書』について、その決済ステータスを定期的・自動的に確認し続ける設定となっています。

具体的には、「(3.未決済滞留)」の工程にある案件が、

経理担当者が案件を進めるたび
12時間の滞留時間を経るたび

に自動工程「PayPal Check」に到達します。そして、セキュア通信（OAuth2通信／PayPal Invoicing API）を通じて決済状況が問い合わせられます。もし、ステータスが「決済された（PAID）」になっていれば、「(3.未決済滞留)」の工程に戻らず「決済された時刻」と「決済された金額」を格納して、全工程終了となる仕組みです。

[Paypal請求書発行プロセス-決済チェック]

続きを読む »

決済に直結する請求書

『ペイパル請求書』は「メールタイプ」の電子請求書です。

メールを受信した人の視点で見れば、『請求書の表示および支払い』のボタンをクリックし、スグに決済処理（カード決済・PayPalアカウント決済）をすませることができるので非常にラクです。もちろん「経理担当者への社内転送」が必要な場合も、メーラでの転送操作だけでよいので、とても簡単です。

請求書を発行する側の視点で見ても、たとえば従来型の「紙請求の業務プロセス」が、

請求書のExcelデータの作成し
請求書を印刷し
請求書を郵送し
指定銀行口座に入金されたかを確認する

といった手順を踏んでいたのに比べて、

PayPal にログインして請求データの入力する
(決済完了通知が来る)

といった非常に簡素なものになります。しかも、クレジットカード情報は受け取らないので「漏洩リスク」もありません。

昨今では、「生産性向上」や「テレワーク環境整備」の観点からも非常に注目されています。（PayPal 請求書）

＜受信したメールの例：メーラ画像＞

ワークフローとのAPI連携

『ペイパル請求書』は、特別なシステム導入が要りません。

しかし、「Paypal にログインすれば請求書が送信できる」というこの手軽さは、同時に「上司承認が曖昧になる」や「複数人でのミスチェックがしづらい」といった新たな課題を抱えることにもなります。特に「業務プロセス」を重視する会社であれば、ガバナンス上の問題として議論される可能性があります。

以下の業務プロセス定義サンプルでは、ワークフローシステムから API 制御させることによって

「PayPal にログインせずに PayPal 請求書を活用する」

という方針を実現しています。すなわち、ワークフローシステム内で承認・チェックされたデータが API を通じて自動的に PayPal 側に連携され、「請求メールの送信指令」もワークフローシステムから API を通じて届けられます。そして「いつ誰が何をしたか」という業務記録は全てワークフローシステム側に記録されます。

※ クラウド型ワークフロー『Questetra BPM Suite』であれば、無料で実現することが可能です。（業務プロセス定義をインポートすれば数時間で構築できます）

[PayPal 請求書発行プロセス]

続きを読む »

プロセス見直しの季節

4月。

日本では「新しい１年が始まる月」です。

国の会計、地方自治体の会計、学校の新学年などが、4月に始まるだけでなく、新社会人の入社式も4月に一斉に行われます。（約2割の日本企業は4月に会計年度を始めます）

日本において4月は、「業務プロセスの改善モチベーションが上がる月」あるいは「業務プロセス改善にはモッテコイの月」と言えるでしょう。

そして当ブログを運営している Questetra 社においても、4月は業務プロセスの更新量（ワークフロー・アプリのバージョンアップ回数）が増えます。

あえて所要時間を伸ばす？

今回紹介する業務プロセスは、「全工程の所要時間を伸ばす」という少し変わった改善例です。

普段の業務改善は、日頃の業務中に感じた「不満」や「課題」に対して『フローの改善』や『データ入力画面の改善』を考えるのが常です。

工程の自動化
ダブルチェック工程の追加
ガイド文の追加
便利ボタンの設置

そして、その多くの場合、「トータル所要時間を少しでも早める方向性」を模索します。

しかし、年度の区切りである4月においては、「全体集計作業を通じて感じた非効率」について対処したくなる場合もあります。この業務プロセス（ワークフロー・アプリ）では、あえて途中滞留させる変更が行われています。（ヒューマン工程「x.差戻滞留」の追加）

※ 改善前の業務プロセス：第511話：振替伝票ファイルを自動生成させる（Excel-CSV）

[請求書発行プロセス-滞留]

続きを読む »

経理工程の独立

「独立したサブルーチン・プロセス」として『PayPal 請求フロー』を準備しておくと、とても便利です。

ワークフローシステム内の様々なビジネスフローから呼び出すことができるので、プロセスオーナーは、メインのビジネスフローの設計やメンテナンスに注力することができます。

下流側の経理部門の視点で言っても、複数のビジネスフローを区別なく処理できるため、効率よい業務をこなせるようになるでしょう。（ただし上流への関与は減る傾向になります）。また、ここ１・２年の変化が極めて激しい経理システム（※）にあって、「一元的に管理メンテナンスしたい」というニーズもあります。

※「クラウド会計」「銀行API」「会計BPO」など

PayPal請求書の処理

以下の業務プロセス定義（ワークフロー・アプリ）は、PayPal と自動連携する『PayPal 請求プロセス』です。

「PayPal REST API」、具体的には「PayPal Invoicing API」を通じて、ワークフローシステム側から様々なリクエストが行われます。つまり、

PayPal 側に『PayPal請求書』を生成させ、
PayPal から『PayPal請求書』を送信させ、
PayPal に対して『PayPal請求書』の決済状況を確認する

という仕組みになっています。（直接 PayPal にログインする機会は減ることになります）

[PayPal請求プロセス]

続きを読む »

請求の自動化

ワークフローシステム『Questetra』から、請求システムとしての『PayPal』をコントロールできれば、とても便利です。

たとえば『商品納入フロー』が完了した直後に「納入内容に合わせた PayPal 請求書」が自動発行されるような仕組みを作れば、「請求ミス」や「請求モレ」の発生を防ぐことができます。もし、現状が「紙の請求書」を郵送する請求業務なのであれば、切手代・印刷費・事務人件費を全てゼロにすることも可能です。

前回までの記事では、「PayPal 内に請求書を生成させる」や「PayPal 内に生成させた請求書を更にお客様にメール送信させる」といった指示が、PayPal に対して自動的に行われる仕組みを紹介しました。

更なる自動化

PayPal に「PayPal請求書」を生成させる
PayPal に「PayPal請求書」をメール送信させる

が自動化できたのなら、更に

PayPal に対して、入金があったか確認する

についても自動化したいものです。（債権回収業務の効率化）

今回の記事では、自動工程を上手に組み立てて『入金確認フロー』を無人化することを考察してみます。

※ここでは自動工程の一種である「スクリプト工程」を使うため、プログラミング知識が必要となります

[エントリ受付システム-ペイパル請求～入金確認]

続きを読む »

請求システムとしての PayPal

「PayPal 請求書」は、とても便利です。

PayPal にログインして「相手のメールアドレス」と「販売した商品明細」をセットするだけで、誰でも簡単に請求書を送ることができます。「ちょっとした受託作業」や「特別な値引き」にも柔軟に対応できる数少ない決済手段と言えるでしょう。その簡単さは「むしろECサイトで買い物をする手続きの方が難しい」と思えてしまうくらいです。しかも、買い手から売り手に「クレジットカード番号」を渡す必要もありません。

しかし、何十枚も発行しなければならない、となれば流石に面倒です。（その「柔軟さ」がアダとなってしまいます）

全く同じ請求内容であれば一括して処理する機能もあるのですが、それぞれに微妙に内容が異なるのであれば一つ一つ請求情報をセットせざるをえません。ただ、手作業の繰り返しは、どうしてもミスを招きます。

請求書生成と送信の自動化

以前の記事(※)で『PayPal システムに対して「PayPal 請求書を生成せよ」というリクエストが自動送信される仕組み』を紹介しました。

※ 第525話：自動工程から OAuth2 リクエストを送出させる方法

今回の記事では、更に『「生成した PayPal 請求書を先方に送信せよ」というリクエストが自動送信される仕組み』について考えてみたいと思います。（プログラミング知識が必要となります）

[エントリ受付システム]

続きを読む »

和暦テキスト

日本では「西暦」ではなく「和暦」を使うケースが多くあります。

現在は『2017年』であるとともに『平成29年』でもあります。

すなわち「2017-03-13」といった日付型データも、印刷物やメール本文などにおいては、「平成29年3月13日」と表示されるべきケースが多くあります。およそ１年前の記事（※）では、自動工程である［スクリプト工程］を活用した和暦変換をご紹介しました。（クラウド型ワークフロー『Questetra BPM Suite』に流れる案件データの自動変換）

第467話：自動生成 PDF の「証明書発行日」を和暦表示する！ (2016-01-25)

スクリプト工程とサービス工程

ただ、クラウド型ワークフロー『Questetra BPM Suite』のバージョン11.1以降（2016-09-05）は、「サービス定義ファイル」（アドオンXML）によって任意の［サービス工程］を追加することが可能となっています。（サービス工程の Addon）

すなわち、和暦変換を行う［サービス工程］を利用すれば、（プログラミング知識を必要とする）、［スクリプト工程］を使う必要がありません。

[証明書発行フロー-和暦変換アドオン]

続きを読む »

サーバサイド JavaScript による自動化

前回記事（※）で『Questetra BPM Suite の「自動工程」では（簡単な数値演算だけでなく）「OAuth2 通信」も実装可能』と書きました。

※第524話：サーバサイド JavaScript による業務の自動化

そこで今回の記事では「具体的にどの様な外部サービスと OAuth2 通信が可能なのか」と「具体的にどの様なプログラミングが必要なのか」について、簡単にまとめてみたいと思います。（ワークフローシステム側からリクエストする視点）

そもそも OAuth2 通信とは

OAuth （おーおーす）とは「サーバへのリクエストを認可する仕組み」です。

参考）『みんな知るべきクラウド技術「OAuth」ってナニ？』 (2014-01-27)

OAuth2 が2012年に登場して以来、Google Drive や Dropbox など多くの「リソース・サーバ」の API が『OAuth2 アクセス』に対応するようになっています。つまり、外部のシステムは「リソース・サーバ」に対して、様々な「参照リクエスト」や「更新リクエスト」を投げることが可能となっています。 (RFC6749/6750)

クラウド型ワークフローである『Questetra BPM Suite』では、業務プロセス定義の中に配置した自動工程に、この「外部のシステム」（OAuth2 クライアント）として振る舞わせることが可能です。すなわち、案件が自動工程（スクリプト工程／サービス工程）に到達する度に以下の様なリクエストが自動的に実行されるよう、設定することができます。

a. Google Sheets API v4 (Sheet の読み書き)

Spreadsheets 全体の一括更新メソッドで、シート末尾に複数データを追加する

b. PayPal Invoicing API REST API 版 (請求書の生成送信)

下書き作成メソッドで、新しい請求書を生成する

c. Dropbox API v1

ファイル更新メソッドで、ファイルをアップロードする

※ スクリプト工程：業務設計者がサーバサイド JavaScript をセットできる工程（HttpClientWrapper を使った通信も実装可能） M230
※ サービス工程（Addon）：スクリプト工程をパッケージ化した工程。業務設計者はコンフィグ設定のみ可能 M415 M416

参考）

アクセストークンの取得方法

このリクエスト通信には「アクセス・トークン」が必要になります。

「アクセス・トークン」とは、「リソースの所有者によって認可されたリクエストであることの証（あかし）」であり、その実態は数十文字から200文字程度の文字列です。ただ、アクセス・トークンの取得方式は「リソース・サーバ」によって異なります。主だった方法としては、

A. 所有者に「許可ボタン」をクリックさせ、その後は自動取得する（Authorization Code Grant）
B. 秘密クレデンシャルをセットしておき、その後は自動取得する（Client Credentials Grant）
C. アクセストークンそのものをセットしてしまう（有効期限が無い Access Token が可能な場合など）

といった方式があるのですが、「リソース・サーバ」の管理するデータの種類や性格によって多岐に及びます。

注意）接続先 API が実装可能な OAuth2 認可方式であっても、「HTTP ヘッダ」や「Content-Type フォーマット」に関する実装制約（Questetra側）により、自動通信を設定できない場合があります。

[請求書送信プロセス]

続きを読む »

「請求データの入力、面倒。。。」

銀行入出金やカード支払などのログが「自動仕訳」されるようになり、ひと昔前と比べて「経理の入力作業」は随分とラクになった。

しかし、特に『売上高』に関して言えば、『入金』のタイミングを待っていたのでは遅すぎる。やはり『請求書』を発行した時点で『売掛金売上』にしたい。。。というか、しなければならない。

2016-11-22: 売掛金 120,000 / 売上高 120,000 = ホームページ制作（A社向け）
2016-12-31: 普通預金 120,000 / 売掛金 120,000 = ホームページ制作（A社向け）

ちなみにその逆に、『請求書』を発行した時点では、（『入金』があった時点でも）、『売上高』にできないケースだってある。

2016-12-31: 普通預金 120,000 / 前受金 120,000 = 保守2017-01~2017-12（A社向け）
2017-01-01: 前受金 10,000 / 売上高 10,000 = 保守2017-01~2017-12（A社向け）2017-01分
2017-02-01: 前受金 10,000 / 売上高 10,000 = 保守2017-01~2017-12（A社向け）2017-02分
2017-03-01: 前受金 10,000 / 売上高 10,000 = 保守2017-01~2017-12（A社向け）2017-03分
2017-04-01: 前受金 10,000 / 売上高 10,000 = 保守2017-01~2017-12（A社向け）2017-04分
2017-05-01: 前受金 10,000 / 売上高 10,000 = 保守2017-01~2017-12（A社向け）2017-05分
2017-06-01: 前受金 10,000 / 売上高 10,000 = 保守2017-01~2017-12（A社向け）2017-06分
2017-07-01: 前受金 10,000 / 売上高 10,000 = 保守2017-01~2017-12（A社向け）2017-07分
2017-08-01: 前受金 10,000 / 売上高 10,000 = 保守2017-01~2017-12（A社向け）2017-08分
2017-09-01: 前受金 10,000 / 売上高 10,000 = 保守2017-01~2017-12（A社向け）2017-09分
2017-10-01: 前受金 10,000 / 売上高 10,000 = 保守2017-01~2017-12（A社向け）2017-10分
2017-11-01: 前受金 10,000 / 売上高 10,000 = 保守2017-01~2017-12（A社向け）2017-11分
2017-12-01: 前受金 10,000 / 売上高 10,000 = 保守2017-01~2017-12（A社向け）2017-12分

いわゆる「振替伝票」（振替レコード）の作成方法や作成タイミングについては、業種業態だけでなく会社方針によっても様々だ。とは言え、その作成作業そのものは、ぜひとも「自動化」したい。

以下のワークフローでは、『請求書』が上司承認された瞬間、

顧客に請求書PDFがメール送付され、
複数行の「振替レコード」が自動計算され
インポート用ファイルが自動生成される。

経理担当は自動生成された Excel-CSV ファイルを、会計システムにアップロードするだけで「入力作業」を終えることができる。

[請求書発行プロセス]

続きを読む »

「顧客マスターは kintone で管理したい！」

『kintone』は日本で人気の「クラウド型データベース」だ。同じく簡易なクラウド型データベースである『Google SpreadSheet』と比べると、機能面では限定される部分が多いものの、その分、クラウド初心者には使いやすい。

そして「顧客管理」は、最も多い kintone 利用用途の一つだ。

以下のワークフローは『kintone 上の顧客マスター』を参照して、『ワークフロー環境上の顧客マスター』を更新する同期プロセスだ。前回記事『第502話：ユラギを無くすには「マスター参照」でしょ！』と全く同じフローで、毎朝5時に自動実行される。

異なるのは『Google SpreadSheet 上のマスター』を参照するのではく、『kintone 上のマスター』を参照するようになっている点だけだ。

[取引先マスター同期-kintone]

続きを読む »

法人名の「ゆらぎ」が頻発！

見積書や請求書の宛先データが、「日本電信電話株式会社」になってたり、「日本電信電話（株）」になってたり、「NTT株式会社」になってたり・・・。やはり、見積書作成フローや請求書作成フローの入力フォームは、（TEXT フォームではなく）、セレクト方式にせざるを得ない。でなければ、集計に耐えないデータが溜まっていく一方だ。

いわゆる『顧客マスター』はスプレッドシートで管理しているのだが。。。

以下のワークフローは、『ワークフロー環境の顧客マスター』が、Google スプレッドシート内のデータによって自動更新される仕組みだ。様々な業務フローで「顧客名選択」というセレクト方式の入力フォームを設置することができるようになる。しかも、その入力フォームは、常に最新の『顧客マスター』が維持されるのだ。

※ ここで使われている［Sheet参照］という自動工程（サービスタスク）は、あらかじめ［アドオンXML］によって機能拡張しておく事で利用可能となる。（v11.1: 2016-09-05）

[取引先マスター同期]

続きを読む »

「顧客リスト」を表計算ソフトで管理している会社は多い。

ただ、、、10年前は当たり前のように『Excel ファイル』が作られていたのに、今では、クラウド型データベースである『Google SpreadSheet』や『kintone』が利用されるケースの方が多くなってきたと思う。つまるところ、

いつでも・どこからでもアクセスできる
データが消失するリスクを小さくできる
データを複製して持ち運ぶ必要が無い
サービスプランによっては閲覧履歴を全て残せる

といった利便性をリーズナブルな価格で（もしくは無料で）享受できるのだから、特に中小零細企業には有り難い。

＜API 通信のイメージ図＞

しかも、クラウド型データベースを使えば、外部システムにも「顧客リスト」を参照させることが可能となる。（API 機能：Application Programming Interface）

以下のワークフローは、「Google SpreadSheet 上の顧客リスト」をワークフロー環境に取り込ませる自動フローだ。この例では、毎日深夜 1:00 に「顧客リスト」が自動的に同期されるようになる。（フローそのものは、以前紹介した kintone 同期とほぼ同じだ）

[顧客マスタ同期プロセス-スプレッドシート連携]

続きを読む »

前回記事では、

> 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 データの自動バックアップという意味もある）

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

続きを読む »

情報システムの高度化が進む今日、ワークフローシステム自身に、

消費税額の「自動計算」
請求書PDFの「自動生成」

といった処理をさせる事も、珍しい話ではなくなった。

途中工程が『自動化』される事によって、ミスや手戻りを大幅に減らすことができる。そして処理全体の所要時間を短縮させることにもつながる。

しかし一方で、様々な工程を『自動化』しすぎると、いわゆる「ブラックボックス化の弊害」として、仕組みそのものが理解できなくなったり、延いてはトラブルが起きた際に対応できなくなったりしてしまう。

通信ネットワークを使った「自動取得」
通信ネットワークを使った「自動保存」
if文が沢山書かれた「スクリプト工程」
小数計算のある「スクリプト工程」

というような「エラー発生率」が無視できない自動工程を含むなら、ナオサラだ。（実は「クラウド活用時代」の大きなテーマなのかも知れない）

[請求書発行フロー-チェック]

続きを読む »

「日割り請求書」を自動化したい。

家賃、水道料金、クラウドサービス。。。どんな分野であっても「請求書発行プロセス」は、非常に重要な業務だ。ミスは許されない。与信調査や住所入力は人間が行うにしても、「日割り計算」の部分はコンピュータに任せたい。

確かに、コンピュータは機械だ。
およそ、ミスは無い。
そして、速い。

ただ一方で、、、「３分の１」を３倍させたら「0.999」にしかならない、という極めてオバカサンな一面も併せ持つ。電卓であれ、スパコンであれ、あまり大差ない。（あぁ、J言語ユーザさん等からの反論が聞こえる…）

以下のワークフローは、「月額利用料 10,000円のサービス」に対する日割計算を自動化している。

「YYYY年MM月にX日間ご利用いただいた」と言う情報を入力すれば、「請求額PDFの自動生成まで」が自動化される、というシンプルなサンプルフローだ。

この例は、業務フロー図を見れば一目瞭然だが、簡単の為に「承認工程」や「差戻工程」すら設定されていない。非常にプレーンな業務プロセスだ。ただ、であるが故に、「自動でプリントアウトする」や「自動で添付メール送信する」といった応用システムを開発する際のベースとして有用といえる。

[請求書発行フロー]

続きを読む »

日本人は、一体いくつの文字を読み書きできるの？

『ひらがな』と『カタカナ』は48種類だが、『漢字』の数はなんと約1万種にのぼる。日ごろ使われない文字も含むと3万文字とも言われる。日本人は、どんな魚でも１文字で表現できてしまうワケで、たとえば Twitter の「140文字制限」に対する感覚も大きく違う。（中国語は8万とか）

そして、日本の学校教育では多くの時間が「漢字の学習」に割かれる。

多くの日本人は、6年間の小学校生活を終える頃に、約1000の文字が読み書きできるようになる。その後の中学校3年間でも更に1000文字を習い、高校や大学でも更に複雑な文字を目にするようになり、一般的な社会人は約3000種類の漢字を難なく読めるようになると言われている。（正直、たぶん1000文字くらいしか「書けない」ですケド）

日本に生まれ育つと何とも実感がない話だが、特にヨーロッパ言語圏の方にこの手の話をすればウケる。

さて、そんな日本人だが、「コンピュータの日本語処理」には、色々と泣かされ続けてきた。

この「漢字の種類が多い」というハンデだけでなく、そもそも「単語の区切り（半角スペース）が無い」とか、「同じ字でも数通りの読み方がある」とか、「同じ読みでも違う意味の漢字が何通りも存在するケースがある」とか、「縦書きと横書きで文字の形が変わるケースもある」とか、、、様々な要因でトラブルに遭遇するのだ。

以下のワークフローは、PDFでの出力テストだ。

日本語フォントは、この1万種類を超える文字がデザインされる訳だが、ワークフローの途中工程で自動的に［台紙PDF］に業務データを挿入させる際に、「その文字フォントがない」といったトラブルを発生しうる。そのトラブルを事前に実感するためのテストフローだ。最大のポイントは［台紙PDF］ファイルに「フォントデータ」が組み込まれているか否かという点となる。

[PDF生成テストフロー]

続きを読む »

※この記事には「改善編」があります

「日付は、和暦で！」

日本において「年の表記」は複雑だ。つまり、行政や学校では「2016年」とは言わない。あくまでも今年は「平成28年」なのだ。『住民票』であれ『戸籍謄本』であれ、ハタマタ『卒業証書』であれ、、、少しでも重みある書類には「和暦」が記入される。

しかし、現実、、、「ことしは平成28年！」と即答できる日本人は少ない。。。
とは言え、この「数十年に一度、元年（１年）にリセットするという仕組み」は、もう1400年以上も続いている。時の政府の一存で止めてしまえるものでもないのだ。。。（そして、現在の天皇が亡くなった日には、また新しい『元号』が発表されるハズだ）

以下のワークフローは『在職証明書』の発行フローだ。

上流工程で在職者の「氏名」や「生年月日」が入力され、フロー途中の［自動工程］で証明書 PDF が自動生成される仕組みとなっている。特筆すべきは「生年月日」や「証明書発行日」などの日付データが自動的に和暦に変換される点だ。たとえば『卒業証明書』や『保護者だより』のなどの発行フロー等にも転用できるだろう。

[証明書発行フロー]

続きを読む »

登録: 投稿 ( Atom )