Hallo, im Editor zeigt er mir, wie von Dir beschrieben alles korrekt an, also mit den Spaltentrennern ;; Aber in OpenOffice (was ich immer zum Bearbeiten von CSVs benutze lässt er die Spalten nicht leer, sondern füllt sie mit dem nächsten Wert !?! Werde das mit str_replace mal versuchen. Vielen Dank schonmal dafür Aktuell verzweifel ich an einer Schleife bzw. einem array. Bei Deinem ersten Aufruf der Api über curl kann man ihm noch sagen , was er aus der DB suchen soll ! Also z.b. nur die ID der Bestellung (select 'id' anstatt select *) was sicherlich bei mehreren Abfragen am Ende performanter laufen sollte. PHP: CURLOPT_URL => $domain ."api.php/v2/orders/search?fields=id", Ich muss ja dann im zweiten Aufruf der API mittels der id's die auf die Bedingungen der ersten Abfrage passten die Bestellungen raussuchen. PHP: CURLOPT_URL => $domain . 'api.php/v2/orders/' . $v['id'] . '?fields=items', Nun haben wir das Problem, dass wir mehrere Zulieferer haben, die das für uns (dropshipping) versenden. Ich muss also zu jeder Bestellung die jeweiligen Artikel raussuchen, was ich ja im anderen Post schon ergänzt hatte. Jetzt hapert es am Zusammenbau des arrays mit den Modelnummern um die jeweilige Hersteller_id herauszuholen. Weil am Ende sollen die Bestellungen je Hersteller (Zulieferer) mit Angabe des Empfängers und des jeweiligen Artikels zusammengestellt werden... Ich hätte prinzipiell die Frage: es gibt laut Doku zwei Möglichkeiten nach einem bestimmten Wert zu suchen bzw. einen Wert abzurufen. entweder PHP: $data ='{"search": {"match": {"products.products_id": "'.$id.'"}}}';Und dann[php] CURLOPT_URL => $domain . 'api.php/v2/products/search?fields=manufacturers_id',CURLOPT_POSTFIELDS => $data, oder eben direkt PHP: CURLOPT_URL => $domain . 'api.php/v2/products/' . $id . '?fields=manufacturers_id', Wann benutze ich was und warum Bzw. gibt es überhaupt einen Unterschied zwischen den beiden Abfragearten??? Ich brauche beide male nur die Hersteller Id nach der ich dann im script filtere und je Hersteller die Bestellung für ihn zussammen stelle... by the way evtl. ein Bug ? auch wenn nur ein Wert abgefragt wird taucht im Anhang IMMER: "_links": { "tracking_codes": "(Link nur für registrierte Nutzer sichtbar.)" } mit auf!!! soll das so sein? Ich brauche es nicht. Danke und schönen Abend noch
Ok, eine Nacht drüber schlafen hilft manchmal Angehängt kann ich nur den jeweiligen Hauptschlüssel abfragen also in dem Fall die Produkt_id Wenn ich nach einer anderen Spalte suche muss ich die " search-Variante" nehmen. Der BUG mit dem {"_link.....} im response besteht aber definitiv! Oder was soll der Grund dafür sein, wenn ich z.B. nur nach der Bestell_ID selecte ? schönen Tag
Hallo wir benötigen für unser Steuerprogramm auch einen Bestellungs- bzw. Rechnungsexport seitens Gambio. Wir leben im 21. Jahrhundert und hier in den Niederlanden wird alles importiert mit ein paar Mausklicks und sorry leider sind die hier in Holland, technisch auch etwas weiter, alles statische IP´s, Banksachen, Rechnungen, Paypal, alles wird importiert. Es kann nicht sein, das man alles noch händisch wie vor 25 Jahren eingeben muss. Warum gibt es noch keinen Export ? Könnte da einer weiterhelfen, da wären wir sehr dankbar wenn das irgendwann mal klappen sollte. Mit freundlichen Grüßen aus den Niederlanden PHI Essences
Moin PHI Essences, entweder die Datei von L&B hier downloaden und selbst einbauen bzw. anpassen oder ein Modul kaufen, dass das kann. Ob die Holländer wirklich weiter sind weiss ich nicht Auch in Deutschland kann man mit ein paar Mausklicks einiges machen! Will halt jeder was anderes machen! Wird schwer da Komplettlösungen anzubieten! Grüße
Hallo Edgar, der Rechnungsexport sollte Standard sein. Die deutsche Postbank und Paypal bieten seit langem Export-Dateien für die Buchhaltung an. Beim Benchmarking mit anderen sieht man was man machen muss.
Die API des Shops ist ein Ort um geregelt Daten aus dem Shop abzuholen. Gibts. Was du willst ist eher anarchische CSV Dateien erzeugen schätze ich. Das gibts nicht, das ist aber auch nicht dieses Jahrhundert. Lösungen wie Easybill und andere, die sich einfach per API selbst die Daten aus dem Shop holen, zeigen wie es sein muss. Statische IPs sind auch kein besonderes Zeichen von Fortschritt, zumindestens Prozesse die darauf basieren, dass externe IPs statisch sind. Das verhindert im Gegenzug oft Skalierung, Anpassung und Dauerbereitschaft von Diensten und DNS als Abstraktion von IP-Adressen wurde auch nicht umsonst erfunden. Genau das händische Zeug wollen wir abschaffen, dazu bauen wir aber keinen Dampfmaschinenprozess mit CSV-Jonglage und Gaffatape. Die Zeit ist um.
Guten Tag Herr Wilken, ich müsste da mal nachfragen, ob Easybill kompatibel mit der niederländischen Ust-Voranmeldung ist. Ich sehe Gambio als einen der zukünftigen Global-Player in Sachen E-Commerce, aber das ganze ist noch zu deutsch, da würde ein CSV-Import erst auch einmal sehr weiter helfen. Man will doch International mit Gambio expandieren oder nicht ? Wir haben den Geschäftssitz in den Niederlanden, und jeder hier vom Steuerbüro schüttelt mit dem Kopf, das wir alles händisch eingeben. Wir arbeiten mit mit der Steuersoftware " Exact Online", die wollen wenn man sich viel arbeit sparen will, eine CSV haben. Mit freundlichen Grüßen PHI Essences
Ähm, also noch mal kurz? Eure Api gibt es für alle anderen Anbieter auch ??? Nein, so viel ich weiss, bastelt da jeder an einer eigenen API rum? Sonst klärt mich bitte auf! Aber ich glaube nicht, dass die Post oder Paypal die gleiche API verwendet ! Und so lange lieber Wilken sind CSV Dateien keineswegs anarchisch! Die sind noch Standard! Und momentan die einzige Möglichkeit Daten zwischen diversen Systemen auszutauschen!!! Weil ich z.B. habe keine Lust, nachdem ich mich mit Eurer Api vertraut gemacht habe, auch noch mit den APIs von all unseren Zulieferen, Zahlungsanbietern und Versendern rumzuärgern. Da finde ich das Erstellen einer CSV relativ unaufwendig und idiotensicher. Denn alles andere ist Individualprogrammierung!!! Exportiere mal was aus DATEV. Was siehst DU? Richtig, eine CSV! Aber wir leben ja bis auf Gambio ALLE noch im Urwald! Google, idealo, alle Preisportale, Zahlungsanbieter, Steuerberater und Versender... Oder wie gesagt, klärt mich bitte auf. Ich möchte auch gerne raus aus dem Djungel So lange werde ich noch anarchisch anarchistische CSV Dateien erzeugen.
Genau da liegt das Problem. Die Steuersoftware möchte Daten haben und gibt ein veraltetes Format vor anstatt sich der API zu bedienen und sich die Daten direkt aus dem Shop zu holen. Wenn ich mein Auto betanken muss, dann stelle ich mich auch nicht hin und erwarte das mir jemand einen Kanister Benzin (CSV-Datei) vorbei bringt. Ich fahre zur Tankstelle, wähle die Zapfsäule (Gambio-API) und tanke den erforderlichen Kraftstoff.
Dann stehst DU aber vor einer Tankstelle mit recht vielen Zapfsäulen bzw. Hähnen!!! Weil, auch wenn ihr es nicht glaubt! Es gibt noch andere Anbieter als Gambio auf dem Shopsoftware-Markt. Sorry, solange bleibt für mich eine CSV der kleinste gemeinsame Nenner. Auch wenn sie überaltert ist! Sonst passiert nämlich genau das was ich im vorigen POST gesgat habe. Ich muss für jedes kack Preisportal, jeden Zahlunsanbieter, Zulieferer und sonstige Dienstleister eine eigene Zafsäule bauen...
Hallo Kai, also wenn ein paar klicks zum importieren antiquarisch ist, dann weiß ich es auch nicht mehr. Die mehrsprachige international ausgerichtete Shopsoftware hat im Moment aber nur deutsche Lösungen, das ist das Problem. Mit freundlichen Grüßen aus den Niederlanden.
@edgar_comanescu Ich glaube Du solltest mal Deine Denkweise ändern. Nicht Du musst die Schnittstellen erstellen, das müssen die Softwarebuden machen. Du als Nutzer der Software musst eigentlich nur die Bedienung der Schnittstellen ggf. noch ein paar Einstellungen für die Zugriffe (Passwort usw.) @PHI Mit den CSV-Dateien sind es aber doch mehr als ein paar Klicks. Du musst erst im Shop die CSV-Datei erstellen, dann speicherts Du diese auf Deinem Rechner. Dann gehst Du in Deine Steuersoftware liest dort die CSV-Datei von Deinem Rechner ein. Bei der Nutzung der API gehst Du in die Steuersoftware und klickst einmal den Button "Daten aus dem Shop verabeiten". Da musst Du vorher keine Dateien aus dem Shop exportieren und auf Deinen Rechner speichern. Die API von Gambio ist keine "deutsche Lösung". Die API stellt die vorhanden Daten bereit und man kann je nachdem, welche man benötigt, diese Daten herausholen. Wenn man in den Niederlanden für die Buchhaltung andere Daten braucht als in Deutschland, dann holt man sich halt diese über die API. Aber wie schon erwähnt sollten das die Hersteller der Software realisieren und nicht die Shop-Betreiber.
Das ist ein eher unfairer Vergleich der sehr stark hinkt. Es ist sicherlich NICHT ZWINGEND der Anbieter einer Buchhaltungssoftware in der Pflicht ein IMPORT-Modul für JEDEN WEBSHOP zu programmieren das auf die API des Webshops zugreift. Das kann sicherlich im Kundenauftrag individuell programmiert werden, allerdings stellt sich dann tatsächlich die Frage nach dem Aufwand und den Kosten. Damit aber trotzdem jede ERP-, Warenwirtschaft, Webshop-Software mit einer/jeder Buchhaltungssoftware klar kommt (z.Bsp. auch mit DATEV!), ist das CSV-Format in allen nennenswerten Buchhaltungen ein Standardimportformat. Jede Bank stellt die Kontoauszüge in gängigen CSV-Formaten zur Verfügung, da ist überhaupt nichts mit API usw. ... Das EXACT so eine Schnittstelle nicht "ab Haus" anbietet ist sicherlich dem Anwenderkreis geschuldet in dem vermutlich nur wenige Kunden einen Gambio-Webshop einsetzen. Mein persönliches Fazit: Der Verzicht einen (billigen) CSV-Export per Knopfdruck anzubieten hat nichts mit Dschungel, Steinzeit oder ähnlichem zu tun, sondern i.m.M. nach einfach nur "viel zu kurz gedacht" und nicht wirklich Zeit- und auch nicht Anwendergerecht. Selbst wenn ich alle Argumente für eine ausschließliche Lösung per API-Zugriff verstehen könnte (was ich nicht tue), verstehe ich nicht warum nicht einfach ein zusätzlicher Button in den ADMIN kommt der Rechnungsdaten im CSV-Format exportiert. Dauert vielleicht nur eine(1) Std. Programmierung und schon ist hier das (berechtigte) zanken vorbei. jm2c
Das Problem ist doch, dass das CSV-Format kein echter Standard ist. Das geht doch schon los wenn ich eine CSV-Datei auf einen UNIX-Server erstelle und mit einer Windows-Maschine einlese. Die Chancen das es Probleme mit der Code-Page gibt stehen dort gut. Dann möchte auch jeder in der CSV-Datei andere Spaltenbezeichnungen haben. Im Prinzip kann das nur wirklich gut funktionieren, wenn die Anbieter der Software sich die erforderliche Daten holen, denn die wissen was wo hingehört und wie verarbeitet wird. Man kann natürlich nicht für jede Shop-Software eine API-Schnittstelle vorhalten, aber ich glaube Gambio ist auch nicht "jede Shop-Software" und für die etwas größeren etablierten Anbieter sollte das ein gutes Softwarehaus, aus meiner Sicht, schon anbieten.
Eine API ist ja nicht eine Anbindung von Gambio an alles. Muss man sich wie eine Brücke vorstellen: Jede Seite baut eine Hälfte, und in der Mitte trifft man sich, und dort tauscht man die Daten in beide Richtungen aus. Gambio hat also eine halbe Brücke zu Exact Online. Die andere Hälfte soll Exact Online bauen. Wenn die das nicht machen, weil du, @PHI vermutlich der einzige Niederländer mit einem Gambio-Shop bist, dann hilft dir nur: 1) Eine eigene Lösung entwickeln lassen 2) die hier angebotene CSV-Lösung umbauen 3) die Shopsoftware wechseln. Mit der APIfizierung sind bestimmte Datenverarbeitungssysteme einfach mit Gambio nicht mehr kompatibel - aber die die übrig bleiben funktionieren vermutlich besser. Kann man gut oder schlecht finden (Ich gehöre zu letzteren). Mit Internationalisierung hat Gambio es aus meiner Sicht nicht so sehr, von daher würde ich an deiner Stelle PHI auch nur auf Gambio setzen, wenn dein Hauptmarkt Deutschland ist und du am besten gar keine anderen Länder belieferst, oder nur als Zusatzgeschäft ein wenig. Zurück zum Thema: Wie sieht denn die CSV aus die du brauchst? Oder kannst du in Exact Online nicht die zu importierenden Felder konfigurieren? Oder bei Exact Online mal fragen, ob eine API-Anbindung an die Gambio API in Planung ist?
Hallo, ja Exact Online bietet den Import von CSV Dateien an, aber Gambio nicht den Export, war eventuell falsch verstanden worden. Wir fragen aber jetzt bei einer Firma wegen der Programmierung einer API an. Mit freundlichen Grüßen aus den Niederlanden.
Nein. Wir müssen vielleicht nochmal kurz klären was eine API ist. Eine API ist normal eine Maschine zu Maschine Schnittstelle. Man legt den Ort fest wo ein Gegenüber (eine andere Maschine) ihre Fragen abkippen kann (einen Endpunkt) und man gibt einen Duden vor, der erklärt welche Fragen man stellen kann und wie die möglichen Antworten darauf aussehen. Auf die Regeln die das vorgibt können sich alle verlassen, aber mit denen muss auch jeder klarkommen. Das schöne dabei ist normal, dass bei Problemen jeder aufgrund von Doku nachsehen kann welche Seite falsch spielt (Frage falsch oder Antwort falsch?) und das die Anbieter für APIs über längere Zeiträume Unverändertheit garantieren, einmal vorhandene Anbindungen also längerfristig funktionieren. Es ist dabei üblich, dass unterschiedliche Anbieter je völlig eigene APIs haben. Die DHL tut was ganz anderes als PayPal, und wir tun was anderes als die beiden. Weil das so ist, folgen zwar alle erstmal der gleichen technischen Grundidee, aber jeder hat da schon seine ziemlich eigene Sprache, für seinen jeweiligen Zweck. Das heisst PayPal, Gambio und DHL bedienen sich alle einer Grundtechnik die sich REST nennt, aber was dahinter passiert ist je ureigen. Zahlungen machen wollen ist eben was anderes als Versandlabel machen wollen ist was anderes als Bestellungen lesen wollen oder Artikel schreiben wollen. Was alle APIs überall im allgemeinen gemeinsam haben ist, dass die "hörend" sind aber nicht "sprechend". Das bedeutet hat man 2 Sachen die eine API haben und setzt die einen Raum, dann spricht niemand. Jeder würde auf Fragen antworten, aber keiner spricht von sich aus. Das läuft dann so: Irgendeine Software sagt sich, dass sie mit einem anderen Produkt Daten austauschen will. An deren Ende wird dann eine Gegenstelle gebaut, die die API des anderen Endes anspricht um von Dort Daten zu bekommen. Als Gambio sagen wir zum Beispiel PayPal ist relevant, also haben wir Dinge im Shop um PayPal anzusprechen und über API Kommunikation Transaktionen einzutüten. Oder wir sprechen von uns aus DHL an, um dort Versandlabel zu erzeugen, in dem wir etwas haben, was in die DHL API Sachen einwirft und die Antworten holt. Der Shop hat nun selbst so eine API, die dazu gedacht ist, dass fremde (durch den Nutzer befugte) Maschinen Daten austauschen können. Dazu müssen die fremden Maschinen unsere Sprache lernen. Easybill zum Beispiel hat das. Oder Billbee. Oder Faktura XP. Oder Desk4. Vario ist fleissig dabei, weitere werden folgen. Und was CSVs angeht: Fürchterliches Zeug, das sauoft Probleme macht. Dahinter steckt einfach keinerlei Standard, absolut gar nichts, und das ist schon für sich ein KIller. Nichtmal der namensgebende Fakt "kommagetrennte Werte" (comma separated Values) gilt irgendwas. Wir brauchen im Shop zum Beispiel oft ein Pipezeichen (|) als Trenner, damit man in Werten wie Artikelbeschreibungen immernoch Kommata verwenden kann. Der Zeichensatz ist nicht festgelegt, es gibt keine Grössenvorgaben, je nach Betriebssystem sind Zeilenumbrüche unterschiedlich, die Spalten die es gibt und in welcher Reihenfolge die zu sein haben ist Kraut und Rüben, oder ob Kommas oder Punkte Dezimaltrenner sind... Das hört überhaupt nicht auf. Und für komplexe Aufgaben gehen die auch nicht. Die sind total nervig "2D". Man kann damit einfach 0 Komplexität ausdrücken, ohne sich dabei in den Fuss zu schiessen. Das führt zu nix. Man spielt da Feuerwehr in einem aktiven Vulkan. Glüht eine Ecke nichtmehr ist das ein Achtungserfolg und die Heizkosten sind da allgemein niedrig, aber die Erfolgschancen je frei zu haben auch. Wie sowas nun laufen muss: Jemand will irgendein A und B zusammenbringen. Er muss dann A oder B überzeugen, dass das wertvoll ist, damit der eine den anderen anbindet, mit dem reden will. Wenn beide nicht wollen, weil sie das für nicht ausreichend umsetzungsrelevant finden, dann muss ein Dritter was bauen, was mit beiden Seiten redet. Aus der einen raus, auf der anderen wieder einkippen. Dabei kann der dann sogar noch "Magie" auf den Daten betreiben, muss es aber oft auch ein bisschen. Für uns ist der Exact Online Usecase gerade zu klein, das heisst wir haben gerade jetzt nicht auf dem Zettel da bald was zu bauen. Vielleicht will Exact Online, da muss man die halt fragen. Vielleicht sagen die aber auch Nein, dann bliebe die Lösung über einen Dritten oder das Tool eines Dritten zu verfolgen, das sind die Wege.
Gambio ist kein UNIX und ein CSV-EXPORT kann problemlos mit einem modernen EXCEL verarbeitet werden. Ein Codeproblem findet auch nicht statt wenn alles auf UTF8 eingestellt ist. Sorry kann ich als Hindernis nicht annehmen. Kann ich auch nicht akzeptieren. Wie die Spaltenköpfe beschriftet sind ist doch schei..egal. Rechnungsdatum, Rechnungsnummer, Kundenummer, Straße etc. werden schlicht nach der Gambio Nomenklatur eingestellt, lediglich die Reihenfolge ist (wenn überhaupt) von Belang. Diese Reihenfolge wird nach DATEV-Vorgabe erzeugt. Wer andere Spaltenköpfe und Reihenfolgen will muss das in EXCEL selbst lösen, fertig! Das glaube ich auch und trotzdem gibt es große Unterschiede. EXACT-Software beschäftigt Weltweit fast 2.000 Mitarbeiter bei einem Jahresumsatz deutlich über 200 Mio Euro ... ... dagegen ist Gambio dann doch eher ein kleiner Partner auf den sich EXACT verlassen muss das sich nicht dauernd etwas bei GAMBIO und der API ändert. Das setzt Verträge mit Fristen evtl. Konventionalstrafe usw. voraus, und wofür? Für eine sehr einfache CSV-Datei per Knopfdruck ....
Danke L&B, da kommt immer Leben in die Bude, einer der immer wieder nachhakt. Wir haben bei einer Programmierfirma hier in Venlo angefragt, die erledigen das hoffentlich. Die händische Buchung zermürbt einen, das ist sehr anstrengend. Mit freundlichen Grüßen aus den Niederlanden, heute ist mal gutes Wetter hier, wärmer als angekündigt.
Oh doch, das ist eins! Auf was anderen als Unixoiden lässt sich der Shop gar nicht ehrlich betreiben, Windows Server sind lange tot und nicht mehr supported. Damit kommen normal auch Unix Zeilenenden aus dem Shop. UTF-8 ist ganz nett und noch der grobe Nabel unserer Welt, aber dass da mal UTF32 kommt oder was ähnliches ist eigentlich schon absehbar, mal sehen wann. Für uns ist es eins und Teil der Begründung warum wir und viele andere technisch involvierte Parteien keine Lust mehr auf den alten Murks haben. Das ist auch relevant. Es bedeutet ohne Handarbeit geht genau nichts aus A in B zu importieren. Es wird nie gut. Die Datev Definition interessiert uns nicht, so wie die unsere nicht interessiert. Und keiner würde sich bei CSVs committen da nie was zu ändern. Sag ich ja, ohne dauernde Handarbeit wirds nie gut. Es muss aber mehr von selbst gut sein, ohne zutun. Wir würden nie Zusicherungen bei CSVs machen, für fast kein Geld der Welt. Auf der API würden wirs tun. Nein, sondern wenn dann für was viel besseres, das weniger Stress macht und einfach flutscht, mit klaren Zuständigkeiten, klarem Fokus, klarem Ziel und klarem Nutzen.