Hallo zusammen Ich betreibe zur Zeit en kleines Business und möchte meine Rechnungen einfach verwalten können. Da ich bisher keine Software Lösung gefunden habe, die meinen Anforderungen entspricht, habe ich mich kurzerhand dazu entschieden selbst ein tool zu programmieren. Ich habe einige Jahre Erfahrung als applikations Entwickler. Der eigentliche Code sollte also kein Problem werden. Ein Freund hat sich bereit erklärt mich im Thema Grafiken zu unterstützen. Das ganze soll auf meinen Kundenstamm zugreifen können, dieser wird in einer SQL basierten Datenbank angelegt. Der Kundenstamm enthält die nötigen Informationen über die Kunden: Name, Adresse, Krankenkasse, Status... ausserdem wird für jeden Kunden eine DB angelegt um seine Rechnungen zu verwalten. Das Programm verfügt in diesem Jungen Stadion über die folgenden Reiter: [Übersicht] Enthält wie die meisten Programme eine art Schnellzugriff Seite für die wichtigsten Funktionen. Sowie notwändige Infos, ob die Datenbank am funktioniert wie sie sollte. Anzahl Kunden, Anzahl offene Rechnungen, Anzahl Vorlagen Updates Letztes Backup ... [Neue Rechnung] Hier kann eine neue Rechnung erstellt werden. Diese basiert auf einer vorher erstellten Vorlage. Es kann gewählt werden ob eine Zahlscheinnummer erstellt werden soll. (vorerst nur für Schweiz) [Alle Rechnungen] Eine Übersicht der Rechnungen als Tabelle. (die Tabelle wird nach Rechnungen geordnet) In der der Tabelle kann man z.B. nach einem Kunden filtern um dessen Rechnungs Profil einzusehen. [Vorlagen] Vorlagen Verwaltung. Die Vorlagen werden mit einem Designer erstellt. Alte Vorlagen können angepasst oder gelöscht werden. Eine Vorlage kann als default ausgewählt werden. [Kunden] Kunden Verwaltung Es können neue Kunden erstellt werden. Bestehende Kunden angepasst werden, bestehende Kunden angezeigt werden. [Datensicherung] Sichert die Daten auf einen angegebenen Datenträger. Oder ruft eine bestehende Sicherung ab. [Über fakturaPro] über eben Lizenzfile Verwaltung [Einstellungen] Pfade und Datenbank settings, preferences. Habt ihr noch Einwände, Verbesserungsvorschläge oder Ähnliches für mein Projekt? --- Fehlerhafte Wiki-Links [[ ersetzt durch [ -rufus
Angehängte Dateien:
-
fakturaPro.png
83 KB
:
Bearbeitet durch User
Hallo Lisa, mein Vorschlag noch: OP-Verwaltung (offene Posten) mit Mahnwesen. Welche Programmiersprache wird benutzt? Viel Spaß bei der Umsetzung. Gruß Kurt
:
Bearbeitet durch User
Die Hauptarbeit wird wohl der Menüpunkt neue Rechnung sein. Was für Produkte Dienstleistungen können in Rechnung gestellt werden. Produktdatenbank, Bestandsverwaltung? Schnittstelle zur Buchhaltung? Schnittstelle zur Bank um Zahlungseingänge mit den Rechnungen abzugleichen ...
Lieferscheine, Angebote, Mahnungen, Lagerwesen, Benutzer- und Rechtesystem, Gdpdu...
Hallo Kurt Vielen Dank für deinen Vorschlag. Ich programmiere mit Delphi. Das mit dem Mahnwesen hatte ich mir unter alle Rechnungen gedacht. Dort soll für die jeweiligen Kunden angezeigt werden ob sie noch offene Rechnungen haben, bereits über dem Datum sind etc. Dank dir kommt mir aber gleich die Idee, dass ich eine Option einbauen könnte um eine Vorlage für Mahnungen einzubinden. Ist dann ein Kunde über der Zahlfrist wird automatisch eine Mahnung erzeugt, wenn man auf drucken klickt. Schönen Abend allerseits
Der Andere schrieb: > Die Hauptarbeit wird wohl der Menüpunkt neue Rechnung sein. Da hast du absolut recht. Der Ersteller soll seine Tabelle in der Rechnung selber populieren können. Also angeben, wie viele Spalten/Zeilen er hat und was die jeweiligen Spaltentitel sind. Aus den einzelnen Positionen wird dann automatisch der gesamtbetrag errechnet. In einer zukünftigen Version soll ein Webfrontend hinzukommen. Das ist aber noch wilde spekulation. Der Andere schrieb: > Schnittstelle zur Bank um Zahlungseingänge mit den Rechnungen > abzugleichen Wäre schön aber wohl eine Utopie, kommt ja ganz auf die APIs der jeweiligen Banken an.
Lisa A. schrieb: > Der Andere schrieb: >> Die Hauptarbeit wird wohl der Menüpunkt neue Rechnung sein. > > Da hast du absolut recht. Der Ersteller soll seine Tabelle in der > Rechnung selber populieren können. Also angeben, wie viele > Spalten/Zeilen er hat und was die jeweiligen Spaltentitel sind. Aus den > einzelnen Positionen wird dann automatisch der gesamtbetrag errechnet. Wenn du für deine Zwecke fest vorgibst, was du an Spalten brauchst, ist der Aufwand relativ gering. Wenn du aber sowas wie einen Spalteneditor u.ä. einbauen willst... glaub mir, das sprengt den Rahmen. (für spalte 1-N brauchst du dann jeweils Infos wie: Datentyp, Datengröße, DB-Tabellen+Spaltennahme, Einfluß auf Rechnung (sind das Anzahlen, Preise, Rabatte , (automatisch gebildete) Gesamtpreise, EAN-Codes oder simpler Text wie Produktbezeichnung. etc), Druckbreite, formatierung, soll auf Rechnungen gedruckt werden:(Ja/nein) (damit man den EK eines Produktes nicht auf der Kundenrechnung wiederfindet ;)),..). Du siehst, das führt schnell zu größeren Konfigurationsorgien als man glaubt. > > In einer zukünftigen Version soll ein Webfrontend hinzukommen. Das ist > aber noch wilde spekulation. Vielleicht wäre es dann klüger, statt in Delphi gleich in PHP mit einem Apache+mysql im Hintergrund zu Coden? Der Andere schrieb: > Schnittstelle zur Buchhaltung? Wenn du dich auf einen bestimmten Kontenrahmen festlegst und für Kunden etc einfach Debitoren- / Kreditorenkonten festlegst, kannst du die Buchhaltungsschnittstelle auch recht einfach implementieren, da der Export und Import der Buchhaltungsdaten dann lediglich Rechnungsbeträge und Datumsangaben sind. Okay + Steuersplittungen und anderen kleinkram ;) > Der Andere schrieb: >> Schnittstelle zur Bank um Zahlungseingänge mit den Rechnungen >> abzugleichen > > Wäre schön aber wohl eine Utopie, kommt ja ganz auf die APIs der > jeweiligen Banken an. Nein, im Zuge der SEPA-Einführung gabs ein neues Austauschformat auf XML-Basis. Das wird heute auch schon in einigen nicht-SEPA-Ländern genutzt. Aber Achtung: die XSL-Beschreibungen heißen nicht umsonst PAIN ;) Allerdings hat jede Bank seinen eigenen Weg, diese XML-Daten entgegen zunehmen (z.B. "Bankingsoftware"). Lisa A. schrieb: > Der Kundenstamm enthält die nötigen Informationen über die Kunden: Name, > Adresse, Krankenkasse, Status... ausserdem wird für jeden Kunden eine DB > angelegt um seine Rechnungen zu verwalten. Du brauchst die Krankenkasse deiner Kunden zur Info? Oder sind deine Kunden eher Patienten.. Weiterhin: für jeden Kunden eine eigene Datenbank? Oder meintest du Mandant im Sinne von 1 Kunde = 1 Firma mit verschiedenen Kunden, Lieferanten, Produkten, Rechnungen..; ein weiterer Mandant = eine weitere Firma mit ... also ähnlich einem Steuerberater, der verschiedene Mandanten betreut) Falls nicht, würde ich für pro Kunde keine extra DB machen, nicht mal eine einzelne Tabelle je Kunde sondern lediglich eine einzige große Tabelle KUNDEN, in der jeder Kunde nur ein Datensatz ist (halt der uralte klassische Ansatz mit den 4 Grundtabellen KUNDEN, ARTIKEL, VORGÄNGE, POSITIONEN). Lisa A. schrieb: > über eben > Lizenzfile Verwaltung Willst du diese Faktura dann kommerziell anbieten? Dann wirst du verschiedene Abnehmer haben mit verschiedenen Ansprüchen und diese wirst du als Einzelkämpfer alleine nicht produktiv in eine Software gießen können (zu großes Arbeitspensum für rechtzeitiges Einhalten von Fristen durch Änderungen in Gesetzen. Selbst die ganz Großen der Branche patzen hier regelmäßig!). Und es gibt Dutzende solcher Anbieter im deutschsprachigem Raum, die alle bis zu 4stellige Beträge verlangen und selbst bei diesen Beträgen noch gröbste Schnitzer in der Software haben, die auch nach Jahren(!) der Bemängelung nicht ausgebügelt wurden. KHK, AFS, Lexware... alles solche Nieten. Teilweise kriegen die einfachste Sachen wie "Gesamtpreis aus Positionen bilden" nicht gebacken, weil sie als Datenformat DOUBLE nehmen usw. Kurt P. schrieb: > OP-Verwaltung (offene Posten) mit Mahnwesen. Wenn du dich clever anstellst, ist das Mahnwesen lediglich eine umgebaute Rechnungserstellung mit anderem (einfacheren) Formular. Dazu muß allerdings ein OP-Liste (=Zahleingänge erfassen) funktionieren. Lisa A. schrieb: > [Datensicherung] > Sichert die Daten auf einen angegebenen Datenträger. > Oder ruft eine bestehende Sicherung ab. Das ist eine typische Funktion erdacht von BWL-Studenten, die so tun, als seien sie Programmierer. Du kannst so eine Funktion zwar einbauen, aber in der Regel werden diese System eh komplett bzw. extern gesichert. (oder auch gar nicht ;)). Du stehst irgendwann vor dem Punkt daß eine Datensicherung aufgrund von vielen Änderungen in der Programmentwicklung (deine Fragen zeigen, daß du noch keine Faktura programmiert hast) im Laufe der kommenden Jahre deine Datensicherungen auf späteren Programmversionen nicht mehr einlesbar sind, weil die Datenstuktur sich gewandelt hat. Es macht mehr Sinn, wenn du entweder a) dein komplettes Programm+DB sichern kannst oder du b) für externe Sicherungssysteme einfach beschreiben kannst, welche Dat(ei)en als zusammengehörend gesichert werden müssen. Und ein letzter Tip: Kunden, Lieferanten, Behörden, Finanzämter, Banken, Versender, Druckformulare, Webshopsysteme, ... für alles solltest du Datenschnittstellen haben oder zumindest später einbauen können
Wow, das ist ein ausführlicher Beitrag. Danke schön für den Input! Andy P. schrieb: > Wenn du für deine Zwecke fest vorgibst, was du an Spalten brauchst, ist > der Aufwand relativ gering. Nun ich hätte mir das so gedacht, dass es eine Beschränkte Anzahlt Spalten mindestens 2 (position und preis), diese beiden sind vorgegeben hat. Dazwischen kann man dann, sagen wir max 4 Text Spalten, einfügen wo man Beschreibung etc. angibt. Andy P. schrieb: > Vielleicht wäre es dann klüger, statt in Delphi gleich in PHP mit einem > Apache+mysql im Hintergrund zu Coden? Und eine browser basierte Lösung zu haben? Ich weiss nicht. Ich möchte das Programm wie du unten erwähnst gerne so gestalten, dass es auch für andere brauchbar ist. Möglicherweise sogar um einen Gewinn daraus zu schlagen. Wäre natürlich toll, man muss ja von irgendwas leben ;). Daher auch die Krankenkasse, ich sehe grosses Abnemer Potenzial in kleinen Praxen. Um es kundentauglicher zu machen denke ich ist eine Desktopanwendung geeigneter. Sonst läuft man wieder in Probleme wie Internet Explorer und Leute, die das Programm an einem 10 Jahre alten PC im Keller betreiben wollen und nur den Netscape Navigator installiert haben. Ob beim Kundennamen eine Firma steht oder ein Einzelkunde sollte nicht relevant sein. Ich würde jetzt eine Tabelle Kunden anlegen und eine Tabelle Rechnungen. Den Kunden wird jeweils eine eindeutige Kundennummer zugewiesen, welche in der Tabelle Rechnungen bei den entsprechenden Rechnungen eingetragen wird. Vorgänge ist eine Gute Idee. Die Artikel weiss ich nicht ob das nicht schon fast zu dynamisch ist und nicht einfach dem Benutzer als offenes Textfeld überlassen werden soll. Andy P. schrieb: > Das ist eine typische Funktion erdacht von BWL-Studenten, die so tun, > als seien sie Programmierer. Du kannst so eine Funktion zwar einbauen, > aber in der Regel werden diese System eh komplett bzw. extern gesichert. Ich sehe worauf du hinaus willst. Aber das Problem der ändernden Datenstruktur lässt sich durch weglassen der Datensicherung nicht lösen. Hat man hingegen eine eingebaut, kann man bei entsprechenden Updates die jeweiligen Spalten so Importieren, dass es weiterhin funktioniert. Den Ansatz für Datensicherung von Apple iOS finde ich hierfür sehr interessant. Möglicherweise könnte eine Art "Time Machine" eingebaut werden. Andy P. schrieb: > Und ein letzter Tip: Kunden, Lieferanten, Behörden, Finanzämter, Banken, > Versender, Druckformulare, Webshopsysteme, ... für alles solltest du > Datenschnittstellen haben oder zumindest später einbauen können Das klingt zwar gut, aber irgendwo muss man eine Grenze setzen. Einbauen ja. Schlussendlich soll man mit dem Programm ja Rechnungen verwalten können, der Benutzer soll ruhig auch noch etwas selber machen müssen. ;) Der Beitrag war echt hilfreich. Werde ihn mir zu Herzen nehmen und versuchen zu verarbeiten.
Lisa A. schrieb: > Ich betreibe zur Zeit en kleines Business und möchte meine Rechnungen > einfach verwalten können. Nachdem ich allen obigen Beiträgen gelesen habe und gesehen was du vorhast, befürchte ich, dass dir für die Verwaltung deiner Rechnungen keine Zeit mehr übrig bleiben wird...
Torsten R. schrieb: > - OS/X Version :-) Das wollte ich auch einwerfen. Schade, dass die Welt für viele nur aus Windows zu bestehen scheint. Dabei kostet plattformunabhängige Programmierung nur wenig Extra-Mühe ...
Noch ein rechtlicher/struktureller Hinweis: Während man in Datenbank-basierten Anwendungen allgemein möglichst viel mit Relationen arbeitet und damit quasi dynamische Dokumente erst beim Abruf erzeugt, ist es bei Rechnungen dringend erforderlich, die Daten tatsächlich hart zu kopieren. Sonst ändern sich z.B. in alten Rechnungen die Anschriften, wenn man die entsprechenden Stammdaten mal korrigiert, weil der Kunde z.B. umgezogen ist. Oder es ändern sich rückwirkend die Preise ... Alternativ dazu führt man Datumsinformationen zur Gültigkeit der Daten (von ... bis) mit (und berücksichtig diese), was aber ungleich aufwändiger ist ...
:
Bearbeitet durch User
Ich weiß, dass hier was neues entstehen soll, aber ich habe z.B. das hier https://www.open3a.de/ und darauf aufgebaut und Funktionen hinzugefügt und abgeändert was nicht gefallen hat. Läuft erste Sahne und wird über den Browser bedient. Installation ist sehr einfach, vllt. einfach mal reinschauen und Abgucken wie es andere machen. Kostet auch nichts.
Lisa A. schrieb: > Dazwischen kann man dann, sagen wir max 4 Text Spalten, einfügen wo > man Beschreibung etc. angibt. Das schränkt natürlich den Aufwand schon deutlich ein. Wenn das deinen Kunden reicht... (Ich verspreche dir: es reicht nicht ;)). Frank E. schrieb: > Sonst ändern sich z.B. in alten Rechnungen die Anschriften, wenn man die > entsprechenden Stammdaten mal korrigiert, weil der Kunde z.B. umgezogen > ist. Oder es ändern sich rückwirkend die Preise ... Kein Problem, dann erklärst du halt dieses "Adressaktualisierungsfeature" zum Userproblem, in dem du sagst: "Das Rechnungjournal dient nicht als Rechnungsarchiv" (O-Ton des Supports einer der einschlägigen Software-Anbieter. Die haben das tatsächlich so implementiert! Die wissen(!), daß das grob fahrlässig ist, sind aber eifrig mit Anwaltsschreiben, wenn du solche Fehler öffentlich mit denen in Verbindung bringst.). Oder noch schlimmer: man erstellt zwar in der Tabelle POSITIONEN ordentliche Kopien der eingetragenen Artikel, liefert aber an alle (!) Kunden als Standard-Formular einen Positionsdruck, der auf die Artikeltabelle zurückgreift. Kleiner Lichtblick: vor einigen Jahren wurde dort wenigstens für das Standard-Formular hinterlegt, daß er wenigstens die Preise aus der Positionstabelle nimmt und nicht den aktuellen Artikelpreis. Ausrede: "Das Standard-Vorgangsformular muß eh vom Mandanten eingerichtet werden". Lisa A. schrieb: > Sonst läuft man wieder in Probleme wie Internet Explorer und > Leute, die das Programm an einem 10 Jahre alten PC im Keller betreiben > wollen und nur den Netscape Navigator installiert haben. Du wirst Lachen: Wir basteln für uns gerade an einer Inventurlösung, die vollständig und offline (inkl Daten) auf einem Android läuft (inkl EANCodescanner). Da wir zur Verfolgung von Artikeln mit Seriennummer hierbei ordentliche Ausbuchungen ähnlich einer Rechnung brauchen, ist das quasi eine vollständige Faktura mit lediglich max 10 "Kundenadressen"= Kostenstellen. Lisa A. schrieb: > Die Artikel weiss ich nicht ob das nicht > schon fast zu dynamisch ist und nicht einfach dem Benutzer als offenes > Textfeld überlassen werden soll. Klar ist das sinnvoll: wenn ein Arzt bei jeden dritten Patienten "1 min Rückenkratzen" zu je 5 Franken und bei jeden 10. Patienten "30 sek. Bauchkitzeln mit Lachgarantie" "verkauft", dann wird das wohl entsprechend oft eingetippt werden. Das ist nichts unheimlich kompliziertes: Letzlich arbeiten eigentlich alle Warenwirtschaften nach diesem Prinzip. So kannst du die über alle Vorgänge einheitliche Struktur in Datenzeile je vorgang abbilden und somit viele vorgänge strukturiert verwalten. (= Rechnungsliste) und die dazu nicht passende Struktur der Einzelpositionen mit Einzelpreis, anzahl, Rabatt etc. in eine zweite Tabelle POSITIONEN mit Referenz auf VORGÄNGE stapeln. Lisa A. schrieb: > der Benutzer soll ruhig auch noch etwas selber machen müssen. ;) https://www.youtube.com/watch?v=3LkQrtCIFA4 (okay., dürfte inzw. 15-20 Jahre alt sein!) Keine Angst-die Mehrheit aller Firmen (auch derer, die hauptsächlich via Internet handeln) ist noch nicht soweit, wie ich immer wieder feststellen muß.
Ich setze CAO Faktura ein (Freeware oder Kaufversion mit mehr Features) und bin sehr glücklich damit. Leider eine MySQL 4 Datenbank dahinter :-(
Torsten R. schrieb: > - OS/X Version :-) Wäre klar wünschenswert. Da muss ich mir noch Gedanken dazu machen, wie das mit dem Rechnungs Designer in Einklang gebracht werden soll. Frank E. schrieb: > Sonst ändern sich z.B. in alten Rechnungen die Anschriften Guter Punkt. Die vorgeschlagenen Softwaren werde ich mir mal anschauen um mir ein Bild darüber machen zu können. Ich muss wohl mal eine Projekt Struktur erstellen um all die Vorschläge und Ideen zu bündeln. Melde mich wieder.
Ich bin auch Gewerbetreibender, und hatte so eine "alles selber machen"-Phase in der ich mein eigenes Tool zur Auftragsverwaltung programmiert habe. Irgendwann hat sich bei mir aber die Erkenntnis durchgesetzt, dass es durchaus von Vorteil sein kann, sich mit den (oft nur vermeintlichen) Unzulänglichkeiten existierender Lösungen anzufreunden, und dazu wenn nötig auch die eigenen, gewohnten Prozesse zu ändern. Jetzt verwende ich Lexoffice und bin sehr zufrieden einen Zeitfresser weniger in meinem Leben zu haben.
Hallo Lisa, solltest du es in absehbarer Zeit schaffen etwas im Umfang von LexWare Financial Office Pro zu schaffen aber ohne die Bugs, Unzulänglichkeiten und schlechter Support von Lexware wäre ich durchaus interessiert. - Projektverwaltung - Einkauf/Verkauf mit Unterstützung der Kontenpläne SKR04/SKR03 - Buchhaltung mit Exportmöglichkeit für Steuerberater. (mindestens CSV, Datev?) - Anlagenverwaltung (Betriebsvermögen mit Abschreibungen etc) - Reisekosten (hier ist LexWare völlig verbockt) - Lohn/Gehalt (wäre nett, muss aber nicht sofort sein) So etwas wie Collmex wäre auch ganz nett, aber sie bieten es nur als Cloud Lösung an. Kosten dürfte es ca. 1K/Jahr, wenn es besser als LW ist. Viel Erfolg,
@Andreas Jedem das seine. Mir macht es spass selbst Dinge zu Basteln und entwickeln. Ob dies wirklich nur eine DIY Phase ist oder sich ändern wird steht in den Sternen. Aber ich hatte davon schon einige erfolgreiche Projekte und Freude daran. Ohne die Bastler und Macher würde dieses Forum ja gar nicht erst existieren. Hallo Charles Es motiviert mich zu sehen, dass das Program auch für andere interessant sein könnte. Sobald ich damit auf einem handfesten Stand bin, werde ich mich bei dir melden. Wir können auch gerne mal genauer darüber sprechen was für Funktionen fehlen/schön wären. Gruss
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.