ZUGFeRD Airtableベースからの電子請求書：PDF4meを使用してMakeでJSONを作成し、ハイブリッドPDFをメールで送信する

PDF4meでZUGFeRDの請求書を作成する これは、構造化された請求書データをPDF/A3サイズの電子請求書に変換するMakeモジュールです。Airtableベースをターゲットとして、1行を読み込み、EN 16931 XMLに変換し、読み取り可能かつ機械解析可能なファイルを返して、レコードに戻します。

電子請求書作成ソフトウェアを検索すると、ベンダー比較（プラットフォーム、スイート、ドキュメントごとの価格設定など）が表示されます。Airtableで請求書を作成できるかどうかを検索すると、できないことを説明する長いスレッドが表示されます。この2つの結果の間には、既にAirtableで業務を行っており、請求書を機械可読形式にする必要があると告げられたものの、フォーマット要件を満たすために業務を請求書作成プラットフォームに移行したくないチームがあります。このシナリオは、まさにそのようなチームのためのものです。

なぜ？という問いに対する質疑応答​

得られるもの​

入力： 請求書番号、日付、販売者ブロック、購入者ブロック、1つの明細項目、合計金額を含むAirtableの行で、ステータスは「新規」に設定されている。 出力： その記録にZUGFeRDのPDF/A-3ファイルが添付され、購入者には同じファイルが添付されたメールが送信されます。

請求書1件につき1行。ここにある各列は、シナリオが構築するJSONのキーになります。

購入者は通常の請求書を見るが、購入者のソフトウェアは請求書内のXMLデータを読み取る。

必要なもの​

シナリオの概要​

1. 記録を見る （Airtable）は新しい行を取得します ZUGFeRD Requests。
2. ZUGFeRDの請求書を作成する (PDF4me)はJSONをハイブリッドPDFに変換します。
3. 添付ファイルをアップロードする （Airtable）はそれを Document 同じ行にあるフィールド。
4. 記録を更新する （Airtableは）結果を返信します。
5. メールを送信する （Gmail）は電子請求書を買い手に配信します。

シナリオの概要全体​

スイスのQRコードシナリオと同じ5つのモジュール構成。中央のPDF4meモジュールのみが異なっている。

ステップ1：Airtableの行からシナリオをトリガーするにはどうすればよいですか？​

これまでの流れ： まだ何も起きていない。これが引き金だ。

「準備完了」とマークされた行は、請求書発行の依頼を表します。

1. 追加 エアテーブル > 記録を見る 引き金として。
2. 設定する:
   • ベース: PDF4me Live Automations
   • テーブル: ZUGFeRD Requests
   • トリガーフィールド: Created
   • ラベルフィールド: Title
   • 制限: 10
   • 式: {Status}='New'

ウォッチレコードの設定​

ステータスは切り替えスイッチです。誰かが行を「新規」に設定するまで、何も発行されません。

ステップ2：行をZUGFeRD請求書に変換するにはどうすればよいですか？​

これまでの流れ： Airtableのトリガー。

これは電子請求書を作成するモジュールです。設定によってフォーマットが決定され、JSONデータによって内容が決定されます。

1. 追加 PDF4me > ZUGFeRDの請求書を作成する。
2. 出力の設定:
   • ファイル名: ZUGFeRD_ プラス 請求書番号 プラス .pdf
   • 入力形式: JSON
   • 出力モード: XML With PDF
   • ZUGFeRD バージョン: 2*
   • 適合レベル: EN16931
   • 請求書をPDF形式でレンダリングする: Yes
3. 請求書オブジェクトを貼り付けます の中へ 請求書JSONデータ そして、以下の列をマッピングします。

