Rechnungen über Excel - Datenbank, Software - Ideensammlung

Guten Morgen.

Und warum nichts kostenloses nutzen und dann ausbauen?

http://www.cao-faktura.de/

ist kostenlos, einfach zu bedienen und erleichert bestimmt die arbeit.

Hallo,

dann mach folgendes:

Lege Dir eine Exceltabelle mit mehreren Tabellenblättern an. Jeweils ein Blatt für Kunden, Artikel und Textbausteine.

Eine weitere Tabelle legst Du als Vorlage für Deine Rechnungen, Angebote, Lieferscheine,.... an. Darin wird mit SVERWEIS auf die andere Tabelle referenziert.
Dann musst Du nur noch Kundennummer, Artikelnumer und gegebenenfalls die Textbausteinnummer eingeben und alles ist ausgefüllt.

Für diese Lösung brauchst Du keinerlei Datenbank bzw. Programmierkenntnisse. Lediglich die SVERWEIS-Funktion in Excel.

Solltest Du Hilfe benötigen, melde Dich bei mir (Kontaktdaten auf meiner Homepage - siehe Profil).
Ich sende Dir dann gerne eine Beispieldatei zu. Ich habe das vor CAO-Faktura genau so gemacht.


Gruß
Andi

Moin,

wir haben uns vor Jahren selber was auf Basis von Access und Excel erstellt.

Vorher hatten wir das mit Excel gemacht und Angebote kopiert.
Das ist aber einer bestimmten Menge doch mühsam und fehleranfällig.
Aber wir wollten nicht die flexibilität verlieren, schnell mal was anzubieten ohne es einpflegen zu müssen.

Es gibt also eine Exceldatei als Formular, die Stammdaten und die einzelnen Waren kann man über ein Makro aus der Accessdatenbank hinzufügen.
Man kann es aber auch selber schnell eintippen.

Beim speichern werden bestimmte Daten in die Datenbank übertragen.

Funktioniert prima in seinen Grenzen.

Stefan

Moin Moin,

so wie ich das sehe: EDV zu Fuß
Mal als Anregung: Ein Angbot kann doch kopiert werden und der Kopf in Rechnung geändert werden. Das dürfte schneller gehen als alles neu einzutippen.

Grundsätzlich gibt es viele gute fertige Programme die sich leicht an deine Bedürnisse anpassen lassen. Sehr viele haben auch gleich eine Schnittstelle zur Buchhaltung.
Gerade für Handwerker gibt es Software wie Sand am Meer. Bei jeder Umstellung werden sich die Mitarbeiter umgewöhnen müssen, das ist normal.

Teste mit deinen Mitarbeitern diverse Lösungen und einigt Euch auf ein Programm, dass für Euch am besten passt. Testversionen gibt es eigentlich immer.
Selber Programmieren kostet Zeit (ungeübt bis zu zwei Jahre) und somit sehr viel Geld. Da ist der Umstieg auf eine fertige Lösung die günstigste und schnellste Lösung.

Suche mal nach Faktura und/oder nach WAWI. Ein paar € sollte dir so ein Programm Wert sein, wenn im Netzwerk mehrere Personen damit arbeiten sollen.

Empfehlungen:
http://www.lexware.de/shop/productDetails?orderNo=A08871
http://www.amicron.org/

Grüße aus Rostock
Wolfgang
(Netwolf)

Hallo mbrkmann!

Also, der Meinung von SteffanKittel schließe ich mich an. Wenn schon über Excel, dann etwas Vernünfiges per VBA-Code mit UserForms und Datenbank. Die Frage ist nur, wer den VBA-Code schreibt und pflegt?

Das sollte eigentlich mit jeder Datenbank-Anbindung möglich sein, wobei sich meine Datenbankkenntnisse allerdings auf Access beschränken.

@ AndiW
Sorry, aber Deinen letzten Vorschlag finde ich geradezu anspruchslos und lächerlich

Gruß Dieter

Tag

Siehe hier:
http://www.greencube.ch/#footer&TT&Elements&TT&Footer&a ...;

