Software zur Rechnungserstellung (Rechnungsformular)

**mm1256**

Mich beschleicht der Verdacht, daß du hier etwas verwechselst: Komplette Rechnungs-Anwendungen und Report-Generatoren, die in fast allen Datenbank-Anwendungen, die eine Druckausgabe zur Verfügung stellen, zur Anwendung kommen.

Tatsache ist, dass keines der mir bekannten TOP-10 Handwerkerprogramme in Deutschland einen Reportgenerator wie Quick-Report oder Fast-Report verwendet um damit die Auftragsbearbeitung abzuwickeln.

**BadenPower**

Zitat von mm1256:

Tatsache ist, dass keines der mir bekannten TOP-10 Handwerkerprogramme in Deutschland einen Reportgenerator wie Quick-Report oder Fast-Report verwendet um damit die Auftragsbearbeitung abzuwickeln.

Wieviel dieser Programme sind in Delphi oder mit C++Builder geschrieben?

Und wieviele Report-Tools gibt es?

Zitat von mm1256:

Tatsache ist, dass keines der mir bekannten TOP-10 Handwerkerprogramme in Deutschland einen Reportgenerator wie Quick-Report oder Fast-Report verwendet um damit die Auftragsbearbeitung abzuwickeln.

Welcher Reportgenerator wird benutzt? Woran erkennt man denn QR oder FR? Aber egal, mit Sicherheit ist kein Designer dabei. Denn damit kannst Du deine Rechnung kaputtdesignen oder durch Unwissenheit schlicht und ergreifend eine falsche Rechnung erzeugen. Und wer hat dann Schuld? Genau! Diese Drecks-Handwerksrechnungssoftware.

FR gibt es auch für .NET. Es muss nicht immer Delphi sein

**mm1256**

Ich verdiene seit über 22 Jahren meine Brötchen mit Handwerkersoftware, und kenne somit die Branche und meine Mitbewerber. Und darum weiß ich, WAS sie verwenden, und WARUM sie es verwenden. Da diese Wissensgrundlage hier teilweise fehlt - was ja bitte nichts negatives ist, sondern lediglich eine Feststellung meinerseits - halte ich mich aus dieser Diskussion jetzt raus. Noch dazu hat dies jetzt mit dem ursprünglichen Thema nichts mehr zu tun.

**Bernhard Geyer**

Zitat von mm1256:

Ich verdiene seit über 22 Jahren meine Brötchen mit Handwerkersoftware, und kenne somit die Branche und meine Mitbewerber. Und darum weiß ich, WAS sie verwenden, und WARUM sie es verwenden. Da diese Wissensgrundlage hier teilweise fehlt - was ja bitte nichts negatives ist, sondern lediglich eine Feststellung meinerseits - halte ich mich aus dieser Diskussion jetzt raus. Noch dazu hat dies jetzt mit dem ursprünglichen Thema nichts mehr zu tun.

Also wir haben in unserer Anwendung auch eine Druckfunktion. Mittlerweile ohne jeglichen "fertigen" Reportgenerator oder dessen Designer.
Den sowie die Handwerker-SW Anforderungen an den Druck haben der mit den üblichen Generatoren nur unzureichend Abbildbar ist (ohne alles doch selbst zu Programmieren) haben wir diese auch.

**Lemmy**

Zitat von Bernhard Geyer:

Also wir haben in unserer Anwendung auch eine Druckfunktion. Mittlerweile ohne jeglichen "fertigen" Reportgenerator oder dessen Designer.
Den sowie die Handwerker-SW Anforderungen an den Druck haben der mit den üblichen Generatoren nur unzureichend Abbildbar ist (ohne alles doch selbst zu Programmieren) haben wir diese auch.

Da mm1256 nicht mehr "mit spielt" die Frage an dich: Kannst Du ein Beispiel nennen? Mich würde das brennend interessieren welche spezielle Anforderungen bei Handwerkern im Rechnungsdruck vorhanden sind.

Zitat von mm1256:

Ich verdiene seit über 22 Jahren meine Brötchen mit Handwerkersoftware,

