CRM Extension Teil 1:Adressbuch

[schman]

@schman
Bis vor 2 Minuten wusste ich noch nicht was vCards sind, aber jetzt will ich sie auch drin haben
Wie stellst du dir die vCards vor? Als Frontendmodul zum runterladen oder eher als Massenabspeicherung wie einen Export?
Wahrscheinlich werden nicht alle Felder in die jeweiligen Programme übernommen werden können.
Aber das Problem werde ich beim Import und Export auch haben.

Einfach als Download für den jeweiligen Kontakt, wäre natürlich fein im Frontend sowie Backend.
Wenn ich das richtig mitgekriegt habe wirst du eh einen exporta ls xls/xml what else anbieten.

[tinoo]

Hallöchen

CSV-Export der gewünschten Daten ermöglichen, und dann ist der Rest einfache Seriendokumenterstellung im Office-Programm der eigenen Wahl!

Ja und nein.

Der Vorteil eines CMS ist ja unter anderem, dass sich niemand (ausser dem Webmaster natürlich) um das Aussehen der bereitgestellten Daten kümmern muss, sondern im Prinzip jeder einen Beitrag schreiben kann und dieser dann in einem einheitlichen Design daher kommt. Warum also soll ich eine Adressdatenbank betrieben, wenn schlussendlich jeder die Daten runterladen und irgendwo wieder importieren muss? Damit ist ja schon nicht mehr sichergestellt, dass wenn ich die Umschläge bedrucke, das dann gleich ausschaut wie wenn es mein Kollege macht. Dann kann ich ja gleich bei unserem bisherigen System bleiben. Oder was soll die Motivation sein, die Daten online zu verwalten, wenn ich sie nur "offline" weiterverarbeiten kann?

Ich finde es schon wichtig, dass man sich von Anfang an nicht bloss Gedanken dazu macht, wie man die Daten erfassen und verwalten kann, sondern auch in welcher Form man die Daten wieder verfügbar macht. Und da gehört nicht bloss der Bildschirm als Medium dazu - sondern halt eben auch der Print auf Papier!

[christian.kolb]

@schman

Wenn ich das richtig mitgekriegt habe wirst du eh einen exporta ls xls/xml what else anbieten.

Ja ist richtig und ich habe vor den export einzelner Adressen im FE anzubieten. Im FE einen voll Export anzubieten finde ich sicherheitstechnisch kritisch da wahrscheinlich nicht einmal ein Verein alle Adressdaten der Mitglieder anbieten würde, geschweigeden ein Unternehmen. Den vollen Export wird es nur im BE geben.

@tinoo
Ja und nein.
Zwar wäre es im Sinne eines CMS die gesamte Verwaltung einer Person (oder kleinen Gruppe) zu überlassen, aber ich denke nicht, dass das der Sinn oder Normalfall bei einem CRM ist. Natürlich hast du Recht das man sich auch Gedanken über den Output machen sollte, aber die Art und die Daten die die unterschiedlichen Unternehmen für sagen wir ein Angebot nutzen sind so unterschiedlich, dass ich nicht denke, dass man sich auf einen festen Satz Daten einigen kann.
Vielleicht wird das CRM irgendwann so weit sein, dass man nurnoch einen Kontakt auswählt, auf einen "Angebot erzeugen" Button klickt und automatisch eine Word Vorlage geöffnet wird und alle Daten übertragen werden. Aber bis dahin wird es wohl noch eine weile dauern.
Aber auf jeden Fall wieder eines was ich im Hinterkopf behalten werde. Bis dahin ist eine Schnittstelle wie CSV wohl ein gutere Kompromiss.

Gruß
Freshlifepages

[Tiggr]

Hiho!

@tinoo:

Ja und nein.

Du hast vollkommen recht! Wenn man erst den Umweg über eine Excel-Tabelle gehen muss, ist das unelegant. Und das schlimmste ist: Der User fängt viel zu schnell wieder an, in Excel statt im CRM Daten zu erfassen und zu pflegen!

ABER: Eine Anbindung an ein Office-Programm, oder direktes erzeugen von PDF-Dokumenten mit allen Layoutfeatures von Word oder OOo ist schwierig und aufwendig. Klar wäre das ein Langzeitziel. Aber ich würde erstmal ein funktionierendes CRM wünschen und das dann eventuell die Dokumentenerstellnug nachliefern - aber auf keinem Fall gleich jetzt schon angehen.

Der erste Schritt ist - das macht Freshlifepages komplett richtig - erstmal das Datenmodell und die Grundfunktionen zu erstellen. Das ist die Basis. Welche Daten braucht man, wie werden sie verknüpft, wie und nach was wird ausgewertet, das sind die Kernfragen, und die stellt er zum Glück auch!

