Vorab: Es geht sich um Version 3.10.0.3 Ich versuche zu verstehen, woher sich der Shop den Lieferstatus nimmt, wenn ich die Bestellbestätigung von Hand erzeuge. Es ist nämlich so, dass dort eigentlich immer "Nicht Lieferbar" steht, egal ob der Artikel oder die Eigenschaft lieferbar ist. Ich bekomme da ständig Rückfragen der Kunden, wenn ich Bestellungen von Hand anlege, weil die sich natürlich wundern, warum das alles nicht lieferbar ist. Teilweise schicke ich gleich eine Mail hinterher oder sage schon am Telefon, dass sie sich nicht wundern sollen, die Anzeige sei falsch. Bestellbestätigungen durch Checkout im Frontend sind immer korrekt. Meine Einstellungen: Überprüfen des Artikelbestandes: Aktiviert Überprüfen des Artikelattribut-Bestandes: Aktiviert Artikelmenge abziehen: Aktiviert Die Artikel mit Eigenschaften haben alle Bestandsprüfung = Kombinationsbestand, Lieferzeitanzeige: Kombinationslieferzeit, alle Artikel ohne Varianten haben dort Artikelbestand und -lieferzeit eingestellt. Ich dachte am Anfang, das bei der Bestellbestätigung von Hand auch bei Artikel mit Eigenschaften einfach der Artikellieferstatus genommen wird, das ist aber nicht der Fall. Der Lieferstatus des Artikels und der Eigenschaft kann ich setzen wie ich will, es wird immer "Nicht Lieferbar" angezeigt. Ich habe schon einiges probiert und weiß aktuell wirklich nicht weiter. Ist es einfach nur ein Bug?
Als Admin ist es auch einfacher für den Kunden das durch den Frontend zugang des Kundenkontos zu machen als im Backend. Meist auch schneller.
Aber deine Lösung Zur Frage: Wie legst du Artikel in die Maske rein? Welche Schritte genau gehst du? Klickst du auf neu berechnen und übernehmen usw. Oder legst manuelle Texte fest... Da gibts einfach zui viele Fallstricke und zu oft falsch berechete Summen. Daher der Weg über das Frontend - einzig sichere Weg. und schneller
Leider nicht die Lösung, denn ich muss hin und wieder Bestellungen im Backend anlegen. Und wenn ich hier im Forum so den ein oder anderen Beitrag lese, ist das wohl auch nicht besonder ungewöhnlich. Ich suche die Artikel über das Suchfeld, füge den gefundenen Artikel hinzu, klicke auf "Eigenschaften", wähle die Eigenschaft aus, klicke auf "Lagerbestand anhand der Anzahl verändern", auf "speichern" und dann auf "zurück". Wenn ich alles zusammen habe, aktiviere ich auf "Nachbearbeitung beenden und Bestellung neu berechnen." und klicke auf "Beenden". Dann klicke ich im Dropdown auf "Bestellbestätigung neu generieren" und dann auf "Email Bestellbestätigung". Das war jetzt noch deutlich ausführlicher als mein erster Beitrag, das müssten eigentlich alle Informationen sein, die nötig sind um das Problem zu erfassen. Lass uns doch jetzt mal darüber reden, wieso bei jedem Artikel nach diesen Schritten in der Bestellbestätigung der Lieferstatus auf "Nicht Lieferbar" steht.
Warum? Du kannst Dich aus dem Admin-Bereich heraus als Kunde anmelden, da gibt es einen Extra-Link in der Kundenübersicht und dann ganz einfach im Frontend die Produkte zusammenstellen. Das geht viel einfacher als die umständliche Suche im Backend. Ich vermute: es findet keine Bestandsprüfung statt. Somit auch keine richtige Zuweisung des Lieferstatus.
Wenn du einen Artikel einer Bestellung hinzufügst, wird der Lieferstatus aus den Artikelstammdaten übernommen. Sonstige Konfigurationen, Attribute und Eigenschaften spielen da nicht rein. Falls es jemand nachlesen will: admin/orders_edit.php, so um Zeile 500 herum.
Habe das gerade getestet Neue Bestellung für Testkunde über Kunden - Kundenliste - Dropdown "Neue Bestellung erstellen" Artikel Bereich auf Bearbeiten den Artikel gesucht die Eigenschaft ausgesucht jeweils hacken bei Bestand verändern gewesen Speichern und neu berechnen beim speichern angehackt Bestellbestätigung neu erzeugt. Lieferzeit stimmt mit dem überein was im shop steht Wenn das bei dir also NICHT richtig ist und über das Frontent bei gleicher auswahl ein anderer Lieferstatus steht Shopversion und ggf. Ticket.
Okay, dann muss ich ein Ticket aufmachen. Genau das habe ich ja probiert, es wird eben nicht der Lieferstatus aus den Stammdaten genommen. Außer, und das fällt mir gerade ein: Ist es möglich, dass nicht der Lieferstatus genommen wird, sondern der Lieferstatus aus dem Bestand berechnet wird? Also wenn ich für "Nicht Lieferbar" den oberen Schwellenwert "0" gesetzt habe, in den Stammdaten aber Bestand 0 ist, kann ich den Artikel ja trotzdem hinzufügen, die Bestandskontrolle soll ja eh über die Eigenschaft stattfinden. Der Lieferstatus aber dann eventuell über Stammdaten "berechnet", dort ist es 0, also nicht lieferbar. Nach dem hinzufügen wurde der Bestand von Stammdaten und Eigenschaften abgezogen, in den Stammdaten ist der Bestand nun "-1", aber der Lieferstatus wurde nur in der Eigenschaft aktualisiert. Dann würde das irgendwie einen Sinn ergeben. Eigentlich ist es ein Bug. Wenn sowohl die Bestandskontrolle als auch der Lieferstatus über die Eigenschaften gehen soll, und es wird trotzdem aus den Stammdaten genommen, ist das einfach falsch. Danke auch an Dennis, dass du es probiert hast. Shopversion wie gesagt 3.10.0.3. Vielleicht wurde es in 3.12. auch schon gefixt? EDIT: Habe das oben beschriebene gerade probiert. Artikel hat in den Stammdaten Lagerbestand "1" Status "Lieferbar". Die Eigenschaft hat Bestand "2" und "Lieferbar". Händisch zur Bestellung hinzugefügt. Ergebnis: Stammdaten: "0" und "Nicht Lieferbar". Eigenschaft: "1" und "Lieferbar". In der händisch erzeugten Bestellbestätigung steht "Nicht Lieferbar".
Steht ja auch oben. Das Modul kann falsch rechnen. Daher immer als Kunde über das Frontend. Schneller und sicherer.
Sooo.... da bin ich wieder. Ein Jahr mehr Erfahrung mit Gambio und ein Jahr weniger bereit mir erzählen zu lassen, dass ich keine Bestellungen im Backend anlegen sollte oder dass das schon alles so richtig ist. Hier also nun nach einem Jahr Frust zumindest mal die Auflösung meiner Frage: Was passiert da eigentlich? Was passiert genau, wenn man einen Artikel im Backend zu einer Bestellung hinzufügt: Wenn der Shop so eingestellt ist, wird der Bestand des Artikels abgezogen. Der Lieferstatus des Hauptartikels wird entsprechend der Schwellenwerte aktualisiert. Bei einem Artikel mit Varianten (Eigenschaften) wird auch der Bestand der Variante abgezogen. Der Lieferstatus wird dabei NICHT aktualisiert. Wenn man die Eigenschaften-Einstellungen auf "Bestandsprüfung: Kombinationsbestand" und "Lieferzeit: Kombinationslieferzeit" stehen hat, steht danach der richtige Bestand aber ggf. die falsche Lieferzeit (wenn man einen Schwellenwert erreicht hat). War der Bestand der Variante vorher "1" ist diese nun "0" steht aber nicht auf "Nicht Lieferbar", wenn man diese Lieferzeit mit dem Schwellenwert 0 definiert hat. In unserem Fall steht im Frontend "Auf Lager" aber der Kunde kann den Artikel nicht mehr in den Warenkorb legen. Erzeuge ich nun die Bestellbestätigung erneut, wird der Lieferstatus des Hauptartikels genommen, egal ob der Artikel eine Variante hat, oder nicht, und egal was zur Bestellung hinzugefügt wurde. Und jetzt kommt das Beste: In der Bestellbestätigung wird der Lieferstatus ausgegeben, den der Hauptartikel hat, NACHDEM man den Artikel oder die Variante zur Bestellung hinzugefügt hat. War vorher noch ein Stück auf Lager und hat man dem Kunden genau dieses eine Stück zur Bestellung hinzugefügt, wird die Bestellbestätigung den Lieferstatus des Schwellenwerts 0 ausgeben, in unserem Fall logischerweise "Nicht Lieferbar". Es gibt keinen Workaround, denn ich muss Bestellungen im Backend ändern und kann nicht von Hand an Lagerbeständen rumpfuschen im Live-Shop damit die Email stimmt. Ich kann einfach keine Bestellbestätigungen versenden, oder, was aktuell meine Lösung ist, ich entschuldige mich bei meinen Kunden, dass das nicht richtig funktioniert und sie die Anzeige zur Lieferanzeige bitte nicht beachten sollen. Ich habe auch ein Ticket dazu eröffnet und würde mich freuen, wenn das angegangen wird. Das ist aus meiner Sicht eine Katastrophe so.