Software zur Rechnungserstellung (Rechnungsformular)

[SyntaxXx]

Schönen guten Tag zusammen,
ich spiele schon länger mit dem Gedanken, eine Software zur Rechnungserstellung zu entwickeln.
Da ich selbst in einem passenden Betrieb arbeite, der auf Dauer eine neuere Rechnungssoftware benötigt.

Ich habe mir schon einige Gedanken gemacht, nur bei einer Sache bin ich noch ordentlich am grübeln.
Das Rechnungsformular muss individuell anpassbar sein.

Jetzt spiele ich zur Zeit mit zwei Gedanken.

1. Ich stelle verschiedene Templates bereit, mit festen Komponenten an einer bestimmten Position und der Anwender kann nur sein Logo und Texte ändern
2. Ich erstelle ein festes Template, indem der Anwender jedoch Formen frei bewegen, hinzufügen und löschen kann.

Jedoch habe ich keine Ahnung, wie man Formen zu Laufzeit bewegen, hinzufügen und löschen kann.

Jetzt die Frage, wäre Variante 2 viel Arbeit oder bietet Delphi da wie bei fast allem eine relativ einfache Lösung?


Oder vielleicht habt ihr ja noch ganz andere Ideen ?!


Vielen Dank schonmal

[Sir Rufo]

Das Rechnungs-Formular ist ein Report und den kann man z.B. mit Fast-Report und dem dortigen Report-Designer anpassen. In den Kauf-Versionen auch mit End-User-Designer.

[SyntaxXx]

Na das ist mal eine feine Sache.
Sieht auf jeden Fall nützlich aus.

Mal schauen, ob ich damit ein Rechnungs-Formular :) zu Stande bekomme.

Vielen Dank

[Darlo]

Quickreport hat auch einen Designer für Endanwender.

[TheMiller]

Ich kann Sir Rufo nur beipflichten.

Ich habe vor langer Zeit ein Rechnungsmodul programmiert und nutze seti Ewigkeiten Fast-Report. Ich finde, es ist eine sehr gute und durchdachte Komponente, Reports sind einfach zu erstellen und Vererbung funktioniert auch prima. Nur der PDF-Export war ein wenig schlecht integriert, wobei sie hier auch nachbessern. Viele Updates etc.

Zum Rechnungsprogramm ein paar Tipps:
Denke zB an
* verschiedene Reports für verschiedene Kundengruppen
* Umgang mit Ratenzahlungen
* Wiederverwendbare Rechnungspositionen (so muss man nicht immer alles neu schreiben, sondern kann sich irgendwann die Rechnung zusammenklicken)
* Statistik offener Rechnungen
* Mahnläufe etc.
* Bewertung vom Zahlungsverhalten von Kunden (wie oft über Mahnstufe X)
* Direkter Export und Versand per eMail/ePost-Brief oder Fax

Nur mal so nebenbei, was mir gerade eingefallen ist.

[Captnemo]

Interessant für ein Rechnungsprogramm, je nach Branche, sind noch die unterschiedlichen zu Berücksichtigenden Mehrwertsteuersätze. Es kann nämlich vorkommen, dass innerhalb einer Rechnung einzelne Positionen mit unterschiedlichen Steuersätzen zu berechnen sind, und diese dann auch in der Summierung einzeln aufzuführen sind.
Wenn man das in der Entwicklung nicht berücksichtigt, dann ist das später nur aufwendig nachzupflegen.

[mquadrat]

Ich würde einfach was am Markt vorhandenes nehmen. Im Web-Bereich gibt's einige schöne Sachen, wenn man einen niedrigen Durchlauf hat. Wer mehr Anforderungen schaut sich die WaWi Box-Ware an (Sage, Lexware, etc) und wer da raus gewachsen ist, schaut dann bei den modularen Systemen.

Selber schreiben macht nur einen Haufen Arbeit. Und du wirst Diskussionen mit Steuerberatern führen, die schon diverse Softwarefabrikanten vor die geführt haben.

[TRomano]

Eine Software vom freien Markt (wie Vorredner) sollte echt genügen, da ich nun keine besonderen Spezifika bei Dir sehe oder lese.
Wenn ich dann noch eine einfache Kosten-Nutzen-Rechnung mache (Aufwand Programmierung, Testen etc. zum einem Kaufpreis), dann lohnt sich so etwas heut zu Tage kaum noch.
So etwas ist auch nicht in zwei Tagen geschrieben.

