Neues Thema starten

Zahlungsart für real.de

Wir haben gestern real.de eingebunden.


Bei den 3 Einstellungen für die Handhabung der Zahlungsart haben wir uns für "3. "nur 1 ZA für gesamten MP" entschieden.


Nun wurde von Unicorn "Real" angelegt. Wir haben aber bereits auf real.de verkauft, und haben daher sowohl eine Zahlungsart als auch Workflows die auf der bereits vorhandenen Zahlungsart aufbauen.


Nun hatte ich dann die Zahlungsart "Real" gelöscht. Da die Zahlungsarten intern sicherlich auch Nummern haben, wäre die Frage ob ich unsere Zahlungsart "real.de" einfach in "Real" umbenennen und Unicorn nur über den Namen prüft und die Zahlungen dann richtig zuweist oder ob ich die erste "Real" wieder holen muss (ggf. reicht auch neu anlegen?!) und dann unsere Workflows alle anpassen muss.


Frage besteht auch in einem Ticket; aber ggf. weiß im Forum ja schneller eine Antwort.


Ticket: #25856


Wir mappen über den Namen, das heißt wenn du die neue Zahlungsart entfernst (ACHTUNG: die damit importierten Bestellungen haben dann keine Zahlungsart mehr !!), kannst du die alte Zahlungsart von euch in die Schreibweise wie die von unicorn angelegt umbenennen (Achte bitte auf exakte Schreibweise, inkl Groß- Kleinschreibung, Sonderzeichen (ok, die hat real nicht, aber ggf. andere Marktplätze), etc.


Dann müsstest du keine Workflows, etc. anpassen ;-) 




1 Person gefällt dies

@Marc danke!


Dann ist die Schreibweise zwar nicht so, wie ich das gerne hätte. Aber okay. Irgendwas ist ja immer ...


Wenn ich nun Ausschalte das Stornierungen übertragen werden, damit ich die jetzt doppelt importierten Bestellungen in der Wawi stornieren kann, wann kann ich das wieder einschalten, ohne das die - jetzt zum Übergang reingeholten Bestellungen - dann doch storniert werden?

Kurzum: nie!

Denn Storno ist auch in Wawi buchhalterisch falsch.


Bitte mach das nicht, den Storno erkennt unicorn auch nachträglich und überträgt ihn an den Marktplatz, damit läufst du Gefahr das Geld nicht mehr vom Marktplatz zu bekommen UND gleichzeitig die Gefahr falscher Buchführung in Wawi (was im bestem Fall einen Prüfer vom FA nur mal "genauer hinsehen" lässt (aber auch diese Arbeit will man i.d.R. nicht)).


Auftrag sperren.

Hinweis: Doppelter Import durch Softwareumstellung.

Falls du Re schon erzeugt hast, dann eine Re-Korrektur erzeugen.

Dazu ggf. noch Auftrag "ohne Versand abschießen".

Also das ich Aufträge nicht einfach so stornieren darf, wäre mir neu - aber okay.


Auftrag sperren (Unter zurückhallten?) bringt das Problem mit sich, das die Artikel dennoch für den Auftrag geblockt werden. Wäre halt schön, wenn es die Option "nur einlesen wenn nicht bereits versendet" gegeben hätte.


Fakt ist: Ich habe nun Aufträge, die ob gesperrt oder nicht, Artikel blocken obwohl die Aufträge schon längst erledigt und versendet sind. Wenn ich die Aufträge (zu denen es keine Rechnung gibt) stornieren würde, würden die Artikel auch wieder freigegeben werden.

Was soll ich also in dem Fall am besten machen?!



" Auftrag sperren. "

    => sollte kurzfristig bewirken, dass deine Jungs im Lager nicht schon schnell den Auftrag versenden ;-)


" Hinweis: Doppelter Import durch Softwareumstellung. "

    => sollte bewirken, damit du (oder ein Prüfer vom FA) in 3 Jahren noch weißt, wieso da hier gemacht wurde.


