Quote nicht fristgemäß verschickter Artikel ...

Guten Morgen,

es gibt jetzt leider ein Dilemma. Sehr wahrscheinlich ist es so, dass Käufe via Preisvorschlag jetzt schneller über die API bereitgestellt werden, als es vor dem 15.09.2023 der Fall war. Das ist zum einen gut, weil man die gekauften Artikel schneller von den anderen Marktplätzen bekommt. Zum anderen ist es schlecht, weil die Preisvorschläge eBay-intern wie Auktionen behandelt werden. Der Käufer hat also jede Menge Zeit, seinen Kauf auch wirklich abzuschließen, was technisch gesehen in einem "CheckoutComplete" resultiert.

Die o.g. Beispiele sind also sehr schnell bei uns aufgeschlagen, allerdings mit "CheckoutIncomplete". Eine halbe Stunde später (beim nächsten Rundruf) hat sich der Status dann i.d.R. auf "CheckoutComplete" geändert. Dann waren auch die Versandkosten da. In der Zeit dazwischen hat natürlich der whBOOK Bestellscan zugeschlagen und sich den Auftrag gezogen. Nun liegt aber manchmal auch sehr viel mehr Zeit zwischen den Aufträgen (createdTime: 2023-09-20 04:07:44, paidTime: 2023-09-20 09:17:47). Hier hätte man jetzt ca. 5h warten müssen, bis man die Bestellung an whBOOK weiterleiten dürfte.

Leider lassen sich Transaktionen, die über Preisvorschläge generiert wurden, in den Schnittstellen nicht erkennen. Andernfalls könnte man diese Transaktionen (Ausland ohne VK und Preisvorschlag) entsprechend lange blocken, bis sich der Status auf "CheckoutComplete" geändert hat.

Welchen Tod soll man also sterben? ALLE Aufträge so lange zurückhalten, bis sie auf "CheckoutComplete" sind (mit der großen Gefahr von Doppelverkäufen) oder akzeptieren, dass man ggf. Rechnungen in whBOOK bzgl. der Versandkosten manuell nachjustieren muss?

Gruß,

Stefan

Sobald die Bestellung hier vollständig (mit VK) sichtbar ist, kann man sie gefahrlos in whBOOK einlesen:

Willkommen im Händlerbereich

Hallo,

Zitat von vogelbuch

Welcher Aufruf wird denn von whbook verwendet?

Mit dem Aufruf "GetOrderTransactions" bekomme ich die Versandkosten bei ebay.

Ja, wir nutzen ebenfalls GetOrderTransactions. Allerdings ist es ein Timing-Problem. Bei den o.g. Fällen sind die Versandkosten anfangs einfach leer. Bei späteren Abrufen sind diese dann enthalten. Aber dann ist die Rechnung in whBOOK schon angelegt. Siehe mein Beitrag dazu Quote nicht fristgemäß verschickter Artikel ...

Zitat von vogelbuch

Ich habe das aktuell bei einem Auftrag, der immer noch CheckoutStatus->Status Incomplete ist.

Vielleicht würde der alternative Aufruf auch die Versandadressenproblematik lösen?

Wir haben immer noch vereinzelt den Fall, dass abweichende Lieferadressen nicht übernommen werden und ich habe nach wie vor den Glauben, dass das vermeidbar wäre.

Ja, das ist im Grunde genau dasselbe Problem. Der Kunde kann im Nachgang seine Adressen noch ändern. Tut er das umgehend, ist das auch in whBOOK so drin. Tut er das irgendwann später, ist der Auftrag in whBOOK möglicherweise mit veralteten Daten angelegt.

Ist halt alles sehr eBay-spezifisch. Keine mir bekannte andere Plattform gibt "unfertige" Aufträge heraus, eBay aber leider schon.

Gruß,

Stefan

Guten Morgen,

Zitat von vogelbuch

Ich hätte zwei hemdsärmlige Ansätze zur Diskussion anzubieten.

Unter der Bedingung, dass der obere Wert nicht 'DE' ist (oder was auch immer Site für Deutschland hat) prüfe ich den folgenden Wert:

Code

Order->TransactionArray->ShippingDetails->ShippingServiceOptions->ShippingServicePriority

Der Wert ist '1'.

In dem Array

Code

Order->TransactionArray->ShippingDetails->InternationalShippingServiceOption

wähle ich die passende ShippingServicePriority und habe die Versandkosten.

Ich könnte mir aber vorstellen, dass das fehleranfällig ist, weil ich nicht weiss, ob der Wert eindeutig pro Transaktion ist.

Alles anzeigen

Die Beispiele, die unvollständig hereinkommen, sind alle noch nicht bezahlt. Deswegen gibt es oben erwähnte Felder gar nicht zum Auswerten. Ich beziehe mich auf das Ergebnis von "GetSellerTransactionsRequest/GetSellerTransactionsResponse".

Zitat von vogelbuch

Noch hemdsärmliger, aber möglicherweise hilfreich oder zur Fehlerprüfung des obigen ist die Annahme, dass die Versandkosten der Differenz zwischen Zahlbetrag und Transaktionspreis entsprechen:

Code

WENN
Order->TransactionArray->Transaction->TransactionSiteID != 'DE'
DANN
Order->TransactionArray->Transaction->AmountPaid->content
- Order->TransactionArray->Transaction->ConvertedTransactionPrice->content
= Shipping

Vielleicht hilft das ja zumindest temporär weiter. Ich kann mir vorstellen, dass es im Zweifel erst mal sinnvoll ist wenn der Rechnungsbetrag dem Zahlbetrag entspricht.

Auch dieser Ansatz bringt uns nicht weiter. Denn im ersten Abruf der Bestellung kommt beispielsweise:

<AmountPaid currencyID="EUR">0.0</AmountPaid>
<AdjustmentAmount currencyID="EUR">0.0</AdjustmentAmount>
<ConvertedAdjustmentAmount currencyID="EUR">0.0</ConvertedAdjustmentAmount>
...
<ConvertedAmountPaid currencyID="EUR">0.0</ConvertedAmountPaid>
<ConvertedTransactionPrice currencyID="EUR">25.0</ConvertedTransactionPrice>

Dieselbe Bestellung ca. 1h später:

<AmountPaid currencyID="EUR">32.5</AmountPaid>
<AdjustmentAmount currencyID="EUR">0.0</AdjustmentAmount>
<ConvertedAdjustmentAmount currencyID="EUR">0.0</ConvertedAdjustmentAmount>
...
<ConvertedAmountPaid currencyID="EUR">32.5</ConvertedAmountPaid>
<ConvertedTransactionPrice currencyID="EUR">25.0</ConvertedTransactionPrice>
...
<ShippingServiceSelected>
   <ShippingService>DE_ExpressInternational</ShippingService>
   <ShippingServiceCost currencyID="EUR">7.5</ShippingServiceCost>
   <ShippingPackageInfo>
       <EstimatedDeliveryTimeMin>2023-09-26T22:00:00.000Z</EstimatedDeliveryTimeMin>
       <EstimatedDeliveryTimeMax>2023-09-27T22:00:00.000Z</EstimatedDeliveryTimeMax>
   </ShippingPackageInfo>
</ShippingServiceSelected>

Aber trotzdem Danke für die Ansätze.

Gruß,

Stefan