Posts by Alex

Woran klemmt es denn genau?

Ich habe mit meinem DHL developer account die API "DHL Paket DE Versenden (Post & Paket Deutschland) v 2.1.13" hinzufügen können.

DHL Paket DE Versenden (Post & Paket Deutschland)
v 2.1.13
Division:  Post & Parcel Germany, Parcel 

Geeignet für:
Geschäftskunden der Post und Paket Deutschland GmbHErstellung und Verwaltung der Versandscheine von nationalen und internationalen SendungenRegion:  Deutschland Used for:  Versand

Gerne:

• Jedes Modul hat eigenen Code für die Erzeugung der Listenansichten die mit dem Code in class.yui zusammenarbeitet, die Anpassung ist aufwändig und fehleranfälli. Es wird HTML- und teilweise Javascript-Code in oder vor den SQL-Funktionen erzeugt, durch die Datenbankabfrage durchgeschleust und dann im Frontend ausgegeben.
  • Abstraktion der Listenansichten und Vereinheitlichung, damit in den Modulen flexibel und einfach Sichten erzeugt werden können
• Es existieren Module mit .tpl-Masken, andere sind über das Widget-System implementiert, andere über Javascript, andere über eine interne Erzeugungsfunktion für Masken (z.B. Shop). Das Widget-System ist unklar, die Programmierung darin total aufwändig, z.B. zum Anlegen eines Feldes in der Maske
  • Vereinheitlichung der Maskensysteme auf einen Systemstandard, der einfach und übersichtlich gestaltet ist
• Es existieren (mindestens) 3 Codegeneration, die nicht zusammengeführt wurden: Module, class.erpapi, Code in /classes, jedes Modul ist irgendwie unterschiedlich umgesetzt
  • Festlegung einer einheitlichen Struktur und Trennung von Modulfrontendcode, Funktionscode und Core-Systemcode
• Das Widget-System verwendet für den Datenbankzugriff die objectapi, diese scheint aus automatisch generiertem Code zu bestehen, der aber teilweise manuell angepasst wurde. Das Codegenerierungsystem ist unbekannt. Änderungen erfordern pro Datenfeld jeweils mehrere Änderungen in unterschiedlichen Dateien. Jedes Modul arbeitet mit eigenen SQL-Befehlen, überall ist individueller Code für den Zugriff auf die Datenbank implementiert
  • Trennen von Funktionen und Datenbankzugriff, einheitliche Schnittstelle in die DB über ein Business-Model
• Ein eigener Eintrag für das Trauerspiel class.erpapi.php
  • Aufräumen, Entheddern, in ordentliche Klassenstrukturen gliedern
• Ein eigener Eintrag für das Trauerspiel class.yui.php
  • Aufräumen, Entheddern, in ordentliche Klassenstrukturen gliedern

Das sind die meiner Meinung nach schlimmsten Dinge, die das Entwickeln so extrem schwierig machen, evtl. kann Andi noch dazu etwas anmerken und ergänzen.

Also grundsätzlich schließe ich mich Andi an, einen derart krassen Wechsel halte ich für völlig unrealistisch. Ich habe auch keine Vorstellung wie das überhaupt umzusetzen sein soll. Da kann man wahrscheinlich gleich ein neues System anfangen.

Was mir viel mehr auf den Fingern brennt ist die Verbesserung der vorhandenen Codebasis. Dort ist alles total kompliziert und an vielen Stellen doppelt und dreifach implementiert. Das ist eigentlich der Grund, warum das Programmieren mit OpenXE so schwierig ist. Mir wäre es lieb wenn wir an der Stelle ansetzen und den Code derart optimieren, dass z.B. das Hinzufügen einer Spalte oder einer neuen Schnittstelle nicht jedes mal in endlose Handarbeit und Datei-Archäologie ausartet. Gerne können wir dabei auch schauen ob wir an der einen oder anderen Stelle vorhandenen Code auf ein neues Framework setzen können, wenn es uns konkret hilft. Dann sollten wir aber nicht das neue Framework dazubasteln, sondern wirklich konsequent migrieren und alten Code komplett entfernen.

Ich würde sogar so weit gehen und sagen dass wir auch komplett ohne neue Frameworks durch strukturiertes Aufräumen des vorhandenen Codes sehr starke Verbesserungen erreichen können, die uns greifbar und zeitnah echten Mehrwert beim Entwickeln bieten.

Hallo Markus,

ich glaube die verschachteteln Artikelkategorien waren in der Xentral-OpenSource-Version nicht enthalten, deswegen ist die Funktion was das angeht leider eingeschränkt. Gegebenenfalls müsste man dort mal genauer hinsehen um herauszufinden, ob sich das entsprechend erweitern lässt.