Ich erst seit 15 Jahren, dafür aber in 4 sehr unterschiedlichen Branchen (bisher noch keine Handwerker). Aber was hat das damit zu tun? Du hast Dinge in den Raum gestellt die so nicht stimmen und meine Frage nicht beantwortet. Finde ich schade...

**Daniel**

Seid bitte so gut und kommt wieder auf den Rechnungsdruck zurück ohne Euch gegenseitig in die Waden zu beißen.
Wie viele Jahre man in der Software-Entwicklung auf dem Buckel hat, ist auch nicht zwingend ein Kriterium für Kompetenz. Das kann - im Extremfall - auch bedeuten, dass man heute noch wie vor X Jahren programmiert.

Alles in Schulungen schon erlebt.

//Edit: Nur für die Statistik - auch ich entwickle für einen Kunden eine Software für das Handwerk. Gerade mit den oben genannten Ebenen Gewerk/Los/Titel/Position/Unterposition und das lässt sich wunderbar und ohne Verrenkungen in FastReport abbilden. Wir können also in der Liste "Handwerk/Delphi/FastReport" einen weitern Strich machen.

Zitat von Daniel:

Das kann - im Extremfall - auch bedeuten, dass man heute noch wie vor X Jahren programmiert.

Alles in Schulungen schon erlebt.

In der Tat

Das findest du nicht nur im Entwicklerbereich, auch bei Webdesignern oder Lehrkräften, die sich anmaßen, den Leuten den Umgang mit MS-Office beizubringen.

Zitat von Daniel:

//Edit: Nur für die Statistik - auch ich entwickle für einen Kunden eine Software für das Handwerk. Gerade mit den oben genannten Ebenen Gewerk/Los/Titel/Position/Unterposition und das lässt sich wunderbar und ohne Verrenkungen in FastReport abbilden. Wir können also in der Liste "Handwerk/Delphi/FastReport" einen weitern Strich machen.

Obwohl ich FastReport erst sein einiger Zeit kenne und nutze, mich jedoch meistens noch immer mit RaveReport rumschlagen muß, würde auch mich stark interessieren, welche Situationen es geradezu gebieten, auf den Einsatz eines Report-Generators – zumal eines derart umfangreichen und ausgereiften wie FastReport – generell zu verzichten. Dabei will ich selbstverständlich ebenfalls keine Waden verspeisen oder verbeißen, sondern einfach meinen Horizont erweitern

Zitat von TRomano:

Wenn ich heute so in Projekten sehe, was da von hand gestrickt in PDF´s gedruckt wird (wirklich Zeile für Zeile, Grafiken, Charts), dann graut es mich. Und ein Controlling (und wenn es der Projekt- oder IT-Leiter ist) scheint es da auch nicht zu geben.

Ich kann mich noch gut an meine erste kommerzielle Software erinnern, die ich mit den Mitteln von Delphi 7 Personal erstellt hatte. Ich war so stolz auf die Entwicklung der dynamischen Grafikausgabe, daß ich mich eine Zeit lang tatsächlich weigerte, mich in Report-Generatoren einzuarbeiten, weil ich davon überzeugt war, durch das Ergebnis meiner langen Tüftelei was ganz Besonderes entwickelt zu haben. Heute würde ich da ganz selbstverständlich eine Datenbank statt typisierte Dateien einsetzen, TChart statt selbstgezeichneter Kuchendiagramme und natürlich einen Report-Generator.

**TRomano**

Ich bin auch erst seit Ende der Achtziger im Geschäft (

), aber mir ist wirklich auch noch nichts untergekommen, was nicht mit einem Reportgenerator ging. Manchmal mühsam, aber es ging.Und da soll es nicht bei handwerker-Software gehen ?
Wenn ich heute so in Projekten sehe, was da von hand gestrickt in PDF´s gedruckt wird (wirklich Zeile für Zeile, Grafiken, Charts), dann graut es mich. Und ein Controlling (und wenn es der Projekt- oder IT-Leiter ist) scheint es da auch nicht zu geben.

