CRM Extension 2. Anlauf + Desktop Version

EDIT: Für alle die dieses Thema zum ersten Mal lesen:
Im Verlaufe des Themas hat sich einiges geändert, die Desktop App ist nicht mehr aktuell. Ihr könnt also getrost ab diesem Beitrag anfangen zu lesen.

Hallo Zusammen,

der eine oder andere hat vielleicht die CRM Extension Themen gelesen. Die Erweiterung hatte ich ja aus Zeitgründen verschoben, bzw. abgegeben. So weit ich weiß wird sie im Moment allerdings nicht weiterentwickelt.

Ich habe mich dazu entschieden die Arbeit daran wieder aufzunehmen. Allerdings mit einem anderen Ansatz.

Die Daten sollen alle in einer Contao Installation gehalten werden und auch über Contao angezeigt werden können. Die Pflege der Daten soll aber (vorerst) nur über eine Desktop Applikation geschehen. Die Verbindung zur Installation soll über SOAP erstellt werden.

Eigentlich wollte ich die Desktop Applikation für Windows mit C# (.NET 4.0) entwickeln. Da ich damit aber die Kollegen mit Mac und Linux ausschließen würde, denke ich darüber nach sie mit Java zu entwickeln.

Für den Anfang dachte ich daran folgende Elemente zu implementieren:

• Kunden (ID + Nummer)
• Adressbuch (Verbindung zu Kunden)
• Aufgaben
• Rechnungen
• Rechnungserinnerungen (Meldung über die Desktop App)

Die zentralen Fragen die sich jetzt stellen sind folgende:

• Habt ihr generell Interesse an einem solchen System? (gerade wenn die meisten wahrscheinlich bereits ein CRM im Betrieb haben)
• Mit welchem Betriebssystem arbeitet ihr? (Besteht Interesse an einer Java Version?)
• Würdet ihr das System testen? (Habe weder einen Mac noch Linux)

Freue mich über eure Meinungen und Vorschläge.

Gruß
Christian

Naja meiner Meinung nach gehört Java auch eher in die Server Welt :)

KnowHow-Technisch wäre ich mit Java zwar besser dran, aber GUI-Technisch kommt Java halt bei weitem nicht an .NET ran. Die haben einfach mehr und die besseren Components.

Die Frage ist, lassen sich die Components auch alle unter Mono ausführen und ist Mono bereits auf dem Stand von .Net 4.0. Ich hab noch nie mit Mono gearbeitet. Und gibt es Mono oder etwas ähnliches auch für Mac oder schießen wir die Mac User damit komplett ab? (Einfach ignorieren sollte man sie ja nicht :) )

Gruß
Christian

"WPF - no plans to implement"

Schon das erste richtig große Problem bei Mono gefunden. Es unterstützt kein WPF. Damit wären schonmal die Linux und Mac User gekickt.

Gruß
Christian

Warum braucht man bei einem CRM Swing? (geht ja auch mit AWT)
Wenn, dann schon gescheit.

Aber wir sind ein bisschen von der eigentlichen Fragestellung abgekommen.

• Generelles Interesse?
• Betriebssystem?
• Testing?

Gruß
Christian

Du weißt schon: Swing und AWT = Java ; Windows Forms und WPF = .NET :)

Gibt einige Components die es so nicht gibt, wie z.B: RibbonBar

Natürlich bracht man das nicht, aber wenn, dann möchte ich das schon gescheit (schön) machen ;)

Gruß
Christian

Das Interesse ist sicherlich da. Ich bin auch gerade an einem CRM dran (ohne Desktop-Anwendung), bin aber noch nicht sicher, ob ich sie kostenlos zur Verfügung stellen werde. Bei mir geht es jedoch nicht allzu schnell vorwärts.

Mal eine allg. Frage : Was verstehst Du/Ihr unter einem CRM ?
Ich verstehe sowas wie dies hier darunter : http://de.wikipedia.org/wiki/Custome..._CRM-Anwendung

Momentan sind die meisten Dinge eigentloch auch mit den vorhandenen Erweiterungen problemlos loesbar. (isotope & catalog)

Und vor allem : Wozu braucht man dann noch eine extra DesktopAnwendung ? Welchen Teil soll dann Contao noch bringen ? Wie soll die Kommunikation zw. den System erfolgen usw.

Grundsätzlich hätte ich Interesse an einem CRM für Contao. Sofern es nicht standalone wäre bzw. nur dem allg. Beziehungsmanagement dienen könnte, sondern ideal auch mit BE- u. FE-Benutzern/Mitgliedern korrespondieren. So ist es vermutlich auch gedacht, oder? Dann hätte es einen echten Mehrwert für Betreiber größerer kommerzieller Portale auf Basis von Contao. Ja, ich hatte mal in dem CRM-Thread gelesen, ist aber schon zu lange her, mich noch an Details zu erinnern.

Dein Ansatz bzgl. einer Desktop-Applikation ... weiß nicht recht, ob mich das begeistert. Bei den Entwicklern gängiger CRM-Lösungen geht die Reise eher weg von Desktop-Anwendungen. Auf der anderen Seite braucht es für sinnvolles Arbeiten mit einem CRM unbedingt eine gute Performance. Bedingt durch die Konzeption für einen ganz anderen Einsatzzweck kann man die Contao-Reaktionszeiten für ein CRM eigentlich knicken, auch ohne den Flaschenhals "Internetzugriff". Und vielleicht lassen sich mit einem Desktop-Programm Schnittstellen zu anderen Desktop-Applikationen einfacher bedienen.

Na ja, "Adressbuch" ist eine recht schlichte Umschreibung für die relativ komplexe Funktionalität, welche allein dieses Objekt bräuchte. Es müsste ja nicht nur auch die Relationen von Ansprechpartnern und deren Profilen enthalten, sondern auch mit einem komplexen Beziehungsmanagement verknüpfbar sein (Daten, Workflows, Dokumente und Personen). Termine und Ereignisse benötigen Filter und Trigger, die auch über anwenderdefinierte Felder erweitert werden können sollten. Von der Ereignishistorie bis hin zu automatisiertem Kontaktmanagement inkl. Wiedervorlagen hättest Du Dir im Hinblick auf ernstzunehmende CRM-Funktionen viel vorgenommen. Das Gute daran ist aber, dass bereits auf dem Weg dorthin diverse zugehörige fertiggestellte Module bereits sinnvolle Anwendung finden könnten.

Dass ein Contao-CRM jenseits der Interaktion zwischen Portalbetreiber und dessen Kunden/Interessenten in größerem Umfang eingesetzt würde, bezweifle ich eher. CRM-Daten sind ein hochsensibler Bereich und wichtiges Unternehmenskapital. Niemals würde ich die in einem Portal verwalten, in dem andere als die eigenen Leute Administrator-Rechte/Zugriff haben.

Als weitere Ideen-Vorlage lad Dir vielleicht mal das CRM "Julitec" runter. Ist proprietär, jedoch recht preisgünstig und die auf 500 Kunden limitierte Vollversion kostenlos erhältlich. Ich hab lockeren Kontakt mit der Anbieterfirma. Sie sind dort sehr freundlich und wenn man nett am Telefon fragt, mailen sie einem inoffiziell auch kostenlos einen Download-Link für eine Extension mit einigen sehr nützlichen Zusatzfunktionen, wie die Verknüpfung benutzerdefinierter Felder mit Formeln a la Excel. Jedenfalls haben sie das bei mir gemacht als Ergebnis eines interessanten Gesprächs.

Julitec gefällt mir als Anwender mit überschaubaren Bedürfnissen funktional sehr gut und verfügt zudem auch über Projektmanagement-Features und Workflows. Die Basisfunktionen sind wirklich intuitiv anzuwenden. Leider nicht Opensource, doch m. E. eine wesentlich interessantere Entwicklungsvorlage als bspw. vtiger - zwar ziemlich mächtig, aber mir viel zu aufgebläht und man konfiguriert sich fast blöde, bloß um es soweit abzuspecken, dass es sinnvoll einsetzbar wird. Der zu erwartende Customizing-Aufwand zählt bei CRM nunmal zu den wesentlichen Entscheidungskriterien für einen Einsatz.