{
  "InvoiceId": "{{1.InvoiceNumber}}",
  "TypeCode": "380",
  "InvoiceType": "RECHNUNG",
  "IssueDate": "{{formatDate(1.InvoiceDate; "YYYY-MM-DD")}}T00:00:00",
  "DeliveryDate": "{{formatDate(1.InvoiceDate; "YYYY-MM-DD")}}T00:00:00",
  "IsTest": false,
  "Seller": {
    "Name": "{{1.SellerName}}",
    "VatId": "{{1.SellerVATID}}",
    "Address": {
      "Street": "{{1.SellerStreet}}",
      "PostalCode": "{{1.SellerPostalCode}}",
      "City": "{{1.SellerCity}}",
      "Country": "{{1.SellerCountry}}"
    }
  },
  "Buyer": {
    "Name": "{{1.BuyerName}}",
    "Address": {
      "Street": "{{1.BuyerStreet}}",
      "PostalCode": "{{1.BuyerPostalCode}}",
      "City": "{{1.BuyerCity}}",
      "Country": "{{1.BuyerCountry}}"
    }
  },
  "LineItems": [
    {
      "ProductName": "{{1.ItemDescription}}",
      "Quantity": {{1.Quantity}},
      "UnitCode": "C62",
      "UnitPrice": {{1.UnitPrice}},
      "LineTotal": {{parseNumber(1.NetTotal; ".")}}
    }
  ],
  "Totals": {
    "Currency": "{{1.Currency}}",
    "LineTotal": {{parseNumber(1.NetTotal; ".")}},
    "TaxBasisTotal": {{parseNumber(1.NetTotal; ".")}},
    "TaxPercent": {{1.VATRate}},
    "TaxTotal": {{parseNumber(1.VATAmount; ".")}},
    "GrandTotal": {{parseNumber(1.GrossTotal; ".")}},
    "ChargeTotal": 0,
    "AllowanceTotal": 0
  },
  "Payment": {
    "Currency": "{{1.Currency}}",
    "PaymentReference": "{{1.InvoiceNumber}}",
    "DueDate": "{{formatDate(1.DueDate; "YYYY-MM-DD")}}T00:00:00"
  }
}

その物体の3つの部分に注目する価値がある。 TypeCode 380 これは商業請求書のコードであり、基本となるコードから派生したものではなく、固定されています。 UnitCode C62 は「何かの1つ」を表すUN/ECEコードで、時間やサービス単位に使うものです。 Payment 最後のブロックは PaymentReference購入者が支払い時に引用するテキストで、ここでは単に請求書番号です。

ZUGFeRD請求書構成を作成する​

エディタ上ではフィールドがスクロールするため、オブジェクトの一部しか一度に表示されます。上のブロックはオブジェクト全体を表しています。

各設定が決定する内容​

ステップ3：電子請求書を記録に戻すにはどうすればよいですか？​

これまでの流れ： トリガーとPDF4meモジュール。

1. 追加 エアテーブル > 添付ファイルをアップロードする。
2. 設定する:
   • ベース そして テーブルステップ1と同様
   • レコードID: その id トリガーから
   • 添付ファイル欄: Document
   • ファイル: 出力 PDF4me - ZUGFeRDの請求書を作成する
   • ファイル名: ZUGFeRD_ プラス 請求書番号 プラス .pdf
   • データ: その 書類 モジュール2の出力
   • コンテンツタイプ: PDF file

添付ファイルの設定をアップロードします​

コンテンツの種類はPDFファイルです。スイスのQRコード関連シナリオでは、同じスロットにPNG画像を使用しています。

ステップ4：行に結果をどのように記録しますか？​

これまでの流れ： すべて添付ファイルアップロードを通じて行います。

1. 追加 エアテーブル > 記録を更新する。
2. 設定する:
   • ベース そして テーブルステップ1と同様
   • レコードID: その id トリガーから
   • 記録: 書き戻したい内容のみを入力してください。通常はステータスと出力リンクです。

レコード構成を更新する​

テーブルのすべての列がここに表示されます。キャプチャ画像では列が空でパネルがスクロールされているため、ステータスを意図的に設定してください。

ステップ5：電子請求書をバイヤーに送信するにはどうすればよいでしょうか？​

これまでの流れ： 記録更新を通じてすべて。

ベースに保存されている電子請求書は発行されていません。

1. 追加 Gmail > メールを送信する。
2. 設定する:
   • に: その メール トリガーからの列
   • 主題: Your e-invoice プラス 請求書番号
   • 体型: Raw HTML
   • コンテンツ購入者名、請求書番号、合計金額を記載した短いHTML本文
