Habe "dummerweise" die 3.0 RC1 installiert, die hat dann erst mal die 2er komplett zerschossen, lässt sich also nicht nebeneinander benutzen.
Soweit sogut - fands nicht weiter schlimm, meine Rechnungen wurden noch geöffnet und das Makro mit der automatischen Rechnungsnummer läuft auch.
AAAABer:
Wollte mal testen, ob das Buchen in der EUeR noch klappt. Und da ist dann alles zuspät.
Makrofehler, keine Werte in den Tabellen für die Umsatzsteuer - also vollkommenes Chaos.
Zum Glück muss ich erst im Oktober alles fertig haben, aber das bedeutet wahrscheinlich eine stundenlange manuelle Deinstallation der 3er und auch dass zukünftig die 3er nicht nutzbar ist, weil man alles übern Haufen geworfen hat.
Gleichlautende Funktionen sind unterschiedlich parametriert (oh gott, welcher Hirnie ist dafür verantwortlich?) - bspw. die Funktion Adresse() ist in ihren Parametern verändert, so dass kein Makro welches diese verwendet mehr läuft, keine Tabelle, welche damit arbeitet wird in der 3er richtige Ergebnisse bringen!
Formularfelder mit Werten lassen sich nicht mehr in gewohnter Art und Weise mit Tabellenzellen verknüpfen (Änderung der Werte aufgrund Änderung des selectedIndex im Optionfeld bspw.) - auch in EUeR für die Monatsansich der USt-Voranmeldung notwendig....
Also - wie kann man das wieder so herstellen, dass das wieder geht? Es kann ja nicht sein, dass so gravierende nicht abwärtskompatible Änderungen vorgenommen werden, die schon existenzbedrohende Ausmasse annehmen (wenn ich nicht meine USt-Erklärung abgebe, schätzt das FA und ich hab grad in diesem Quartal ein Problem, war der Sommer doch recht "umsatzschwach"...)
Wenn das so ist, dann dürfte im kommerziellen Umfeld OOo nicht mehr in Frage kommen, da dann lieber doch proprietäre, abwärtskompatible Software benutzen...
Mann mann mann, bin ich vielleicht stinkig und sauer ob dieser Sch.... Was hat sich SUN dabei nur gedacht? Oder denkt keiner mehr und ist nur drauf bedacht irgendwelche selbst erstellten Standards zu erreichen, auf Kosten der User? Sind wir bei OS-Software unterdessen auch soweiet? Na dann....
3.0 RC1 Deutsch - Calc - Buggy oder was?
Moderator: Moderatoren
Re: 3.0 RC1 Deutsch - Calc - Buggy oder was?
doch, sollte gehen, läuft hier bei mir auch problemlos (ich habe hier 2.4.0 und 3.0RC1 nebeneinander installiert)Habe "dummerweise" die 3.0 RC1 installiert, die hat dann erst mal die 2er komplett zerschossen, lässt sich also nicht nebeneinander benutzen.
Hast Du beim Installieren von 3.0 die neue OPtion zum Entfernen alter Versionen beacht und diese deaktiviert?
dann müßtest Du mal bitte sagen was das ("EUeR") ist.Wollte mal testen, ob das Buchen in der EUeR noch klappt. Und da ist dann alles zuspät.
Ist das ("EUeR") irgendeine Calc-Datei mit Makros?Makrofehler, keine Werte in den Tabellen für die Umsatzsteuer - also vollkommenes Chaos.
Gleichlautende Funktionen sind unterschiedlich parametriert (oh gott, welcher Hirnie ist dafür verantwortlich?)
Was für Beispiele dafür hast Du?
Anpassungen von Tabellenfunktionen in der Vergangenheit geschahen meist zur Verbesserung der Excel-Kompatibilität.
Ersteres (Funktionieren im Makro) ist eine grundlegend unrealistische Forderung, denn exakt niemand kann wissen wie, wer was in Makros verwendet, woraus dann nur eines resultieren könnte um keine Probleme zu khaben: keinerlei Änderung, mithin keinerlei Weiterentwicklung.die Funktion Adresse() ist in ihren Parametern verändert, so dass kein Makro welches diese verwendet mehr läuft, keine Tabelle, welche damit arbeitet wird in der 3er richtige Ergebnisse bringen!
In Tabellen selbst läuft die Funktion Adresse m.W. hingegen problemlos, die ursprüngliche Syntax, z.B.:
=ADRESSE(1;1;2;"Tabelle2")
die in 2.x funktionierte, wird ohne manuelles Eingreifen problemlos in die neue Syntax:
=ADRESSE(1;1;2;1;"Tabelle2")
gewandelt sobald Du das Dokument in 3.0 öffnest.
Aber vielleicht bist Du bei ADRESSE() auf ganz andere Probleme gestossen, dann freue ich mich über eine Info dazu.
Könntest Du bitte eine Beispieldatei hochladen, dann schaue ich mir das gene mal an.Formularfelder mit Werten lassen sich nicht mehr in gewohnter Art und Weise mit Tabellenzellen verknüpfen (Änderung der Werte aufgrund Änderung des selectedIndex im Optionfeld bspw.) - auch in EUeR für die Monatsansich der USt-Voranmeldung notwendig....
weiß ich nicht, weil ich leider die konkreten Probleme nicht kenne, beispielsweise die Makros von denen Du sprichstAlso - wie kann man das wieder so herstellen, dass das wieder geht?
Moment ... wer bitteschön würde denn z.B. Excel (was ich nebenbeigesagt für ein sehr gelungenes Programm halte) für steuerrechtsrelevante Dinge einfach so einsetzen? Das ist schlicht und ergreifend Leichtsinn, der vielleicht funktioniert, aber auf den sich doch kein seriöser Unternehmer einließe.Es kann ja nicht sein, dass so gravierende nicht abwärtskompatible Änderungen vorgenommen werden, die schon existenzbedrohende Ausmasse annehmen (wenn ich nicht meine USt-Erklärung abgebe, schätzt das FA und ich hab grad in diesem Quartal ein Problem, war der Sommer doch recht "umsatzschwach"...)
Wenn das so ist, dann dürfte im kommerziellen Umfeld OOo nicht mehr in Frage kommen, da dann lieber doch proprietäre, abwärtskompatible Software benutzen...
Sorry, ich weiß immer noch nie wie genau Du nun die Steuer machst, vielleicht mit einer bestimmtn Calc-Datei o.Ä., nur auch die hat einen Hersteller der dafür verantworlich zeichnet, und da ich sowohl unternehmerisch tätig bin, als auch wüßte wie ich mit Calc eine Datei zum Steuerberechnen zusammenbastle, gilt doch zweierlei:
*als Anbieter einer solchen Datei würde ich Systemvoraussetzungen vorschreiben, also z.B. bestimmte OOo-Version, genau das wäre aber bei Excel auch nicht anders, denn auch da würde ich die Version vorschreiben plus mögluiche Updates
*als Benutzer einer solchen Datei würde ich mir die Funktion der Software für diesen speziellen Zweck (Steuern) garantieren lassen
Im Übrigen würde ich generell immer die Software einsetzen die zur Lösung de konkreten Aufgabe am Besten ist, das kann dann auch properitäre Software sein wenn es keine adäquate OSS gibt.
Ich bin jedenfalls strikter Gegner einer Haltung man müsse OSS gewisse Fehler nachsehen, weil ja so viele Leute freiwillig ihre Zeit in die Entwicklung investieren, etc.
Komm bleib fair. Entweder wir reden über Probleme oder wir bashen ein wenig gegen OOo.Mann mann mann, bin ich vielleicht stinkig und sauer ob dieser Sch.... Was hat sich SUN dabei nur gedacht? Oder denkt keiner mehr und ist nur drauf bedacht irgendwelche selbst erstellten Standards zu erreichen, auf Kosten der User? Sind wir bei OS-Software unterdessen auch soweiet? Na dann....
Was ich Dir oben zur Problematik Steuer schrieb meine ich nämlich tatsächlich Ernst und alles Andere ist für meinen Geschmack am Thema vorbei, zumindest wenn wir über ernsthafte geschäftliche Dinge reden.
Wenn bei mir eine Festplatte 'abraucht', was diese ja eigentlich auch nicht soll, und ich dadurch wichtige Unterlagen verliere, gibst dafür genau einen Schuldigen - mich selbst, denn ich weiß das ich für Backups verantwortlich bin, Und das aus einem ganz einfachen SACHgrund: kein Festplattenhersteller der Welt kann bei heutigem technischen Stand fehlerfreie festplatten herstellen.
Und kein Softwarehersteller der Welt kann fehlerfreie Programmweiterentwicklungen machen ... es ist schlicht so. Wenn ich also solche Software zusammen mit Makros eines anderen Anbieters benutze lasse ich mir von diesem Anbieter zuverlässige Funktion garantieren und er wird die sicherlich in Form dessen geben das er bestimmte OOo-Versionen für seine Makros freigibt.
Denn es ist garkeine FRage das der FAkt als solcher genauso besteht wie Du sagst: es kann makros geben die in einer bestimmten OOo-Version laufen und in einer anderen nicht. Z.B. läuft auch http://www.calc-info.de/makros.htm#mottco derzeitig nicht fehlerfrei unter 3.0
.Dass sich mehrere Versionen nicht parallel installieren lassen, ist seit 2.0 so
stimmt für 3.0 nicht mehr und ich kanns auch praktisch nicht bestätigen, denn ich habehier OOo 2.4.0 parallel zu 3.0 zu laufen und habe 3.0 normal mit Installer installiert ohne /a und ähnliche Faxen.
Einzig (und das sollte ich dazusagen) ist mein 2.4.0 ein OxygenOffice, wobei sich das von Ordnernamen etc. normal wie ein OOo installiert, aber ein geringes Restrisiko das es bei mir nur wegen Oxygenoffice funktioniert bleibt natürlich.
Gruß
Stephan
Re: 3.0 RC1 Deutsch - Calc - Buggy oder was?
Erst mal Danke für Eure Antworten und auch die Geduld mit der ihr meinen Ärger ertragen habt... 
Die 3er ist runter, die zweier läuft noch, installier aber nochmal drüber weil die Dateiverknüpfungen im System entfernt wurden. Hat sich nur leider nach der Deinstallation der 3er ein neues Problem im System ergeben (obwohl ich fairerweise sagen muss, dass es nicht sicher ist, ob die Deinstall der 3er daran explizit "Schuld" ist) - DAO funktioniert nicht mehr spezielle die JetEngine und die WISO-Programme die darauf aufbauen, komischerweise laufen die ELSTERn problemlos, aber egal.
Zurück zu OOo.
Es geht im Speziellen um die Einnahmen-Überschussrechnung von J. Schlenther, die bei mir seit einigen Jahren schon zum Einsatz kommt.#
Funktion Adresse() definitiv neu parametriert.
Adresse(2;6;0;$A5) in OOo 2.x mit korrektem Wert muss in 3x neuerdings seltsamerweise Adresse(2;6;1;1;$A5) lauten, übernommen wird aber bei spez. Dokument Adresse(2;6;0;1;$A5)
Wird dann etwas lästig, das im gesamten Dokument ändern zu müssen, zumal die Funktion dann noch in Matrixformeln eingesetzt wird.
Feler am deutlichsten in der Tabelle "Monate" der hochgeladenen Beispieldatei zu finden (ist ne normale in der 2.x funktionierende Version mit üblichen Geschäftsvorfällen, so wie sie von mir verwendet wird - Namen und Identitätskennzeichen sind beseitigt worden...)
Makrofehler
In der Tabelle "Stammdaten" der Schalter Sperren-Entsperren, Fehler tritt nach Entsperren und neuem Sperren in der 3.x er auf.
Verknüpfung von Feldern:
In der Tabelle "USt Monat" wird der Monat bei Auswahl im Optionfeld in der 3.x er nicht mehr vorgenommen, zusätzlich hier auch die Fehler mit der Fkt. Adresse() - die sich durch die gesamte Tabelle durchziehen und damit einen Einsatz des Dokuments in der 3er momentan unmöglich machen.
Für'n Moment war mir so, nen Pfeil abzuschiessen, der Ärger war doch recht gross und jetzt, nachdem klar ist, dass die 2er wieder läuft und die Datei dort noch verwendbar ist, relativiert und rationalisiert sich das ganze ein wenig, obwohl die Probleme erst mal bleiben und sicher viele andere treffen werden...
Problematisch wird es allerdings, wenn jemand seine Dateien in der 2er erstellt hat und in der 3er öffnet und dann da auch abspeichert.
Die gehen in der 2er definitiv nicht mehr fehlerfrei, die Fehler der 3er sind jetzt "zurückportiert" auf die 2er, d.h. alles was nach Öffnen in der 3er dort nicht mehr funktionierte bzw. Fehlermeldungen hervorrief tut dies dann auch in der 2er, die falschen Formeln/Funktionen sowie die Makrofehler und auch die nichtstattfindende Übernahme geänderter selectedIndizes von Optionfelder in die zugewiesenen Funktionen.
Vielleicht hilft es ja weiter und die Fehler sind reproduzierbar und damit möglicherweise auch beseitigbar bis zu nem Release

