Airtable Tabanından ZUGFeRD E-Faturası: PDF4me ile Make Kullanarak JSON'u Oluşturun ve Hibrit PDF'i E-posta ile Gönderin

PDF4me Create a ZUGFeRD invoice yapılandırılmış fatura verilerini hibrit PDF/A-3 elektronik faturaya dönüştüren bir Make modülüdür. Airtable tabanına yönlendirilen bu modül, tek bir satırı okur, EN 16931 XML'e dönüştürür, hem okunabilir hem de makine tarafından ayrıştırılabilir bir dosya döndürür ve kayda geri ekler.
E-fatura yazılımı arattığınızda, satıcı karşılaştırması karşınıza çıkar: platformlar, paketler, belge başına fiyatlandırma. Airtable fatura oluşturup oluşturamayacağını arattığınızda ise, oluşturamayacağını açıklayan uzun bir yazı dizisiyle karşılaşırsınız. Bu iki sonuç arasında, zaten Airtable kullanan, faturalarının makine tarafından okunabilir olması gerektiği söylenen ve bir format gereksinimini karşılamak için işlemlerini bir faturalama platformuna taşımak istemeyen bir ekip yer alıyor. Bu senaryo tam da onlar için.
Bir satır, satıcı, alıcı, bir kalem ve toplamları içeren bir Airtable tablosuna kaydedilir. Make bunu alır, sütunlardan kompakt bir JSON nesnesi oluşturur ve PDF4me bunu EN 16931 XML'i içine yerleştirilmiş bir PDF/A-3 dosyasına dönüştürür. Dosya, kayda ek olarak geri gönderilir ve alıcıya e-posta yoluyla gönderilir. Beş modül ve kimse XML yazmıyor.
Neden Odaklı Soru-Cevap
Why run this from Airtable rather than an invoicing product?Çünkü fatura verileri genellikle zaten bir yerde takip edilen çalışmaların bir yan ürünüdür. Eğer proje, müşteri ve kararlaştırılan fiyat bir veri tabanında yer alıyorsa, bu veri tabanı elinizdeki en güvenilir bilgi kaynağıdır. Bunu bir dosya formatına uyması için bir ürüne taşımak, aynı müşteriyi sonsuza dek iki yerde tutmak anlamına gelir.
Why describe the invoice as JSON instead of writing the XML?Çünkü sektörler arası fatura sözdizimi uzun, derinlemesine iç içe geçmiş ve her bir kodun nerede yer aldığı konusunda hoşgörüsüzdür. JSON nesnesi aynı şeyi çok daha az yer kaplayarak, iş terimleri gibi okunan anahtarlarla ifade eder ve PDF4me bundan uyumlu XML'i oluşturur. Yanlış yapılması kolay olan kısım, bakımını yapmadığınız kısımdır.
Why does the hybrid file matter?Çünkü faturanın iki hedef kitlesi var. Alıcının muhasebe sistemi, içine gömülü XML dosyasını okuyarak belgeyi kimsenin manuel olarak girmesine gerek kalmadan kaydeder; ödemelerden sorumlu kişi aynı dosyayı açar ve bir sayfa görür. Tek bir belge her iki tarafı da tatmin eder, bu yüzdenFeRD Formatın arkasındaki Alman forumu, XML'i tek başına belirtmek yerine bu şekilde oluşturdu.
Why attach the result back to the record?Çünkü daha sonra bulamadığınız bir e-fatura, sadece ertelediğiniz bir sorundur. PDF dosyasını ilgili satırdaki Document alanına koymak, belgeyi onu oluşturan verilerle ilişkilendirir; bu da bir alıcının on sekiz ay sonra bir rakama itiraz etmesi durumunda tam olarak istediğiniz şeydir.
Neler Alacaksınız?
Girdi: Fatura numarası, tarihler, satıcı bloğu, alıcı bloğu, bir kalem ve toplamları içeren ve Status "Yeni" olarak ayarlanmış bir Airtable satırı. Çıktı: Bu kayda eklenmiş bir ZUGFeRD PDF/A-3 dosyası ve aynı dosyayı içeren alıcıya gönderilmiş bir e-posta.

