FISを利用してSAP Concur Expense/Invoiceとデータ連携するポイントを紹介
こんにちは。ソリューション開発部の栗田です。
ソリューション開発部では、FIS(Financial Integration Service)を利用してConcur Expense/Concur Invoice(以降Concurで表記)から承認されたデータを5分ごとにデータ取得し、基幹システムへ連携するシステムを構築しました。
日本の企業でFISを利用しているところはまだ少なく、多くの企業が1日1回のファイル連携を使用しています。
手探りからのスタートでしたが、無事システムを構築し、現時点でC/Oから1年半程システムを運用しています。
本記事では、FISを利用したデータ連携の流れと運用する中で見えてきたポイントをAPIごとに紹介します。
FISを利用したデータ連携の流れ
FISを利用する際は、下記の5つのAPIを(図1)のようなフローで利用します。
- Access Token取得(FISの②～⑤のAPIを利用する際に必要)・・・①
- Get Financial Transactions(支払申請ドキュメントの取得)・・・②
- Post Financial Transaction Acknowledgement(対象の支払申請ドキュメントをロック)・・・③
- Post Financial Transaction Confirmations(連携完了にステータスを変更する)・・・④
- Post Financial Payment Confirmations(支払完了にステータス変更する(任意))・・・⑤
(図1)
①Access Token取得(FISの下記APIを利用する際に必要)
FISの②～⑤のAPIを利用する際にはAccess Tokenを利用します。Access Tokenは1時間で無効となるため、期限が切れる前に新しいAccess TokenをRefresh Tokenを利用して取得する必要があります。
DBなどにAccess Tokenを保持しておき、45分ごとにRefresh Tokenを利用してAccess Tokenを発行し直してDBに保持するなどをして、API呼び出しの頻度を下げられます。
②Get Financial Transactions(支払申請ドキュメントの取得)
Get Financial Transactionsでは、1回のAPI呼び出しで依頼書が100件しか取得ができないという制約があります。仮に5分単位でAPIを呼び出す場合は、1時間に1,200件の依頼書しか取り込みできません。
もしそれだと厳しい場合は連携頻度を上げるか、page情報が取得できるため、page情報を見ながら再取得をしにいくかを判断するなどの仕組みをいれると良いと思います。
運用観点では特定の依頼書のみ個別で取り込みをしたいケースがあるため、docIdと呼ばれる依頼書を特定できるIdをパラメータに指定して、取得する仕組みを用意しておくと良いと思います。
③Post Financial Transaction Acknowledgement(対象の支払申請ドキュメントをロック)
Post Financial Transaction Acknowledgementでは、Concur側で依頼書を変更されてしまうと、基幹システムへ連携する情報と差異が出る可能性があるため、Concur側で変更ができないようにするためのロックをリクエストします。
②のGet Financial Transactionsを実施したら、即時ロックを取得する仕組みにしておくことが重要です。
④Post Financial Transaction Confirmations(連携完了にステータスを変更する)
Post Financial Transaction Confirmationsでは、(図1)のフローの中では基幹システムへ連携した結果を返していますが、実際にはConcurの監査ルールなどでチェックしきれないチェック処理を連携システムでチェックすることが多いと思います(基幹システムへ送ったら問題あるデータがないかチェックするため)。
ロックを取得後、チェック処理を連携システムで実施し、問題がある依頼書はエラーでConcurに返却することで、承認者が承認後に依頼書に問題があるかをすぐ知れます。
基幹システムの取り込みは即時でないケースが多いと思いますので、基幹システムの取り込み結果返却と、連携システムのチェック結果をConcurに返却する部分をうまく設計する必要があります。
⑤Post Financial Payment Confirmations(支払完了にステータス変更する(任意))
Post Financial Payment Confirmationsは任意となっており、弊社が構築した際は利用しませんでしたが、基幹システムなどが支払処理を終えた後に利用するAPIです。
その他ポイント
ConcurはSaaSであるため、どうしても負荷が高いタイミングがあったり、何かしら障害が発生したり、API呼び出しがうまくいかないケースがあります。APIの呼び出しがタイムアウトすることを前提に処理を設計すると良いと思います(例えば数回はリトライするなど)。
また運用していく中で、どうしても連携システム側だけでは解決できず、Concur側の調査をお願いするケースが出てくると思います。
問い合わせをするにあたり、いつ時点のAPI呼び出しかを特定する情報を提供すると調査がスムーズに進むことがあります。APIのレスポンスヘッダーにConcur-Correlationidという情報が入っているため、この情報をログに残したりDBに保持すると良いと思います。
最後に
ConcurとFISのデータ連携のポイントを紹介しました。
他にも従業員情報・ワークフロー情報・リスト情報の連携についても、Concurと基幹システムの連携を実現したためノウハウがあります。またConcurにWalkMeを用いたUX改善の実績もあります。
詳しいご相談はぜひ弊社までお問い合わせください。
