Sage 100 erweitern: AppDesigner, eigenes Modul oder externe API – wann was?

„Können wir das in Sage abbilden?" ist eine der häufigsten Fragen, die wir hören. Die ehrliche Antwort lautet fast immer: ja – und es gibt mehrere Wege dorthin. Welcher der richtige ist, hängt weniger von der gewünschten Funktion ab als davon, wie tief sie in den ERP-Kern hineingreift, wer sie pflegen soll und wie lange sie tragen muss.

Wir sehen in der Praxis drei Hauptwege: den AppDesigner, ein eigenes Sage-Modul und eine externe Anwendung mit API-Anbindung. Jeder Weg hat seinen Sweet Spot.

1. AppDesigner – wenn die Logik nah am Standard bleibt

Der AppDesigner ist das Werkzeug der ersten Wahl, wenn Sie bestehende Masken erweitern, Pflichtfelder ergänzen, Plausibilitäten einbauen oder einfache Berechnungen ergänzen wollen. Er ist mit dem Standard-Updateweg von Sage kompatibel und erlaubt Ihren Power-Usern, viel selbst zu erledigen.

Stark, wenn:

die Anpassung sich auf Standard-Entitäten bezieht (Kunden, Belege, Artikel)
die Logik im Wesentlichen Eingaben validieren oder Felder ableiten heißt
die Anpassung von Mitarbeitern mit Sage-Kenntnis gepflegt werden soll

Schwächt sich, wenn:

mehrere Entitäten in komplexen Workflows verwoben werden müssen
viel benutzerdefinierte Oberfläche entsteht (eigene Dialoge, mehrstufige Assistenten)
Performance ein Thema wird – AppDesigner ist nicht für hochfrequente Massenoperationen gebaut

2. Eigenes Sage-Modul – wenn die Logik tief im ERP wohnen soll

Ein eigenes Modul, entwickelt mit dem Sage-SDK gegen die Office Line bzw. Sage 100 API, ist die richtige Wahl, wenn die fachliche Logik fester Bestandteil des täglichen Sage-Erlebnisses sein soll: eigene Funktionsbereiche, neue Auswertungen, eigene Dialoge, Hintergrundprozesse, die im ERP-Server laufen.

Stark, wenn:

die Anwender ohne Wechsel die Funktion nutzen sollen
tiefe Integration in Belegerfassung, Buchung, Lagerbewegung gefragt ist
Sie eine Lösung wollen, die sich „wie Sage anfühlt"

Schwächt sich, wenn:

Web- oder Mobile-Zugriff zentral gefordert ist
die Lösung außerhalb der Sage 100 Installation genutzt werden soll (z. B. Lieferanten, Kunden)
Sie schnell iterieren wollen – jede Änderung braucht ein Sage-Deployment

3. Externe Anwendung mit API-Anbindung – wenn andere Anwender oder Kanäle dazukommen

Web-Portale, mobile Apps und neue Dienste rund um Sage entstehen am besten als eigene Anwendungen, die Sage über eine API ansprechen. Sage bleibt das System of Record, die externe Anwendung übernimmt die Aufgabe, für die sie gebaut ist – sei es ein Self-Service-Portal für Lieferanten, eine Außendienst-App oder ein Dashboard für die Geschäftsführung.

Stark, wenn:

Nutzer außerhalb des Sage-Umfelds zugreifen sollen (Kunden, Lieferanten, Außendienst)
Sie auf moderne UI-Patterns angewiesen sind (Mobile, Offline, Echtzeit)
die Lösung sich schnell weiterentwickeln soll, ohne den ERP-Kern zu berühren

Schwächt sich, wenn:

Sage-Anwender intern die zentrale Zielgruppe sind (dann lieber Modul)
der API-Layer instabil ist – hier muss man bewusst architektonisch sauber arbeiten und die Datenhoheit klar regeln

Die eigentliche Frage: Wer soll es in fünf Jahren noch verstehen?

Technologie-Entscheidungen werden im Mittelstand zu oft nach Bauchgefühl gefällt – „der Externe baut das eben". Die wichtigere Frage ist: Welcher Weg ist in fünf Jahren noch wartbar, mit dem Personal, das Sie dann haben werden?

Unsere Faustregel:

AppDesigner-Anpassungen sollten dokumentiert sein, aber dürfen ruhig „Bordmittel" bleiben.
Eigene Module gehören in ein Versionsverwaltungssystem, mit Build-Skripten und automatisierten Deployments.
Externe Anwendungen brauchen klare Schnittstellenverträge zur Sage 100, idealerweise mit einem Adapter, der entkoppelt von beiden Seiten weiterentwickelt werden kann.

Wenn Sie mit einer konkreten Anforderung im Kopf kommen, helfen wir Ihnen, den passenden Weg zu finden – und ehrlich davon abzuraten, wo eine Lösung später wartungsteurer wäre, als sie heute aussieht.