Es gibt bei Euch bestimmt auch noch spannendere Themen in der Firma, oder :?

[mm1256]

Zitat:

Zitat von mquadrat (Beitrag 1295562)

Selber schreiben macht nur einen Haufen Arbeit.

Kann ich nur wiederholen. Das ist schon ein sehr großer Haufen, auch wenn's am Anfang nicht danach aussieht.

Zitat:

Zitat von mquadrat (Beitrag 1295562)

Und du wirst Diskussionen mit Steuerberatern führen, die schon diverse Softwarefabrikanten vor die geführt haben.

Alleine DATEV verlangt für die Dokumentation der Schnittstelle schon so viel, was eine Standardlösung kostet.

Nochmals zum Thema: Ob Fast Report oder Quick Report, beide kommen schnell an die Grenzen, wenn es in die Tiefe geht. Darum ist erst mal wichtig, für welche Branche soll es denn sein. Ansonsten ist eine qualifizierte Aussage über das zu verwendende Report-Tool nicht möglich. Wenn es "einfache" Rechnungen sind, z.B. für den Handel, dann reichen diese Tools aus. Wenn es aber z.B. in den Bereich Handwerk geht, dann wird das damit eine Bauchlandung.

[RSF]

Zitat:

Zitat von mm1256 (Beitrag 1295570)

Ob Fast Report oder Quick Report, beide kommen schnell an die Grenzen, wenn es in die Tiefe geht. Darum ist erst mal wichtig, für welche Branche soll es denn sein. Ansonsten ist eine qualifizierte Aussage über das zu verwendende Report-Tool nicht möglich. Wenn es "einfache" Rechnungen sind, z.B. für den Handel, dann reichen diese Tools aus. Wenn es aber z.B. in den Bereich Handwerk geht, dann wird das damit eine Bauchlandung.

Kann ich nicht bestätigen.
Ein gängiges Report-Tool (z.B. Fast Report) verursacht keine Bauchlandung bei Handwerker-Rechnung. Entscheidend ist eher das Gesamtkonzept (DB, Programmlogik, Rechtsgrundlagen usw)

[mm1256]

[ot]

Zitat:

Zitat von RSF (Beitrag 1295581)

Kann ich nicht bestätigen. Ein gängiges Report-Tool (z.B. Fast Report) verursacht keine Bauchlandung bei Handwerker-Rechnung.

Und warum investieren dann Softwarehersteller in dieser Branche Mannjahre (und somit einige hunderttausend Euronen) für Eigenentwicklungen?

Ich hab die zitierte Bauchlandung jedenfalls schon hinter mir.
[/ot]

[BadenPower]

Zitat:

Zitat von mm1256 (Beitrag 1295570)

Ob Fast Report oder Quick Report, beide kommen schnell an die Grenzen, wenn es in die Tiefe geht.
...
Wenn es aber z.B. in den Bereich Handwerk geht, dann wird das damit eine Bauchlandung.

Sorry, aber diese Aussage verstehe ich nicht.

Was gibt es auf der Rechnung eines Handwerkers darzustellen, was QuickReport nicht darstellen könnte?

[Lemmy]

Zitat:

Zitat von mm1256 (Beitrag 1295601)

[ot]

Zitat:

Zitat von RSF (Beitrag 1295581)

Kann ich nicht bestätigen. Ein gängiges Report-Tool (z.B. Fast Report) verursacht keine Bauchlandung bei Handwerker-Rechnung.

Und warum investieren dann Softwarehersteller in dieser Branche Mannjahre (und somit einige hunderttausend Euronen) für Eigenentwicklungen?

Ich hab die zitierte Bauchlandung jedenfalls schon hinter mir.
[/ot]

Sag es uns bitte. Mich würde das fachlich sehr interresieren warum eine bestimmte Druckausgabe bei Rechnungen im Handwerk nicht ausreichend sein soll.

[mm1256]

Zitat:

Zitat von BadenPower (Beitrag 1295612)

Was gibt es auf der Rechnung eines Handwerkers darzustellen, was QuickReport nicht darstellen könnte?

Jetzt wird's total OT, aber ganz kurz: Die gängigen Reporting-Tools können nur eine Sub-Ebene oder Master-Detail...wie immer man das nennt. In einer Handwerker-Rechnung kommen bis zu 4 Ebenen vor.

