Eine Wahrheit
Katalogartikel, konkrete Lagerstücke, kanalbezogene Angebote und Aufträge besitzen getrennte Identitäten.
tapinomahub Commerce
Ein eigener, kanalneutraler Vertrag für Katalog, Bestand, Angebote, Aufträge und Rückabwicklung. REST, Katalog-XML und CSV sind drei Darstellungen desselben tapinomahub-Datenmodells.
01 · Eigenständiger Standard
Ein Kanalwechsel darf keine öffentliche API-Umbenennung erzwingen. Deshalb kennt der Commerce Core nur tapinomahub-eigene Objekte und stabile Zustände.
Katalogartikel, konkrete Lagerstücke, kanalbezogene Angebote und Aufträge besitzen getrennte Identitäten.
Kanal- und Dateiformate werden übersetzt, ohne Fremdbegriffe in den öffentlichen Vertrag zu tragen.
Vollständigkeit wird je Verkaufskonto mit Cursor, Ereignisfolge und regelmäßigem Soll-Ist-Abgleich belegt.
02 · Einrichtungsassistent
Eine vorhandene Shopanalyse beschleunigt das Matching, ersetzt aber nie den aktuellen, autorisierten Bestandsabruf.
Diese Auswahl erzeugt nur eine Ablaufvorschau und verändert kein Verkaufskonto.
03 · Initialer Sync
Kein Schreiben vor Simulation und Freigabe. Nach dem ersten Snapshot folgt eine Beobachtungsphase mit automatischem Differenzbericht.
04 · Beteiligung und Preisabsicherung
Die Simulation trennt Listenbeteiligung, Aktionssatz und Preisstrategie. So sieht der Verkäufer vor der Freigabe den erwarteten Erlös.
Beispielrechnung ohne Steuern, Versand und weitere variable Belastungen.
Für exakt gleichen Zielerlös sind bei 8 % Beteiligung rund 8,70 % Aufschlag nötig. Ein pauschaler Aufschlag von 8 % ergäbe 99,36 € und damit 0,64 € weniger. Eine Garantie ist erst möglich, wenn alle variablen Belastungen bekannt sind.
05 · Ein Modell, drei Darstellungen
IDs, Zustände, Geldregeln und Validierungsfehler stammen aus einem gemeinsamen Schema. Übersetzungen laufen als prüfbare Transfers mit Vorschau.
Einzelobjekte, Ereignisse, Aufträge und Statusänderungen mit Idempotenz und Revisionen.
application/jsonVersionierte Voll- und Änderungsübertragung mit Sequenz, Prüfsumme und Importquittung.
application/xmlManifest plus getrennte Tabellen für Artikel, Kennungen, Medien, Bestand und Angebote.
text/csv + manifest06 · Verkaufskanäle
Die Kanalliste wird nicht als Marketingtext festgeschrieben. Das Konto erhält eine aktuelle, geprüfte Fähigkeitsmatrix je Marktbereich.
| Fähigkeit | Nachweis vor Freigabe | Anzeige in der Oberfläche |
|---|---|---|
| Katalog | Snapshot, Delta, Quittung und verlustfreier Roundtrip | je Konto verifiziert |
| Bestand | Aktueller Abruf, atomare Reservierung und Differenztest | je Konto verifiziert |
| Preise | Vorschau, Rundung sowie Brutto-/Netto-Abgleich | je Konto verifiziert |
| Aufträge | Ereignisfolge, Nachladen und Duplikatschutz | je Konto verifiziert |
| Versand | Positionsquittung und Statusabgleich | je Konto verifiziert |
| Storno | Positionsmenge, Quittung und Restmengenabgleich | je Konto verifiziert |
| Retoure | Eingang, Artikelzustand und Auftragsbezug | je Konto verifiziert |
| Erstattung | Geldjournal, Korrektur und Auszahlungsabgleich | je Konto verifiziert |
07 · Produktions-Gates
Die Vorschau beschreibt das Zielbild. Produktive Aktivierung erfolgt erst nach technischen, finanziellen und betrieblichen Abnahmen.
REST, XML und CSV erhalten jedes kanonische Feld; Voll- und Deltaimporte sind wiederholbar.
Ein Verkauf reserviert genau einmal und reduziert betroffene Angebote kanalübergreifend.
Teilstorno, Retoure, Erstattung, Gebührenkorrektur und Rundung sind centgenau getestet.
Ereignislücken, Wiederholungen und Ausfälle erzeugen weder Doppelaufträge noch stille Differenzen.
Shopanalyse, Initialabgleich, Verkauf, Teilstorno, Retoure und Offboarding werden als Ende-zu-Ende-Abnahmeszenarien festgeschrieben.