[gelöst]Rechnungen erstellen mit CCK, View, Computed Field (+ Calendar)

Hallo,
ich finde den Ansatz sehr interessant. Ich probiere zur Zeit das Modul stom zu nutzen, um ein Projektmanagementtool zu integrieren. Leider sind hierbei umfangreiche Anpassungen entsprechend der Bedürfnisse vorzunehmen, so dass es nicht so einfach zu integrieren ist.
Vielleicht kannst du deinen jetzigen Ansatz etwas intensiver erklären? Also bspw. wie und wo verwaltest du den Zeitaufwand, der pro Kunde entsteht?

Leider habe ich keine Idee, wie die Daten in die Rechnung integriert werden können, bin aber an einer Lösung interessiert.

Grüße

Hi,
Strom hatte ich mir auch angesehen. Das ist aber für meine Bedürfnisse zu komplex. Genauso wie auch UC, oder wie dieses Shoppingsystem heißt.

Im Moment ist das Ganze noch nicht so flexibel, als dass man von "Verwalten des Zeitaufwandes beim Kunden" reden könnte. In meinem speziellen Fall geht es darum, sehr fixe Termine, wie Musikunterricht, Nachhilfe oder Altenpflege zu verwalten.

Die Dienstleistung ist bei mir ein Inhaltstyp "Service" mit Dauer, Preis, Beschreibung etc.. Für die einzelnen Dienstleistungen ist dann jeweils ein Node abgelegt, etwa: Haarewaschen - 5 min. - 5 Euro, Nachhilfe Deutsch - 30 min. - 20 Euro.
Wenn du einen Termin anlegst, kannst du Kunden und Service (jeweils per Dropdown) wählen und eben Datum/Zeit angeben.
Zeiterkennung (wie Terminüberschneidungen etc.) gibt es - noch - nicht. Alles also recht einfach.

Hab gerad in der DB gesehen, dass über Computed Fields eingebettete und gespeicherte Views als html-Code hinterlegt werden. Bekommt man den Code mit einem PDF-Export hinterher wieder vernünfitg formatiert ausgelesen?

Die Rechnung sieht momentan so aus. Fehlen Summe der Leistung und MwSt.-Berechnung.

Ideen sind herzlich willkommen!

Ich mache zwar nicht gerade Rechnungen, aber andere Dokumente (bis zu 30 Seiten), welche ein relativ komplexes Datenmodell und Berechnungen voraussetzen.

Nach langem Hin und Her bin ich zum Schluss gekommen, dass ich
a) Stammdaten sauber in verschiedene Inhaltstypen versorge (z.B. Kunden, Dokument-Header, Artikel- und Leistungs-Vorlagen, Rapporte u.ä.)
b) Mit Node Relationsships dafür sorge, dass die relationalen Verknüpfungen korrekt sind
c) Mich NICHT MEHR um die Berechnung und optische Darstellung des "Dokuments" am Bildschirm über "Drupal" kümmere, weil viel zu kompliziert mit Computed Fields, Views etc.

Da ich die Dokumente berechnen, sichten und drucken muss, habe ich mir ein Modul gemacht, welches in erster Linie das Dokument berechnet und aufbereitet und mir
dieses per fpdf als PDF am Bildschirm zeigt.
Dies kann ich "provisorisch" oder "definitiv" tun. Bei "definitiv" werden die berechneten Werte in einer Node gespeichert, bei "provisorisch" nicht. Die Prozesse werden über Links gestartet,
die ich mir in die nodexxx.php.tpl eingebaut habe (quick&dirty...).
Das PDF kann dann anschliessend auch gedruckt werden.
Sowas kann dann natürlich auch automatisiert aufbereitet, gespeichert und gedruckt werden - soweit musste ich aber bisher nicht gehen.

Die Modul-Methode hat für mich den Vorteil, dass meine Berechnungen nur genau an einem Ort stattfinden und der Update sehr easy ist.
Dafür kann ich Drupal für eine schöne Stammdaten-Darstellung ausreizen und muss keine Angst haben, dass mir bei einer "Theme-Spielerei" die Optik meiner
Dokumente flötengeht.

Vielleicht ist dieser Ansatz nützlich für Euch...

Moin,
danke für deine hilfreiche Antwort.

Bei a) und c) stimme ich voll zu. So wollte ich das eigentlich haben, ein einfaches PDF-Template, in dem per Knopfdruck die Rechnungsdaten eingefügt werden und das PDF erzeugt wird. Leider habe ich feststellen müssen, dass ein guter PDF-Export in dieser Art als Modul noch nciht besteht, eigenlich kann man lediglich Nodes drucken, was dann die von dir beschriebenen Probleme mit der Darstellung bringt.
Eine Frage noch, warum hinterlegst du Kundendaten als nodes anstatt die Benutzerprofile zu nutzten? Hat das Vorteile?

Zu b): Node Relationship hab ich mal kurz angesehen. Im Moment verstehe ich den Nutzen noch nicht ganz, außer dass ich einzelne Inhalte verlinke. Kannst du das bitte etwas näher erklären, wie du das Modul verwendest.

fpdf hab ich auch angesehen und das könnte tatsächlich etwas sein. :)

Zum Thema "Rechnung mit Computed Fields":
Also ich hab mein Node "Rechnung" jetzt so weit zum laufen gebracht, dass Computed Field auch die Berechnung von Rechnungssumme, Mehrwertsteuer usw. automatisch erzeugt.
Der ganz große Nachteil ist, dass in den einzelnen Computed Fields ein ziemlicher Wust an php-Code hinterlegt ist. Nicht gerade wartungsfreundlich, könnte man sagen. Außerdem habe ich allein für diese Node 10-12 Eintragungen bei den Berechtigungne im content-permission-modul-Bereich. Auch das ist etwas aufwändig.
Kurz: Die Lösung gefällt mir nicht wirklich und das Problem des PDF-Druckens besteht noch immer.