Wie schon angedeutet, würde mich eine gut mit den sonstigen Features wie der Rechteverwaltung zusammenwirkende Contao-CRM Extension weniger universell als speziell mit der Zielrichtung auf Marketing und Kundenverwaltung größerer Portale interessieren. "Eierlegende Wollmilchsäue" gibt´s schon genug. Auf Schnickschnack wie selbstwählende Telefon-ToDo-Listen könnte ich gut verzichten. Email-Anbindung und Dokumentenverwaltung sollten aber schon sein.

Nun frag ich mich aber, warum Du das Rad neu erfinden willst, statt ein ausgereiftes bestehendes CRM gut in Contao zu integrieren. Erschlösse auch gleich einen weit größeren Interessentenkreis. Könnte vielleicht z. B. durchaus die Opensource-Lösung vtiger sein. Nach meinem Geschmack etwas oversized, aber ließe sich ja für den Zweck customizen. Oder auch ein erschwingliches kommerzielles wie Julitec.

Ich verwende Linux und WindowsXP, meine Tochter Apple. Kann´s noch nicht versprechen, wie ich zeitlich bestellt bin. Im Fall eines für mich interessanten Fortgangs Deines Projekts bin ich jedenfalls grundsätzlich bereit zum testen. Und auch zum Nachdenken. ;-)

Die Beschreibung entspricht dem was ich mir unter einem CRM vorstelle.

Es lässt sich tatsächlich das meiste mit Catalog und Co darstellen, diesen Weg bin ich auch zuerst gegangen (deshalb habe ich die CRM Extension auch nicht mehr weiterentwickelt).

Vielleicht hätte ich erst meine Vorstellung bzw. Anforderungen erklären sollen :)

Ich bin angestellter Fachinformatiker und habe mich Nebenberuflich zusätzlich Selbstständig gemacht. Mit meinem kleinen Unternehmen setzte ich Internetauftritte mit Contao um. Und für diese benötige ich ein CRM. Jedes CRM das es bereits gibt ist total oversized. Alles was ich benötige ist eine Kundenverwaltung (mit Adressen), eine ToDo Liste und eine Verwaltungen der Rechnungen die ich stelle. Ich arbeite nicht jeden Tag durchgehend für mein Unternehmen und logge mich dem entsprechend nicht täglich in ein CRM System ein. Trotzallem muss ich an wiederkehrende Rechnungen erinnert werden.

Wenn ich das CRM für eine Zielgruppe erstellen würde, dann wären es wohl die Freelancer und Freiberufler. Mit meinen beiden Berufen habe ich für das CRM nicht extrem viel Zeit und könnte das niemals so groß wie z.B. vtiger aufziehen. Abgesehen davon, dass man das nur machen kann wenn man es kommerziell vertreibt oder es in einer Gruppe entwickelt, wäre das wie schon gesagt total oversized.

Die Desktop App könnte im Autostart liegen und sich melden wenn eine Rechnung zu schreiben ist oder ein ToDo ausläuft. Man müsste sich nicht immer in das CRM bzw. Contao einloggen um Daten zu ändern, hätte sie aber zentral zur Hand auch wenn man unterwegs ist. Mit Extensions wie Catalog lässt sich viel machen, aber es lassen sich nicht alle Beziehungen darstellen, außerdem wird es ab einem bestimmten Grad doch kompliziert ein neues Element einzupflegen. Gerade wenn man z.B. eine Rechnung erstellt und diese einpflegen möchte (einloggen, Rechnung hochladen, neuen Eintrag anlegen). Mit einer Desktop App könnte man eine erstellte Rechnung per DragnDrop in die App ziehen, ein paar Daten eingeben und den Rest übernimmt die Applikation.
In einem vollständigen CRM übernimmt die Rechnungserstellung das CRM und startet womöglich noch mehrere Workflows oder einen E-Mail Versand.

Die CRM Extension wird nie an die bekannten CRM Systeme herankommen und das ist auch nicht das Ziel. Wer also nach einem solchen System für Contao sucht ist hier leider falsch. (Das hätte ich aber auch am Anfang sagen sollen) :)

Selbstverständlich kann das System wachsen und wenn ich die Zeit finde werde ich auch gerne Wünsche der Community in die Extension einfließen lassen. Wenn die Extension mal größer werden sollte und jemand diese kommerziell weiterentwickeln möchte, wäre ich auch sicher bereit den Quellcode für eine kleine Spende weiterzugeben ;)

Aber das ist Zukunftsmusik.

Wie gesagt das System wird, vorallem am Anfang, klein sein und höchstwahrscheinlich für die meisten Poweruser uninteressant sein. Trotzallem würde mich auch deren Meinung interessieren. :)

Das ganze soll halt so klein und schnell zu bedienen sein wie möglich. So könnte ich mir die GUI vorstellen:

http://www.contao-community.de/attac...3&d=1306789011

Deshalb auch WPF, mit Java ist sowas gar nicht möglich (außer mit Flamingo, aber auch das kommt bei weitem nicht daran)

Gruß
Christian

Ich finde die Idee prima.

Mal zurück zu der Frage nach der Entwicklungsumgebung ... Mir fällt da spontan Titanium ein. Eine tolle kleine Software die sicher einige kennen ist schon damit entwickelt worden: Wunderlist!

Komplett plattformunabhängig ;)

Dann solltest Du Dir für die Agenturkunden tatsächlich mal Julitec runterladen und installieren. Hindert Dich ja nicht daran, uns trotzdem eine schnuckelige Contao-Extension zu stricken.

Ist wie gesagt in der kostenlosen Version auf die Verwaltung von max. 500 Kunden beschränkt. Doch mehr wirst Du mit Deiner nebenberuflichen Agentur wohl vorläufig nicht haben. Unterhalb dieser Kunden können natürlich beliebig viele Ansprechpartner angelegt werden. Rechnungsverwaltung ist vorhanden und alles andere angesprochene ebenfalls sehr ausgereift und praxisgerecht. Da braucht nichts angepasst werden wie bei vtiger. Installieren und gleich mit der Stammdateneingabe loslegen. Oder per CSV-Import.

Hab natürlich nix von der Produktempfehlung, arbeite halt nur sehr gerne mit diesem nach meinem Geschmack echt tollen Programm.

@ku-ma-122:
Titanium sieht interessant aus, aber gerade in den Programmiersprachen des Desktop Teils habe ich nur wenig Erfahrung.
PS: Welches Betriebssystem hast du denn?

@soweit_ok:
Das System sieht ebenfalls interssant aus (abgesehen von der GUI :) ). Aber ich hätte schon gerne eine Verbindung zu Contao. Contao soll nicht nur eine Plattform zum Speichern der Daten, sondern eben auch zur Präsentation sein. So dass sich Kunden z.B. einloggen können und ihre Projekte betrachten können (Wenn Projekte auch implementiert sind).

Eine weitere Idee:
Die Desktop Applikation wird gar nicht zur Datenpflege genutzt, sondern als Schnittstelle zu anderen CRM Systemen. Das diese die Daten exportieren und über die App an Contao übertragen. Da kommt es natürlich stark darauf an, welches CRM viel genutzt wird und wie groß das Interesse daran ist, die Daten in Contao zu präsentieren.

Gruß
Christian

ist die Entwicklung nicht plattformübergreifend auch mit Adobe Air denkbar?

@stefan-at-work
Ja bestimmt, aber genauso wie mit Titanium sind es auch dort die "falschen" Programmiersprachen.

Gruß
Christian

Ja, eben darauf wollte ich hinaus ... Contao als Schnittstelle zum CRM und Präsentationsschicht zu verwenden. Das Rad von Grund auf innerhalb Contao neu zu erfinden, böte zwar schneller einige viell. auch zu anderen Zwecken verwendbare Funktionalitäten, würde andererseits womöglich aber recht lange dauern, bis mal was herauskäme, das die Bezeichnung "CRM" verdient.

