Beiträge von AndiPalm

Und das tut "monat" eigentlich auch... Immer wenn "abgerechnetbis" erreicht ist wird eine neue Rechnung fällig. Und mit Zahlzyklus=3 rechnet er immer 3x das definierte Intervall von einem Monat ab. Nur dass man den Preis dann bei monatx als Summe für den Zeitraum und bei "monat" eben als Preis pro Monat einträgt wenn ich das jetzt richtig verstanden habe.

Es kann gut sein, dass das beim ersten Lauf geklappt hat weil die Berechnung des Zeitraums bei der ersten Abrechnung natürlich "einfacher" ist und er auf gewisse "defaults" zurückgreift. Aber Hauptsache wir haben erstmal die Ursache, jetzt können wir überlegen wo es noch hin gehen soll.

Alles klar, dann ist das der Fehler! "monatx" wird noch nicht unterstützt wie im Wiki-Artikel auch beschrieben:

Zitat von AndiPalm

Die übrigen Auswahlmöglichkeiten wurden aus Kompatibilitätsgründen in der Liste belassen, werden aber derzeit noch nicht unterstützt. Bitte ggf. einen entsprechenden Featurerequest eröffnen

Workaround: Stelle den 01.01.2024 als Startdarum ein mit "Monatspreis" und "Zahlzyklus=3". Das sollte dein gewünschtes Verhalten abbilden. Falls nicht bitte den UseCase nochmal genauer beschreiben. Ich hatte monatx nämlich mangels Verständnis bisher nicht umgesetzt

Unabhängig davon kümmere ich mich darum, dass der Fehler in Zukunft sauber abgefangen wird.

Was ist die jeweilige preisart? Überall "monat"?

Jawohl. Prima, da haben wir zumindest schon mal den Fehler. Es kann also irgendein Datum nicht korrekt interpretieren und dabei stürzt er ab.

Bitte führe doch mal folgende Abfrage gegen die Datenbank aus:

SELECT id, artikel, startdatum, abgerechnetbis, enddatum FROM abrechnungsartikel WHERE adresse = 22;

Die 22 kannst du natürlich auch durch eine andere Adress-ID ersetzen, da wo jetzt halt der Fehler aufgetreten ist. In den drei Datumsspalten sollten überall gültige Daten oder '0000-00-00' stehen. Ist das bei dir so?

