Kontoauszüge automatisch auswerten

[Alfonso]

Hallo,

wir möchten Kontoauszüge, die als CSV vorliegen, einlesen und automatisch in einer Fakturasoftware einlesen. Die Software enthält offene Rechnungen und es soll automatisch erkannt werden, welche Rechnungen bezahlt wurden.

Welchen Algotithmus oder Methode würdet ihr verwenden um den Match zu machen? Die Software kennt Rechnungsnummer (Format PP-xx/jahr), wobei P ein beliebiger Präfix ist und xx eine fortlaufende Nummer. Ferner kennt die Software den Rechnungsempfänger und das Rechnungsdatum.

Wie würdet ihr vorgehen?

Danke
Alfonso

[Dejan Vu]

Erst alle offenen Rechnungen in eine Dictionary laden
Dann die CSV-Datei einlesen und Rechnungsnummern extrahieren (bzw. das, was wie eine Re-Nr. aussieht). Jeden Kandidaten in der Dictionary nachschlagen (ob es die Rechnungsnummer gibt). Dann den Betrag von der Rechnung abziehen und -wenn vollständig bezahlt- die Rechnung aus der Dictionary entfernen (wäre ja denkbar, das Teilzahlungen möglich sind).

Eine Fehlerbehandlung gehört auch dazu, d.h. extrahierte Rechnungsnummernkandidaten, die keiner Rechnung zugeordnet werden können könnten ein Tippfehler sein oder eben gar keine Rechnungsnummer.

Bei Verdacht auf Tippfehler könnte man den Kandidaten noch mit Levenshtein (max. Distanz 1) auf die übriggebliebenen Rechnungen in der Dictionary loslassen.

Auf jeden Fall ist das etwas riskant, denn ihr habt ja offensichtlich kein festes Format für die Angabe der Re-Nr. im Betreff-Feld. Ergo muss man parsen und interpretieren. Und da ist immer eine Unsicherheit dabei.

[Perlsau]

Moin, ich würde so vorgehen:

Meine Bank-CSV-Dateien enthielten damals, als ich mich damit befaßt hatte, Kontonummer und Bankleitzahl des Kunden oder Lieferanten (auch bei Abbuchungen, wenn im Laden mit Karte bezahlt wurde), heute wohl BIC oder was es da so gibt. Anhand dieser Daten sollte man den Kunden eindeutig und fehlerfrei ausfindig machen können. Bankdaten sind im Gegensatz zu Daten, die vom Kunden eingetragen wurden, annähernd 100%ig zuverlässig. Ich würde daher die Bankdaten als Erkennungsmerkmal präferieren und den eingegangenen Betrag von der ältesten unbezahlten Rechnung abziehen, unabhängig davon, was der Kunde diesbezüglich eingetragen hat. Gewöhnlich hat man ja sowieso nur eine offenstehende Rechnung pro Kunde, denn vor der Annahme des nächsten Auftrags sollte der vorhergehende bezahlt worden sein. In der Datenbank sollten dann auch die Bankdaten eine eigene Tabelle beanspruchen, wiel ein Kunde ja unter Umständen über mehrere Konten verfügt. Im Fall eines Neukunden, von dem noch keine Überweisungen vorliegen, könnte es natürlich sein, daß eine Zahlung nicht zugewiesen werden kann, weil eben noch keine Bankdaten eingetragen wurden. Diese Fälle müssen dann, nachdem auch das Parsen der Betreff-Felder nichts ergeben hat, von einem Mitarbeiter persönlich bearbeitet werden, indem er die Bankdaten einträgt und den betreffenden Datensatz noch einmal von der Software bearbeiten läßt.

[jaenicke]

Welcher Weg möglich ist, hängt sehr davon ab um welchen Kundenkreis es sich handelt. Wenn die Kunden fest erfasst sind und in der Regel mehrfach bestellen, ist letztere Methode von Perlsau möglich.
Allerdings ist die Frage, ob die Erfassung der Bankdaten, wenn sie nicht durch den Kunden hinterlegt wurden, datenschutzrechtlich in Ordnung ist. Das kann ich nicht beurteilen.

Wenn die Kunden aber eher nur einmal bestellen und auch keine Bankdaten hinterlegen (was bei Zahlung per Überweisung die Regel sein dürfte), lässt sich auf dem Weg nicht viel erreichen.

