20.2.4. Procesor Inbound Email şi Sesizări

Configurare Procesor Inbound EMail

Dacă se doreşte activarea unui mecanism automat de interceptare a mesajelor e-mail şi transformarea acestora în sesizări, atunci se va folosi un "Procesor Inbound EMail". Acesta se configurează din fereastra cu acelaşi nume, din meniul SysAdmin / Servicii Email. Datele necesare sunt următoarele:

https://sites.google.com/a/bitsoftware.ro/manual-socrateopen/acasa-as/19-crm/19-3-sesizari/19-4-1-procesor-seizari/Procesor%20Inbound%20Email.png

  • Schedule - se alege frecvenţa dorită pentru rularea automată;
  • Zile jurnalizare - se indică numărul de zile pentru care se păstrează log-ul. Înregistrările de jurnalizare se pot vizualiza în tab-ul Log;
https://sites.google.com/a/bitsoftware.ro/manual-socrateopen/acasa-as/19-crm/19-3-sesizari/19-4-1-procesor-seizari/Setari.png

  • Contul de Inbound Email care este scanat de automat de procesor. Acest cont trebuie definit în prealabil în fereastra "Cont Inbound Email": (a se vedea Inbound Email Account):
    • Denumirea dorită;
    • Tipul de cont (deocamdată implementarea este activă doar pentru conturi de tip Gmail);
    • Folder - opţional, poate fi o etichetă, caz în care doar mesajele cu această etichetă vor fi procesate;
    • EMail - se introduce obligatoriu adresa de email a căsuţei, indiferent de numele utilizatorului acestei căsuţe;
    • În detalii se adaugă o înregistrare pentru accesul la căsuţa de email:
      • ID Utilizator
      • Parola
  • Societatea, Grupul, Tipul de sesizare - care vor fi folosite pentru sesizările create din email (obligatoriu);
  • Categoria, Starea - care vor fi folosite pentru sesizările create din email (opţional);
  • care se va folosi pentru sesizările create din email (opţional);
  • Tipul de proiect pe baza căruia se va determina proiectul care se va folosi pentru sesizările create din email (obligatoriu). Proiectul se determină după următoarele reguli: 
    • proiectul să aibă tipul specificat pe procesorul de inbound, şi
      • să fie definit pentru terţul corespunzător utilizatorului identificat prin adresa From din email, şi
      • să fie activ, şi
      • să fie deschis (neprocesat), şi
      • să fie valid la data curentă
    • Dacă sunt mai multe proiecte care îndeplinesc toate condiţiile de mai sus se va lua proiectul cu ID-ul cel mai mare
https://sites.google.com/a/bitsoftware.ro/manual-socrateopen/acasa-as/19-crm/19-3-sesizari/19-4-1-procesor-seizari/notificari%20mesaje%20email.png

  • Adrese de e-mail pentru a trimite notificări în situaţiile în care anumite mesaje e-mail nu au putut fi procesate şi transformate în sesizări sau acţiuni la sesizări.

Rulare Procesor Inbound EMail

Procesorul, odată definit, se activează prin accesarea ferestrei "Monitorizare Servicii" şi apăsarea butonului "Porneşte tot".