Genau, wenn der raus ist sollte erstmal Ruhe sein. Wenn das auch so ist, dann versuch nochmal eine Rechnung zu erzeugen (vielleicht erstmal für einen anderen Kunden als die adress_id=22 falls es dort an irgendwas liegt

Das ist sehr merkwürdig. Hast du die Möglichkeit in der Datenbank einmal in die Tabelle "subscription_cycle_job" zu schauen und diese einfach mal zu leeren? Danach dann die Aboerstellung für die gewünschten Rechnungen erneut starten

Die Fehler sind vom 05.12.2023... also vermutlich als die Emails eingerichtet wurden.

Wird denn jetzt mit der neuen Datei auch bei jedem Lauf eine neue Rechnung mit 0€ erzeugt oder hat sich durch die neue Version etwas am Verhalten geändert?

Könntest du bitte einmal die Datei <OpenXEVerzeichnis>/classes/Modules/SubscriptionCycle/Scheduler/SubscriptionCycleManualJobTask.php durch die Datei hier im Anhang ersetzen? Danach den Prozessstarter wieder starten und nachdem der Fehler wieder aufgetreten ist bitte einmal die Seite "index.php?module=log&action=list" in deinem OpenXE aufrufen. Dort müsste dann hoffentlich ein entsprechender Logeintrag mit Level ERROR erscheinen. Diesen bitte aufklappen und einen Screenshot erstellen (vertrauliche Daten bitte schwärzen).

Ich versuche es mir heute Abend mal anzuschauen ob ich da was finden kann.

Das ist komisch, ich hatte das bisher nicht. Kannst du mir denn ein paar weitere Informationen geben? Hat es mal funktioniert und jetzt nicht mehr? Wenn ja, habt ihr was geändert? Tritt das Problem nur bei einem Kunden auf oder bei mehreren?

Nutzt ihr DHL über Sendcloud oder die DHL-Schnittstelle direkt?

Ach, das hatten wir doch im anderen Thread schon... Sorry!

Ich schaue mal da rein.

Ja, das habe ich auch gesehen, daher habe ich auch nicht verstanden wieso der das plötzlich ändern will und das vorher noch nie wollte.

Bei -drop_keys will er bei mir alle keys löschen und neu anlegen. Das geht aber wiederum aufgrund von foreign_keys nicht. Aber selbst nachdem er einige entfernt und neu angelegt hat, will er sie beim nächsten run wieder löschen und neu anlegen. Hattest du das schonmal oder liegt das irgendwie an meiner DB?

Alex Bei meinem letzten Versuch des DB-Updates bekomme ich nun auch einen "max key length" Fehler auf der Tabelle 'auftrag' weil er die Spalte shopextid von varchar(255) auf varchar(1024) ändern möchte. Ich verstehe aber derzeit leider nicht woher diese Änderung jetzt plötzlich kommt, die letzten Updates haben das nie ändern wollen. Kannst du da vielleicht schnell helfen?

Und wieso ist die Spalte shopextid überhaupt so groß? Die längsten mir bekannten Ids von shops sind GUIDs und die sollten ja sogar mit einem varchar(50) klar kommen, oder übersehe ich was?

Hier mal ein Bild mit allen Einstellungen von mir:

Hilft dir das vielleicht noch weiter?

Sonst würde mir noch einfallen zu prüfen, ob der PHP-Prozess auf dem Server die exec() Funktion ausführen darf und ob der user auch Zugriff auf den Drucker hat. Der entsprechende PHP-Code lautet:

exec("$befehl $dokument");

Ggf. könnt ihr das ja auch mal mit einer test.php-Datei im Webserververzeichnis testen:

<?php
exec("lp -d HP_PageWide_Pro_477dw_MFP -o media=EnvDL -o InputSlot=Tray2 /home/seccoadm/label.pdf");

Nur um sicher zu gehen: Du weißt aber, dass der Befehl auf dem OpenXE-Server ausgeführt wird und die IP 127.0.0.1 dort ggf. einen anderen Host meint?

Da muss man dann leider ein bisschen debuggen. Da tickt jeder Drucker anders. Am besten du nimmst einmal das PDF aus dem Spooler und versuchst das mit dem Kommandozeilenbefehl bis das richtig aus dem Drucker kommt. Wenn bspw. das Papierformat im PDF nicht mit dem Format des Befehls übereinstimmt oder nicht mit dem im Drucker eingestellten Format dann macht Drucker A ein automatisches resizing, Drucker B nimmt dann das A4 Papier aus Schacht 1 weil es noch am ehesten passt, Drucker C macht gar nix und Drucker D piept was das Zeug hält bis der Nutzer den Fehler direkt am Drucker quittiert.

Sowohl bei Sendcloud als auch bei DHL stellt man das Format des PDFs im Controlpanel bzw. Geschäftskundenportal ein

lp -h 172.20.10.15 -d L1_HLL5100DN -o media=A6,THICK,MPTRAY -o fit-to-page

Druck einer Paketmarke auf einem Brother Laserdrucker im Format A6 mit der Einstellung "dickes Papier" vom manuellen Papiereinzug. Das Label wird auf A6 vergrößert/verkleinert

Ich gebe bei mir alles wichtige über die Kommandozeile an, also auch Papierformat, Papiertyp und Zufuhrschacht wo erforderlich. Das funktioniert für mich stabil und zuverlässig

Hab doch mal schnell geschaut: Die entsprechende Poll-Funktionalität, die dich dann über einen verfügbaren Download informieren würde, wurde vor knapp 2 Jahren deaktiviert. Das ist schon mal der Grund warum es nicht funktioniert.

Braucht ihr das denn zwingend als Download oder wäre unser Ansatz auch für euch passend?

Sonst müsste sich Alex einmal versuchen an die Gründe zu erinnern Dann finden wir da bestimmt eine Lösung

Die Drucker unter System->Einstellungen->Drucker haben wir mit unseren "echten" Druckern konfiguriert. Bei uns sind dort bspw. der A4-Laserdrucker und der Zebra Etikettendrucker vom Packplatz eingerichtet. Wenn man eine Paketmarke erstellt kommt diese dort sofort aus dem Drucker raus. Gleiches gilt für Rechnung und Lieferschein sofern diese denn überhaupt als Papierversion benötigt werden.

Man kann dort im Drucker ja auch die Möglichkeit "PDF in Verzeichnis" oder "Download" auswählen, das habe ich selbst aber noch nie benutzt. Müsste ich mir einmal anschauen wie genau das funktioniert sofern nicht Alex oder Josef ggf. schon etwas dazu sagen können.