Wo die Datenhaltung stattfiinden sollte bzw. wie sie verteilt wäre und welche Vor-/Nachteile eine zumindest teilweise redundante Datenhaltung mit Synchronisation böte, respektive das Datenmodell der Anbindung, dass sollte man m. E. zunächst lediglich als Grobkonzept dargestellt werden. Wobei man ja in dieser Phase noch alternative Modelle entwerfen und vergleichen kann.

Falls Du klären möchtest, inwieweit bei Julitec Interesse an einer Contao-Anbindung besteht, hier die Kontaktdaten:
Nico Ardelean, Kundenbetreuung Julitec GmbH, Fon +49 9131 97911-10, ardelean@julitec.de

Der vermittelt Dir ggf. auch Ansprechpartner unter den zuständigen Entwicklern, um die techn. Machbarkeit und API´s zu besprechen.

Ansonsten finde ich OpenSource CRM wie vtiger durchaus überlegenswert, denn die Customizing-Möglichkeiten sind da eindeutig besser und es sollte so eigentlich gut gelingen, ein für die Contao-Integration gut passendes praxisgerechtes Paket zu schnüren. Kommerzielle Software böte widerum über den Hersteller Kontakt zu einer Kundenbasis, die nicht erst kompliziert überredet werden bräuchte, sich auch mit Inkaufnahme von Kosten für eine solche Anbindung zu interessieren. Deine Idee geistert mir seit Jahren immer mal wieder durch den Kopf. Für kleine bis mittlere Budgets ist sowas bis heute meines Wissens nämlich noch nicht zu haben. Und für große Budgets könntest Du dann gleich mal die Eignung des Database Abstraction Layers von Contao auch für Oracle testen. :D Hätte ich immer noch gute Kontakte, war dort lange als PM tätig. Aber das wird nix, denn die verhökern lieber ihr eigenes Bundle ("Oracle CRM" und "Oracle Portal").

Na ja, die Idee hatte ich also auch schon - freilich ohne Priorität, denn in anderen Projekten sah und sehe ich bislang letztlich interessantere finanzielle Potenziale. Wollte ich jede vermeintlich brauchbare meiner Ideen realisieren, müsste ich mindestens 500 Jahre leben.

@stefan-at-work

Noch nie davon gehört, hab eben mal die Webseite besucht. Klingt auf den ersten Blick nicht uninteressant, auch unabhängig von dieser Contao Erweiterungsidee. Hast Du schon Erfahrungen damit gesammelt bzw. konkrete Vorhaben damit realisiert?

@soweit_ok
Erstmal vielen Dank für deine Anregungen, aber das ist mir schon wieder zu groß.
Eine Schnittstelle zu einem bestehenden CRM (sei es vTiger, Julitec oder sonst eins) zu realisieren, bedeutet es so vollständig wie möglich umzusetzen. Dafür habe ich allerdings keine Zeit. Ich werde mir die Zeit dazu nehmen meine Anforderungen umzusetzten und ggf. die, die aus der Community kommen. Aber mehr ist nicht drin. Selbstverständlich hätte es sehr viele Vorteile an ein bestehendes System anzukoppeln, aber dazu habe ich schlicht und einfach nicht die Zeit.

Ein Datenmodell werde ich auf jeden Fall erstellen. Dieses könnte ich hier gerne zeigen und diejenigen die sich für das Projekt interssieren könnten Vorschläge für Änderungen machen.

Ich habe so den Eindruck, dass MAC User Contao im Unternehmen einsetzen. Diese Gruppe wird höchstwahrscheinlich bereits ein CRM im Einsatz haben. Liege ich damit richtig? Bzw. gibt es MAC User mit Interesse an dem CRM?

Das CRM wird auf jeden Fall aus zwei Teilen bestehen: Contao Modul + Desktop App. Weshalb ich kein bestehendes CRM anbinden möchte habe ich ja nun schon ausführlich beschrieben :) .

Die Entscheidung die noch aussteht ist: Java oder .NET?
Für Java spricht eigentlich nur die Plattformunabhängikeit. Die spielt allerdings auch nur eine Rolle wenn auch User außerhalb von Windows an dem CRM interesse hätten.

Deshalb nochmal die Fragen vom Anfang:

• Welches Betriebssystem?
• Interesse?

Gruß
Christian

AspectJ/Java <-

Also ich bin definitiv gegen .NET. Ich benutze einfach kein Windows mehr ( ausser wenn ich was im IE testen muss :) ) Mit Mono hätte ich aber auch kein Problem. Java fänd ich persönlich noch am besten. Ich denke da gibts auch noch ein paar Entwickler mehr als bei .NET. Was Spricht eigentlich gegen C++? Dort gibts auch noch QT

Zitat:

---

Zitat von smung0r

Also ich bin definitiv gegen .NET. Ich benutze einfach kein Windows mehr ( ausser wenn ich was im IE testen muss :) ) Mit Mono hätte ich aber auch kein Problem. Java fänd ich persönlich noch am besten. Ich denke da gibts auch noch ein paar Entwickler mehr als bei .NET. Was Spricht eigentlich gegen C++? Dort gibts auch noch QT

---

Und wo ist der Unterschied .Net zu Mono? Das eine ist eine Implementierung des Anderen für Nicht-Windows-Systeme... (Um mal klugzuscheißen :D)
Ich halte .Net für eine gute Basis.

Grundsätzlich würde ich aber empfehlen erstmal mit der Arbeit am CRM zu beginnen (Oder ein bestehendes System zu integrieren) und dann erst mit der Desktop-Anwendung zu beginnen. Gerade wenn ein CRM neu entwickelt werden soll, dürfte das schon genug Zeit in Anspruch nehmen...

@backbone:
Ich versteh ehrlich gesagt nicht ganz wozu AspectJ gut sein soll und was für einen Mehrwert es in dem System hätte.

@smung0r:
Jetzt haben wir bald alle Programmiersprachen durch :) Abgesehen von Python habe ich auch bereits mit jeder etwas gemacht, aber wirklich gut beherrschen tue ich (im Desktop Bereich) Java und C#. Auch bei C++ hätte ich nicht die nötige Erfahrung, dass am Ende ein schönes System dabei heraus kommt. Qt ist zwar eine geniale Bibiotek, aber meiner Meinung nach leider auf einem sterbenden Ast (aber das ist wieder ein anderes Thema)

@Bandyt:
Mono ist tatsächlich nicht viel anderst als .NET, nur hinkt es leider hinterher und kann nicht mit WPF umgehen. Wenn ich .NET einsetzte, dann auf jeden Fall mit WPF.
Was meinst du mit "Der Arbeit am CRM beginnen"? Zu Beginn wird Contao erst einmal als Datenablage herhalten, das heißt die Arbeit am CRM wäre die Datenmodellierung und die Arbeit das Datenmodell nach Contao zu bringen. Ein Teil davon habe ich bereits, da ich ja schon einmal ein CRM im Contao gestartet habe. Das ich kein bestehendes System integrieren werde habe ich schon oft genug geschrieben.

@alle drei:
Keiner von euch hat geschrieben welches Betriebsystem er nutzt, könntet ihr mir das noch schreiben :)

@all:
Wer hätte an der Schnittstellen-Funktion des CRM interesse? Also daran, Teilmengen aus einem anderen CRM in Contao zu übertragen und diese dort zu präsentieren? Und wenn ja, mit welchem System?

Gruß
Christian

<-- Linux
<-- kann Java programmieren

wäre vielleicht nicht schlecht ne Umfrage zu starten. Geht das hier im Forum?

Zitat:

---

Zitat von smung0r

wäre vielleicht nicht schlecht ne Umfrage zu starten. Geht das hier im Forum?

---

Ja, kann man machen.

@christian.kolb

