Dateiformat csv für SEPA-account converter
Guten Tag, liebe Helfer! Ich muss für den SEPA-Lastschrifteinzug zum Umrechnen der alten Kontodaten in die IBAN und BIC Nummern eine Tabelle als Dateityp CSV (Trennzeichen getrennt) (.csv) speichern. Ich krieg das leider nicht so hin, dass der SEPA-converter (Sparkasse) es annimmt. Kann jemand helfen? Dank und Gruß Hanna Ganter -- Hanna Ganter Sägegasse 12 79244 Münstertal Telefon und Fax 07636 1736 - To unsubscribe, e-mail: users-de-unsubscr...@openoffice.apache.org For additional commands, e-mail: users-de-h...@openoffice.apache.org
Update
Hallo Freunde! Ich wollte vor kurzem das Update 4.0.1 auf meinen Mac Book Air herunterladen. Wie Ihr wisst, ist dies ein 64 Bit System. Ich habe natürlich auch Mavericks! Beim Herunterladen ist jedoch ein Fehler aufgetreten, es kam immer - ich versuchte den Download 3mal! - die Meldung „Programm beschädigt, bitte löschen!“. Liegt dies vielleicht daran, dass die Version 4.0.1. für Mac auf 32 Bit erstellt wurde? Beste Grüße Hans - To unsubscribe, e-mail: users-de-unsubscr...@openoffice.apache.org For additional commands, e-mail: users-de-h...@openoffice.apache.org
Re: Dateiformat csv für SEPA-account converter
Hallo, From: Hanna Ganter [mailto:hanna.gan...@online.de] Ich muss für den SEPA-Lastschrifteinzug zum Umrechnen der alten Kontodaten in die IBAN und BIC Nummern eine Tabelle als Dateityp CSV (Trennzeichen getrennt) (.csv) speichern. Ich krieg das leider nicht so hin, dass der SEPA-converter (Sparkasse) es annimmt. Warum nicht? Was passiert denn? Kann jemand helfen? Ohne weitere Informationen wohl eher nicht da ich nicht wüsste das es einen allgemeinen Standard gibt welchen cvs-Aufbau ein SEPA-Konverter erwartet. Man muss ganz einfach wissen welche Trennzeichen und ggf. welche Texttrenner erwartet werden. Wenn ich google finde ich unter SEPA-converter (Sparkasse) ein Programm [1] in dessen Dokumentaion als Aufbau der cvs dokumentiert ist das der Feldtrenner das Semikolon sein muss und der Text in stehen muss, also wäre beim Speichern in OO das in dem Dialog auszuwählen der erscheint wenn man als cvs speichert, also: Feldtrenner: ; Texttrenner: Ob allerdings alle 'SEPA-Konverter' mit einer derartigen csv zurechtkommen entzieht sich meinerr Kenntnis, ich wseiß nicht einmal ob es mehrere vesxchiedene SEPA-Konverter gibt. Rückantworten NUR an die Mailingliste. Gruß Jörg [1] https://www.ksk-koeln.de/leistungen/dienstleistungen/zahlungsverkehr/sepa-zahlungs verkehr/sepa-converter.aspx - To unsubscribe, e-mail: users-de-unsubscr...@openoffice.apache.org For additional commands, e-mail: users-de-h...@openoffice.apache.org
Re: Dateiformat csv für SEPA-account converter
Am 08.01.2014 21:25, schrieb Hanna Ganter: Guten Tag, liebe Helfer! Ich muss für den SEPA-Lastschrifteinzug zum Umrechnen der alten Kontodaten in die IBAN und BIC Nummern eine Tabelle als Dateityp CSV (Trennzeichen getrennt) (.csv) speichern. Ich krieg das leider nicht so hin, dass der SEPA-converter (Sparkasse) es annimmt. Kann jemand helfen? Woran genau scheitert es denn? Hast Du korrekt eingestellt - die richtige Reihenfolge der Daten? - das richtige Trennzeichen (Feldtrenner)? - Hochkomma ja oder nein (Alle Textzeilen zitieren)? Wolfgang -- - To unsubscribe, e-mail: users-de-unsubscr...@openoffice.apache.org For additional commands, e-mail: users-de-h...@openoffice.apache.org
Re: Update
Hallo Freund, mittlerweile gibt es für den Mac mindestens LibreOffice 4.1.4.2. Okay, ich weiß, falsche Fraktion. Aber das läßt sich herunterladen und funktioniert bestens, zumindest auf meinem MacBook 64, Mavericks. Und LO hat schon einige Extensions an Bord. Bitte nicht steinigen. Wir sind doch eine Familie. Mut zum Wechsel? Viele Grüße Bernd Am 09.01.2014 um 08:26 schrieb Mag. Hans Lach hans.l...@icloud.com: Hallo Freunde! Ich wollte vor kurzem das Update 4.0.1 auf meinen Mac Book Air herunterladen. Wie Ihr wisst, ist dies ein 64 Bit System. Ich habe natürlich auch Mavericks! Beim Herunterladen ist jedoch ein Fehler aufgetreten, es kam immer - ich versuchte den Download 3mal! - die Meldung „Programm beschädigt, bitte löschen!“. Liegt dies vielleicht daran, dass die Version 4.0.1. für Mac auf 32 Bit erstellt wurde? Beste Grüße Hans - To unsubscribe, e-mail: users-de-unsubscr...@openoffice.apache.org For additional commands, e-mail: users-de-h...@openoffice.apache.org - To unsubscribe, e-mail: users-de-unsubscr...@openoffice.apache.org For additional commands, e-mail: users-de-h...@openoffice.apache.org
Re: Update
From: Bernd Kloß [mailto:kloss.mail...@gmail.com] Sent: Thursday, January 09, 2014 10:37 AM To: users-de@openoffice.apache.org Subject: Re: Update Hallo Freund, mittlerweile gibt es für den Mac mindestens LibreOffice 4.1.4.2. Okay, ich weiß, falsche Fraktion. Aber das läßt sich herunterladen und funktioniert bestens, zumindest auf meinem MacBook 64, Mavericks. Und LO hat schon einige Extensions an Bord. Bitte nicht steinigen. Wir sind doch eine Familie. Mut zum Wechsel? Mut für Wahrheiten? https://www.heise.de/artikel-archiv/ct/2014/01/140_Standfester-Oldie Zitat: Vergleicht man die Liste der Funktionen von OpenOffice und LibreOffice, scheint letzteres Paket auf den ersten Blick mächtig aufzutrumpfen. Doch LibreOffice verspricht viel, ohne diesen Anspruch in der Praxis halten zu können. Viele Funktionen sind auch in der aktuellen Version 4.1.3.2, die das Team als stabil und für den professionellen Einsatz geeignet declariert, so fehlerhaft das sie sich kaum sinnvoll nutzen lassen. Damit beschränken sich die Vorteile auf kleine Verbesserungen. [...] Letztendlich punktet das OpenOffice-Paket, da dessen Entwickler neue Funktionen erst dann einzubauen scheinen, wenn sie zuverlässig laufen, und anderenfalls lieber darauf verzichten - wie man es von Profientwicklern eigentlich erwartet. SCNR Gruß Jörg - To unsubscribe, e-mail: users-de-unsubscr...@openoffice.apache.org For additional commands, e-mail: users-de-h...@openoffice.apache.org
Re: Update
Immer! Sind die Dateiformate noch 100% kompatibel? Kann man LO und OO gefahrlos auf dem Mac parallel installieren? Ich habe da in LO schon ein paar Bugs, die nerven. Z. B. in Calc die Achsen-Beschriftung von Diagrammen mit negativen Exponenten und griechischen Symbolen. Klappt sowas einwandfrei in OO? Erfahrungen damit? Gruß Bernd Am 09.01.2014 um 10:55 schrieb Jörg Schmidt joe...@j-m-schmidt.de: From: Bernd Kloß [mailto:kloss.mail...@gmail.com] Sent: Thursday, January 09, 2014 10:37 AM To: users-de@openoffice.apache.org Subject: Re: Update Hallo Freund, mittlerweile gibt es für den Mac mindestens LibreOffice 4.1.4.2. Okay, ich weiß, falsche Fraktion. Aber das läßt sich herunterladen und funktioniert bestens, zumindest auf meinem MacBook 64, Mavericks. Und LO hat schon einige Extensions an Bord. Bitte nicht steinigen. Wir sind doch eine Familie. Mut zum Wechsel? Mut für Wahrheiten? https://www.heise.de/artikel-archiv/ct/2014/01/140_Standfester-Oldie Zitat: Vergleicht man die Liste der Funktionen von OpenOffice und LibreOffice, scheint letzteres Paket auf den ersten Blick mächtig aufzutrumpfen. Doch LibreOffice verspricht viel, ohne diesen Anspruch in der Praxis halten zu können. Viele Funktionen sind auch in der aktuellen Version 4.1.3.2, die das Team als stabil und für den professionellen Einsatz geeignet declariert, so fehlerhaft das sie sich kaum sinnvoll nutzen lassen. Damit beschränken sich die Vorteile auf kleine Verbesserungen. [...] Letztendlich punktet das OpenOffice-Paket, da dessen Entwickler neue Funktionen erst dann einzubauen scheinen, wenn sie zuverlässig laufen, und anderenfalls lieber darauf verzichten - wie man es von Profientwicklern eigentlich erwartet. SCNR Gruß Jörg - To unsubscribe, e-mail: users-de-unsubscr...@openoffice.apache.org For additional commands, e-mail: users-de-h...@openoffice.apache.org - To unsubscribe, e-mail: users-de-unsubscr...@openoffice.apache.org For additional commands, e-mail: users-de-h...@openoffice.apache.org
Re: Update
From: Bernd Kloß [mailto:kloss.mail...@gmail.com] Sent: Thursday, January 09, 2014 11:26 AM To: users-de@openoffice.apache.org Subject: Re: Update Immer! Sind die Dateiformate noch 100% kompatibel? Jein, das sind sie auch nie gewesen, denn LO basierte von Anfang an auf go-oo und das unterschied sich schon immer von OO. Etwas genauer gesagt: Da beide Programme ODF nutzen, sind sie natürlich kompatibel im Sinne der Formatdefinition, da es aber im Format z.B. zulässige optionale Inhalte gibt (z.B. Makros) oder z.B. unterschiedliche Wiedergaben von Formatierungen (bei der Darstellung durch das jeweilige Programm) sind Dateien in Praxis nicht völlig kompatibel im Wortsinn. Sehr wahrscheinlich sind aber OO/LO untereinander immer noch weit kompatibler als OO oder LO verglichen mit anderen Programmen (z.B. fiel ja vor einigen Jahren ein Vergleich der C't von KOffice und OOo hinsichtlich der Kompatibilität von Dokumenten sehr ernüchternd aus) Kann man LO und OO gefahrlos auf dem Mac parallel installieren? Ich weiß garnichts zu MacOS, sonst wäre ich bereits auf die Frage des OP eingegangen. Ich habe da in LO schon ein paar Bugs, die nerven. Z. B. in Calc die Achsen-Beschriftung von Diagrammen mit negativen Exponenten und griechischen Symbolen. Klappt sowas einwandfrei in OO? Wahrscheinlich eine Frage des konkreten Diagramms. Wennn Du ein Beispiel hast kann ich es ausprobieren. Ein testweise angelegtes Säulen-Diagramm (griechisch als Beschriftung plus Exponentialwerte mit negativem Exponennten) macht hier keine Probleme, nur kann mein zufälliges Beispiel ganz irrelevant für Deine Anforderung sein. Erfahrungen damit? Nein, ich nicht was die konkrete Frage negativen Exponenten und griechischen Symbolen betrifft. Gruß Jörg - To unsubscribe, e-mail: users-de-unsubscr...@openoffice.apache.org For additional commands, e-mail: users-de-h...@openoffice.apache.org
AW: Dateiformat csv für SEPA-account converter
Hallo Hanna, Frage: Wenn Du (oder Dein Arbeitgeber) offenbar Sparkassenkunde bist, warum verwendest Du nicht zB das Programm SFirm (Netzwerk) als Banking-Programm; das kann auch alte Bankdaten konvertieren? (beim Preis erschrickt man erst mal, der ist meiner Erfahrung nach verhandelbar; einfach frech sein! oder alternativ Star-Money, kann SEPA/IBAN auch) Ich sehr das Problem auch darin, dass Du beim Konvertieren immer wieder führende Nullen einfügen mußt, je nachdem, wie lang die vorherige Kontonummer war. Und Du mußt eine Prüfziffer errechnen. Kennst Du den Algorithmus dazu? Du hast also ein Datenbankproblem (siehe meine Vorredner: Felder, Trennzeichen...) und vor allem das Berechnungsproblem. Die SPK stellt im Internet einen IBAN Rechner zur Verfügung, das geht bei geringem Umfang: https://www.sparkasse.de/privatkunden/konto-karte/iban-rechner.html Viel Erfolg! Konrad -Ursprüngliche Nachricht- Von: Hanna Ganter [mailto:hanna.gan...@online.de] Gesendet: Mittwoch, 8. Januar 2014 21:25 An: users-de@openoffice.apache.org Betreff: Dateiformat csv für SEPA-account converter Guten Tag, liebe Helfer! Ich muss für den SEPA-Lastschrifteinzug zum Umrechnen der alten Kontodaten in die IBAN und BIC Nummern eine Tabelle als Dateityp CSV (Trennzeichen getrennt) (.csv) speichern. Ich krieg das leider nicht so hin, dass der SEPA-converter (Sparkasse) es annimmt. Kann jemand helfen? Dank und Gruß Hanna Ganter -- Hanna Ganter Sägegasse 12 79244 Münstertal Telefon und Fax 07636 1736 - To unsubscribe, e-mail: users-de- unsubscr...@openoffice.apache.org For additional commands, e-mail: users-de- h...@openoffice.apache.org - To unsubscribe, e-mail: users-de-unsubscr...@openoffice.apache.org For additional commands, e-mail: users-de-h...@openoffice.apache.org
Re: AW: Dateiformat csv für SEPA-account converter
Man kann die IBAN tatsächlich nach guter alter Sitte mit der Hand ausrechnen (nimmt etwa eine DIN-A4-Seite in Anspruch). Die Probleme sind tatsächlich häufig woanders. Beispielsweise kennen manche Menschen ihre vollständige Kontonummer nicht. Bei einigen Banken gibt es nämlich eine Stammnummer und angehängt Ziffern für Unterkonten z.B. Giro-, Sparkonten etc.. Die Banken haben aber auch dann Überweisungen ausgeführt, bei der nur die Stammnummer angegeben war. Für die IBAN braucht man jedoch die vollständige Kontonummer (also mit Unterkontonummer). Will man auch die Kontonummer verprüfen, so soll es dafür allein in Deutschland über 140 verschiedene Verfahren geben (das Prüfverfahren ist also von Bankengruppe zu Bankengruppe verschieden). Man braucht also eine Datenbank, um anhand der BLZ das richtige Kontonummerprüfverfahren anzuwenden. Bessere Programme haben das implementiert. Die IBAN darf auch nur vom kontoführenden Institut errechnet und ausgegeben werden. Wer eine nicht vom Kreditinstitut ausgegebene IBAN benutzt, kann beim Auftreten von Fehlern nicht das Kreditinstitut haftbar machen und auch sonstige Rechtsverluste erleiden. Das Hauptverfahren zur Berechnung der Prüfziffer der IBAN kann übrigens nicht in einem Starbasic-Makro umgesetzt werden, da der zu bearbeitende Integerwert zu viele Stellen hat. Man muss also dann auf die dokumentierten Hilfsverfahren ausweichen. Gruß Michael signature.asc Description: OpenPGP digital signature
Dateiformat csv für SEPA-account converter
Hallo Jörg, es funktioniert! Ganz herzlichen Dank. Man muss halt nur wissen wie, die Sprache mit ,*;, etc beherrsche ich leider nicht. Deine Hilfe erspart mir einige Stunden Arbeit (der Einzelumrechnung für die ganze Vereinsmitgliederliste) Viele Grüße Hanna -- Hanna Ganter Sägegasse 12 79244 Münstertal Telefon und Fax 07636 1736 - To unsubscribe, e-mail: users-de-unsubscr...@openoffice.apache.org For additional commands, e-mail: users-de-h...@openoffice.apache.org
Re: [SOLVED] Auf der Liste mit Konto von web.de anmelden
Am Montag, den 30.12.2013, 23:24 +0100 schrieb H.-Stefan Neumeyer: Nur noch für's Archiv: Nach dem nichts, aber auch wirklich nichts mit diesem Konto zu wollen war - sogar eine Anmeldung von einem meiner Rechner mit Evolution, Mutt oder KMail wurde verweigert - haben wir extra für die Liste(n) einen eigenen Mailaccount angelegt. Und damit lief die Registrierung auf Anhieb. -- Gruß Stefan Die e-Mail-Adresse nimmt grundsätzlich keine privaten Nachrichten entgegen. Solche bitte an hsn.neumeyer[dot]arcor.de senden. GnuPG-Schluesselkennung für diese Adresse: 7C9AB525 Für dort unverschlüsselt eingehende Nachrichten behalte ich mir vor diese nicht zu beachten! signature.asc Description: This is a digitally signed message part
Re: Update
Hi, Am 09.01.2014 10:55, schrieb Jörg Schmidt: From: Bernd Kloß [mailto:kloss.mail...@gmail.com] Sent: Thursday, January 09, 2014 10:37 AM To: users-de@openoffice.apache.org Subject: Re: Update Hallo Freund, mittlerweile gibt es für den Mac mindestens LibreOffice 4.1.4.2. Okay, ich weiß, falsche Fraktion. Aber das läßt sich herunterladen und funktioniert bestens, zumindest auf meinem MacBook 64, Mavericks. Und LO hat schon einige Extensions an Bord. Bitte nicht steinigen. Wir sind doch eine Familie. Mut zum Wechsel? Mut für Wahrheiten? https://www.heise.de/artikel-archiv/ct/2014/01/140_Standfester-Oldie Alle 6 Wochen eine neue Version herauszubringen und dabei gleichzeitig darauf hinzuweisen, dass man bei Wertlegung auf Stabilität die ältere Version nehmen soll, erscheint mir schon sonderbar. AFAIK war die Formulierung betreffs des Unterschieds früheren Versionen deutlicher. IMHO sind dies Beta- oder zumindest RC-Versionen. Dies hatte ich im LO-Forum mal so geäußert, was man gar nicht gerne gehört hat. Ich möchte OO nicht missen und hoffe, dass so einige Dinge nicht impliziert werden, wie z.B. Wegfall der Seitenumrandung oder Ausblenden der Gitterlinien in Calc, wenn eine Zellhintergrundfarbe genutzt wird. Dies wurde nach heftigen Protesten reversibel gemacht, bei der Seitenumrandung werden allerdings die 'nichtdruckbaren Zeichen' mit eingeblendet, nicht schön. Gruß - To unsubscribe, e-mail: users-de-unsubscr...@openoffice.apache.org For additional commands, e-mail: users-de-h...@openoffice.apache.org
Re: Dateiformat csv für SEPA-account converter
Hallo Hanna! Auch wenn Dein Problem zwischenzeitlich gelöst wurde - hier noch mal ein Nachtrag für CALC-Tüftler zum selbstberechnen von (deutschen) IBAN-Nr.: Im Grunde ist die IBAN-Nr. nämlich nur eine zusammengesetzte Nummer aus der altbekannten BLZ und der üblichen Konto-Nr. - sonst (fast) nix! Fast nix? Naja: Die IBAN-Nr. muß immer mit einem Länderkennzeichen beginnen (für Deutschland DE) und zwischen diesem Länderkennzeichen und der eigentlichen Konto-Information muß noch eine sogenannte Prüffziffer eingefügt werden. Diese Prüfziffer ist quase eine Art Quersumme der kompletten Zahlenreihe und verhindert z.B. Tippfehler: Falls der Empfänger aus den übermittelten Konto-Infos diese Prüfziffer nicht korrekt nach- rechnen kann, dann ist irgendwas schief gelaufen. Gerade diese Prüfziffer ist der Stolperstein, der aber - wenn man sich ein bißchen reinhängt - relativ leicht zu durchschauen ist. Beim Zusammensetzen einer IBAN-Nr. muß man noch ein bißchen auf die richtige Stellenanzahl achten: Die BLZ ist in Deutschland zum Glück immer gleich lang: 8 Stellen. Kontonummern können unterschiedlich lang sein und müssen deshalb rechtsbündig evtl. mit Vor-Nullen auf 10 Stellen getrimmt werden. Diese beiden Zahlen werden dann einfach hinteranander gestellt und ergeben schon mal das 1. Teil-Ergebnis: die sogenannte BBAN (Basic Bank Account Number). Wichtig ist noch, daß keine Leerzeichen, Punkte oder sonstige Sonder- zeichen im Code enthalten sind. Das also wäre schon mal die Basis - jetzt geht's los: Gebrauchsanleitung zum Selbstberechnen einer IBAN-Nr. mit Hilfe einer Tabellenkalkulation (z.B. OO-Calc): === Wir bauen die Tabelle erst mal 1-zeilig von links nach rechts auf. Dadurch lassen sich später die einzlenen Rechenfelder bequem mit festgehaltener Maus nach unten vervielfältigen. Feld [A1] = Ländercode (für Deutschland DE) bereitstellen. Einfach als normales Textfeld füllen. ACHTUNG: Nur Grossbuchstaben!! Feld [B1] = BLZ bereitstellen (als Zahl). Feld [C1] = Kontonummer bereitstellen (als Zahl). Feld [D1] = BBAN aus BLZ + KtoNr. zusammensetzen. Die Feldfuntion TEXT(B1;) TEXT(C1;00) stellt die korrekte Stellenanzahl von BLZ (8-stellig) + KtoNr. (10-stellig) als formatierte Zeichenkette zur Verfügung. Feld [E1] = Numerische Werte des Ländercodes ermitteln: Die Buchstaben A-Z müssen in Zahlenwerte 10-35 umgewandelt werden. Dazu ermitteln wir einfach mit dem Feldfunktion CODE den ASCII-Code der einzelnen Zeichen und ziehen davon jeweils den Wert 55 ab. Das Computer- Alphabet beginnt bei A mit dem ASCII-Code 65, abzügl. 55 ergibt also z.B. für den Buchstaben A die gewünschte Zahl 10! Mit der Feldfunktion LINKS und RECHTS kann man das erste und das letzte Zeichen einer Zeichenkette extrahieren. Da wir nur 2 Zeichen haben, reicht das für unsere Zwecke: CODE(LINKS(A1))-55 CODE(RECHTS(A1))-55 - fertig. Feld [F1] = Prüfziffer berechnen. Die Prüfziffer ergibt sich aus dem Divisionsrest - genannt Modulo - von (BBAN + Num.Ländercode + 00)/97. Der Feldfunktion für die Modulorechnung heißt REST. Zur internen Berechnug von REST muß der Funktionscode WERT verwendet werden, da alle interessanten Felder als Text formatiert wurden. = REST( WERT(D1 E1 00); 97 ) - FUNKTIONIERT LEIDER NUR THEORETISCH!!! Feld [G1] = die fertige IBAN-Nr. Die bisherigen Teilergebnisse werden in der Reihenfolge Ländercode, Prüfziffer und Basic Account Number aneinandergereiht. = A1 F1 D1 - FERTIG! ... schön wär's! Leider kann CALC mit solchen großen Zahlen keine Moduloberechnungen anstellen - jetzt wird's doch etwas komplizierter: Die Modulorechnung muß in Teilschritten von jeweils 9 Stellen von links nach rechts über die gesamte Ziffernfolge laufen, wobei ab dem 2. Schritt jeweils der Divisionsrest aus dem vorhergehenden Schritt vorangestellt wird. Dazu müssen folgende Funktionscodes verschachtelt werden, wobei ich auf eine explizite Erläuterung verzichte (diese Mail würde sonst zu umfangreich): Hilfsfeld Nr.1: [H1] = Divisionsrest aus (erste 9 Stellen von [D1])/97 = REST( WERT( LINKS(D1;9) ); 97 ) Hilfsfeld Nr.2: [I1] = DR. aus (Ergebnis[H1] + nächste 9 Stellen)/97 Hierzu muß das Divisionergebnis der vorherigen Rechnung vorgestellt werden = REST( WERT( LINKS( TEXT(H1;00) TEIL(D1;10;9); 9) ); 97) Hilfsfeld Nr.3: [J1] = DR. aus (Ergebnis[I1] + nächste 9 Stellen)/97 = REST( WERT( LINKS( TEXT(I1;00) TEIL(D1;17;9); 9) ); 97) Hilfsfeld Nr.4: [K1] = DR. aus (letzte Stellen + num.Ländercode + 00)/97 = REST( WERT( LINKS( TEXT(J1;00) TEIL(D1;24;9) E1 00; 9 ) ); 97) ... jetzt können wir dem Feld [F1] die richtige Prüfziffer übergeben: Dazu wird der letzte Restwert aus Feld [K1] von der Zahl 98 subtrahiert und wieder mal als 2-stelliges Textfeld formatiert (wegen Vor-Nullen): = TEXT((98-K1);00) ... und im Feld [G1] erscheint nun auch die korrekte IBAN-Nummer gemäß der Formel, wie sie weiter oben bereits von mir definiert wurde. Viel Spaß beim Ausprobieren! Gruß: Ernst P.S. Die bei uns
Re: Dateiformat csv für SEPA-account converter
Am 09.01.2014 17:26, schrieb E.J.Minhorst: ... und im Feld [G1] erscheint nun auch die korrekte IBAN-Nummer gemäß der Formel, wie sie weiter oben bereits von mir definiert wurde. Ist das sicher? AFAIK gibt es zig verschiedene Berechnungsmethoden für die IBAN. Gruß - To unsubscribe, e-mail: users-de-unsubscr...@openoffice.apache.org For additional commands, e-mail: users-de-h...@openoffice.apache.org
Re: Update
Hi Am 09.01.14 08:26, schrieb Mag. Hans Lach: Ich wollte vor kurzem das Update 4.0.1 auf meinen Mac Book Air herunterladen. Wie Ihr wisst, ist dies ein 64 Bit System. Ich habe natürlich auch Mavericks! Beim Herunterladen ist jedoch ein Fehler aufgetreten, es kam immer - ich versuchte den Download 3mal! - die Meldung „Programm beschädigt, bitte löschen!“. Liegt dies vielleicht daran, dass die Version die 4.0.1. für Mac auf 32 Bit erstellt wurde? Nein. Es wäre hilfreich zu wissen, ob die Meldung beim Öffnen des heruntergeladenen .dmg kommt oder beim Start des aus dem dmg in Programme kopierten Programms? (btw: der Versuch, das Programm im heruntergeladenen dmg (disk image) direkt zu starten, schlägt meistens fehl.) Es sollte eigentlich sagen Open Office kann nicht geöffnet werden, weil es nicht von einem zertifizierten Entwickler stammt. Das liegt daran, dass die Apache Fondation bislang versäumt hat, ein Software-Zertifikat für AO von Apple zu besorgen. Schau mal in die Systemeinstallungen - Sicherheit - Allgemein. Dort sollte Mac App Store und verifizierte Entwickler markiert sein. Jetzt kannst Du entweder Keine Einschränkungen anklicken, AO einmal starten und das wieder zurücksetzen oder aber das Programm mit einem Rechtsklick auf das Programm und Öffnen starten. Der Mac fragt Dich dann, ob Du das wirklich willst - sag ja und alles wird gut. Und: Ja, man kann ohne Probleme LibreOffice und Apache Open Office auf dem Mac parallel installieren. -- Mit freundlichen Grüßen Uwe Altmann - To unsubscribe, e-mail: users-de-unsubscr...@openoffice.apache.org For additional commands, e-mail: users-de-h...@openoffice.apache.org
Re: Update
Hallo Jörg, danke für das Angebot. Anbei mal ein Beispiel ohne großen Firlefanz. https://dl.dropboxusercontent.com/u/16673743/Test-Achse.ods Als Zeichensatz für die Hochwertachse geht in LO nur Lucida Grande und ich kann keine Exponenten „-1“ ordentlich schreiben. In der Legende bekomme ich das gar nicht hin. Auch der Umweg über das Einfügen aus der Zeichensatztabelle bringt keine befriedigende Lösung. Latex ist halt nicht für den schnellen täglichen Gebrauch und nicht für die Weitergabe an andere geeignet. Aber vielleicht ist das in OO besser gelöst. Viele Grüße Bernd Am 09.01.2014 um 11:54 schrieb Jörg Schmidt joe...@j-m-schmidt.de: From: Bernd Kloß [mailto:kloss.mail...@gmail.com] Sent: Thursday, January 09, 2014 11:26 AM To: users-de@openoffice.apache.org Subject: Re: Update Immer! Sind die Dateiformate noch 100% kompatibel? Jein, das sind sie auch nie gewesen, denn LO basierte von Anfang an auf go-oo und das unterschied sich schon immer von OO. Etwas genauer gesagt: Da beide Programme ODF nutzen, sind sie natürlich kompatibel im Sinne der Formatdefinition, da es aber im Format z.B. zulässige optionale Inhalte gibt (z.B. Makros) oder z.B. unterschiedliche Wiedergaben von Formatierungen (bei der Darstellung durch das jeweilige Programm) sind Dateien in Praxis nicht völlig kompatibel im Wortsinn. Sehr wahrscheinlich sind aber OO/LO untereinander immer noch weit kompatibler als OO oder LO verglichen mit anderen Programmen (z.B. fiel ja vor einigen Jahren ein Vergleich der C't von KOffice und OOo hinsichtlich der Kompatibilität von Dokumenten sehr ernüchternd aus) Kann man LO und OO gefahrlos auf dem Mac parallel installieren? Ich weiß garnichts zu MacOS, sonst wäre ich bereits auf die Frage des OP eingegangen. Ich habe da in LO schon ein paar Bugs, die nerven. Z. B. in Calc die Achsen-Beschriftung von Diagrammen mit negativen Exponenten und griechischen Symbolen. Klappt sowas einwandfrei in OO? Wahrscheinlich eine Frage des konkreten Diagramms. Wennn Du ein Beispiel hast kann ich es ausprobieren. Ein testweise angelegtes Säulen-Diagramm (griechisch als Beschriftung plus Exponentialwerte mit negativem Exponennten) macht hier keine Probleme, nur kann mein zufälliges Beispiel ganz irrelevant für Deine Anforderung sein. Erfahrungen damit? Nein, ich nicht was die konkrete Frage negativen Exponenten und griechischen Symbolen betrifft. Gruß Jörg - To unsubscribe, e-mail: users-de-unsubscr...@openoffice.apache.org For additional commands, e-mail: users-de-h...@openoffice.apache.org - To unsubscribe, e-mail: users-de-unsubscr...@openoffice.apache.org For additional commands, e-mail: users-de-h...@openoffice.apache.org
Re: Update
Hallo Bernd, Anbei mal ein Beispiel ohne großen Firlefanz. https://dl.dropboxusercontent.com/u/16673743/Test-Achse.ods Als Zeichensatz für die Hochwertachse geht in LO nur Lucida Grande und ich kann keine Exponenten „-1“ ordentlich schreiben. In der Legende bekomme ich das gar nicht hin. Offenbar wird nur der blanke Text ohne Formatierungen in die Legende übernommen. Aber vielleicht ist das in OO besser gelöst. Nein. Das ist dort genauso. Was spricht prinzipiell gegen die Angabe m/s? Ansonsten bleibt dir nur: http://de.wikipedia.org/wiki/Unicodeblock_Hoch-_und_tiefgestellte_Zeichen Klappt doch ganz gut: ms⁻¹²³⁰⁴⁵⁶⁷⁹... Du musst natürlich eine Schrift verwenden, die diese Zeichen enthält. Beispiel: http://www.scitec4.org/transfer/LegendeNegativePotenzen.ods Gruß, Michael - To unsubscribe, e-mail: users-de-unsubscr...@openoffice.apache.org For additional commands, e-mail: users-de-h...@openoffice.apache.org
Re: AW: Dateiformat csv für SEPA-account converter
Hallo, -Original Message- From: RA Stehmann [mailto:anw...@rechtsanwalt-stehmann.de] Das Hauptverfahren zur Berechnung der Prüfziffer der IBAN kann übrigens nicht in einem Starbasic-Makro umgesetzt werden, da der zu bearbeitende Integerwert zu viele Stellen hat. Man kann das als Stringberechnung implementieren. Ich bin zu faul es selbst hinzuschreiben, weswegen ich auf ein Beispiel in VBA verweise: http://www.ms-office-forum.net/forum/showthread.php?t=259499 Dort ist nur in der Zeile die eine Fehlermeldung wegen des Dateityps bringt ein VAL() zu ergänzen, aus: bytPrd = Mid$(strNo1, lngVar1, 1) * Mid$(strNo2, lngVar2, 1) + bytCarry Wird also: bytPrd = VAL(Mid$(strNo1, lngVar1, 1)) * VAL(Mid$(strNo2, lngVar2, 1)) + bytCarry Gruß Jörg - To unsubscribe, e-mail: users-de-unsubscr...@openoffice.apache.org For additional commands, e-mail: users-de-h...@openoffice.apache.org
Re: AW: Dateiformat csv für SEPA-account converter
-Original Message- From: RA Stehmann [mailto:anw...@rechtsanwalt-stehmann.de] Sent: Thursday, January 09, 2014 12:48 PM To: users-de@openoffice.apache.org Subject: Re: AW: Dateiformat csv für SEPA-account converter Man kann die IBAN tatsächlich nach guter alter Sitte mit der Hand ausrechnen (nimmt etwa eine DIN-A4-Seite in Anspruch). Die Probleme sind tatsächlich häufig woanders. Beispielsweise kennen manche Menschen ihre vollständige Kontonummer nicht. Bei einigen Banken gibt es nämlich eine Stammnummer und angehängt Ziffern für Unterkonten z.B. Giro-, Sparkonten etc.. Die Banken haben aber auch dann Überweisungen ausgeführt, bei der nur die Stammnummer angegeben war. Für die IBAN braucht man jedoch die vollständige Kontonummer (also mit Unterkontonummer). Will man auch die Kontonummer verprüfen, so soll es dafür allein in Deutschland über 140 verschiedene Verfahren geben (das Prüfverfahren ist also von Bankengruppe zu Bankengruppe verschieden). Man braucht also eine Datenbank, um anhand der BLZ das richtige Kontonummerprüfverfahren anzuwenden. Bessere Programme haben das implementiert. Die IBAN darf auch nur vom kontoführenden Institut errechnet und ausgegeben werden. Wer eine nicht vom Kreditinstitut ausgegebene IBAN benutzt, kann beim Auftreten von Fehlern nicht das Kreditinstitut haftbar machen und auch sonstige Rechtsverluste erleiden. Das Hauptverfahren zur Berechnung der Prüfziffer der IBAN kann übrigens nicht in einem Starbasic-Makro umgesetzt werden, da der zu bearbeitende Integerwert zu viele Stellen hat. Man muss also dann auf die dokumentierten Hilfsverfahren ausweichen. Gruß Michael - To unsubscribe, e-mail: users-de-unsubscr...@openoffice.apache.org For additional commands, e-mail: users-de-h...@openoffice.apache.org
Re: Dateiformat csv für SEPA-account converter
Hallo, From: Josef Latt [mailto:josef.l...@gmx.net] Ist das sicher? AFAIK gibt es zig verschiedene Berechnungsmethoden für die IBAN. Wenn z.B. Wikipedia die Wahrheit sagt: http://de.wikipedia.org/wiki/International_Bank_Account_Number Und Ernst sich nicht verrechnet hat, Sollte das natürlich richtig sein, denn die verschiedenen Rechenverfahren bringen doch keine unterschiedliche IBAN hervor, sonst wäre diese ja nicht eindeutig. Berechnungsmethoden meint doch hier nur das man gleiche Werte (es geht hier im Eigentlichen nur um die Prüfziffern) auf unterschiedlichem Wege berechnen kann. Richtig ist wohl, ich habs irgendwo gelesen als ich die Rechenverfahren quergelesen habe, das es in Ausnahmefällen (bei ungünstiger Kombination BLZ+Kto-Nr.+Land) Probleme geben kann, ich kann dafür aber kein konkretes Beispiel geben. Gruß Jörg - To unsubscribe, e-mail: users-de-unsubscr...@openoffice.apache.org For additional commands, e-mail: users-de-h...@openoffice.apache.org
Re: Update
Hallo, -Original Message- From: Bernd Kloß [mailto:kloss.mail...@gmail.com] Sent: Thursday, January 09, 2014 11:31 PM To: users-de@openoffice.apache.org Cc: joe...@j-m-schmidt.de Subject: Re: Update Hallo Jörg, danke für das Angebot. Anbei mal ein Beispiel ohne großen Firlefanz. https://dl.dropboxusercontent.com/u/16673743/Test-Achse.ods Als Zeichensatz für die Hochwertachse geht in LO nur Lucida Grande Hier in OO geht Alles, also beliebige Schriften (hasbe natürlich nicht Alle probiert, aber z.B. Verdana oder Arial gehen) oder ich verstehe das Problem falsch. In der Legende bekomme ich das gar nicht hin. Für solche Fälle (manchmal gilt es auch beliebige Zusatzbeschriftungen in ein Diagramm zu bringen) gibt es den Trick das in das Diagrammobjekt einzukopieren, beispielsweise: -lass die Zeichenfunktionen (in Calc) anzeigen -nimm die Textfunktion (das T) und ziehe einen 'Rahmen' damit auf -schreibe in den 'Rahmen' v in ms-1 -stelle das -1 mit Format-Zeichen hoch -stelle die richtige Größe des Rahmens ein -markiere und kopiere den Rahmen -doppelklicke das Diasgramm um es in den Editiermodus zu bringen -füge jetzt in das Diagramm den kopierten Text ein Der Text ist nun Teil des Diagrammobjekts und kann zusammen mit dem Diagramm verschoben werden. Für Deinen Fall müsstest Du nun noch eine kleine Grafik dazutun, das sollte mit Gruppieren zu vereinfachen sein. Gruß Jörg - To unsubscribe, e-mail: users-de-unsubscr...@openoffice.apache.org For additional commands, e-mail: users-de-h...@openoffice.apache.org