Procesorul se va conecta la contul de inbound email specificat şi va citi toate mesajele de email (indiferent dacă sunt citite sau necitite). Pentru fiecare email procesorul execută următoarele operaţii:
  • Verifică dacă pentru adresa de From din email există un utilizator pe titularul unde rulează procesorul de sesizări. Dacă nu există procesarea acelui mesaj eşuează, mesajul fiind transferat în folderul "Failed".
    • începând cu v15.09 s-a adăugat posibilitatea de a gestiona mesajele eşuate, spre a fi transformate cu succes în sesizări;
    • toate mesajele eşuate se regăsesc în fereastra "Mesaje Inbound Email Netransformate", de unde, un operator poate să le parcurgă şi, în funcţie de motivul de eroare care a dus la neprocesarea mesajului, să rezolve/corecteze problema, iar apoi să lanseze o reprocesare a fiecărui mesaj în parte;
    • erorile pot avea, printre altele, următoarele surse şi acţiuni pentru rezolvarea acestora:
      • adresă expeditor neregăsită între contactele/utilizatorii din SocrateCloud -> 
        • se defineşte contactul respectiv cu adresa de e-mail aferentă, 
        • se aplică o resetare de cache serve+client, 
        • se aplică reprocesarea mesajului;
      • imposibilitatea de a determina toate valorile obligatorii din componenţa unei sesizări ->
        • se verifică şi se corectează definirile din procesorul de inbound email;
        • se verifică existenţa unui proiect pe terţul respectiv, cu tipul de proiect indicat în procesorul de inbound, proiect activ la data curentă! (a se vedea regulile de determinare proiect din paragraful anterior);
        • se verifică definirile necesare pentru a opera cu sesizări de tipul indicat în procesorul de inbound.
  • Verifică dacă mesajul este un reply la un alt mesaj. 
    • Dacă nu este un reply atunci crează o sesizare nouă cu următoarele valori:
      • Societate, Grup, Tip sesizare, Categorie, Stare conform valorilor specificate la configurarea procesorului de sesizari;
      • Terţ: Terţul corespunzător utilizatorului identificat pe baza adresei From din email;
      • Subiect: Subiectul mesajului
      • Sumar: Textul mesajului
      • Ataşamente: ataşamentele de la email dacă există
      • Email notificări terţi - se adaugă toate adresele din mesajul sursă, din "From:", "To:" şi "Cc:"
        • v15.09 - aceste adrese vor fi folosite şi pentru comunicarea acţiunilor de pe sesizare, doar pentru acţiunile cu confidenţialitate "Terţ";
        • v16.01 - aceste adrese vor fi trecute în "Cc:", în loc de "BCc:" pentru ca fiecare destinatar să vadă persoanele implicate şi să poată răspunde prin "Reply to all"
      • Proiect: se determină după următoare regulă: 
        • Proiectul să aibă tipul specificat pe procesorul de sesizări, şi
          • să fie definit pentru terţul corespunzător utilizatorului identificat prin adresa From din email, şi
          • să fie activ, şi
          • să fie deschis (neprocesat), şi
          • să fie valid la data curentă
        • Dacă sunt mai multe proiecte care îndeplinesc toate condiţiile de mai sus se va lua proiectul cu ID-ul cel mai mare. Dacă nu există niciun proiect se va crea sesizarea fără proiect.
      • Sistemul va genera notificare email de creare sesizare nouă conform regulilor standard.
    • Dacă este un reply citeşte primul ID de email din lista de referinţe şi incearcă să identifice pe baza acelui ID sesizarea. Dacă nu există o sesizare cu acel ID de email pe titularul unde rulează procesorul de sesizări procesarea acelui mesaj eşuează. Dacă este găsită sesizarea atunci se adaugă o notă la sesizare cu următoarele valori:
      • Rezultat: Textul mesajului
      • Data acţiune: data curentă
      • Creat de: utilizatorul identificat pe baza adresei From din email
      • Dacă există ataşamente la email acestea se adaugă la sesizare.
      • Sistemul va genera notificare email de actualizare sesizare conform regulilor standard însă din lista de destinatari se exclude expeditorul mesajului.
  • La final dacă procesarea mesajului a fost terminată cu succes mesajul va fi mutat intr-un folder cu numele "Processed". Dacă procesarea mesajului a eşuat mesajul va fi mutat intr-un folder cu numele "Failed". Nu este necesar ca aceste foldere să existe anterior. Dacă nu sunt găsite ele vor fi create automat de către procesorul de sesizări.

Configurare Procesor Sesizări