Im Ausdruck sind das Lose/Titel/Untertitel, mit den verschiedenen Positionsarten Material/Leistung/Stundenlohn/Jumbo/Text/Bild, den dazu möglichen Positionseigenschaften ALternativ/Bedarf/Garantie, mit den optional wählbaren Druckmöglichkeiten von Aufmaß/Materialzuordnung (Leistung+Jumbo) und Lohn- und Materialanteil.

Hinzu kommt, dass mit Standard-Tools das "Mergen" von mehreren Druckjobs wie Deckblatt, der eigentlichen Rechnung, dem Aufmass, sowie der Los- und Titelzusammenstellung nicht oder nur sehr schwierig bzw. umständlich möglich ist.

[Perlsau]

Zitat:

Zitat von mm1256 (Beitrag 1295570)

Nochmals zum Thema: Ob Fast Report oder Quick Report, beide kommen schnell an die Grenzen, wenn es in die Tiefe geht. Darum ist erst mal wichtig, für welche Branche soll es denn sein. Ansonsten ist eine qualifizierte Aussage über das zu verwendende Report-Tool nicht möglich. Wenn es "einfache" Rechnungen sind, z.B. für den Handel, dann reichen diese Tools aus. Wenn es aber z.B. in den Bereich Handwerk geht, dann wird das damit eine Bauchlandung.

Das hat mich auch verwundert: Inwiefern sollten Report-Generatoren wie Fast- oder Quickreport "schnell an die Grenzen" kommen, da es sich hierbei doch lediglich um darstellende Komponenten handelt, die die Ausgabe erleichtern? 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.

Zitat:

Zitat von mm1256 (Beitrag 1295619)

Jetzt wird's total OT, aber ganz kurz: Die gängigen Reporting-Tools können nur eine Sub-Ebene oder Master-Detail...wie immer man das nennt. In einer Handwerker-Rechnung kommen bis zu 4 Ebenen vor.

Das ist doch Sache der Datenaufbereitung. Die Report-Generatoren dienen lediglich der Ausgabe.

Zitat:

Zitat von mm1256 (Beitrag 1295619)

Im Ausdruck sind das Lose/Titel/Untertitel, mit den verschiedenen Positionsarten Material/Leistung/Stundenlohn/Jumbo/Text/Bild, den dazu möglichen Positionseigenschaften ALternativ/Bedarf/Garantie, mit den optional wählbaren Druckmöglichkeiten von Aufmaß/Materialzuordnung (Leistung+Jumbo) und Lohn- und Materialanteil. Hinzu kommt, dass mit Standard-Tools das "Mergen" von mehreren Druckjobs wie Deckblatt, der eigentlichen Rechnung, dem Aufmass, sowie der Los- und Titelzusammenstellung nicht oder nur sehr schwierig bzw. umständlich möglich ist.

Also wenn du das ohne Report-Generatoren hinbekommst, dann bekommst du das noch leichter mit Report-Generatoren hin.

[mm1256]

Zitat:

Zitat von Perlsau (Beitrag 1295620)

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:

Zitat von mm1256 (Beitrag 1295622)

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?

[RSF]

Zitat:

Zitat von mm1256 (Beitrag 1295619)

... Die gängigen Reporting-Tools können nur eine Sub-Ebene oder Master-Detail...wie immer man das nennt. In einer Handwerker-Rechnung kommen bis zu 4 Ebenen vor.

Im Ausdruck sind das Lose/Titel/Untertitel, mit den verschiedenen Positionsarten Material/Leistung/Stundenlohn/Jumbo/Text/Bild, den dazu möglichen Positionseigenschaften ALternativ/Bedarf/Garantie, mit den optional wählbaren Druckmöglichkeiten von Aufmaß/Materialzuordnung (Leistung+Jumbo) und Lohn- und Materialanteil.

Hinzu kommt, dass mit Standard-Tools das "Mergen" von mehreren Druckjobs wie Deckblatt, der eigentlichen Rechnung, dem Aufmass, sowie der Los- und Titelzusammenstellung nicht oder nur sehr schwierig bzw. umständlich möglich ist.

Na und …:lol:
Ist mit Fast Report kein Problem. Vorausgesetzt man hat eine ordentlich strukturierte Datenbank und die passende Geschäftslogik dazu.

[Lemmy]

Zitat:

Zitat von mm1256 (Beitrag 1295619)

Zitat:

Zitat von BadenPower (Beitrag 1295612)

Was gibt es auf der Rechnung eines Handwerkers darzustellen, was QuickReport nicht darstellen könnte?

