Zwischen den Codezeilen - Teil 1: Von der Idee zum Feature
22. August 2025
🔘 „Könnt ihr da nicht einfach noch einen Knopf einbauen?“
Wenn’s nur so einfach wäre. Die Reise von einem Wunsch zur fertigen Lösung beginnt meist lange vor dem ersten Mausklick - und führt durch Diskussionen, Skizzen, technische Abklärungen, Architekturüberlegungen und viele Entscheidungen im Hintergrund. In diesem ersten Teil unserer Serie „Zwischen den Codezeilen“ zeigen wir, was passiert, bevor ein neues Feature live geht. Mit dabei: ein echtes Beispiel aus der Praxis - der digitale Rückschubschein für Festlieferungen.
💡Der Auslöser: Ein echter Kundenbedarf
Viele unserer Kunden beliefern regelmässig Feste - mit Getränken und Leihmaterial wie Festbänken, Zapfanlagen oder Kühlwagen. Nach dem Fest wird zurückgeholt, was nicht konsumiert oder nur ausgeliehen wurde. Klingt einfach - ist es aber nicht. Der bisherige Prozess war komplett analog: Ein Lieferschein, zwei Ausdrucke - einer für die Lieferung, einer als Rückschubschein mit leeren Feldern für handschriftliche Rückerfassung. Der Wunsch war klar: Bitte digitalisieren. Aber ohne, dass sich alles verändert.
🧠Der Denkprozess: Von der Idee zur Planung
Bevor wir etwas entwickeln, müssen wir verstehen:
- Was ist das eigentliche Ziel?
- Wie wirkt sich das auf bestehende Prozesse aus?
- Welche fachlichen und technischen Abhängigkeiten sind zu beachten?
Beim Rückschub ging es nicht nur um Rücknahmen - sondern um Tourenplanung, Logistik, Lagerbewegungen, Fakturierung, Statistiken und Benutzerführung. Alles musste möglichst nahtlos ineinandergreifen, ohne dass sich der gewohnte Ablauf auf Kundenseite komplett ändert.
Solche Anforderungen besprechen wir intern in sogenannten Refinements. Entwicklung und Projektleitung bringen dabei fachliche und technische Perspektiven zusammen. Daraus entsteht ein Lösungsraum mit verschiedenen Varianten, Aufwandsschätzungen und Risiken.
⚙️ Die Architekturfrage: Wie bauen wir das möglichst schlank?
Zwei Hauptszenarien standen zur Diskussion:
- Ein zusätzliches Rückschubdatum im bestehenden Lieferschein
- Ein neuer Belegtyp „Rückschubschein“ als Folgedokument
Beide Varianten hatten weitreichende Folgen:
Beim Rückschubdatum wären neue Probleme entstanden - etwa in der Tourenplanung oder bei der Frage, auf welches Datum Umsätze und Bewegungen geschrieben werden. Ein neuer Belegtyp hätte die Fakturierung, Belegflüsse und Reporting-Logiken verändert - technisch lösbar, aber aufwändig. Und für unsere Kunden wären neue Prozesse und Schulungen notwendig gewesen. Dann kam die pragmatische Idee: Was wäre, wenn wir einfach den bestehenden Belegtyp Lieferschein nutzen - aber ihn mit einem Flag„Warenrücknahme“ versehen? Plötzlich drehte sich die Diskussion:
- Das Rückschubdatum entspricht dem Belegdatum des neuen Lieferscheins
- Die Rücknahme erscheint separat in der Tourenplanung
- In der Logistik-App läuft sie als Wareneingang, obwohl es ERP-seitig ein Verkaufsprozess bleibt
- Sammelrechnung: Die beiden Lieferscheine lassen sich bequem zusammenfassen - wie man’s von Monatsrechnungen kennt
Die Lösung war klar: Minimalinvasiv, elegant und robust. Und: Keine bestehenden Prozesse mussten gebrochen werden. Dieses kleine Häkchen („Warenrücknahme“) löst gleich eine ganze Reihe von Herausforderungen.✅
🔧Die Umsetzung: Neue Funktion, vertrauter Ablauf
Der Rückschubschein wird nun als zweiter Lieferschein mit Flag „Warenrücknahme“ erstellt. Er hat ein eigenes Datum, taucht in der Tourenplanung auf, läuft im Logistikprozess als Wareneingang - und wird fakturiert wie gehabt. Und weil wir gerade dabei waren, haben wir noch einen draufgelegt: VinX kann jetzt automatisch einen Warenrücknahme-Beleg aus allen Fest-Lieferscheinen erzeugen. Basierend auf dem Ereignis „Fest“ wird ein Rücknahmeschein erstellt, die Positionen werden genullt und dann mit den effektiven Rücknahmen ergänzt. Was fehlt oder beschädigt ist, erkennt VinX automatisch - und verrechnet es.
🧭Fazit: Zwischen Idee und Umsetzung liegt viel Handwerk
Bevor die erste Zeile Code geschrieben war, haben wir:
- das Problem analysiert
- technische und fachliche Abhängigkeiten geklärt
- Aufwand und Risiken bewertet
- verschiedene Architekturansätze entwickelt
- mehrere Varianten durchdacht - und verworfen
Was am Ende einfach aussieht, ist das Ergebnis vieler Diskussionen, viel Know-how - und viel Liebe zum Detail. Im nächsten Teil nehmen wir euch mit in die technische Umsetzung: Wie wird aus einem Architekturkonzept funktionierender Code? Wie testen wir? Wo schleichen sich Bugs ein? Und wie arbeitet unser Team in Iterationen zusammen? Bleibt dran - wir gehen weiter zwischen die Codezeilen.
