今回は、Salesforceの画面フローを使って、入金管理レコードから複数の進捗管理レコードへ、入金額を自動で按分して割り当てる仕組みを作成しました。
複数の商品・サービスをまとめて受注し、その代金を分割で入金してもらう場合、毎回の入金額を「どの商品にいくら割り当てるか」を手作業で計算するのはかなり大変です。
特に、以下のようなケースでは、単純な手計算ではミスが起きやすくなります。
契約総額：3,050,000円
分割入金：12回
1回目〜11回目：254,000円
12回目：256,000円
内訳は以下のようなイメージです。
商品・サービス 販売金額
Googleサイト作成 140,000円
パンフレットデザイン6P 350,000円
封筒デザイン 100,000円
名刺デザイン 50,000円
ホームページ制作 15P 2,260,000円
SDGs宣言ページ作成 スタンダード 150,000円
合計 3,050,000円
今回作ったフローでは、入金管理レコードから画面フローを起動し、按分対象にする進捗管理レコードを選択すると、今回の入金額を自動計算して、入金割り当てレコードを一括作成できるようにしました。
今回作ったもの
今回作成したのは、入金管理レコード上から起動する画面フローです。
処理の流れは以下のようになります。
入金管理レコードを開く
↓
画面フローを起動
↓
按分対象にする進捗管理レコードを複数選択
↓
選択した進捗の販売金額合計と、入金管理の元本額が一致するかチェック
↓
今回の入金額を販売金額比率で按分
↓
端数は販売金額が一番大きい進捗に自動調整
↓
作成前に確認画面を表示
↓
入金割り当てレコードを一括作成
オブジェクト構成
今回の仕組みでは、主に以下のオブジェクトを使っています。
入金管理＝入金そのものを管理するオブジェクトです。
主な項目は以下です。
項目 用途
入金_売上 税抜きの入金金額
割り当て済み金額 子レコードである入金割り当ての合計
割り当て可能金額 入金_売上 から割り当て済み金額を引いた金額
入金日 入金された日にち
元本額 この入金管理が対象とする契約金額
関連商談 対象となる商談
今回の例では、入金管理の元本額は以下です。
3,050,000円
そして、今回の入金_売上は以下です。
254,000円
入金割り当て
入金管理から、各進捗管理へいくら割り当てたかを保存するオブジェクトです。
主な項目は以下です。
項目 用途
入金管理 親の入金管理
割り当て金額 各進捗管理に割り当てる金額
割り当て日 割り当てを実施した日
Googleサービス進捗管理 Google系の進捗へ割り当てる場合に使用
WEBサービス進捗管理 WEB系の進捗へ割り当てる場合
SDGsサービス進捗管理 SDGs系の進捗へ割り当てる場合
認証マーク進捗管理 認証マーク系の進捗へ割り当てる場合
mireva_VR進捗管理 mireva系の進捗へ割り当てる場合
動画サービス進捗管理 動画系の進捗へ割り当てる場合
その他サービス進捗管理 その他サービスへ割り当てる場合
入金割り当てレコードは、7種類の進捗管理オブジェクトのうち、どれか1つを参照する形にしています。
なぜ入金割り当てオブジェクトを挟んだのか
最初は、入金があったら各進捗管理レコードの「入金済金額」を直接更新する方法も考えました。
ただし、直接更新だけにすると、あとから見たときに、
・どの入金管理から
・どの進捗に
・いくら割り当てたのか
等が分かりにくくなります。
そこで今回は、間に 入金割り当てオブジェクト を挟みました。
これにより、入金割り当ての履歴がレコードとして残ります。
入金管理
↓
入金割り当て
↓
各進捗管理
この形にしておくと、あとから修正や確認がしやすくなります。
画面フローの完成イメージ
起動すると、まず入金管理の情報を表示します。※起動条件は「入金日≠ null」です。
入金金額：254,000円
割り当て済み金額：0円
割り当て可能金額：254,000円
その下に、按分対象にする進捗管理レコードをチェックボックスで表示します。
今回の例では、以下の6つを選択します。
Googleサイト作成 / 金額140,000円
パンフレットデザイン6P / 金額350,000円
封筒デザイン / 金額100,000円
名刺デザイン / 金額50,000円
ホームページ制作 15P / 金額2,260,000円
SDGs宣言ページ作成 スタンダード / 金額150,000円
複数オブジェクトの進捗を1つの画面で選ばせる
今回の仕組みを作るうえでおさえておくべきポイントの1つは、進捗管理オブジェクトが1種類ではないことです。
たとえば、以下のように複数の進捗管理オブジェクトがあります。
・Googleサービス進捗管理
・WEBサービス進捗管理
・SDGsサービス進捗管理
・認証マーク進捗管理
・mireva_VR進捗管理
・動画サービス進捗管理
・その他サービス進捗管理
Salesforceの通常の参照項目では、1つの項目から複数オブジェクトを動的に参照することはできません。
そこで今回は、画面フローのチェックボックスグループに、7種類のレコード選択肢セットを追加しました。
・Google用の選択肢
・WEB用の選択肢
・SDGs用の選択肢
・認証マーク用の選択肢
・mireva用の選択肢
・動画用の選択肢
・その他サービス用の選択肢
選択肢の値は「カテゴリ＆ID」という数式項目にした
選択肢の表示ラベルは選びやすいように「進捗管理のレコード名と販売金額」を表示する項目にし、値として保存するのは後述する「カテゴリとID」を表示する項目（後述する按分選択値）にしました。
各進捗管理の「按分選択値」
チェックボックスで選ばれた値が、どの進捗管理オブジェクトのレコードなのか分かるように、判別するための数式項目です。
たとえばGoogle系なら、以下のような値を返します。
“Google|” & CASESAFEID(Id)
WEB系なら以下です。
“WEB|” & CASESAFEID(Id)
SDGs系なら以下です。
“SDGs|” & CASESAFEID(Id)
このようにしておくと、選択された値が以下のようになります。
Google|a02xxxxxxxxxxxx
WEB|a01xxxxxxxxxxxx
SDGs|a1rxxxxxxxxxxxx
後続のフローでは、この値を使って、選択された進捗かどうかを判定しています。
「今回の入金額だけ」で按分すると数値がずれていってしまうことへの対処
単純に「今回入金された金額」を、各商品の販売金額の割合で按分すると、いずれ金額に誤差が生じてしまいます。
たとえば今回の入金額は254,000円です。
今回の入金額：254,000円
契約の元本額：3,050,000円
単純に考えると、各商品の割当額は以下の式で出せます。
今回の入金額 × 各商品の販売金額 ÷ 契約の元本額
Googleサイト作成の場合は、以下のようになります。
254,000 × 140,000 ÷ 3,050,000
= 11,659.01639…
Salesforceの入金割り当て金額は円単位で持ちたいので、小数点以下は切り捨てます。
Googleサイト作成：11,659円
同じように他の商品も計算すると、以下のようになります。
商品・サービス 計算上の金額 切り捨て後
Googleサイト作成 11,659.016… 11,659円
パンフレットデザイン6P 29,147.540… 29,147円
封筒デザイン 8,327.868… 8,327円
名刺デザイン 4,163.934… 4,163円
SDGs宣言ページ作成 スタンダード 12,491.803… 12,491円
この5つの合計は以下です。
11,659 + 4,163 + 8,327 + 29,147 + 12,491 = 65,787円
残りをホームページ制作に入れると、
254,000 – 65,787 = 188,213円
になります。
1回分だけ見ると、以下のように綺麗に合います。
商品・サービス 割当額
Googleサイト作成 11,659円
パンフレットデザイン6P 29,147円
封筒デザイン 8,327円
名刺デザイン 4,163円
SDGs宣言ページ作成 スタンダード 12,491円
ホームページ制作 15P 188,213円
合計 254,000円
ここだけ見ると、問題なさそうに見えます。
しかし、回を重ねるとズレが出る
問題が起きるのは、これを分割入金のたびに繰り返した場合です。
今回の契約では、3,050,000円を12回に分割して入金されます。
1回目〜11回目：254,000円
12回目：256,000円
もし毎回、単純に「その回の入金額だけ」を見て按分すると、1回目から11回目までは毎回同じ金額になります。
商品・サービス 1回あたりの割当額
Googleサイト作成 11,659円
パンフレットデザイン 29,147円
封筒デザイン 8,327円
名刺デザイン 4,163円
SDGs宣言ページ作成 スタンダード 12,491円
ホームページ制作 15P 188,213円
合計 254,000円
この時点では、各回の合計は254,000円に合っています。
ただし、12回すべてが終わったときに、商品ごとの入金済み金額が販売金額と完全に一致するとは限りません。
単純按分を12回続けた場合
最後の12回目は256,000円です。
Googleサイト作成の場合、12回目の按分額は以下のようになります。
256,000 × 140,000 ÷ 3,050,000 = 11,750.819…
切り捨てると、11,750円になります。
この方法で12回分を合計すると、以下のようなズレが生じます。
商品・サービス 本来の販売金額 単純按分を12回した合計 差額
Googleサイト作成 140,000円 139,999円 -1円
パンフレットデザイン 350,000円 349,994円 -6円
封筒デザイン 100,000円 99,990円 -10円
名刺デザイン 50,000円 49,989円 -11円
SDGs宣言ページ作成 スタンダード 150,000円 149,991円 -9円
ホームページ制作 15P 2,260,000円 2,260,037円 +37円
合計 3,050,000円 3,050,000円 0円
全体の合計は3,050,000円に合っています。
しかし、内訳を見るとズレています。
Googleサイト作成は1円足りない
パンフレットデザイン6Pは6円足りない
封筒デザインは10円足りない
名刺デザインは11円足りない
SDGs宣言ページ作成 スタンダードは9円足りない
ホームページ制作は37円多い
つまり、合計金額は合っているのに、商品ごとの入金済み金額が販売金額と一致しない状態になります。
これが、単純に「今回の入金額だけ」で按分したときの問題です。
なぜズレるのか？
原因は、小数点以下の端数です。按分計算では、ほとんどの場合、小数点以下が出ます。
11,659.016…
4,163.934…
8,327.868…
29,147.540…
12,491.803…
この小数点以下を毎回切り捨てると、各商品ごとに少しずつ差がたまっていきます。
1回あたりは1円未満の差でも、分割回数が増えると、最終的には数円から数十円のズレになります。
金額としては小さなズレかもしれませんが、Salesforce上で入金済み金額や売掛金額を管理する場合、このズレは見逃せません。
本来は全額入金済みのはずなのに、
名刺デザインだけ11円足りない
封筒デザインだけ10円足りない
ということになってしまいます。
運用上、これは解決しなければなりません。
「累計按分方式」にすることで解決
このズレを防ぐために、今回は「今回の入金額だけ」を見るのではなく、その時点までの累計の入金額を見るようにしました。
考え方は以下の通りです。
今回の割り当て後の入金済み合計 × 各商品の販売金額 ÷ 契約の元本額
そして、そこから、「すでにその商品に割り当て済みの金額」を引きます。
今回の割当額 = 累計で本来入っているべき金額 - 今までに割り当て済みの金額
この考え方にすると、毎回の端数をその場だけで終わらせず、次回以降の計算で自然に調整できます。
累計按分の具体例
1回目の入金後は、累計入金額が254,000円です。
累計入金額：254,000円
この時点では、先ほどと同じような金額になります。
商品・サービス 1回目の割当額
Googleサイト作成 11,659円
パンフレットデザイン6P 29,147円
封筒デザイン 8,327円
名刺デザイン 4,163円
SDGs宣言ページ作成 スタンダード 12,491円
ホームページ制作 15P 188,213円
合計 254,000円
次に、2回目の入金があったとします。
2回目も254,000円なので、累計入金額は508,000円になります。
1回目：254,000円
2回目：254,000円
累計入金額：508,000円
ここで、名刺デザインの累計で本来入っているべき金額を計算します。
508,000 × 50,000 ÷ 3,050,000 = 8,327.868…
切り捨てると、累計で8,327円
1回目に名刺デザインへ割り当てた金額は4,163円なので、2回目の名刺デザインの割当額は、8,327 – 4,163 = 4,164円になります。
単純に毎回の入金額だけで計算すると、名刺デザインは毎回4,163円でした。
しかし、累計按分では2回目に4,164円になります。
これは、1回目で切り捨てられた端数が、2回目の計算で自然に調整されている自動化ができるということです。
端数調整の必要性について
前述の累計按分方式を採用するにしても、1回ごとの入金割り当てを作るときには、小数点以下の端数が出ます。
たとえば、Googleサイト作成は以下のようになります。
254,000 × 140,000 ÷ 3,050,000 = 11,659.016…
小数点以下を切り捨てると、11,659円になります。
ただし、すべての商品を単純に切り捨ててしまうと、そもそも今回の入金額254,000円と、作成する入金割り当ての合計が一致しない可能性があります。
仮に、ホームページ制作も普通に計算して切り捨てた場合は以下です。
254,000 × 2,260,000 ÷ 3,050,000 = 188,212.459…
切り捨てると、188,212円になります。
すると、全体の合計は以下になります。
Googleサイト作成：11,659円
パンフレットデザイン6P：29,147円
封筒デザイン：8,327円
名刺デザイン：4,163円
パンフレットデザイン6P：29,147円
SDGs宣言ページ作成 スタンダード：12,491円
ホームページ制作 15P：188,212円
合計：253,999円
今回の入金額は254,000円なので、1円足りません。
この1円のズレを残したままにすると、入金管理の「割り当て可能金額」が1円残ってしまうような状態になります。
そのため、どこか1つの商品に端数を寄せて、合計を必ず一致させる必要があります。
端数は一番大きい販売金額に寄せる
今回のフローでは、端数調整先をユーザーに選ばせるのではなく、選択された進捗の中で販売金額が一番大きい進捗を自動で端数調整先にしました。
今回の例では、販売金額が一番大きいのはホームページ制作15P：2,260,000円です。
そのため、Googleサイト作成、パンフレットデザイン6P、封筒デザイン、名刺デザイン、SDGs宣言ページ作成 スタンダードを先に計算します。
その合計は以下です。
11,659 + 4,163 + 8,327 + 29,147 + 12,491 = 65,787円
最後に、今回の入金額からこの金額を引きます。
254,000 – 65,787 = 188,213円
これをホームページ制作に割り当てます。
商品・サービス 割当額
Googleサイト作成 11,659円
パンフレットデザイン6P 29,147円
封筒デザイン 8,327円
名刺デザイン 4,163円
SDGs宣言ページ作成 スタンダード 12,491円
ホームページ制作 15P 188,213円
合計 254,000円
これで、今回の入金額と入金割り当て合計が必ず一致します。
なぜ一番大きい商品に端数を寄せるのか
端数は、1円〜数円程度の小さな金額になることが多いです。
この端数を販売金額が小さい商品に寄せると、割合として少し目立ちやすくなります。
たとえば、50,000円の商品に1円の差が出るのと、2,260,000円の商品に1円の差が出るのでは、後者の方が影響は小さく見えます。
そのため今回は、フロー側で自動的に選んだ商品の中で一番販売金額が大きいものを端数調整先とするようにしました。
これにより、ユーザーが毎回判断しなくても、一定のルールで端数の処理を実行できます。
フロー上の作り方
今回のフローでは、ループを2回に分けています。
1回目のループ
1回目のループでは、入金割り当てレコードは作りません。
やることは以下です。
選んだ進捗管理の販売金額（合計）を計算する
選んだ進捗管理の現在の入金済み金額の合計を計算する
販売金額が一番大きい進捗管理を端数調整先として保存する
上記を7つの進捗管理オブジェクトごとに分けてループさせます。つまり１回目のループではループ要素は7回使用します。
元本金額と選択金額のチェック
ユーザーが按分対象を選ぶ方式にしたため、フロー内で選択ミスを防ぐチェックを入れました。
チェック内容は以下です。
選んだ販売金額合計 = 入金管理の元本金額
今回の例では、選んだ販売金額合計が以下になります。
140,000 + 50,000 + 100,000 + 350,000 + 2,260,000 + 150,000 = 3,050,000円
入金管理の元本額も3,050,000円なので、処理を続行します。
※もし一致しない場合は、エラー画面を表示するようにしました。
2回目のループ
2回目のループでは、実際に入金割り当てレコードを作りますが、端数調整となる進捗管理への入金割り当てはこの時点では作らず、あとまわしにします。
まず、端数調整先以外の商品（進捗管理）について、今回の割当額を計算します。
計算式の考え方は以下です。
割当後の入金済み合計 × 今ループ中の進捗管理の販売金額 ÷ 選んだ販売金額合計 – 今ループ中の進捗管理の入金済み金額
※Salesforceの数式では、入金済み金額が空欄の場合は、0として扱うようにしました。
そうしないと、計算結果がNullになってしまい、割当額が作られないということが起こります。
端数調整先となる進捗管理以外の合計金額を保存する
端数調整先以外の入金割り当てを作るたびに、その金額を合計しておきます。
今回の例では、以下の金額が入ります。
Googleサイト作成：11,659円
パンフレットデザイン6P：29,147円
封筒デザイン：8,327円
名刺デザイン：4,163円
SDGs宣言ページ作成 スタンダード：12,491円
合計は65,787円となります。
ここを間違えて、端数調整分の金額を加算してしまうと、最後の端数調整先の金額が崩れます。
端数調整先は最後に作る
端数調整先の金額は、最後に以下の式で出します。
今回の割り当て可能金額 – 端数調整先となる進捗管理以外の合計金額
今回の例では、
254,000 – 65,787 = 188,213円となります。
この188,213円を、販売金額が一番大きいホームページ制作に割り当てます。
フローでは、1回目のループで保存しておいた以下の情報を使います。
端数を入れる先のName項目
端数を入れる先のID項目
端数を入れる先のオブジェクトの種類（決定要素で分岐をつくる）
今回の端数調整先はホームページ制作15Pなので、入金割り当てレコードのWEBサービス進捗管理項目にIDをセットします。
確認画面
フロー実行前には、下記のような確認画面を表示するようにしました。
作成される入金割り当てレコード
最終的には、以下の6件の入金割り当てレコードが作成されます。
入金割り当て先の進捗管理 金額
Googleサイト作成 11,659円
パンフレットデザイン6P 29,147円
封筒デザイン 8,327円
名刺デザイン 4,163円
SDGs宣言ページ作成 スタンダード 12,491円
ホームページ制作 15P 188,213円
合計 254,000円
今回の構築で良かった点
今回の仕組みを作ったことで、以下のようなメリットがありました。
・手作業で按分計算しなくてよくなった
・端数処理の自動化によりミスがなくなった
・元本額と一致するもののみを対象としたことで、数値上の不整合がでなくなった
・入金割り当ての履歴をレコードとして残せるようになった
・分割入金でも商品ごとの入金済み金額がズレなくなった
特に、単純な分割ごとの入金額ベースの按分ではなく、累計按分にしたことで、回を重ねたときの端数ズレを抑えられるようになりました。
まとめ
今回は、Salesforceの画面フローを使って、入金管理レコードから複数の進捗管理レコードへ、入金額を累計按分で割り当てる仕組みを作成しました。
毎回の入金額だけを見て按分すると、商品ごとの累計金額に小さなズレが残ることがあります。
今回のように累計按分にすることで、過去の端数も含めて次回以降で調整できるため、より実務に合った入金管理ができます。結果的にかなり実務的な入金按分処理を作ることができたと思います。
