Das Controlling will den Umsatz nach Warengruppe über drei Jahre sehen. Die IT verbindet sich mit der ALPHAPLAN-Datenbank, und der Zugang funktioniert auf Anhieb. Dann der Blick in die Tabellenliste: hunderte Tabellen mit kryptischen Namen, keine Beschreibung, keine offensichtliche Logik. Welche enthält die Belege, welche die Positionen, was bedeutet die Statusspalte mit den Zahlen?
Das ist die typische ALPHAPLAN-Situation. Anders als bei vielen Altsystemen ist hier nicht der Zugang das Problem. Das Problem ist, die richtige Tabelle und die richtige Spalte im undokumentierten Schema zu finden.
Was unter ALPHAPLAN wirklich liegt
ALPHAPLAN ERP ist ein deutsches ERP-System der CVS Ingenieurgesellschaft mbH aus Bremen, verbreitet im Großhandel, im In- und Export und bei Fertigungsbetrieben mit Materialschwerpunkt, oft mit angebundenem Onlineshop.
Die gute Nachricht für jeden, der Daten auswerten will: ALPHAPLAN läuft auf dem Microsoft SQL Server. Seit der ALPHAPLAN SQL Edition aus den Jahren 2000 und 2001 ist das der Unterbau, die aktuelle Generation setzt einen SQL Server ab Version 2008 voraus. Es gibt also kein proprietäres Dateiformat, keine fremde Datenbank-Engine, keinen ODBC-Umweg über einen Spezialtreiber. Es ist ein ganz normaler SQL Server, an den sich jedes Standardwerkzeug anschließen lässt.
Damit ist ALPHAPLAN der einfachste Anbindungsfall, den man im Mittelstand antreffen kann. Der Zugang ist Standard. Die Arbeit liegt woanders.
Die eigentliche Hürde: das undokumentierte Schema
Ein ERP wie ALPHAPLAN hat hunderte Tabellen. Ihre Namen sind vom Hersteller vergeben, die Bedeutung der Felder ist nicht öffentlich dokumentiert, und Statuswerte stecken oft als Zahlencodes in den Spalten. Sprechende Tabellennamen wie Kunden oder Belege, die in manchen Anleitungen kursieren, sind in der Regel erfunden und führen in die Irre.
Die eigentliche Aufgabe beim Anbinden von ALPHAPLAN ist deshalb nicht die Verbindung, sondern das Entschlüsseln: Welche Tabelle hält die Belegköpfe, welche die Positionen, wie hängen sie zusammen, was bedeutet eine Belegart oder ein Statuscode. Dieses Wissen kommt aus der ALPHAPLAN-Dokumentation des Herstellers, aus dem Partner oder aus systematischem Reverse Engineering anhand bekannter Vorgänge.
Aus meiner Praxis im norddeutschen Mittelstand: Der häufigste Fehler ist, eine plausibel benannte Tabelle zu finden, daraus eine Auswertung zu bauen und erst Wochen später zu merken, dass es die Tabelle der stornierten Vorgänge war.
Zwei Regeln, bevor die erste Abfrage läuft
Regel eins: nur lesen. Auch wenn der Zugang trivial ist, gehört kein Schreibzugriff auf die Live-Datenbank. Ein eigenes Read-only-Login mit Leserechten auf die benötigten Tabellen, mehr nicht. Direkter Schreibzugriff auf die ALPHAPLAN-Tabellen kann die Konsistenz zerstören und den Herstellersupport kosten.
Regel zwei: auf einer Kopie arbeiten. Für Auswertung und DWH ist der saubere Weg, eine zurückgesicherte Kopie der Datenbank zu nutzen oder einen Read-only-Spiegel, nicht das Produktivsystem direkt unter Last abzufragen. Weil ALPHAPLAN auf SQL Server läuft, ist genau das einfach: ein Backup einspielen und darauf arbeiten ist Standard-SQL-Server-Handwerk.
So sieht der Zugriff aus
Weil ALPHAPLAN nativ auf SQL Server liegt, kannst du direkt aus dem SQL Server arbeiten oder die Tabellen per ODBC in Access verknüpfen. Einen Linked Server oder eine ODBC-Bridge brauchst du dafür nicht.
Das hier ist der Kern einer Auswertung direkt im SQL Server. Der entscheidende Punkt steht im Kommentar:
-- ALPHAPLAN-Tabellen- und Feldnamen sind herstellerspezifisch und nicht
-- öffentlich dokumentiert. <Belegkopf>, <Belegposition>, <Artikel> sind
-- Platzhalter und müssen vorab aus dem Datenmodell ermittelt werden.
SELECT
FORMAT(k.Belegdatum, 'yyyy-MM') AS Monat,
SUM(p.Gesamtpreis) AS Umsatz
FROM [ALPHAPLAN].[dbo].[<Belegkopf>] AS k
JOIN [ALPHAPLAN].[dbo].[<Belegposition>] AS p ON p.BelegID = k.BelegID
WHERE k.Belegart = /* Code für 'Rechnung' aus der Doku */ 0
GROUP BY FORMAT(k.Belegdatum, 'yyyy-MM')
ORDER BY Monat;
Für den Zugriff aus Access reicht eine ODBC-Verknüpfung auf denselben SQL Server. Auch hier gilt: ein Read-only-Login verwenden, nicht den Dienstaccount der Anwendung.
Wenn der Hersteller oder Partner direkten SQL-Zugriff nicht freigibt, bleibt der dokumentierte Weg über die CSV- und Excel-Exporte der ALPHAPLAN-Oberfläche. Beim Import in den SQL Server gilt:
BULK INSERT staging.ALPHAPLAN_Belege
FROM 'D:\alphaplan_export\belege.csv'
WITH (
FIELDTERMINATOR = ';',
ROWTERMINATOR = '0x0a',
FIRSTROW = 2,
CODEPAGE = '1252' -- ältere Exporte sind codepage-basiert, nicht UTF-8
);
Wo der Weg an Grenzen stößt
Bei ALPHAPLAN ist weder Verschlüsselung noch eine fremde Engine das Problem. Die Grenze ist das Schema-Wissen. Wer ohne die Bedeutung der Tabellen und Statuscodes loslegt, baut Auswertungen, die plausibel aussehen, aber falsch sind. Das ist die teurere Variante als gar keine Auswertung, weil man der falschen Zahl glaubt.
Eine Einordnung zur Aktualität: ALPHAPLAN wird aktiv weiterentwickelt und ist im E-Commerce gut etabliert, inklusive Shop- und EDI-Anbindungen. Es gibt also keinen akuten Grund, das System abzulösen. Diese Seite handelt vom Daten-Herausholen für Auswertung und Reporting, nicht vom Wechsel. Ein klassisches offenes REST-API für freie Abfragen bietet ALPHAPLAN nicht, aber für den Auswertungszweck ist der direkte SQL-Zugriff ohnehin der bessere Weg.
Was das für dich heißt, wenn du es nicht selbst baust
Für dich als Geschäftsführer oder Controller ist das eine vergleichsweise gute Ausgangslage. Deine ALPHAPLAN-Daten liegen in einer normalen, modernen Datenbank. Der Aufwand steckt nicht in der Technik des Zugangs, sondern im Verstehen der Struktur und im sauberen, lesenden Arbeiten auf einer Kopie.
Der wirtschaftlich spürbare Unterschied: Einmal richtig entschlüsselt und modelliert, liefert die Anbindung danach jeden Monat verlässlich dieselben Kennzahlen, statt dass jemand sie aus der Oberfläche zusammenklickt und in Excel zusammenrechnet, mit dem Risiko, jedes Mal einen anderen Fehler einzubauen.
Wenn du sowas im Bestand hast
Wenn bei euch ALPHAPLAN läuft und ihr verlässliche Auswertungen oder ein DWH darauf aufsetzen wollt, lohnt sich, das Schema einmal sauber zu entschlüsseln und einen lesenden Zugriff auf einer Kopie aufzusetzen, statt am Produktivsystem zu experimentieren. Wer das einmal aufsetzen lassen möchte, erreicht mich über ein kostenloses Erstgespräch.
Quellen
- Hersteller, Backend (MS SQL Server) und Versionsgeschichte: Software-Wiki – ALPHAPLAN ERP
- Produktinformation des Herstellers: alphaplan.de – ERP-System
Über Sönke Schäfer
Sönke Schäfer berät seit über 25 Jahren norddeutsche KMU bei der Anbindung von ERP- und Branchensystemen an SQL Server und Microsoft Access. Sein Schwerpunkt liegt darauf, aus gewachsenen Beständen wie ALPHAPLAN verlässliche Auswertungen und Data-Warehouse-Strukturen zu bauen — mit besonderem Blick auf das Entschlüsseln undokumentierter Datenmodelle, ohne das laufende ERP zu gefährden. Büro in Sierksdorf, Ostholstein.