Procesoarele de sesizări sunt necesare atunci când se doreşte formarea de reguli de alocare, escaladare şi trimitere de alerte în funcţie de anumite evenimente sau funcţie de anumite date din conţinutul sesizărilor.

Aceste "modele de procesare" au fiecare dintre ele parametri de rulare diferiți (tip sesizare, frecvența etc). Funcție de valorile parametrilor folosiți la definirea unui procesor, pentru fiecare din procesoarele definite se execută pașii descriși mai jos la punctele 1.1. - 1.4. Configurarea se realizează din fereastra "Procesor sesizări" din meniul SysAdmin / Reguli Generale / Server.

Procesorul, odată definit, se activează prin accesarea ferestrei "Monitorizare Servicii" şi apăsarea butonului "Porneşte tot".

Reguli de procesare

1.1. Actualizare/alocare Reprezentant
În acest pas se procesează toate sesizările 
  • fără reprezentant
  • neprocesate (nefinalizate/neînchise) 
  • și filtrate pe Tip Sesizare de pe definirea Procesorului de sesizări - doar dacă acest câmp este completat
Pentru fiecare sesizare în parte se încearcă determinarea Reprezentantului după două metode:

1.1.1. Bazat pe reguli de rutare
Aceste reguli(rute) se definesc în tabul Rutare din fereastra Procesor Sesizari
Regulile se parcurg în ordinea secvenței și pentru fiecare regulă în parte
    • dacă pe regula, Tip Sesizare = cu tipul sesizării procesate se setează pe sesizare, ca reprezentant, Utilizatorul configurat pe regula respectiva.
    • dacă pe regula, Tip Sesizare <> de tipul sesizării procesate sau Tip Sesizare nu este configurat, se preia lista de cuvinte cheie (lista se definește în câmpul Cuvant cheie și poate conține mai multe cuvinte delimitate de " ,;\t\n\r\f" ). În cazul în care se identifica (fără a ține cont de CASE pe sumar sau cuvinte cheie) un cuvânt cheie în sumarul sesizării se setează pe sesizare, ca reprezentant, Utilizatorul configurat pe regula respectiva.
1.1.2. Din Procesor sesizari
Se setează pe sesizare, ca reprezentant, valoarea din câmpul Supervizor din definirea procesorului

Se salvează în log-ul procesorului de sesizări (tabul Log din fereastra Procesor sesizări)
  • No unallocated Requests = în cazul în care nu au fost sesizări fără reprezentant
  • Allocated SalesRep = nr de sesizări pentru care s-a reușit setarea reprezentatului , 
  • Not = nr de sesizări fără reprezentant pentru care nu s-a reușit determinarea reprezentantului.
1.2. Procesare sesizări
În acest pas, procesorul generează și trimite alerte funcție de termenul sesizărilor, astfel:

 1.2.1 Sesizări cu Termen = Programat/Scheduled

Alerta se va trimite pentru sesizările care vor trece din Programat/Scheduled -> Datorat


În acest pas se procesează toate sesizările:

  • cu Termen = Programat/ Scheduled

  • cu Data Urmatoarei Actiuni < Data curenta (inclusiv ore, minute etc)

  • neprocesate (nefinalizate/neînchise)

  • și filtrate pe Tip Sesizare din definirea Procesorului de sesizări - doar dacă acest câmp este completat

Pentru fiecare sesizare în parte se:

  • Actualizează Termenul, doar dacă este completată Data Următoarei Acțiuni, astfel:
    • se calculează Data Limita ca fiind Data Urmatoarei Actiuni la care se adaugă nr de zile “Toleranta Data Limita” din definirea Tip Sesizare
      • dacă data curentă este < Data Urmatoarei Actiuni => Termen = Programat
      • daca data curentă este între Data Urmatoarei Actiuni si Data Limita => Termen = Datorat
      • daca data curentă este > Data Limita => Termen = Depasit
  • Verifică dacă noul Termen = “Datorat” și dacă Tipul Sesizării are bifa de “Email la Termen”. În caz afirmativ:
    • se trimite o alerta cu mesajul “RequestDue” (configurat in AD_Message) conform regulilor de la pct. 1.6
      • Subiect email = Solicitarea {nr} - la termen de rezolvare
    • se actualizează pe sesizare Data Ultimei Alerte


