1C-Konfigurationsarchitektur-Probleme für Entwickler

Kritische Schwachstellen in der Architektur standardmäßiger 1C-Konfigurationen

Standard-1C-Konfigurationen lagern Geschäftslogik häufig direkt in Formulare aus und beschränken die Ausführung auf die Client-Umgebung. Prozeduren in Formularen und Objektmodulen sind selten als exportiert gekennzeichnet, was einen direkten Aufruf ohne Erweiterungen verhindert. Funktionen sind eng gekoppelt und stark vom Formularkontext abhängig, was gegen das Prinzip der Isolation verstößt.

Typische Beispiele für diese enge Kopplung sind:

• Das Laden von Kontoauszügen ist nur über eine Listenansicht oder ein Dokumentformular möglich.
• Das Abrufen von Organisations- oder Partnerdaten über die Steuernummer ist an UI-Elemente gebunden, was Entwickler zwingt, Code zu duplizieren, wenn Objekte programmatisch erstellt werden.

Dieser Architekturansatz behindert die Wiederverwendbarkeit von Modulen und das Testing erheblich.

Irrationale Nutzung von Serveraufrufen

1C-Entwickler greifen oft übermäßig auf Module mit dem Suffix _ServerCall_ zurück und duplizieren dabei Aufrufe identischer Prozeduren. Funktionen in gemeinsamen Modulen werden direkt auf dem Server aufgerufen, ohne das Flag „Serveraufruf“ zu setzen, nur um sie anschließend erneut über Proxy-Module mit aktiviertem Flag aufzurufen. Dies vervielfacht die Codebasis unnötig.

Dutzende solcher Module in Standardkonfigurationen überfordern Entwickler. Ein saubererer Ansatz wäre, serverseitige Prozeduren einfach über das Schlüsselwort Export freizugeben und redundante Wrapper zu eliminieren.

Monströse Abfragen statt lesbarem Code

Die Datenextraktion erfolgt überwiegend über Datenbankabfragen, selbst wenn Objektmethode ausreichen würden. In Dokumentverwaltungsmodulen generieren Abfragen Druckdaten, doch bei der Berechnung von Registerbewegungen schwellen sie zu unleserlichen Konstrukten an, die voller Joins und bedingter Verzweigungen stecken.

Dies opfert die Lesbarkeit zugunsten eines deklarativen Stils und erschwert das Debugging sowie zukünftige Anpassungen. Eine bessere Alternative ist die Kombination von Abfragen mit imperativer Logik innerhalb von Prozeduren.

Mehrdeutige Datenstrukturen

Bei der Erstellung von Druckvorlagen werden häufig mehrere Tabellenblätter zu einem einzigen Dokument zusammengeführt, getrennt durch Bereiche (_Dokument1_, _Dokument2_), anstatt korrekte Sammlungen zu übergeben. Diese Sammlungsstrukturen imitieren Objekte, doch ihre Feldzusammensetzung ist oft unlogisch und erfordert manuelles Mapping bei Anpassungen.

Chaotische asynchrone Ketten

Asynchrone Aufrufketten in 1C sind schlecht dokumentiert: Prozedurnamen liefern keinen beschreibenden Kontext, Kommentare fehlen. Das Debugging der Verarbeitung von Kassenbons ist ein klassisches Beispiel – eine lange Abfolge von Aufrufen ohne klaren Einstiegspunkt.

Die optimale Lösung ist eine Zustandsmaschine (State Machine) mit einem aktuellen Statusparameter, der die Aufrufe entsprechend steuert.

Pseudocode-Beispiel für eine Zustandsmaschine:

Procedure ExecuteAction(CurrentStatus) Export
    If CurrentStatus = "Initialization" Then
        InitializeReceipt();
        TransitionToStatus("Forming");
    Else If CurrentStatus = "Forming" Then
        GenerateReceipt();
        TransitionToStatus("Printing");
    // Und so weiter
    EndIf;
EndProcedure

