Skip to main content

Caches

Zwei Arten von Cache-Typen

  • 10300 Cache Timeout in Minuten (für Bewegungsdaten)
  • 10031 Cache Timeout in Minuten für Stammdaten
Logisth.AI | Allgemeine Einstellungen | Zwei unterschiedliche Caches
Einstellmöglichkeit unter Einstellung | Firma bearbeiten |Allgemeine Einstellungen

 

Die Dauer der Ablaufzeit kann individuell festgelegt werden.

Der Cache ist jeweils spezifisch für eine Funktion, einen Mandanten und ein Geschäftsjahr. Das bedeutet, es gibt tatsächlich viele separate Caches für jede einzelne Funktion, wie zum Beispiel:

  • Alle Mandanten
  • Stammdaten des Mandanten 4711
  • Offene Posten des Mandanten 4712 im Geschäftsjahr 202301
  • Journal des Mandanten 4713 im Geschäftsjahr 202301

Der Cache für alle Mandanten existiert nur einmal, während der Cache für die Mandantenstammdaten für alle Geschäftsjahre gilt.

10300 Cache Timeout in Minuten (für Bewegungsdaten)

• Rechnungen (Journal): Der Cache dient dazu, doppelt gebuchte Rechnungen zu erkennen. Dies führt dazu, dass das erste Laden einer Rechnung länger dauert, da zuerst das gesamte Journal abgerufen werden muss.

• Offene Posten

• Saldenliste und Gewinn- und Verlustrechnung (GuV)

Tipp: Die ideale Einstellung dafür beträgt 4 Stunden.

Im Extremfall kann es vorkommen, dass der Mandant bis zu 4 Stunden lang keine neuen Daten sieht. In der Regel wird der Mandant sich einloggen, und die aktuellen Daten werden geholt, da entweder kein Cache vorhanden ist oder dieser abgelaufen ist. Der Extremfall tritt nur auf, wenn der Mandant seine Daten häufig abruft, unabhängig davon, ob er sich aus- und wieder einloggt.

Der Cache für Mandantendaten wird nur dann aufgebaut, wenn ein Mandant/Fibu über die Benutzeroberfläche abgerufen wird, und dies geschieht jeweils nur für die spezifische Funktion. Daher kann es unterschiedliche Ablaufzeiten für den Cache geben, abhängig von den Anforderungen und Verwendungszwecken, wie das Journal, die offenen Posten usw.

Sonderfälle, in denen der Cache der betroffenen Funktion geleert wird.

• Logisth.AI legt einen Kunden/Lieferanten an oder ändert diesen.

• OP oder Journal wird ein Kunde/Lieferant nicht gefunden.

• Anmeldung eines Mitarbeiters mit einem neu zugeordneten Mandanten, der noch nicht im Cache aller Firmen ist.

• Beim Verarbeiten von Rechnungen (Belegverarbeitung) werden immer die aktuellen Kunden/Lieferanten abgerufen, ohne Cache.

Vorteil längere Cache-Zeiten:

• Schnellere Datenzugriffe, da weniger häufig auf das API zugegriffen wird.

Nachteil längere Cache-Zeiten :

Der Mandant sieht alte Daten, bis der Cache abläuft.

• Veränderungen in den Stammdaten werden erst wirksam, nachdem die Cache-Zeit abgelaufen ist, beispielsweise:

  • Änderungen an der UID oder am Namen.
  • Das Anlegen neuer Geschäftsjahre.
  • Das Anlegen neuer Mandanten.

10031 Cache Timeout in Minuten für Stammdaten

Betrifft:

  • Alle Mandanten
  • Mandant mit Firmenstammdaten und Fibus
  • DMS Info welche Kategorien es gibt
  • Kostenstellen
  • Zahlungsbedingungen
  • VAT posting groups
  • Countries
  • Verantwortlichkeiten
  • Mitarbeiter der Kanzlei
  • Firmenstrukturen
  • Kunden/Lieferanten
  • Sachkonten

Die ideale Einstellung dafür beträgt 1 Tag, wobei die Mindesteinstellung bei 4 Stunden liegt. Werte, die kürzer als 4 Stunden sind, werden ignoriert.

Der Cache wird täglich ab 5 Uhr neu geschrieben, und zwar für alle Mandanten sowie für diejenigen Mandanten, bei denen Belege verarbeitet wurden. Wenn die Cache-Zeit auf 1 Tag eingestellt ist, erfolgt die Aktualisierung daher ziemlich rasch. Dies betrifft:

  • Alle Mandanten
  • Mandant mit verarbeiteten Belegen (Mandantenstammdaten, Fibus)
  • Journal des jeweiligen Mandanten

Das Abrufen aller Mandanten dauert sehr lange und wird bei jeder Funktion benötigt. Datev weist jedem Mandanten eine interne ID zu, die erst geliefert wird, wenn alle verfügbaren Mandanten abgerufen werden. In der weiteren Verarbeitung wird nur mit dieser ID gearbeitet. Zum Beispiel hat der Mandant mit der Nummer 23456 die ID: 45691ece-1f88-403f-8d45-f08016bc60f6.

Der Cache dient dazu, zwei Hauptziele zu erreichen:

a) Die Überlastung der Datenbank/API beim Steuerberater zu reduzieren.

b) Die Geschwindigkeit an der Benutzeroberfläche zu erhöhen, da API-Aufrufe oft zeitaufwändig sind. Durch das Caching können bereits abgerufene Daten schnell wiederverwendet werden, anstatt sie erneut von der API zu beziehen, was die Benutzererfahrung verbessert.