Daher würde ich eher eine Regular Expression erstellen, die auf das Format der Rechnungsnummer anspricht. Da das Format der Rechnungsnummer gut erkennbar ist, sollte das in der Regel kein Problem sein.

Problematisch ist es, wenn sich ein Kunde verschreibt. An der Stelle sollte es aber reichen, wenn man den Betrag abgleicht. Stimmt der nicht, wird die Rechnung in eine Prüfliste eingetragen, die dann manuell durchgesehen werden muss. Kommen Teilzahlungen öfter vor, müsste man sich da evtl. noch mehr einfallen lassen (Abgleich des Absenders und / oder des restlichen Betreffs mit den Daten des Kunden, ...).

[Dejan Vu]

Zitat:

Zitat von jaenicke (Beitrag 1325391)

Daher würde ich eher eine Regular Expression erstellen, die auf das Format der Rechnungsnummer anspricht. Da das Format der Rechnungsnummer gut erkennbar ist, sollte das in der Regel kein Problem sein.

Das deckt sich in etwa mit meinem Ansatz. Ich weiss nicht, ob eine RegEx hier geeignet ist. Man will ja u.a. auch unscharfe Matches und dann wird so eine RegEx sehr schnell sehr unübersichtlich. Aber im Prinzip in jedem Fall ein geeignetes Hilfsmittel.

Egal wie: Je mehr Freiheiten man dem Kunden lässt, sein Überweisungsformular auszufüllen, desto schwerer hat man es hinterher, die Information zu entschlüsseln.

Daher mein wichtigster Tipp: Sage dem Kunden genau(!), wie er die Überweisung durchzuführen hat.

• Rechnungsnummer ohne Zusätze ins Betrefffeld
• oder Kundennumer + Rechnungsnummer (je nach Anwendungsfall)
• oder nur die Kundennummer
• oder oder oder

Aber in jedem Fall EINE strikte Anweisung.

[jaenicke]

Zitat:

Zitat von Dejan Vu (Beitrag 1325392)

Ich weiss nicht, ob eine RegEx hier geeignet ist. Man will ja u.a. auch unscharfe Matches und dann wird so eine RegEx sehr schnell sehr unübersichtlich.

Die Unschärfe wird aber ja nicht bei der Rechnungsnummer selbst benötigt, denn die ist ja klar definiert.
Wenn deren Format nicht stimmt, bin ich mir nicht sicher, ob man da versuchen sollte automatisch etwas zu finden...

Man könnte natürlich den Schrägstrich zum Beispiel in einem zweiten Versuch einfach optional machen. Aber je mehr man weglässt desto höher wird die Chance einer Fehlerkennung. Wobei der Betrag natürlich noch eine zusätzliche Sicherheit bietet.

Ich schreibe bei Überweisungen zum Beispiel prinzipiell immer Rechnungsnummer (oder was drauf soll) und meinen Namen drauf um notfalls eine manuelle Zuordnung zu ermöglichen, wenn die Nummer nicht gefunden werden sollte.

Ich denke mal es sollte aber genügend historisches Material vorhanden sein um zu evaluieren welche Ansätze nötig sind ohne zu viel manuelle Nacharbeit zu erfordern.

[Dejan Vu]

Völlig richtig, nur besteht leider ein Unterschied zwischen 'Klar definiert' und 'ich schreibe'. ;-)

[mm1256]

Hallo,

ich mache das seit knapp 2 Jahren so:

Bei jedem Kunden ist eine Standard-Bankverbindung, und wahlweise mehrere zusätzliche Bankverbindungen hinterlegt
Die Kontoauszüge werden in eine Datenbank eingelesen. Aus den nachstehenden Feldern erstelle ich einen MD5-Hash, der im Datensatz mit gespeichert wird, und für die Eindeutigkeit des Datensatzes verwendet wird.
Hintergrund: Es sollte ausgeschlossen werden, dass der User eine Datei mehrfach einliest. Zudem bieten manche Banking-Programme (z.B. Windata) die Option, beim Export den letzten Buchungstag nochmals zu wiederholen.

Felder für den Hash:
Datum : TDateTime; // Auszug-Datum
Valuta : TDateTime; // Valute-Datum
Blz : string[8];
Konto : string[10];
Umsatz : double;
BuchungsText: string[27];
VerwendungsZweck: string[216]; // 8 Verw.Zw. * 27 Zeichen
Auszug : double; // Format: AuszugNummer.Seite
WKennz : string[3];
AG_Name1 : string[27];
AG_Name2 : string[27];
AG_Blz : string[8];
AG_Konto : string[10];
AG_IBAN : string[22];
AG_BIC : string[11];

