Danke, Sie haben sicher recht mit der Community. Ich bitte meinen Gefühlsausbruch zu entschuldigen. Eine gewisse Ungeduld rührt auch daher, dass ich (nachdem ich in Erklärvideos und diversen Hilfedokumenten zum Thema SKR42 nicht fündig geworden war) inzwischen auch in einem SKR42-Online-Workshop diese Frage stellte, wo sie aber meiner Wahrnehmung nach teils falsch verstanden, teils (möglicherweise aufgrund des Zeitdrucks) übergangen wurde.
Für siebenstellige Sachkontonummern wie in SKR14 finde ich eine Art Tausendertrennzeichen für den Lesefluss jedenfalls sinnvoll, aber bei fünfstelligen Kontennummern ausgerechnet die letzte Ziffer abzuheben, darüber lässt sich trefflich streiten: Ist denn nicht nach der Logik des Kontenrahmens theoretisch jede signifikante Stelle hinter der ersten Ziffer als Untergruppe des aus den vorhergehenden Ziffern gebildeten Bereichs begreifbar, weil sich hierdurch auch komplexe Kontenbereiche einfach darstellen lassen? Besteht bei Abhebung einer einzigen Ziffer (statt einer Dreierreihe wie in SKR14) nicht umgekehrt die größere Gefahr, die letzte Ziffer als "weniger wichtig" zu übersehen und dadurch Fehler zu begehen - gerade wenn man SKR49 (vierstellig) auf SKR42 (fünfstellig) wechselt? Mein Verdacht ist, dass die letzte Ziffer in SKR42 abgehoben wird, könnte einer "Weder Fisch noch Fleisch"-Strategie entstammen, um den Wechsel von den vierstelligen Sachkonten in SKR49 zu verschlimmbessern.
Aber wie Sie sagen, das eigentliche Problem ist die unterschiedliche Umsetzung an verschiedenen Programmstellen. Ich finde einfach, Datev sollte an allen Stellen die "harten" Leerzeichen entfernen, da diese das mathematische Zahlenformat sprengen und entsprechende Zahlenoperationen sabotieren; und optische Abhebungen, wenn schon, dann konsequent durch Formatvorlagen vornehmen. Eine klare Trennung von ästhetischer Form und Inhalt (=das, was z.B. bei Copy&Paste als Plaintext rauskommt).
(Oder eben eine Option, diese Trennzeichen-Zwangsbeglückung zu deaktivieren.)
