<?xml version='1.0' encoding='ISO-8859-1'?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
  "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
<!-- $Id: time.xml,v 1.1 2010/12/01 10:43:32 mg Exp $ -->

<chapter id="time">
<title>Zeitabhngige Funktionen in OTRS</title>

<sect1 id="time-settings">
<title>Relevante Zeiteinstellungen fr das System festlegen</title>

<para>
In OTRS werden einige Aktionen abhngig von der aktuellen Systemzeit
ausgelst. Von den Zeiteinstellungen betroffen sind die Berechnung der
Eskalationszeit und die eigentliche Eskalation von Tickets. Weiterhin hngt
die Zusendung von Benachrichtigungen fr eskalierte Tickets bzw. fr
Erinnerungs-Tickets, die den Erinnerungszeitpunkt erreicht haben, ab.
Ebenfalls wird die automatische Freigabe von Tickets durch diese
Einstellungen beeinflusst.
</para>

<para>
Mit Hilfe der Parameter

<link linkend="Framework:Core::Time:TimeWorkingHours">
TimeWorkingHours
</link>,

<link linkend="Framework:Core::Time:TimeVacationDays">
TimeVacationDays
</link>

und

<link linkend="Framework:Core::Time:TimeVacationDaysOneTime">
TimeVacationDaysOneTime
</link>

knnen die fr das System relevanten Zeiten entweder ber das

<link linkend="sysconfig">
grafische Konfigurations Frond-end
</link>

oder direkt ber die Datei <filename>Kernel/Config.pm</filename>
eingestellt werden.
</para>

<sect2 id="TimeWorkingHours">
<title>TimeWorkingHours</title>

<para>
Die Stunden, in denen Ihre Agenten aktiv am system arbeiten, knnen
folgendermaen in der Datei <filename>Kernel/Config.pm</filename>
festgelegt werden:
</para>

<example id='specifying-workinghours'>
<title>Festlegen der fr das System relevanten Arbeitsstunden</title>

<para>
<programlisting>
    $Self->{'TimeWorkingHours'} = {
        Mon => [ 8,9,10,11,12,13,14,15,16,17,18,19,20 ],
        Tue => [ 8,9,10,11,12,13,14,15,16,17,18,19,20 ],
        Wed => [ 8,9,10,11,12,13,14,15,16,17,18,19,20 ],
        Thu => [ 8,9,10,11,12,13,14,15,16,17,18,19,20 ],
        Fri => [ 8,9,10,11,12,13,14,15,16,17,18,19,20 ],
        Sat => [  ],
        Sun => [  ],
    };
</programlisting>
</para>

</example>

<para>
Nur whrend dieser Stunden knnen Tickets eskalieren, Benachrichtigungen zu
Erinnerungs-Tickets versendet oder Tickets automatisch freigegeben werden.
Weiterhin werden auch nur diese Stunden in die Berechnung der
Eskalationszeit und der Zeit fr die automatische Freigabe mit einbezogen.
</para>
</sect2>

<sect2 id="TimeVacationDays">
<title>TimeVacationDays</title>

<para>
Feiertage deren Datum jedes Jahr gleich ist, knnen dem System folgendermaen
in der Datei <filename>Kernel/Config.pm</filename> bekannt gemacht werden:
</para>

<example id='specifying-vacation-days'>
<title>Festlegen von regelmig wiederkehrenden Feiertagen</title>

<para>
<programlisting>
    $Self->{'TimeVacationDays'} = {
        1 => {
            1 => 'New Year\'s Eve!',
        },
        5 => {
            1 => '1 St. May',
        },
        12 => {
            24 => 'Christmas',
            25 => 'First Christmas Day',
            26 => 'Second Christmas Day',
            31 => 'Silvester',
        },
    };
</programlisting>
</para>

</example>

<para>
Whrend der hier festgelegten Tage werden keine zeitabhngigen
Aktionen oder Berechnungen auf Tickets im system ausgefhrt.
</para>
</sect2>