Wenn die Kontoauszüge in die DB eingelesen wurden, können sie gebucht werden, und werden im Erfolgsfall als gebucht gekennzeichnet. Für das Buchen gibt es eine kleine DB mit Buchungsregeln, die frei definierbar sind, und auf jeden Buchungssatz angewendet werden. Reichen die Regeln nicht aus, oder müssen sie angepasst/verändert werden, ändere ich nur die DB und muss das Programm nicht neu compilieren.

Aktuell läuft das so:

1. Ist eine Rechnungsnummer im Verwendungszweck eindeutig vorhanden? Stichwort Umbrüche bei den Verwendungszwecken.
2. Hat der Kunde (der aus der Rechnungsnummer ermittelt wird) einen Offenen Posten?
3. Passt dieser Offene Posten zum Betrag auf dem Kontoauszug? Dabei wird mögliche Skontierung berücksichtigt. Ist der Betrag höher, wird geprüft (rekursiv) ob der Kunde eventuell mehrere Rechnungen zu einer Zahlung zusammengefasst hat
3. Stimmt die Bankverbindung überein?

Dem Anwender werden dann in einem Buchungsdialog die automatisch ermittelten Daten angezeigt. Stimmen alle Buchungsregeln überein, wird das optisch angezeigt (die Ampel steht auf "grün") und der Anwender kann die Buchung sofort vornehmen. Fehlt z.B. die Bankverbindung, kann diese wahlweise gleich beim Kunden eingetragen werden. Im Gegenzug wird die Kundennummer im entsprechenden Zahlungsvorgang beim Kontoauszug eingetragen. Bereits beim Importieren der Kontoauszüge werden die Kontoauszüge gekennzeichnet, ob die Bankverbindung bereits bekannt ist. Ist eine Bankverbindung mehrfach vorhanden wird im Buchungsdialog darauf hingewiesen, um Fehlbuchungen zu vermeiden.

Dieses Schema wende ich auch bei den Lieferantenrechnungen an, und an der Implementierung für die Personaldaten (Löhne) arbeite ich gerade.

Der Vorteil der DB-Lösung liegt also darin: Sie ist flexibel erweiterbar. Möchte dann ein Anwender zudem die Daten noch an die Buchhaltung übergeben, was ja früher oder später der nächste logische Schritt bei der Verarbeitung der Buchungen ist, so stehen hierzu bereits alle Daten zur Verfügung. Man muss nur noch die Exportfunktion programmieren.

[Mavarik]

Zitat:

Zitat von Alfonso (Beitrag 1325384)

Welchen Algotithmus oder Methode würdet ihr verwenden um den Match zu machen? Die Software kennt Rechnungsnummer (Format PP-xx/jahr), wobei P ein beliebiger Präfix ist und xx eine fortlaufende Nummer. Ferner kennt die Software den Rechnungsempfänger und das Rechnungsdatum.

Wie würdet ihr vorgehen?

Die Frage ist was machen die Kunden...

1.) Der Kunde schreibt seinen Namen anders als bei Dir in der Datenbank erfaßt..
Beispiel: Bei Dir steht "A.L.S.O" der Kunde schreibt aber "ALSO" oder "Ra Maier" -> "Rechtsanwälte Petersen, Klaus & Maier"
2.) Der Kunde gibt nicht aktuele Rechnungsnummer an, sondern hat die Vorgabe der Banksoftware übernommen und es ist die alte Rechnungsnummer
3.) Der Kunde schreibt nicht sauber (ohne Bankprogramm) 2712/15 ergibt "27l1(1S"
4.) Der Betrag stimmt nicht mit der Rechnung überein. Vertippt oder (unberechtigtes) Skonto

Dann kommt es darauf an wie die Rechnungen aussehen...

100 Kunden erhalten die gleiche Rechnung mit der gleichen Summe... Blöd für einen Betragsvergleich.

Bei mir läuft die Analyse über mehrere Stufen.