Jetzt wird's total OT, aber ganz kurz: Die gängigen Reporting-Tools können nur eine Sub-Ebene oder Master-Detail...wie immer man das nennt. In einer Handwerker-Rechnung kommen bis zu 4 Ebenen vor.

falsch. Fastreport kann auf einfachem Weg bis zu 6 Ebenen https://www.fast-report.com/public_d...-en/index.html und per Subreport noch deutlich mehr.

Zitat:

Zitat von mm1256 (Beitrag 1295619)

Im Ausdruck sind das Lose/Titel/Untertitel, mit den verschiedenen Positionsarten Material/Leistung/Stundenlohn/Jumbo/Text/Bild, den dazu möglichen Positionseigenschaften ALternativ/Bedarf/Garantie, mit den optional wählbaren Druckmöglichkeiten von Aufmaß/Materialzuordnung (Leistung+Jumbo) und Lohn- und Materialanteil.

ich kann keine Anforderung erkennen die nicht mit FR umzusetzen ist...

Zitat:

Zitat von mm1256 (Beitrag 1295619)

Hinzu kommt, dass mit Standard-Tools das "Mergen" von mehreren Druckjobs wie Deckblatt, der eigentlichen Rechnung, dem Aufmass, sowie der Los- und Titelzusammenstellung nicht oder nur sehr schwierig bzw. umständlich möglich ist.

alles kein Problem mit Fastreport. Sei es den Report aus mehreren Seiten zu erstellen oder bel. Reports zu erstellen und vor dem Druck/Preview zusammen zu führen.

Zitat:

Zitat von mm1256 (Beitrag 1295622)

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.

Preisfrage: Wie viele sind davon in Delphi implementiert? und welche Reportgeneratoren verwenden die? Dass es individuelle Entscheidungen / Notwendigkeiten gibt auf den einen Reportgenerator zu setzen oder eben nicht will ich nicht abstreiten.

[Dejan Vu]

Zitat:

Zitat von mm1256 (Beitrag 1295622)

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:

Zitat von mm1256 (Beitrag 1295632)

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.

[Perlsau]

Zitat:

Zitat von mm1256 (Beitrag 1295622)

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:

Zitat von mm1256 (Beitrag 1295632)

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 ...

[Dejan Vu]

Ich beschäftige mich seit 35 Jahren mit Softwareentwicklung und habe daher viel mehr Weisheit mit Löffeln gefressen als ein Juniorprogrammierer, der gerade mal lächerliche 22 Jahre Erfahrung hat... und alle anderen haben eh keine Ahnung. Und weil das so ist, rede ich nicht mit dem Mob? :wall:

Was soll diese Art der Argumentation? Und dann noch nicht mal Fehler zugeben können ("Master-Detail" mehr können die nicht). Disqualifiziert man sich damit nicht selbst?

Ob Reportgeneratoren geeignet sind oder nicht, muss jeder selbst entscheiden. Ich habe noch alle Anforderungen (egal wie komplex sie waren) mit FR umgesetzt bekommen, aber teilweise musste ich schon ganz schön knobeln. Es wäre denkbar, das ich die eine oder andere Seite mit selbstrenderndenen Code schneller hinbekommen hätte, aber dann hätte ich zwei Reportparadigmen in der SW und das wäre noch schlimmer, als die paar mal suboptimal zu arbeiten, denn unterm Strich bin ich mit FR immer besser gefahren, als alles selbst zu rendern (nebenbei: Was ich rendern kann, kann ich auch mit FR rendern).

Aber natürlich macht jeder seine eigenen Erfahrungen.

[Lemmy]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1295636)

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:

Zitat von mm1256 (Beitrag 1295632)

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. ;-)

[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.

[Perlsau]

Zitat:

Zitat von Daniel (Beitrag 1295677)

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:

Zitat von Daniel (Beitrag 1295677)

//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. ;-)

:thumb:

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 :lol:

Zitat:

Zitat von TRomano (Beitrag 1295683)

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]

Wie gesagt: ich kenne auch keinen konkreten Anwendungsfall, wo FastReport (ich nutze Version 5.2 Enterprise) nicht ausreichen würde. Rave war und ist bestimmt nicht der Burner, geht aber für einfache Sachen auch.
Wenn man allerdings das Reporting losgelöst von der Anwendungssoftware haben möchte (oder eine Mischform) gibt es halt auch andere Sachen, wie Crystal Reports oder die Reportgeneratoren in den Datenbank-Systemen.