Fatura başına bir satır. Buradaki her sütun, senaryonun oluşturduğu JSON'da bir anahtar haline gelir.

Alıcı normal bir fatura görüyor. Yazılımı ise faturanın içindeki XML dosyasını görüyor.
İhtiyacınız Olanlar
- A Make account.Open Make Standart uygulamalar üzerine beş modül.
- PDF4me API key.Get your API key PDF4me bağlantısı bu senaryoyu kapsıyor.
- An Airtable baseYakalanan veri tabanı,
ZUGFeRD Requestsadlı bir tablo içerenPDF4me Live Automationsve bu tabloda fatura başlığı, KDV kimlik numarası da dahil olmak üzere satıcı bloğu, alıcı bloğu, satır öğesi alanları, toplamlar, bir E-posta sütunu, bir Status alanı veDocumentadlı bir ek alanı bulunmaktadır. - A Gmail accountTeslimat için, Make ile bağlantılı.
- Your seller details including a VAT IDBunlar sütunlardan gelir, bu nedenle bir baz birden fazla tüzel kişilik için fatura kesebilir.
Senaryonun Genel Görünümü
- Airtable Watch records,
ZUGFeRD Requestsyeni satırları algılar. - Create a ZUGFeRD invoice (PDF4me), JSON'u hibrit bir PDF'ye dönüştürür.
- Upload an attachment (Airtable), dosyayı aynı satırdaki
Documentalanına ekler. - Update a record (Airtable) sonucu geri yazar.
- E-posta (Gmail) Send an email e-faturayı alıcıya iletir.
Senaryonun tam özeti

İsviçre QR kodundakiyle aynı beş modüllü yapıya sahip. Sadece ortadaki PDF4me modülü farklı.
Adım 1: Airtable satırından bir senaryoyu nasıl tetiklersiniz?
Şu ana kadar olan süreç: henüz hiçbir şey olmadı, bu tetikleyici.
"Hazır" olarak işaretlenmiş satır, fatura düzenleme talebini ifade eder.
- Tetikleyici olarak Airtable > Watch records ekleyin.
- Yapılandır:
- Temel:
PDF4me Live Automations - Masa:
ZUGFeRD Requests - Trigger field:
Created - Label field:
Title - Sınır:
10 - Formül:
{Status}='New'
- Temel:
Watch records yapılandırması

Status, anahtardır. Bir kişi bir satırı "Yeni" olarak ayarlayana kadar hiçbir şey yayınlanmaz.
Adım 2: Bir satırı ZUGFeRD faturasına nasıl dönüştürürsünüz?
Şu ana kadarki akış: Airtable tetikleyicisi.
Bu, elektronik faturayı oluşturan modüldür. Ayarlar formatı belirler; JSON ise içeriği belirler.
- PDF4me ekleyin > Create a ZUGFeRD invoice.
- Çıkışı yapılandırın:
- File Name:
ZUGFeRD_artı InvoiceNumber artı.pdf - Input Format:
JSON - Output Mode:
XML With PDF - ZUGFeRD Version:
2* - Conformance Level:
EN16931 - Render Invoice on PDF:
Yes
- File Name:
- Fatura nesnesini Invoice JSON Data alanına yapıştırın ve sütunları şu şekilde eşleştirin:
{
"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"
}
}
Bu nesnenin üç bölümüne dikkat etmekte fayda var. TypeCode 380, ticari fatura kodudur ve sabittir, temeldeki herhangi bir şeyden türetilmemiştir. UnitCode C62, "bir şeyin bir tanesi" anlamına gelen BM/ECE kodudur ve bu da saatler veya hizmet birimleri için istediğiniz şeydir. Ve sondaki Payment bloğu, alıcının ödeme yaparken belirttiği metin olan PaymentReference taşır; burada bu sadece fatura numarasıdır.
Create a ZUGFeRD invoice