Se salveaza în log-ul procesorului de sesizări (tabul Log din fereastra Procesor sesizari)

  • New Due # - numărul de sesizari cu Termen = Datorat

  • (n Email) - n = numarul de emailuri trimise

 1.2.2. Sesizări cu Termen = Datorat

Alerta se va trimite pentru sesizările care vor trece din Datorat - > Depasit


În acest pas se procesează toate sesizările:

  • cu Termen = Datorat

  • cu Data Limita (calculata ca fiind Data urmatoarei actiuni la care se adaugă nr de zile “Toleranta data limita” de pe Tip sesizare) > Data curenta (inclusiv ore, minute etc)

  • neprocesate (nefinalizate/neînchise)

  • și filtrate pe Tip Sesizare din definirea Procesorului de sesizări - doar dacă acest câmp este completat


Pentru fiecare sesizare în parte se:

  • Actualizează Termenul, doar dacă este completată Data Următoarei Acțiuni, astfel:
    • se calculează Data Limita ca fiind Data Urmatoarei Actiuni la care se adaugă nr de zile “Toleranta Data Limita” din definirea Tip Sesizare
    • dacă data curentă este < Data Urmatoarei Actiuni => Termen = Programat
    • dacă data curentă este intre Data Urmatoarei Actiuni si Data Limita => Termen = Datorat
    • dacă data curentă este > Data Limita => Termen = Depasit
  • Verifică dacă noul Termen = “Depasit”, daca Tipul Sesizarii are bifa de “Email peste Limita” și dacă nu a mai fost trimisă o alertă în ziua curentă. În caz afirmativ:
    • se trimite o alerta cu mesajul “RequestOverDue” conform regulilor de la pct. 1.6
    • se actualizează pe sesizare Data Ultimei Alerte

Se salvează în log-ul procesorului de sesizari

  • New OverDue # - numarul de sesizari cu Termen = Depasit

  • (n Email) - n = numarul de emailuri trimise

 1.2.3. Alertă Dată Limită din Procesor Sesizare

Acționează doar dacă la nivelul Procesorului de Sesizare este introdusă o valoare mai mare ca 0 în câmpul Alerta Data Limita (în zile)