1. Texte nominieren... Sonderzeichen raus und ggf. Token wie "Ra" -> "Rechtsanwalt" erstzen. Hier habe ich eine "selbstlernende" Liste die bei einem Treffen die Ersetzungstabelle befüllt.
2. Falschbuchstaben-Erkennung. S -> 5, ( -> /, l -> 1 usw.
3. Offene gegen Betrag falls Betrag nur 1x vor kommt und ggf. Rest noch passt..

usw... Insgesammt habe ich 8 Stufen und daran 4 Monate entwickelt...

Meine Trefferquote liegt zu Zeit bei ca. 1000 Buchnungen werden ca. 80 nicht erkannt oder werden zur Überprüfung (um sicher zu gehen) auf dem Bildschirm angezeigt. Davon können i.d.R. 60 mit ok bestätigt werden. Rest ist Handarbeit.

Zur Zeit arbeite ich noch an der Zuordnung Paypal, Amazon & Kreditkartenabrechnung (Währungsumrechnungen, Gutschriftverrechnung und splitten von Sammeleinzügen...)

Nächster schritt wir eine Multi-Thread Anpassung, da die ganzen Datenbankzugriffe und analysen zu langsam geworden sind.

Es gibt noch viel zu tun...

Mavarik

[mm1256]

Hallo,

die Frage "was machen die Kunden" stellt sich - so wie es aussieht - beim TE in diesem Umfang wohl gar nicht, und somit wäre das Parsen der Texte nicht sein größtes Problem. Es geht offensichtlich um Privatliquidation für Ärzte, und da wird sich die Anzahl der (Privat-)Patienten nicht stetig ändern. Somit wäre dann die Zuordnung wiederkehrender Zahlungen über die Bankverbindung wohl der erste - und bereits erfolgreiche - Schritt. Erst dann würden die zusätzlichen Überprüfungen folgen.

[Mavarik]

Zitat:

Zitat von mm1256 (Beitrag 1325478)

Hallo,

die Frage "was machen die Kunden" stellt sich - so wie es aussieht - beim TE in diesem Umfang wohl gar nicht, und somit wäre das Parsen der Texte nicht sein größtes Problem. Es geht offensichtlich um Privatliquidation für Ärzte, und da wird sich die Anzahl der (Privat-)Patienten nicht stetig ändern. Somit wäre dann die Zuordnung wiederkehrender Zahlungen über die Bankverbindung wohl der erste - und bereits erfolgreiche - Schritt. Erst dann würden die zusätzlichen Überprüfungen folgen.

Das mag sein, aber es ging um Kontoauszüge automatisch auswerten...

Zum Beispiel bei Einzügen von Dritten wird die Zielkonto Verbindung nicht mit übertragen, sondern nur der Name.
Genauso bei Überweisungen. (Frei nach dem Motto - Musst Du doch wissen, hast es doch selber gemacht)

[mm1256]

Hallo Frank, mal ne Frage: Hast du die HP bzw. die SW des TE mal angesehen?

[Dejan Vu]

Also ich fand den Bericht von Mavarik wirklich sehr interessant. Vielleicht gehörte das direkt zur Problemstellung des TE, aber wenn sich hier mal einer verirrt (ich z.B.), dann weiß er gleich, das mit dem Thema 'Kontoauszüge automatisch auswerten' nicht zu spaßen ist.

Ich musste neulich nur ein paar Telefonnummern, Passport-ID und Adressen von A nach B synchronisieren. 'Neulich' hat dann 8 Monate gedauert, bis alles gepasst hat. Das gehört zwar gar nicht hierhin, zeigt aber, das die einfachen Sachen häufig die langwierigsten sind.

Übrigens: Respekt, Mavarik.

[Perlsau]

Wenn man die Bankdaten verarbeiten will, sind die normalen Kontoauszüge, die man wohl meist als PDF-Datei am Ende des Monats von der Homepage der Bank herunterladen kann, nicht geeignet, denn darin fehlen gewöhnlich die Bankdaten. Die meisten Banken bieten meiner Kenntnis nach jedoch auch detailliertere Informationen zum Download an, die täglich aktualisiert werden. Darin befinden sich dann genau die Details, die man benötigt. Die Kontoauszüge sind für mich lediglich zum "Abheften" bzw. Sichern, mit den Detailinformationen würde ich, wenn ich das bräuchte, arbeiten.

Soweit ich den TE verstanden habe, geht es ihm nicht um eine universelle Problemlösung für alle nur denkbaren Anwendungsfälle, sondern um seinen ganz speziellen Fall, wo ein Kundenstamm mit gewöhnlich gleichbleibenden Bankdaten existiert, von denen aus wiederholt Zahlungen geleistet werden.

[Mavarik]

Zitat:

Zitat von Dejan Vu (Beitrag 1325497)

Also ich fand den Bericht von Mavarik wirklich sehr interessant.
...
Übrigens: Respekt, Mavarik.

Vielen Danke... Genau aus diesem Grund mache ich mir die "mühe" und schreibe eine "so" lange Antwort...

Zitat:

Zitat von Perlsau (Beitrag 1325500)

Wenn man die Bankdaten verarbeiten will, sind die normalen Kontoauszüge, die man wohl meist als PDF-Datei am Ende des Monats von der Homepage der Bank herunterladen kann, nicht geeignet, denn darin fehlen gewöhnlich die Bankdaten. Die meisten Banken bieten meiner Kenntnis nach jedoch auch detailliertere Informationen zum Download an, die täglich aktualisiert werden. Darin befinden sich dann genau die Details, die man benötigt. Die Kontoauszüge sind für mich lediglich zum "Abheften" bzw. Sichern, mit den Detailinformationen würde ich, wenn ich das bräuchte, arbeiten.

Soweit ich den TE verstanden habe, geht es ihm nicht um eine universelle Problemlösung für alle nur denkbaren Anwendungsfälle, sondern um seinen ganz speziellen Fall, wo ein Kundenstamm mit gewöhnlich gleichbleibenden Bankdaten existiert, von denen aus wiederholt Zahlungen geleistet werden.

Es ging auch nicht um PDF's sondern um *.csv

Aber wie ich schon geschrieben habe, sind da leider auch nicht immer alle Infos drinn...

Mavarik

[mm1256]

Sorry, wenn's jemand in den falschen Hals bekommen hat. Ich wollte nur äußerst "dezent" darauf hinweisen, dass wir vom Thema abweichen, denn um "Einzüge" geht es dem TE ja nicht.

[jobo]

Zitat:

Zitat von mm1256 (Beitrag 1325520)

Sorry, wenn's jemand in den falschen Hals bekommen hat. Ich wollte nur äußerst "dezent" darauf hinweisen, dass wir vom Thema abweichen, denn um "Einzüge" geht es dem TE ja nicht.

Richtig, es geht um "Auszüge". Davon wurde hier auch geschrieben oder?
Ein Kontoauszug selbst kann Einträge Einzügen (DirectDebit) und vielen anderen Formen von Zahlungsverkehr enthalten, also eigentlich zu allen Formen von Zahlungsverkehr, hoffe ich.

[mm1256]

Zitat:

Zitat von jobo (Beitrag 1325543)

Ein Kontoauszug selbst kann Einträge Einzügen (DirectDebit) und vielen anderen Formen von Zahlungsverkehr enthalten, also eigentlich zu allen Formen von Zahlungsverkehr, hoffe ich.

Absolut richtig, ein Auszug kann all das beinhalten, aber das interessiert in diesem Fall doch wirklich niemand. Abgesehen davon, was kennzeichnet einen Einzug - richtig, ein negativer Betrag. So einen Eintrag muss ich also gar nicht parsen, denn...

Zitat:

Zitat von TE #1

Die Software enthält offene Rechnungen und es soll automatisch erkannt werden, welche Rechnungen bezahlt wurden.

[Sir Rufo]

Anscheinend können immer nur die Anderen so einen Einzug machen :stupid:
(Was erscheint bei denen wohl auf dem Konto? Auch ein negativer Betrag?)

[mm1256]

Nur dass es hier nicht um die Anderen geht, sondern um die SW des TE. Darum halte ich mich jetzt wohl lieber raus, denn anscheinend geht es nicht mehr um das Anliegen des TE sondern um das Auswerten von Kontoauszügen allgemein.

[Dejan Vu]

Menno Kinners,

Endlich mal ein Thread, in dem verdammt viel Know-How präsentiert wird und dann verabschieden sich die Helden dieses Threads, weil sie (a) beleidigt sind oder (b) unter akuter Selbstzensur leiden.

Knuffig, irgendwie.

PS: Beides ist heilbar und eh hypochondrisch.

[jobo]

Zitat:

Zitat von mm1256 (Beitrag 1325554)

Nur dass es hier nicht um die Anderen geht, sondern um die SW des TE. Darum halte ich mich jetzt wohl lieber raus, denn anscheinend geht es nicht mehr um das Anliegen des TE sondern um das Auswerten von Kontoauszügen allgemein.

Also dass es zunächst allgemein um die Auswertung von Kontoauszügen geht, steht ja im ersten Beitrag des TE. Dass dabei offenbar nur bestimmte Zahlungsformen von Bedeutung sind, kann man ebenfalls folgern. Dass es um die Software in der Signatur des TO geht, wäre möglich, allerdings schon etwas zu empathisch nach meinem Geschmack. Dass es nicht um Einzüge geht, ist sehr wahrscheinlich, in den Schilderungen aber ja auch nur ein Teilaspekt.
Wenn also einige Teilnehmer hier ihre (Gesamt)Verfahren darstellen, ist das doch durchaus angemessen. Meine Erfahrung ist, dass man bei einer hohen automatischen Zuordnungsquote schon eher Richtung fuzzy unterwegs ist. Die Leute zeigen durchaus Fantasie bei der Problematik der Geldtransfers (die Rechnungsempfänger). Spätestens seit SEPA ist auch die Abbildung der Zahlungsinformationen etwas in diesen Bereich gerückt (Fantasie), je nach ausführender Bank. Das geht soweit, dass die Banken sich bei unerklärlichen Kontoauszugsdaten auf das Bankgeheimnis berufen. Wir haben z.B. für Januar die Signale auf orange, weil eine Bank eines Kunden intern ihre aktualisierten SEPA Schnittstellen scharf schaltet.
Ich glaub nicht, dass es an der Ecke schadet, mal (versehentlich) über den Tellerrand zu schauen.

Letztlich hat der TO sich selbst noch nicht weiter geäußert und die vorhandenen Infos sind spärlich. Kein Grund sich rauszuhalten.

[jobo]

Zitat:

Zitat von Dejan Vu (Beitrag 1325555)

Endlich mal ein Thread, in dem verdammt viel Know-How präsentiert wird

Kann es sein, dass Du stark untertreibst? :)
Hier wird täglich eine Menge Know How präsentiert.
Kann natürlich sein, dass es Dir nicht so auffällt, weil es für Dich alles Kinderkram ist. ;)

