ZurĂŒck zum Blog

Ist es noch weit?

📅  

ERP-Schnittstelle

Die ERP Schnittstelle beherrscht nun auch die Anlage von Bestellungen im ERP-Produktivsystem. Dies umfasst auch die Anlage der entsprechenden Bestellpositionen inklusive der Position der Versandkosten.

Im Zuge dessen haben wir auch eine weitere Mailing-Funktion konfiguriert: Kunde und Vertriebsoffice des Shopbetreibers werden per E-Mail in Form der BestellbestĂ€tigung ĂŒber den Erfolg der Bestellung benachrichtigt.

Im Zuge der Tests sind wir auf einen Designfehler der Schnittstelle gestoßen: Wurden Interessenten seitens des ERP-Systems in Kunden umgewandelt, so haben wir die Referenz am Shop auf den korrekten Kundenaccount insofern verloren, als wir auf einen Datensatz zeigten, den es in dieser Form im ERP nicht mehr gibt. Wir können aber die korrekte Referenzierung wieder herstellen, indem wir aus Mercator ĂŒber die Kontaktinformationen im ERP die Referenz ermitteln und diese in Mercator aktualisieren. Das erledigen wir per Job tĂ€glich. ZusĂ€tzlich kontrollieren vor der Anlage einer Bestellung die Richtigkeit der Referenz und korrigieren sie gegebenenfalls.

Im Zuge dessen haben wir die Benutzeraccountdarstellung in Mercator verbessert.

Stimmung im Team

In den letzten Wochen sind in diesen Artikeln nicht auf die Stimmung im Team eingegangen. Dies ist insofern stimmig, als wir uns auch im Projektverlauf nicht mit den Befindlichkeiten der Mitarbeiter nÀher beschÀftigt haben. Die Entwicklung schritt voran und wir waren tief in den Problemen und Aufgaben der Entwicklung und des Testens gefangen.

In den letzten Tagen fÀllt nun zusehens auf, dass wir den ersten Produktiveinsatz von Mercator herbeisehnen, die offenen Aufgaben öfters zÀhlen und die Zeit bis zum möglichen Produktivstart schÀtzen.

Ganz konkret fehlt fĂŒr den ersten Produktiveinsatz

Wir sind so nahe bei diesem Milestone wie noch nie und gleichzeitig auch so ungeduldig wie noch nie. Hinzu kommt die allgemeine Ferienzeit und -stimmung unserer Umgebung. Wir befinden uns in einer interessanten und spannenden Situation im Projektverlauf.

Mit der AnnĂ€herung an den Produktiveinsatz testen wir wieder intensiver. Dabei haben wir auch einige kleinere Fehler und UnzulĂ€nglichkeiten gefunden, die wir allesamt mit relativ geringem Aufwand beheben konnten. Von einigen dieser Fehler wussten wir, haben sie aber nicht ausreichend dokumentiert und daher in Folge ĂŒbersehen bzw. vergessen. Hier haben wir Verbesserungsbedarf.

Hobo-Einsatz

In dieser Situation der Analyse betrachten wir auch wieder des System als Ganzes. Zwei wesentliche Erkenntnisse aus der Vergangenheit finden sich bestÀtigt:

  1. Die Entwicklung mittels Hobo ist Goldes Wert, die EinschrÀnkung durch die zusÀtzlichen Konventionen hÀlt den Programmcode konsistent. Code anderer Entwickler lÀsst sich deutlich einfacher lesen, als wir das aus alten Ruby On Rails Anwendungen kennen.
  2. Die Anzahl der verwendeten Komponenten ist sehr groß. Bei Durchsicht können wir aber ad hoc auf keine der AbhĂ€ngigkeiten verzichten. Eigentlich hat die Einbindung der Komponenten erst eine Entwicklung eines Systems in dieser GrĂ¶ĂŸe fĂŒr ein derart kleines Team, wie wir es darstellen, ermöglicht.
ZurĂŒck zum Blog