În acest pas se procesează toate sesizările:

  • cu Data Limita (calculata ca fiind Data Urmatoarei actiuni la care se adaugă nr de zile din “Alerta Data limita” de pe Procesor Sesizări) < Data curenta (inclusiv ore, minute etc)

  • și

    • fără nici o alerta

    • sau, cu Data ultimei alerte (la care se adaugă nr de zile din Zile Ramase” de pe Procesor Sesizări, în cazul în care Procesorul de sesizări are completat câmpul “Zile Ramase > Data curenta (inclusiv ore, minute etc)

  • neprocesate (nefinalizate/neînchise)

  • și filtrate pe Tip Sesizare de pe definirea Procesorului de sesizări - doar dacă acest camp este completat


Pentru fiecare sesizare în parte se:

  • Actualizează Termenul, doar dacă este completata Data Urmatoarei Actiuni, astfel:
    • se calculează Data Limita ca fiind Data Urmatoarei Actiuni la care se adauga nr de zile “Toleranta Data Limita” de pe Tip Sesizare
      • dacă data curentă este < Data Urmatoarei Actiuni => Termen = Programat
      • dacă data curentă este intre Data Urmatoarei Actiuni si Data Limita => Termen = Datorat
      • dacă data curentă este > Data Limita => Termen = Depasit
  • Verifica dacă Tipul Sesizării are bifa de “Email peste Limita” și dacă nu a mai fost trimisa o alerta în ziua curenta. În caz afirmativ:
    • se trimite o alerta cu mesajul “RequestAlert” conform regulilor de la pct. 1.6
    • Subiect email = Alertă: Solicitarea {nr} a depaşit timpul de aşteptare

    • se actualizează pe sesizare Data Ultimei Alerte

Se salvează în log-ul procesorului de sesizări
  • Alerts # - numarul de sesizari procesate

  • (n Email) - n = numarul de emailuri trimise


 1.2.4. Escaladare către Supervizorul Reprezentantului de pe sesizare

Acționează doar dacă la nivelul Procesorului de Sesizare este introdusă o valoare diferită de 0 în câmpul Escaladare dupa Termen (în zile).

În acest pas se procesează toate sesizările:

  • cu Data Limita (calculata ca fiind Data Urmatoarei actiuni la care se adaugă nr de zile din “Escaladare dupa Termen” de pe Procesor Sesizari) < Data curenta (inclusiv ore, minute etc)

  • neprocesate (nefinalizate/neînchise)

  • fără bifa de Escaladat

  • și filtrate pe Tip Sesizare din definirea Procesorului de sesizări - doar dacă acest câmp este completat

Pentru fiecare sesizare în parte se verifică și escaladează doar sesizările cu Reprezentant setat:

  • Se determină Supervizorul Reprezentantului sau dacă acesta nu există se alege Supervizorul de pe Procesor Sesizare
  • Se trimite o alertă cu mesajul “RequestEscalate” către Reprezentant și către Supervizorul determinat anterior și doar utilizatorilor care sunt angajați (BPartner legat de user are bifa Angajat)
    • Escaladare solicitare {0} la {1}
  • Actualizează Termenul, doar dacă este completată Data Urmatoarei Actiuni, astfel:
    • se calculeaza Data Limita ca fiind Data Urmatoarei Actiuni la care se adauga nr de zile “Toleranta Data Limita” de pe Tip Sesizare
    • dacă data curentă este < Data Urmatoarei Actiuni => Termen = Programat
    • dacă data curentă este între Data Urmatoarei Actiuni si Data Limita => Termen = Datorat
    • dacă data curentă este > Data Limita => Termen = Depasit
  • Actualizează bifa de Escaladat
  • Adaugă o nota pe sesizare cu textul Sesizare Escaladata

Se salveaza în log-ul procesorului de sesizari

  • Escalated # - numărul de sesizări escaladate - independent de faptul ca a fost sau nu trimis email

 1.2.5. Alerte inactivitate

Acționează doar dacă la nivelul Procesorului de Sesizare este introdusă o valoare diferită de 0 în câmpul Zile inactivitate (în zile).

În acest pas se procesează toate sesizările:

  • nu au avut acțiuni în limita de inactivitate: cu Data Limita (calculata ca fiind Data Ultimei actualizari la care se adaugă nr de zile din “Zile inactivitate” de pe Procesor Sesizari) < Data curenta (inclusiv ore, minute etc)

  • neprocesate (nefinalizate/neînchise)

  • cu Data Urmatoarei Actiuni sau Data Ultimei actualizari, la care se adaugă nr de zile “Toleranta Data Limita” de pe Tip Sesizare < Data curenta (inclusiv ore, minute etc)

  • și

    • fără nici o alertă

    • sau cu data ultimei alerte (la care se adaugă nr de zile din Zile Ramase” de pe Procesor Sesizari, în cazul în care procesorul are completat câmpul Zile Rămase) < Data curenta (inclusiv ore, minute etc)

  • și filtrate pe Tip Sesizare de pe definirea Procesorului de sesizari - doar dacă acest câmp este completat

Pentru fiecare sesizare în parte se:

  • Actualizează Termenul, doar dacă este completată Data Urmatoarei Actiuni, astfel:
    • se calculeaza Data Limita ca fiind Data Urmatoarei Actiuni la care se adauga nr de zile “Toleranta Data Limita” de pe Tip Sesizare
    • dacă data curentă este < Data Urmatoarei Actiuni => Termen = Programat
    • dacă data curentă este între Data Urmatoarei Actiuni si Data Limita => Termen = Datorat
    • dacă data curentă este > Data Limita => Termen = Depasit
  • Verifica dacă nu a mai fost trimisa o alerta în ziua curentă. În caz afirmativ:
  • se trimite o alerta cu mesajul “RequestInactive” conform regulilor de la pct. 1.6

    • Alertă de inactivitate: Solicitarea {0}

  • se actualizează pe sesizare Data Ultimei Alerte

Se salvează în log-ul procesorului de sesizari
  • Inactivity # - numărul de sesizări procesate

  • (n Email) - n = numărul de emailuri trimise


1.3. Procesare Status (Timeout)

Acest pas se execută doar dacă pe procesorul curent am configurat un Tip Sesizare sau există Tipuri de Sesizări care nu au un procesor dedicat definit.


În acest pas se procesează toate sesizările:

  • cu stări ce au completate cămpurile Zile Timeout și Stare Urmatoare la definirea lor

  • care au depășit nr de Zile Timeout de la ultima Data actiune de pe tabul Actualizari (nu se tine cont de inregistrarile din Actualizari care nu au completat Data actiune)

  • neprocesate (nefinalizate/neînchise)

  • și filtrate pe Tip Sesizare de pe definirea Procesorului de sesizări -  dacă acest camp este completat; dacă acest camp nu este completat se filtrează pe toate tipurile de sesizări care nu au un Procesor Sesizări dedicat definit.

Pentru fiecare sesizare se încearcă determinarea Stării următoare din definirea Stării curente.

Dacă se reușește se adaugă o nota la sesizare de forma: “Status solicitare expirat: Stare Curenta -> Stare Următoare” și se setează Stare următoare pe sesizare curenta.

În aceste proces se notifica (via mecanism standard de notificări la acțiuni pe sesizare) doar utilizatorii care sunt angajați (BPartner legat de user are bifa Angajat) cu excepția situației când starea sesizării se modifică într-o stare de închis final

Se adaugă în log (Status Timeout #) numărul de sesizări pe care a fost modificat câmpul Stare Sesizare.


1.4. Actualizare Log procesare

Șterge înregistrările din Log care nu mai respectă politica de nr zile jurnalizare (Zile jurnalizare >= 1)

Adaugă în log o înregistrare cu detaliile rulării separate de stringul “ - ”:



1.5. Trimitere email/alerta

Alerta este trimisă către primul din utilizatorii de mai jos (doar în cazul în care acesta este identificabil)

  • Reprezentantul de pe sesizare

  • Reprezentant Proiect de pe Proiectul de pe Sesizare

  • Supervizor de pe Societate de pe Sesizare - doar la alerte

  • toţi utilizatorii din Grupul de pe sesizare şi care au cel puţin un rol

  • toţi utilizatorii din Tip Sesizare / tab Notificări Actualizare

  • toţi utilizatorii din Categorie Sesizare / tab Notificări Actualizare

  • toţi utilizatorii din Starea sesizării / tab Status Updates - direcţi sau din rolul selectat

  • tote adresele din câmpul "Email notificări terţ" de pe sesizare.

Emailul conține:

  • Subiect - Textul primit ca parametru de intrare (motivul alertei) - Se poate customiza limitat in AD_Message

  • Corp email - Sumarul sesizarii

  • Atașament - nu se pot trimite pentru moment atașamente

Se trimite doar către utilizatorii care au în definirea lor:

  • Email Bounced = ‘N’

  • Tip Notificare diferit de “Nimic”