Manchmal verabschieden sich die Leute nicht von Uralt-Techniken des vorigen Jahrhunderts, von Dingen, die sie kennen oder von alten Angewohnheiten. Zur Zeit "programmiere" ich PDF-Ausgaben, die ich mit FR5 in einer halben Stunde fertig hätte, step by step, oder auch Zeile für Zeile. Die Procedures sollen dabei so verallgemeinert werden, dass Sie auch für andere Developer nutzbar wären ... geht´s noch ? Das ist doch schon alles in FR5 programmiert worden und funktioniert dort auch ganz ordentlich !

In der Diskussion hieß es auch, dass man früher schon des Öfteren durch Reportgeneratoren-Wechsel (Delphi-Versionssprung) zurückgeworfen wurde. Ja und ? Eigenes Tool nach Vorgaben aussuchen (muss ja nicht von Emba sein) und dann auch wirklich nutzen. Oder sich beim Reporting komplett von Delphi unabhängig machen und entsprechende Report-Servewr einsetzen. Sollte bei Firmen > 10.000 MA doch möglich und strategisch richtig sein.

Zitat von mm1256:

Tatsache ist, dass keines der mir bekannten TOP-10 Handwerkerprogramme in Deutschland einen Reportgenerator wie Quick-Report oder Fast-Report verwendet um damit die Auftragsbearbeitung abzuwickeln.

Reportgeneratoren dienen ja auch nicht der Autragsbearbeitung oder -abwicklung, sondern der Ausgabe der Resultate eben dieser Bearbeitung. Irgendwie scheint mir, als ob du nicht so recht wüßtest, was ein Reportgenerator genau ist. Ein Reportgenerator ist auf keinen Fall ein Programm, das Rechnungen oder Aufträge verwaltet oder bearbeitet. Ein Reportgenerator ist ein Konstrukt, um alle nur denkbaren Ausgaben zu verwirklichen. Dabei geht es um Tabellen, Layout von Geschäftspapieren (z.B. Rechnungen oder Bestellungen) und dergleichen mehr. Nicht der Reportgenerator bearbeitet die Aufträge und erstellt die Rechnungen, sondern die Anwendungslogik, von der der Reportgenerator nur der Ausgabeteil ist.

Um es auf den Punkt zu bringen: Wer bei der Entwicklung von Business-Software, die nachvollziehbar nicht ohne Druck- und sonstige Ausgabemöglichkeiten (z.B. PDF-Export) auskommt, freiwillig auf den Einsatz von Reportgeneratoren verzichtet, macht sich unnötige Arbeit bzw. sucht das Rad neu zu erfinden.

Zitat von mm1256:

Ich verdiene seit über 22 Jahren meine Brötchen mit Handwerkersoftware, und kenne somit die Branche und meine Mitbewerber. Und darum weiß ich, WAS sie verwenden, und WARUM sie es verwenden. Da diese Wissensgrundlage hier teilweise fehlt - was ja bitte nichts negatives ist, sondern lediglich eine Feststellung meinerseits - halte ich mich aus dieser Diskussion jetzt raus. Noch dazu hat dies jetzt mit dem ursprünglichen Thema nichts mehr zu tun.

Wie darf man das verstehen? Du verfügst über den Quellcode von zehn mit deinem Projekt konkurrierenden Anwendungen im Bereich Handwerkersoftware und hast diese zehn Konkurrenzprodukte daraufhin überprüft, ob sie einen Reportgenerator verwenden? Mal ein kleines Beispiel:

Vor etlichen Jahren hab ich eine Spezialsoftware für eine Nischensparte entwickelt, deren Druckausgabe mehrere Möglichkeiten bot: Via Reportgenerator (damals: Rave) oder über MS-Word bzw. OpenOffice-Writer. Die Seiten unterschieden sich so geringfügig voneinander, daß praktisch nicht festzustellen war, welche nun mit Rave, Word oder Writer erstellt worden sind. Wie also willst du feststellen, daß deine Konkurrenz keinen Reportgenerator in ihren Code verbaut hat?

Auf die Frage, welche unüberwindlichen Hindernisse durch den Einsatz von Reportgeneratoren angeblich entstehen sollten, hätte auch ich gerne eine sinnvolle Antwort gelesen ...