Overview
プロジェクト概要
専門商社向けに、オンプレミスの販売管理システム（基幹）にしかなかった与信情報をSalesforceへ日次同期し、受注登録の時点で与信超過・値引超過を自動判定する仕組みを構築しました。超過したときだけ営業責任者・経理へ承認を回し、依頼と結果はChatworkで通知します。通常の受注は止めずに、例外だけを確実に統制する設計です。
導入前は、営業はSalesforce上で商談・受注を進めていましたが、与信限度額や売掛残高は基幹システムにしかありませんでした。そのため受注の段階で与信超過に気づけず、出荷手配の直前に経理から差し止められるケースがありました。値引にも明文化された基準がなく、承認の依頼はメールで行われ、誰が・いつ・どの条件で承認したかを後から追えませんでした。当社は、要件定義からテスト・リリースまでを担当しました。
※ お客様名は記載していません。掲載している画面とデータは、説明用に再構成したイメージです。
- 分類
- 専門商社向けの業務システム（Salesforceによる与信確認と値引承認）
- 連携元
- オンプレミスの販売管理システム（与信情報を日次同期）
- 判定方式
- 受注保存時にFlowで自動判定、超過時のみ承認
- 承認者
- 営業責任者・経理（Chatworkで通知）
- 業種
- 専門商社
- ロール
- 要件定義 / 承認フロー設計 / Salesforce開発 / 同期バッチ開発 / テスト・リリース
- 技術
- Salesforce / Salesforce Flow / Node.js / TypeScript / PostgreSQL / Chatwork API
01 — 導入前の課題
出荷直前に止めるのでは、遅い
営業の受注画面では与信が見えず、与信超過に気づくのは受注後の経理でした。画像の例では、与信余力1,500万円の取引先に1,800万円の受注が入り、出荷手配の後になって300万円の超過が見つかり、出荷が保留になっています。値引の承認基準も担当者の裁量で、案件ごとにばらついていました。承認の依頼と回答はメールに散在し、履歴を追えませんでした。
- 与信情報が基幹システムに閉じていた
- 与信超過に気づくのは受注後の経理
- 値引の承認基準が担当者の裁量
- 承認の依頼と回答がメールに散在
02 — 受注保存時の自動判定
通常か、要承認か。受注した瞬間に分かる
営業がSalesforceで受注を保存すると、レコードトリガーフローが与信と値引を順に判定し、結果と判定理由を受注レコードに書き込みます。与信は、受注金額に前回の同期以降に確定した同じ取引先の受注を足して、与信余力と比べます。値引は、明細のうち最も大きい値引率を、商品区分ごとの値引基準と照合します。どの条件にも該当しなければ、承認なしで受注確定へ進めます。値引超過は営業責任者（さらに大きければ営業部長まで）、与信超過は経理へ回り、両方超過のときは値引承認 → 経理承認の順に直列で回します。
- 受注保存時に、与信と値引をFlowで自動判定
- 条件に該当しなければ、承認なしで受注確定
- 値引超過は営業責任者、与信超過は経理へ
- 判定理由（超過額など）を受注レコードに記録
開発中の課題と解決
判定は、通過させる方向には倒さない
- 課題
- 与信余力は毎日夜間に同期した値から計算するため、同期の後に確定した受注や、同期の失敗・遅延があると、実際より余力を多く見てしまうおそれがあります。
- 解決
- 与信判定では、受注金額に前回の同期より後に確定した同じ取引先の受注を足してから比べます。与信同期日時が2営業日以上前の取引先は「要確認」と判定し、自動で経理承認へ回します。同期が止まったときに、判定を通過させてしまう方向には倒しません。
03 — 承認とChatwork通知
必要な案件だけ、判断する人へ
承認が必要なときは、承認プロセスの各ステップでプラットフォームイベントを発行し、Node.js製の通知中継が購読してChatworkへ送ります。承認者には、受注金額と与信余力、判定の内容、申請者と、受注レコードへのリンクが届きます。承認者はリンクから受注レコードを開き、判定理由を確認して、コメント付きで承認・却下します。判断とコメントは標準の承認履歴として受注レコードに残り、後から監査できます。申請者には、結果と承認者のコメントがChatworkで届きます。
- 承認依頼と結果をChatworkで通知
- 通知から受注レコードを開いて判断
- コメント付きで承認・却下
- 判断とコメントを承認履歴として記録
開発中の課題と解決
判定と承認はSalesforceの中で行い、外部へは通知だけを中継する
- 課題
- 判定や承認のロジックを外部のシステムに持たせると、承認の記録が分散し、後から追いにくくなります。
- 解決
- 判定と承認はSalesforceの標準機能（レコードトリガーフロー・承認プロセス）で実装し、外部のChatworkへは通知だけを中継しました。通知中継の送信失敗は再送キューに積み、一定回数失敗したものはログに残して管理者へ通知します。
04 — 与信情報の日次同期
通常は速く。例外は、確実に
毎日夜間に、Node.js（TypeScript）製の同期バッチが基幹DBから与信限度額・売掛残高・受注残・与信区分を読み取り、PostgreSQLに保存した前回値と比べて、変化のあった取引先だけをSalesforceへ一括でUpsertします。キーには基幹取引先コード（外部ID）を使い、二重登録は起きません。基幹システムは社内ネットワークに残したままです。営業は取引先レコードで与信余力を確認でき、問題のない受注はそのまま次工程へ、与信・値引の例外だけが確実に承認されます。
- 基幹の与信情報を毎日夜間に同期
- 前回値との差分だけをSalesforceへ反映
- 外部IDで二重登録を防止
- 同期の失敗は管理者へChatworkで通知
開発中の課題と解決
値引の基準と判定ルールは、設定で変えられるようにする
- 課題
- 取引方針が変わるたびに判定ルールの改修が必要になると、運用が追いつきません。
- 解決
- 値引の基準はカスタムメタデータ型で管理し、商品区分ごとに責任者承認と部長承認のしきい値を持たせました（初期設定の例：標準品10%・20%）。基準の切り替え・一時停止もでき、変更履歴はSalesforceの設定変更履歴で追えます。
Scope
担当範囲
当社は、要件定義からテスト・リリースまでを担当しました。
| 工程 | 担当 |
|---|---|
| 要件定義 | 営業・経理それぞれから、受注〜出荷の流れと、与信超過・値引承認の現状の判断方法を聞き取り |
| 承認フロー設計 | 与信超過の定義、値引率のしきい値、承認者と順序を表にまとめ、営業責任者・経理と合意 |
| Salesforce開発 | 項目追加、レコードトリガーフロー、承認プロセス、リストビュー・ページレイアウトを構築 |
| 同期バッチ開発 | 項目対応・外部IDの方式・同期時刻と失敗時の扱いを設計し、Node.js / TypeScriptで同期バッチと通知中継を開発。PostgreSQLに同期ログを整備 |
| テスト・リリース | 与信・値引の境界値、両方超過、同期遅延、却下・再申請などをSandboxで検証。本番反映後、操作手順の共有と初期の問い合わせ・設定調整に対応 |
Architecture
使用技術・システム構成
- Salesforce
- 取引先・商談への項目の追加、承認プロセス、リストビュー・ページレイアウト
- Salesforce Flow
- レコードトリガーフロー。受注の保存時に与信余力と値引率を判定し、承認要否と承認ルートを決める
- Node.js / TypeScript
- 与信情報の同期バッチと、プラットフォームイベントを購読する通知中継
- PostgreSQL
- 抽出データと同期ログの保管。前回値との差分を取る
- Chatwork API
- 承認依頼・結果の通知と、同期が失敗したときのシステム管理者への通知
主な技術の選定理由
承認は、条件に該当したときだけ挟む
すべての受注に承認を入れると、通常の受注まで遅くなるためです。通常の受注は従来どおりの速度で進めながら、例外だけを確実に統制します。
同期は差分だけを送る
前回値と比べて変化のあった取引先だけを送ることで、Salesforceへの反映を最小限にし、実行ごとの抽出・反映・失敗件数を同期ログで追えるようにするためです。
Process
開発の進め方
- 1
最初に、営業・経理それぞれから現状の判断方法を聞き取り、承認ルールを表にまとめて営業責任者・経理と合意してから、設計と開発に進みました。
- 2
PHASE 1 ヒアリング・業務整理 → PHASE 2 承認ルールの定義 → PHASE 3 データ・連携設計 → PHASE 4 Salesforce開発 → PHASE 5 同期バッチ・通知の開発 → PHASE 6 テスト → PHASE 7 リリース・定着支援、の7段階で進めました。
- 3
テストはSandboxで行い、本番反映後は、操作手順の共有と、初期の問い合わせ・設定調整まで対応しました。
Quality & Security
品質・セキュリティ・運用
権限設計
与信項目は同期バッチ専用の連携ユーザーだけが更新でき、営業は参照のみです。値引の承認は営業責任者、与信の承認は経理、判定ルールや値引基準の変更はシステム管理者が行います。
承認者が不在の場合
システム管理者が、承認プロセスの「再割り当て」で代理承認者へ付け替えます。
緊急出荷が必要な場合
経理が基幹側で与信限度額を一時的に引き上げ、手動で同期を再実行してから再判定します。
監視とログ
同期バッチは実行ごとに抽出件数・反映件数・失敗件数を記録し、失敗が1件でもあれば、失敗した取引先コードとエラー内容を管理者へChatworkで通知します。
Results
成果
承認は超過時だけ挟む設計としたため、通常の受注は従来どおりの速度で進めながら、例外だけを確実に統制する状態を実現しています。判定ルールと基準値は設定で変更できるため、取引方針の変化にも合わせて運用を調整できます。
- 営業が受注を進める画面上で、与信余力と値引の妥当性が自動で判定されるようになりました。
- 与信超過に受注の段階で気づけるようになり、出荷直前の差し止めに頼らない運用に切り替わりました。
- 値引の承認基準が値引基準マスタとして明文化され、担当者による判断のばらつきがなくなりました。
- 承認の依頼・判断・コメントがメールではなく受注レコードに履歴として残り、後から確認できるようになりました。
FAQ
技術面のよくあるご質問
- Q. 基幹システムをSalesforceへ移したのですか？
- いいえ。基幹システムは社内ネットワークに残したまま、Node.js（TypeScript）製の同期バッチが毎日夜間に与信情報を抽出し、前回値との差分を取って、Salesforceの取引先へ反映しています。
- Q. すべての受注に承認が必要ですか？
- いいえ。営業が受注を保存した時点で判定が走り、超過がなければ、そのまま受注確定へ進みます。超過があった場合だけ承認プロセスが起動し、承認者へChatworkで依頼が届きます。
- Q. 同期が止まったら、判定はどうなりますか？
- 与信同期日時が古い取引先は「要確認」と判定し、自動で経理承認へ回します。判定を通過させてしまう方向には倒しません。
- Q. 値引のしきい値は、後から変えられますか？
- はい。値引の基準はカスタムメタデータ型で管理し、商品区分ごとに責任者承認と部長承認のしきい値を持たせています。変更はシステム管理者が行い、変更履歴はSalesforceの設定変更履歴で追えます。
Tech Stack