ReWe, Reaktionsverhalten bei aktivierten Belegen

[#1]

Im Programm Kanzlei ReWe gibt es fast überall die Möglichkeit, sich die zum Buchungssatz verknüpfte Belege anzeigen zu lassen. Beim Wechsel der Zeile wird zeitnah der nächste aktuelle Beleg angezeigt.
Das ist eine sehr schöne, wenn nicht sogar geniale Funktion und daher erst einmal ein Dankeschön an die Entwickler.

Leider gibt es aber einen klitzekleinen Schönheitsfehler.

Während sich der Beleg auf dem 2. Monitor aufbaut, ist die primäre Bedienung von ReWe gesperrt.

Konkret beim Anlagenzugang (GWG- Liste)
- [Inventar anlegen] Klick
- neues Inventar ist aufgebaut, und ich möchte den Text editieren
- leider muß ich erst bis zu 3 Sekunden warten, bis sich der Beleg aufgebaut hat, bevor ich das Feld aktivieren kann.

Thema. Blättern durch die Konten.
- bei einem Buchungssatz den Beleg aktiviert, OK. möchte ich sehen, die 3 Sekunden sind akzeptabel.
- Strg Down (Nächstes Konto -> [bitte warten] während sich irgend ein für mich unwichtiger Beleg aufbaut, wird das neue Kontoblatt nicht gefüllt. 

Der Wunsch wäre, daß bei aktivierter Belegansicht das Navigieren durch das Programm nicht ausgebremst wird und sich die Beleganzeige nur noch "bemüht", immer den aktuellen Beleg anzuzeigen.

Techniker, bitte stricken Sie das Programm intern so um, daß die Bedienungsgeschwindigkeit nicht darunter leidet, wenn das belege- Fenster offen ist. in der Realität gibt es Mandanten, die Monster- Belege senden und  es gibt Tage, wo UO oder auch das lokale Internet nicht mit optimaler Performance läuft.

Ein optional aktivierender Workaround wäre, daß sich ReWe im vorauseilenden Gehorsam alle Belege in einen Cache holt, so daß das Arbeiten super- flüssig möglich wäre. 

Nutzen: Auch wenn es immer nur Sekunden sind, jedes Stocken der Anwendung unterbricht den Rhythmus des Workflows und sollte für die gute Ergometrie weg programmiert werden.

Genutzte Hardware: I8700 Clienten am 4,5 GHz- DATEV- Server, alles SSD.
Internet leider nur "normales DSL" 16 MBit über DATEVNET.

[#2]

Der Belegaufbau geht recht zügig vonstatten, ReWe kann hier wenig verbessern, bei lokaler Beleghaltung im DMSclassic sind die Belege zügig da. UO kann ich nicht vergleichen.

[#3]

Ich habe hier auch ein extremes träges Verhalten bemerkt.

Schade finde ich, wenn ein Beleg schon einmal heruntergeladen wurde, und man auf einen anderen Buchungssatz springt, wird dieser wohl gelöscht bzw. prüft nicht auf das Vorhandensein eines Beleges, so dass dieser jedesmal neu geladen wird.

Will sagen:

Wurde ein Beleg schon einmal heruntergeladen, dann sollte dieser im Tmp-Verzeichnis bleiben. Wird ein Buchungssatz ein weiteres mal angesprungen, dann erspart man sich ein erneuten Download. Erst wenn der Vorlauf geschlossen wird, wird das Tmp-Verzeichnis geleert.

Ich weiß nicht, wie oft ich einen Beleg mehrmals herunterladen musste (aus Dummheit oder was auch immer). Schön wäre es auch, wenn man in den Betrachtungsmodus geht, dass immer schon die 10 nächsten Belege vorab heruntergeladen werden, so dass ein flüssiges Kontrollieren von importierten Buchungen aus DUO leichter und flüssiger vonstatten geht.

Aber das werden wohl ewige träume bleiben.

Gruß Achilleus

[#4]

---

@einmalnoch  schrieb:

Der Belegaufbau geht recht zügig vonstatten, ReWe kann hier wenig verbessern, bei lokaler Beleghaltung im DMSclassic sind die Belege zügig da. UO kann ich nicht vergleichen.

---

Ich bin mir fast sicher, daß das Zeit- Problem beim Holen der Belegbilder über das Internet aus Nürnberg liegt und wir hier daran technisch nichts ändern können.

Daher der Wunsch, daß unser lokales ReWe flott weiter arbeitet, auch dann, wenn sich das Belegbild noch auf der Reise befindet.

Sie bestätigen aber, daß ein lokal automatisch gefüllter Cache auch eine Lösung sein könnte.
(einfaches Verschlüsseln der Daten im TEMP- Ordner für den Datenschutz...)

[#5]

@martinkolbergmit dem Cache ist das ja eine Sache, mal gut, mal schlecht. Beim Belegbuchen alle bereitgestellten Belegbilder heruntergeladen werden ist das ja kein Problem, bei der Durchsicht einer Fibu ist die Entscheidung, welche Bilder vorsorglich übertragen werden, schon schwieriger. Ganz und gar wahlfrei wird es bei der Abschlussbearbeitung.

Eben mal aus UO getestet. Der Verbindungsaufbau dauert ca. 15 sek. danach pro Beleg (mit der ominösen Warnmeldung, der Beleg sei groß) ca. 2 sek. Im Vergleich zu DMSclassic langsamer.

Ein umfangreicher Download zum cachen kann aber auch die Kollegen ausbremsen.

PS @martinkolberg Seit Montag Du.

[#6]

lokal verknüpfte digitale Belege werden beim Durchblättern der Buchungen quasi ohne Verzögerung angezeigt

Apropos ....,

wird das Anwendungskürzel "DDMS" im Beleglink auch für die "Dokumentenablage" verwendet ?

Nachtrag:

.... bin gerade selbst auf die Antwort gestoßen

https://www.datev.de/dnlexom/v2/content/documents/1001008/pdf

... früher war für die Dokumentenablage das Anwendungskürzel für die GUID offenbar "DORG" anstatt "DDMS"

[#7]

@einmalnoch ,

... Duzende Mitglieder im "Dialograum Community" ? 🤔

... das lässt hoffen 😁😎

[#8]

Hallo Community,

vielen Dank für Ihre Beiträge zum oben genannten Thema.

Anhand Ihrer Diskussion wird für uns deutlich, dass es unterschiedliche Arbeitsweisen und unterschiedliche Lösungsansätze gibt.

Wir werden uns daher ein paar Gedanken zu Ihren Beiträgen machen und diese in den nächsten Tagen mit Ihnen teilen. 

Mit freundlichen Grüßen

Angelika Roßmeisl
Service Rechnungswesen (FIBU)
DATEV eG

[#9]

wow, die Datev liest, leidet, denkt und teilt mit, danke

... "geteiltes Leid ist halbes Leid" ... oder so ähnlich 😉

[#10]

Hallo zusammen,

vielen Dank auch nochmal von meiner Seite für die Diskussionen. Was ich auf jeden Fall mitgenommen habe, ist, dass Sie das langsame Laden von Belegbildern in einigen Fällen daran hindert, die Buchungssätze im Kontoblatt oder in der Primanota schnell durchzugehen und zu kontrollieren. Der Diskussion konnte ich ebenfalls entnehmen, dass sich das Problem mit der Ladedauer überwiegend auf Belege bezieht, welche in Belege online abgelegt sind.

Wie Sie ja bereits in Ihren Beiträgen angeführt haben, ist die Ladedauer für die Belege u.a. von der Internetverbindung und von der Größe der Belege abhängig. Daher auch noch einmal die Empfehlung von meiner Seite darauf zu achten, dass das Volumen der Belege in einem angemessenen Rahmen bleibt. Beim Scannen haben wir gute Erfahrungen mit einer Auflösung von 300 dpi im Modus schwarz/weiß und dem Dateityp TIF/TIFF oder PDF gemacht. Eine gescannte DIN-A4-Seite sollte also im Durchschnitt ein Volumen zwischen 50 und 100 KB haben.

Wir haben uns aber aufgrund Ihrer Rückmeldung auch angeschaut, ob es einen einfachen Lösungsansatz gäbe. Leider ließe sich ein lokaler Cache nicht ganz so einfach umsetzen. Wie bereits in den Diskussionen angeführt wurde, würde sich hier zunächst die Frage stellen, welche Belege eigentlich gecacht werden sollten. Innerhalb eines Buchungsstapels könnte man vielleicht noch eine Grenze ziehen, doch spätestens beim Blättern im Kontoblatt wäre diese Entscheidung nicht mehr so einfach möglich. Letztlich müssten ggf. alle Belege eines Wirtschaftsjahres heruntergeladen werden. Daher würde sich hier dann auch die Frage ergeben, wann genau sich der Cache aktualisieren sollte. Bei der ersten Anzeige eines Belegs wäre dies dann vermutlich zu spät, weil das Herunterladen wiederum Auswirkungen auf die Performance hätte. Auch der Datenschutz wäre noch ein wichtiges Thema, da auch ein verschlüsseltes TEMP-Verzeichnis nicht dafür genutzt werden könnte, um die Belege über eine längere Zeit zu speichern.

Dennoch würde uns interessieren, wie Sie genau vorgehen und wann genau das DATEV-Rechnungswesen-Programm in Ihren Augen hängt. So können wir prüfen, ob wir ggf. an der ein oder anderen Stelle zumindest eine kleine Optimierung realisieren könnten.

@martinkolberg:
Wenn ich Sie richtig verstanden habe, liegen Ihre Belege in Belege online, ist das richtig?
Können Sie mir insbesondere Ihren Workflow bei der Erfassung eines Inventars noch einmal genau schildern?
Ich muss gestehen, dass ich kein Anlag-Experte bin. Daher wäre es für mich interessant zu wissen, wo genau Sie sich genau befinden, worauf Sie klicken und an welcher Stelle das DATEV-Rechnungswesen-Programm in Ihren Augen hängt.

Mit freundlichen Grüßen

Natalie Bauer

Business Analyst Finanzbuchführung

DATEV eG

[#11]

---

@Natalie_Bauer  schrieb:

@martinkolberg:
Wenn ich Sie richtig verstanden habe, liegen Ihre Belege in Belege online, ist das richtig?
Können Sie mir insbesondere Ihren Workflow bei der Erfassung eines Inventars noch einmal genau schildern?
DATEV eG

---

Hallo Frau Bauer,

wenn ich Herrn Kolberg verstanden habe möchte er das die Beleganzeige nicht modal ist.

---

Während sich der Beleg auf dem 2. Monitor aufbaut, ist die primäre Bedienung von ReWe gesperrt.
...
Der Wunsch wäre, daß bei aktivierter Belegansicht das Navigieren durch das Programm nicht ausgebremst wird und sich die Beleganzeige nur noch "bemüht", immer den aktuellen Beleg anzuzeigen.

---

Das würde eigentlich schon genügen, und man bräuchte sich nicht über einen Cache etc. Gedanken machen 

[#12]

Mittlerweile haben wir unsere internet- Leitung um den Faktor 4 erweitern können.
Leider hat das kaum Auswirkungen auf die Anzeige der Belege, die in UO gespeichert sind.

Wann- und welche Belege vorab gecascht werden sollen, kann nur eine KI erlernen.  
Sicherlich alle Belege im AV- Verzeichnis, wenn ich die Analge- Güter zuordne, aber niemand benötigt die 2.000 Wareneinkaufs- Belege, mit Ausnahme des einen Beleges, welcher mit verkehrtem Steuersatz gebucht wurde.

Wichtig: Die Anzeige läuft bei den Abschluß- Arbeiten im Hintergrund und bremst das Navigieren nicht aus.

Workflow heute:
- Ansicht ein Kontoblatt mit Belegen (links das rote Symbol)
- Navigation per Tastatur durch die Zeilen
- Mangels Shortcut Maus- Doppeltklick auf das Belege- symbol (2 Sek warten)
- Pfeil runter auf die nächste Zeile ohne Funktion, da Cursor im Beleg fest hängt.

- Mausklick in die Zeilen
- Taste runter (Während des "Bitte warten" wird der Tastaturpuffer nicht gefüllt) 
- Strg down ... selbes Problem mit dem Tastatur- Puffer. 

Beleggröße: 18 Seiten Großhandels- tif haben Ihre Größe und dann gibt es die unkomprimierbaren PDF aus dem Mailverkehr. ...

[#13]

---

@Natalie_Bauer schrieb:

Wie Sie ja bereits in Ihren Beiträgen angeführt haben, ist die Ladedauer für die Belege u.a. von der Internetverbindung und von der Größe der Belege abhängig. 

---

Ich kann das Verhalten auch nachvollziehen. Vielleicht nicht in dem Ausmaße wie @martinkolberg ihn mit 3 Sekunden beschreibt aber da wir als Kanzlei bei der DATEV im DATEVasp sind, kann die Internetverbindung nun nicht das Problem sein, wenn man quasi "neben" den Belegen arbeitet und die Belege das RZ nicht mal verlassen müssten. Ob sie das tun, kann ich nicht sagen aber die Belege müssen zumindest nicht via Internet an einen lokalen Standort innerhalb Deutschlands, weil Citrix uns nur die DATEV Ansicht "zurückholt". 

Aber als ich der FiBu Kollegin über die Schulter geschaut habe, die sich auch links den Beleg und rechts die Buchungszeile aufgerufen hat - es war zäh. Dauert für mich zu lange aber ich bin auch ein sehr ungeduldiger Mensch. Für mich kann die gesamte DATEV Performance noch ein gutes Stück zulegen. Viel zu oft sehen wir Ladebalken oder Fortschrittsbalken. 

Wir arbeiten zu 100% mit Belege online. 

---

@Gelöschter Nutzer schrieb:

Schade finde ich, wenn ein Beleg schon einmal heruntergeladen wurde, und man auf einen anderen Buchungssatz springt, wird dieser wohl gelöscht bzw. prüft nicht auf das Vorhandensein eines Beleges, so dass dieser jedesmal neu geladen wird.

---

Volle Zustimmung 👍! Das kann ich nachvollziehen aber technisch leider nicht verstehen.  

---

@martinkolberg schrieb:

Ich bin mir fast sicher, daß das Zeit- Problem beim Holen der Belegbilder über das Internet aus Nürnberg liegt und wir hier daran technisch nichts ändern können.

---

Wie gesagt, im DATEVasp ist's mir auch noch zu lahm. Will heißen: im DATEVasp ist es sicherlich messbar besser als bei Ihnen aber der Knaller ist die Bedienung mit Belegvorschau auch da nicht wirklich. Also zu 100% liegt's nicht an den 16Mbits (und wenn man weiterliest bestätigen Sie das auch schön 😀). Zumal Sie im Router doch sehen können, wie viel davon belegt sind? Ich wette, die werden nie zu 100% ausgelastet sein; auch nicht für ein paar Sekunden. Zumal wir wie @Natalie_Bauer schon schreibt, von maximal 100KB ausgehen. Das sind nun wahrlich keine großen Datenmengen mehr. Schickt das Mandat 1MB pro Rechnung - okay, dann wendet sich das Blatt. 

Die Cache Lösung halte ich im Hinblick auf die Allgemeingültigkeit für schwierig. Wenn DATEV das machen würde, müsste DATEV im DATEVasp / Smart IT ebenso viel extra Speicher bereithalten und aufgrund der Masse an Anwendern wird sich DATEV das gut überlegen, ob das wirtschaftlich ist. Im Client-Server Betrieb ist das ehr egal aber wenn x Tausend DATEV Anwender im RZ gleichzeitig x GB mehr Speicher brauchen, die das Produkterlebnis nur zum Teil verbessern - fraglich. 

EDITH: Als ich die FiBu Software bei einem unserer Mandate gesehen habe (zugegeben ohne verknüpfte Belege), dachte ich: krass, ist das flott 😲. Beim Tipp auf Enter war eine ellenlange Liste an Buchungen sofort da. Neues Konto angegeben, Enter und gefühlt keine 50ms später wieder so eine lange Liste. Und DATEV REWE fühlt sich wie Kaugummi an. Überall leider 😔. 

[#14]

---

@metalposaunist  schrieb:

---

---

Ich kann das Verhalten auch nachvollziehen. Vielleicht nicht in dem Ausmaße wie @martinkolberg ihn mit 3 Sekunden beschreibt aber da wir als Kanzlei bei der DATEV im DATEVasp sind, kann die Internetverbindung nun nicht das Problem sein, wenn man quasi "neben" den Belegen arbeitet und die Belege das RZ nicht mal verlassen müssten. Ob sie das tun, kann ich nicht sagen aber die Belege müssen zumindest nicht via Internet an einen lokalen Standort innerhalb Deutschlands, weil Citrix uns nur die DATEV Ansicht "zurückholt". 

Aber als ich der FiBu Kollegin über die Schulter geschaut habe, die sich auch links den Beleg und rechts die Buchungszeile aufgerufen hat - es war zäh. Dauert für mich zu lange aber ich bin auch ein sehr ungeduldiger Mensch. Für mich kann die gesamte DATEV Performance noch ein gutes Stück zulegen. Viel zu oft sehen wir Ladebalken oder Fortschrittsbalken. 

---

Dieses Reaktionsverhalten ist ja schon als "normal" zu bezeichnen, oder?

Andere Frage: gibt es denn Anwender, bei denen das definitiv nicht zu beobachten ist? 3 Sekunden pro Beleg, da kommt ja je nach Belegaufkommen doch ganz schön was zusammen. Auch wenn es dann weniger als 3 Sekunden wären...

"Flott" ist anders.....

[#15]

@metalposaunist 

Denkfehler, DATEVasp (oder SmartIT) ist ein System, Belege Online ein Anderes. Da geht nichts "nebenher", die Aufrufmechanismen "Web" werden genau so durchlaufen wie von einem in der Kanzlei direkt installierten System. Oder mit anderen Worten ausgedrückt, die Anfrage wird über die Schnittstelle an den Belegspeicher gestellt, der DATEV DNS Server liefert die entsprechende IP zurück und die Anfrage geht raus und zwar über die ganz normalen Webmechanismen, die Transportverbindung ist dabei zu vernachlässigen, viel interessanter sind die Mechanismen auf Seiten der Belegspeicherung. Zunächst die Datenbank abfragen wo denn der angeforderte Beleg steckt, den Beleg im System anfordern und dann ausliefern. Diese Prozesse sind natürlich nicht 1:1 sondern viele fragen an und entsprechend viele sind auszuliefern. Ist halt Web. Beleg ausgeliefert, Verbindung geschlossen. Neue Anfrage (nächster Beleg), das Spiel beginnt komplett von vorn.

Schneller geht es natürlich mit dem Belegspeicher in DMSclassic (oder einem anderen DMS mit dem entsprechenden Connect Modul). Hier beginnt das Spiel mit dem Aufbau der Verbindung (ca. 10s), danach kann dann jeder x-beliebige Beleg innerhalb einer Sekunde angesehen werden.

[#16]

---

@einmalnoch  schrieb:

Denkfehler, DATEVasp (oder SmartIT) ist ein System, Belege Online ein Anderes.

---

So ist es : Datev RZ <> Datev RZ

Es gibt nicht DAS Datev RZ, sondern ganz viele verschiedene Lösungen.

(Edit:Schreibfehler/värbässert)

[#17]

---

@einmalnoch  schrieb:

@metalposaunist 

Schneller geht es natürlich mit dem Belegspeicher in DMSclassic (oder einem anderen DMS mit dem entsprechenden Connect Modul). Hier beginnt das Spiel mit dem Aufbau der Verbindung (ca. 10s), danach kann dann jeder x-beliebige Beleg innerhalb einer Sekunde angesehen werden.

---

Cooler Avatar, @einmalnoch ....,

Das ist dann aber bald Vergangenheit, wenn alles auf DATEV-DMS umgestellt haben, oder?

[#18]

---

@einmalnoch schrieb:

der DATEV DNS Server liefert die entsprechende IP zurück und die Anfrage geht raus

---

Genau das kann man doch DATEV intern per DNS abfangen? 🤔 Wenn das System schon weiß, ich stehe bei der DATEV und ich will zur DATEV gehe ich doch nicht über den DECIX in Frankfurt? War ja nur so eine Idee aber da es im DATEVasp auch mir zu langsam ist, muss Ihre Version technisch wohl stimmen 😬. 

[#19]

Mach doch mal ein tracert

[#20]

Nein, da geht nichts über das externe Netz, der DNS Server routet das schon über das interne Netz der DATEV, aber die ganzen Abfragen und Antworten über das Netz kosten Zeit und Interrupts mit denen sich die Systeme beschäftigen müssen. In der Steinzeit hat man sich über solche Sachen noch den Kopf zerbrochen um die Ladezeiten zu reduzieren, heute wird einfach der Takt erhöht (wirklich? Im RZ ist Takt = Wärme und Wärme ist doof). Viele Unterbrechungen sind dann auch eine Bremse.

Auf der anderen Seite sind die Mechanismen des ausliefernden Systems zu betrachten. Nicht umsonst haben ownCloud und NextCloud gerade diese Mechanismen zur Skalierung auf den Prüfstand gestellt und teilweise neu geschrieben.

[#21]

---

@andreashofmeister  schrieb:

---

---

Cooler Avatar, @einmalnoch ....,

---

Eigentlich als Denksportaufgabe für @metalposaunist gedacht.😉

[#22]

---

@einmalnoch schrieb:

Eigentlich als Denksportaufgabe für @metalposaunist gedacht. 😉

---

Ja, ist jetzt nicht Helene Fischer 🙈 und auch wenn Wikipedia meint, das soll Melodic Death Metal sein - ist jetzt nicht so mein Fall 😬. Metal ≠ Metal 

Was ist mit Bölzer? Oder Mantar? 🤘

[#23]

Wie der Wiki Autor auf Death Metal kommt weiß ich auch nicht. Eher viele Power Einflüsse, die Jungs haben eine nette Live Show und machen einfach Spaß. Wenn es abgehoben sein soll dann eher  Nerved . Aber zum Glück sind die Geschmäcker unterschiedlich.😉

[#24]

... ich habe bei BØLZER & Co. immer unwillkürlich Angst um die Stimmbänder der Sänger und um meine eigenen Trommelfelle.

.... allerdings ist das Eintauchen in allzu 'seichtes Wasser' auch gefährlich 😃

... gut, dass es hier keine Hintergrundmusik gibt, sonst würde man damit viele User verscheuchen.

... es reicht ja völlig, wenn der Ton die Musik macht 😊

[#25]

Die Technik ist schon speziell und belastet die Stimmbänder kaum, es muss aber sehr viel geübt werden.

Einen kleinen Überblick gibt es https://de.wikipedia.org/wiki/Gutturaler_Gesang hier.

Wie @metalposaunist schon schrieb gibt es im Metal für jeden etwas.

Ansonsten sind wir hier im Thread gerade irgenwie falsch abgebogen. Wie war noch mal das Thema? 😀

[#26]

@vogtsburger scheint auf Nina Hagen zu stehen (s. Signatur). Hat die überhaupt noch Stimmbänder...

[#27]

😅😅 ... scharfes Auge, @ManfredLener  😄

Nina kann zumindest (nachweislich auch) singen.

... ich mag es tatsächlich, wenn nicht (nur) brüllen, knurren, schreien und grunzen, sondern auch einzelne Töne mit Her(t)z(-Frequenzen) zu erkennen sind 😄

[#28]

Na, dann ist das hier ein schöner Einsteiger .