<sect2 id="TimeVacationDaysOneTime">
<title>TimeVacationDaysOneTime</title>

<para>
Freie oder Feiertage, fr die sich jhrlich das Datum ndert, knnen
folgendermaen in der Datei <filename>Kernel/Config.pm</filename> angegeben
werden:
</para>

<example id='specifying-sometime-vacation-days'>
<title>Festlegen von unregelmig wiederkehrenden Feiertagen</title>

<para>
<programlisting>
    $Self->{'TimeVacationDaysOneTime'} = {
        2008 => {
            10 => {
                3 => 'German Unification Day'
            },
            12 => {
                27 => 'Anual closing',
                28 => 'Anual closing',
                29 => 'Anual closing',
                30 => 'Anual closing',
            },
        },
        2009 => {
            6 => {
                12 => 'Anual works outing',
            },
        },
    };
</programlisting>
</para>

</example>

<para>
Whrend der hier festgelegten Tage werden keine zeitabhngigen
Aktionen oder Berechnungen auf Tickets im system ausgefhrt.
</para>

</sect2>
</sect1>

<sect1 id="unlock-tickets">
<title>Automatische Ticket "Freigabe" (unlock)</title>

<para>
Gesperrte Tickets knnen automatisch vom System freigegeben werden. Diese
Funktion kann z. B. dann ntzlich sein, wenn sich ein Agent im Urlaub
befindet und noch Tickets gesperrt hat, die bearbeitet werden sollen /
mssen.
</para>

<para>
Die Zeit, nach der gesperrte Tickets automatisch freigegeben werden, kann
in den

<link linkend="adminarea-queue">
Einstellungen jeder Queue
</link>

festgelegt werden. Mit Hilfe des Moduls
<filename>bin/UnlockTickets.pl</filename>, das als cron-Job regelmig
ausgefhrt werden sollte, wird die automatische Freigabe von Tickets
umgesetzt. Tickets werden nur whrend der in

<link linkend="TimeWorkingHours">
TimeWorkingHours
</link>

festgelegten Stunden automatisch freigegeben. An mit

<link linkend='TimeVacationDays'>
TimeVacationDays
</link>

und

<link linkend='TimeVacationDaysOneTime'>
TimeVacationDaysOneTime
</link>

festgelegten Tagen, werden keine Tickets automatisch freigegeben.
</para>

<para>
Benachrichtigungen ber automatisch freigegebene Tickets werden an die
Agenten versendet, die die Queue mit dem automatisch freigegebenen Ticket in
"Meine Queues" aufgenommen haben und bei denen in den

<link linkend="user-preferences">
Benutzereinstellungen
</link>

die Benachrichtigung fr vom System freigegebene Tickets aktiviert ist.
</para>

<para>
In der nachfolgenden Tabelle werden die Unlock-Zyklen der bisherigen OTRS Versionen verglichen.
</para>