Also ich finde, die Wahl der Entwicklungsumgebung sollte sich an den Implementierungsanforderungen orientieren und nicht umgekehrt. Sofern nicht von Entwicklerseite her von vornherein eine Festlegung auf bestimmte Sprachen/Tools gegeben ist. Ist diese Festlegung an ein Betriebssystem (Windows) gebunden, wozu dann überhaupt etwas anderes diskutieren.

Zunächst brachtest Du Plattformunabhängigkeit in die Diskussion, beharrst dann aber auf .net. Auf den Vorschlag von Mono als Alternative brachtest Du den Einwand, es könne nicht mit WPF umgehen. Das stimmt, jedoch ist stattdessen das WPF-ähnliche Silverlight Framework verfügbar. Mag sein, dass es derzeit nicht an WPF heranreicht - kann ich nicht beurteilen, weil ich beides nicht kenne. Jedenfalls dient es lediglich zur Entwicklung der Benutzeroberfläche und wird wohl beides für eine brauchbare reichen. Sorry, das empfinde ich als eine am Zweck eines CRM vorbeigedachte Gewichtung. Obgleich es nie mein Schwerpunkt war, hatte ich schon ein paar Mal das "Vergnügen", das Bid-Management für große CRM-Projekte übernehmen zu müssen. Schwerpunkt war dabei stets die Anpassbarkeit der Datenstrukturen des Systems an die Kundenanforderungen - über Benutzeroberflächen wurde nichtmal gesprochen.

Wenn Du also ein eingeschworener Windows-Entwickler bist, dann mach es doch so. Deine Desktopanwendung muss doch garnicht plattformunabhängig sein, da die meisten Unternehmen eh Windows-Clients einsetzen und Linux nur serverseitig. Und Mac kannst Du dafür ruhig außen vor lassen, wen interessiert das schon für ein CRM. Und letzlich kann man Dein Desktopprogramm auch unter Linux und OS X in einer VM benutzen.

Den zweiten Widerspruch brachtest Du mit der Frage auf´s Tapez, ob es als eigenständiges CRM fungieren sollte oder als Schnittstelle zu einem bereits bestehenden. Vorschläge dazu hast Du anschließend damit abgebügelt, aus Zeitgründen auf keinen Fall auf ein bestehendes aufzusetzen. Und heute fragest Du schon wieder "Wer hätte an der Schnittstellen-Funktion des CRM interesse? Also daran, Teilmengen aus einem anderen CRM in Contao zu übertragen und diese dort zu präsentieren? Und wenn ja, mit welchem System?".

Sorry, das verstehe ich nicht. Zunächst mal geht´s ja um den Entwurf des Datenmodells. Und das geschieht entweder mit Fokus auf zumindest für die Synchronisation Fremdsystem-Kompatibilität oder halt nicht. Vor dem Datenmodell steht m. E. außerdem erstmal der Entwurf des Use-Case.

Nach meinem Eindruck wärest Du gut beraten, vorgenannte grundlegende Aspekte erstmal im Sinne einer Vorgabe zu überdenken. Dann kann man sich über die konkreten Kernanforderungen unterhalten. Oder eben umgekehrt und eine Kompatibilitätsprüfung erst nachrangig. Die ist immerhin keine Kleinigkeit, denn selbst bei Open Source Systemen ist das Datenmodell zumeist nicht so dokumentiert, ohne aufwändiges Reengineering durchzublicken, wie man darauf aufsetzen oder es auch nur per Schnittstelle bedienen kann. Gerade standardisierte Schnittstellen sind, wenn überhaupt, meist noch recht kümmerlich vorhanden. So kann man z. B. bei Julitec meines Wissens bislang nur Rechnungsdaten nach Excel exportieren, ansonsten Stamm-, aber keine Bewegungsdaten im/exportieren und eine Synchronisation ist nur mit Outlook umgesetzt. Und ich fürchte, bei anderen CRM sieht es damit nicht viel anders aus.

Ich werde den Thread mal weiterverfolgen. Weil er mir allerdings momentan noch zu sehr in die Breite läuft, klinke mich jedoch am besten an dieser Stelle erstmal solange wieder aus, bis ein konkretes Grobkonzept vorliegt.

@soweit_ok
Vielleicht habe ich mich zu schammig ausgedrückt, ich versuch es noch einmal:

Ich beherrsche zwar einige Programmiersprachen, aber nur ein paar wenige richtig gut. In der Desktop Welt sind das .NET(C#) und Java. Die Wahl zwischen den beiden Programmiersprache ist einzig und allein abhängig von der Betriebssystemnutztung derjedenigen, die das System einsetzten wollen. Deshalb auch die Frage nach der Interesse und des Betriebssystems.

Wenn es hauptsächlich Interesse in der Windows Welt gibt, dann werde ich mit .NET entwickeln. Da ich aber nicht auf dem alten WinForms System aufsetzten werde, bedeutet dies allerdings, dass Linux und Mac User das System nur über eine Windows VM zum laufen bekommen werden (ich bezweifel stark das jemand für so ein kleines System extra eine VM aufsetzten wird). Falls es aber Interesse von Linux und Mac Usern geben sollte werde ich mit Java entwickeln, würde aber die Hilfe von denen zum testen der App benötigen. Vielleicht ist Silverlight (Moonlight) eine Alternative, aber auch damit habe ich zu wenig Erfahrung.

Zitat:

---

Den zweiten Widerspruch brachtest Du mit der Frage auf´s Tapez, ob es als eigenständiges CRM fungieren sollte oder als Schnittstelle zu einem bereits bestehenden.

---

Es gibt dort kein entweder oder. Es soll an sich ein eigenständiges kleines CRM sein, dessen Daten in Contao abgelegt werden und dessen Datenpflege über die Desktop App geregelt werden soll. Contao dient hier zum einen als "Datenbank" und zum anderen dazu, über Module die CRM Daten zu veröffentlichen. Zusätzlich könnte das CRM als Schnittstelle zu anderen CRM Systemen dienen. Das bedeutet nicht, dass das CRM auf den Daten oder dem System aufsetzt, sondern lediglich, dass es die Daten, die sowohl in meinem CRM als auch im "verbundenen" CRM vorhanden sind, in Richtung Contao exportiert werden könnten. Dies wäre allerdings nur eine Möglichkeit und es handelt sich dabei lediglich um die Teilmenge der Daten. Selbstverständlich müsste es dort eine extra Anbindung an jedes System geben. Wie gesagt, eine Option und nur wenn genügend Interesse an einer Anbindung bestehen würde.

Falls es tatsächlich keine Schnittstellen für verschiedene Systeme geben sollte, dann wird es an diese eben keine Anbindung geben.

Du denkst bei allen Anforderungen viel zu groß. Es soll ein kleines System sein, welches langsam wachsen wird. Es ist auch gut möglich, dass es für die meisten viel zu klein wäre und sie doch lieber auf ein bereits bewährtes CRM setzen möchten. Aber das ist genau das, was ich hier heraushören möchte.

Gruß
Christian

Zitat:

---

Es ist auch gut möglich, dass es für die meisten viel zu klein wäre und sie doch lieber auf ein bereits bewährtes CRM setzen möchten. Aber das ist genau das, was ich hier heraushören möchte.

---

Ich denke, das kann man schlecht verallgemeinern und kann nur jeder für sich entscheiden. Für meinen Bedarf bzgl. der allg. Kundenakquise und -betreuung wäre alles was Du in überschaubarem Zeitraum entwickeln könntest, viel zu klein.

Was nicht bedeutet, ich hätte keine Verwendung für eine auf Contao zugeschnittene Spezialanwendung. Was ich persönlich prima innerhalb eines Contao-Portals brauchen könnte, wäre eine auf den Kundenstammdaten aufsetzende Kommunikations- u. Vorgangsverwaltungslösung zum strukturierten Management aller diesbezüglich anfallenden Aufgaben. So wäre jeder Kunde inkl. der ihm zugeordneten Ansprechpartner und Aufgaben innerhalb des Gesamtprojekts praktisch ein Mini-Projekt. Idealerweise wären bereits vorhandene Module wie Helpdesk oder BE-Aufgaben sowie Mailversand damit verknüpfbar. Mit Filtern ließen sich Workflows generieren, z. B. kundenbezogene Wiedervorlagen/Terminkalender/Statusberichte. Die Rechteverwaltung sollte insoweit erweitert werden, dass Portaladmins konfigurieren können, welche Informationen auch zur Kundenseite hin transparent sein sollen.

Nee, ich glaube nicht, dass ich zu groß denke. Sondern praxisorientiert im Rahmen meines persönlichen Bedarfs. Der kann natürlich bei jedem CRM-Nutzer anders gelagert sein, doch wie die Bezeichnung Kundenbeziehungsmanagement schon ausdrückt, liegt der Fokus wohl kaum auf banalem Banner-Management oder einer minimal erweiterten Mitgliederverwaltung für Sportvereine etc., sondern auf dem Handling einer größeren Kundenbasis, die jeweils auch nicht nur 5 Euro monatl. einbringen. Wenn die Erweiterung das nicht leistet, fände ich den Begriff CRM nicht zutreffend und wir reden nicht über dieselbe Sache. Sooo komplex wie Standard CRM ist das ja auch garnicht, sondern eher für die ganz spezielle Anforderung der Portalkundenverwaltung. Zumindest hatte ich Deinen Plan als spezialisierte Anwendung in dieser oder ähnlicher Art verstanden. Ebenso wäre bspw. auch eine dezentrale Agenturlösung zur Verwaltung von Contao-Projekten vorstellbar. Deshalb schrieb ich ja auch, erstmal sollten Use Cases entworfen werden. Wie auch immer die dann aussehen könnten, ohne die Möglichkeit von Workflows und Vorgangsverfolgung wäre es kein CRM, sondern bloß eine Stammdatenverwaltung. Wenn wir uns darüber einig sind, wäre jedenfalls sicher, dass wir uns alle über dieselbe Sache unterhalten.

Logisch, dass Du Dich für ein neben-nebenberufliches Vorhaben möglichst nicht extra in eine neue Programmiersprache und/oder neue Frameworks einarbeiten willst. Ist ja auch okay, wenn das die Vorgabe ist. Nur ist dann eben auch eine darauf bezogene Diskussion überflüssig.

Zitat:

---

Sondern praxisorientiert im Rahmen meines persönlichen Bedarfs.

---

Entwickel ich etwa für dich? :D

Workflows und ähnliches wären bestimmt interessante Erweiterungen für ein CRM innerhalb von Contao, aber diese kommen sicher erst später (wenn überhaupt). Zuerst wird es sicher erst einmal eine Stammdatenhaltung mit bestimmten Optionen sein. Ob man das dann CRM nennen kann, ist Ansichtssache. Hast du einen besseren Titel? Bin offen für alles :)

