Zoho CRMで「入金」「仕入」「経費」といった数値を月ごとに集めて、損益や口座残高まで一枚のモジュールにまとめたい、という相談はよくあります。今回は、複数のモジュールに散らばった金額を月次レコードへ集計転記するDeluge関数の作り方を、設計の考え方を中心に紹介します。

そもそもワークフローで集計してはいけない

最初にやりがちなのが、各レコードの作成・編集時に発火するワークフローで集計関数を呼ぶ方法です。これは月次集計には向きません。

月の合計は、1件のレコードが変わると月全体の数字が動きます。レコード単位のトリガーだと「1件だけ足す」「1件だけ引く」といった差分更新を書くことになり、編集・削除・減額のたびに整合性が崩れやすくなります。とくに加算方式で書くと、同じレコードを編集するたびに二重計上され、数字がどんどん膨らみます。

集計系は、定期実行関数（Scheduled Function）で「対象を全件取得して毎回フルで計算し直す」のが正解です。差分を追わず、毎回ゼロから組み直すので、どんな編集が入っても常に正しい値に収束します。

冪等な「全件→上書き」で組む

定期実行関数の中身は、シンプルな3ステップで構成します。

まず、集計したい各モジュールを全件取得し、月をキーにしたMapに合計を積み上げます。次に、書き込み先の月次モジュールを読み込み、月キーで対応するレコードを特定します。最後に、月ごとに集計値を書き込み、ついでに損益や残高を計算します。

ポイントは、加算ではなく「その月の値を丸ごと上書きする」ことです。これなら何度実行しても結果が変わらない冪等な処理になり、二重計上が原理的に起きません。

月キーは文字列で揃える

複数のモジュールをまたいで集計するので、月の表現を統一しておく必要があります。日付フィールドから「yyyy/M」形式の文字列キーを作り、書き込み先モジュールの主フィールド（例: 2026/2）と突き合わせます。

<pre> key = dueDate.toDate().toString("yyyy/M"); totals.put(key, ifnull(totals.get(key),0) + amount); </pre>

ここで注意したいのが表記ゆれです。片方が「2026/2」で片方が「2026/02」（ゼロ埋め）だったり、全角が混ざっていたりすると、キーが一致せず集計が0になります。集計が合わないときは、まずこのキーの形を疑うとよいです。

レポートの集計条件を関数に移植する

実務でいちばんハマるのが「Zohoの標準レポートでは正しく集計できているのに、関数の数字だけ合わない」というケースです。

これはたいてい、レポート側が何らかのフィルター条件で絞り込んでいて、関数がその条件を再現できていないために起きます。今回の案件でも、レポートは「支払い状況がクレジット払いのものを除外」という条件で集計していました。関数は全件を合算していたため、クレジット払いの数件分だけ数字がズレていたわけです。

原因の特定は、1ヶ月分だけ「レポートの正解値」と「関数の出力値」を並べ、差額を出すのが速いです。差額が特定のレコード群の合計と一致すれば、その性質（支払い方法、種別、日付の有無など）が除外条件だと分かります。あとは同じ条件を関数のループ内に1行足すだけです。

<pre> if(payStatus != "クレジット払い") { // この条件を満たすものだけ集計 } </pre>

正しい数字はレポートが持っていることが多いので、レポートを「正解」と置いて関数を寄せていく進め方が確実です。

ページングと日付欠落に注意

getRecordsは1回で取れる件数に上限があります。1ページ200件なので、データがそれを超えるモジュールでは、ページ番号を回して全件取得しないと、超えた分が黙って無視され、合計が実態より小さく出ます。

また、集計の基準にしている日付フィールドが空のレコードは、そのままだと集計から漏れます。漏れること自体が正しい運用なのか、それとも別の日付で拾うべきなのかは、業務側の意図によります。スキップした件数をログに出しておくと、こうした欠落に早く気づけます。

<pre> if(closeDate != null) { // 締め日があるものだけ集計 } else { skipped = skipped + 1; } info "日付が空でスキップした件数: " + skipped; </pre>

縦持ちモジュールを集計ソースにする

入金のように「1件の取引に複数回の支払いがある」データは、回数ごとにフィールドを分けて持つ（1回目・2回目・3回目…）よりも、1支払=1レコードで縦持ちにした集計用モジュールを用意しておくと扱いが楽です。

横持ちのまま集計しようとすると、関数側で回数ぶんのフィールドをすべて拾って合算する必要があり、回数が増えるたびにコード修正が発生します。縦持ちモジュールを集計ソースにすれば、1つのフィールドをループで足すだけで全回数が自然に集まります。集計や帳票を見据えるなら、データ構造の段階で縦持ちにしておくのがおすすめです。

まとめ

複数モジュールから月次サマリーへ集計転記する実装の勘どころは、レコードトリガーではなく定期実行を選ぶこと、加算ではなく全件→上書きの冪等処理にすること、月キーの表記を揃えること、そしてレポートの集計条件を関数に正確に移植することです。

数字が合わないときは、レポートを正解として1ヶ月分の差額を出す。この一手で、ズラし・日付欠落・除外条件といった原因がほぼ確実に切り分けられます。集計ロジックそのものより、こうした「条件合わせ」のほうが実装の本番だと考えておくとよいです。