" Falls du Re schon erzeugt hast, dann eine Re-Korrektur erzeugen. "

    => ist ja irrelevant, da du schreibst, dass ihr keine RE erzeugt habt, dann den Schritt einfach überspringen


" Dazu ggf. noch Auftrag "ohne Versand abschießen". "

    => sorgt dann dafür, dass geblockter Bestand (von dem du in der letzten Antwort schreibst) wieder freigegeben wird =)




"Wäre halt schön, wenn es die Option "nur einlesen wenn nicht bereits versendet" gegeben hätte."


Im Grunde gibt es das sogar schon =)
Wir lesen nur Bestellungen ein, von denen wir denken, die fehlen in JTL-Wawi (da ja unicorn immer probiert Wawi und Marktplatz "synchron" zu halten).

Bevor wir also einen Auftrag einlesen prüfen wir, ob seine Marktplatz Bestellnummer nicht ggf. schon in Wawi in anderen Aufträgen hinterlegt ist.

Ist das der Fall, dann "verheiratend" wir die Bestellungen nur (also stellen wieder synchronität her, indem wir dann die alten Bestellungen auch "überwachen"), aber legen keine "Dubletten" in Wawi an ;-)

Wichtig ist dafür, dass in den Aufträgen in Wawi das Feld "Externe Bestellnummer" eben mit der externen Bestellnummer (also in diesem Fall der Bestellnummer von real) gefüllt ist. Das ist ja die einzige Nr die wir von real bekommen beim abholen einer Bestellung und nach dieser suchen wir entsprechend in Wawi in diesem Feld.



1 Person gefällt dies

Alles klar.

Ja, die Nummer "gibt es" - nur steht davor halt was: "MT471F4" = bei uns "real.de MT471F4".


Da die folgenden keine Hinweise haben, was sie bedeuten und/oder "anrichten", frag ich dich einfach hier ...

Was passiert bei bzw. wofür ist:


- "Zahlungsart nicht aktualisieren" ?!

- "Bestellhinweis anstatt Anmerkung"

- "Angebotsfeed nutzen" (Wir erstellen keine Artikel. Wenn Artikel XYZ bei real vorhanden ist, dranhängen und gut. Alles andere: nein danke.)


Weil wir uns nur dranhängen läuft auch alles über eine einzige Kategorie bei uns.

" Weil wir uns nur dranhängen läuft auch alles über eine einzige Kategorie bei uns. "


Das ist suboptimal.

Es wäre besser, wenn ihr die Kategorisierung in unicorn richtig macht.

Aktuell geht es so zwar vllt mit einer einzigen Kategorie.

