Sie sind aktuell nicht angemeldet.

Funktionen: Einloggen  |  Neu registrieren  |  Suchen

Meine Erfahrungen mit SQL-Express 2005 und ADO.NET - Projekt eigenes DATEV-Tool
Autor: BernyH
Datum: 25.09.08 18:24
Hallo Gemeinde, Da wir in unserer Firma DATEV (inhouse, Rechnungswesen) nutzen, stand ich vor der Aufgabe, ein Programm zu schreiben, das die mangelhafte Suchfunktionen der DATEV-Lösung ersetzen konnte. Das Kontieren ist lästig, sogar, wenn man den Kontenplan neben sich liegen hat, bzw. den Ordner mit den Buchungen der letzten Monate, um zu schauen, wie das denn bisher gehandhabt wurde... Wenn man das nur vertretungsweise macht, wird es noch schlimmer. Wie sehr man sich vorab Gedanken über ein sinnvolles Datenbankdesign machen sollte, darüber möchte ich hier berichten: DATEV-Rechnungswesen besitzt die Möglichkeit Daten z.B. nach dem GDPdU-Standard zu exportieren. Diese Dateien sind ordentlich dokumentiert. Sie sind simple Textdateien, csv-like, jeder Buchungssatz in einer Zeile, getrennt mit Semikolon, die Werte in chr(34) eingefasst. Datenbank erstellt: Eine Table mit dem Kontenplan, eine Table mit den Buchungssätzen. Da wir mehrere Firmen buchen und natürlich auch mehrere Wirtschaftsjahre als Datenbestand vorhanden sind, habe ich alle Daten über eine eigene Routine aufbereitet und in die Tables importiert. Reines split(";") funktioniert nicht, weil in den Buchungstexten jeder Buchung z.B auch ein Semikolon drin sein kann, also muss das erst bereinigt werden. Und jetzt kommt's: 4 Jahre x 2 Firmen machen etwa 1,2 Millionen Buchungszeilen!!! Man glaubt es kaum, was man da so im Laufe des Jahres in den PC hämmert... Das von mir entwickelte Tool sollte ad hoc, über mehrere Suchfelder Konten, Datensätze, Kostenstellen usw. eingrenzen können. *****Und zwar aktualisiert nach [u]jedem eingegebenen Zeichen. So soll z.B eine Kontenliste des Jahres angezeigt werden, und darunter die bebuchten Konten. Daneben dann die jeweiligen Buchungen für das Konto und das Gegenkonto. Gefiltert u.U. nach datum Buchungstext, Kostenstelle oder Belegnummer, jeweils (INSTR). Da macht das Kontieren richtig Spass, weil nun nur noch ein Teil des Lieferanten eingegeben werden muss, wie "t-" für die "Deutsche -T----", "T-Systems" oder eben auch "Schalt-Ede"... Schon sieht man nur noch die passenden Lieferanten, darunter die bisher bebuchten Konten (wo natürlich auch das Konto für die Telefonkosten drin ist), und die bisherigen Buchungssätze, ihre Textung und den Buchungsschlüssel, der ja nur bei NICHT-Automatikkonten zu kontieren ist. (OK, das sind Infos für Buchhalter....) Die Kontenliste war immer fix da, aber eine Abfrage wie: "SELECT DISTINCT konto, funktion, saldo, text FROM tblKontenplan WHERE (berater=@berater) and (firma=@firma) and (jahr=@jahr) and (konto=@konto) and (...dynamische Stringvergleiche, auch mit z.B. Ä=Ae, Ö=oe usw.) ORDER BY konto", dann noch die Abfrage für die Buchungsliste mit Kostenstelleneingrenzung, Datumsintervall usw. - war unerträglich langsam auf dem Schirm. Alles mit ado.net, datatables und datagridview. Kurzer Code (.fill), keine Schleifen o.ä. Nun, die ***** ein paar Zeilen weiter oben sind das (stehende) Rädchen in der Uhr, was schlussendlich dazu führte, nochmal über die Datenbank nachzudenken. Ich habe dann die folgende Lösung gefunden: Für jeden Mandanten, jede Firma, jedes Jahr werden 2 eigenständige Tables erstellt, die dann auch abgefragt werden. die Tables sind dann aufgebaut nach dem Schema tbl_Typ_beraternummer_mandantennummer_wirtschaftsjahr so z.B. tbl_KP_0123456_12345_2008 für den Kontenplan der Firma 12345 des Jahres 2008 und tbl_BP_0123456_12345_2008 für das passende Buchungsprotokoll. Da Mandant, Firma und Jahr über ComboBoxen eingestellt, bzw. bei Programmstart initialisiert werden, läßt sich der table-String einfach über eine Funktion erzeugen. Die SQL-Abfragen sind dann sehr viel kürzer und vor allem ist der Datenbestand der Tabellen sehr viel kleiner. Ich habe jetzt maximal 150.000 Buchungszeilen in einer Tabelle. Die kann ich nun nach Belieben in kürzester Zeit durchsuchen. Kurz vor Feierabend exportiere ich die Daten des aktuellen WJ auf den Server, wo dann ein Cron-Job des Nachts die Daten in die DB einfügt. So bin ich immer auf dem Stand von Gestern. Mit jedem Tastendruck in einem Suchfeld habe ich nun "ad hoc" das Ergebnis auf dem Schirm - und so wollte ich das auch haben. Gru? BernyH

Meine Erfahrungen mit SQL-Express 2005 und ADO.NET - Projekt...	1.706	BernyH	25.09.08 18:24
Re: Meine Erfahrungen mit SQL-Express 2005 und ADO.NET - Pro...	1.169	FZelle	26.09.08 12:10
Re: Meine Erfahrungen mit SQL-Express 2005 und ADO.NET - Pro...	1.068	BernyH	26.09.08 13:46

Sie sind nicht angemeldet! Um auf diesen Beitrag zu antworten oder neue Beiträge schreiben zu können, müssen Sie sich zunächst anmelden. Einloggen  |  Neu registrieren

Funktionen:  Zum Thema  |  Gesamtübersicht

Suchen