Bei mehreren Kunden im Einsatz (vor allem auch bei Handwerkern und Garagen), bietet Adressverwaltung, Debitoren & Kreditorenverwaltung, Lagerverwaltung, FiBu, Fakturierung, Lohnverwaltung für 10 Mitarbeiter, etc. etc. Mehr brauchst du nicht. Die Software ist gratis, übersichtlich gegliedert und basiert auf MS SQL-Server 2008 Express Edition. Beim Backup musst du beachten, dass du entweder den SQL-Dienst stoppst, die DB sicherst und dann den Dienst wieder startest oder einen Dump der DB machst.

Hallo mbrkmann!

Wie bereits erwähnt, sollte es mit allen Datenbanken funktionieren. Die Frage ist nur das wie? D.h. die Verbindung (Connect) mit den entsprechenden Parametern herstellen und per SQL-Syntax die entsprechenden Daten in einen ADO-Recordset zu laden. Der ADO-Recordset ist praktisch eine Schnittstelle, in der unabhängig vom Datenbank-Typ, die Daten gelesen/bearbeitet/gespeichert... werden können.

Gruß Dieter

@Dieter: Ich bin gerne "anspruchslos und lächerlich". Wenn ich den Leuten damit Helfen kann....
Ich habe nicht nur diesen Vorschlag gemacht. Aber für das gewünschte Ziel würde es genügen, denn: Wenn ich von Datenbank reden würde, wäre es mindestens eine MySQL - kein Access.

@mbrkmann: Du kannst mit dem Connector in der Datenbank alles machen - wie vernünftig das ganze ist, hängt von der Datenbankstruktur ab.
Solltest Du Dich für diese Lösung entscheiden, nimm Dir viel Zeit für das Konzept. Das erspart Dir Ärger, wenn Du das ganze mal erweitert werden soll.

Bsp: Statt eine Tabelle anzulegen in der die kompletten Adressinformationen ablegegt sind, kannst Du z.B. PLZ + Ort auslagern. Damit stellst Du sicher, das Du nicht 1000 Mal den selben Ort in der Datenbank hast, sondern nur einmal - referenziert wird dann über die sogenannten Primary Keys. Ist zwar etwas mehr Programmieraufwand - aber Zukunftsicher.

Für den Anwender hätte es sogar den Vorteil das er bei Kundenneuanlage nur die PLZ eingibt und der Ort automatisch eingetragen wird, sofern es den schon gibt.

Hallo,

was bringt dich denn zu der Überzeugung, dass für eine von dir entwickelte Lösung keine Einarbeitung notwendig wäre? Was du später haben willst ist ja auch mehr als "ganz einfaches" Excel.
Ich würde vorschlagen, einige Stunden in Ausarbeitung von Standardabläufen & eine gute Dokumentation derselbigen zu verwenden. Gerade, wenn man viel Fluktuation hat, ist das wichtig.

Von einer Eigenentwicklung würde ich in fast allen Fällen abraten. Nicht nur, dass die Erstellung irre aufwändig ist, du musst das ganze ja auch pflegen. Und was passiert, wenn der Entwickler vom Zug überfahren wird?
Auch das halte ich für einen Trugschluss (bzw. für einen Nach- keinen Vorteil). Das bedeutet ja, dass du über einen langen Zeitraum ständig wieder Änderungen hast. Gerade, wenn man wieder weiß, wie alles funktioniert, kommt der ITler mit seinem nächsten blöden Update. Gerade nicht-IT-affine reagieren unwirsch, wenn sie jeden Monat was neues zur IT lernen müssen. Dann lieber einmal auf ein neues Produkt schulen und gut ist.

Gruß

Filipp

Hi,

also entweder mach es richtig - oder gar nicht. Du schreibst du möchtest das auf Excel/VBA o.ä. bauen? Halte ich für zimlich Unsinnig. Denn was passiert wenn du in einem Jahr das SP2 für dein office installierst (oder nen neues Office angeschafft werden muss) und dort dein Code nicht mehr läuft? Und du verlierst auch gleichzeitig die ganzen guten Dinge die eine DB so bringt - oder musst solche Filter umständlich bauen... Wie willst du z.B. die Stammdaten-Eingabe lösen?

Von daher gibt es für mich 4 Optionen:

a) Es bleibt wie es ist - weil war schon immer so und neu kostet immer Zeit...

b) Du baust das z.B. mit Access (oder Open-Office - die haben mittlerweile auch eine DB-Anwendung).