<table id="table-of-unlock-mechanismen">
<title>"Freigabe" (unlock) Eigenschaften</title>
<tgroup cols="6">
<thead>
<row>
<entry>
"Freigabe" (unlock) Eigenschaften
</entry>
<entry>
2.0.x
</entry>
<entry>
2.1.1 - 2.1.5
</entry>
<entry>
2.1.6 - 2.1.x
</entry>
<entry>
2.2.x
</entry>
<entry>
2.3.x
</entry>
</row>
</thead>
<tbody>
<row>
<entry>
Ein Ticket wird "freigegeben" (unlocked) wenn...
<para/>
<para>a) fr die Queue, in der sich das Ticket befindet, eine Unlockzeit gesetzt ist.</para>
<para>b) die in den Queue Einstellungen hinterlegte Unlockzeit abgelaufen ist.</para>
<para>c) das Ticket von einem Agenten gesperrt ist.</para>
<para>d) sich das Ticket in einem "offen" Status befindet. Wenn ein "pending" Status gesetzt ist, wird die Unlockzeit ausgesetzt.</para>
</entry>
<entry>
x
</entry>
<entry>
x
</entry>
<entry>
x
</entry>
<entry>
x
</entry>
<entry>
x
</entry>
</row>
<row>
<entry>
Die Unlockzeit wird zurck gesetzt, wenn ein Agent einen extenen Artikel am Ticket erstellt. Als externer Artikel gelten im OTRS Standard Produkt alle Artikel mit dem Artikel-Typ "email-external", "phone", "fax", "sms", oder "note-ext".
</entry>
<entry>
-
</entry>
<entry>
-
</entry>
<entry>
x
</entry>
<entry>
x
</entry>
<entry>
x
</entry>
</row>
<row>
<entry>
Die Unlockzeit wird zurck gesetzt, wenn ein Ticket durch einen Agenten gesperrt wird. In diesem Moment luft die in den Queue-Settings definierte Zeit, solange sich das Ticket in einem offen Status befindet. Wechselt das Ticket in einen Pending-Status, wird die Unlock-Time angehalten.
</entry>
<entry>
x
</entry>
<entry>
x
</entry>
<entry>
x
</entry>
<entry>
x
</entry>
<entry>
x
</entry>
</row>
<row>
<entry>
Die Unlockzeit wird zurck gesetzt, wenn ein Agent einen extenen Artikel am Ticket erstellt.
Als externer Artikel gelten im OTRS Standard Produkt alle Artikel mit dem Artikel-Typ "email-external", "phone", "fax", "sms", "note-ext".
</entry>
<entry>
-
</entry>
<entry>
-
</entry>
<entry>
x
</entry>
<entry>
x
</entry>
<entry>
x
</entry>
</row>
<row>
<entry>
Die Unlockzeit wird zurck gesetzt, wenn ein Kunde ein "Follow-Up" auf ein Ticket sendet und der letzte Artikel von einem Agenten stammt.
</entry>

<entry>
-
</entry>
<entry>
-
</entry>
<entry>
x
</entry>
<entry>
x
</entry>
<entry>
x
</entry>
</row>
</tbody>
</tgroup>
</table>

</sect1>

<sect1 id="pending-tickets">
<title>Erinnerungs Tickets</title>

<para>
Mit OTRS ist es mglich Erinnerungs Tickets zu erstellen. Es kann ein
Zeitpunkt festgelegt werden, zu dem das System eine Nachricht verschickt,
in der es an ein vorher gesperrtes Ticket erinnert. Diese Funktion ist z. B.
dann ntzlich, wenn man daran erinnert werden will einen Kunden zu
kontaktieren, dieser Kunde aber fr die nchsten 2 Wochen im Urlaub ist.
</para>

<para>
Benachrichtigungen fr Erinnerungs Tickets werden legidlich whrend der
Stunden versendet, die in

<link linkend="TimeWorkingHours">
TimeWorkingHours
</link>

festgelegt wurden. Das Modul <filename>bin/PendingJobs.pl</filename>,
welches regelmig mit Hilfe eines cron-Jobs ausgefhrt werden sollte, lst
den Versand der Benachrichtigungen aus.
</para>

</sect1>

<sect1 id="escalate-tickets">
<title>Ticket Eskalation</title>

<para>
OTRS bietet verschiedene Mglichkeit, Tickets im System eskalieren zu lassen. Agenten wird hierbei mit Hilfe des Eskalations-Mechanismus eine Eskalationsmeldung in der Oberflche eingeblendet. Weiterhin bietet OTRS die Mglichkeit, Agenten per Email auf eskalierte Tickets aufmerksam zu machen. Durch die Ticket-Eskalation kann gewhrleistet werden, dass Tickets die ein bestimmtes Alter (oder ein vereinbartes SLA) berschreiten, die notwendige Beachtung bei den zustndigen Agenten finden.
</para>

