UPDATE: Änderungen für vTiger 5.30 befinden sich in einem extra Post.
Dies soll der erste Post einer Reihe von Artikeln sein, welche sich um Anpassungen des CRM-Systems vTiger drehen.
Da ich beruflich in den letzten Wochen sehr viel mit dieser Software zu tun hatte, wollte ich meine Erkenntnisse im Internet veröffentlichen um evtl. anderen Hilfesuchenden behilflich zu sein.
In diesem ersten Artikel geht es jetzt darum, wie ich das größte Problem beim Einsatz eines vTigers mit Kundenkontakt in Deutschland habe: Das Datumsformat.
Von Haus aus unterstützt das CRM leider nur die folgenden Formate:
- yyyy-mm-dd
- dd-mm-yyyy
- mm-dd-yyyy
Punkt 2 kommt dem deutschen Format „dd.mm.yyyy“ zwar schon sehr nahe, wirkt aber doch unprofessionell, da auf ausgehenden Rechnungen das Datum mit „10-02-2009“ angegeben ist.
„Kein Problem“, dachte ich mir und begann das System zu untersuchen … und verstand langsam, warum es nicht alzu viele Extensions zu dem System gibt. … Es ist einfach unheimlich komplex.
Lösung
Zu erst, habe ich in der Tabelle „vtiger_date_format“ eine Zeile mit folgendem Inhalt eingefügt:
date_formatid : 4
date_format : dd.mm.yyyy
sortorderid : 0
presence : 1
Die Spalte sortorderid kann natürlich angepasst werden, um die Formatauswahl umzusortieren. Bei mir war einzig das deutsche Format notwendig, weshalb es auch an erster Stelle erscheinen sollte, damit es als Standard gewählt wird.
Daraufhin fingen die Probleme an. Erst wurden zu importierten eMails (Die Anpassung fand während der Einrichtung des Systems statt) keine Sende-Daten mehr gespeichert, dann verschwanden Geburtsdaten und Rechnungsdaten.
Das Ergebnis war also wenig zufriedenstellend, sodass ich motiviert weitergesucht habe.
Daraufhin habe ich in folgenden Dateien noch Änderungen gemacht, damit das deutsche Datumsformat verfügbar ist. (Die Zeilenangaben richten sich jeweils an ein vTiger Version 5.21)
Ich versuche die Positionen aber zu beschreiben, sodass auch andere Version davon profitieren können.
include/utils/CommonUtils.php
Funktion : getNewDisplayDate(…) [Line ~1012]
folgendes an passender Stelle einfügen: (If Abfragen sind gut erkennbar)
[php]
elseif($dat_fmt == ‚dd.mm.yyyy‘)
{
$display_date = date(‚d-m-Y‘);
}
[/php]
Funktion: parse_calendardate(…) [Line ~221]
folgendes an passender Stelle einfügen: (If Abfragen sind gut erkennbar)
[php]
elseif($current_user->date_format == ‚dd.mm.yyyy‘)
{
$dt_popup_fmt = "%d.%m.%Y";
}
[/php]
Funktion: getDisplayDate(…) [Line ~945]
folgendes an passender Stelle einfügen: (If Abfragen sind gut erkennbar)
[php]
elseif($dat_fmt == ‚dd.mm.yyyy‘)
{
$display_date = $d.‘.‘.$m.‘.‘.$y;
}
[/php]
include/utils/utils.php
Funktion: getDBInsertDateValue(…) [Line ~1541]
folgendes an passender Stelle einfügen: (If Abfragen sind gut erkennbar)
Achtung! Der Bindestrich an dieser Stelle ist korrekt. Erklärung folgt darunter.
[php]
elseif($dat_fmt == ‚dd.mm.yyyy‘)
{
list($d,$m,$y) = explode(‚-‚, $value);
}
[/php]
Offenbar wird der Funktion getDBInsertDateValue(…) ab und zu ein Datumsformat übergeben, in welchem alle nichtnumerischen Zeichen durch den Bindestrich ersetzt werden. (Genauer: Bei der JavaScript-Inpage Edit-Funktion)
Deshalb habe ich in der Funktion getDBInsertDateValue(…) nach der Zuweisung von $dat_fmt [Line ???] folgende Zeile eingefügt:
[php]
$value = str_replace(".", "-", $value);
[/php]
Diese ersetzt alle Punkte durch Bindestriche, sodass dd.mm.yyyy im Grunde zu dd-mm-yyyy wird.
include/js/general.js
Funktion: patternValidate(..)
Hier wird offenbar nicht korrekt geprüft, ob das pattern überhaupt gesetzt wird, weshalb der Ajax-Edit nicht mehr korrekt abgeschickt werden kann. Deshalb folgende Stelle suchen:
[php]
if (type.toUpperCase()=="TIME") {//TIME validation
var re = /^\d{1,2}\:\d{1,2}$/
}
[/php]
und danach folgendes einfügen:
[php]
if(re == undefined)
return true;
[/php]
include/ComboStrings.php
Um Line 304 steht die Zuweisung
[php]
‚date_format_dom‘ => Array(‚dd-mm-yyyy’=>’dd-mm-yyyy‘,
‚mm-dd-yyyy’=>’mm-dd-yyyy‘,
‚yyyy-mm-dd’=>’yyyy-mm-dd‘
),
[/php]
An dieser Stelle muss folgende Zeile eingefügt werden. Bestenfalls vor der ‚mm-dd-yyyy‘ Zuweisung
[php]
‚dd.mm.yyyy‘ => ‚dd.mm.yyyy‘
[/php]
Ich verspreche nicht, dass durch die Änderung des Datumsformates später nicht noch weitere Probleme auftreten, werde diesen Post allerdings updaten und dahingehend aktuell halten, wenn sich solche Probleme in unserer, oder eurer, Umgebung abzeichnen sollten.
Leider wurde unser Format bei der Entwicklung vom vTiger komplett vergessen. Trotz dessen ist dieses KOSTENFREIE CMS problemlos auch in Deutschland einzusetzen und gerade weil es in der Basis keinen Euro kostet, schon Wert genutzt zu werden.
Ich habe noch einige Problemlösungen auf Lager und werde diese im Laufe der Tage noch posten.
Unter anderem:
- Rechnungen über Webservice mit einer Produktliste anlegen
- Schwierigkeiten mit dem Webservice und UTF-8
- Listen standardmäßig nach der ersten Spalte sortieren, statt der ID, damit jeder User die Sortierung ändern kann
Bis dahin!
Bye
UPDATE [19.07.2011]:
Da ich den Hinweis vergessen hatte:
Um die Änderungen zu aktivieren, müsst Ihr unter „Meine Einstellungen“, rechts oben, das neue Datumsformat „dd.mm.yyyy“ auswählen. Ansonsten nutzt Ihr weiter die fest integrierten Formate.
UPDATE2 [26.09.2011]:
Solltet Ihr ein komplett neues vTiger-System nutzen, könnt ihr auch folgendes Archiv nutzen, welches alle geänderten Dateien beinhaltet. Die Datenbankänderung in Schritt 1 müsstet Ihr aber trotzdem durchführen:
https://stefanwarnat.de/wp-content/uploads/2011/07/vtiger_files1.zip
Hi Stefan,
Vielen Dank für deinen Artikel. Genau das was ich gesucht habe.
Hätte nicht gedacht das die Umstellung so aufwendig ist.
Werde das mal heute Abend in Agriff nehmen.
LG
Rene
Hi Stefan habe die Datein und SQL Tabelle angepasst aber ist bei mir immer noch (yyyy-mm-dd) format 🙁 Sind deine Änderungen nur für Email? Ich bräuchte das dd.mm.yyyy für Rechnungen..
Hmm habe herausgefunden das mann das Datum Format natürlich noch bei Meinen Einstellungen (rechts oben)/ Datumsformat ändern muss.
Habe dann auf ddm.mm.yyyy gewechselt. Jedoch wird es im Modul Rechnungen nicht angezeit auch nicht in den generierten PDF.
Habe es dann noch mit dd-mm-yyyy probiert und mit dem funktionierts. Also denke ich das ich irgendwo was falsch angepasst habe. Daher wäre es super wen du deine Angepassten Datein Public machen könntest.
Hallo Rene,
Danke für deine Rückmeldung.
Den Hinweis mit den Einstellungen unter „Meine Einstellungen“ habe ich gerade noch hinzugefügt. Das ist natürlich richtig.
Alle angepassten Dateien für diese Änderung findest du in folgendem Archiv:
Download
Da ich an den vTiger-Files noch eine ganze Menge Änderungen mehr gemacht habe, würde ich dir raten die überschriebenen Dateien zu sichern, wenn du es einfach einspielen möchtest.
Gerade bei dieser Änderung sind es halt sehr grundlegende Dateien, die überschrieben werden.
Empfehlen würde ich dir stattdessen einen Dateivergleich über das sehr hilfreiche Tool Notepad++, wenn du es noch nicht installiert hast. 🙂
Bei den PDF-Rechnungen setze ich immer auf den PDF-Maker und kann deshalb auch nur für diesen angeben, dass die Umstellung funktioniert.
Stefan
Hoi Stefan,
Danke für die Dateien. Habe Sie gerade hochgeladen und funktioniert einwandfrei !
Vielen Dank!
Hoffe das VTIGER Update wird keine probs damit haben 😉
Was findest du besser VTIGER oder SUGAR CRM? VTIGER ist ja sozusagen eine abgeänderte SUGAR CRM Version nicht?
Hast du ne Idee wie man einen Service statt ein Produkt bei erstellung einer Rechnung als Default hat? Denke sowas ist sicher kompliziert umzustellen?
Hallo!
Freut mich, dass es so einfach war.
Bei einem Update auf die Version 5.3 werden wir wohl auf die *.patch – Files angewiesen sein, bzw. Änderungen nach einem Update nochmal durchführen müssen.
Ich habe mich längere Zeit mit der Frage rumgeschlagen, welches CRM System für die Zwecke meiner Kunden am besten funktioniert.
Denn du hast Recht: SugarCRM ist ein erweitertes vTiger in schön und nutzerfreundlich.
Allerdings hat SugarCRM den, für mich, großen Nachteil, dass es in der kostenfreien Version nur als nebenläufige Version unterstützt wird, welche einige Module garnicht unterstützt und Extensions nicht installiert werden konnten.
Bei so einer Konstellation muss man immer befürchten, dass die gratis Version noch weiter eingeschränkt wird, bzw. irgendwann wegfällt.
Und für mich ist Support vom Hersteller weniger wichtig, da ich die meisten Wünsche selbst umsetzen kann.
Zu deiner zweiten Frage:
Ich habs mir das gerade mal angeschaut, ob sich sowas einfach realisieren lässt. Leider scheint es aber wirklich nicht ohne weiteres umstellbar zu sein.
Die Routine, welche den ersten Eintrag einer Rechnung anzeigt, unterscheidet sich deutlich von der Routine hinter dem „Dienstleistung hinzufügen“.
Erstere ist in PHP implementiert und erstellt nebenbei noch die Überschrift der Tabelle. Jeder weitere Eintrag wird über JavaScript angehangen.
Das sowas aber beim besten Willen nicht die Antwort sein kann, habe ich einen Workaround gebaut, für den Fall, dass du diese Sache brauchst:
Einfach ganz unten in die Datei /Smarty/templates/Inventory/ProductDetails.tpl folgende Zeilen einfügen: (Ohne die Leerzeichen in den HTML-Tags)
[sourcecode language=“html“]
<script type="text/javascript">
function service() {ldelim}
fnAddServiceRow(‚Invoice‘,’themes/softed/images/‘);
moveUpDown(‚UP‘,’Invoice‘,2);
deleteRow(‚Invoice‘,2,’themes/softed/images/‘);
{rdelim}
window.setTimeout("service();", 350);
</script>
[/sourcecode]
Damit werden die Schritte zum Einfügen einer Dienstleistung und dem Entfernen des ursprünglichem Produktes automatisch durchgeführt.
Diese Lösung unterscheidet allerdings nicht und macht diesen Schritt bei jeder anzulegenden Rechnung, aber nicht beim Konvertieren eines Angebotes.
Vielleicht hilft es dir ja. 🙂
Bye,
Stefan
Nur ein Wort:
Suuuuuuuuuuuuper.
Danke Dir sehr dafür!
Wenn Du mal in Nbg. bist ruf an-Ein Freibier wartet:-)
Hallo Stefan!
Das mit dem Datum ist ja super! Ist schon komisch, warum die Inder das europäische Format so vernachlässigen… Dabei komme ich gleich auf meine Frage: Hast Du schonmal wegen dem europäischen Zahlenformat nachgeforscht? Es werden ja hier die Tausendertrennzeichen mit Komma getrennt und das Komma mit Punkt (amerikanisch halt!) Ich hörte mal davon, dass es wahnsinnig schwer sein soll, das alles umzuschreiben, darum habe ich diesen Punkt auch nicht weiter verfolgt (Ausserdem sind meine PHP-Kenntnisse miserabel!)!
Ich schreibe allerdings gerade meine Bachelor Thesis und das vTiger ist da ein Teil davon! Es geht bei mir um Angebotsprozesse, und das vTiger soll das „Werkzeug“ werden!
Gruß
Andreas
Hallo Andreas,
Bisher ist mir das noch nicht aufgefallen, dass das Format nicht stimmt. Könnte allerdings davon kommen, dass ich beim programmieren sowieso nur Punkte nutzen kann.
Ich werde mir aber auf jeden Fall mal ansehen, ob ich daran relativ unkompliziert etwas ändern kann.
Stefan
Also folgendes kam bei mir gerade überraschenderweise heraus:
Das Format der Zahlen hängt vollkommen an der Sprache, welche ich für den vTiger nutze.
Sprich wenn ich eine Installation mit zwei Browser öffne habe ich einmal auf Deutsch: 14.855,25 und einmal auf Englisch: 14,855.25 stehen.
Also gibt es da schon eine Unterscheidung.
Bei der Eingabe von Zahlen allerdings, besteht das Problem allerdings nicht auf der Seite von vTiger, sondern auf Seiten des Browsers, welcher nur das amerikanische System kennt und alles andere als Zeichenkette interpretiert.
Stefan
Gibt es eigentlich schon einen Ansatz für die Datumsumstellung bei 5.3? Ich habe es irgendwie nicht hinbekommen.
Gruß
Frank
Ich bin noch nicht zum Testen meines Weges unter 5.3 gekommen.
Das Team vom vTiger hat bei 5.3 aber einen großen Schritt bei der Internationalisierung gemacht, was Formatierungen angeht.
Und da letzte Woche auch die Final der neuen Version erschienen ist, werde ich mich wohl darüber machen, ein paar Posts zu aktualisieren.
Sollte also die nächsten Tage kommen.
Stefan
Gerade habe ich, für alle Interessierten, die Änderungen für 5.30 eingestellt.
Zu finden hier:
https://stefanwarnat.de/220/vtiger-auf-deutsches-datumsformat-dd-mm-yyyy-umstellen-1/