3. 添付ファイルを追加してください：
   • ファイル: その PDF4me - ZUGFeRDの請求書を作成する 出力
   • ファイル名: ZUGFeRD_ プラス 請求書番号 プラス .pdf
   • データ: その 書類 モジュール2の出力

メール設定を送信​

添付ファイルはモジュール2から取得されるため、Airtableはファイルの読み込みを行いません。

シナリオを実行して検証する​

1. 保存 シナリオを作成して、一度実行してください。
2. 行を追加 ZUGFeRD Requests 売り手、買い手、1行の商品、日付とステータスの両方を含む New。
3. 5つのモジュールすべてが、それぞれ1つの操作を報告する必要があります。
4. 行を開く: Document このフィールドには、請求書番号と同じ名前のPDFファイルが格納されている必要があります。
5. 添付ファイルを開いてください。読みやすい請求書ページが表示され、ZUGFeRDバリデーターが同じファイル内にEN 16931 XMLを検出するはずです。
6. 購入者の受信トレイにメッセージとその添付ファイルが届いているか確認してください。

キャプチャされた実行では、行 RE-2026-0009 ベルリンの Muster GmbH (VAT ID DE123456789) からミュンヘンの Test Kunde AG 宛ての請求書が作成され、コンサルティング 10 ユニットが 100.50 で、メールには合計 1195.95 ユーロと記載されていました。

再構築せずに追加できる一般的なバリエーション​

これは、他の電子請求書作成方法と比べてどうなのか​

各行はそれぞれ異なる選択肢を示しています。最後の行はこのシナリオを表しています。

よくある質問​

買掛金自動化とは何ですか？​

受信側では、請求書が届き、入力なしでその項目が読み取られ、数値が確認され、結果が計上されるか承認のために送付されます。ハイブリッド電子請求書は、データがページの画像から復元されるのではなく埋め込まれているため、読み取りステップの信頼性を高めます。

このシナリオは、その取り決めにおける送信側の役割を担っています。購入者のシステムが解析できるファイルを作成することで、購入者の買掛金処理を自動化することが可能になります。

Airtableで請求書を作成できますか？​

規格に準拠していません。Airtableは請求書データを保存し、インターフェースや印刷可能なビューにレイアウトすることはできますが、EN 16931 XMLに準拠したPDF/A-3形式の請求書を作成することはできません。そして、電子請求書の義務化では、まさにそのような形式の請求書の作成が求められているのです。

このシナリオで使用されている分割方法は、実用的なものです。Airtableがレコードとなり、PDF4meが成果物を生成し、その成果物が添付ファイルとしてレコードに戻ってきます。

買掛金自動化はどのように機能するのですか？​

これは、取り込み、抽出、転記の3つの部分から構成されます。取り込みとは、文書を1か所に集めることです。抽出とは、文書をフィールドに変換することです。転記とは、それらのフィールドを台帳に書き込むことです。通常、転記の前には信頼度または承認ゲートが設けられています。

ハイブリッド型電子請求書は、中間部分を省略します。XMLが既にファイル内に含まれている場合、抽出は認識ではなく解析となるため、規制当局は引き続きこの方向へと推進しています。

Airtableの自動化とは何ですか？​

Airtableには、ベース内でトリガーやアクションを実行するための独自の自動化ビルダーが搭載されており、内部処理の大部分はこれでカバーされます。しかし、ドキュメントAPIを呼び出して添付ファイルフィールド用のファイルを返すことはできません。このシナリオでは、まさにその処理が必要なのです。

Makeがその隣に配置されているのはまさにそのためです。トリガーは引き続きAirtableテーブルを監視しますが、シナリオの中間部分では、Airtable独自の自動化機能ではアクセスできないサービスにアクセスできます。

トラブルシューティング​

次のステップ​

委任状は通常、ファイル形式の問題として現れます。つまり、請求書データが既にどこに保存されているのか、そしてそれを読み取れるシステムが存在するのか、という問題なのです。