c) Du baust das ganze mit PHP/MySQL. Je nachdem wie fit du bist auch kein Thema - und die Angebote dann als PDF rausfeuern, dann hast du auch keine allzugroßen Probleme. Ok, die Eingabemaske muss natürlich vernünftig formatiert werden, ein (minimales) Rechtesystem brauchst du auch (sonst kann jeder ja alles mögliche ändern - eher schlecht...). Ob du das ganze jetzt in PHP, Java oder sonsteiner Sprache schreibst ist zweitrangig - die Sprache ist nur der kleinste Part...

d) Du kauft eine Anwendung - hier gibts genug zum Testen...

Du kommst eh nicht umzu dir verschiedene Programme anzusehen - bzw. wärst schön doof wenn du das nicht machst. Denn auch wenn du selbst Programmierst - dann hat ggf. Programm X noch eine Funktion die dir noch gar nicht in den Kopf kam - aber die richtig genial ist. Dasselbe gilt auch für Excel - ggf. hat man da ja noch ne Idee die einen aus so einem Programm gradezu anspringt während nur noch niemand darüber nachgedacht hat.

Wichtig ist jedoch: Rechne bei so einer Umstellung IMMER mit einem großen Zeitaufwand. Nicht nur das Programmieren selbst - sondern auch die Nebenkriegsschauplätze. Ich hatte z.B. in meinem Betrieb immer gesagt das es doof ist wenn nur ich das Programm kenne - WENN ich einmal das Unternehmen verlasse dann könnte das Probleme geben... Und grade wenn da das ganze Angebots-/Rechnungssystem von betroffen ist dann muss man da einfach auch dem Chef gegenüber ehrlich sein.

Schönen Gruß

Mike

Ich nutze für sowas schon seit Jahren JTL-WAWI.
Kostenlos, Mehrbenutzerfähig, Mandantenfähig, Datenbankbasiert und wirklich einfach.

http://www.jtl-software.de/produkte/jtl-wawi/

Wenn ihr sowieso eine hohe Fluktuation in dem Bereich habt, sollte es nicht so schwer sein, ein neues System einzuführen. Eine Lösung mit Excel wird nie zu einem vernünftigen Ergebnis führen.

Das ist eine Fehleinschätzung hoch drei.

Oft neue Mitarbeiter bedeutet zunächst, dass in dieser Firma irgendwas nicht rund läuft. Eine Fluktuation wo ich alle 3 bis 5 Monate die
Leute neu einarbeiten kann, das gibt es vielleicht bei Direktvertrieben im Außendienst. Diese Mitarbeiter haben aber wohl nix mit Excel-Files
am Hut. Aber wenn im kaufmännischen Bereich (egal ob Handwerkbetrieb, Handel, Produktion, ...) eine so hohe Fluktuation herrscht, dann
muss da zuvorderst eine Lösung her, die die Leute länger zu halten geeignet ist.

Ist euch bekannt woher diese hohe Fluktuation kommt?

Wenn es nicht am Führungsstil liegt, z.B. weil der Boss ein A.....h ist, dann wohl an irgendwas anderem, eventuell eben an den Arbeitsbedingungen
und dazu gehört ja wohl regelmäßig auch die IT-Bedienbarkeit und die wird durch Aufblähen einer an sich schon ungeliebten Sache nicht besser,
eher im Gegenteil. (Nur mal so zum drüber nachdenken.)

Ob es wirklich daran liegt - who knows. Aber die Handwerker/ Handwerksmeister rühren nach deiner Schilderung die EDV sowieso eher nicht an.
Also betrifft es wohl nur den kaufmännischen Bereich. Wenn also die IT tatsächlich der Reibungspunkt ist, dann kannst du auch gleich eine Komplettlösung
einführen.

Ich würde erst mal die Betroffenen fragen, wieso sie nach so kurzer Zeit schon wieder weg wollen. Und ruhig auch die Zusatzfrage wegen
der EDV-Bedienbarkeit stellen. Erst wenn das als Ursache ausgeschlossen ist, kannst du ungefähr abschätzen, ob sich der Aufwand für

Option A (Excel plus ggf. Access),

Option B (Standalone-Komplettlösung wie auch immer) oder

Option C (wie immer die auch aussehen mag)

überhaupt rechnet. Weil sonst fängt nach Deiner Fluktuation *g* der nächste IT-Verantwortliche von vorne an. Klar was ich meine?