Editörde alan kaydırılabildiği için nesnenin yalnızca bir kısmı aynı anda görünür. Yukarıdaki blok ise nesnenin tamamını göstermektedir.
Her ayarın neye karar verdiği
| Alan | Buradaki değer | Kontrol ettiği şeyler |
|---|---|---|
| Input Format | JSON | Hazır XML veya CSV satırı yerine yapılandırılmış bir nesne sağlamanız gerekiyor. |
| Output Mode | XML With PDF | Tek bir hibrit dosya döndürün. XML Only fatura XML dosyasını tek başına döndürür. |
| ZUGFeRD Version | 2* | EN 16931 ile uyumlu olan 2.x nesli. Eski 1.0 nesli ise uyumlu değil. |
| Conformance Level | EN16931 | Faturanın karşılamayı iddia ettiği profil ve dolayısıyla JSON'un sağlaması gereken anahtarlar. |
| Render Invoice on PDF | Yes | Aynı verilerden okunabilir bir fatura sayfası oluşturun. Temel bir PDF dosyası sağlanmadığı için, dosyanın insan tarafından anlaşılır olmasını sağlayan şey budur. |
| Document | boş | Buraya antetli kağıdınızın yer alacağı temel bir PDF dosyası gelecek. Boş bırakırsanız, PDF4me düz bir sayfa oluşturacaktır. |
Tip.Para ve miktar anahtarlarının tırnak içinde değil, doğrudan rakamlar olarak gelmesi gerekiyor, bu yüzden işlemden geçiyorlar.parseNumber Metin alanları tırnak içine alınırken. Alıntılanan bir metin alanı."1005" sade bir şekilde reddedilecektir1005 Bu kabul edilir ve alacağınız hata mesajı tırnak işaretleri yerine şemadan bahsedecektir. İkinci argümana dikkat edin:parseNumber(1.NetTotal; ".") Ondalık ayırıcıyı nokta Make. Noktayı kaldır ve yazan bir yerel ayar belirt.1005,00 Hata vermektense yanlış sayıya dönüştürülecektir ki bu daha kötü bir sonuçtur.
3. Adım: Elektronik faturayı kayıtlara nasıl geri eklersiniz?
Şu ana kadarki süreç: tetikleyici ve PDF4me modülü.
- Airtable ekle > Upload an attachment.
- Yapılandır:
- Base ve Table: 1. adımda olduğu gibi
- Record ID: Tetikleyiciden gelen
id - Attachment field:
Document - File: PDF4me çıktısı - Create a ZUGFeRD invoice
- File name:
ZUGFeRD_artı InvoiceNumber artı.pdf - Data: 2. modülün Document çıktısı
- Content type:
PDF file
Upload an attachment

Burada Content type PDF file. İsviçre QR kodlu benzer senaryoda ise aynı alanda PNG görseli kullanılmaktadır.
Adım 4: Sonucu satıra nasıl kaydedersiniz?
Şu ana kadarki süreç: her şey dosya yükleme aşamasından itibaren.
- Airtable ekle > Update a record.
- Yapılandır:
- Base ve Table: 1. adımda olduğu gibi
- Record ID: Tetikleyiciden gelen
id - Record: Yalnızca geri yazılmasını istediğiniz bilgileri doldurun; bu genellikle Status ve OutputLink
Update a record

Tablodaki her sütun burada görünür. Ekran görüntüsünde sütunlar boş ve panel kaydırılmış halde gösteriliyor, bu nedenle Status bilerek ayarlayın.
Tip.Eşleştirilmiş ancak boş olan bir alan hücreyi temizler. Fatura tablosunda bu, boş bir KDV numarası veya aksi halde başarılı olarak raporlanan bir çalıştırmada kayıp bir vade tarihi anlamına gelir; bu nedenle kasıtlı olarak yazmadığınız her şeye dokunmayın.
Adım 5: Elektronik faturayı alıcıya nasıl gönderirsiniz?
Şu ana kadarki süreç: kayıt güncellemesine kadar her şey.
Veritabanında bulunan bir elektronik fatura henüz düzenlenmemiştir.
- Gmail ekle > Send an email.
- Yapılandır:
- To: Tetikleyiciden gelen Email sütunu
- Subject:
Your e-invoiceve InvoiceNumber - Body type:
Raw HTML - Content: Alıcının adını, faturayı ve toplam tutarı belirten kısa bir HTML metni.
- Ekteki dosyayı ekleyin:
- File: PDF4me - Create a ZUGFeRD invoice
- File name:
ZUGFeRD_artı InvoiceNumber artı.pdf - Data: 2. modülün Document çıktısı
Send an email

