Gibt es eine Logik hinter den Datev-Produkt-Versionsnummern oder ist das ein Geschäftsgeheimnis ?

[#1]

Hallo @Datev-Community und @Datev,

ich muss zugeben, dass ich mit den diversen Datev-Produkt-Versionsnummern schon immer 'auf Kriegsfuß' stand.

Heute hätte mir ja ganz plötzlich 'ein Licht aufgehen' können, aber nein ... falsch gedacht

... zwei kleine Beispiele gefällig ?

Produkt:
Tool EBS-Konvertierung V.7.51.4 Service-Release
Es ist die ältere Version V.7.5.98 installiert

Produkt:
ISWL Beleg2Buchung V.1.4.5
Es ist die ältere Version V.1.31.3 installiert

habe ich etwas verpasst, obwohl ich immer regelmäßig und immer vollständig und netzweit zu aktualisieren glaube ? 🤔

Ich sehe einfach keine fortlaufenden Versionsnummern, sondern Lücken und Sprünge.

Vermutlich würde ein FA-Prüfer solche Lücken auch bemängeln, falls es Rechnungsnummern wären 😎

... oder ich erkenne einfach die 'innere Logik' nicht

Falls es aber doch eine einfache Lösung für dieses Rätsel gibt, muss ich wohl oder übel bei mir einen 2-stelligen IQ vermuten

Apropos,

am Beispiel des Tools "EBS-Konvertierung" irritiert mich, dass dieses Tool angeblich immer noch in das Datev-Postversandformat konvertiert.
🤔

Hat sich die Abkündigung des Postversandformats (etwa im Jahr 2016) bei den Datev-Entwicklern noch nicht herumgesprochen ? 

Vielleicht spricht sich die Abkündigung des Telemoduls ebenfalls nicht so schnell herum.

Dann funktioniert das Telemodul vielleicht ja noch ein paar Jahre 😅😎

[#2]

... ich muss mich korrigieren:

das Postversandformat wurde 'erst' zum Jahreswechsel 2017/2018 'eingestampft'

https://www.datev.de/web/de/aktuelles/datev-news/postversandformat-und-bisheriges-rechnungswesen-format-werden-eingestellt/ 

... außerdem hat sich das Tool inzwischen doch entschlossen, die Buchungssätze im Datev-Format zu exportieren

(es ist also keine offizielle "Gegendarstellung der Datev" erforderlich !  

Die Erwähnung des Postversandformats ist also bloß eine 'Reminiszenz' an alte Postversandformat-Zeiten 😅 )

[#3]

DATEV weiß um das Problem und will es langfristig lösen. Es ist/war angedacht es aufs aktuelle Jahr zu beziehen, sodass es ein REWE 2022 und ESt 2022 und, und und gibt. Wann DATEV das so umsetzt oder ob überhaupt, fraglich. 

[#4]

ein Versionsnummern-System, das vermutlich jeder (sogar ich) verstehen würde, wäre z.B. das Datum der Veröffentlichung also z.B. "Kanzlei Rechnungswesen Version 2022-04-13"

Die interne Versionsnummer (für die Entwickler) könnte ja sonst irgendwo im Code oder an anderer Stelle stehen, z.B. als Build-Nr. 

... dieses Chaos mit den Versionsnummern ist jedenfalls ein ewiges Ärgernis

Immer wenn man sich (z.B. am Telefon) gegenseitig informieren muss, von welcher Programm-Version man spricht, fängt die Sucherei an und man hat kein Gefühl dafür, wie alt ein Versionsstand ist 

Will denn die Datev diese nützlichen Informationen möglichst so verklausulieren, dass niemand mehr durchblickt ?

... möglicherweise kennt jeder einzelne Datev-Entwickler die Versionsnummern des einen Produkts, mit dem er sich langfristig beschäftigt, aber nicht die eines anderen Kollegen.

... ich kapier es nicht !

Ich glaube, ich muss doch mal an einem Fortbildungslehrgang zum "Datev-Versions-Coach" teilnehmen

Nachtrag:

... dann könnte ich, mit einem entsprechenden Datev-Zertifikat bewaffnet, Schulungen und Seminare auf der Basis der Datev-Consulting-Stunden-und Tagessätze anbieten 

[#5]

... noch ein kleines Beispiel, das in Kürze Sammlerwert haben wird (wg. Abkündigung des Telemoduls)

Bereitstellung	Produkt
Service-Releases 17.02.2022 zu DATEV-Programme V.15.0	Telemodul DÜ Rechnungswesen SR V.12.34
Service-Releases 30.12.2021 zu DATEV-Programme V.15.0	Telemodul DÜ Rechnungswesen V.12.3
DATEV-Programme V.15.0 (August 2021)	Telemodul DÜ Rechnungswesen V.12.1

[#6]

Hallo @vogtsburger ,

Eine Versionsnummer ist bei DATEV folgendermaßen aufgebaut:

[m]n.n[m][X].z

Wertebereiche

m: beliebige Ziffer >0 

n: beliebige Ziffer

X: beliebiger Großbuchstabe (Buchstaben kennzeichnen Pilotversionen).

z: beliebige Zahl im Wertebereich von 1-9999

Damit ist, in Ihrem Beispiel 

ISWL Beleg2Buchung V.1.4.5 gleichbedeutend mit ISWL Beleg2Buchung V.1.40.5 bzw.

Tool EBS-Konvertierung V.7.5.98 gleichbedeutend mit Tool EBS-Konvertierung V.7.50.98 

ich hoffe ich konnte zur Klärung beitragen. 

mit freundlichen Grüßen,

Katrin Zahlten

[#7]

Hallo Frau @Katrin_Zahlten ,

danke für die Aufklärung.

Man nimmt natürlich, was man 'kriegt', aber trotzdem fragt man sich bzw. frage ich mich, warum es Versionslücken gibt ?

Hat man einzelne Verbesserungen bzw. Versionen verpasst oder ist der D-Zug der Datev-Entwicklung über einen hinweggerauscht ?

Spielen die 'Lückenbüßer'(-Versionen) noch irgendeine Rolle oder wurden sie intern bereits 'entsorgt' ?

[#8]

Hallo @vogtsburger ,

das wird im Haus m.W.n. unterschiedlich gehandhabt. Es ist allerdings durchaus üblich zum nächsten größeren Release etwas 'Puffer' vorzusehen, falls vor Auslieferung des geplanten Releases eine Fehlersituation auftaucht, die zwischen geschoben werden muss.

mit freundlichen Grüßen,

Katrin Zahlten

[#9]

Danke, das klärt die Struktur gut auf.

Die optionalen "Ziffern" Felder sind dennoch irritierend.

Vorschlag: Alle "Ziffern" Felder verbindlich ggf. mit 0 füllen - außer vielleicht die führenden Nullen. Dann würden die Zahlen zwischen den "." immer auch in ihrem Wert der Versionsreihenfolge entsprechen.

Glaube nicht, dass diese ggf. notwendigen zusätzlichen Nullen praktisch irgendwie schaden würden, außer dass dann die Versionsnummer bis vor "[X].z" immer gleich groß wäre.

PS: die Ziffern sind sicher alle unabhängig, also: "[m]n.n[m]" -> [o]p.n[m] 😉!

Viele Grüße

[#10]

"das wird im Haus m.W.n. unterschiedlich gehandhabt"

Sehr professionell. Das macht Mut für die Zukunft der Software....

ERNSTHAFT?

[#11]

Aus dem HAndbuch eines Softwareentwicklers:

Jede Codeveränderung schlägt sich in der Versionisierung nieder.

ESt 25.1

Setzt sich z.B. aus ESt V 10.55 Build 51
und Steuern Grundmodul V 10.55 Build 52
Elster-Modul V 35.4 (35.4.2.00000)

Die Datev (zumindest sehe ich das seit ein paar Jahren so) zählt die ersten beiden Module "Zahlenmäßig" zusammen und kommt somit auf ihre Version 25.1.
Die einzelnen Module hingegen verfolgen typische Klassifizierungen.
Gibt es simple einfache Änderungen (Eine Eingabe Maske muss z.B. aus optischen gründen angepasst werden) Verändert sich die Versionsnummer Ganz am Ende 10.55.xxxx.
Je kleiner die Änderung desto weiter hinten ändert sich die Zahl.

Kommen weitere "größere" Änderungen hinzu ändert sich die mittleren Zahlen 10.XX.0000

Kommt es zu einer kompletten Neuprogrammierung oder grundsätzlichen Anpassungen ändert sich vorne die Zahl XX.55.00000 .

Nun muss man auch bedenken, dass nicht jede kleine Änderung sofort ausgerollt wird. Sie fließt also in ein Updatepaket ein. Fallen mehrere zusammen springt also die Versionnummer von 10.55.00123 auf z.B. 10.55.00450 vielleicht sogar auf 10.56.00000 (hier fängt man gerne wieder bei Null an).

Das bedeutet keineswegs das man Updates verpasst hat, sondern zeigt nur die Entwicklungsstufe an.

Buildnummern kann man natürlich ebenfalls wählen. Setzen dann aber wiederum voraus, dass fertige Builds keine kleinen Änderungen bekommen, sondern durch komplett "neue" Builds ersetzt werden. Natürlich hängt es hier von der Softwarearchitektur und deren Programmieren ab wie schlussendlich gezählt wird.

[#12]

Hallo @oaausb69,

vielleicht war meine Anmerkung missverständlich. Es liegt im Ermessen der Fachabteilung wie häufig Lieferungen geplant sind, wie schwergewichtig eine Änderung war, so dass 'Lücken' vorzusehen sinnvoll ist.

Die Anmerkung soll durchaus nicht auf heterogenes Entwicklungsvorgehen hindeuten.

mit freundlichen Grüßen,

Katrin Zahlten

[#13]

Danke, @p4ge und @Katrin_Zahlten und @weitere User für die Kommentare

... ich kann zumindest erahnen, mit welchen logischen und 'logistischen' Problemen und Abhängigkeiten die Datev-Entwickler zu kämpfen haben.

Allerdings betrachte ich das Thema "Produkt-Versionsnummern" naturgemäß aus der Sicht des Anwenders.

Mit den Hunderten von unterschiedlichen Versionsnummern für die Datev-Produkte und -Komponenten kann ich quasi nichts anfangen. Die "Detailübersicht" aus dem "Installationsmanager" heraus (z.Z. 121 Seiten) eignet sich nicht als spannende Bettlektüre 

(hier ein kurzer Auszug)

Apropos, für wen ist diese Detailübersicht eigentlich gedacht ? Wurde sie jemals gelesen ?

(ist sie vielleicht mitverantwortlich für das Waldsterben im Amazonas-Gebiet ? 😎)

Die 'Kurzübersicht' (16 Seiten, 809 Produkte) ist schon deutlich 'humaner'.

(hier ein kurzer Auszug)

Entwickler sind vermutlich von der kompakten Darstellung begeistert

Als Anwender wäre mir allerdings ein Versionsbezeichnung am angenehmsten, aus dem das Datum der Veröffentlichung hervorgeht. 

... und falls mich jemand z.B. am Telefon nach dem Versionsstand fragen würde, könnte ich 'locker aus dem Handgelenk heraus' antworten "... stammt alles von der Auslieferung 2022-04-14

Wäre es nicht möglich und hilfreich, wenigstens das Veröffentlichungsdatum der Haupt-Anwendungsprogramme (REWE, LODAS, ESt, USt, GewSt, KSt, EO Comfort usw.) im Titel des jeweils geöffneten Programms anzuzeigen ?

nach dem Motto (Neil Armstrong) :  

"that's one small step for man, one giant leap for mankind"

... wobei "man" nicht nur für "Mann" steht und mit "mankind" nicht das Kind im Manne gemeint ist 😎 )

also hier etwa mit folgender Aussage:

"ein kleiner Griff für die Datev-Entwickler, eine große Erleichterung für die Datev-Anwender"😎

[#14]

Ihr Forderungen werden derzeit bereits umgesetzt, vielleicht fällt es Ihnen nur nicht in diesem Maße auf.

Beispiel USt 2020 classic V 24.4

Ihr Problem "Hilfe mein USt 2020 macht Probleme".
Nun ist natürlich die Frage, haben sie alles immer sofort upgedatet? An diesem Punkt bringt einem "Version 2020" herzlich wenig.
Mit 24.4 kommt man da schon weiter. Denn der Fehler könnte nur bis 24.3 existent gewesen sein und wurde dann gepatcht.
Oder aber der Fehler war nur so minimal, dass es einen Hotfix gab. V 24.4 und V 24.4 (inkl. Hotfix vom X.Xx2022) sind identische Nummern.

Nur auf Version alles runter brechen ala Version 2020/2021/2022 etc. halte ich für schwierig da dann die mögliche Fehlersuche nicht eindeutig wird.
Nur auf Entwicklerversionen runter brechen ist ebenfalls schwierig. Ist die Version 3.3.14 nun besser als 3.3.14.2 ? Zumindest hilft sie die beiden Versionen zu unterscheiden.

Mir stellt sich einzig die Frage, WANN beschäftigt sich der Anwender (nicht EDV Abteilung) wirklich einmal intesiv mit der Versionisierung? Wenn Rewe zickt weil BOP die Daten nicht bekommt, schaut man ob es updates gibt, nicht ob sich die Versionsnummern unterscheiden.

Wenn sie das aber schon alles triggert, schauen sie sich mal die KB Nummern von Microsoft, die Build-Stringnummern von deren Betriebssystemen sowie die CVE Kennung von Virensignaturen. Viel Spass da eine Logik zu erkennen.

[#15]

@p4ge ,

... stimmt, bei den Steuerprogrammen (bei den Jahresversionen) hat sich schon viel getan. Hier will ich gar nicht meckern.

.. man kann sogar noch erkennen, wann umgestellt wurde 😉

(kleines Beispiel)

[...]
211.Erbschaftsteuer V.4.81 (S0000800- 481100-0003)
212.ErbSt 2002-2006 V.2.71 (S0000811- 271100-0000)
213.ErbSt 2002-2006 Formulardruck V.2.71 (S0000812- 271100-0000)
214.ErbSt 2007-2008 V.3.31 (S0000814- 331101-0001)
215.ErbSt 2007-2008 Formulardruck V.3.31 (S0000815- 331101-0001)
216.ErbSt 2009-2014 V.4.82 (S0000816- 482101-0002)
217.ErbSt 2009-2014 Formulardruck V.4.82 (S0000817- 482101-0001)
218.ErbSt 2015 V.5.11 (S0000818- 511100-0034)
219.ErbSt 2016(1.Hj) V.6.2 (S0000819- 62 101-0115)
220.ErbSt 2016(2.Hj)-2020 V.7.7 (S0000820- 77 101-0141)
221.ErbSt 2021-2022 V.8.11 (S0000821- 811100-0003)
222.ErbSt/SchenkSt comfort V.3.2 (S0000898- 32 101-0020)
{...]
656.SchenkSt 2002-2006 V.2.71 (S0000841- 271100-0000)
657.SchenkSt 2002-2006 Formulardruck V.2.71 (S0000842- 271100-0000)
658.SchenkSt 2007-2008 V.3.31 (S0000844- 331101-0001)
659.SchenkSt 2007-2008 Formulardruck V.3.31 (S0000845- 331101-0001)
660.SchenkSt 2009-2014 V.4.82 (S0000846- 482101-0001)
661.SchenkSt 2009-2014 Formulardruck V.4.82 (S0000847- 482101-0001)
662.SchenkSt 2015 V.5.11 (S0000848- 511100-0009)
663.SchenkSt 2016(1.Hj) V.6.2 (S0000849- 62 101-0115)
664.SchenkSt 2016(2.Hj)-2020 V.7.7 (S0000850- 77 101-0141)
665.SchenkSt 2021-2022 V.8.11 (S0000851- 811100-0003)
666.Schenkungsteuer V.4.81 (S0000830- 481100-0003)
[...]

... aber was immer wieder mal vorkommt, sind Probleme beim Datenaustausch zwischen Mandant und Kanzlei wg. unterschiedlichen Versionen und wegen zwischenzeitlichen SQL-Datenanpassungen

Wenn z.B. ein Mandant stolz berichtet, dass er "Rechnungswesen Compact 6.0" und "Datev Arbeitsplatz 8.1" im Einsatz hat, weiß der Kanzlei-Mitarbeiter vermutlich nicht auf Anhieb, ob er weinen oder lachen soll oder ob der Mandant oder die Kanzlei updaten muss.

Könnte ja sein, dass die Kanzlei- und Mandantenversionen unterschiedliche Nummernkreise haben.

... aber aus Ihnen spricht ein Insider.

... ja, ich gebe zu, dass ich die Logik bei den MS-Updates, CVE-Nummern und anderen 'Systemen' auch oft nicht nachvollziehen kann

[#16]

Insider 🤣

Nein um Gotteswillen, nein.

Sie müssen natürlich folgendes bedenken.
Die Datev gibt folgendes vor: "Updates so schnell wie möglich nach Release installieren!!! Bitte stets informieren ob es Anpassungen der Software gibt."

Dagegen läuft die Anwenderdenkweise:
"Software läuft, ............ Ach schau mal da ein Update, könnte man ja mal installieren"

Und nicht zu vergessen EDV/Administratoren
"Updates müssen aufgespielt werden, aber bitte mit Vorsicht, vielleicht etwas abwarten und nochmal testen. Mist Kritische Sicherheitslücke.... Dann muss das Update vorgezogen werden". Und nicht zuvergessen "Never change a running System"

Sie können es keiner Partei 100% gerecht machen. Klar im Austausch mit Mandanten hat man da nochmal eine Schippe mehr Anforderungen. Aber durch ein stetes aufbauen (so wie hier gerade in diesem Thread) über genau so ein Wissen, begegnet man den folgenden Problemen wesentlich entspannter. Man weiß jetzt "einfacher" wo der Fehler stecken könnte. Das macht den Fehler nicht besser, aber beide Parteien agieren ruhiger wenn nicht blind reagiert, sonder mit (zumindest ein wenig) wissen agiert wird.