Beiträge von Bergami

...hmmmm - wenn ich '' als Wert in beide Einträge eingebe, dann wird mir zweimal '' auf dem Beleg ausgeben. Jetzt habe ich beide Einträge komplett gelöscht und nun steht auf dem Beleg wieder 0

Sehr schön - das PDF wird nun problemlos angezeigt.

Das einzige was jetzt noch ein wenig stört ist, dass unterhalb des Datums eine Null angezeigt wird. Muss ich vielleicht noch "darf_null" von 0 auf 1 setzen?

Über die Oberfläche kann ich die Formel nirgends entdecken...mit einem Blick in die Datenbank schon:

Sie steht als Wert der Spalte "freitext1inhalt" und "freitext2inhalt" in der Tabelle "firmendaten_werte.

Moin Alex,

damit ist die Fehlermeldung weg und es wird mir ein PDF-Vorschau gezeigt. Allerdings wird mir in der PDF oben rechts eine Infobox ohne Inhalte angezeigt:

ja...wirklich etwas wortkarg das System. Muss wohl ein männliches System sein

Typ1 und Wert stehen auf 1.

Value steht auf 0.

Habe den Wert 1 gerade mal auf 0 gesetzt - der Fehler kommt aber trotzdem bei mir.

Achja - den Auftrag den ich geändert habe hatte ursprünglich AmazonPay als Zahlart. Ich habe ihn dann in OpenXE auf "Kauf auf Rechnung" umgestellt - eben weil eine nachträgliche Änderung der Bestellsumme bei AmazonPay für diesen Vorgang nicht möglich ist.

Ja, "extsoll" ist gesetzt. So ein Gedanke ging mir heute morgen auch durch den Kopf, dass der Betrag bei Online-Aufträgen vielleicht gesperrt sein könnte. Im Shop hängen dort ja Aufträge drann, die z.B. PayPal oder AmazonPay als Zahlart haben und bei denen ist eine nachträgliche Änderung der Summe ja auch nicht möglich.

Es wundert mich dann allerdings, dass sich der Betrag heute ändern lässt.

Sehr schön, die bessere Kenntlichmachung der der optionalen Preise habe ich schon lange vermisst!

Wäre es jedoch noch möglich, dass "Gesamt optional" erst angezeigt wird, wenn es auch eine optionalen Positionen im Angebot gibt und nicht generell immer?

Ich war gerade dabei Dir eine E-Mail mit den gewünschten Datensätzen zu schicken, als mir noch eine Idee in den Sinn kam, die ich ausprobieren wollte. Beim Ausprobieren in meinen aktuellen Datensätzen stellt ich dann fest, dass das Problem bei drei anderen importierten Aufträgen gerade nicht auftritt. Daher habe ich den Auftrag, bei dem mir das Problem zuerst auffiel, noch einmal bearbeitet bzw. den Preis der Auftragspostion geändert. Auf einmal wird der Bruttopreis nun auch korrekt in der Übersicht angezeigt.

Wie kann das den sein? Ein Problem mit dem Cache, das aber nur bei bestimmten Bruttopreisen auftritt? Sehr merkwürdig.

Ich wollte gerade einen Brief im CRM schreiben. Nach dem Speichern der Inhalte, habe ich auf den "PDF-Button" geklickt, um mir dem Brief im fertigen Layout anzusehen und bekam leider diese Fehlermeldung:

Ich bin eigentlich der Meinung, dass schon das einmal getestet hatte und dass es zu dem Zeitpunkt auch funktioniert hatte.

Cool, danke!

Ich bin schon dabei eine entsprechende Testumgebung anzulegen. Sowie sie steht, schicke ich Dir die benötigten API-Zugangsdaten.

Die htaccess ist nicht fehlerhaft. Sie entspricht nach Deiner Änderung in dieser Datei nur nicht mehr dem Original. Wenn Du Deine Änderung dort rückgängig machst, oder nach dem nächsten Update von OpenXE, ist die Meldung auch wieder weg.

Bist Du Dir überhaupt wirklich sicher, dass der Cronjob nicht funktioniert? Normlerweise gibt es nämlich eine Fehlermeldung im Prozessstarter, wenn dieser global aktiviert ist aber kein Cron darauf zugreift.

Ich habe jetzt gerade noch mal getestet was passiert, wenn ich die Rechnung aus einem solchen Auftrag erstelle, bei dem der Bruttogesamtpreis in der Übersicht nicht aktualisiert wird, nachdem der Verkaufspreis einer Bestellposition geändert wurde:

In der Rechnung werden der geänderte Preis der Bestellposition als auch der neue Bruttogesamtpreis korrekt ausgegeben.

Auf Dein Root hattest Du bislang keinen Zugriff, weil das die .htaccess im Root verboten hat. Nun hattest Du doch in dieser .htaccess den Zugriff nur auf Deine "bridge.php" erlaubt. Dementsprechend müsste die bridge.php nun auch ins Root verschoben werden und dann stimmt auch der Pfad zur starter2.php..

Vorher kannst Du aber noch einmal etwas anderes ausprobieren. Ändere die erste Zeile Deiner bridge.php auf:

 exec("/usr/bin/php74 ../cronjobs/starter2.php  2>&1", $out, $result);

Ich habe mir jetzt mal ein paar Vorgänge angesehen, konnte aber nur ein paar wenige Unterschiede festestellen. Die importierten Aufträge aus dem Shop haben:

• eine zusätzliche Internetbestellnummer
• keine VertriebID
• keine Lieferbedingung (z.B. ab Werk)
• eine shopextid

....und das war es auch schon. Selbst wenn ich die VertriebsID und die Lieferbedigungen nachpflege, ändert sich nichts am falschen Bruttopreis in der Auftragsübersicht.

Deine "bridge.php" liegt im Root-Verzeichnis Deiner OpenXE-Installation?

Wenn nicht, bitte ins Root verschieben und dann noch die URL vom Cronjob entsprechend anpassen.

Na klar.

Ich habe das Problem bei zwei Aufträgen nachvollziehen können. Gemein haben die beiden Aufträge, dass sie beide bereits angelegt und gespeichert waren, bevor bei einer Auftragsposition der Verkaufspreis geändert und erneut abgespeichert wurde.

Der eine Auftrag hat des Status "storniert" und es wurde weder ein Lieferschein noch eine Rechnung geschrieben.

Der andere Auftrag hat den Status "freigegeben" und es wurde ein Lieferschein geschrieben.

Achja - beides sind Aufträge, die aus Shopware5 importiert wurden.

Daher habe ich diese nachträgliche Preisänderung gerade noch einmal bei einem Auftrag durchgeführt, den ich händisch in OpenXE angelegt habe. Und tatsächlich - dort tritt das Problem nicht auf.

Das Problem tritt also nur bei aus dem Shop importierten Aufträge auf.

...ich meine im Auftrag (Verkauf).

Hast Du schon die Möglichkeit gefunden mal einen Blick darauf zu werfen? Brauchst Du von mir dazu sonst irgendetwas?

Zitat von AndiPalm

Ich kann mir das gerne einmal anschauen.