Hallo Leute,
UPDATE Die nachfolgende Beschreibung kann auf vTiger 5.3 UND 5.4 angewendet werden.
Vielen Dank für das umfassende positive Feadback auf die erste Beschreibung.
Deshalb möchte ich mit diesem Post meine Anpassungen des Datums-Formates im vTiger für die Version 5.30 / 5.40 aktuallisieren.
Da das Team hinter vTiger in dieser Version größere Anpassungen in diesem Bereich gemacht haben, sind die Änderungen leider komplett anders. Allerdings deutlich übersichtlicher gewurden.
Da ich finde, dass sich der Ablauf bewährt hat, hier der übliche Ablauf der Änderungen:
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 : parse_calendardate(…) [Line ~221]
In if-Anweisung integrieren, bzw. einfach dahinter schreiben:
[php]
elseif($current_user->date_format == ‚dd.mm.yyyy‘)
{
$dt_popup_fmt = "%d.%m.%Y";
}
[/php]
/include/fields/DateTimeField.php
Funktion : __convertToDBFormat(…) [Line ~95]
folgendes an passender Stelle einfügen: (If Abfragen sind gut erkennbar)
[php]
elseif ($format == ‚dd.mm.yyyy‘) {
if(strpos($date, "-") !== false) {
list($d, $m, $y) = explode(‚-‚, $date);
} else {
list($d, $m, $y) = explode(‚.‘, $date);
}
}
[/php]
An dieser Stelle wird leider ab und zu ein Format dd-mm-yyyy und die Einstellung des Users dd.mm.yyyy übergeben. Deshalb nochmal der Check.
Funktion: __convertToUserFormat((…) [Line ~157]
folgendes an passender Stelle einfügen: (If Abfragen sind gut erkennbar)
[php]
elseif ($format == ‚dd.mm.yyyy‘) {
$date[0] = $d . ‚.‘ . $m . ‚.‘ . $y;
}
[/php]
Funktion: convertToUserFormat(…) [Line ~139]
An dieser Stelle wird das Standard-Format des Vtigers auf dd.mm.yyyy gesetzt. Diese Einstellung ist besonders für die Extension PDFMaker relevant, da diese für Datumsausgaben in PDF’s aus einem Workflow genutzt wird.
Suchen:
[php]
if(empty($format)) {
$format = ‚dd-mm-yyyy‘;
}
[/php]
ersetzen:
[php]
if(empty($format)) {
$format = ‚dd.mm.yyyy‘;
}
[/php]
Funktion: convertToDBFormat(…) [Line ~139]
Suchen:
[php]
if(empty($format)) {
$format = ‚dd-mm-yyyy‘;
}
[/php]
ersetzen:
[php]
if(empty($format)) {
$format = ‚dd.mm.yyyy‘;
}
[/php]
include/js/general.js
Funktion: patternValidate(..)
Diese Position überprüft eingegebene Datumsangaben und muss ebenfalls um dd.mm.yyyy erweitert werden.
Folgendes suchen:
[php]
case "mm-dd-yyyy" :
case "dd-mm-yyyy" :
var re = /^\d{1,2}(\-|\/|\.)\d{1,2}\1\d{4}$/
[/php]
und folgendermaßen ergänzen:
[php]
case "mm-dd-yyyy" :
case "dd-mm-yyyy" :
case "dd.mm.yyyy" :
var re = /^\d{1,2}(\-|\/|\.)\d{1,2}\1\d{4}$/
[/php]
Funktion splitDateVal(…)
Folgendes suchen:
[php]
case "dd-mm-yyyy" :
dateelements[0]=dateval.substring(0,dateval.indexOf(datesep))
dateelements[1]=dateval.substring(dateval.indexOf(datesep)+1,dateval.lastIndexOf(datesep))
dateelements[2]=dateval.substr(dateval.lastIndexOf(datesep)+1,dateval.length)
[/php]
daraus folgendes machen (case „dd.mm.yyyy“ für „dd-mm-yyyy“ einfügen)
[php]
case "dd-mm-yyyy" :
case "dd.mm.yyyy" :
dateelements[0]=dateval.substring(0,dateval.indexOf(datesep))
dateelements[1]=dateval.substring(dateval.indexOf(datesep)+1,dateval.lastIndexOf(datesep))
dateelements[2]=dateval.substr(dateval.lastIndexOf(datesep)+1,dateval.length)
[/php]
Funktion: re_patternValidate(…) [~LIne 4262]
Suchen:
[php]
case "dd-mm-yyyy" :
var re = /^\d{1,2}(-)\d{1,2}\1\d{4}$/
[/php]
Daraus folgendes machen:
[php]
case "dd-mm-yyyy" :
case "dd.mm.yyyy" :
var re = /^\d{1,2}(\-|\/|\.)\d{1,2}\1\d{4}$/
[/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]
Daraus folgendes machen:
[php]
‚date_format_dom‘ => Array(‚dd-mm-yyyy’=>’dd-mm-yyyy‘,
‚dd.mm.yyyy’=>’dd.mm.yyyy‘,
‚mm-dd-yyyy’=>’mm-dd-yyyy‘,
‚yyyy-mm-dd’=>’yyyy-mm-dd‘
),
[/php]
Bitte zuletzt noch das Datumsformat rechts oben unter „Meine Einstellungen“ aktuallisieren, damit Ihr auch eine Änderung sehen könnt.
Die anderen Updates für 5.30 kommen heute im Laufe des Tages online.
Bis dahin!
Bye
Also die Umstellung funktioniert. Allerdings lassen sich einzelne Felder z.B. bei Rechnungen nach Änderungen nicht mehr speichern. Ich kann dann nur noch Änderungen vornehmen, wenn ich die gesamte Rechnung bearbeite und dann speicher.
Leider sind die Änderungen von Deinem Update nicht ersichtlich
Hi,
hast du es mittlerweile hin bekommen?
Wenn ich deine Umstellungen mache, kann ich Datumsfelder nicht mehr verändern.
Was mir auch aufgefallen ist, die Punkt uns Koma Notation bei Zahlen wird durcheinander geworfen.
Gruß Pascal
Ich hab alles nochmal überprüft und nachgeschaut und konnte in meinem vTiger keine Probleme bei der Eingabe finden.
Allerdings bin ich schon länger einem Fehler direkt im Vtiger auf der Spur, welcher er verhindert, dass bei der Verkaufsbestellung das Wiederholungs-End-Datum nicht verändert werden kann.
Dieser Umstand liegt aber im Vtiger, da eine Variable wahrscheinlich falsch benannt wurde. Dazu werde ich aber noch einen Post schreiben.
Welche Felder kannst du denn nicht bearbeiten?
Was definitiv funktioniert, da gerade getestet, ist, z.B. das Datum für die Bindefrist eines Angebotes. Dieses ändert sich definitiv durch die Modifikation.
Stefan
Hallo,
erstmal großes Lob für die Arbeit. Die Anpassungen funktionieren bei uns sehr gut.
Wir haben aber noch das Problem, dass in E-Mail Templates benutzte Datumsfelder im original Format YYYY-mm-tt in den Mails versendet werden. Hat jemand dafür schon eine Lösung gefunden?
Gruß Torsten
Hi,
so schade dass im neuen Vtiger 5.4. das deutsche Datum noch nicht als Auswahl realisiert wurde. Kann man Deine Änderungen(funktionieren unter 5.3. prima) auch in 5.4. vornehmen?
Bin auch nicht sicher ob es sinnvoll ist schon jetzt auf 5.4. zu migrieren?
Danke für Deine Arbeit, und schönen Gruß aus Nürnberg
Hallo Klaus,
Eine Umstellung auf 5.4 halte ich für sehr sinnvoll. Gerade durch das neue Menü dürfte sich das Arbeiten mit dem System als deutlich flüssiger darstellen.
Ich arbeite momentan meine Modifikationen gerade durch und stecke momentan auch in den Datumsroutinen.
Eine Lösung sollte als nicht mehr allzu fern sein.
So wie ich das aber sehe, kann die 5.3 Version nicht 100% übernommen werden, da in den vTiger Datumsfunktionen der 5.3 wohl ein herber Bug steckte und da einiges umgestellt wurde.
Stefan
Herzlichen Dank für Deine Information
Das kann ich gerne abwarten.
Ich habe in meinem Job eine größer Vtiger Aufgabe vor mir.
Ich werde sicher eine Menge an Anpassungen benötigen.
Vielleicht könnten wir uns über eine Zusammenarbeit unterhalten. Schreibe mir bitte doch mal Deinen Stundensatz/Tagessatz für Vtiger Anpassungen.
es geht nicht um einfache ergänzende Felder, sondern eher um Eingriffe im Core.
Liebe Grüße
Klaus
(info@fuchs-net.de)
Für die Version 5.4 sind zwei weitere Files zu ändern:
Folgendes Fehlverhalten wird beseitigt:
In „Benutzerdefinierten Berichten“ kann in „7.Filter –> erweiterte Filter“ kein Datum zum Vergleich eingetragen werden.
modules/Reports/Reports.js – ca. Zeile 583
case „dd.mm.yyyy“ :
var re = /^\d{1,2}(\-|\/|\.)\d{1,2}\1\d{4}$/
Folgendes Fehlverhalten wird beseitigt:
Wird im Mail Manager eine Aufgabe zu einer Mail erstellt, kann diese nicht erzeugt werden. Nach Drücken des Buttons „speichern“ schließt sich das QuickCreate Fenster der Aufgabe nicht.
include/js/QuickCreate.js – ca. Zeile 61
case „dd.mm.yyyy“ :
var re = /^\d{1,2}(\-|\/|\.)\d{1,2}\1\d{4}$/
Die Case Anweisung muss erweitert werden, der Regulare Ausdruck ist zu ersetzen.
Viel Erfolg
Gruß
Werner
Hallo Werner,
Danke für die Ergänzung.
Gerade die Module Reports und Mailmanager wurden bisher bei keinen meiner bisherigen Installationen benötigt, da andere Webmailer im EInsatz waren und für Reports meist auf die Ariacom Lösung gesetzt wurde.
Stefan
Pingback: deutsches Datumsformat für vTigerCRM 6.0 | Stefan bloggt über Hohndorf, Sachsen und die Welt
Hallo Stefan,
tolles Tut, allerdings ja schon älter, daher meine Frage:
Wie nutzbar für 5.4?
Am Ende deines Beitrages steht „Patch für 5.4“ und dann aber nix mehr.
Würde mich über eine Rückinfo sehr freuen – das fehlende deutsche Format nervt ja wirklich 😉
lg vom Deutsch aus Wien 😉
Hallo Marco,
Diese Beschreibung sollte sich problemlos auch mit 5.4 verwenden lassen.
Den Patch(Und jetzt auch den Hinweis) habe ich herausgenommen, da damit mehr Probleme aufgetreten sind, als er lösen konnte.
Momentan gibt es nur den kurzen manuellen Weg um das Format zu ändern.
Stefan
Hallo Stefan,
leider hab ich zuviel Angst, was „kaputt“ zu machen.
Könntest Du da unter die Arme greifen?
Natürlich gegen eine kleine Entschädigung.
lg Marco
Hallo Marco,
Ich melde mich per eMail bei dir.
Stefan
Würde mich sehr freuen! Danke!
Muss gestehen, dass ich ein wenig enttäuscht bin. Warte bis heute noch immer auf die versprochene Hilfe. Finde sehr schade, dass nun bereits nach einem ersten, netten Gespräch 2 meiner Mails unbeantwortet bleiben…