@Perlsau: Damals war das in vielen Fällen auch noch notwendig, da es z.B. in den Reportgeneratoren keinen PDF-Export gab usw. Auch ich habe mir einen Wolf mit Listen (so hieß das damals noch :-D) programmiert. Will ich aber auch nicht mehr haben ...

[IBExpert]

es kommt mit Sicherheit nicht auf eine Entscheidung entweder oder an, also entweder Reportdesigner eingebaut und durch den Endkunden benutzbar oder gar nichts eingebaut, mit dem der Kunde was anpassen kann. Meiner Erfahrung nach sind die meisten Kunden sehrwohl daran interessiert, die Report Vorlagen selbst anzupassen und wenn das nur in kryptischen Text- oder XML Formaten machbar ist, dann kommt da nicht immer Freude auf.

Eine GUI Version, in der ich schon mal sehen kann, wie es aussieht, wo ich Schriften anpassen kann, Felder und Spalten da einsetze, wo die hin sollen, der verbringt auch wenig Zeit, falls er mal als Softwarehersteller in einer Diskussion mit dem Kunden interaktiv das Formular so anpassen soll, wie er es denn haben möchte.

Wer aber seine Report Vorlagen mit kompletter Business Logik umsetzt, der scheitert da auch ganz schnell. Wer sich mal in der Software AvERP mit der Anpassung eines Reports beschäftigt hat, weiß wovon ich rede.

Ich bevorzuge eine Kombination der Techniken. Ich erstelle in unserer brp Software für Kunden die Reportdaten in Form von Firebird Stored Procedures (könnte ggf. aber auch jede andere Art von Prozedur im Delphi oder Lazarus Code sein). In diesen Prozeduren sind dann die alle anzuzeigenden Daten bereits enthalten, d.h. auch so was wie Zwischensummen bei Gruppenwechsel o.ä. berechne ich in dieser Prozedur, den sehr oft sind zum Beispiel in Angeboten Alternativpositionen enthalten und wenn man die einfach in die Endsumme reinrechnet, sieht das nicht nur blöd aus, sondern ist auch faktisch falsch, weil abschreckend für den Kunden, der das Angebot nur über die Endsumme vergleicht.

Die Logik, wie man nun Alternativpositionen im Code des Reports auseinandernimmt, brauch ich in der Datenbank sowieso, will die also nicht ncoh mal im Report Generator umsetzen, der meistens keinen Debugger hat und daher viel Arbeit doppelt macht.

Aus diesem Grund erzeuge ich für jeden Report eben in der Datenbank Prozeduren, die ich da auch debuggen kann und wo ich eigene Rundungsvarianten umsetzen kann und vieles mehr (ich mach auf dem weg auch die mehrsprachigkeit, da alle Labels auch aus einer Prozedur gefüllt passend zur Kundensprache werden, das geht auf dem Weg ggf auch mit Fremdwärungen etc.).

Im Reportdesigner stelle ich nun einen rudimentären Report für den Kunden als Vorlage auf Basis der SP Daten zusammen. Diesen kann der Kunde auf Basis der verfügbaren Daten dann selbst so lange optisch verfeinern, wie er das möchte. Kostet nur seine Zeit, die Logik der Daten kann er damit aber nicht unterwandern. Wenn also irgendwas in der Ausgabe nicht passt, dann muss ich nicht lange suchen, wo der Kunde wohl versehentlich mal ein berechnetes Objekt im Reportdesigner verbessert hat ...

Ob man das nun technisch wie wir mit Lazarus und Lazreport macht oder mit anderen Datenbanken und Delphi und Fastreport oder anderen Reporttools macht, ist dabei fast egal. Lass einfach keine unbeteilgten an der Business Logik rumschrauben, sondern ziehe klare Grenzen, das er das gerne bunt anmalen darf oder so wie das ein Kunde auch schon geschafft hat, die Schriftfarbe veränder. Der hatte nämlich für das Reportformular eine Schriftfarbe weiss eingestellt, die dann an alle Objekt auf dem Deignerformular vererbt wurde, dort aber dann trotzdem in schwarz angezeigt wurde, so das man nicht auf Anhieb erkennen konnte, warum da immer nur weisse Seiten rauskommen. Das war entweder Quickreport oder Reportsmith ....

Ja auch das war mal in Delphi drin. Ganz im Sinne des o.a. Posts ist aber weder Alter noch Jugend irgendeine Art der Qualifikation. Erfahrung hilft in diesem Job erheblich, birgt aber auch die Gefahr, die eigene Technik als das Non Plus Ultra zu sehen.