Tschüss
Marcus (aka Tiggr)

[tinoo]

@Freshlifepages:
Deinen Einwand bezüglich Export und Datensicherheit finde ich sehr gut. Überlegen muss man sich aber, ob das CRM auf einem Intranet betrieben wird, oder im Internet. Wenn es nur in einem Intranet läuft, ist es vielleicht sinnvoller, wenn die Anwender nur im Frontend wirken können und das Backend dem Admin vorbehalten bleibt. Läuft die Anwendung auf einem Internetserver ist es vielleicht besser, wenn gar keine Frontend-Module zur Verfügung stehen... Oder man findet irgend einen Mix...

@Tiggr:
Ich glaub, deine Gedanken gehen viel zu weit. Wir sind hier im Thread "Adressbuch". Was muss man mit den erfassten Adressen alles machen können? Man muss sie
a) anderen (CRM)-Modulen zur Verfügung stellen
b) am Bildschirm auflisten können
c) exportieren können
und schlussendlich auch
d) drucken können (Listen, Etiketten, Briefumschläge)

Es geht mir gar nicht darum, ganze Briefe oder gar komplexe Offerten oder was auch immer erstellen zu können. Aber ich denke, wenn man sich überlegt, was man mit den Adressdaten machen können sollte, kommt man automatisch auf obenstehende Funktionen. Ob es dann irgendwann mal ein Offert-Modul gibt, welches die Adressdatenbank mit einem Shopsystem oder was auch immer verbindet und Offerte druckt, ist im Moment gar nicht wichtig!

Und mal abgesehen davon: Bis auf Punkt d) kann die Mitgliederverwaltung vom TL-Grundsystem ja schon alles (export bin ich mir jetzt grad nicht sicher). Also warum sich dann den Aufwand machen und nochmals das gleiche programmieren?

[Tiggr]

Hallo!

Ich glaub, deine Gedanken gehen viel zu weit. Wir sind hier im Thread "Adressbuch".

Da muss ich dich leider verbessern, der Thread heißt: "CRM Extension Teil 1:Adressbuch", es geht also um einen Bestandteil eines CRM, um die Kontaktverwaltung innerhalb eines CRMs!

a) anderen (CRM)-Modulen zur Verfügung stellen
b) am Bildschirm auflisten können
c) exportieren können

Full Ack. Allerdings fehlt da noch:

x) Nach verschiedenen Kriterien selektiert werden.

Es muss irgendwie möglich sein, Kontakte nach Kriterien (Klasse A-Mandant, Rechtsform GmbH, Spieler der 1. Liga, hat laufende Projekte, ...) zu selektieren!

d) drucken können (Listen, Etiketten, Briefumschläge)

Ich glaub das siehst du zu eng! Einfache Listen kann ich auch mit Excel! ;-) Dafür braucht es kein CRM! Und Freshlifepages will ja expliziet ein CRM programmieren! tolles aber großes Vorhaben! Und heutzutage verschickt man nicht mehr einen Brief mit einem Adressaufkleber, mit der Anrede "Sehr geehrte Damen und Herren", sondern man personalisiert den ganzen Brief! Also "Guten Tag Herr Maier!"

Einfache Etikette, Listen und Briefumschläge bekommt man vielleicht sogar mit geschicktem CSS und HTML hin, auf alle Fälle noch per PDF. Abersoll ein Firmenloge mit auf den Aufkleber, Absenderzeile, dann wird es schwierig. Elektronische Briefmarke? Komplette Briefe?

Ich bleib dabei: Erstmal eine saubere Infrastruktur schaffen, Kontaktverwaltung und gute Selektionsmöglichkeiten, und wenn das läuft, dann gerne als Krönung auch noch Printausgabe!

Für meinen Brötchengeber hab ich auch ein CRM ausgewählt, das das alles kann, aber da kostet der Arbeitsplatz 900 Euro, und M$ programmiert das. Das TL-CRM ist im Moment ein 1-Mann-Learning-by-Doing-Projekt - da will ich realistisch bleiben mit den Wünschen!

Schau dich mal bei OpenSource-CRM-Systemen um. Viele gibt es nicht, und dann schau mal, wie viele auch nur einen Etikettendruck beherrschen!

Tschüss
Marcus (aka Tiggr)

[tinoo]

Hiiiii

Da muss ich dich leider verbessern, der Thread heißt: "CRM Extension Teil 1:Adressbuch", es geht also um einen Bestandteil eines CRM, um die Kontaktverwaltung innerhalb eines CRMs!