Die 3er ist runter, die zweier läuft noch, installier aber nochmal drüber weil die Dateiverknüpfungen im System entfernt wurden. Hat sich nur leider nach der Deinstallation der 3er ein neues Problem im System ergeben (obwohl ich fairerweise sagen muss, dass es nicht sicher ist, ob die Deinstall der 3er daran explizit "Schuld" ist) - DAO funktioniert nicht mehr spezielle die JetEngine und die WISO-Programme die darauf aufbauen, komischerweise laufen die ELSTERn problemlos, aber egal.
Zurück zu OOo.
Es geht im Speziellen um die Einnahmen-Überschussrechnung von J. Schlenther, die bei mir seit einigen Jahren schon zum Einsatz kommt.#
Funktion Adresse() definitiv neu parametriert.
Adresse(2;6;0;$A5) in OOo 2.x mit korrektem Wert muss in 3x neuerdings seltsamerweise Adresse(2;6;1;1;$A5) lauten, übernommen wird aber bei spez. Dokument Adresse(2;6;0;1;$A5)
Wird dann etwas lästig, das im gesamten Dokument ändern zu müssen, zumal die Funktion dann noch in Matrixformeln eingesetzt wird.
Feler am deutlichsten in der Tabelle "Monate" der hochgeladenen Beispieldatei zu finden (ist ne normale in der 2.x funktionierende Version mit üblichen Geschäftsvorfällen, so wie sie von mir verwendet wird - Namen und Identitätskennzeichen sind beseitigt worden...)
Makrofehler
In der Tabelle "Stammdaten" der Schalter Sperren-Entsperren, Fehler tritt nach Entsperren und neuem Sperren in der 3.x er auf.
Verknüpfung von Feldern:
In der Tabelle "USt Monat" wird der Monat bei Auswahl im Optionfeld in der 3.x er nicht mehr vorgenommen, zusätzlich hier auch die Fehler mit der Fkt. Adresse() - die sich durch die gesamte Tabelle durchziehen und damit einen Einsatz des Dokuments in der 3er momentan unmöglich machen.
jepp, sorry... bashen hilft ja nicht weiter, lassen wirs alsoKomm bleib fair. Entweder wir reden über Probleme oder wir bashen ein wenig gegen OOo.

