ECOCARD DATENVORLAGEN V2.0 Alle Daten sind synthetisch. Nicht als Versand- oder Produktionsauftrag verwenden. CSV: UTF-8 mit BOM, Semikolon, CRLF. IDs, Kartennummern und PLZ als Text importieren. 6 fachliche Beispieldateien: Personalisierung, Codes, Carrier, Spieldeck, Nachbestellung und technische Codierung. 42 Felddefinitionen im Datenwoerterbuch. datenschema.json dokumentiert die CSV-Felder; pruefe-daten.py prueft lokal. Aufruf: python pruefe-daten.py ORDNER Optional: --assets DATEIORDNER zur Existenzpruefung der referenzierten Dateien. Foto- und Motivdateien sind nicht enthalten. Ohne --assets keine Dateipruefung. Die Beispiele bilden ein zusammengehoeriges Paket. Vor echten Lieferungen den benoetigten Tabellenumfang und Vertrag abstimmen. Keine Geheimnisse eintragen. Die XLSX-Datei dient der lesbaren Vorbereitung, CSV ist das Austauschformat. Das Datenhandbuch ist A4-Dokumentation; ID-1-Druckdaten bleiben 90 x 58 mm. SHA256SUMS.txt prueft Integritaet, ist aber keine digitale Signatur. Produktivdaten nur ueber den vereinbarten geeigneten Kanal uebermitteln. Kein VS-NfD-Versand ohne vorherige Pruefung der konkreten Freigaben. Kontakt: info@ecocard.de Personalisierung datensatz_id: Stabile, dateiübergreifende Referenz; keine Zeilennummer. name: Freigegebener sichtbarer Name, Unicode unverändert. kartennummer: Sichtbare Nummer als Text; keine automatische Chip-UID. foto_datei: Dateiname ohne Pfad; leer bedeutet bewusst ohne Foto. layout_ref: Freigegebene Kombination aus Motiv und Layoutversion. abteilung: Optionaler Drucktext; Semikolon und Anführungszeichen sind CSV-Testfälle. gueltig_ab: Beginn im ISO-Format JJJJ-MM-TT. gueltig_bis: Ende einschließlich; nicht vor gueltig_ab. QR und Barcode datensatz_id: Stabile, dateiübergreifende Referenz; keine Zeilennummer. code_typ: Vereinbartes Codesystem. code_inhalt: Zu codierender Text; nicht identisch mit dem optionalen Klartext. klartext: Sichtbarer Begleittext, kein Ersatz für Codeprüfung. Carrier und Versandset datensatz_id: Stabile, dateiübergreifende Referenz; keine Zeilennummer. kartennummer: Sichtbare Nummer als Text; keine automatische Chip-UID. traegervariante: Freigegebene Variante inklusive Versionsstand. anrede_demo: Synthetische persönliche Anrede. empfaenger_name: Erfundener Empfänger; niemals als Versandliste einsetzen. strasse: Synthetische Straße mit Hausnummer. plz: Als Text importieren; deutsches Beispiel mit führender Null. ort: Ortsfeld für das vereinbarte Adresslayout. land: Zweistelliger Ländercode; Beispiel DE. versandgruppe: Demo-Markierung verhindert eine Verwechslung mit Versanddaten. Vollständiges Spieldeck decktyp: Referenz des vereinbarten Deckaufbaus. position: Lückenlose Reihenfolge innerhalb des Decks. kartenkennung: Eindeutiges Motiv im Deck. vorderseite_datei: Dateireferenz des Kartenmotivs. rueckseite_datei: Dateireferenz der gemeinsamen Rückseite. exemplare_pro_deck: Anzahl dieses Motivs pro Deck. Nachbestellung abruf_id: Eindeutiger Abruf, nicht erneut mit anderem Inhalt verwenden. auftragsreferenz: Referenz des freigegebenen Ursprungsauftrags. layoutstand: Exakter freigegebener Layoutstand. profilstand: Freigegebene technische Profilreferenz, niemals ein Schlüssel. letzte_kennung: Letzte vergebene sichtbare Nummer als Text. startkennung: Erste neue Nummer, ohne Überschneidung. endkennung: Letzte neue Nummer; einschließlich. neue_menge: Menge = Endkennung - Startkennung + 1. Technische Codierung datensatz_id: Stabile, dateiübergreifende Referenz; keine Zeilennummer. plattform: Logische Plattformreferenz; konkrete Version separat abstimmen. profil_ref: Autorisierter technischer Profilstand, keine Schlüsselbytes. applikation_ref: Opake Referenz zur Anwendungsspezifikation. zielsystem_ref: Testumgebung bzw. vereinbarter Systembezug. datenklasse: Synthetische Beispiele ausschließlich TESTDATEN.