zplCloud Blog
Ein kompletter Label-Workflow an einem Nachmittag, mit Google Spreadsheet als Datenbank
Drucker → Design → Tabelle → Print View. Inklusive des Apps-Skripts, das sich tatsächlich authentifiziert.
Fang mit der Datenquelle an, die du schon hast
Die meisten Label-Projekte scheitern nicht am Drucker und nicht am Design. Sie scheitern an den Daten: Irgendjemand muss die Artikelliste verantworten, und aus „wir binden das ERP an" wird ein Ticket über sechs Wochen.
Also fang mit einer Google-Tabelle an. Sie ist eine echte Datenquelle, jede und jeder im Büro kann sie pflegen, und der Weg von dort zum gedruckten Etikett ist kurz. Wenn die ERP-Anbindung irgendwann steht, ändern sich weder Etikett noch Druckweg - nur die Herkunft der Zeilen.
Das ist die ganze Kette, von vorn bis hinten.
1 - Drucker im Netz und angebunden
Auspacken, Medien einlegen, einschalten, ins Netz bringen, dann per Weblink-Einzeiler oder CLI-Agent mit zplCloud verbinden und ein Druckerprofil anwenden, damit Schwärzung und Geschwindigkeit zum Material passen. Das steht Schritt für Schritt im Speed-Run-Beitrag; rechne mit 10 Minuten.
2 - Etikett entwerfen
Im Designer mit einer Vorlage oder leer starten und die Felder anlegen, die je Etikett wechseln: Artikelnummer, Bezeichnung, Menge, Ziel. Benenne die Bindings exakt wie die Spaltenüberschriften der Tabelle - diese eine Entscheidung erspart später die gesamte Zuordnungsarbeit.
Die Vorschau als PNG, PDF oder SVG prüfen. Sie wird serverseitig von derselben Engine gerendert, die auch das ZPL erzeugt - also keine Annäherung.
Merk dir die Design-ID. Sie hat die Form <name>.<id>, z. B. shipping-label.42; du brauchst sie für die API.
3 - Die Tabelle
Eine Zeile je Etikett, eine Spalte je Binding:
| artikel_nr | name | menge | ziel |
|---|---|---|---|
| 4006381333930 | Kabelbinder 200 mm | 50 | Rampe 4 |
| 4006381333947 | Kabelbinder 300 mm | 25 | Rampe 2 |
Weg A - ohne Code. Zeilen in den Tab Testdaten des Designers oder in einen Batch-Job kopieren und drucken. Für einen wöchentlichen Druck reicht das und braucht keinerlei Einrichtung.
Weg B - Apps Script. Die Tabelle wird zum Auslöser. Gerendert wird über die öffentliche API mit einem API-Key:
// Erweiterungen → Apps Script. Rendert die aktive Zeile und gibt ZPL zurück.
const API_KEY = 'sk_zplcloud_…'; // Tab API in der Plattform
const DESIGN_ID = 'shipping-label.42'; // "<name>.<id>"
function renderActiveRow() {
const sheet = SpreadsheetApp.getActiveSheet();
const header = sheet.getRange(1, 1, 1, sheet.getLastColumn()).getValues()[0];
const row = sheet.getRange(sheet.getActiveCell().getRow(), 1, 1, sheet.getLastColumn()).getValues()[0];
// Der Body ist ein Array von Records: die Keys müssen zu den Bindings des Designs passen.
const record = {};
header.forEach((col, i) => record[col] = row[i]);
const res = UrlFetchApp.fetch(
'https://api.zplcloud.com/v1/zpl/render/design/' + DESIGN_ID,
{
method: 'post',
contentType: 'application/json',
headers: { 'X-API-Key': API_KEY },
payload: JSON.stringify([record]),
muteHttpExceptions: true // sonst wirft ein 4xx, bevor du die Meldung lesen kannst
});
if (res.getResponseCode() !== 200) throw new Error(res.getContentText());
return res.getContentText(); // das ZPL
}
Zwei Grenzen, die die API durchsetzt und die man einplanen sollte:
- 500 Records je Request - größere Läufe in Blöcke teilen.
- 1 MB Request-Body - bei normalen Labeldaten sind das Tausende Zeilen, es greift also zuerst die Record-Grenze.
Mit einem Menü (onOpen → SpreadsheetApp.getUi().createMenu(...)) bekommen die Kolleginnen und Kollegen einen Drucken-Eintrag direkt in der Menüleiste der Tabelle.
4 - Das ZPL zum Drucker bringen
Rendern und Drucken sind bewusst zwei Schritte - du kannst jetzt rendern und später drucken, oder einmal rendern und an drei Standorten drucken.
- Aus der Plattform: Das Design druckt mit einem Klick auf einen Weblink- oder Agent-Drucker, ganz ohne Skript.
- Aus eigenem Code: Das ZPL über den Agent per TCP 9100 an den Drucker schicken oder an CloudToBrowserPrint auf dem Rechner der Bedienung übergeben.
- Für einen Menschen: Skript weglassen und eine Print View geben (nächster Schritt).
5 - Print View für die, die wirklich drucken
Aus dem Design eine Print View erzeugen, menge und ziel editierbar markieren, artikel_nr sperren und die View mit den Tabellendaten oder einem Lookup hinterlegen. URL teilen oder den QR-Code ausdrucken und neben den Drucker kleben.
Die Bedienung öffnet den Link auf dem Handy, scannt den Artikel-Barcode ins Feld, prüft die Live-Vorschau und tippt auf Drucken. Keine App, keine Schulung.
Die ganze Kette
| Schritt | Was | Zeit |
|---|---|---|
| 1 | Drucker + Weblink/Agent + Profil | ~10 min |
| 2 | Design mit Bindings wie die Spalten | ~5 min |
| 3 | Tabelle, optional ein Apps Script | ~5 min |
| 4 | Druckweg (Plattform, API oder Print View) | ~2 min |
| 5 | Bedienung scannt und druckt | Sekunden |
Warum eine Tabelle eine vertretbare Wahl ist
Das ist kein Kompromiss, für den man sich entschuldigen müsste. Eine Tabelle bringt Versionierung, Kommentare, Zugriffsrechte je Person und eine Historie von Haus aus mit, und niemand braucht eine Einführung.
Ihre echten Grenzen sind Nebenläufigkeit und referenzielle Integrität - wenn zwei Leute in einer Schicht dieselbe Zeile bearbeiten, oder wenn die Artikelliste exakt zum ERP passen muss, ist das das Signal, auf den Datenhub zu wechseln und SQL Server oder MongoDB direkt abzufragen.
Die Migration bleibt überschaubar: gleiches Design, gleiche Bindings, gleiche Print View. Nur die Datenquelle wechselt.