融資・返済と管理本部業務を、案件に一元化。
入力漏れまで検知する仕組みへ

設計の大原則は、「情報ごとに正本を1つに定め、同じ情報を複数のオブジェクトに重複して持たせない」ことです。案件や子案件に項目を足していくのではなく、「融資」「返済明細」「管理本部手続」という3つの独立したオブジェクトを新設し、既存の案件管理と連携させる構造にしました。

• 01PJ融資：金融機関・融資金額・融資実行日・返済期日などを借入1本ごとに管理。1つの案件に複数の融資を持てる。融資残高・完済予定日・完済日は、返済明細からの集計で自動算出
• 02返済明細：返済の予定と実績を、返済1回ごとに管理。返済の基準となる子案件の販売決済日を参照し、決済予定日が変わると返済予定日も自動で更新される（返済手続中・返済済みのものは上書きせず、メールで通知）
• 03管理本部手続：火災保険・電気・水道・ガス・税金・還付・書類管理などを、1手続＝1レコードで管理。仕入決済日・販売決済日を基準に、開始予定日・終了予定日を自動設定する

案件に簡易的に持たせていた従来の融資項目は廃止し、新しいオブジェクトへ完全に移行しました。また、当初は子案件に約27項目を追加して管理する案もありましたが、手続ごとに期日・状況を持てるよう、管理本部手続オブジェクトに一本化しています。

業務の実態に合わせて、設計の途中で方針を見直した点がいくつもあります。

• 01実際の組織を調べて、前提を訂正：設計の出発点に整理されていた内容には、実際のSalesforce組織と異なる前提が含まれていました（新規と思われていた融資管理に簡易版が既存だった、など）。実際のメタデータと既存Flowを調査したうえで前提を訂正し、設計方針を確定
• 02あえて「自動化しすぎない」：分筆・合筆時の手続・返済明細の引継ぎは、自動判定にせず必ず画面で管理本部に確認させる設計に。必要な契約や返済予定を誤って解約・削除扱いにするリスクを避けるため
• 03「必要な手続のみ作成」に方針変更：当初は「不要な手続もレコードを作り、ステータスを『不要』にする」案でしたが、「後から必要になった時に、既存レコードを更新するのか新規作成するのか分かりにくい」という運用面の指摘を受け、必要な手続のみを作成する方針に変更
• 04通知先を名簿に一元化：当初は各手続のレコードに通知先をコピーする方式でしたが、「通知先を変えるのに名簿と手続レコードの両方を直すのは本末転倒」との指摘を受け、通知時に常に最新の担当者名簿を直接参照する方式へ。担当者の異動時は名簿を更新するだけで、既存・新規すべての手続に反映される
• 05既存の分筆・合筆Flowへの影響を最小限に：既存の按分計算ロジックを壊さないよう、既存Flowへの追加は末尾に接続する形を基本方針とした