Ja natürlich. Du scheinst die Grundbedingungen freier Software nicht verstanden zu haben, denn Du hast hier überhaupt keine Ansprüche.
Beim Cloudshop zahlst du für den Speicherplatz und den Traffic (so verstehe ich das) und nicht für den Shop an und für sich. Hier muss ich Chrisitan Recht geben. Wenn ich zu unserer Buchhaltung gehe und der sage wir müssen die Rechnung ändern (und das am besten auch noch bei einem Firmenkunden) schmeißt die mich aus dem Büro... Gerade für Retouren und Gutschriften ist Gambio meiner Meinung nach nicht geeignet und ich glaube auch nicht gedacht. Wir nutzen schon immer eine Warenwirtschaft welche den Shop ansteuert und haben die Funktion der Bestellbearbeitung auch nie benötigt. Meiner Meinung nach (und die ist sehr subjektiv) ist der Großteil der Gambio Nutzer mehrgleisig unterwegs. Und hier bietet sich eine zentrale Lagerverwaltung über eine WaWi definitiv an welche dann die Bestellbearbeitung überflüssig macht. Es ist bei Gambio wie bei so vielen Firmen. Alles auf einmal geht nicht und daher muss man sehen was als erstes erledigt werden muss und was einfach nach hinten geschoben werden kann. Das mag nicht mit deiner Einschätzung einhergehen aber da muss man durch.
Ich gebe Dir in allen Punkten Recht, deshalb arbeite ich auch mit Wawi, löst alle Probleme auf einmal und kann dabei auch noch die Statistik richtig. Dabei übernehme ich die Aufträge von Hand, weil Kunden teilweise nicht mal ihren Ort kennen, alles klein schreiben usw. Eine automatische Übernahme scheidet da meist eh aus. Und ich bin bei den oberen 10%, also kein Kleiner.
Nur mal als kurzer Einwurf, von einem der "wenigen Leute", die diese Funktion angeblich nur nutzen: Auch wir ärgern uns mit der Bestellnachbearbeitung rum. Til hat absolut Recht mit dem, was er hier bemängelt. Ich habe nur gerade Wichtigeres zu tun, als mich stärker an dieser "Diskussion" zu beteiligen. Denn es ist wie immer in diesem Forum: Jemand macht einen konstruktiven Vorschlag oder beschreibt konstruktiv Dinge, die nicht optimal oder richtig laufen und schon kommen Leute, die dir erklären, warum das nicht geändert werden muss, warum sie dieses Problem nicht haben, warum du auch kein Problem hast und wie du das alles ganz anders machen musst, am besten mit externen Programmen, auch wenn Gambio das eigentlich auch selbst kann. Am Ende ist man nach zig Seiten, die diese Themen dann meistens haben, kein Stück weitergekommen. Anstatt einfach mal anzuerkennen, dass nicht jeder die gleichen Abläufe hat oder braucht, die man selbst vielleicht mit externen Programmen abbildet und dass hier ein valides Problem beschrieben wurde, das definitiv behoben werden sollte.
Guck dir mal Easybill an, damit könnten einige deiner Probleme gelöst werden: Rechnungsimport aus Gambio (+ Amazon, eBAY,Kaufland u.v.a. ) per API. Lieferscheine, Aufträge, Angebote, Datev-Eport u.v.a.. Benutzen wir seid Jahren und OSS ist auch kein Problem. Auf Gambio als führendes "Rechnungsprogramm" würde ich nicht setzen, die Gründe hast du ja selbst erwähnt.
Dann wirst du vermutlich noch ein paar Jahre auf Gambio warten müssen. Ganz so groß, scheint dein Problem nicht zu sein.
Wir hatten vor Jahren überlegt, ob wir die nicht von uns entwickelte, uralte Bestellnachbearbeitung ersatzlos komplett entfernen oder ob wir sie ein letztes Mal mit sehr viel Aufwand noch soweit zurecht biegen, dass sie in vielen, aber nicht allen Fällen für simple Vorgänge ihren Zweck erfüllt, wohlwissend, dass sie einiges gar nicht leistet und dann einfach Unfug macht und wir entsprechend Meldungen dazu bekommen. Wir haben uns für Letzteres entschieden. Das Machbare mit der technischen Grundlage ist ausgereizt, alles darüber hinaus benötigt eine ganz andere technische Grundlage, um kein Zeitgrab zu werden. Daran arbeiten wir in den letzten Jahren und auch in der Zukunft Stück für Stück. Jetzt und im kommenden Jahr finden Modernisierungen rund um Kunden und Produkte statt. Kombiniert man beides, erkennt man, dass die Grundlage für den Warenkorb geschaffen wird. Zusammen mit dem Warenkorb ist wiederum die Grundlage für den Checkout vorhanden. Ist der Checkout da, ist alles für die Bestellung vorhanden. Alles kombiniert ermöglicht eine Nachbearbeitung. Es ist also noch ein langer Weg dorthin. Wer auf Funktionalitäten angewiesen ist, die im Shop nicht gehen, muss auf Alternativlösungen zurück greifen. Um mit etwas Positivem zu enden: In GX 4.5.1 sind Modernisierungen enthalten, die es endlich ermöglichen die Rechnungen und Lieferscheine abhängig von der Sprache der Bestellung zu erzeugen. Es gab mehrere Tickets dazu, weshalb da auch welche auf "Abgewiesen" stehen.
Die REST-API der aktuellen Shopversion 4.5 unterstützt Eigenschaften und Attribute. WaWi-Schnittstellen werden aktuell entsprechend erweitert, um z. B. mit Cloud-Shops zu harmonieren. Bitte reiße Zitate nicht aus dem Zusammenhang und unterstelle mir Aussagen, die ich nicht getätigt habe. Der Satz lautet: Natürlich könnte der alte Code in dem Stil erweitert werden. Das ist nur so extrem fehlerbehaftet und fehleranfällig aufgrund einer sehr schlechten Code-Basis, so dass Kosten und Nutzen nicht im richtigen Verhältnis stehen. Wenn es fehlerfrei laufen soll, muss die Codebasis das her geben und das kommt an vielen Stellen einer Neuentwicklung gleich. Wir sind der Meinung, dass nur eine moderne, wartungsarme, stabile Codebasis eine Zukunft hat. Daran arbeiten wir, die Schritte dazu habe ich grob umrissen.
@Til Wenn man so unzufrieden ist, sollte man auf ein anderes Shopsystem wechseln. Da bin ich bei dir, ich deinen genannten Bereichen sollte baldmöglichst nachgebessert werden. Ich warte auch noch, dass im Versand mit Dimensionen gearbeitet wird. Paket - Länge x Breite x Höhe / Stückzahlen / Preis
Das unterstütze ich vorbehaltlos, denn alle Lieferdienste haben Längen- und/oder Volumenbegrenzungen, meist sogar abgestuft. UPS, DHL, DPD und GLS haben die erste Längenstufe bei 1,20 m, alles darüber kostet Aufpreis. Die nächste Stufe liegt bei 1,60m oder 1,70 m. Der Eine hat eine maximale Länge von 1,20m, der Andere 1,70m, wieder ein Anderer 2,00m. Bei DHL-Express wird grundsätzlich mit Volumen gerechnet. Selbst Warenpost hat unterschiedliche Größenbeschränkungen. Das lässt sich im Shop alles nicht abbilden. In der Folge kann man günstige Versandmöglichkeiten nicht anbieten, weil man das gesamte Sortiment auf den kleinsten gemeinsamen Nenner bringen muss. Dadurch ergeben sich Wettbewerbsnachteile und das schlägt sich konsequent im Umsatz nieder.
Die Sachlage ist eigentlich simpel: Wir haben 3876 Ideen was man wie machen könnte. Zeit ist immer für vielleicht 100 da, das heisst 3776 Ideen müssen warten. Wir priorisieren also, was uns am wichtigsten für das Gesamtprodukt erscheint. Da wird nicht jeder immer mit uns einiger Meinung sein, gerade wenn er sein Steckenpferd gerade nicht in Arbeit vorfindet, trotzdem geht es um die Verheiratung der Ansprüche aller und die Zukunftsfähigkeit und das Gedeihen des Ökosystems insgesamt. Was auch noch dazu kommt: Wenn man sich eine Baustelle ankuckt, wird taxiert. Da legt man dann ein Soll fest und findet dann heraus das zu erreichen dauert vorraussichtlich 300 Arbeitsstunden. Dann wird geschaut, welche Querabhängigkeiten da sind, die auch auf der Liste stehen. Kommt dabei heraus, dass es wenn man was anderes vorher macht für die andere Baustelle nur noch 150 Stunden aufzuwenden wären, dann fliesst das in eine Priorisierung ein. Und dann gibt es noch die Frage von Brüchen. Wenn man etwas ändern will, muss dafür oft in der Breite irgendwas tief geändert werden, das macht angeschlossene Sachen kaputt. Hier werden nach wie vor fleissig SQL Hacks ausgetauscht, die dann eben nicht mehr gehen. Oder Leute haben irgendwelche Connectoren, die dann funktional brechen. Wir sagen allen immer wieder die sollen sich was besseres ausdenken und den alten Shit aufhören zu tun, aber das braucht dann eben auch bei einigen länger um anzukommen, solange halten diese Leute den Laden auf. Man muss sich dann nämlich immer überlegen, wie oft man etwas zerbrechen kann, bevor es untragbar wird. Wenn 3 Baustellen nacheinander 3x dasselbe Ding zerbrechen würden, muss man sich überlegen ob man das in 3 Intervallen machen kann und Leute 3x über die Klippe schmeisst oder einmal richtig, oft ist einmal richtig am Ende besser. Die Bestellnachbearbeitung braucht um besser zu werden einen grossen Aufschlag, mit Kleinkram erreicht man da nichts was mehr gewinnt. Dazu müssten zum Beispiel erstmal Bestelldaten teilweise besser werden, aber auch vieles andere. Das ist ein fettes Eisen, wenn man das macht bleibt erstmal viel anderes über einen grösseren Zeitraum liegen, weil es gerade mit nichts anderem zusammenspielt. Das also jetzt zu gehen wären wir nicht bereit, weil das jetzt nicht das grösste Problem des Ökosystems ist. Keiner sagt es wäre kein Problem, aber anderes wiegt für uns schlicht mehr. Ich sehe da kurzfristig keine Veränderungen kommen, die Til glücklich machen würden.
Ich kann nachvollziehen, dass manche aktuellen Fehler der Bestellnachbearbeitung den Eindruck machen, als wären nur "kleinere Fixes und Änderungen" notwendig, um sie zu lösen. Wir hätten es schon längst gemacht, wäre es so. Es ist ja nicht so, als ob wir die Probleme bestreiten. Was hier nur schwer zu vermitteln ist, was die tatsächliche Arbeit dahinter ist. Wenn man mir hier nicht glaubt, ist das in Ordnung. Weiter bringt es uns nur nicht in der Diskussion. Ich denke es ist alles gesagt worden.
Manchmal muss man damit aber auch aufhören, immer Rücksicht zu nehmen. Manche lernen es halt erst, wenn es nicht mehr anders geht. Kaum jemand wird ein Running System ändern auf ein neues, wenn er nicht gezwungen wird. Andererseits sehe ich, was externe kleine Entwickler für Module und Erweiterungen heraushauen und was von Gambio in vergleichbarer Zeit an Änderungen kommt. Da frage ich mich, warum externe soviel effektiver und schneller sind. Manchmal hat man das Gefühl als ob ihr euch selbst im Weg steht oder zu viel Rücksicht auf andere nehmt und damit die Entwicklung ausbremst.