Jep, aber ich nehme an, Freshlifepages wird nicht sämtliche Funktionen in ein einziges Programm-Modul packen wollen. Wenn ich so ein grossen Projekt realisieren würde, würde ich mehrere kleine Programm-Module machen, die jeweils für die spezifischen Funktionen verantwortlich sind.

Full Ack. Allerdings fehlt da noch:
x) Nach verschiedenen Kriterien selektiert werden.
Es muss irgendwie möglich sein, Kontakte nach Kriterien (Klasse A-Mandant, Rechtsform GmbH, Spieler der 1. Liga, hat laufende Projekte, ...) zu selektieren!

Einverstanden. Aber genau das ist doch der Punkt, wo die selbstdefinierbaren Felder ins Spiel kommen. Es macht ja keinen Sinn, da irgendwelche fixen Vorgaben zu machen, wenn schlussendlich eh jeder andere Kritierien braucht.

Ich glaub das siehst du zu eng! Einfache Listen kann ich auch mit Excel! ;-)

Ja du! In meiner Funktion als Präsident von einem Verein bekomm ich immer wieder Excel-Files zugestellt. Du kannst dir gar nicht vorstellen, wozu man Excel alles missbrauchen kann...

Einfache Etikette, Listen und Briefumschläge bekommt man vielleicht sogar mit geschicktem CSS und HTML hin, auf alle Fälle noch per PDF. Abersoll ein Firmenloge mit auf den Aufkleber, Absenderzeile, dann wird es schwierig. Elektronische Briefmarke? Komplette Briefe?

Schlag dir mal die kompletten Briefe aus dem Kopf. Das hat nichts mit einem Adressbuch zu tun, sondern ist eine Funktion, die von einem anderen Programmteil übernommen werden muss.

Wenn man Templates zum Druck von Websiten hinbekommt und dort Logo usw. hinzufügen kann, sollte es ja theoretisch kein Problem sein, dies auch für eine Adressliste hinzubekommen. Die Beschriftung von Etiketten kann insofern schwierig werden, weil es Formate wie Sand am Meer gibt. Da wäre der direkte Adressdruck auf Briefumschläge wohl einfach zu lösen...

Ich bleib dabei: Erstmal eine saubere Infrastruktur schaffen, Kontaktverwaltung und gute Selektionsmöglichkeiten, und wenn das läuft, dann gerne als Krönung auch noch Printausgabe!

Ich bin schon froh, dass sich überhaupt jemand dem Thema annimmt und verstehe mich einfach als Ideen-Lieferant

Schau dich mal bei OpenSource-CRM-Systemen um. Viele gibt es nicht, und dann schau mal, wie viele auch nur einen Etikettendruck beherrschen!

Darauf will ich ja hinaus. Wenn man etwas Neues macht, sollte es sich doch von bestehenden Produkten abheben / unterscheiden! Wir brauchen nicht ständig das Rad neu zu erfinden...

[Tiggr]

Hiho!

Jep, aber ich nehme an, Freshlifepages wird nicht sämtliche Funktionen in ein einziges Programm-Modul packen wollen. Wenn ich so ein grossen Projekt realisieren würde, würde ich mehrere kleine Programm-Module machen, die jeweils für die spezifischen Funktionen verantwortlich sind.

Jupp, sehe ich auch so! Ich schreib es halt hier rein, ob es im Adressbuch realisiert wird, oder mal ein eigenständiges Modul "Seriendokumente" gibt, ist nicht meine Entscheidung. Freshlifepages kann das alles entscheiden. Und wenn er sagt, wir beide reden nur Stuss, er macht das anders, dann ist es auch ok!

Einverstanden. Aber genau das ist doch der Punkt, wo die selbstdefinierbaren Felder ins Spiel kommen. Es macht ja keinen Sinn, da irgendwelche fixen Vorgaben zu machen, wenn schlussendlich eh jeder andere Kritierien braucht.

Jupp, full ack! Da stehen wir komplett bei einander!

Ja du! In meiner Funktion als Präsident von einem Verein bekomm ich immer wieder Excel-Files zugestellt. Du kannst dir gar nicht vorstellen, wozu man Excel alles missbrauchen kann...

Doch, ich kann es mir vorstellen! Ich sag nur Wirtschaftsprüfer, Controller und Consulting! Ich betreue da so ca. 100 Stück! Ich wurde ernsthaft gefragt, wozu man ein CRM bräuchte, das könnte man doch alles in Excel machen!

Schlag dir mal die kompletten Briefe aus dem Kopf. Das hat nichts mit einem Adressbuch zu tun, sondern ist eine Funktion, die von einem anderen Programmteil übernommen werden muss.