Für'n Moment war mir so, nen Pfeil abzuschiessen, der Ärger war doch recht gross und jetzt, nachdem klar ist, dass die 2er wieder läuft und die Datei dort noch verwendbar ist, relativiert und rationalisiert sich das ganze ein wenig, obwohl die Probleme erst mal bleiben und sicher viele andere treffen werden...
Problematisch wird es allerdings, wenn jemand seine Dateien in der 2er erstellt hat und in der 3er öffnet und dann da auch abspeichert.
Die gehen in der 2er definitiv nicht mehr fehlerfrei, die Fehler der 3er sind jetzt "zurückportiert" auf die 2er, d.h. alles was nach Öffnen in der 3er dort nicht mehr funktionierte bzw. Fehlermeldungen hervorrief tut dies dann auch in der 2er, die falschen Formeln/Funktionen sowie die Makrofehler und auch die nichtstattfindende Übernahme geänderter selectedIndizes von Optionfelder in die zugewiesenen Funktionen.
Vielleicht hilft es ja weiter und die Fehler sind reproduzierbar und damit möglicherweise auch beseitigbar bis zu nem Release
- Dateianhänge
-
- EUeR_Fehlertest.ods
- CALC-Beispieldatei zur Fehlerdemonstration bei Übernahme in die 3 RC
- (91.12 KiB) 63-mal heruntergeladen
Re: 3.0 RC1 Deutsch - Calc - Buggy oder was?
Ein ziemlich typischer Fehler, denn es hat Ähnliches auch bei anderen Funktionen gegen, allerdings ist OOo daran unschuldig, denn die Sorgfalt die Du anmahnst hat OOo hier eingehalten. Schuld am Fehler ist allein der Erzeuger der Formel Adresse(2;6;0;$A5) der einen undokumentierten Wert für einen Parameter benutzt hat (0 ist NIRGENS dokumentiert).Funktion Adresse() definitiv neu parametriert.
Adresse(2;6;0;$A5) in OOo 2.x mit korrektem Wert muss in 3x neuerdings seltsamerweise Adresse(2;6;1;1;$A5) lauten, übernommen wird aber bei spez. Dokument Adresse(2;6;0;1;$A5)
Hätte er zulässige Werte benutzt wäre auch mit 3.0 nie ein Fehler eingetreten.
Bitte mißverstehe hier meine Aussage nicht, denn sicher gibt es x-Stellen wo auch mir solche Fehler bei der Verwendung von Funktionen unterlaufen können, auch kann das insgesamt ärgerlich sein, nur es ist kein Fehler des Programms und im Konkreten noch nicht einmal ungeschickte Weiterentwicklung.
Das hier im Übrigen (wie bereits durch mich vermutet) der neue Umgang mit dem (nicht zulässigen) 0-Wert die Kompatibilität verbessert, ist augenscheinlich, denn OOo 3.0 vehält sich nun an der Stelle wie MS Excel.
(Nö, ich bin erklärter Gegner davon in OOo MS Excel nachzubilden, nur bei Tabellenfunktionen ist solches Verhalten essentiell, auch mit Blick auf zukünftige Entwicklungenhinsichtlich einheitlicher Dateiformate)
mit Suchen-Ersetzen brauche ich ca. 30 Sekunden pro betroffener Tabelle dEiner Beispieldatei dazuWird dann etwas lästig, das im gesamten Dokument ändern zu müssen
ich kann keinen Fehler feststellen mit OOo 3.0RC1 (deutsch, Windows) würde aber wenn ich mir das Makro anschaue schätzen das es an der Tools-Bibliothek liegt, denn ich erinnere mich das es wohl schon bei den 3.0Beta-Versionen Probleme damit gabIn der Tabelle "Stammdaten" der Schalter Sperren-Entsperren, Fehler tritt nach Entsperren und neuem Sperren in der 3.x er auf.
Überprüfe doch bitte einmal ob bei Deiner 3.0 Installation die Makrobibliothek "Tools" vorhanden ist
komisch, in Deiner Beispieltabelle klappt das hervorragend - kann es sein das Du einen Fehler nur vermutest weil in Zelle B2 die Schriftfarbe auf Weiss steht ud eine Änmderung des Monatsnamens somit nur nicht sichtbar wird?In der Tabelle "USt Monat" wird der Monat bei Auswahl im Optionfeld in der 3.x er nicht mehr vorgenommen
Natürlich, nur das ist überhaupt nicht andes zu machen. Auch jede Änderung die kein Fehler ist kann sich so auswirken. Einziges Gegenmittel ist die Entwicklung des Programms einzustellen.Problematisch wird es allerdings, wenn jemand seine Dateien in der 2er erstellt hat und in der 3er öffnet und dann da auch abspeichert.
Weil diese ZUsammenhänge (und ihre Unvermeidlichkeit) bekannt ist reagieren Hersteller kommerzieller (hier ist properitär egal) Software meist mit Updates (MS macht das für Office so). OOo reagiert hier bewußt nicht mit Updates weil inkrementelle Updates derzeitig noch nicht möglich sind und somit jedes Update ohnehin der Vollversion entspricht/entspräche.
Neuere OOo Versionen (2.4 hats sicher) weisen sogar ungefragt auf diese Zusammenhänge mit einem Meldungsfenster hin.
Ich fasse mal zusammen:
*Du hast u.U. Probleme mit der "Tools"-Bibliothek (wenn das so ist: =kein Programmproblem, sondern Fehler der Programmdistribution)
*Formeln waren von Anfang an falsch, bisher hat OOo die Fehler toleriert, nun wo es richtig rechnet fällt die Datei auf die Nase (=wieder kein Problem des Programms)
insgesamt:
Du benutzt Software, die eine Firma erstellt hat (Calc-Datei mit Makros und Formeln) und diese Firma hat offensichtlich leichtfertig diese Datei für OOo ab 2.2 freigegeben. Es wäre der richtige und vernüftige Schritt gewesen diese Firma anzuschreiben und um Korrektur der Datei zu bitten statt über OOo herzuziehen, was keine Schuld trägt. Ja, ich sehe das die dAtei OSS ist, nur auch Entwickler solcher Software brauchen Rückmeldung und werden auch i.A. Fehler dann schnell korrigieren.
Nein, ich schütze hier OOo überhaupt nicht pauschal, nur keine Deiner Fehlervermutungen erweist sich als zutreffend.
Gerade bei der Funktion ADRESSE() liegt der Fehler nicht bei OOo 3.0, auch nicht in strategischer Hinsicht, sondern die Funktion wurde von Anfang an falsch verwendet.
Die Situation ist hier schlicht so als wenn ich zehnmal bei Falschparken nicht erwischt werde, es beim elften Mal dann werde und nicht bereit bin mein 'Ticket' zu bezahlen mit der Begründung ich parke ja garnicht falsch, denn ansonsten hätte ich ja schon zehnmal bestraft werden müssen.
Echte FEhler in Tabellenfunktionen von Calc siehst Du z.B. hingegen bei UNREGER.KURS() und UNREGER.REND()
Gruß
Stephan
Re: 3.0 RC1 Deutsch - Calc - Buggy oder was?
Hallo,
ich hatte die V. 2.4 und die aktuelle 3er parallel laufen. Weil die 3er auch mit allen Makros, z.T. sehr komplexen Formeln fehlerfrei gelaufen ist, habe ich auf dem ganz neuen Rechner gleich nur noch die aktuelle 3er installiert. Benutze sie "leichtsinnigerweise" auch geschäftlich (allerdings ohne Steuerdinge- weil es dafür geeignetere Programme gibt wie z.B. Taxpool
).
Das einzige Problem das ich anfänglich mit der 3er hatte, war die Übernahme der Datenbankfelder aus dem zentralen und erweiterten Thunderbird-Adressbuch. Ab der 3er wurden keine Feldbefehlsnamen mehr übernommen, die Umlaute, Leerzeichen, etc. in sich trugen... Nachdem ich daraus z.B. E_Mail1, etc., gemacht hatte, ging alles problemlos. Wie gesagt, nicht alles ganz einfach gestrickt
Viele Grüße
Thomas
ich hatte die V. 2.4 und die aktuelle 3er parallel laufen. Weil die 3er auch mit allen Makros, z.T. sehr komplexen Formeln fehlerfrei gelaufen ist, habe ich auf dem ganz neuen Rechner gleich nur noch die aktuelle 3er installiert. Benutze sie "leichtsinnigerweise" auch geschäftlich (allerdings ohne Steuerdinge- weil es dafür geeignetere Programme gibt wie z.B. Taxpool

Das einzige Problem das ich anfänglich mit der 3er hatte, war die Übernahme der Datenbankfelder aus dem zentralen und erweiterten Thunderbird-Adressbuch. Ab der 3er wurden keine Feldbefehlsnamen mehr übernommen, die Umlaute, Leerzeichen, etc. in sich trugen... Nachdem ich daraus z.B. E_Mail1, etc., gemacht hatte, ging alles problemlos. Wie gesagt, nicht alles ganz einfach gestrickt

Viele Grüße
Thomas
Re: 3.0 RC1 Deutsch - Calc - Buggy oder was?
Vielen Dank für die Umfassenden Antworten und das Testen.
Beruhigt mich schon, dass das nicht doch direkte Bugs sind sondern das "Basismaterial" die Probleme verursacht.
Werd mich also mal ernsthaft und ohne emotionale Bewertung mal damit auseinandersetzen....
Viele Grüße aus dem Erzgebirge ins weite Rund
Beruhigt mich schon, dass das nicht doch direkte Bugs sind sondern das "Basismaterial" die Probleme verursacht.
Werd mich also mal ernsthaft und ohne emotionale Bewertung mal damit auseinandersetzen....
Viele Grüße aus dem Erzgebirge ins weite Rund