Zitat:

---

Logisch, dass Du Dich für ein neben-nebenberufliches Vorhaben möglichst nicht extra in eine neue Programmiersprache und/oder neue Frameworks einarbeiten willst. Ist ja auch okay, wenn das die Vorgabe ist. Nur ist dann eben auch eine darauf bezogene Diskussion überflüssig.

---

Darüber habe ich nie eine Diskussion gestartet. Die einzige Frage die ich gestellt habe, war die nach dem Betriebssystem und nach der Interesse. Frameworks standen doch nie zur Debatte ;)

Deshalb weiter die einfachen Fragen:

• Betriebssystem?
• Interesse?

Gruß
Christian

Hihi, Du bist ja lustig. :) Nö, natürlich entwickelst Du nicht für mich. Den "persönlichen Bedarf" zu nennen, bezog sich bloß auf Deine Frage nach dem Interesse, welches sich ja eben meist daran orientiert. Und aus der Summe aller derartigen Nennungen kannst Du eine Gewichtung ableiten als Entscheidungshilfe, was Du implementieren willst. Also als Beitrag zu Deiner Recherche, welche unterschiedlichen Wünsche die User mit einer solchen Erweiterung gern abgedeckt sehen würden. Schließlich erwarte und schrieb ich nicht, dass dies speziell meine sein müssen.

Was die Namensgebung angeht, ich finde immer die Bezeichnung am besten, welche die Leistungsmerkmale der Erweiterung am zutreffendsten umschreibt. Nicht als Wertung gemeint, doch mit einem CRM hat Deine Vorstellung zumindest der ersten Ausbaustufe vielleicht noch nicht so wahnsinnig viel gemein und "Kundenverwaltung" oder auch "Kundenvorgangsverwaltung" würde es womöglich eher treffen. Aber warten wir doch erstmal ab, bis Dein konkreter Projektplan und das Grobkonzept vorliegen. Nur - da Du Dein Vorhaben im Thread nunmal als CRM bezeichnetest, ist es nicht verwunderlich, wenn typische CRM-Features angesprochen werden.

Also grundsätzlich besteht Interesse!
System Linux (Ubuntu 10.04),
derzeitiges CRM Julitec, da Kundendaten bei uns möglichst nicht kpl. ins Internet sollen.

Da größere Firmen schon Probleme mit Datensicherheit haben (egal aus welchem Grund), aber die "Begehrlichkeit" an solchen Daten nimmt einfach ungemein zu.
Und wir möchten einfach keinem Kunden erklären müssen, warum z.B. Bankdaten, oder auch nur e-Mails in falsche Hände geraten sind.


Wenn hier eine Möglichkeit besteht, z.B. aus Julitec, eine Schnittstelle zu den für den Kunden interessanten Informationen der Zusammenarbeit aktuell sehen zu können, OK, aber halt nicht alle Daten aus dem CRM.

Software ist NIE Fehlerfrei, Compiler sind es schon nicht. Die vielen Adobe, Java und MS - Bugs der letzten zeit zeigen es.

Zitat:

---

Zitat von legalstuff

Also grundsätzlich besteht Interesse!
Da größere Firmen schon Probleme mit Datensicherheit haben (egal aus welchem Grund), aber die "Begehrlichkeit" an solchen Daten nimmt einfach ungemein zu.
Und wir möchten einfach keinem Kunden erklären müssen, warum z.B. Bankdaten, oder auch nur e-Mails in falsche Hände geraten sind.
Wenn hier eine Möglichkeit besteht, z.B. aus Julitec, eine Schnittstelle zu den für den Kunden interessanten Informationen der Zusammenarbeit aktuell sehen zu können, OK, aber halt nicht alle Daten aus dem CRM.

---

Exakt dasselbe schrieb ich weiter oben auch schon, doch offensichtlich sind die diesbezüglichen Einschätzungen wohl unterschiedlich. Wenn man bereits aus der Praxis kennt, wie extrem insbesondere große Unternehmen aus guten Gründen heute die Kontaktdaten ihrer Mitarbeiter nach außen abschirmen (ohne Vertrauenszertifikat bekommst du außer von ihm persönlich nicht mal die Emailadr. eines Ansprechpartners, geschweige denn eine Telnr.), kann man sich wahrscheinlich eher vorstellen, dass dieses Verhalten mehr und mehr auch auf den Mittelstand übergreift.

Macht deshalb das Vorhaben eines kleinen CRM für Contao nicht überflüssig. Ich bin halt nur davon überzeugt, dass Kunden in der Onlinedatenbank überwiegend nur öffentlich unbedenkliche Daten zur Speicherung freigeben würden. Speichert man ohne deren Wissen nicht explizit freigegebene, insbesondere Bewegungsdaten und das würde mal gehackt, dann wäre vermutlich der Teufel los. Praktisch alle nennenswerten CRM-Hersteller haben meines Wissens den Ansatz: Daten im Intranet und nur die Präsentation auch im Web, z. B. für den dezentralen autorisierten Zugriff auf segmentierte Datasets durch Vertriebsaußendienst und Kunden.

Julitec entwickelt übrigens gemäß einer Auskunft vom letzten Jahr ebenfalls ein Web-Interface mit dem genannten Konzept. Wie der akt. Stand dabei ist, weiß ich momentan nicht.