<para>
Es gibt verschiedene Mglichkeiten die Email-Eskalationen in OTRS zu konfigurieren. Zuerst mssen wir entscheiden, wer Eskalations-Nachrichten zu welchem Zeitpunkt bekommen soll. OTRS bietet hier standardmig zwei verschiedene Varianten.
</para>

<para>
In der Einstellung "NotifyAgentGroupOfCustomQueue" werden alle Agenten benachrichtigt, die die Queue in der sich das eskalierte Ticket befindet, unter Ihren Einstellungen als "Eigene Queue" gewhlt haben und damit die Zustndigkeit fr die betroffene Queue besttigt haben.
</para>

<para>
In der Einstellung "NotifyAgentGroupWithWritePermission" werden alle Agenten benachrichtigt, die Schreib-Berechtigung (rw) auf die betroffene Queue und somit auch auf das eskalierte Ticket besitzen.
</para>
<para>
Hier die "richtige" Einstellung zu finden, ist eine reine Philosophiefrage. Sollen sich alle berechtigten Agenten um eskalierte Tickets kmmern, oder ausschlielich die, die sich fr die betroffene Queue zustndig erklrt haben? Diese Entscheidung muss bei der initialen Konfiguration des Systems, in Abhngigkeit der firmeninternen Prozesse, getroffen werden.
</para>

<para>
Die Eskalationszeiten (Reaktionszeit, Updatezeit und Lsungszeit) knnen in den <link linkend="adminarea-queue"> Queue-Einstellungen</link> und in den <link linkend="adminarea-queue"> SLA-Einstellungen</link> festgelegt werden.
Falls in Ihrem Unternehmen SLAs mit  festgelegten Eskalationszeiten (z. B. in Form eines Service-Katalogs) existieren, macht es Sinn diese in OTRS zu konfigurieren und mit den entsprechenden Eskalationszeiten zu versehen.
Falls keine Services und SLAs verwendet werden sollen, muss die Eskalationszeit in den <link linkend="adminarea-queue"> Queue-Einstellungen</link> hinterlegt werden.
Falls nur eine Teilmenge der Tickets ein SLA zugewiesen bekommt, kann es auch Sinn machen, die Eskalationszeiten in den  den <link linkend="adminarea-queue">Queue-Einstellungen</link> und in den <link linkend="adminarea-queue">SLA-Einstellungen</link> zu hinterlegen.
Die Eskalationszeiten in der Konfiguration des SLA berschreiben hierbei immer die Einstellungen der Queue, falls an beiden Stellen Eskalationszeiten gesetzt wurden.
</para>

<example id='genericagent-job-for-escalated-tickets'>
<title>GenericAgent Job zum Versand von Eskalations Benachrichtigungen</title>

<para>
Mit Hilfe des <link linkend="adminarea-genericagent">GenericAgents</link> knnen Eskalations-Benachrichtigungen per E-Mail an die Agenten versendet werden. In der Datei <filename>Kernel/Config/GenericAgent.pm(.dist)</filename> ist  eine Beispielkonfiguration aufgefhrt, mit der Benachrichtigungen ber eskalierte Tickets an Agenten versendet werden. ffnen Sie diese Datei und entfernen Sie die Kommentarzeichen vor den entsprechenden Zeilen:
</para>

<para>
<programlisting>
%Jobs = (
   # --
   # [name of job] -> send escalation notifications
   # --
   'send escalation notifications' => {
       Escalation => 1,
       # new ticket properties
       New => {
           Module => 'Kernel::System::GenericAgent::NotifyAgentGroupOfCustomQueue',
       },
   },
   # insert your jobs (see Kernel/Config/GenericAgent.pm.examples)
);
</programlisting>
</para>

