REST API / Python3 / EXCEL - Rechnungsexport

Hallo liebe Community,

hat einer von euch schon Erfahrungen mit der REST API (api.php/v2/orders) gemacht?
Evtl. in Verbindung mit Excel oder Python3 Skript?

Ich würde mir gerne alle Rechnungen aus meinem Shop exportieren.
Entweder direkt nach Excel (ja.. ist kein Wawi...) oder via Python3 Skript -> CSV (und dann nach Excel)

Vielen Dank und Grüße
Cedric

p.s.: Beim einfachsten Python Skript aus dem Beispiel bekomme ich nämlich folgenden Output:

Code:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
</p>
<hr>
<address>Apache Server at xxx Port 443</address>
</body></html>

 

... per ODBC-Treiber direkt und dynamisch in Excel ...

 

Keine gute Idee, kriegst weniger Informationen als per API. Ein Teil der Daten wird dynamisch erzeugt, den gibts nie in der Datenbank. Das selber erzeugen ist 3x komplizierter als über die API zu gehen.

 

Also für den Rechnungsexport sind alle Daten drin wenn ich mich richtig erinnere, ggf. auch mit Verknüpfung mehrerer Tabellen ...

... und ja, ich finde diese Möglichkeit wirklich ideal, schnell und einfach.

 

@Wilken (Gambio)

... aber wenn Du mir erklärst wie ich via API den Gambio-Shop abfrage und die Daten in Excel visualisiere, will ich das gerne einmal testen ...

 

Ich auch


Schau mir aber auch mal ODBC an... also direkt auf die Datenbank via SQL?


Bei einer Realisierung über Python habe ich mir vorgestellt, über einen wöchentlichen Cronjob, mir jeweils eine CSV für eine gesamte Woche abzulegen. Die müsste dann nur in irgendeine (bestehende) Auswertung importiert werden.

 

Nur mal ein Beispiel:
Für PayPal Transaktionen speichern wir im Shop nur und ausschliesslich die Payment ID. Viele Leute wollen weil sie mit an der Stelle historischer Sofftware hintendran arbeiten die Transaktions IDs haben. Die gibts nicht in der Datenbank, die ist nicht da. Fragst du den Shop aber per API ab, besorgt dir die API die Daten in dem Moment von PayPal, also kannst du die darüber haben.

Probier mal aus, im Browser:

https://www.[deinshop].de/api/v2/orders/[order id]/payment_details/

Benutzername und Passwort sind die Logindaten eines Shop Admins.

Dokumentiert hier:
https://developers.gambio.de/docs/3...i/reference/orders/get-order-payment-details/

Ein weiteres Problem von ODBC:

Wenn darüber auch Daten in den Shop geschrieben werden, triggern alle möglichen Folgeprozesse nicht. Beispiel: Du hast eine Bestellung versendet und schreibst per ODBC eine Tracking ID in die Datenbank. Da kriegt kein Kunde eine Mail, da wird auch keinem Paymentanbieter der Versand gemeldet. Geht nur per API.

 

Okay, PayPal und Payment IDs interessieren mich nicht die Bohne ...
... die Anforderung war auch nur "RECHNUNGSEXPORT" und das ist via ODBC doch nur Kindergeburtstag.

Da gebe ich Dir recht, aber ich wiederhole mich gerne zum 357st. mal:
MEINE ODBC-TREIBER SIND AUSSCHLIESSLICH LESEND EINGESTELLT.


Dazu kommen alle anderen Gambio-Tabellen die ich LESEND AUSWERTE ...

