数式エラーのトラブルシューティング

学習の目的

この単元を完了すると、次のことができるようになります。

一般的な数式エラーの原因を理解する。
高度な数式項目をトラブルシューティングする。

構文エラー

高度な数式のエキスパートでも時として、数式の問題に突き当たることがあります。最も一般的な数式エラーは、構文エラーです。数式の構文を任意の時点でチェックするには、[構文を確認] をクリックします。

括弧の過不足

誤って数式に余分な括弧を付けたり、括弧を付け忘れたりすることはよくあります。このエラーは特に、IF()、AND()、OR() などの論理ステートメントをネストしているときに多く見られます。

たとえば、次の数式は最後の閉じ括弧が抜けています。

括弧が抜けている構文エラー。Is Executive (Checkbox) = OR(BEGINS(Title, "Chief"), CONTAINS(Title, "President")

括弧が多すぎる場合や、関数内のカンマの位置が間違っている場合も、このエラーが生じます。次も同じ数式ですが、余分な括弧が付いています。

余分な括弧がある構文エラー。Is Executive(Checkbox)=OR(BEGINS(Title, "Chief"), CONTAINS(Title, "President")))

存在しない項目

構文エラーについては、高度な数式エディタを見方につけます。[演算子の挿入] または [項目の挿入] ボタンを使用中は、項目や関数の名前のスペルを間違えることがほぼありません。

項目名にスペルミスがある構文エラー。Interest Rate (Percent)= IF(Principle_c<1000, 0.02, IF(Principle_c>=1000 && Principle_c<1000, 0.03,0.04))

上記は、Principle__c ではなく、Principal__c 項目を参照することを意図しています。また、テキスト文字列の前後に引用符を付け忘れた場合も、このエラーが発生します。

パラメータの数の間違い

特定の関数に使用するパラメータの数が正しくないと、構文エラーが生じます。CASE() のように、可変数のパラメータを取る関数は特に注意します。

関数のパラメータの数が正しくない構文エラー。Priority(Number)=CASE(Type, "Electrical",1,"Electronic",2,"Mechanical",3,"Structural",4,"Other",5)

上記の数式には、CASE() ステートメントの最後の引数 (失敗ケース) がありません。数式エディタは、ケースを 5 つではなく、4 つのみをチェックする意図であったと想定します。そのため、本来ならば 12 の引数を指定すべきときに、エディタは合計 10 の引数しか確認していません。

不明な関数

関数名のスペルを間違えたときや、存在しない関数を使用しようとしたときにもエラーが発生します。

上記の数式は、存在しない MINIMUM() という関数を参照しようとしています。本来意図していた関数は、数値のリストを取って最小値を返す MIN() です。

異なるデータ型の処理

数式を作成するときは、記述する前に、返される値をどのデータ型にするか検討します。数式で選択したもの以外のデータ型が返されると保存できません。

型を変換しているとき、あるいは日付と日付/時間や数値と通貨などよく似たデータ型を使用しているときにデータ型を混同することがよくあります。たとえば、次の数式は、戻り値のデータ型に日付/時間を選択していますが、日付値を返すように記述されています。

この数式の戻り値のデータ型は、返される値として記述されたデータ型と異なります。Payment Due (Date/Time)= TODAY() +7

このエラーを修正するには、数式項目の戻り値のデータ型を日付に変更します。あるいは、TODAY() を NOW() に置換して、日付ではなく日付/時間値が生成されるようにします。

コンパイルサイズおよび数式文字数のエラー

数式項目は強力ですが、サイズに制限があります。数式の最大文字数は、スペース、改行文字、コメントを含めて 3,900 字または 4,000 バイトで、コンパイル時に 5,000 バイト以下である必要があります。ここで重要な点は、これらのサイズ制限の違いと、この制約下で対処する方法を理解することです。

文字数の制限

数式の最大文字数は 3,900 字です。この文字数はいくつかの方法で減らすことができます。たとえば、AND() を && に置換すれば、該当箇所ごとに数文字減らすことができます。また、ネストされた IF() ステートメントを CASE() ステートメントに置換しても何文字か減少します。また、項目名やコメントを短くすれば、わずかですか確実に減少させることができます。

数式項目が 3,900 字を大幅に超えている場合は、ヘルパー数式項目を使用します。

コンパイルサイズの制限

数式が 3,900 字未満でも、コンパイルサイズが 5,000 バイトの制限を超えることがあります。数式がコンパイルサイズの制限を超える場合は、ヘルパー項目を作成したり、項目名やコメントを短くしても変わりません。ヘルパー項目を参照すると、そのコンパイルサイズが、参照元の数式のコンパイルサイズに加算されます。数式のコンパイルサイズを縮小する 1 つの方法は、他の数式項目への参照を最小限にすることです。

ネストされた IF() ステートメントを CASE() ステートメントに置換するなど、数式の文字数を減らす方法の中に、数式のコンパイルサイズも縮小するものがあります。

次の 2 つの項目について考えてみます。

Date1__c は日付項目です。
Date2__c は、Date1__c から日付を作成する数式項目です。
```
DATE( YEAR( Date1__c ), MONTH( Date1__c ), DAY( Date1__c ) )
```

次の数式は、指定した日付の月の最終日の日付を返します (2 月の日数を常に 28 日と仮定します)。

DATE(
 YEAR( SomeDate__c ),
 MONTH( SomeDate__c ),
 IF(
   OR(
     MONTH( SomeDate__c ) = 4,
     MONTH( SomeDate__c ) = 6,
     MONTH( SomeDate__c ) = 9,
     MONTH( SomeDate__c ) = 11
   ),
   30,
   IF(
     MONTH( SomeDate__c ) = 2,
     28,
     31
   )
 )
)

この数式は最初に日数が 30 日の月、次に 2 月、最後に 31 日の月をチェックします。このためにはネストされた IF() 関数が必要ですが、かなり読みにくく、Date1__c のコンパイルサイズは 1069 字、Date2__c については 7,271 字です! なぜなら、数式が日付を 7 回も参照しているためです。この数式を次の修正バージョンと比較してみましょう。

DATE(
 YEAR( SomeDate__c ),
 MONTH( SomeDate__c ),
 CASE(
   MONTH( SomeDate__c ),
   2, 28,
   4, 30,
   6, 30,
   9, 30,
   11, 30,
   31
 )
)

読みやすくなっただけでなく、数式のコンパイルサイズが Date1__c は 645 字、Date2__c は 3,309 字になり、日付の参照も 7 回から 3 回に減っています。

次の例は Salesforce アンサーコミュニティで取り上げられたものです。選択リストには、商談を担当するエージェントの名前が格納されています。この数式は、基本手数料の値と乗数に基づいて手数料を計算します。けれども、CASE() ステートメントの条件ごとに Base_Commission__c が参照されるため、コンパイルサイズを超えてしまいます。

CASE( Agent__c,
  "John", Base_Commission__c * 2,
  "Jane", Base_Commission__c * 6,
  /* Repeat for many other agents */
  Base_Commission__c
)

この問題を修正するために、Base_Commission__c を CASE() 関数の外に移動します。数式は次のように記述し直すことができます。

Base_Commission__c * CASE( Agent__c,
  "John", 2,
  "Jane", 6,
  /* Repeat for many other agents */
  1
)

基本手数料が単なる通貨項目で、それ自体が数式でなくても、参照が複数回から 1 回になれば、数式のコンパイルサイズが大幅に減少します。