[Dejan Vu]

Sagen wir: "Endlich ein Thread, der mich interessiert".

[jobo]

Ja, ich finde es auch spannend, wie andere mit Ihren Geldproblemen umgehen. :)

[Mavarik]

Zitat:

Zitat von Dejan Vu (Beitrag 1325571)

Sagen wir: "Endlich ein Thread, der mich interessiert".

Tja.. Dachte auch... Mal weg von dem üblich Windows,XE10 xy funktioniert nicht.

Zitat:

Zitat von jobo (Beitrag 1325567)

Letztlich hat der TO sich selbst noch nicht weiter geäußert und die vorhandenen Infos sind spärlich. Kein Grund sich rauszuhalten.

Ja aber die Threadpolizei hat wieder zu geschlagen. Warum glauben eigentlich einige User, Sie müssten die Fragen des TO's immer leiten oder andere User informieren, dass der TO etwas anderes gemeint hat. Glauben einige der TO kann plötzlich nicht mehr Antworten?

[jobo]

Zitat:

Zitat von Mavarik (Beitrag 1325597)

Zitat:

Zitat von jobo (Beitrag 1325567)

Letztlich hat der TO sich selbst noch nicht weiter geäußert und die vorhandenen Infos sind spärlich. Kein Grund sich rauszuhalten.

Ja aber die Threadpolizei hat wieder zu geschlagen. Warum glauben eigentlich einige User, Sie müssten die Fragen des TO's immer leiten oder andere User informieren, dass der TO etwas anderes gemeint hat. Glauben einige der TO kann plötzlich nicht mehr Antworten?

Warum? Weil das zu einem Forum dazu gehört? Ist ja nicht selten, dass gerade ein Anfänger sich unglücklich oder mehrdeutig ausdrückt. Irgendwer hat dann vielleicht den richtigen Riecher und postet es und alle sind glücklich. Oder er hat den falschen Riecher und alle machen sich deshalb unglücklich. An der Stelle sind wir wohl gerade- unglücklich- obwohl noch nicht mal klar ist, welche von den vielen Vermutungen und daraus folgenden Tipps richtig ist.

Also ich find das kein Drama. Hier werden zwar gelegentlich Posts wegen Speicherplatzverschwendung gelöscht, aber das ist ja wohl eher eine formale Begründung.

Wenn es alles streng analytisch ablaufen würde, wärs doch irgendwie öde, find ich. Jeder schießt mal übers Ziel hinaus oder läuft unter der Stange durch, ich z.B., also einfach mal zurücklehnen, das Jahr wird schon bald vorüber sein. :)