office-alexander-logistics/doc/KSeF/README.md
2025-07-30 10:12:11 +02:00

52 lines
1.9 KiB
Markdown

# KSeF - Converter
Die Idee ist es auf Basis der KSeF FA(2) XSD-Spezifikation einen Java-Konverter zu entwickeln.
## Strategische Überlegungen:
### **1. Hybride Lösung mit EN 16931 + KSeF**
Ihr Ansatz würde funktionieren:
- **Interne Basis**: EN 16931 XML als Standardformat in Ihrem System
- **Automatische Konvertierung**: Java-Konverter mappt EN 16931 → KSeF FA(2)/FA(3)
- **Zusätzliche Felder**: Polnische Spezialfelder werden über Extension Points in EN 16931 oder separate Datenstrukturen bereitgestellt
### **2. Technische Umsetzung**
```java
// Konzeptioneller Ansatz
public class EN16931ToKSeFConverter {
public FakturaType convert(EN16931Invoice source, KSeFExtensionData extensions) {
// Mapping der Standard-Felder
// + Ergänzung der Polen-spezifischen Daten
}
}
```
### **3. Vorteile dieser Lösung:**
- **EU-Compliance**: Basis bleibt EN 16931-konform
- **Polen-Compliance**: Vollständige KSeF-Unterstützung
- **Flexibilität**: Ein System für verschiedene EU-Länder erweiterbar
- **Wartbarkeit**: Klare Trennung zwischen Standard und nationalen Extensions
### **4. Herausforderungen aus der XSD:**
Basierend auf der bereitgestellten Spezifikation sehe ich:
- **Komplexe Steuer-Klassifikationen** (GTU-Codes, Procedura-Felder)
- **Transport-spezifische Daten** (perfekt für Ihr Logistik-Unternehmen)
- **Währungs-Handling** mit polnischen NBP-Kursen
- **Korrektur-Mechanismen** für Rechnungsänderungen
## **Empfehlung für das Treffen:**
**Präsentieren Sie diese Lösung als "Best of both worlds":**
1. "Wir bleiben EU-Standard-konform mit EN 16931"
2. "Zusätzlich entwickeln wir automatische Konvertierung zu KSeF"
3. "Polen-spezifische Daten kommen aus unserem ERP-System"
4. "Zukunftssicher für weitere EU-Länder"
Das zeigt **technische Kompetenz** und **strategisches Denken** - Sie lösen nicht nur das polnische Problem, sondern schaffen eine skalierbare EU-weite Lösung!