本シリーズについて：全体構成はこちら
本件では、既存のアプリとして取引先管理アプリがあったため、そちらを改修して新規システムに活用しています。
課題
これまでのシステムでは、取引先ごとの費用条件（費用タイプ・掛率・商品コードなど）を「取引先管理アプリ」で管理していました。これらの情報は社内で複数回の承認を経て確定しますが、従来の仕組みは承認完了までの管理にとどまっていました。
今回、承認後の費用条件を取引先への共有や会計システムとの連携にも活用していくにあたり、大きく3つの課題がありました。
1. 取引先・費用条件を識別するための情報が不足している
既存の取引先管理アプリには、承認後のデータ活用を想定した情報が十分に整備されていませんでした。
具体的には、以下の情報が不足していました。
- 取引先を一意に識別するためのキー
- 1社に紐づく複数の費用条件を個別に識別・管理するための情報
- 会計システムとの連携に必要な情報
2. 既存アプリを活かしながら取引先へ情報を公開する必要がある
確定した費用条件は取引先にも公開・共有する必要がありましたが、既存の「取引先管理アプリ」の構成では、そのまま公開することはできませんでした。
1社に対して複数の費用条件を保持する必要がある一方で、既存アプリの仕組みはできるだけ活かす要件から、両者を両立できる公開方法を検討する必要がありました。
3. 承認状況と取引先への公開情報を連動させる必要がある
取引先への情報反映のタイミングも課題でした。
承認プロセスと公開情報の更新タイミングにずれが生じると、社内で確定した内容と取引先が閲覧する内容に差異が生じてしまいます。
そのため、承認ステータスと連動し、承認が完了した費用条件を自動的に取引先向けの情報へ反映する仕組みが必要でした。
実行内容・取り組んだこと
業務と情報の整理をして、取引先管理アプリに以下を実施しています。
- 足りない項目の追加
- 複数条件に対応するようにフィールドの整備
- 承認フローの再定義・整備
費用条件については、既存アプリを活用する観点からテーブルフィールドで管理することにしました。ただし、kViewerの仕様上、テーブル内の値を個別のレコードとして参照することができないため、kintone側にkViewer反映用の別アプリを用意し、費用条件をレコード単位に展開して反映する仕組みを設けました。
（図：kViewer制約・実施イメージ）
また、上記に合わせて、エンドユーザー様にご協力をいただき、アプリ内レコードの情報の整備も実施しています。
処理面としては、承認フローの完了をトリガーに、JavaScriptカスタマイズで契約情報アプリを自動更新する仕組みを構築しました。
処理の流れは以下の通りです。
- 取引先管理アプリ上でプロセス管理の承認（または否決）が完了する
- JavaScriptが起動し、同じ取引先管理コードに紐づく契約情報アプリの既存レコードを取得する
- 既存レコードに「論理削除」フラグを立てて無効化する
- 承認の場合のみ、取引先管理アプリの最新の契約明細をもとに新しいレコードを契約情報アプリへ登録する
- 処理が完了すると画面上に完了ダイアログが表示される
否決の場合はステップ3（既存データの無効化）のみ実行し、新規登録は行いません。
（図：実装後の自動更新フロー）
実施ポイント
① 公開用アプリへの転記処理の実装
既存のアプリを利用する点・条件別ではなく取引先別に管理する必要がある点から、費用条件はテーブルで持つ形としました。そのため、kViewerで参照するために別アプリとして費用条件を管理できるようにしています。アクティブな条件を反映するタイミングを取引先管理アプリの承認フローと合わせることで、差異なく取引先に公開できるようにしています。
② 論理削除で履歴を残しながら最新データを整合させる
契約情報アプリのレコードを上書き更新するのではなく、古いレコードに「論理削除」フラグを立てて無効化し、新しいレコードを別途登録するアプローチを採用しました。
これにより、過去の費用条件がレコードとして残るため、「いつ・どの条件に変更されたか」の履歴をkintone上で追跡できます。kViewerは論理削除フラグが立っていないレコードのみを参照する設定にしているため、取引先から見えるデータは常に最新の情報のみになります。
論理削除としての更新処理と新規レコードの登録処理は、両方が完了して初めて画面上に完了ダイアログを表示する設計にしており、どちらかが失敗した場合はエラーとして検知できます。
まとめ・効果
この実装により、取引先管理アプリでの承認完了後、担当者が別アプリを操作することなく、自動的に契約情報アプリへ最新の費用条件が反映されるようになりました。
承認フローと公開情報の更新タイミングを一致させることで、取引先が参照するkViewer上の情報と社内の実運用データの間に差異が生じない運用を実現しています。また、論理削除による設計を採用しているため、過去の条件変更の履歴もkintone上で確認でき、管理性の向上にもつながっています。
「プロセス管理の完了をトリガーにする」という設計は、承認後に別アプリを自動更新する業務フロー全般に応用できるパターンです。また、テーブルフィールドの値をkViewerなどの外部ツールに公開する事例にもなっています。