Bei Julitec habe ich nur ein Problem, es lässt sich problemlos unter Ubuntu installieren, doch leider (das WINE) findet es dann den OpenOffice-Writer nicht.

Ob es inzwischen mit Libre-Office zusammenarbeitet ist mir nicht bekannt.

Aber wir kommen hier vom Thema ab.

Ja, damit kämen wir wirklich zu weit vom Thema ab und sollten wir nicht weiter vertiefen. Nur eben noch soviel ...

Weil ich mir an WINE mitunter selber schon die Zähne ausbiss, verwende ich es schon lange nicht mehr. Bei mir läuft Julitec in einer Windows VM. Denn Du es so machst, könntest Du darin auch ein zusätzliches OpenOffice installieren, das seine Dateien in einem Shared Folder mit kompatiblen Filesystem ablegt, damit Du auch unter Linux darauf zugreifen kannst. Vielleicht gibt´s elegantere Lösungen, aber eine andere weiß ich nicht.

HI

Es wäre nett, wenn ihr derartige Diskussionen über andere Software vielleicht privat führen könnte.
Hier soll es nur um eine CRM-Extension für Contao gehen, was der Threadersteller ja nun auch schon einige Male kundgetan hat.

Sebastian

Zitat:

---

Zitat von Sebastian

HI
Es wäre nett, wenn ihr derartige Diskussionen über andere Software vielleicht privat führen könnte.
Hier soll es nur um eine CRM-Extension für Contao gehen, was der Threadersteller ja nun auch schon einige Male kundgetan hat.
Sebastian

---

Na klar, ist okay und hatten wir aus dem Grund auch schon selbst angemerkt, dass Probleme mit anderer Software vom Thema abkommen. Nehme ich als berechtigte Kritik natürlich an.

Davon mal abgesehen hatte der Threadersteller nach dem Wunsch nach Schnittstellen zu anderen CRM sowie konzeptionellen Aspekten gefragt. Nach meinem Verständnis zählte deshalb auch die vergleichende Betrachtung anderer Systeme jenseits des "heiligen" Contao ebenso zum Kontext wie die Debatte, welche Programmiersprachen und Frameworks am besten zur Entwicklung des lokalen Clients geeignet seien - gleichfalls "andere" Software. :eek: Aber lass uns das am besten nicht weiter vertiefen. Ich halte meine Klappe und gut ist. :)

Zitat:

---

Zitat von christian.kolb

@ku-ma-122:
Titanium sieht interessant aus, aber gerade in den Programmiersprachen des Desktop Teils habe ich nur wenig Erfahrung.
PS: Welches Betriebssystem hast du denn?

---

Ich benutze Mac OSX ;)

Ein bisschen schade, dass diese Disskussion so ausschweift. Hoffentlich lässt Du dich dadurch nicht von Deinem Vorhaben abbringen ...

@ku-ma-122:
Meine Motivation wäre nicht sehr hoch, wenn ich mich von sowas von meinem Vorhaben abbringen lassen würde ;)

Allerdings hat sich mein Vorhaben, unabhängig von den Beiträgen hier, ziemlich geändert. Ich habe auf der Contao-Konferenz mit einigen Leuten gesprochen und die meisten Meinungen waren die selben:
Desktop App eigentlich eine tolle Idee, aber verlangsamt natürlich die Entwicklung und birgt ein zusätzliches Sicherheitsrisiko. Außerdem hatten ein paar Mac User Probleme mit der Ribbon Navigation (da es nicht zum einheitlichen Design von Mac passt) was ich auch verstehen kann.

Die Desktop App wird jetzt also erst einmal wegfallen und die Bearbeitung der Inhalte wird doch in Contao stattfinden. Damit entspricht die Erweiterung doch eher der Idee der ersten Version. Abgesehen von einem wichtigen Detail. Ich habe vor das CRM viel mehr mit den bestehenden Contao Modulen zu verdrahten. Kunden => Mitglieder, Termine => Events, Tasks => Aufgaben (Todos) (vielleicht fällt euch auch noch mehr ein).

Ich bin momentan so richtig motiviert und werde deshalb gleich durchstarten. Das heißt ich bräuchte auch bald ein paar Tester die mich unterstützen. Jetzt bin ich ja mal auf Feedback und Resonanz gespannt :)

Gruß
Christian

Zitat:

---

Zitat von christian.kolb

@ku-ma-122:
Ich bin momentan so richtig motiviert und werde deshalb gleich durchstarten. Das heißt ich bräuchte auch bald ein paar Tester die mich unterstützen. Jetzt bin ich ja mal auf Feedback und Resonanz gespannt :)

Gruß
Christian

---

Da bin ich sofort dabei wenn es ums testen geht, da mir bisher die auch z.T. shcon genannten Programme nicht wirklich gefallen ;)

Ich würde mich ebenfalls gern zum testen anbieten. Momentan ginge es leider nur lokal, mein akt. Vorhaben geht erst in ca. 2 Mon. live. Dein neuer (alter Ansatz) und auch, soweit praktikabel, bestehende Contao-Module einzubinden, gefällt mir wesentlich besser.
Zwischenzeitlich sind mir auch noch ein paar Ideen dazu gekommen, die viell. auch Dir und anderen gefallen könnten, ich weiß es nicht ...

• Wenn die Kundenverwaltung in die Benutzer u. Benutzergruppenverwaltung integrierbar wäre und für FE-Einsatz auch an die Mitgliederverwaltung.
• Wenn zu den Kunden und beliebig vielen derer Ansprechpartner jeweils ein Profil angelegt werden könnte. Idealerweise vielleicht sogar mit konfigurierbaren Feldern und auch Grafiken (Fotos, Logo etc.). So könnte man die Anwendung auch universeller einsetzen und ein "Kunde" könnte dann ebensogut ein Vereinsmitglied, Community-Mitglied oder sonstwas sein. Bzw. der "Kunde" ebenso eine Einzelperson wie auch eine Gruppe mit Membern sein.
• Wenn man denen auch verbundene Pages und evtl. Inhaltselemente zuordnen könnte. Da Seiten bei Bedarf geschützt werden können, ließen sich so mit Bordmitteln sogar ganz simpel Dokumenten- u. Projektstrukturen angelegen.
• Wenn auch noch ein internes Nachrichtensystem dafür verfügbar wäre.
• Wenn man ohne Template- und/oder CSS-Eingriffe ggf. nicht benötigte Teile wie z. B. "Rechnungen" oder "Aufgaben" ausblenden könnte. Zu sehen, was man für den jeweiligen Zweck nicht braucht, irritiert ja bloß.

Es wäre viell. nicht unbedingt schlimm, wenn der Oberbegriff so etwas universeller einfach "Beziehungsmanagement" lauten würde und nicht nur speziell "Kundenbeziehungsmanagement, oder?

Hallo Zusammen,

hier mal der aktuelle Stand + ein bisschen Planung:

Konzeptionell ist folgendes geplant:

1. Mitglied kann zum Kunden werden
2. Projekte können angelegt werden (Kunde 1 : * Projekt)
3. Leistungen können angelegt werden (Leistung * : 1 Projekt)
4. Leistungstypen können angelegt werden (Leistungstyp 1 : * Leistung)

Um ein Mitglied zu einem Kunden zu machen ist nur ein Klick notwendig:

http://www.contao-community.de/attac...1&d=1307266773


Alle Kunden werden im Backend mit ihren Projekten und deren Leistungen aufgelistet:

http://www.contao-community.de/attac...1&d=1307266773
(Das Icon bei jeder Leistung wird im Leistungstyp definiert)

Aktuell lassen sich Kunden komplett verwalten und die Datenbank ist für die anderen Elemente vorbereitet. Alle Daten aus dem Screenshot kommen aus der Datenbank sind allerdings noch manuell eingetragen.

Nächste Schritte:

• Verwaltung der Projekte, Leistungstypen und Leistungen
• Adressen zu Kunden hinzufügen (möglicherweise lässt sich der Adressenteil von Isotope nutzen, werde Andreas diesbezüglich anschreiben)

Ideen:

• Durch die Auflistung der Leistungen könnten Rechnungen direkt daraus generiert werden.
• Momentan enthält jede Leistung den Preis der für die Leistung berechnet wird, mögliche Zusatzattribute wären Abrechnungsintervall und Leistungsdatum
• Da es sich ja schnell um einige Projekte und Leistungen handelt wird die Übersicht bestimmt schnell unübersichtlich. Deshalb sollten alle Kunden und Projekte jeweils auf- und zugeklappt werden können.

Meinungen und Kommentare erwünscht :)

Gruß
Christian

Guten Abend Zusammen,

es gibt ein kleines Update.

Inzwischen können auch Projekte und Leistungen über die Kundenansicht angelegt werden:

http://www.contao-community.de/attac...1&d=1307299784

Die Leistungstypen können über die Einstellungen gesetzt werden:

http://www.contao-community.de/attac...1&d=1307299784

Ein Leistungstyp:

http://www.contao-community.de/attac...1&d=1307299784

Nächster Schritt:

• Adressen verwalten

Idee:

• Weitere Felder für Projekt wie z. B. Projektleiter (Contao Benutzer)

Wie zuvor Kommentare, Meinungen oder auch Feldvorschläge erwünscht :)

Gruß
Christian

Sieht schonmal gar nicht schlecht aus. Wie du ja festgestellt hast wird es bei der Übersicht schwierig wenn es viele Kunden werden. Ein einfaches ein und ausklappen wird dort nicht mehr ausreichen. Es muss schon eine Suche mit rein da selbst bei 200 Kunden die Übersicht verloren gegangen ist.

Hallo Christian,

nach der Contao Konferenz wollte ich mich auch mal an soetwas setzen. Und da sehe ich grad, dass du schon an einer Lösung arbeitest.

Sieht schon klasse aus!

Falls du noch einen Testnutzer brauchst, würde ich mich gerne hiermit melden! ;)

Weiterhin frohes Schaffen!

VG, Martin

@smung0r:
Gute Idee

@derbackes:
Freut mich das es dir gefällt und das ich noch einen Tester habe.

@all:
Ich denke am Mittwoch Abend werde ich die erste Alpha Version veröffentlichen,

Gruß
Christian

Gefällt mir sehr gut, ich melde mich auch mal zum Testen an ;)

War doch ein bisschen schneller als gehofft:

Die erste Version der CRM Erweiterung ist im ER verfügbar. Sie nutzt die Adress-Erweiterung und sieht nun so aus:

http://www.contao-community.de/attac...1&d=1307483477

Ihr findet die Erweiterung bereits im ER unter folgendem Link:
http://www.contao.org/erweiterungsli...ew/li_crm.html

Die Erweiterung ist auf die Version 2.9.5 gestellt, sollte aber auch zumindest mit den anderen 2.9.* Versionen laufen. Ich würde mich freuen wenn der eine oder andere, der Zeit hat, die Erweiterung testen könnte und mir ein kurzes Feedback schreiben könnte (und wenn es nur ist ob es in der Version *.*.* funktioniert).

Nächster Schritt:

• Alle Texte sprachunabhängig in die languages files auslagern

Freue mich immer über Feedback oder Anregungen.

Gruß
Christian

Zitat:

---

Zitat von christian.kolb

Ich würde mich freuen wenn der eine oder andere, der Zeit hat, die Erweiterung testen könnte und mir ein kurzes Feedback schreiben könnte (und wenn es nur ist ob es in der Version *.*.* funktioniert).

---

Zitat:

---

Sehr schön! Getestet unter Contao 2.10.beta1. Alles fein soweit. :)

---

Naja, fast: Wenn ich einen neuen Kunden anlege und die Option "Kunde" aktiviere, dann blitzt kurz der Lade-Hinweis auf, die Felder "Kundennummer" und "Kundenname" werden aber nicht angezeigt. Die beiden letztgenannten Eingabefelder sind erst dann sichtbar, sobald der Kunden-Datensatz erneut zum Editieren geöffnet wird.

Nabend,

habs testweise gerade mal installiert, weil ich die Idee und deine Mühe richtig klasse finde! Teste es unter 2.9.5 mit Mac OS X und Firefox.

Wenn ich unter Einstellungen einen neunen Leistungstyp anlegen (z.B. Webhosting Paket M) und diesem einen Preis mitgebe und dann unter "Kunden" einem Projekt eine Leistung hinzufügen will, kann ich ja den Leistungstyp auswählen. Der Preis wird hier aber nicht übernommen. Ist das gewollt so? Wieso muss ich unter "Leistungstypen" denn einen Preis eingeben?

Außerdem wird die Anzeige unter Leistungstypen etwas "zerschossen" angezeigt bei mir (siehe Screenshot)

Ansonsten bin ich gespannt wie sich die Erweiterung entwickelt!
Hut ab + Danke für deine Mühe.

Lieben Gruß
Torben

Danke euch beiden für das schnelle Feedback.

@xchs:
Ich glaub da habe ich ein submitonchange vergessen. Schau ich mir auf jeden Fall an.

@tbruhn:
Der Standardpreis soll bei einer neuen Leistung als default-Wert eingetragen werden. Das ist allerdings noch nicht implementiert. Das es bei dir so zerschossen aussieht, liegt daran, dass du kein Icon für die Leistung definiert hast.
Für den Fall werde ich noch ein default-Icon einfügen.

Freue mich über weiteres Feedback :)

Gruß
Christian

Hallo Christian,

bei mir läuft es unter Contao 2.9.4 & Firefox 4.0.1 problemlos.
Habe aber noch einen Vorschlag:
Ich fände es gut, wenn die Kunden- & Projektnummern automatisch nummeriert würden und man dann evtl in den EInstellung den aktuellen Zähler verändern könnte.

Gruß
Jan

Oder die Nummern werden automatisch generiert, können aber überschrieben werden.

Hallo schumja,

daran hatte ich auch schon gedacht.

Nur dachte ich, nicht jeder nutzt einfach aufsteigende Nummern.
In meinem Beispiel laufen die Kundennummern von 001 aufsteigend. Andere möchten aber diese vielleicht vierstellig haben.
Und meine Projektnummern sind zweistellig mit vorgestellter Kundenummer, z. B. 00101.

Da gibt es halt sehr verschiedene Systeme. Entweder müsste man sich dann auf eines einigen oder mehrere anbieten. Oder man macht das ganze Konfigurierbar.

Was haltet ihr von dieser Konfiguration:
Kundennummer: Textfeld + Zahl (Stellen einstellbar) + Textfeld
Projektnummer: Kundennummer + Textfeld + Zahl (Stellen einstellbar) + Textfeld

Über die Textfelder würden sich statische Werte eintragen lassen.

EDIT:
@psren:
Die Nummer wäre auf jeden Fall nur der Defaultwert, die komplett vorzuschreiben macht eigentlich keinen Sinn.

Gruß
Christian

Zitat:

---

Zitat von christian.kolb

Was haltet ihr von dieser Konfiguration:
Kundennummer: Textfeld + Zahl (Stellen einstellbar) + Textfeld
Projektnummer: Kundennummer + Textfeld + Zahl (Stellen einstellbar) + Textfeld

---

Wobei man die Felder dann optional sind oder?
Dann würde ich das begrüßen.
Bei mir sehen die Projekte nämlich JAHRxxxx aus ;)

Die Textfelder sind auf jeden Fall optional ausfüllbar. Wenn ich dort dann noch die Insert-Tags nutzbar mach, dann denke ich, müsste man das allermeiste umsetzen können.

Gruß
Christian

Danke fürs schnelle Feedback!
An der fehlenden Icon-Grafik lag es! ;)

Die Idee mit den generierten Nummern würde ich sehr begrüßen!
Deine Idee mit Textfeld inkl. Nummer klingt sehr gut!

