Beiträge von vogelbuch

    Der Teufel steckt im Detail und schlaue Kommentare abgeben ist leichter als die Umsetzung, aber ich gebe trotzdem mal meinen Senf dazu.


    Wir haben auch immer wieder das Problem und die Kunden sagen immer wieder, dass sie die abweichende Adresse bereits bei der Bestellung angegeben hätten.


    An dem Punkt bin ich immer noch nicht überzeugt, dass es nicht an der Art des Abrufs bei ebay liegt, dass die Adresse nicht übernommen wird.

    Es ist schon eine halbes Jahr her, dass ich mit der API von ebay gespielt habe, aber es gibt Abrufe, die die Adresse des Kontos melden und andere, die die Adresse der Bestellung melden.


    Vor nachträglichen Änderungen ist man da natürlich nicht sicher.


    Hilfreich und halbwegs automatisch wäre es schick, wenn man vor der tatsächlichen Bearbeitung der Bestellung noch einmal die Lieferanschrift abrufen könnte. Auf den ersten Blick trivial, auf den zweiten müsste da dann aber wohl auch noch mit der Steuer aufgepasst werden, da der Ort der Lieferung entscheidend für den Steuersatz z.B. bei Anwendung des OSS Verfahrens ist.

    In der Dosis finde ich ein bisschen politisieren bzw. über den Tellerrand gucken auch ganz angenehm, ich für meinen Teil begrüsse das.

    Buchempfehlungen in einem Bücherforum sind doch irgendwie auch ein bisschen passend.

    Danke für die Empfehlung, gucke ich mir gerne mal an. Finde ich auch gut, dass ich das gleich bei Buchfreund suchen kann!

    Ohne eine politische Diskussion anstossen zu wollen bin ich überzeugt davon, dass ein Buch über Details von AL dann dazu geführt hätte, dass keiner von beiden Kanzler ist. So traurig das ist, den Kanzler wählen wir ja nicht, den stellt erst mal die Partei mit den meisten Stimmen und da haben unsere beiden Volksparteien Ihre Kandidaten ins Rennen geschickt obwohl die Mitglieder eigentlich schon mehr wissen müssten als wir Wähler. Ich mache mir jetzt erst einmal ein Bier auf...

    Soweit ich das verstehe ist der Börsenverein ein wenig zurückhaltend in der offenen Kommunikation. Deshalb möchte ich hier keine Zahlen nenne. Ich habe per E-Mail auf die Frage geantwortet. Der Beitrag ist umsatzabhängig und liegt für uns im mittleren dreistelligen Bereich. Der Versand ist relativ preiswert, liegt aber deutlich über der BÜWA-Schwelle.

    Ich hatte über einen Großhändler aus einem anderen Wirtschaftszweig vor einigen Jahren DHL Paketmarken

    und da war dann auch das Thema, das der Vertrag mit DHL endet.

    Hamsterkäufe wurden dadurch unterbunden, dass die Bestellmengen durch die historischen Bestellmengen limitiert waren.

    DHL möchte das vermutlich einfach nicht, also würde auch eine kurzfristige Mitgliedschaft vermutlich nicht viel helfen.


    Die Versandsituation finde ich eher ubefriedigend. Zu geringe Marktmacht und zu schlechte Konditionen für die kleinen Teilnehmer.

    Alle wollen Tracking und die Büchersendung mit den langen Laufzeiten führt im Zweifel zu unzufriedenen Kunden.


    Aktuell versenden wir in Deutschland die meisten Dinge mit DPD (DHL wäre mir lieber), aber über den Böresenverein bekommt man hier Sonderkonditionen. Der Haken an der Sache ist die Mitgliedschaft beim Börsenverein (die damit verbundenen Kosten) und die Preise sind eben nur für Deutschland halbwegs interessant. Österreich geht noch einigermaßen, den Rest von Europa kann man - Stand heute - eher vergessen. Für Deutschland ist das für uns im Moment die attraktivste Lösung.

    Das sieht auf den ersten Blick sehr schick aus. Dafür schon mal ein Lob!

    Gibt es bestimmte Punkte auf die man beim Testen achten sollte (veränderte/neue Funktionalität)?

    Hat sich die Daten/Datenbankstruktur irgendwie geändert bzw. werden neue Felder genutzt?

    Ich werde mir die neue Version übers Wochenende genau ansehen.

    Bei der Einbindung der XML-Schnittstelle von whsoft ist mir aufgefallen, dass das Feld RECID bei der Ausgabe aufgeführt wird.

    Das Feld taucht aber nicht bei allen Aufträgen auf und ist - soweit ich das sehe - nie gefüllt.

    Ich vermute, dass das Feld die IDENT aus der Tabelle REC sein sollte. Der Wert ist hilfreich wenn er tatsächlich vorhanden ist.


    Ergänzung: Ich sehe gerade, dass das Feld RECID scheinbar gar nicht ausgegeben wird. Für die Zuordnung wäre es trotzdem ganz praktisch, Entschuldigung für die Verwirrung.


    Darüber hinaus hänge ich gerade daran, dass das Feld Kundennummer nicht über die XML-Schnittstelle verfügbar ist.

    Für die Verarbeitung, z.B. in der Buchhaltung wäre das eine sehr hilfreiche Information.


    Für eine Überprüfung und kurze Info bin ich dankbar.

    Nur noch so als Input / Erfahrungsergänzung. Wir haben ca. 20.000 Bücher bei ebay aktiv.

    Auf Grund der Anzahl haben wir das Premium Abonnement und zahlen dafür natürlich den entsprechenden Preis.

    In den ersten 9 Monaten wurden über ebay 962 Bücher verkauft, die Monatsgebühr macht dabei dann für uns ca. 8% des Umsatzes aus.

    Dazu kommen dann die Kosten für Verkaufsprovision - bei Büchern 11% soweit ich das sehe.

    Insgesamt trägt sich das ganz gut, auch wenn damit fast 20% auf den Umsatz nicht ganz günstig sind.

    Guten Morgen,


    ich habe ein kleines Anliegen welches mir die Arbeit erleichtern würde.

    Wir nutzen die XML-Schnittstelle von whsoft, um Auftragsdaten zu bearbeiten.

    Die Schnittstelle liefert die Mehrwertsteuer der Rechnungspositionen mit.

    Wenn die Lieferung in ein Drittland erfolgt, dann bekomme ich konsequenterweise eine "0" auf Positionsebene.

    Hilfreich wäre zusätzlich das Feld MWST aus der Tabelle BOOK.

    Auch wenn praktisch keine Umsatzsteuer ausgewiesen wird würde mir die Information über die Klasse des Artikels helfen.


    Durch die Umstellung auf OSS wird es darüber hinaus etwas unkommod aus den Zahlenwert zu erkennen, ob es sich um den reduzierten oder den vollen Mehrwertsteuersatz handelt.

    Also wäre auch an der Stelle die Klasse ergänzend zum tatsächlichen Satz hilfreich.


    Vielen Dank

    Zur aktuellen Situation kann ich nichts sagen, aber meine persönliche Erfahrung von vor ein paar Jahren sind ähnlich ansprechend wie Deine.
    Die Kunden bekamen mehr vorbehaltlosen Service, ohne dass das eine Auswirkung auf den Umsatz gehabt hätte.

    Im Moment habe ich keine besonders große Motivation das noch einmal zu machen.

    Sorry, ich hänge immer noch an dem Thema, weil ich der Überzeugung bin, dass hier ein Glitch vorliegt und ich habe eine neue These dazu.

    Ich vermute, dass der Abruf der Aufträge durch wh irgendwie zur Rückgabe von

    'Buyer' => 'BuyerInfo' => 'ShippingAddress'

    führt, z.B. über den Abruf von 'GetItemTransactions' über die eBay-API.

    Ich bekomme hier eine Versandadresse zurückgeliefert, die vermutlich die Standardversandadresse des eBay-Nutzers ist.

    Wenn ich denselben Auftrag über GetOrderTransactions abrufe, dann erhalte ich eine Versandadresse auf Auftragsebene:

    'Order' => 'ShippingAddress',

    was hierarchisch auf den Auftrag bezogen ist.

    Bei einem Auftrag mit offener Zahlung erhalte ich mit GetOrderTransactions noch keine Adresse, mit GetItemTransactions diejenige, die vermutlich beim eBay-Nutzer hinterlegt ist. Nach dem Senden der Zahlungsinformationen bekomme ich auch über die GetOrderTransactions eine Adresse. Das scheint mir auch insofern schlüssig mit der o.g. OrderID 3142900, die als Zahlungsart Banküberweisung hatte, d.h. auf Auftragsebene liegt noch keine Versandadresse vor. Jetzt stelle ich mal die These auf, dass eBay bei dem Abruf nicht zwingend die aktuelle Lieferadresse des Kunden liefert, sondern vielleicht die ursprünglich bei der Erstellung des Kundenkontos verwendete. Ich hoffe, dass das was ich damit hinterfragen möchte nachvollziebar ist.

    VG

    Niko

    Ist es denn möglich, dass bei dem Abruf von whsoft zwei verschiedene Abfragen verwendet werden?

    ebay gibt an, dass die "falsche" Adresse in dem obigen Beispiel keine Lieferanschrift war und die Lieferanschrift auch nicht geändert wurde sondern auch für vorhergehende Bestellungen schon hinterlegt war.

    Vielmehr handelt es sich bei der "falschen" Adresse um die Kontaktadresse des Kunden. Möglicherweise lässt sich ein Teil der "Fehler" durch eine modifizierte Abfrage lösen.


    Die ebay-Artikelnummer ist in der API die orderItemId, das sieht hilfreich aus, danke für den Tip.

    Woran liegt es, dass bei allen anderen Portalen die Originalnummer verwendet wird und bei ebay eine eigene?

    Wir haben etwa 1x pro Quartal das Problem, dass ein Kunde eine vermutlich abweichende Lieferadresse bei ebay angibt.

    Konkret war das (als Bemerkung für wh) die OrderID 3142900.

    Die Lieferung sollte in dem Fall nach Polen gehen, in whbook erscheint im Auftrag eine Adresse in Italien. Wenn ich selbst eine Abfrage über api.ebay.com/ws/api.dll mit GetOrdersRequest mache, dann bekomme ich die Adresse, die auch der Kund erwartet hätte. In der Webübersicht von whsoft unter "Meine eBay - Bestellungen" ist auch die korrekte Adresse angezeigt. Mir ist nicht ganz klar, an welcher Stelle hier ein Fehler passiert. Darüber hinaus ist mir aufgefallen, dass ich in "Meine eBay - Bestellungen" die korrekte ebay-Bestellnummer sehen kann. In whBOOK ist aber - anders als bei den anderen Portalen - eine eigene OrderID hinterlegt, nicht die Bestellnummer von ebay. Kann ich hier irgendwie Rückschlüsse ziehen? Dann könnte ich zumindest die Adressen über eine eigene Abfrage noch einmal prüfen.

    Besten Dank

    Zitat

    Funktioniert whBook mit libreoffice?

    So weit ich das sehe leider im Augenblick nicht. Ein Dokument, dass mit whBook erstellt wurde und gespeichert wurde (z.B. mit Microsoft Word) kann ich zwar mit LibreOffice öffnen, aber das ist ja nicht die Idee. Ich habe bisher noch keinen Weg gefunden das an whBook vorbei umzusetzen. Ehrlicherweise ist das aber auch relativ weit unten auf meiner ToDo Liste. Der Ball liegt denke ich bei whsoft. Im Moment nutzen wir die XML-Daten, um eigene PDF-Rechnungen mit unserem Design zu erstellen. Die werden per Klick als E-Mail an den Drucker verschickt und dann mehr oder weniger direkt gedruckt. Alles etwas holprig aber eigentlich ganz effektiv.