<para>
Bitte beachten Sie, dass Sie je nach bentigter Konfiguration das zugrunde liegende Eskalationsmodul (siehe oben) anpassen mssen. Mithilfe der nachfolgenden Konfiguration werden die Eskalationsnachrichten an alle Agenten versendet, die Schreib-Berechtigung (rw) auf die betroffene Queue und somit auch auf das eskalierte Ticket, besitzen:
<programlisting>
%Jobs = (
   # --
   # [name of job] -> send escalation notifications
   # --
   'send escalation notifications' => {
       Escalation => 1,
       # new ticket properties
       New => {
           Module => 'Kernel::System::GenericAgent:: NotifyAgentGroupWithWritePermission',
       },
   },
   # insert your jobs (see Kernel/Config/GenericAgent.pm.examples)
);
</programlisting>
</para>
</example>

<para>
Wird ein Ticket erstellt oder in eine andere Queue verschoben, werden dem Agenten zunchst die verbleibenden Eskalationszeiten (Reaktions-, Update-, Lsungszeit) dargestellt. Befindet sich das Ticket in einem fr die Berechnung relevanten Zeitfenster, werden die Eskalationszeiten von diesem Zeitpunkt an herunter gezhlt. Befindet sich das Ticket nicht in den in TimeWorkingHours festgelegten "Arbeitsstunden", oder es ist aktuell ein in TimeVacationDays bzw. TimeVacationDaysOneTime definierter Feiertag, finden keine Berechnungen der Eskalationszeiten statt und die Eskalationszeiten werden angehalten.
Wird der Wert 0 bei einer der Eskalationszeiten erreicht, eskaliert das Ticket. Im weiteren Verlauf wird der Wert negativ, das Ticket hat die Eskalationszeit berschritten. Beim nchsten Lauf des GenericAgent-Jobs, werden die Eskalations-Nachrichten versendet und dem Agenten wird eine Eskalationsmeldung in der Oberflche eingeblendet.
</para>

<para>
Die Reaktionszeit wird auf den konfigurierten Ursprungswert zurckgesetzt, wenn der erste "externe Artikel" (E-Mail, Telefonanruf) am Ticket dokumentiert wird.
</para>

<para>
Die Updatezeit wird auf den konfigurierten Ursprungswert zurckgesetzt, wenn ein "externe Artikel" (E-Mail, Telefonanruf) in Form eines "FollowUps" durch einen Kunden oder einen Agenten am Ticket dokumentiert wird.
</para>

<para>
Die Lsungszeit wird zurckgesetzt, sobald der Ticketstatus in einen Status des Typs "Geschlossen" wechselt.
</para>

<para>
In der nachfolgenden Tabelle werden die Eskalationszyklen/Eskalationseigenschaften der bisherigen OTRS Versionen verglichen.
</para>

<table id="table-of-escalation-mechanismen-firstresponse">
    <title>Eskalations Eigenschaften - Reaktionszeit</title>
    <tgroup cols="5">
        <thead>
            <row>
                <entry>Eskalations Eigenschaften - Reaktionszeit</entry>

                <entry>2.0.x</entry>
                <entry>2.1.x</entry>
                <entry>2.2.x</entry>
                <entry>2.3.x</entry>
              <entry>2.4.x</entry>
            </row>
        </thead>
        <tbody>
            <row>
                <entry>
<para>
Ein Ticket eskaliert, wenn der Kunde nach Ablauf der hinterlegten Reaktionszeit keine Antwort in Form eines "externen Artikels" (Email, Telefonanruf) bekommen hat.
</para>
<para>
Nachdem ein  "externer Artikel" einem Ticket hinzugefgt wurde, wird die Reaktionszeit zurckgesetzt und deaktiviert.
</para>
<para>
Die Reaktionszeit beginnt bei der Ticketerstellung und endet mit dem Anlegen eines "externen Artikels" in Form eines E-Mail oder eines Anrufs.
</para>
<para>
Ob das Ticket von einem Agenten gesperrt ist findet keine Bercksichtigung.
</para>
                </entry>
                <entry>-</entry>
                <entry>-</entry>
                <entry>-</entry>
                <entry>x</entry>
                <entry>x</entry>
            </row>
        </tbody>
    </tgroup>