Bin gespannt wie sich die Erweiterung entwickelt und freu mich schon wie bolle auf den ersten Test Rechnungen generieren zu können ;)

@tbruhn:
Bis es Rechnungen zu generieren gibt wird es wohl noch eine Weile dauern, aber toll das du dich jetzt schon freust :)

@xchs:
Ich habe die neueste Version (2.10.RC1) aus dem svn ausgecheckt und habe das mit den Kunden getestet. Bei mir funktioniert alles problemlos.

Hat irgendjemand mit einer anderen Version das Problem?

Gruß
Christian

Es gibt eine neue Version der CRM Erweiterung im ER.

Änderungen:

• Alle Texte sind sprachunabhängig, verfügbare Sprachen sind Deutsch und Englisch
• Wenn kein Icon für einen Leistungstyp ausgewählt wird, wird ein Standardicon genutzt. Dadurch zerschießt es das Layout nicht mehr.

Nächste Schritte:

• Automatisch generierte Projektnummer
• Übernahme des Standardpreises eines Leistungstypes bei Erstellung einer Leistung

Freue mich über Tester, Feedback und Anregungen.

Gruß
Christian

Hallo,
teste gerade 2.10 beta lokal unter xampp und die Erweiterung installiert. Den Beiträgen gemäß funktioniert es bei mir entsprechend. Ein paar Gedanken hierzu:

- Die zusätzlichen Adressen sind sicherlich hilfreich - evtl. auch ein wenig verwirrend.
Im Bereich Kunden habe ich die zwei Symbole für die Kunden/Mitglieder Bearbeitung.

Hier würde das Contao Standard Symbol ausreichen, wenn dieses dann auf die Adressen Liste zeigt. Hier erreicht man ja dann das eigentliche Mitglied/bearbeiten und die weiteren Adressen.

Wenn ich eine Zusatzadresse als Standardadresse setze, werden die Daten übertragen (Mitgliedsdaten) - soweit so gut. Warum aber dann diese Zusatzadresse weiter /explizit auflisten?

Die Standard Daten sind ja dann quasi Bestandteil der Mitgliedsdaten - in meinen Augen ist dies dann einfach die Standardadresse.

Wenn ich nun eine andere Zusatzadresse kopiere, in der die Checkbox Standardadresse noch aktiv war und dies abspeichere - kann man leicht seine (korrekten) Mitgliedsdaten versehentlich überschreiben. ??

- Weiterhin würde mich ebenfalls die Vorschläge/Gedanken zur Integration weiterer, projektbezogener Daten interessieren ( FTP Name, Provider, Version ...). Eine subjektive Auswahl der Felder kann sicherlich nie allgemeingültig sein. Wäre hier eine Interaktion mit der "Dma elementgenerator" Erweiterung möglich?

Ansonsten - Tolle Idee, werde ich weiter gespannt verfolgen
Franko

Hallo Franko,

Zitat:

---

Hier würde das Contao Standard Symbol ausreichen, wenn dieses dann auf die Adressen Liste zeigt. Hier erreicht man ja dann das eigentliche Mitglied/bearbeiten und die weiteren Adressen.

---

Wenn ich dich richtig verstehe, willst du das Adressensymbol aus der Kundenansicht raus haben. Dann müsste man doch, um an die Adressen zu kommen, zwei mal klicken. Sehe ich eigentlich keinen Grund der dafür spricht.

Zitat:

---

Wenn ich eine Zusatzadresse als Standardadresse setze, werden die Daten übertragen (Mitgliedsdaten) - soweit so gut. Warum aber dann diese Zusatzadresse weiter /explizit auflisten?

---

Weil nur die Daten übertragen werden, die es sowohl im Mitglied als auch in der Adresse gibt. Ein Teil der Daten sind nur in der Adresse verfügbar (Zweite E-Mail Adresse, Rechnungsadresse, Privatadresse).

Zitat:

---

Wenn ich nun eine andere Zusatzadresse kopiere, in der die Checkbox Standardadresse noch aktiv war und dies abspeichere - kann man leicht seine (korrekten) Mitgliedsdaten versehentlich überschreiben. ??

---

Wenn du eine Zusatzadresse kopierst, dann die Daten änderst und die Checkbox "Standardadresse" drin lässt, wird diese zu deiner Standardadresse. Die andere ist aber noch vorhanden, die Checkbox ist nur nicht mehr angewählt. Wenn du bei dieser "Standardadresse" wieder anhakst, werden alle Daten wieder übertragen. Du löschst also keine Daten, du änderst nur die Standardadresse.

Zitat:

---

Weiterhin würde mich ebenfalls die Vorschläge/Gedanken zur Integration weiterer, projektbezogener Daten interessieren ( FTP Name, Provider, Version ...). Eine subjektive Auswahl der Felder kann sicherlich nie allgemeingültig sein. Wäre hier eine Interaktion mit der "Dma elementgenerator" Erweiterung möglich?

---

Du hast vollkommen Recht, eine allgemeingültige Auswahl kann nicht getroffen werden. Es muss also wirklich noch eine Möglichkeit, eigene Felder zu generieren, her. "dma elementgenerator" kannte ich noch nicht und habe ich bis jetzt noch nicht getestet. Bis war eher eine Verbindung zu Catalog gedacht, muss mir darüber aber auch noch Gedanken machen. Die freien Felder werden aber eher zu den Leistungen (Leistungstypen) gehören als zu den Projekten. Ich denke für Projekte wird man allgemeingültige Felder finden können.

Gruß
Christian

Moin Christian,
das ging ja mal wieder fix -

Hinsichtlich der Kunden Bearbeitungssymbole dachte ich lediglich, das ein Symbol ausreichend wäre, da man über Deine Adressliste ganz oben ja ebenfalls auf die Mitgliedssätze zugreifen kann.

Bezüglich der Adressaufteilung schaue ich es mir sicherlich nochmals genauer an - kann von meiner Seite durchaus zu subjektiv gefärbt worden sein. Deine Angaben hören sich sinnvoll an - von daher.

Ich habe jetzt 3 Zusatzadressen angelegt (Rechnung/Privat/Standard) - zusammen mit den Mitgliedsdaten - fühlt es sich momentan noch unübersichtlich an - wüßte jedoch augenblicklich auch keine bessere Aufteilung.

Den dma_elementgenerator hatte ich gerade in einem Projekt eingesetzt - Der Zeitaufwand gegenüber dem Katalog war hier ausschlaggebend und von der Aufgabenstellung ausreichend. Ich denke für Deine Erweiterung wäre die Handhabung ala dma zur komfortablen und freien Erstellung von Projekt/Elementen hilfreich.

Aus dem Norden
Franko

Zitat:

---

Ich habe jetzt 3 Zusatzadressen angelegt (Rechnung/Privat/Standard) - zusammen mit den Mitgliedsdaten - fühlt es sich momentan noch unübersichtlich an - wüßte jedoch augenblicklich auch keine bessere Aufteilung.

---

Deshalb habe ich schon die Icons eingesetzt, aber mir fällt nichts ein wie man es noch übersichtlicher machen könnte.

Zitat:

---

Den dma_elementgenerator hatte ich gerade in einem Projekt eingesetzt - Der Zeitaufwand gegenüber dem Katalog war hier ausschlaggebend und von der Aufgabenstellung ausreichend. Ich denke für Deine Erweiterung wäre die Handhabung ala dma zur komfortablen und freien Erstellung von Projekt/Elementen hilfreich.

---

Gut in dem Fall werde ich ihn mir mal auch noch anschauen.

Danke für das Feedback

Gruß
Christian

Hallo Zusammen,

bin ja schon eine ganze Weile hier im Forum unterwegs, aber irgendwie muss ich den Punkt "Sonstige Erweiterungen" irgendwie übersehen haben. Das ganze Thema passt dort inzwischen eher hin.

Soll heißen alles weitere, wie z.B. das neue Update, läuft über dieses Thema.

Gruß
Christian