Aber wenn mal in ein paar Jahren ein Mitarbeiter hinzukommt der davon nichts weiß und Artikel für real einstellen möchte, dass ist es nicht ersichtlich, wieso das so nicht klappt (und dann kann sich auch niemand mehr an "wir haben das vor paar Jahren so und so  darum gemacht" erinnern ;-)
Abgesehen davon, gehen wir immer davon aus, dass in Wawi, wie auch unicorn alle Felder korrekt befüllt und eingestellt sind (das heißt vollständig und keine anderen Werte (was man ja manchmal in Wawi sieht, wenn Felder "Zweckentfremdent" werden).

Das ist für eine Software so schlicht nicht nachvollziehbar und kann daher dann "unvorhersehbare" Probleme mit sich bringen.

Besser wäre es daher wirklich, auch dKategoriesierung zumindest einmal sauber in unicorn zu machen.


" - "Zahlungsart nicht aktualisieren" ?! "

Bei real garnichts.

Bei anderen Marktplätzen wo sich nach Bestellung noch die Zahlungsart ändern kann (zB Hood) sagt die Option, ob unicorn solche Änderungen auch an Wawi weiterleiten sollen oder nicht.


" - "Bestellhinweis anstatt Anmerkung" "

Bei real auch hier garnichts, da real keine Bestellhinweise weitergibt (ich bin mir nichtmal sicher, ob der Kunde auf real selbst die Möglichkeit dazu hat). Aber für andere Marktplätze, wo der Kunde einen Hinweis bei der Bestellung aufgeben kann, kannst du über diese Checkbox steuern, ob diese Nachricht als Hinweis oder als Anmerkung im Auftrag auftauchen.


 

" - "Angebotsfeed nutzen" (Wir erstellen keine Artikel. Wenn Artikel XYZ bei real vorhanden ist, dranhängen und gut. Alles andere: nein danke.) "

Das bitte AUF JEDEN FALL aktivieren.

Es geht ja garnicht um das "erstellen" von Artikeln (also Produktdaten), sondern eben um die Angebote. Also das, was ihr bei euch anhängen nennt.

Der ANgebotsfeed ist wichtig, dieser MUSS genutzt werden. Daher auch der Hinweis in der unicorn Oberfläche wenn ihr das nicht aktiviert habt, sowie der Artikel dazu in unserer Dokumentation.

Das ist suboptimal.

Es wäre besser, wenn ihr die Kategorisierung in unicorn richtig macht.

Aktuell geht es so zwar vllt mit einer einzigen Kategorie.

Aber wenn mal in ein paar Jahren ein Mitarbeiter hinzukommt der davon nichts weiß und Artikel für real einstellen möchte, dass ist es nicht ersichtlich, wieso das so nicht klappt (und dann kann sich auch niemand mehr an "wir haben das vor paar Jahren so und so  darum gemacht" erinnern ;-)
Abgesehen davon, gehen wir immer davon aus, dass in Wawi, wie auch unicorn alle Felder korrekt befüllt und eingestellt sind (das heißt vollständig und keine anderen Werte (was man ja manchmal in Wawi sieht, wenn Felder "Zweckentfremdent" werden).

Das ist für eine Software so schlicht nicht nachvollziehbar und kann daher dann "unvorhersehbare" Probleme mit sich bringen.

Besser wäre es daher wirklich, auch dKategoriesierung zumindest einmal sauber in unicorn zu machen.


Wird bei uns nicht passieren - Familienbetrieb; ich verlasse das Unternehmen nur, wenn ich sterbe. Und auch so gibts immer Gespräche, das jeder weiß was wie, warum gemacht wird. Es würde einfach in keinem Verhältnis stehen, wenn wir bei allen Artikeln diese Daten pflegen. Das dauert einfach zu lange. Sind halt "nur" Ladengeschäft. Das dranhängen ist für uns völlig ausreichend.


Ansonsten hast du natürlich (!) Recht und ich bin auch ein Fan davon, Dinge richtig zu machen. Aber auch bei richtig, muss man die Sinnhaftigkeit und das Verhältnis im Hinterkopf behalten.


-----

Bei allem anderen: Danke, danke!

" Ansonsten hast du natürlich (!) Recht und ich bin auch ein Fan davon, Dinge richtig zu machen. Aber auch bei richtig, muss man die Sinnhaftigkeit und das Verhältnis im Hinterkopf behalten. "


Da bin ich vollkommen bei dir! Endlich mal jemand der auch unternehmerisch an die Sache geht und wirklich kalkuliert (gefühlt machen das gerade im Onlinehandel immer weniger).


Ein abschließende Info:


"  wenn wir bei allen Artikeln diese Daten pflegen "


Das ist garnicht nötig und wäre auch wahnsinnige Arbeit.

Bei uns reicht es aus, deine Wawi Kategorien auf ein Pendant von real zu mappen.

Noch konkreter reicht es aus, die Oberkategorien zu mappen (das sollten ja nicht so viele sein, die auf der obersten Ebene), da dies sich (so lange man kein detaillierteres Mapping macht) autom. innerhalb unicorn "nach unten" vererbt (also auf die Unterkategorien und auf deren Unterkategorien und so weiter).

Eben um es so effizient wie möglich zu gestalten ;-)


Wir haben probiert das in diesem Dokuartikel etwas näher zu erklären:  https://portal.marcos-software.de/support/solutions/articles/26000027031-wie-weise-ich-meinen-shopkategorien-in-unicorn-2-portalkategorien-zu-  


Gruß und einen schönen Feierabend, Marc

Anmelden oder Registrieren um einen Kommentar zu veröffentlichen