additionalCosts in MERGEPORT
Verständnis dynamischer Zusatzkosten und empfohlene Verarbeitung
MERGEPORT
Letztes Update: vor 18 Tagen
Das Feld additionalCosts in MERGEPORT Bestellungen enthält zusätzliche Gebühren, die von der jeweiligen Bestellplattform erhoben werden.
Wichtig:
additionalCosts ist kein fest definiertes Enum.
Die Werte sind freie Textfelder und hängen vollständig vom jeweiligen Anbieter ab (z. B. Wolt, Lieferando, Uber Eats, Foodora).
Das bedeutet:
Beispiele für Werte
Hier sind einige Beispiele für additionalCosts, die bisher beobachtet wurden:
Wichtig:
Diese Liste ist nicht vollständig und sollte nicht als abschließend betrachtet werden.
Warum es keine feste Liste gibt
Jede Plattform definiert ihre eigenen Gebührenstrukturen und Bezeichnungen.
Daher:
Beispiele:
Empfohlene Implementierung
Für eine robuste Integration sollte das Kassensystem oder Backend folgende Punkte berücksichtigen:
1. Bekannte Werte gezielt behandeln
Falls notwendig für UI oder Logik, können bekannte Werte gemappt werden:
2. Unbekannte Werte korrekt verarbeiten
Es darf nicht davon ausgegangen werden, dass alle Werte bekannt sind.
Das System sollte:
3. Leichte Normalisierung anwenden (empfohlen)
Wir empfehlen eine einfache Normalisierungsschicht, z. B.:
Beispiele:
Best Practice
Wichtig:
additionalCosts ist kein fest definiertes Enum.
Die Werte sind freie Textfelder und hängen vollständig vom jeweiligen Anbieter ab (z. B. Wolt, Lieferando, Uber Eats, Foodora).
Das bedeutet:
- Es gibt keine feste Liste möglicher Werte
- Neue Werte können jederzeit auftreten
- Bezeichnungen können sich zwischen Plattformen unterscheiden
Beispiele für Werte
Hier sind einige Beispiele für additionalCosts, die bisher beobachtet wurden:
- Delivery
- Service Fee
- Extra Distance
- Discount Delivery
- Minimum Order Surcharge
- Campaign Surcharge
- Priority Delivery Fee
Wichtig:
Diese Liste ist nicht vollständig und sollte nicht als abschließend betrachtet werden.
Warum es keine feste Liste gibt
Jede Plattform definiert ihre eigenen Gebührenstrukturen und Bezeichnungen.
Daher:
- Kosten unterscheiden sich je nach Anbieter
- Namen können sich ändern
- Gleiche Kostenarten können unterschiedlich benannt sein
Beispiele:
- „Service Fee“ vs. „ServiceCharge“
- „Delivery Fee“ vs. „Delivery“
Empfohlene Implementierung
Für eine robuste Integration sollte das Kassensystem oder Backend folgende Punkte berücksichtigen:
1. Bekannte Werte gezielt behandeln
Falls notwendig für UI oder Logik, können bekannte Werte gemappt werden:
- Delivery → Liefergebühr
- Service Fee → Servicegebühr
2. Unbekannte Werte korrekt verarbeiten
Es darf nicht davon ausgegangen werden, dass alle Werte bekannt sind.
Das System sollte:
- Unbekannte Werte trotzdem anzeigen oder verarbeiten
- Nicht fehlschlagen oder Daten ignorieren
- Diese als generische Zusatzkosten behandeln
3. Leichte Normalisierung anwenden (empfohlen)
Wir empfehlen eine einfache Normalisierungsschicht, z. B.:
- Entfernen von Unterstrichen
- Umwandlung von camelCase in lesbaren Text
- Mapping ähnlicher Begriffe
Beispiele:
- service_fee → Service Fee
- serviceFee → Service Fee
Best Practice
- Keine feste Werteliste hardcoden
- Alle Einträge in additionalCosts verarbeiten
- Implementierung flexibel und zukunftssicher gestalten