NOVERA.Software

10 · Status

Wo jedes Modul steht.

ModulZustandAnmerkung
FinanzkernIm ProduktivbetriebBuchung, Bank, Ausgleiche, Perioden und Mehrwährungsfähigkeit im täglichen Einsatz
Slowakische UmsatzsteuerLive, Meldungen angenommenVoranmeldung, Kontrollmeldung und beide XML-Exporte; die Übermittlung bleibt bewusst manuell
Berichtswesen18 Berichte liveAktuelle Arbeit: Abgleich der verbleibenden Berichte mit ihren Originalen
Document AILiveDer lernende Speicher läuft mit einem integrierten Regelsatz; seine Tabelle ist optional
E-Mail & KI-TriageLivePostfach, Triage, Übersetzung und die Warteschlange für Lieferantenrechnungen
InvestmentsGebaut, Schema ausstehendPhase eins abgeschlossen; Hauptbuchbuchung und Broker-Import für Phase zwei vorgesehen
MessagingGebaut, Schema ausstehendKern und Echtzeit geliefert; Reaktionen, Suche und Vorlagen folgen
Benachrichtigungen & PushGebaut, Schema ausstehendPlattform vollständig; benötigt ihre Tabellen und ein Schlüsselpaar, um live zu gehen
Planer & NotizenLive, in ErweiterungKalendersuche und ausführliche Detailansicht in diesem Monat ausgeliefert

Plattformbeschreibung

Wo das System steht

NOVERA v2.0 ist live, trägt reale Benutzer und reale Meldungen, und die wichtigsten Teile wurden sowohl an der Realität als auch an Tests verifiziert. Die Summen- und Saldenliste wurde über zweiundsiebzig Konten mit dem Vorgängersystem verglichen und ergab keine Differenzen. Die Umsatzsteuermeldungen wurden anhand von sechs angenommenen Übermittlungen spezifiziert. Die Regeln für das Auslesen von Belegen reproduzieren die eigenen durchgerechneten Beispiele des Unternehmens auf den Cent genau. Der Belegungsbericht stimmt nun Zeile für Zeile mit dem Bericht überein, den er ersetzt.

Warten auf Schemaskripte. Diese Module sind im Code vollständig und verlassen ihren noch nicht konfigurierten Zustand, sobald ihre Skripte ausgeführt sind:

  • Benachrichtigungen und Web Push;
  • Messaging;
  • Teile von Investments;
  • die KI-Lektionstabelle.

Durch das Warten geht nichts verloren, und jede Maske sagt klar, dass sie für diesen Mandanten noch nicht eingeschaltet ist.

Vier offene Punkte, die im Blick bleiben sollten:

  • Ein Datenbankindex auf der Hauptbuchtabelle. Er ist die dauerhafte Lösung für die Ausgleichsabfragen hinter den Kennzeichen "bezahlt" und "gleicht aus". Ohne ihn führen diese Abfragen Scans durch, und bei einem wachsenden Hauptbuch werden sie irgendwann ihr Zeitlimit überschreiten und scheitern, ohne dass ein Fehler sichtbar wird. Es handelt sich um eine Schemaänderung, die daher auf die Zustimmung des Projektinhabers wartet.
  • Der blinde Fleck beim Testen von SQL. Der Build-Container betreibt keine Datenbank, daher werden Abfrageänderungen durch Inspektion und statische Zusicherung nachgewiesen, bis sie auf den Produktivkatalogen laufen. Das hat schon reale Mängel verursacht. Die Methode berücksichtigt es, doch es bleibt der schwächste Punkt der Kette.
  • Reproduzieren einer eingereichten Umsatzsteuervoranmeldung. Eine eingereichte Voranmeldung kann nach einer Änderung derzeit nicht reproduziert werden, weil die Felder live neu berechnet werden und das übermittelte XML nicht gespeichert wird. Das Speichern der eingereichten Zahlen würde diese Lücke schließen.
  • Versionskontrolle. Das Projekt steht nicht unter Versionskontrolle. Das war eine wohlüberlegte Entscheidung, und die Hash- und Ausgangsbasis-Disziplin dient dem Ausgleich, doch es bleibt der eine Bereich, in dem ein Fehler am schwersten rückgängig zu machen ist. Das Thema sollte in einer ruhigen Woche erneut aufgegriffen werden.

Als Nächstes: das Berichtsregal, bei dem die nächste Arbeitsrunde wieder ansetzt.