Ek dosya 2. modülden geliyor, bu nedenle Airtable dosyayı hiçbir zaman tekrar okumuyor.
Senaryoyu Çalıştırın ve Doğrulayın
- Senaryoyu Save ve bir kez çalıştırın.
ZUGFeRD Requestssatıcı, alıcı, tek kalem, her iki tarih veNewStatus bir satır ekleyin.- Beş modülün her biri birer işlem bildirmelidir.
- Satırı açın:
Documentalanında fatura numarasıyla adlandırılmış bir PDF dosyası bulunmalıdır. - Ekteki dosyayı açın. Okunabilir bir fatura sayfası görmelisiniz ve ZUGFeRD doğrulayıcısı aynı dosya içinde EN 16931 XML'i bulmalıdır.
- Alıcının gelen kutusunu kontrol ederek mesajı ve ekini inceleyin.
Yakalanan kayıtta, RE-2026-0009 numaralı satırda, Berlin Muster GmbH (KDV numarası DE123456789 Muenchen Test Kunde AG 10 adet 100,50 birimlik Consulting için bir fatura düzenlenmiş ve e-postada toplam 1195,95 EUR tutarında bir ödeme raporlanmıştır.
Do not trust the grid for decimals.Airtable tablosunda VATAmount 191 ve GrossTotal 1196 olarak gösterilirken, fatura ve e-postada sırasıyla 190.95 ve 1195.95 yazıyor. Hiçbir şey yeniden hesaplanmıyor: TaxTotal ve GrandTotal doğrudan bu iki sütundan okunuyor. Tablo, bunları yalnızca sayı alanının ayarlandığı hassasiyette görüntülüyor. Rakamlar yalnızca tutarsız göründüğü için, herhangi birinin bir sütunu bir faturayla karşılaştırmaya çalışmadan önce bu hassasiyeti genişletin.
Yeniden derlemeye gerek kalmadan ekleyebileceğiniz yaygın varyasyonlar
Bu, e-fatura oluşturmanın diğer yöntemleriyle nasıl karşılaştırılır?
Her satır alternatifi açıklıyor. Son satır ise bu senaryoyu gösteriyor.
| Karşılaştırmak | Kim yönetiyor? | Verilerin kaynağı | Bakımını yaptığınız şeyler |
|---|---|---|---|
| E-fatura platformu ile bu senaryo karşılaştırması | Finans, bir portal aracılığıyla | Yüklemeler veya entegrasyon | Belge bazlı bir sözleşme ve ona ilişkin bağlantı |
| ERP modülü ile bu senaryo arasındaki karşılaştırma | ERP sistemi içindeki Finans | ERP'nin kendi defteri | Lisanslar ve verilerinizi aktarmak için bir geçiş işlemi. |
| Geliştirici kütüphanesi ve bu senaryo | Bir uygulama geliştiricisi, uygulama içinde | Veritabanınız, kod aracılığıyla | Kod, şema güncellemeleri ve sürümler |
| Bu senaryo | Airtable satır ekleyebilen herkes | Ekibin halihazırda sahip olduğu temel | Beş modül ve bir JSON nesnesi |
Sıkça sorulan sorular
Borçlar muhasebesi otomasyonu nedir?
Alıcı tarafında bu, bir faturanın gelmesi, alanlarının kimse tarafından girilmeden okunması, rakamların kontrol edilmesi ve sonucun onay için kaydedilmesi veya yönlendirilmesi anlamına gelir. Hibrit e-fatura, okuma adımını güvenilir kılan şeydir, çünkü veriler bir sayfanın resminden alınmak yerine içine yerleştirilir.
Bu senaryo, söz konusu düzenlemenin gönderme tarafını oluşturuyor. Alıcının sisteminin ayrıştırabileceği bir dosya üretmek, onların ödeme işlemlerinin otomatik olarak yürütülmesini sağlıyor.
Airtable fatura oluşturabilir mi?
Uyumlu olmayanlar. Airtable fatura verilerini tutabilir ve bir arayüzde veya yazdırılabilir bir görünümde düzenleyebilir, ancak EN 16931 standardına uygun XML içeren bir PDF/A-3 üretemez ve e-fatura zorunluluğu da bunu gerektirir.
Bu senaryoda kullanılan ayrım pratik bir yaklaşımdır: Airtable kayıttır, PDF4me çıktıyı üretir ve çıktı dosya ek olarak kayda geri döner.
Borçlar muhasebesi otomasyonu nasıl çalışır?
Bu işlem üç aşamadan oluşur: alım, çıkarma ve kayıt. Alım, belgelerin bir araya getirilmesidir; çıkarma, bu belgelerin alanlara dönüştürülmesidir; kayıt ise bu alanların genellikle bir güven veya onay eşiğiyle birlikte deftere yazılmasıdır.
Hibrit e-faturalar, orta aşamayı atlıyor. XML zaten dosyanın içinde olduğunda, çıkarma işlemi tanıma değil, ayrıştırma oluyor; bu nedenle düzenlemeler sürekli olarak bu yönde baskı yapıyor.
Airtable otomasyonu nedir?
Airtable bir temel içinde tetikleyiciler ve eylemler için kendi otomasyon oluşturucusunu sunar ve bu, birçok dahili işlemi kapsar. Ancak, bu senaryonun gerektirdiği adım olan, bir belge API'sini çağırıp ek alanı için bir dosya döndüremez.
Make tam da bu nedenle onun yanında yer alıyor. Tetikleyici hala bir Airtable tablosunu izliyor, ancak senaryonun ortası Airtable kendi otomasyonlarının erişemediği hizmetlere ulaşabiliyor.
Sorun giderme
Modülün giriş paketini çalıştırma geçmişinde açın ve JSON olarak okuyun. Boş bir Airtable sütunu, anahtarı boş bırakır ve tırnak işaretlerini koruyan bir para değeri, sayı beklenirken metin olarak gelir. Her ikisi de düzgün görünen ancak yine de dönüştürmede başarısız olan bir nesne üretir.
Conformance Level profilin hangi alanları gerektirdiğini belirler. JSON dosyasında profilin beklediği anahtarlar eksik olsa bile EN16931 iddiasında bulunmak, dosya normal şekilde açılsa bile doğrulamayı başarısız kılar. Eksik anahtarları sağlayın veya daha düşük bir profile geçin.
Render Invoice on PDF "Hayır" olarak ayarlanmış ve temel bir PDF dosyası sağlanmadığı için XML dosyası hiçbir şey çizilmeden gömülmüştür. Dosya hala geçerli bir e-faturadır, ancak insan tarafından okunacak kısmı boştur.
Output Mode XML With PDF ayarlandığından emin olun, ardından 3 ve 5 numaralı modüllerin verilerini 2 numaralı modülden aldığından emin olun. Başka bir şey eklemek, doğru görünen ancak yazılımlarının okuyamayacağı hiçbir şey içermeyen bir sayfa gönderir.
Sonraki Adımlar
Make programında ZUGFeRD faturası oluşturun.
Format detaylı olarak açıklanmıştır.
API anahtarınızı alın
Genellikle bir dosya formatı sorunu olarak ortaya çıkar. Aslında mesele, fatura verilerinizin nerede saklandığı ve herhangi bir şeyin bu verileri okuyup okuyamayacağıyla ilgilidir.