Laravel-Entwicklung in Hamburg für Logistik und Verlage

Die zwei großen Branchen Hamburgs verlangen von einem Backend dasselbe Unangenehme: korrekt zu sein über Daten, die es nicht erzeugt hat und an der Quelle nicht korrigieren kann.

Speditionen, Reedereien und Hafenlogistiker liegen hinter Terminalsystemen, Zollplattformen und EDI-Feeds von Partnern. Verlage liegen hinter Agenturen, Syndication und einem Archiv, das älter ist als jedes heute laufende System. Keiner kann das Vorgelagerte reparieren, also muss die Anwendung das Chaos aufnehmen, ohne es weiterzugeben.

Hamburger EDI-Nachrichten wiederholen sich, kommen spät und in falscher Reihenfolge

Das ist die bestimmende Eigenschaft von Logistikintegration und die Quelle der meisten ihrer Fehler.

Ein Partner sendet eine Statusmeldung zweimal, weil sein Retry gefeuert hat. Ein Zollupdate für Dienstag kommt nach dem für Mittwoch. Eine Korrektur kommt zu einer Sendung, die das System schon geschlossen hat. Nichts davon ist außergewöhnlich, und eine Anwendung, die es als außergewöhnlich behandelt, produziert monatelang still falsche Summen.

Was trägt, ist unspektakulär. Die Absenderreferenz wird zum Unique-Constraint, sodass ein Duplikat an der Datenbank scheitert und nicht an einer Prüfung, die jemand entfernen könnte. Vorgänge tragen den Zeitpunkt des Geschehens und den der Ankunft, sodass die Reihenfolge eine Eigenschaft der Daten ist und nicht der Zustellung. Und die Rohnutzlast wird vor dem Parsen gespeichert, was die spätere Uneinigkeit darüber klärt, wessen System falsch lag.

Die Queue von Laravel wiederholt von Haus aus - hier ein Vorteil, und eine Falle, wenn der Job nie darauf geschrieben wurde, gefahrlos zweimal zu laufen.

Der Laravel-Nachtbatch ist ein Zuverlässigkeitsproblem, kein Geschwindigkeitsproblem

Jedes Hamburger Logistiksystem hat einen Import, der um drei Uhr morgens läuft und vor dem alle ein wenig Respekt haben.

Ihn schneller zu machen ist überwiegend Mechanik - in Chunks einfügen statt ein Model pro Zeile, nicht in der Schleife abfragen, und die Aggregation der Datenbank überlassen, die das besser kann. Diese Arbeit fällt unter Datenbank- und Eloquent-Engineering, und sie ist die Hälfte, die Aufmerksamkeit bekommt.

Die wichtigere Hälfte ist, was bei Zeile 240.000 passiert, wenn er abbricht. Kann der Job nicht sagen, was er schon verarbeitet hat, hat der Betrieb zwei schlechte Optionen und keine gute. Also hält der Import den Fortschritt laufend fest, und ein Neustart setzt fort - was auch bedeutet, dass man ihn absichtlich stoppen kann, und damit wird aus einer Sechs-Stunden-Verpflichtung etwas Unterbrechbares.

Hamburger Frachtsätze gelten zu einem Datum

Referenzdaten in dieser Branche sind keine Nachschlagetabelle. Sie sind eine Historie.

Ein Frachtsatz, ein Zuschlag, ein Hafentarif, ein Umrechnungskurs - jeder galt für einen Zeitraum und wurde dann ersetzt. Wird die Zeile an ihrem Platz aktualisiert, verliert das System die Fähigkeit, eine Belastung von vor drei Monaten zu erklären, und im Streit mit einem Kunden ist genau das das Einzige, was jemand wissen will.

Die Lösung ist ein Gültigkeitszeitraum an der Referenzzeile und ein gespeicherter Verweis auf die tatsächlich benutzte Fassung an der Belastung. Ein wenig mehr Schema, und der Unterschied zwischen einer Rechnung, die man verteidigen kann, und einer, für die man sich nur entschuldigen kann. Dieselbe Begründung gilt für Geld und Datumsangaben überhaupt, die zwei Dinge in einem Logistiksystem, die sich nachträglich nicht reparieren lassen.

Ein Hamburger Titel existiert vor dem Erscheinen, und das ist ein Lebenszyklus

