検証する PDF/A で Make

このモジュールの機能

PDF4me検証する PDF/文書 チェックする PDF に準拠する PDF/A （ISO 19005） 読み取り専用: ファイルの修復や書き換えは行いません。生成後、またはアーカイブアップロード前に使用してください。 ゲート コンプライアンスに関するシナリオと、検証が失敗した場合のルーティング、通知、または変換手順との組み合わせ。

関連ブログ記事

この機能に関するブログ記事はまだありません。近日公開予定です。

その間、PDF4me ブログを閲覧して、あらゆるプラットフォームのチュートリアルやワークフローをご覧ください。

ブログをご覧ください →

APIリクエストの認証

毎 PDF4me モジュール Make 有効な 繋がりご希望の接続を作成または選択してください PDF4me API シナリオが安全に検証を呼び出せるように、認証情報を提供します。

Get your API Key

見逃してはならない重要な事実

実際のバイナリコンテンツをマップする

File Content 実際の PDF 前のモジュールからのバイト (例: Data （Dropboxからダウンロード）。メタデータや空のバッファをマッピングすると、チェックが失敗したり、意味をなさなくなったりします。

ファイルとマップ

選ぶ Map ファイル名とコンテンツが動的な前モジュールの出力から取得される場合。常に同じ論理ファイル構造を読み込む場合は、固定ソースモジュール（例：Dropbox）を使用してください。

検証は修復ではない

文書が PDF/A、ルート PDF/A を作成する または、フローを修正してから再度検証し、2回目のチェックなしに変換後に合格と判断しないでください。

典型的なパターン: ダウンロード手順の後、地図 Filename から 1. ファイル名 そして File Content から 1. データ。

主な機能

• ISO 19005準拠のチェック 長期保存ワークフロー向け
• 柔軟な入力以前のDropbox、クラウドストレージ、または HTTP モジュール出力
• Map モード ステップ1で取得した名前とバイナリの動的バンドルについて
• シナリオ対応: 承認または再試行のための検証出力に基づいて分岐します
• ペアになる ZUGFeRD 変換ハイブリッド請求書の後に検証するか、 PDF/創作物

パラメータ

必須： Connection、 Filename、 そして File Content. 設定方法 File 供給される（直接モジュール対 Mapモジュールを保存する前に、）

パラメータ	必須	その機能	マッピング例
Connection	Required	PDF4me API connection for the scenario.	Your PDF4me connection
File	Required	How the PDF is chosen: e.g. Dropbox Download or Map.	Map
Filename	Required	Name of the PDF to process, including its extension.	1. File Name
File Content	Required	Content (binary data) of the PDF to process, from the source module.	1. Data

出力

PDF4me リクエストをバックグラウンドジョブとして処理し、 Make 次のモジュールを実行する前に、結果を待ちます。

分野	タイプ	内容物
pdfA Validator	Text	The PDF/A validation result, including whether the file conforms and any problems found. Branch on it with a filter or router for pass/fail logic.

クイックセットアップ

1. 追加 PDF4me → PDF/A文書を検証する。
2. 選択 Connection （または以下から追加） 追加)
3. 下 File、 選ぶ Map 入力が前のモジュールの出力から来る場合。
4. 地図 Filename 前のステップのファイル名に (例: ファイル名)
5. セット File Content 前のステップのバイナリデータ（多くの場合 データ)
6. 保存 シナリオを実行し、分岐します。 pdfA Validator 合否判定のためのフィルタまたはルーターを使用する。

ワークフローの例

ワークフローの例Opens by default: common Make patterns around PDF/A validation.

Dropboxへの取り込み → 検証 → アーカイブ

1. Dropbox、ファイルのダウンロード 受信用 PDFs。
2. PDF/A文書を検証する と Map: 名前 + Data ダウンロードから。
3. 成功した場合：アーカイブフォルダにアップロードするか、レコードを更新します。
4. 失敗時: ルート PDF/A を作成する または所有者に通知してください。

ZUGFeRD の後またはマージ後

1. 最終的な顧客向けコンテンツを生成またはマージします PDF。
2. 走る PDF/A文書を検証する 出力バッファ上。
3. コンプライアンスログに結果を使用する前に ERP 渡す。

関連モジュール

作成する ZUGFeRD 請求書

ハイブリッド請求書を生成する PDFs次に、アーカイブのコンプライアンスに準拠しているかどうかを出力結果に基づいて検証します。

作成する PDF/A

検証が失敗した場合、またはポリシーで要求された場合は、アーカイブプロファイルに変換します。 PDF/A.

修理PDF

変換前、または2回目の検証を行う前に、構造上の問題を修正してください。

ヘルプが必要な場合

Make + PDF4me HelpAPI Keys