VG,

Alex

Also aus der Tabelle "seriennummern_beleg_position" diese Zeile entfernen bei denen die Spalte Seriennummer die ID der Dummynummer aus der Tabelle "seriennummern" hat.

Die neue Kommissionierfunktion ist nun veröffentlicht. Folgende Neuerungen sind enthalten:

• Lagerplätze können als Kommissionierlager markiert werden, diese sind für die Autoversand-Auslagerung gesperrt
• Beim Vorkommissionieren wird der Kommissionierlagerplatz gewählt (z.B. auch für Kommissionierboxen)
• Ein Standard-Kommissionierlagerplatz kann im Projekt hinterlegt werden
• Beim Kommissionieren werden die Artikel aus den Autoversand-Lagerplätzen zusammengestellt und in den Kommissionierlagerplatz gebucht
• Die Artikel werden im Kommissionierlagerplatz auf den Auftrag reserviert
• Es wird ein Kommissionierschein erzeugt mithilfe dessen die Artikel dann physisch in den Kommissionierlagerplatz/Kommissionierbox gelegt werden können
• Der Auftrag wird gesperrt und bekommt im Lagerstatus den Status "Kommissioniert"
• Beim Autoversand wird dieser Auftrag dann mit den reservierten Artikeln aus dem Kommissionierlagerplatz ausgebucht

Du kannst mich per Mail hier erreichen: alex@openxe-dev.org

Hi,

das ist bis jetzt noch von niemandem angefragt worden, steht daher nicht auf der Liste.

Ich kann Euch entweder anbieten das gegen Kostenübernahme zu entwickeln, oder ihr macht es selbst falls das eine Option ist. Bitte aber dann mit mir Rücksprache halten, weil ich momentan eine andere Sache an der Datev-Schnittstelle erweitere, nicht dass es zu Problemen beim Zusammenfügen der Entwicklungen gibt.

VG

Alex

Hi,

momentan enthält der DATEV-Export nur die folgenden Belege: Rechnung, Gutschrift, Verbindlichkeit, Lieferantengutschrift. Die Verbuchung der Kontoauszüge dient der Ermittlung der offenen Posten bzw. Fehlbeträge.

Bei uns ist es z.B. so dass das Steuerbüro sich die Kontobewegungen direkt von der Bank holt und im DATEV alles selbst verbucht, funktioniert reibungslos.

Wie macht Ihr die Buchungen der Kontoauszüge im OpenXE? Über CSV-Import und dann über die Saldo-Funktion?

VG

Alex

Wenn die Seriennummer einem Beleg (Wareneingang oder Warenausgang) zugeordnet ist, dann kann die nicht mehr gelöscht werden. Du könntest in der Datenbank-Tabelle "seriennummern_beleg_position" die entsprechenden Verknüpfungen entfernen, und dann die Dummynummern löschen.

Bis jetzt ist das nicht weiter verfolgt worden. Was momentan funktioniert, ist von extern lesend auf die Kalendereinträge von OpenXE zuzugreifen über ICS.

Bitte nochmal Upgrade ziehen, es sollte jetzt durchlaufen.

Dazu gibt es die Funktion, den Artikel zu sperren. Die Artikel werden dann nicht mehr für Belege vorgeschlagen, sind aber noch da.

Von unserer Seite ist dazu momentan nichts geplant. Ich habe gerade nachgesehen, die Funktion ist leider in der Opensource-Version nicht drin, müsste also nachgebaut werden.

Okay danke, jetzt sehe ich woran es liegt. Ich werde mir das demnächst ansehen und reparieren.

Danke für den PR. Es wäre schön wenn die Docker-Nutzer das mal testen können bevor ich es übernehme.

Führe das Ganze mal bitte mit '-v' aus, dann kann man sehen welche Tabelle es ist.

Hallo Markus,

bei einer frischen OpenXE-Installation sollte dieses Verhalten nicht auftauchen. Du kannst evtl. das Upgrade auch auf der Konsole mit der Option "-drop_keys" ausführen, dann werden die Schlüssel neu angelegt. Gegebenfalls zweimal ausführen.

Ich habe etwas am Code verändert, ziehe bitte nochmal ein Upgrade und probiere aus ob es jetzt besser ist.

Kannst Du mit dem Befehl aus der CLI drucken? Falls nein, wäre meine erste Anlaufstelle die Firewall.

echo "Test" | lp -h XXX.XXX.XXX.XXX:631 -d Laser_single