Ich werd mir jetzt mal anschauen, wie man das mit einem Modul realisieren kann.

Tipps, Hinweise und Infos weiter herzlich willkommen.

Gruß
Michael

Zu Deinen Fragen:

- Kundendaten als Node: Ganz einfach - ich habe ein Intranet, und da haben meine Kunden nichts zu suchen ;-)
Deshalb: Kunden müssen nicht immer zwangsweise User sein. Es ist simpel und einfach eine Adresse...
Notabene muss ich meine Theming-Methoden nicht ändern, wenn es um Adressen geht...es ist ein Inhaltstyp, wie jeder andere.

- Das Modul Node Reference nutzt nicht nur die CCK Node Reference, sondern stellt v.a. ein Super Frontend zur Verfügung, relationale Konstrukte zu erstellen u dzu warten und - das ist am schönsten: es bringt Views, welches die Child-Nodes direkt in einem Headernode als Tabelle innerhalb des Nodes, oder als Tabelle in einem separaten Register des Nodes darstellt. Das Modul Views ist dazu natürlich Grundvoraussetzung.
Man muss aber schon eine Ahnung von relationalen Datenbanken haben, um das Modul auszureizen.

- Ja, es gibt kein Modul, welches etwas komplexe Konstrukte "gescheit" zu Papier bringen kann. Aber ich habe mit fpdf fast nichts mehr, was ich nicht machen könnte. Allerdings musste ich halt eben dafür ein eigenes Modul machen.

- Im Endeffekt geht es bei mir so:
Mein Dokument ist ein "Objekt". Daher habe ich mir eine php-Klasse dafür gebaut. Das Modul erzeugt also aufgrund der übergebenen Stamm-Daten ein Dokument-Objekt, loopt durch die zugeordneten "Child"-Nodes, rechnet sich durch, sucht sich weitere Informationen zusammen und speichert bei Bedarf die berechneten Werte in Hauptnode zurück. Danach erstelle ich ein fpdf-Objekt, wo ich dann ganz nach Lust und Laune die Print-Optik zusammenbastle. So kann ich z.B. auch die Graphiken unabhängig von Drupal "lagern" - so ist mein php-Code auch nicht in der DB, sondern im Modul.

Klingt einfach, aber es war ein nicht ganz kurzer Weg dahin...^^

Hey, herzlichen Dank nochmal, leda!

Das Eigenes-Modul-Schreiben war dann doch nicht soooo kompliziert wie ich zuerst dachte, wobei meine Funktionen dem Anschein nach nicht so komplex sind wie bei dir (zB deine Node Reference Beschreibung hab ich noch immer nicht voll verdaut...muss mal mehr damit testen).

Auf jedenfall hab ich gerade mein erstes Rechnungs-PDF aus einem eigenen Node-Modul generiert. Zeigt zwar iM nur unformatiert (und testweise) die R.Nr. & 2 Daten aus dem Kundenprofil an, aber das ist jetzt nur noch eine Frage der Formatierung und des Copy&Paste, also der Zeit. Bisschen muss ich noch am Modul tun: Leistungen in DB-Tabelle eintragen, restliche Berechnungen aus den Computed Fields einfügen, hook_update einfügen, der hook_view sowie hook_form(type=>date) laufen auch noch nicht so richtig.

Sorry, ich bin etwas überschwänglich :D

Für alle Interessierten die (sehr spezielle) Lösung:
Ein node-Modul (Infos dazu gibts hier im Forum bzw. bei drupal.org (v6.x) sowie in einigen Video bzw. auf anderen Webseiten) für die Rechnungen erstellen. In der .install-Datei die notwendige Tabelle samt Felder erzeugen lassen (uninstall_hook nicht vergessen ;) ). Die .modul_datei nach Schema F, also wie überall reichlich beschrieben aufbauen. Mit hook_form die notwendigen Felder einfügen. Im hook_insert die notwendigen Daten - auch jene aus anderen Tabellen zB mit user_load die Kunden bzw. per selbstgeschriebenen Filter und db_query verknüpft die Daten der Dienstleistungen und Preise für den Rechnungsemfänger zur Zeit der Rechnungsstellung - ermitteln und dann in die neue Datenbanktabelle schicken.
Diese Tabelle ist Ausgang für die Rechnung-PDF, die mit fpdf erzeugt wird. Dazu einfach fpdf im Modulverzeichnis (hab ich so gemacht) installieren und eine print.php in das Verzeichnis legen. Die print.php liest die Daten aus der Tabelle und generiert damit die PDF. Dazu habe ich einfach - wie leda vorschlug - in einem node-rechnung.tpl einen Link eingefügt und übergebe mit "get" die nid. Diese nutze ich dann zum Auslesen der Datenbank für das PDF. Thats it! (Zeitaufwand bisher etwa 14h - geschätzt noch etwa 8 -12 h für Reste und Design - danach 3/4-vollautomatisiert Rechnungen per Knopfdruck als PDF speichern und/oder drucken. Yippie ya yeah.)

Dem ein oder anderen wird das etwas anfängermäßig vorkommen. Zur Rechtfertigung: Ich bin sowohl in php als auch in Drupal Anfänger. Insofern liebe Anfänger traut Euch!

Erbaulichen Gruß
Michael