Sie muss da hin, wo sie funktional und vom Workflow gut passt - wohin genau wird sich zeigen. Aber was es nicht geben sollte sind mehrere Seriendokumenterzeugungsstellen. Eine für Briefe, eine für Etiketten, eine für Listen. Womöglich noch mit inkonsistenten Funktionen und Arbeitsweisen (leider schon so gesehen)!

Eigentlich ist der Ablauf doch:

- Ich pflege meine Daten
- Ich selektiere über x Kriterien eine Zielgruppe
- Ich arbeite mit dieser Menge an Kontakten, erstelle Serienbriefe, Etiketten, Namensschilder, Listen, ect.

Wenn man Templates zum Druck von Websiten hinbekommt und dort Logo usw. hinzufügen kann, sollte es ja theoretisch kein Problem sein, dies auch für eine Adressliste hinzubekommen. Die Beschriftung von Etiketten kann insofern schwierig werden, weil es Formate wie Sand am Meer gibt. Da wäre der direkte Adressdruck auf Briefumschläge wohl einfach zu lösen...

Bedrucken von Briefumschlägen ist mir in der realen Bürowelt eher selten vor gekommen. Aus den verschiedensten Gründen. Entweder Etiketten, oder echte Serienbriefe. Serienbrief aus HTML ist jedenfalls spannend, ich glaube das gibt CSS noch nicht ganz her, zumindest nicht das, was die Browser umsetzen - schade!

Ich bin schon froh, dass sich überhaupt jemand dem Thema annimmt und verstehe mich einfach als Ideen-Lieferant

Genau so geht es mir auch! Ich werf einfach mal alles in die Threads, versuche es halbwegs geordnet zu halten, und Freshlifepages soll sich die Rosinen raus picken.

Wenn die Grundstruktur fertig ist, schau ich mir aber vielleicht selber an, ob und wie man das an die Eventverwaltung von TL anhängen könnte!

Darauf will ich ja hinaus. Wenn man etwas Neues macht, sollte es sich doch von bestehenden Produkten abheben / unterscheiden! Wir brauchen nicht ständig das Rad neu zu erfinden...

Allein schon ein CRM zu haben wäre toll - es gibt an Open Source ganz ehrlich nichts gescheites! Und die, die sich in ein CMS integrieren tuen das meist bei Joomla, Drupal oder Typo3. Und da sind die meisten auch noch eher rudimentär! :-( Egal was hier raus kommt, es kann nur ein Gewinn sein!

Tschüss
Marcus (aka Tiggr)

[tinoo]

Langer Rede kurzer Sinn, ich habe mich dazu entschieden eine eigene Adressbuch Extension zu programmieren.

Ich würd sagen: Lassen wir Freshlifepages einfach mal arbeiten und schauen, was dabei herauskommt

[deerwood]

Hi Freshlifepages,

@deerwood
Mit options_callback habe ich es ja vorher gehabt, nur dann wird ja der Wert der im Dropdown angezeigt wird in die DB gespeichert und ich möchte ja die id des Datensatzes, des in diesem Fall, Mitarbeiteres in dei DB speichern.
Gibt es dafür eine Möglichkeit? Oder lässt sich das irgendwie mit options_callback realisieren?

options_callback KANN den Anzeigewert auch in die DB speichern, wenn Dein Callback ein nicht assoziatives Array zurückliefert (also mit durchgehed numerischen, lückenlosen Keys beginnend bei 0). Lieferst Du aber ein assoziatives Array zurück, dann wird der KEY in die DB gespeichert und der VALUE im Select angezeigt. Das mit Bedacht gewählte Beispiel für tl_content.form hätte Dir das auch gezeigt: das Feld ist in der DB INT(10), da passt also kein String rein, der Callback liefert ein assozitives Array zurück (tl_fom.id => tl_form.title . 'some_string'). Und wenn Du Dir mal ansiehst wie TL option_callbacks verarbeitet (in Controller.php etwa Zeilen 2050-2120) dann siehst Du, dass man da auch noch mehr haben kann (z.B. Option-Groups). Schade ist nur, dass das nirgendwo vernünftig dokumentiert ist, auch nicht im Entwickler-Handbuch, so dass man auf reverse Engineering angewiesen ist.

LG, Georg

[christian.kolb]

Stimmt du hast vollkommen Recht. Hätte mich auch stark gewundert, wenn TL für so eine doch sehr trivialie Problemstellung keine interne Lösung hätte.
Hinter die komplette Logik des Controller.php Teils bin ich noch nicht gestiegen, aber das kommt noch

Vielen Dank nochmal und Gruß
Freshlifepages