システムの目的
購買申請〜承認〜発注管理〜検収（会計処理）〜支払い（FBデータ作成）〜消し込み（会計処理）〜債務残高管理までの業務フローを完全自動化するシステムを構築します。
これを、プロトタイプ稼働まで4時間で実現します。
システム化の方針
上記の業務フローはどの会社にもありますが、一つだけ作って全社で利用すると、汎用的にするために入力項目が増え、生産性が落ちます。
業務毎の専用購買フローを作ることで、入力項目が減り、飛躍的に生産性があがります。
一方、会社としては、全社の購買活動を網羅的に一元把握し、支払い、会計処理する必要があります。
したがって、システム化の方針としては、購買申請〜検収までを業務毎に最適化したアプリケーションを作成し、会計処理以降はツバイソに丸投げします。そうすることで、各業務最適化し、網羅的に一元管理すること、複雑で専門性が高い領域の開発が不要となり、短時間で全体システムの構築、業務の完全自動化が可能となります。
さらに、今後新しい業務が増えた場合は、新たに専用アプリケーションを作成し、不要となれば廃棄するといった柔軟な運用が可能となります。
シナリオ
今回は、備品や消耗品の購買システムをサンプルに作ります。
以下のフローをとある会社の開発太郎さん（開発部スタッフ）が、1月15日に机（15,000円）を購入申請をした時の一連の作業とともに流れを見ていきましょう。
出来上がりのスクリーンショットともにご確認ください。
●購買申請
備品や消耗品は、各部署の現場担当者から申請します。
●承認
発注金額が10,000円以上なら、所属部署の責任者が承認します。
10,000円未満なら、直接、調達部門（総務部）の担当者へ申請書が流れます。
所属部責任者は、内容を見て承認、差し戻しを行います。
●発注
総務部の担当者は、申請書に従って発注します。発注先は、総務部で選択します。会計処理方法も選択します。
●検収
発注したものが納品されたら、検収を行います。
●会計処理
検収日にて、発注部門のコストとして、適切な部門別会計処理を行います。
●支払い
取引先マスタに設定されている支払いサイトで、他の支払いと合わせて総合振込み用のFBデータを作成します。
●消し込み
全入出金データをCSVで取り込み、購買関係のみ抽出し、自動消し込みを行います。同時に、適切な部門別会計処理を行います。
●残高管理
全支払い先について、支払先別残高一覧表（月初残高、増加、減少、月末残高）で網羅性、正確性を検証します。
開発太郎作業
開発太郎さんは机の購入申請を消耗品購入申請アプリから行います。
まずは、右上のプラスボタンを押して新しい申請書を作成します。
この画面では何も記入せずに保存を押します。
＊画面上で灰色になっている入力欄は入力できません。
画面右上の
を押して、購入したい物の詳細を入力します。
入力が終わったら「保存」ボタンを押します。
入力した内容が問題なければ申請するボタンを押します。
出てきた、次のステータスが部門長確認中、作業者が自分の部門の部門長の名前であることを確認して正しければ実行を押します。
以下のようにステータスが部門長確認中、現在の作業者が自分の部門の部門長の名前となっていれば成功です。
これで開発太郎さんの作業は終わりました。
この時点で開発部長の開発マネオさんに承認依頼の通知が送られています。
次は開発マネオさんの作業に移りましょう。
開発マネオ作業
さて次の1月16日、開発マネオさんがポータルページを見ると
未処理の項目があるとお知らせが来ていました。
アプリを開いてみると
このように購入承認依頼が来ています。（kintoneアプリをインストールしているとスマートフォンから通知を確認できます）
各項目の詳細を見るために一番左の
のアイコンをクリックします。
この内容で承認できるのであれば、また右の方のボタンを押して編集画面に移動します。
編集画面では承認日が入力できるので以下のようなカレンダー型の選択画面から承認した日の日付を選択します。
正しい日付が入力されたら保存ボタンを押します。
入力内容が正しいことを確認したら承認するを押し、
次のステータスが購買部確認中、作業者が購買部の担当者（ここでは総務太郎）であることを確認し実行を押します。
もし申請内容に不備があったり、承認できないときは差し戻すを押して
ステータスが差し戻し、作業者が申請してきた人（ここでは開発太郎）であることを確認し実行を押します。
これで開発マネオさんの作業は終わりました。
次は総務太郎さんの作業になります。
総務太郎作業
さて、総務太郎さんがお昼ごはんを食べていると、スマートフォンにkintoneから通知が来ていたので、昼休み明けに早速消耗品購入申請アプリを開きました。
すると総務太郎さんから発注依頼が来ていたので、詳細を確認することにしました。
入力されている内容に沿って机を発注しました。アプリにも発注情報を入力します。ボタンを押して編集画面を開きます。
発注日や発注先を選択し、会計処理選択で勘定科目は何にするか決めます。
入力欄の横にある「取得」と書いてあるボタンを押すと
選択できる項目が出てくるので、当てはまるものを選択します。今回は消耗品費で登録します。
選択をして入力がすべて正しかったら、保存ボタンを押します。
もう一度確認をして問題が無ければ、「発注する」ボタンを押し、
次のステータスが発注済み、作業者が自分自身（ここでは総務太郎）であるのを確認し良ければ実行を押します。
これで発注作業まで終わりました。
次は発注した備品が届いた後の作業です。
備品が到着しました
3日後の1月19日、さっそく机が到着しました。
到着したことをアプリに登録します。
kintoneアプリの机を発注した時の項目詳細の編集画面を開きます。
検収日を入力し保存ボタンを押します。
内容を確認し問題が無ければ検収するボタンを押して、
次のステータスが検収済みとなっているのを確認して実行ボタンを押します。
検収まで完了するとツバイソ上の購買管理に情報が登録されます。
これで、kintone上での作業は終了です。
1月末
次は経理部に舞台が移ります。
月末になって経理部の経理マネ子は1月の購入品がきちんと計上しているか確認をしています。購買管理の仕入・経費明細のページの確認です。
↓ ↓ ↓
kintoneからの入力がされています。ここでの仕訳は以下のようになっています。
仕訳は、kintoneからPOSTされた取引先コードと原因コードを元にツバイソが自動的に適切な会計処理を行います。開発者の負担を減らし開発の生産性を上げることができます。
チェックして問題が無かったので月末の締め作業は無事に終わりました。
アスクルの支払日は締日の翌々月10月なので次は3月の頭に作業をします。
支払い登録
3月2日になりました。
今日は3月10日支払の取引先への振込手続きをする日です。
経理マネ子は手続きのためのFBデータ作成を行います。経理マネ子はツバイソERPを開いて3月支払の支払予定表の3月支払のページを開きました。このページではその月に支払予定の一覧が、支払締日や、手続き銀行別に表示されます。
ゆうちょ銀行から支払いをする取引先はアスクルだけのようです。
内容を確認して正しかったので、赤い下線が引いてあるボタンを押してFBデータを作成しました。そのデータを使って銀行で振込の手続きをして今日の業務を終えました。
消込作業
3月12日の週末になりました。経理マネ子は一週間分の銀行明細をツバイソに登録します。
各銀行から取得したCSVデータをもとに銀行明細をインポートします。3月2日に行った振込の手続は上手くいっているようです。3月10日の明細にがあります。
ここでの仕訳はこのようになっています。
銀行明細のインポートが終わったので、次は消込作業を行います。
購買管理の消込ページで一括消込を行います。
赤丸で囲ったボタンを押してください。このボタンではキーワードでデータを結びつけ自動で消込を行ってくれます。
消込がうまくいくと下図のアスクルの行のように、消込が行われたデータが入力され、
消込の仕訳はこのようになります。
残高照会
最後にちゃんと消込ができているかと、取引先の残高があっているか確認をします。
まず購買の残高一覧で確認します。
アスクルの計上はうまくいっています。
次に取引先元帳を開き数字を確認します。
きちんと計上できています。
これで、今回の消耗品購入に関する業務フローは終わりです。
kintoneアプリの作成
消耗品購入申請アプリをサンプルとして利用してみたい方はこのページ末の「消耗品購入申請アプリサンプルセット.zip」をダウンロードしてkintoneのご自身の環境にインストールしてください。
kintone上で行うことのポイントは、プロセス管理とレコードとフィールドのアクセス権の管理です。
今回のアプリでは 申請者が入力編集削除できる項目と、承認者、総務部が入力編集できる項目をプロセスを考慮して、レコードとフィールドを制御しています。 また、cybozu.com共通管理の組織/ユーザー設定も利用しています。それぞれをご利用の環境に合わせて設定してください。
また、この後に説明しますがAPIトークンなどを書き足さないときちんと動作しないのでJavascriptのファイルの編集を行ってください。
管理の設定方法の詳細はkintoneユーザーヘルプを参考に行ってください。
ツバイソ連携用javascript
ツバイソERPと連携やkintoneのデフォルトの機能でカバーできない作業をJavascriptで行います。
このファイルも添付のzipファイルをインストールすると消耗品購入申請サンプルアプリにプリセットされていますので、このあとの説明を元に必要な情報を追加し、アレンジをしてください。
・ツバイソ
最初の行の
var ACCESS_TOKEN = "**********";
のダブルクォーテーションで囲まれた「**********」にはツバイソから取得できるアクセストークンを記入してください。これが正しくないと、検収ボタンを押したときツバイソERPに正しくデータを反映させることができません。
次のコードはkintoneで入力したデータをツバイソAPIに対応させるコードです。
// ---------------------------------------------------
// ツバイソ形式のJsonに変換
// kitone形式のレコードをツバイソAPI形式に変換する
// ---------------------------------------------------
function convertToApJson(kintoneRecord)
{
var apJson = {};
apJson['price_including_tax'] = kintoneRecord['amount_total_included_tax'['value'];
apJson['accrual_timestamp'] = kintoneRecord['acceptance_date']['value'];
// 下記取引先も、原因マスタのように別のkintoneアプリで管理すればルックアップで取得できます
switch (kintoneRecord['order_destination']['value']) {
case '大塚商会' : apJson['customer_master_code'] = 'c-miha0019'; break;
case 'アスクル' : apJson['customer_master_code'] = 'c-miha0017'; break;
default : apJson['customer_master_code'] = 'c-miha0019'; break;
}
apJson['reason_master_code'] = kintoneRecord['reason_code']['value'];
apJson['dc'] = 'c';
apJson['memo'] = kintoneRecord['item']['value'] + '/'
+ kintoneRecord['unit_price']['value'] + '/'
+ kintoneRecord['quantity']['value'] + '/'
+ kintoneRecord['purpose']['value'] + '/'
+ kintoneRecord['remarks']['value'] + '/'
// TODO+ プロセス管理の変更履歴 + '/'
+ '[This record was posted by kintone]';
apJson['tax_code'] = 1003;
apJson['port_type'] = 1;
apJson['dept_code'] = 'COMMON';
apJson['need_tax_deduction'] = 0;
return apJson;
}
// ---------------------------------------------------
注意してほしいのは、「// 下記取引先も、原因マスタのように別のkintoneアプリで管理すればルックアップで取得できます」の下に書いてある部分です。 ツバイソERPにデータを送る時、取引先については取引先の名前ではなく”取引先コード”というツバイソERP内で使われているコードに直さなくてはなりません。ツバイソERPに送られた情報を登録するときはこの”取引先コード”でどこの取引先かを判断するので、ここが間違っていると誤った取引先で登録されてしまいます。 ここはルックアップで項目を選択できるようにすることも可能です。ツバイソの取引先マスタとkintoneを連携するアプリを利用することもできますが、取引先が2、3で固定なら、このようにハードコーディングすることも業務の生産性を上げるコツです。
それ以外のコードについては、下記を参照しながら確認してみてください。
・GitHubのTsubaiso API
・cybozu.com developper network のkintone API
最後に
いかがでしょうか。慣れれば4時間程度でプロトタイプ稼働まで可能な感覚をつかめたでしょうか。
従来、このようなシステム構築にはとても時間がかかり、自動化のメリットと投資コストの検討が必要でした。しかし、今回の生産性で業務システム開発ができるれば、自動化しない理由はありません。
このような手法を利用する他社に遅れないためにも、是非ご活用ください。