支給から支払までのガイダンス
計算プロセスは支払プロセスから分離されています。 計算を実行すると、実行するたびに支給が更新されます。
支払金額を支払システムに送信する前に、計算を複数回実行できます。 その支払サイクルの計算が完了したとき、プロセス・フローの最後に支払プロセスが開始されます。 支払プロセスでは、参加者の支給データを連結する支払バッチの作成および支払を実行しますが、支払システムに送信する前にレビューできます。
この図では、支払プロセスの実行および支払バッチの生成前にいくつかの計算が実行されています。

支給から支払までのバッチ
計算を実行すると、新しい支給項目レコードが作成されるか、更新がない場合は古い支給項目レコードがそのまま残ります。 ある期間の支払バッチを作成すると、これらの支給レコードが連結され、すでに支払われている金額が確認され、その期間に支払われる現在の支払金額が算出されます。 期間がオープンであるかぎり、支払バッチが支払済かどうか、または支払バッチが存在するかどうかさえ、計算の実行の制限にはなりません。 つまり、支払バッチを作成しても支払っても、同じ期間を再計算できます
この図のバッチは、計算から支給を取得し、期間の支払済金額を差し引いてBATCの支払金額を決定

未払の支払バッチ
支払バッチの作成後、再計算により新しい支給レコードが作成されて、支払バッチがまだ未払の場合は、「支払バッチのリフレッシュ」プロセスを実行して、最新の支給を支払バッチに反映する必要があります。 このプロセスを実行しないと、計算を再実行する前に作成された古い支給項目レコードに基づいた支払データになります。 つまり、この未払バッチをリフレッシュせずに支払うと、更新済の支給金額とすでに支払済の金額の間のデルタ(プラスまたはマイナス)が、次に作成する支払バッチに含められます。
この図では、既存のバッチが未払である間に支給が再計算されたため、支払バッチのリフレッシュが実行されます。

たとえば、2020年1月の営業担当John Smithの支給が$1000の場合に、2020年1月の支払バッチを作成するとします。 John Smithの未払の支払シートに反映される支払金額も$1000になります。 ここで、支払バッチの作成後に発生した変更のために、再計算が必要になりました。 John Smithの2020年1月の支給が$1200になりました。 ただし、John Smithの支払シートの金額は、「支払バッチのリフレッシュ」プロセスを実行しないかぎり$1000のままになります。 支払バッチをリフレッシュせずにバッチをそのまま支払うと、John Smithを含む次の支払バッチに、彼に対する$200の支払デルタが設定されます。
支払済の支払バッチ
支払バッチの支払後に、再計算のために新しい支給レコードが作成された場合は、すでに支払済の支払バッチにそれらは反映されません。 支払済の支払バッチはリフレッシュできません。 新しい金額は、作成される次の支払バッチにのみ反映されます。 そのため、作成される次の支払バッチには、更新済の支給金額とすでに支払済の金額の間のデルタ(プラスまたはマイナス)が含まれます。
たとえば、2020年1月の営業担当John Smithの支給が$1000の場合に、2020年1月の支払バッチを作成して支払うとします。 John Smithの支払済の支払シートに反映される支払金額も$1000になります。 ここで、支払バッチの支払後に発生した変更のために、再計算が必要になりました。 John Smithの2020年1月の支給が$700になりました。 2020年1月の支払バッチはすでに支払われているため、その支払バッチは変更できません。 ただし、John Smithに対して作成される次の支払バッチには、2020年1月に対して再度作成される場合も、2020年2月などの後続の期間に対して作成される場合も、彼に対するマイナス$300の支払デルタが反映されます。