Fehlendes sicheres Debugging

Kritische Operationen, wie die Interaktion mit Fiskalgeräten, unterstützen keine Antwortemulation. Der Code erwartet echtes Hardware-Feedback, was virtuelle Tests ausschließt. Dies erhöht die Risiken während der Entwicklung und Integration erheblich.

Instabile Benennung und Refactoring

Anwendungsobjekte, Module und Felder werden häufig umbenannt, manchmal mit dem Präfix _Delete_. Eine Suche nach _Delete_ in der Konfiguration liefert Hunderte von Ergebnissen. Terminologie wie „Partner/Gegenparteien/Käufer“ ist inkonsistent, und Entitäten (z. B. Acquiring-Verträge) werden ständig zusammengeführt oder aufgespalten.

Dieser Ansatz spiegelt impulsive Architekturentscheidungen wider und zwingt Entwickler dazu, Zeit für die Migration von Referenzen zu verschwenden.

Inkonsistente Schnittstellen

UI-Elemente verwenden stark variierende Namenskonventionen: Eine Hinzufügen-Schaltfläche in einem Tabellenabschnitt könnte _InventoryAdd oder einfach _Add heißen. Die rechte Spalte eines Dokuments könnte _RightColumn oder _HeaderRight lauten. Diese Inkonsistenz behindert die Automatisierung und die Entwicklung von Erweiterungen.

Ineffiziente Algorithmen

Trotz eines starken Fokus auf Leistung enthält die Codebasis erheblichen Ballast. Beim Drucken von Rechnungen werden alle Vorlagen im Voraus geladen, obwohl nur wenige benötigt werden. Ein bedarfsgesteuertes Caching würde den Overhead in 99 % der Fälle reduzieren.

Duplizierte HTTP-Funktionalität

Verschiedene Teams implementieren HTTP-Anfragen isoliert (für direktes Banking, Website-Synchronisation usw.) ohne einen einheitlichen Abfangpunkt. Es fehlt ein standardisierter Proxy für eine zentrale Konfiguration.

Funktionale Defekte

Standardlösungen scheitern oft in der Praxis aufgrund zu vereinfachter Annahmen der Systemarchitekten.

Probleme bei der Kostenberechnung

Der Wechsel zur monatlichen Abrechnung funktioniert für die Großproduktion, schafft aber Engpässe für den Einzelhandel und mittelständische Unternehmen: negative Periodenendbestände blockieren die Kostenberechnung vollständig.

Hardware-Einschränkungen

Das Verbot von zwei Registrierkassen an einem einzigen Arbeitsplatz ist ein Paradebeispiel dafür, wie geschäftsfreundliche Optimierungen blockiert werden.

Falsche Bonusverbuchung

Auslaufende Boni erfordern eine Chargenverfolgung, doch 1C greift standardmäßig auf Durchschnittsmethoden zurück, was zu Berechnungsfehlern führt. Version 2.5 verschärft das Problem noch und macht die Funktionalität ohne eine vollständige Neuentwicklung unbrauchbar.

Veraltetes Zugriffsrechte-Modell

Rollen basieren auf statischen Checkboxen und ignorieren die dynamische Codeausführung. Vollständige Zugriffsrechte beinhalten versehentlich administrative Privilegien, was regulären Benutzern erlaubt, Konten zu erstellen oder die gesamte Datenbank herunterzuladen.

Wichtige Erkenntnisse

• Architektonische Starrheit: Enge Kopplung an Formulare und Kontext schränkt die Wiederverwendbarkeit stark ein.
• Code-Duplizierung: _ServerCall_-Module vervielfachen die Logik unnötig.
• Unleserliche Abfragen: Monolithische Abfragen ersetzen saubere Objektmethode.
• Keine Emulationsunterstützung: Das isolierte Testen fiskaler Operationen ist unmöglich.
• Instabile Benennung: Hunderte von _Delete_-Elementen erschweren die langfristige Wartung.

— Editorial Team