項目の合計、税金の計算、または請求書の合計を自動的に行う入力可能な PDF フォームは、受信者が自分で計算する必要があるドキュメントとは根本的に異なります。自動計算フィールドは、静的なフォームを動作する電卓に変えます。受信者が数量と料金を入力すると、フォームが目の前で合計をリアルタイムで計算します。請求書、発注書、経費報告書、および数値を正しく合計する必要があるフォームの場合、自動計算はユーザーを支援するフォームと余分な作業を生み出すフォームの違いとなります。
PDF の計算はすべての主要な PDF ビューアに組み込まれている JavaScript の簡易バージョンで実行されるため、PDF に計算フィールドを追加するには、JavaScript ベースのフィールド スクリプトをサポートするフォーム エディターが必要です。セットアップには、ユーザーが数値を入力する入力フィールドの作成、結果が表示される出力フィールドの作成、それらをリンクする計算スクリプトの作成の 3 つのステップが含まれます。構成が完了すると、ユーザーが値を変更するたびに計算が自動的に実行されます。保存も更新もボタンのクリックも必要ありません。
PDF フィールド タイプとそれらの連携方法について理解する
計算スクリプトを作成する前に、計算に関与する 3 つのフィールド タイプを理解する必要があります。テキスト フィールドは、ユーザーからの入力を受け入れます。数値のみ、日付のみ、または任意のテキストを受け入れるように構成できます。計算フォームの場合、数値のみのテキスト フィールドが標準の入力タイプです。各フィールドには、計算スクリプトが参照する一意の名前が付いています。 「Item1_Qty」などの一貫した名前付け。 「アイテム1_レート」 「アイテム 1_合計」計算ロジックを読みやすく、保守しやすくします。
ドロップダウン リストとラジオ ボタンも計算に含めることができます。ドロップダウンでユーザーが製品を選択すると、対応する価格がルックアップ テーブルから料金フィールドに自動的に入力されます。チェックボックスでオプション料金の有無を切り替えることができます。重要な概念は、値を持つフィールドはすべて計算の一部にできるということです。スクリプトは各入力フィールドの現在の値を読み取り、計算を実行し、結果を出力フィールドに書き込みます。
通常、出力フィールドは読み取り専用に設定されているため、ユーザーが誤って計算結果を上書きすることはありません。読み取り専用の計算フィールドは、ユーザーが制御する数値とフォームが制御する数値を明確に分離します。この区別はフォームの整合性にとって重要です。ユーザーが合計を編集できる場合、計算は存在しないのと同じことになります。
ステップバイステップ: 簡単な自動計算フォームの作成
まず入力フィールドを作成します。 PDF フォーム エディターで、フォーム フィールド ツールを選択し、ユーザーが入力する必要がある値ごとにテキスト フィールドを配置します。請求書の場合、これは各品目の数量フィールドと単価フィールドになります。各フィールドに明確で一意の名前を付けます。 JavaScript では変数名として参照されるため、フィールド名にはスペースや特殊文字を使用しないでください。代わりにアンダースコアまたはキャメルケースを使用してください: "item1_qty" 「商品 1 個の数量」ではありません。
次に、計算された合計が表示される出力フィールドを作成します。これを論理的な位置 (通常は数値の列の最後または合計セクション) に配置します。フィールドのプロパティでこのフィールドを読み取り専用に設定します。これは重要です。編集可能な計算フィールドは、計算を自動化するという目的全体を台無しにしてしまいます。
次に、出力フィールドの計算プロパティを開きます。 WukongPDF のエディタで合計フィールドを選択し、フィールドのプロパティで [計算] タブを開き、[カスタム計算スクリプト] を選択します。これにより、スクリプト エディターが開き、計算を実行する JavaScript を記述します。単純な品目合計は次のようになります:event.value = this.getField("item1_qty").value * this.getField("item1_rate").value;。 「event.value」フィールドに表示される結果です。 「this.getField()」別のフィールドの現在の値を名前で取得します。複数の計算を連鎖させて合計を求めることができます:event.value = this.getField("line1_total").value + this.getField("line2_total").value + this.getField("line3_total").value;。
スクリプトを作成したら、すぐにテストします。フォームを保存し、PDF ビューアで開き、入力フィールドに数値を入力し、計算フィールドが更新されるのを確認します。 Tab キーを押してフィールド間を移動すると、再計算が開始されます。数値フィールドに文字を入力して、何が起こるかを確認してください。スクリプトは、数値以外の入力を処理するか、適切に無視する必要があります。合計が「NaN」を示す場合は、 (数値ではありません)、入力フィールドの 1 つに数値ではないものが含まれており、スクリプトには検証チェックが必要です。次のようなガード句を追加します。 var qty = Number(this.getField("item1_qty").value) || 0;これにより、フィールド値が数値に変換され、変換が失敗した場合はデフォルトで 0 が設定され、NaN が計算中にカスケードされるのを防ぎます。
エッジ ケースの処理: 空のフィールド、負の数、ゼロによる除算
テスト データでは完璧に動作する計算スクリプトでも、実際のユーザーがフォームに入力すると、恥ずかしい形で失敗する可能性があります。最も一般的な失敗は、フィールドが空であることです。ユーザーがフィールドに何も入力していない場合、その値はゼロではなく空の文字列になります。空の文字列に数値を乗算すると NaN が生成され、その結果に依存するすべての計算に反映されます。
修正方法は、すべての入力値が空の場合にゼロに正規化することです。各計算スクリプトの先頭で、各フィールド値を取得して変換します。 var qty = this.getField("qty").value; if (数量 === "" || isNaN(数量)) 数量 = 0;このパターンは、すべての入力フィールドに一貫して適用されるため、空フィールドの問題が解消されます。また、ユーザーが誤って数値フィールドに文字を入力した場合、NaN が生成される場合にも対応します。
負の数にはポリシーの決定が必要です。フォームでは負の数値を受け入れる必要がありますか?ほとんどのビジネス フォームでは、答えは「いいえ」であり、計算スクリプトでは if (qty < 0) qty = 0; を強制する必要があります。ゼロによる除算は、パーセンテージとレートの計算に現れる微妙な問題です。分母として機能するフィールドがゼロになる可能性がある場合、スクリプトは分割する前に次のようにチェックする必要があります。 if (denominator !== 0) { result = numerator / denominator; } else { 結果 = 0; }。これらのガード句により、数行のコードが追加され、フォームがユーザーにわかりにくいエラー値を表示するのを防ぎます。
高度な計算: 条件付きロジックとルックアップ テーブル
基本的な算術演算では、明細項目の合計と総計を処理します。より洗練されたフォームには、ユーザーの選択に基づいて変更される条件付き計算が必要です。一般的な例は、選択した州または地方によって税率が異なる税金の計算です。計算スクリプトはドロップダウン フィールドの値を読み取り、対応するレートを適用します。 var state = this.getField("state").value; var レート = 0; if (状態 === "CA") レート = 0.0725; else if (state === "NY") rate = 0.04;イベント.値 = 小計 * レート;
多くのオプションを備えた大規模なルックアップ テーブルの場合、if-else 条件のチェーンよりも switch ステートメントまたはルックアップ オブジェクトの方がクリーンです。 var rate = { "CA": 0.0725、"NY": 0.04、"TX": 0.0625、"FL": 0.06 }; var rate = レート[状態] || 0;このパターンは、読み取れなくなることなく、数十のエントリに拡張できます。 || によって提供されるデフォルト値のゼロ。演算子は、ルックアップ テーブルにない状態を適切に処理します。
割引層は、もう 1 つの一般的な条件付き使用例です。小計がしきい値を超えた場合は、パーセント割引を適用します。 vardiscount = 0; if (小計 > 1000) 割引 = 小計 * 0.10; else if (小計 > 500) 割引 = 小計 * 0.05;イベント.値 = 小計 - 割引 + 税金;。計算はフィールドが変更されるたびに実行されるため、ユーザーが項目を追加または削除すると、割引も自動的に更新されます。ユーザーは価格の調整をリアルタイムで確認できます。これはまさに、記入可能な PDF フォームを紙ではなくアプリケーションのように感じるインタラクティブなエクスペリエンスです。
計算フォームを送信する前にテストする
テストされていない計算フォームは、間違った数値を生成するフォームです。系統的なテストでは、クライアントや顧客に届く前にエラーを検出します。まず通常の値でテストします。頭の中で計算できる数値を入力し、出力が一致することを確認します。次に、エッジ ケースをテストします。フィールドを空のままにし、ゼロを入力し、ビジネス ルールで拒否される場合は負の数値を入力し、オーバーフローをチェックするために非常に大きな数値を入力し、数値フィールドにテキストを入力します。
複数の PDF ビューアでテストします。 Adobe Acrobat で正しく計算されるフォームは、Mac のプレビュー、Web ブラウザーの組み込み PDF ビューア、またはモバイル PDF アプリでは動作が異なる場合があります。各ビューアは JavaScript エンジンの実装方法が若干異なります。一部のモバイル ビューアは PDF JavaScript をまったくサポートしておらず、計算機能なしでフォーム フィールドを表示します。視聴者にモバイル ユーザーが含まれている場合は、計算にデスクトップ PDF ビューアが必要であることをフォームに注記するか、フォールバックとして事前に計算された参照テーブルを提供します。
最後に、ユーザーのワークフローを最初から最後までテストします。あなたが受信者であるかのようにフォームを開きます。実際のユーザーが行う順序で入力してください。保存してください。保存したコピーを再度開き、計算が依然として正しいことを確認します。それを印刷し、計算された値が紙に表示されていることを確認します。画面上では正しく見えるフォームでも、空白の計算フィールドが印刷されるというエラー モードは、プリント エンジンがフィールド値を画面レンダラーとは異なる方法で処理することが原因で発生する、驚くほど一般的な障害モードです。徹底したテストに費やした 1 時間は、500 人の顧客に合計金額の計算を誤った請求書を送信した場合の損害に比べれば、取るに足らないものです。
スプレッドシートがより良いツールである場合
PDF フォームの計算は強力ですが、スプレッドシートをより適切な選択肢とする制限があります。 PDF 計算では外部データ ソースを参照できません。ライブ為替レート、株価、データベース値を取得することはできません。目標探索関数やソルバー関数などの反復計算を実行することはできません。入力されたデータからグラフやピボット テーブルを生成することはできません。フォームにこれらの機能のいずれかが必要な場合は、PDF 内でスプレッドシートの機能を複製するのではなく、Excel または Google スプレッドシートで計算ロジックを作成し、結果を PDF にエクスポートします。
PDF 計算は、計算が簡単で入力が制限されているフォーム、つまり、固定項目を含む請求書、既知の製品価格を含む注文フォーム、事前定義されたカテゴリを含む経費報告書、および標準の時給を含むタイムシートに最適です。フォームの機能は 1 つであり、それを確実に実行するため、受信者は使用するためのトレーニングを必要としません。 WukongPDF の PDF Editor は、フォーム フィールドの作成と JavaScript 計算サポートを単一のブラウザ ベースのツールで組み合わせて、このスイート スポットをうまく処理します。適切な使用例では、適切に構築された PDF 計算フォームにより、数学エラーに関するフォローアップ メールが不要になり、処理時間が短縮され、別個の計算機を伴う静的フォームよりもプロフェッショナルなエクスペリエンスが提供されます。