</table>


<table id="table-of-escalation-mechanismen-update">
    <title>Eskalations Eigenschaften - Aktualisierungszeit</title>
    <tgroup cols="5">
        <thead>
            <row>
                <entry>Eskalations Eigenschaften - Aktualisierungszeit</entry>
                <entry>2.0.x</entry>
                <entry>2.1.x</entry>
                <entry>2.2.x</entry>
                <entry>2.3.x</entry>
                <entry>2.4.x</entry>
            </row>
        </thead>
        <tbody>
            <row>
                <entry>
Ein Ticket eskaliert...
<para/>
<para>a) Wenn eine Aktualisierungszeit fr die entsprechende Queue gesetzt, oder wenn dem Ticket ein SLA mit Aktualisierungszeit zugewiesen wurde.</para>
<para>b) Wenn die in den Einstellungen hinterlegte Aktualisierungszeit abgelaufen ist.</para>
<para>c) Wenn sich das Ticket in einem "offen" Status befindet. Wenn ein "pending" Status gesetzt ist, wird die Eskalationszeit ausgesetzt.</para>
                </entry>
                <entry>x</entry>
                <entry>x</entry>
                <entry>x</entry>
                <entry>x</entry>
                <entry>x</entry>
            </row>
            <row>
                <entry>
Die Eskalationszeit wird zurckgesetzt, wenn ein Kunde einen Artikel am Ticket erstellt (z. B. durch Email-FollowUp). Das Ticket muss dabei nicht wiedererffnet werden. Ist bereits der letzte Artikel von einem Kunden, wird die Eskalationszeit (Startpunkt) nicht zurck gesetzt, da sich hier die Eskalation verzgern wrde.
                </entry>
                <entry>-</entry>
                <entry>x</entry>
                <entry>x</entry>
                <entry>x</entry>
                <entry>x</entry>
            </row>
            <row>
                <entry>
Die Eskalationszeit wird zurckgesetzt, wenn ein Agent einen externen Artikel (z. B. eine Email an einen Kunden oder eine Telefon-Notiz) anlegt.
                </entry>
                <entry>-</entry>
                <entry>x</entry>
                <entry>x</entry>
                <entry>x</entry>
                <entry>x</entry>
            </row>
        </tbody>
    </tgroup>
</table>


<table id="table-of-escalation-mechanismen-solution">
    <title>Eskalations Eigenschaften - Lsungszeit</title>
    <tgroup cols="5">
        <thead>
            <row>
                <entry>Eskalations Eigenschaften - Lsungszeit</entry>
                <entry>2.0.x</entry>
                <entry>2.1.x</entry>
                <entry>2.2.x</entry>
                <entry>2.3.x</entry>
                <entry>2.4.x</entry>
            </row>
        </thead>
        <tbody>
            <row>
                <entry>
<para>
Die Lsungszeit eines Tickets wird berschritten, wenn das Ticket nicht innerhalb der konfigurierten Lsungszeit in einen Status des Typs "geschlossen" wechselt.
</para>
<para>
Durch das Schlieen eines Tickets wird die Lsungszeit deaktiviert und zurckgesetzt.
</para>
<para>
Die Eskalationszeit  beginnt mit der Ticket-Erstellung und endet (Endpunkt) mit dem Schlieen eines Tickets.
</para>
<para>
Ob das Ticket von einem Agenten gesperrt oder frei ist findet keine Bercksichtigung.
</para>
                </entry>
                <entry>-</entry>
                <entry>-</entry>
                <entry>-</entry>
                <entry>x</entry>
                <entry>x</entry>
            </row>
        </tbody>
    </tgroup>
</table>

</sect1>

</chapter>