Ein Schwank aus dem Programmier-Alltag.

Der wöchentliche Bestelllisten-Versand ist ein kritischer Task, das heißt: er muss funktionieren. Die Hersteller rechnen fix damit, dass sie die Bestelllisten am Mittwoch früh in ihrem Posteingang finden. Dementsprechend viel Zeit floss bzw. fließt in die Umsetzung, ich als Support für viele Initiativen, die bei mir hosten, möchte ja am Mittwoch früh bitte meine Ruhe haben 😉

99,25% – 99,50% sind eben zu wenig…

Ich betreue und hoste momentan 25 Initiativen mit jeweils im Durchschnitt 15 Herstellern, das macht knapp 400 Listen, die jede Woche versendet werden. Soweit, so gut. Aber ab und zu (bei 2 bis 3 Herstellern) klappte das Versenden nicht, weil ein Fehler auftritt, der auch nach oftmaligem Debuggen einfach nicht einzugrenzen und zu finden war. Noch seltener (ist aber auch ein paar Mal vorgekommen) ist dann das ganze Skript abgebrochen und die Listen an die Hersteller, die noch keine Mail erhalten haben, wurden gar nicht versendet. Ziemlich nervig für alle beteiligten. 📞📞📞

Die Lösung

Ich habe mich also vor ca. einem Monat dazu entschieden, das ganze Versende-System (das technisch auch für den Rechnungsversand verantwortlich ist) komplett neu zu programmieren. Mittels einer Queue ist nun die Generierung der PDFs und das Versenden der Mails technisch getrennt. Außerdem werden jetzt die Mails einzeln versendet und bei einem Fehler automatisch bis zu 2x wiederholt. Das reicht, um ein Nicht-Versenden wegen kurzer Ausfälle des Mailservers zu vermeiden. Sollte die Liste dann immer noch nicht versendet worden sein (wenn z.B. die Mailbox des Herstellers voll ist), bleibt das Symbol in den Aktivitäten auf rot (siehe Kreis im Screenshot).

Und siehe da: Alles funktioniert jetzt einwandfrei 🤗

PS: Alle Initiativen, die ich betreue, verwenden die neue Funktion bereits. Alle anderen klonen entweder sofort direkt von Github (develop-Branch) und installieren sich die Vendors selbst oder warten auf die Version 3.2, die im Frühjahr 2021 erscheinen wird.

Das mit dem Pfand ist ja so ein Thema… Natürlich ist es umwelttechnisch total sinnvoll, Mehrweggebinde inkl. Pfandsystem zu verwenden, nur in der Praxis bedeutet das oftmals einiges an Mehraufwand. So müssen in der Software FoodCoopShop sowohl die Pfand-Rückgaben der Mitglieder (da Mitglied bringt das leere Joghurt-Glas ins Lager) als auch die Pfand-Rücknahmen der Hersteller (der Hersteller nimmt alle leeren Joghurt-Gläser der letzten Woche wieder mit in seinen Betrieb) eingetragen werden. Das funktioniert natürlich nie 100%ig.

Es gibt nun aber eine große Hilfe: Im Admin-Bereich unter “Finanzberichte / Pfand-Übersicht” gibt es eine neue, übersichtliche Tabelle, die alle Pfand-relevanten Daten über die einzelnen Jahre gesondert ausweist. Außerdem ist dort eine Grafik vorhanden, die alle manuell eingetragenen Daten (Pfand-Rücknahmen, Pfand-Rückgaben und Ausgleichszahlungen) als Liniendiagramm darstellt. So können Fehleingaben leichter gefunden und anschließend korrigiert werden.

In diesem Beispiel hat die Initiative offene Pfand-Forderungen der Hersteller von 1.654,94 €. Die Summe der Guthaben aller Mitglieder verfügt über einen Anteil, der für Pfand-Ausgleichszahlungen vorgesehen ist, von 1.085,86 €. Das heißt es wurde 598,08 € fehlerhaft eingetragen (entweder zuviele Pfand-Rückgaben oder zuwenige Pfand-Rücknahmen).

Viele weitere Infos zur Pfand-Verwaltung findet ihr in der Online-Doku:
https://foodcoopshop.github.io/de/pfand.html

PS: Alle Initiativen, die ich betreue, können die Funktion ab sofort verwenden. Alle anderen klonen entweder sofort direkt von Github (develop-Branch) und installieren sich die Vendors selbst oder warten auf die Version 3.2, die im Frühjahr 2021 erscheinen wird.

Für Initiativen, die den Selbstbedienungs-Modus bereits verwenden, gibt es eine tolle Verbesserung.

Beim Einkaufen mit dem Handy kann man nun direkt mit der Smartphone-Kamera (und zwar ganz ohne App) die Barcodes scannen. Dazu muss im Profil das Häkchen bei “Ich möchte die Kamera meines Smartphones zum Scannen der Barcodes benutzen.” angehakt werden und beim Scannen dann der Kamera-Zugriff freigegeben werden.

Diese Funktion wurde – wie übrigens der gesamte Selbstbedienungs-Modus – von einem privaten Unterstützer finanziert.

 

Technisch habe ich für das Scannen Quagga (Javascript-Library) verwendet (https://github.com/ericblade/quagga2) verwendet.

PS: Alle Initiativen, die ich betreue, können die Funktion ab sofort verwenden. Alle anderen klonen entweder sofort direkt von Github (develop-Branch) und installieren sich die Vendors selbst oder warten auf die Version 3.2, die im Frühjahr 2021 erscheinen wird.

Der Bauernladen Eibiswald hat am Freitag, 09.10.2020 seinen ersten Abholtag. Sie ist die erste Initiative in der Steiermark, die ich mit meiner Software unterstützen darf.

Ich wünsche euch viel Erfolg!