Im Verlagswesen hat ein Produkt eine Identität, einen Katalogeintrag und eine Verkaufshistorie, bevor irgendetwas gedruckt ist, und das System muss etwas beschreiben, das es noch nicht gibt.

Ein Titel wird mit vorläufigem Erscheinungstermin, vorläufigem Preis und absichtlich unvollständigen Metadaten angekündigt. Der Handel übernimmt diesen Feed, listet das Produkt und nimmt Vorbestellungen an. Dann verschiebt sich der Termin, was er tut, und alles weiter unten muss davon erfahren. Den Erscheinungstermin als einzelnes Feld zu führen, das jemand überschreibt, verliert die Tatsache, dass er sich verschoben hat - und dass er sich verschoben hat, ist genau das, was das System eines Händlers wissen muss.

Bei Ausgaben und Formaten wird die Hierarchie entschieden. Ein Werk, mehrere Ausgaben, jede mit eigener Kennung, eigenem Preis, eigenen Gebietsrechten und eigener Verfügbarkeit. Hardcover überall verfügbar, Taschenbuch noch nicht, Hörbuch nur in zwei Gebieten, E-Book in einem ausgenommen, weil die Rechte separat verkauft wurden. Eine flache Produkttabelle kann das nicht ausdrücken, und die Rechtedimension ist die, die wirklich Ärger macht, wenn sie fehlt - ein Produkt, das dort angeboten wird, wo es nicht verkauft werden darf, ist ein vertragliches Problem und kein Darstellungsfehler.

Der Metadaten-Feed ist eine Pflicht mit einem Format. Der Handel konsumiert einen strukturierten Datensatz und weist zurück, was nicht konform ist. Der Katalog muss also pro Ausgabe und Gebiet einen gültigen Datensatz erzeugen können und wissen, welcher Händler welche Fassung bekommen hat. Letzteres macht die Frage beantwortbar, warum der Preis auf jener Website falsch ist.

Laravel-Honorarabrechnungen für einen Hamburger Verlag

Honorare sind die Rechnung, an der ein Team lernt, warum versionierte Stammdaten wichtig sind - meistens auf die harte Weise.

Verkäufe kommen aus einem Dutzend Kanälen in unterschiedlicher Granularität und zu unterschiedlichen Zeitpunkten - teils pro Transaktion, teils als Monatssumme, teils abzüglich Remittenden und teils brutto. Das in ein einziges Verkaufsjournal zu normalisieren, mit Quelle und Granularität festgehalten, ist der größte Teil der Arbeit. Eine Summe, die sich nicht zerlegen lässt, ist trotzdem brauchbar - vorausgesetzt, das System weiß, dass es eine Summe ist, und versucht später nicht, sie einem Gebiet zuzuordnen, das sie nie benannt hat.

Remittenden kommen verspätet, und das ist das strukturelle Problem. Eine Abrechnung für das erste Halbjahr geht hinaus, und Rückläufer zu diesen Verkäufen kommen noch Monate danach. Rückstellungen für Remittenden sind die branchenübliche Antwort - ein zurückbehaltener Anteil, später freigegeben - und das ist ein Saldo mit einer Regel dahinter, keine Korrektur, die jemand von Hand vornimmt.

Sätze staffeln nach kumulierten Verkäufen, das heißt ein Satz hängt an der Historie und nicht nur am Zeitraum. Zehn Prozent bis fünftausend Exemplare, danach zwölfeinhalb, gezählt über die Lebensdauer der Ausgabe. Berechnet man das nur aus dem Zeitraum, ist die Antwort für jeden Autor falsch, der eine Schwelle überschritten hat. Berechnet man es aus kumulierten Stück mit dem Schwellenstand pro Ausgabe gespeichert, ist die Abrechnung reproduzierbar - und das ist die Anforderung, denn ein Autor hat ein Recht darauf, seine Abrechnung zu verstehen, und eine Zahl, die niemand erklären kann, ist ein Streit, der darauf wartet zu passieren.

Kaufmännisch

Umfang vor Beginn schriftlich, Preis pro Projekt. Der Rahmen auf Länderebene - was der deutsche Datenschutz von einem Dienstleister verlangt, das E-Rechnungsformat, Hosting - steht auf der Länderseite Deutschland.

Abgerechnet von der Codefacture Yazılım A.Ş. in der Türkei, in Euro, per Überweisung auf ein IBAN-Konto, ohne türkische Umsatzsteuer unter der Befreiung für exportierte Leistungen.