• Offene Warenkörbe
• Kundenstatistik (wie oft war der Kunde im Shop, wie oft hat er gekauft, wann zum 1. mal, wann zum letzenmal usw. usf.
• Übernahme der Kundendaten und Newsletteranmeldungen mit 8 Klicks in mein eigenes Newsletterprogramm ((Link nur für registrierte Nutzer sichtbar.)) inkl. Sprachcodes (kann Mailbeez noch nicht)
• Übernahme der E-Mails aus den letzten Bestellungen direkt in TRUSTPILOT und E-Mail Versand zur Transaktionsbewertung (dauert keine 3 Minuten)
• usw. usw.

Das alles "on the fly", direkt in eine Software die ich recht gut beherrsche, mit Verknüpfungsmöglichkeiten zu den Tabellen meiner Wawi, da bleibt keine Auge trocken und kein Wunsch offen.

Das soll aber jeder für sich selbst entscheiden ...
... allerdings wenn ich hier lese, wie oft nach CSV-Exporten irgendwelcher Daten aus irgendwelchen Tabellen gefragt wird, die dann mühselig weiterverarbeitet werden und das im schlimmsten Fall auch noch einmal in der Woche ...
... dann muss ich immer leise schmunzeln und bin froh das ich mir das nicht antun muss.

Aber wie ich schon oben geschrieben habe, jeder wie er will.

jm2c

 

Meine Empfehlung: mach' es mit ODBC !
NUR EIN EINZIGES MAL die Auswertung so anlegen wie Du sie haben willst.
Danach einfach nur Excel starten, aktualisieren klicken und auswerten was Du willst ...

... automatisch mit Kreisdiagramm o.ä. und jedem anderen SchnickSchnack den Excel so bietet.
Ziemlich simpel

 

Historische Software ? Datev arbeitet bei der Zuordnung von Paypal-Zahlungen an Buchungen mit der Transaktions-ID.
Wenn die Trx-ID NICHT bei der Bestellung gespeichert wird, dann ist dies aber ein ganz schöner Rückschritt. Die Transaktions-ID steht zum Zeitpunkt der Zahlung zur Verfügung und identifiziert die Zahlung eindeutig. Wieso wird diese dann nicht auch gleich mit der Bestellung zusammen gespeichert ? Verstehe ich nicht.

Gruß, Dirk

 

Funny... Irgendwie gibt es immer wieder Themen, die sich flott von der eigentlichen Frage wegbewegen ohne irgendwas sinnvolles zur Frage mitzuteilen... Vielleicht sollte eine Untergruppe "Disputes" eröffnet werden, wo man sowas dann hin verschieben kann???

Wenn ich es richtig sehe, war die Frage:

So:
Guyonthecouch
Kannst Du mal das Script posten mit dem Du den Aufruf versucht hast? Da scheint was nicht richtig zu sein, sonst käme eine andere Antwort vom Shop über die API.
Nachdem ich mich gerade ohnehin Step by Step in die API einarbeite, kann ich da vielleicht weiterhelfen.
Tipp: Die API Dokumentation ist leider nicht immer ganz korrekt was den Syntax angeht, da muss man mit ein wenig Try-and-error arbeiten...
Ich bin jetzt leider nicht firm in Python und werde die API Anbindung über Filemaker (Datenbank) realisieren, da die API Aufrufe da sehr simpel funktionieren und die Serverantworten (die ja im JSON Format kommen) mit Filemaker ganz einfach ausgewertet werden können (FileMaker unterstützt das JSON Format). Aber am Ende dürfte das Grundprozedere das selbe sein.

 

Die typischen Leiden eines Forums. Jörg hat die Frage unsachgemäß beantwortet, es ging mir darum das mal eben zu fangen. Das hat diesen Thread natürlich auf den Scheiterhaufen geführt, dafür meine kurze Entschuldigung. Jetzt müssen wir das trotzdem mal eben zu Ende machen:

Falsch. Stimmt nicht.

Wir wollen mittelfristig niemanden mehr haben, der direkt in unserer Datenbank herumhühnert. Der Grund ist, dass wir keinerlei Stabilität für Tabellen mehr garantieren wollen, 0. Es gibt einige Dinge die in der Datenbank superblöde gespeichert sind, damit kaum erweiterbar und sind auch nicht optimierbar, solange wir um Nerven zu schonen alles grob gleich lassen. Wir wollen das nicht länger als nötig. Wir haben darum Abstraktionen gebaut, wie die REST-API, die stabile Interfaces auf die Daten bieten. Wem ein abstraktes Interface fehlt kann uns fragen, dann reden wir drüber und versuchen das zu beherzigen, das klappt oft.

Andersrum gilt in Richtung auf Hoster:
Wer seine Datenbank überhaupt nach aussen öffnet wird von uns immer wieder erinnert werden so einen Unsinn einzustellen. Das ist gar nicht mal so perfekt sicher in 99% der Fälle.

In Bezug auf Partnerkandidaten:
Wer direkt auf der Datenbank herumhühnert und keinen guten Grund hat das zu tun den wir verstehen oder noch nicht beseitigt haben, kann kein Partner werden bis er das beseitigt hat.

In Bezug auf bestehende Partner:
Wir werden alle aktiv und wirkungsvoll treiben sich da zu ändern.

In Bezug auf Händler:
Es wird immer wieder kaputtgehen. Wir werden uns mit Doku und Vorankündigungen zu Datenbankänderungen gezielt zurückhalten. Wir haben da viele unnötige Dauersupportfälle und grosse Unfälle. Die Gesamtbilanz ist negativ.

Der Pfad den wir wollen muss klar sein: Wir wollen alle daraus haben, alle.

Das ist kein Rückschritt, das ist eher unverstandener Fortschritt. Früher mal, grob bis 2012 herum, war eine Transaktions ID die höchste Ordnung eines Zahlungsvorgangs bei PayPal. Dann hat PayPal sich aber verändert und eine Ordnung oberhalb der Transaktionen eingeführt, eine Zahlungsvorgangs ID. Der Hintergrund ist simpel und mit einem Beispiel schnell erklärbar:

Kunde A kauft 6 paar Socken und zahlt Händler dafür 60 Euro per PayPal. Dann ruft er an und bestellt noch 1 paar karierte Socken nach, dafür kriegt der Händler nochmal 10 Euro. Die Ware geht zum Kunden, der retourniert 2 paar Socken für 20 Euro weil Sie ihm nicht gefallen, es gehen 20 Euro zurück. Das sind 3 Transaktionen, sie gehören aber alle zu einem einzigen Vorgang. Als diesen einen einzigen Vorgang speichert PayPal seitdem die Daten bei sich. Das spiegelt sich auch ganz massiv in den seit 2012 aktuellen APIs wieder, nur die alten APIs die auslaufen haben das nie gelernt. Dasselbe Thema gilt auch zum Beispiel bei Abonnementzahlungen, wo die wiederkehreden Zahlungen dann alle in einem Vorgang sind usw...

Das bedeutet Datev ist da historisch, die sind da wie noch einige andere in 2012 stehengeblieben. Wenn man im Shop eine Bestellung mit PayPal ansieht sendet der Shop nun die Zahlungsvorgangs ID in dem Moment an PayPal und ruft live die darunterliegenden Daten ab. Man sieht so im Shop nie einen historischen Zustand der Zahlung, sondern immer den aktuellen. Bei API-Zugriffen macht der Shop genau dasselbe. DIe Transaktions ID hat für uns damit letzlich Nullwert. Wir speichern auch keinen Schnappschuss einer Zahlungsvorgangsstruktur, weil der mit guter Wahrscheinlichkeit wenn der nächste ihn lesen will keine Gültigkeit mehr hat. Irgendwann werden Datev und die anderen Quasibehörden auch auf die neueren Formate springen müssen, wenn die alten PayPal APIs endgültig weg sind.

Wer weitere Fragen zu einem der beiden Thema hat kann gern fragen, dann aber besser in eigenen Threads.

Und jetzt zurück zum Thema des Fragestellers...

 

Was spricht denn gegen einen LESENDEN ZUGRIFF ?
Der Sicherheitsaspekt ist relvant, keine Frage, aber sonst ?

 

Ich hab den Eindruck du hast nur oberflächlich gelesen. Denn du hast das hier misachtet:

Markus hatte da schon recht mit seinem Einwurf zum Themenfokus. Und du hast auch die Antwort nicht gelesen, die steht da im Grunde in meinem schon drin. Frag in einem eigenem Thread wenn dus trotzdem nicht findest.

 

Gut, nehme ich ...

... nehme ich nicht !

Im Threattitel steht "...Rechnungsexport", in der Frage selbst mehrfach EXCEL und auch "... direkt nach Excel".

Diese Frage habe ich sachgemäß beantwortet, einfache und schnelle DB-Abfrage mit lesendem ODBC-Treiber.
Ist in 5 Minuten fertig, ohne weitere Exporte, Importe und CSV-Dateien.
Einfach, schnell, gut.

Ich persönlich finde meine Antwort noch immer sachgerecht und der Frage angemessen.
Du hast hast daraus einen philosophischen Epos gemacht, sorry.

Wie auch immer, Thema (für mich) erledigt.

 

Könntest du mir mal einen "Beispielcode" für deine ODBC zeigen?

Aber gerne doch.

Code:

import http.client
conn = http.client.HTTPSConnection("shop.mps-elektro.com")


#authorization: xxxx       (base64 codierung)

headers = {
'content-type': "application/json",
'authorization': "Basic xxxxx"
}
conn.request("GET", "shop.mps-elektro.com/api.php/v2/orders?per_page=50", headers=headers)

res = conn.getresponse()

data = res.read()
print(data.decode("utf-8"))

 

Da gibt es keinen Beispielcode ...
... Du installierst den passenden ODBC-Treiber (mySQL irgendwas), richtest darin die Verbindung ein und fertig.
Es gibt hier einige Anleitungen dazu ...

 

Anschließend EXCEL starten ...

[DATEN] - [AUS ANDEREN QUELLEN] - [AUS MICROSOFT QUERY]




... wählst die Datenquelle die Du kurz vorher angelegt hast (in meinem Fall "Dilyanas")




... und schon bist Du mit der DB verbunden, suchst dort die passende(n) Tabelle(n) und alles ist gut ...

 

Nochmals: Diese Form der ODBC verbindungen sind ausdrücklichst nicht empfohlen. A aus Sicherheitsgründen, B weil man die Datenbank verstehen muss, und das schaffen die meisten nicht.

Beispiel hier am Fall: In der Orders Tabelle gibt es eine Spalte mit Rechnungs IDs. Die ist nicht nur nicht maßgeblich, die ist oft falsch!!! Man muss da die 1:n Beziehung von Bestellungen zu Rechnungen durch das joinen anderer Tabellen auflösen, und dafür ist ein zweidimensionales Excel reichlich unpraktisch, sonst kriegt man nur Datenmüll.

Besser: API. Tausend mal besser.

Repariertes Python Beispiel anbei, gegen den Demoshop 1, läuft exakt so bei mir. Wichtig: Das ist so für Python3 geschrieben, Python2 mag das so nicht.

Code:

import http.client
import base64

conn = http.client.HTTPSConnection("www.gambio-shop.de")

userAndPass = base64.b64encode(b"admin@shop.de:12345").decode("ascii")

headers = {
'content-type': "application/json",
'Authorization' : 'Basic %s' %  userAndPass
}

conn.request("GET", "/shop1/api.php/v2/orders?per_page=50", headers=headers)

res = conn.getresponse()

data = res.read()
print(data.decode("utf-8"))

 

An alle die mir den Weg über ODBC präsentiert haben, danke!
Falls ich mit Python nicht weiterkomme, versuche ich es über diesen Weg.
Allerdings ist für mich der direkte Zugriff auf die Datenbank nur die letzte Möglichkeit.

@Wilken (Gambio)
Der Code funktioniert jetzt, danke. (Hinweis: Ich bin noch am Anfang was Python angeht)
Ich versuche nun über ein Pandas Objekt die Daten zu laden und dann irgendwann in ein CSV zu schreiben.
Allerdings wird die json Daten nicht richtig geladen. Hast du Pandas schon mal benutzt oder wie würdest du es machen, sodass am Ende eine CSV mit allen Spalten rauskommt? (evtl. doch über import json, import csv?)

Hier noch der Code.

Code:

import http.client
import base64
import json
from pandas import DataFrame

conn = http.client.HTTPSConnection("www.gambio-shop.de")
UserAndPass = base64.b64encode(b"admin@shop.de:12345").decode("ascii")

headers = {
'content-type': "application/json",
'Authorization': 'Basic %s' % UserAndPass
}

conn.request("GET", "/shop1/api.php/v2/orders?per_page=50", headers=headers)

res = conn.getresponse()
raw_data = res.read()
jdata = json.loads(raw_data)
result = DataFrame(jdata)

result output sieht wie folgt aus:



p.s.: Was mir auffällt, dass .decode('utf-8') nicht das gewünschte Ergebnis bringt. Ich habe noch immer keine Umlaute :/ (ist jetzt nicht im code-beispiel enthalten)