計算フィールドを備えた PDF フォーム の入力可能なドキュメントにより、ユーザーは手作業での計算を行う必要がなくなります。注文フォームでは、品目の合計が自動的に計算されます。経費レポートではカテゴリが合計されます。タイムシートは、開始時刻と終了時刻から労働時間を計算します。これらの計算が正しく機能するのは、すべての数式、フィールド参照、および条件付きロジック ルールがフォーム デザイナーで正しく設定されており、フォームがユーザーに配布される前に一定範囲の入力値を使用してテストされた場合に限られます。
フォームが流通した後に計算ミスが発見されると、信頼性の問題が生じます。エラーに気付いたユーザーはフォームの使用を中止する可能性があります。それに気付かないユーザーは、下流システムに伝播する誤ったデータを送信します。配布前にフォームフィールドの計算を検証することで、実際のユーザーデータによって明らかにされるまで検出されなかった数式エラー、フィールド参照の間違い、およびエッジケースのエラーが検出されます。
WukongPDF の Fillable PDF ツールには、計算フィールドのセットアップおよび検証機能が含まれています。
PDF フォームの計算の仕組み
PDF フォームの計算では、フィールドのプロパティに埋め込まれた簡素化された JavaScript 構文が使用されます。各計算フィールドには、他のフィールドを名前で参照する式があります。この数式では、基本的な算術演算を実行し、if-else ステートメントを使用して条件付きロジックを適用し、結果を数値、通貨、パーセンテージ、または日付としてフォーマットすることができます。ユーザーが数式が参照するフィールドを変更すると、PDF リーダーは依存フィールドを自動的に再計算します。
複数ステップの数式では、計算順序が重要です。フィールド C がフィールド B に依存し、フィールド B がフィールド A に依存する場合、計算では最初に A、次に B、次に C を処理する必要があります。PDF リーダーはフィールドの依存関係に基づいて計算順序を自動的に決定しますが、フィールド A がフィールド B に依存し、フィールド B がフィールド A に依存する循環参照では、エラーまたは無限ループが発生します。フォームを配布する前に、計算順序を検証して、すべての依存関係が正しく解決されることを確認する必要があります。
各計算フィールドの系統的なテスト
フォーム内のすべての計算フィールドと、特定の入力値に対して予想される出力をリストするテスト計画を作成します。数量、単価、明細合計フィールドを含む単純な注文フォームの場合、テスト計画では数量 = 5、単価 = 10.00、予想される明細合計 = 50.00 と指定されます。計画の各行をテストし、実際の出力が予想される出力と一致するかどうかを記録します。
単一のセットだけでなく、入力値の範囲をテストします。数値フィールドの場合は、ゼロ、標準値、非常に大きな値、およびフィールドが負数を受け入れる場合は負の値でテストします。 1 桁の入力では正しく機能する数式が、6 桁の入力ではオーバーフローしたり、予期しない結果が生成される場合があります。フィールド値で除算する数式は、そのフィールドがゼロの場合を処理する必要があります。
フォームフィールドの条件付きロジックの検証
多くのフォームには、ユーザーの選択に基づいてフィールドを表示、非表示、または変更する条件付きロジックが含まれています。配送フォームには、国フィールドが米国の場合は国内配送オプションが表示され、それ以外の場合は国際配送オプションが表示される場合があります。各条件パスは個別にテストする必要があります。フォームに 3 つの条件付きフィールドがあり、それぞれに 2 つの可能な状態があり、テストする必要がある組み合わせは 8 つになります。
条件間の境界をテストします。ユーザーが条件をトリガーするドロップダウンの最後のオプションを選択するとどうなりますか?最初のオプションを選択すると何が起こるでしょうか?選択を行った後にフィールドをクリアするとどうなりますか?状態間の遷移は、バグが最も多く隠れている場所です。条件が満たされたときに正しく表示されるフィールドが、その後条件がクリアされたときに消えない場合があります。
フィールド参照の整合性のチェック
計算フィールドは、内部フィールド名によって他のフィールドを参照します。これは、ユーザーに表示されるラベルとは異なる場合があります。フォーム上の「電子メール アドレス」というラベルの付いたフィールドには、内部名「Email_Address」または「email1」が付いている場合があります。計算フィールドが EmailAddress を参照しているが、実際のフィールド名が Email_Address である場合、計算は警告なしに中断されます。フォームにはエラーは表示されません。計算フィールドには単にゼロまたは空白が表示されます。
各計算フィールドのフィールド プロパティを開き、[フィールド] パネルですべてのフィールド参照を実際のフィールド名と照合して確認します。 Qty と Qtty など、フィールド参照に 1 つのタイプミスがあると、そのフィールド全体の計算が中断されます。 [フォームの準備] ツールのフィールド リストを使用すると、すべてのフィールド名を 1 つのビューで表示し、計算式と相互参照できます。
| 計算タイプ | 例 | 検証方法 |
|---|---|---|
| フィールドの合計 | 小計 + 税金 = 合計 | サンプル計算を手動で検証する |
| 条件付きロジック | チェックボックス A の場合、フィールド B を有効にします | 各条件パスをテストする |
| 日付の計算 | 終了日 = 開始日 + 30 日 | 閏年を含むエッジ日付をテストする |
複数の PDF リーダーでのフォームのテスト
PDF フォームの計算は、PDF リーダーでの JavaScript の実行に依存します。さまざまなリーダーが、さまざまな完成度で Acrobat JavaScript API を実装します。 Adobe Acrobat Reader で機能する計算は、ブラウザベースの PDF ビューア、Mac のプレビュー、またはモバイル PDF アプリでは実行できない場合があります。フォームには、計算をサポートする PDF リーダーを指定するメモを含める必要があります。
少なくとも 3 つのリーダー (Adobe Acrobat Reader、Chrome や Edge などのブラウザベースのビューア、Mac 上のプレビュー) でフォームをテストします。各リーダーについて、テスト値を入力し、計算が正しく実行されることを確認します。特定のリーダーで計算が機能しない場合は、Acrobat Reader でフォームを開くようにユーザーに指示する互換性に関する注記を追加するか、より広くサポートされている JavaScript 機能を使用するように計算を変更するかを決定します。
フォーム配布用の検証チェックリストの作成
計算フォームを配布する前に、最終検証チェックリストを実行してください。すべての計算フィールドが、少なくとも 3 つの入力の組み合わせに対して正しい出力を生成することを確認します。数式内のすべてのフィールド参照が実際のフィールド名と一致していることを確認します。すべての条件付きロジック パスをテストします。複数の PDF リーダーで計算を検証します。タブ オーダーが論理的な順序でフィールド内を移動することを確認します。
どのテスト値が使用されたか、どのリーダーがテストされたか、見つかって解決された問題など、検証結果を文書化します。検証記録は、将来のフォーム更新のための文書として、またフォームの正確性を証明する必要があるコンプライアンス要件のための文書として機能します。検証に合格し、結果が文書化されたフォームは、単に正しく機能すると想定されているフォームよりも信頼感が高まります。
配布前に PDF フォームの計算を検証すると、フォームが正確であると信頼しているユーザーから誤ったデータが自動的に生成されるエラーが検出されます。検証プロセスは、フォームが数週間配布された後にデータ エラーを修正するよりも短時間で済みます。
形式計算における浮動小数点精度の処理
PDF フォームの計算では、浮動小数点の JavaScript 数値型を使用します。 0.1 と 0.2 を加算すると、0.3 ではなく 0.30000000000000004 が生成される場合があります。財務計算の場合は、toFixed() を使用して結果を四捨五入します (event.value = (field1 + field2).toFixed(2))。これは小数点第 2 位に四捨五入され、精度の誤差を回避します。
正確なエッジケースを生成することがわかっている値を使用して計算をテストします。 0.1 と 0.2 を加算し、四捨五入後の 0.3 を確認します。 0.1 に 3 を掛けて、0.3 を確認します。これらの精度テストを、標準の算術テストと並行して検証テスト計画に含めます。
将来のフォーム管理者向けに計算ロジックを文書化する
実際には、複雑な PDF フォームを継承する人は、計算ロジックを理解する必要があります。各計算フィールドをその式と依存関係とともに文書化します。フィールド名、数式、依存関係をリストした単純なスプレッドシートは、フォームのトラブルシューティングや変更のための計算マップとして機能します。
ドキュメントを PDF の非表示ページとして、またはコンパニオン ファイルとして含めます。変更が必要な場合、管理者はフィールドのプロパティから式をリバースエンジニアリングするのではなく、ドキュメントを参照します。この投資は、元の作成者以外の誰かがフォームを初めて更新するときに報われます。
フォーム計算の検証は、データ収集の品質を保証します。配布前にテストに時間を費やすことで、何百人ものユーザーが計算エラーのあるフォームを送信した後で不正なデータを修正するためにかかる時間のコストが大きくなるのを防ぐことができます。検証されたフォームはユーザーの信頼を呼び起こし、正確なフォーム送信に依存するワークフロー全体でデータの整合性を保護します。
実際には、ここで説明する検証テクニックは、フォームの作成に使用されたツールに関係なく、計算を含むあらゆる PDF フォームに適用されます。体系的なテスト、エッジケースのカバレッジ、フィールド参照検証、およびマルチリーダーテストの原則は普遍的です。これらをフォーム開発プロセスに組み込むと、出荷されるすべてのフォームが正しく計算されます。
検証プロセスは文書化され、再現可能である必要があります。今日検証に合格したフォームは、明日も同じ検証に合格するはずです。文書化されたテスト計画により、フォームの作成者だけでなく、チーム メンバー全員がフォームを検証できるようになります。
ユーザーに届くフォーム計算エラーは、下流システムに波及するデータ品質の問題を引き起こします。提出されたフォームで合計が正しく合計されていない場合は、会計上の不一致となります。検証による予防は、提出後の修正よりもはるかに安価です。
ほとんどのツールにおいて、フォーム検証に費やされる時間は、送信された何百ものフォームから不正なデータを修正するのに必要な時間のほんの一部です。配布前の徹底的な検証パスは、文書作成における品質保証活動の中で最も利益が大きいものの 1 つです。
検証された PDF フォームはユーザーに自信を与えます。ユーザーは、計算が正しく一貫して機能していることを確認すると、フォームを信頼し、正確なデータを送信します。この信頼は、一度確立されると、フォームを発行した組織にまで及びます。