2.12. Fluxuri

Un flux poate fi definit ca un ansamblu de pași ce implică oameni și este folosit pentru a automatiza procese economice. Documente, informații sau sarcini sunt pasate de la un participant la altul în funcție de anumite reguli și proceduri. Un flux este compus din noduri (pași) ce conțin acțiuni. Pentru o tranziție intre noduri, opțional, pot exista condiții. Posibilitatea de definire a tranzițiilor multiple de la un nod la altul permite procesarea paralelă, ceea ce duce la modelarea de scenarii complexe folosind funcționalitatea flux de documente.

În SocrateCloud fluxurile se pot gestiona cu ajutorul ferestrelor din meniul Sys Admin -> Reguli Generale -> Workflow. 

• Fereastra Fluxuri - conține lista completă de fluxuri din SocrateCloud și permite gestionarea acestora;

• Fereastra Activități Flux - conține un istoric cu toți pași efectuați, pentru toate fluxurile parcurse;

• Fereastra Procese Flux - conține un istoric cu toate fluxurile parcurse;

• Fereastra Responsabili Flux - în aceasta fereastra se definesc persoanele responsabile de fluxuri.

Fluxuri

Fluxurile de tip document se gestionează în fereastra Fluxuri din meniul Sys Admin -> Reguli Generale. Sunt disponibile următoarele câmpuri:

• Cod Căutare, Denumire, Descriere, Comentariu - se completează pentru a putea identifica înregistrarea în sistem;

• Tip Flux - din punct de vedere al modului de declanșare, există următoarele tipuri de fluxuri:

  • • "Procesare Document" - sunt acele fluxuri care se declanșează în momentul în care documentul este procesat. Aceste fluxuri pot fi invizibile utilizatorului, în situații de tip introducere document sau pot cel mult solicita utilizatorului să realizeze o anumită acțiune pentru finalizarea procesului;

      • • Un Flux de tip Document controlează stările prin care trec toate tipurile de documente și este inițializat automat când un document este procesat. In SocrateCloud fluxurile de tip document sunt predefinite pentru toate tipurile de documente din sistem. Lista completă de fluxuri se poate găsi în fereastra Fluxuri, localizată în meniul Sys Admin -> Reguli Generale.

• • • • Prin intermediul fluxurilor de tip document utilizatorii pot defini o ierarhie de aprobare;

      • Diagrama fluxului unui document este următoarea:

• • • "Valoare Document" - sunt acele fluxuri care pot fi declanșate în mod automat atunci când, pentru o înregistrare, la salvare, se îndeplinește o condiție (valoare pe un câmp de pe înregistrarea respectivă).

      • poate fi implementat numai pentru tabele care au coloana ”Processing” ! (dacă un astfel de flux este necesar pentru alte tabele decât cele aferente documentelor, atunci trebuie adăugată, ca și customizare, coloana indicată).

      • începând cu v20.03 se pot indica, în tab ”Coloane declanșatoare”, acele câmpuri pentru care se dorește execuția condiționată a fluxului, doar dacă acestea și-au modificat valoarea! Astfel, în aceste cazuri, fluxul este declanșat doar dacă se îndeplinește condiția scrisă în câmpul ”Logica ValDoc” ȘI dacă există modificări de valoare pe câmpurile indicate în tab ”Coloane declanțatoare”.

    • "Tutorial" - fluxuri declanșate prin intermediul ferestrei Setup din meniul Unelte. Detalii în Setup;

• Tabela - tabela aferentă înregistrării care declanșează fluxul;

  • e.g. dacă fluxul se aplică pentru facturi se alege: C_Invoice;

• Logica ValDOC - condiție pentru activarea unui flux de tip "Valoare Document";

  • condiția este verificată doar în momentul salvării unei înregistrări;

  • exista 2 modalități de definire pentru logica activării:

    • condiție SQL - sintaxa de forma "SQL=" + {condiție SQL de tip WHERE}

      • • exemplu: SQL=(Updated=Created AND 1=1) unde Updated și Created reprezintă coloane din tabela selectată

• • • • condiție context - sintaxă specifică SocrateCloud:

        • format: {expression} [{logic} {expression}]

          • expression: @{context}@{operand}{value} sau @{context}@{operand}@{context}@ sau {value}{operand}{value}

        • logic: OR{|} sau AND{&}

          • Obs: a nu se folosii OR și AND, ci simbolurile din dreapta lor;

        • context: orice context global sau de fereastră;

          • prin fereastră se înțelege fereastra din care este operată înregistrarea care declanșează fluxul;

        • value: număr sau text;

          • textul poate sau nu fi încadrat în ghilimele simple;

        • operand: egal{=}, mai mare{>}, mai mic{<}, nu{!} 

      • exemplu: 

        • @AD_Table_ID@=14 | @Language@!GERGER 

        • @PriceLimit@>10 | @PriceList@>@PriceActual@

        • @Name@>'J'

• Nivel Acces Date

• Tip Entitate, Stare Publicare, Versiune, Autor - aceste câmpuri conțin informații despre flux;

• Responsabil Flux - se selectează un responsabil pentru execuția fluxului. Opțiunile disponibile se definesc în fereastra Responsabili Flux;

• Prioritate - indică prioritatea cu care fluxurile de acest tip vor fi procesate de către procesorul de flux;

• Procesor Flux, Background window procesor

• Valid de la, Valid până la - interval de valabilitate pentru flux;

• Start Node - se selectează primul nod din flux;

• Unitate Durată - se selectează o unitate: zi, luna, an, etc. Se utilizează pentru a defini timpul de execuție;

• Limita Durată - durata maxima permisă (în unitatea selectată) pentru o acțiune înainte de escaladare;

• Durata, Cost, Working Time, Waiting Time - sunt folosite pentru validarea unui flux;

După completarea câmpurilor necesare, se apasă butonul Validare Flux a valida și salva fluxul.

Noduri

Un nod reprezintă un pas din fluxul unui document. Definirea unui nod se face în tab-ul Nod. Sunt disponibile următoarele câmpuri:

• Tip Entitate - pentru toate nodurile adăugate de utilizator este obligatorie alegerea tipului "User maintained", astfel încât aceste modificări să nu se piardă în procesul de migrare la o versiune nouă;

• Responsabil Flux - determină modul de selecție a utilizatorului responsabil pentru execuția fluxului (e.g. aprobare). Opțiunile disponibile se definesc în fereastra Responsabili Flux și pot fi de următoarele tipuri:

  • "Invoker" - utilizatorul "invoker" (individ) este determinat după următoarea regulă, în funcție de tipul documentului (dacă există unul definit pe titular se folosește acesta în locul celui de pe system ”Invoker”):

    • utilizatorul aferent reprezentantului de vânzări completat pe document (e.g. comandă);

    • utilizatorul aferent angajatului completat pe document (e.g. necesar de aprovizionare);

    • utilizatorul care a procesat documentul;

    • Utilizator/contact - dacă se selectează, responsabilul va fi acest utilizator;

    • Invoker Supervisor - dacă se bifează, utilizatorul responsabil va fi supervizorul, definit în fereastra Utilizator, pentru utilizatorul "Individ";

    • rolul utilizatorului trebuie sa aibă acces specific la societatea documentului. Fluxurile nu țin cont de bifa "Acces Toate Soc" setată la nivel de rol. Un rol cu bifa "Acces Toate Soc" poate vizualiza cererile de aprobare dar nu poate aproba documentele respective.

    • dacă utilizatorul determinat nu are drepturi de aprobare (rolul/rolurile pe care le are nu au setate drepturi de aprobare), atunci sistemul încearcă deteminarea unui alt aprobator astfel:

      • supervizorul utilizatorului - din definiția utiizatorului, sau dacă acest câmp nu este completat, atunci,

        • supervizorul societății documentului - din definiția societății (Info societăți), sau dacă nici acest câmp nu este completat, atunci,

        • supervizorul societății părinte a societății documentului (idem),

        • dacă până aici nu se determină un utilizator aprobator, atunci sistemul răspunde cu mesajul ”No approver”! 

        • atenție! pentru supervizori nu se verifică dacă au sau nu rol cu drept de aprobare, se presupune că au, odată ce sunt desemnați ca fiind ”supervizori”. Deci e obligatoriu ca orice utilizator desemnat ca ”supervizor” să fie inclus într-un rol care poate aproba documente! Această regulă e valabilă și pentru supervizorii de mai jos.

  • "Organization" - utilizatorul responsabil va fi supervizorul, definit în fereastra Societăți, tab Info Societăți, pentru societatea de pe document.

    • escaladare la SuperUser - dacă nu există setat supervizor pe societe.

    • ”Org LastApprover” - ”Ultimul aprobator societate” - determinat dinamic relativ la ultimul aprobator de tip societate document (Organization), pentru care se determină Societatea nod superior și care are bifa ”Nivel de aprobare”, de pe care se preia supervizorul:

    • dacă Societatea prim determinată nu are bifa ”Nivel de aprobare” atunci se încearcă determinarea unui nod superior cu bifa setată.

  • "Role" - orice utilizator cu acest rol va fi responsabil de flux.

    • ”Payroll Organization” - supervizorul societății din tab ”Salarizare” aferente utilizatorului care a introdus documentul. Pentru cazurile în care sunt mai multe înregistrări în tab Salarizare (angajat pe mai multe societăți, mai multe contracte), determinarea societății se face astfel:

      • societatea cu aceeași ”societate de pontaj” pe care o are și societatea de pe documentul din flux

      • ȘI

      • înregistrarea validă la data documentului.

    • ”BusinessUnit” - ”Departament Loc de muncă” - supervizorul societății Departament (AD_OrgTrx_ID) din tab ”Loc de muncă” aferente utilizatorului care a introdus documentul. Se poate folosi doar dacă există activată componenta HRM. Pentru cazurile în care sunt mai multe înregistrări în tab Loc de muncă (angajat pe mai multe societăți, mai multe contracte => multe departamente), determinarea înregistrării de pe care se citește Departamentul se face tot prin intermediul societății (AD_Org_ID) astfel:

      • societatea cu aceeași ”societate de pontaj” pe care o are și societatea de pe documentul din flux

      • ȘI

      • înregistrarea validă la data documentului

      • ȘI

      • departamentul determinat are bifa ”Nivel de aprobare”;

    • dacă Departamentul prim determinat nu are bifa ”Nivel de aprobare” atunci se încearcă determinarea unui departament nod superior cu bifa setată.

    • ”BU LastApprover” - ”Departament Loc de muncă ultimul aprobator” - determinat dinamic relativ la ultimul aprobator de tip ”Departament Loc de muncă”, pentru care se stabilește Departamentul nod superior și care are bifa ”Nivel de aprobare”, de pe care se preia supervizorul. Se poate folosi doar dacă există activată componenta HRM.

    • ”Area Inspector” - ”Inspector zonal” - inspectorul zonal (AreaInspector_ID) din Info Societăți, conform societății documentului.

      • escaladare la ”Inspector zonal” de pe societatea părinte, dacă societatea nu are setat, inspectorul zonal, sau la SuperUser dacă nu există nicio altă setare făcută.

    • ”Area Supervizor” - ”Supervizor zonal” - supervizorul zonal (AreaSupervizor_ID), din Info Societăți, conform societății documentului.

      • escaladare la ” Supervizor zonal” de pe societatea părinte, dacă societatea nu are setat, supervizorul zonal, sau la SuperUser dacă nu există nicio altă setare făcută.

    • ”Supervisor of LastApprover” - ”Supervizorul ultimului aprobator” - determinat dinamic relativ la ultimul aprobator. Se determină nodul anterior de aprobare prin care a trecut documentul. Se preia userul de pe nodul anterior de aprobare și se determină supervizorul acestuia, din definiția Utilizatorului (AD_User.Supervisor).

                   Observații generale legate de responsabilii de flux: 

• • • Pentru a putea putea escalada fluxurile de aprobare într-un mod previzibil (ca urmare a depășirii timpului de așteptare), se recomandă a se defini câte un supervizor pentru fiecare rol, societate și utilizator din sistem;

    • Dacă se utilizează mai multe nivele de aprobare multiple, se recomandă a se utiliza câte un rol separat pentru fiecare nivel;

      • Dacă supervizorul determinat nu are drepturi de aprobare -> fluxul se lasă suspendat la acest user (adminul va da drepturi ulterior).

    • Este posibilă și indicarea de perioade de înlocuire și înlocuitori pentru aprobatori, prin intermediul ferestrei ”Utilizatori”, tab ”Înlocuitor Utilizator”, opțiunea ”Workflow”. Astfel, sistemul în mod automat, determină pentru toate documentele care așteaptă aprobarea, dacă aprobatorii au indicate perioade de înlocuire (din motive de concediu sau alte indisponibilități) și mută automat documentele respective spre a fi aprobate către înlocuitorii desemnați pentru perioadele respective. Dacă în perioada respectivă nu se intervine/aprobă, sistemul mută automat documentele înapoi la aprobatorul inițial.

    • În situația în care avem mai multe nivele de aprobare și un utilizator a aprobat documentul pe un nivel inferior, acesta nu va trebui să mai (re)aprobe documentul pe un nivel superior, dacă tot el este responsabil pe nivelul respectiv!

• Prioritate - indică prioritatea pentru sesizările generate de nod;

• Start Mode - se selectează felul în care se executa activitatea unui nod:

  • Automatic- este executată automat de către sistem

  • Manual - poate fi executată numai de către un utilizator 

• Finish Mode - se selectează modul în care este finalizata activitatea unui nod;

• Join Element - felul în care tranzițiile multiple ce intra în nod sunt procesate:

  • AND - toate tranzițiile ce intră în nod trebuie procesate;

  • XOR - o singură tranziție ce intră în nod trebuie procesată.

• Split Element - felul în care tranzițiile multiple ce ies din nod sunt procesate:

  • AND - toate tranzițiile ce ies din nod vor fi procesate;

  • XOR -  în funcție de secvență și condiții, doar o singură tranziție ce iese din nod va fi procesată.

• Acțiune - un nod poate avea următoarele acțiuni, descrise mai jos. In funcție de alegere, fereastra Noduri se modifică corespunzător:

  • "Acțiune Document" - se poate alege din listă o acțiune document care va determina starea documentului documentului: "Finalizează", Închis, Pregătire, etc

    • • este posibilă modificarea stării "Neaprobat" ca stare finală, închisă, fără efecte în sistem!

• • • opțiunea "Invalidare" va trece documentul în starea "Invalid";

    • atunci când un document intră în stare Invalid sistemul returnează și Descriere Nod (din Fluxuri/Nod respectiv Descriere Tranziție aferentă nodului care a cauzat intrarea în Invalid - pentru ca utilizatorul să știe de ce nu a putut finaliza documentul. Astfel se pot implementa restricții de completare ale unor câmpuri cu anumite valori. 

• • "Sub Workflow" - pornește un nou flux;

• • • Execuție Subflow:

      • "Sincron" 

      • "Asincron"

  • ”Apps Process” - lansează procesul indicat în câmpul ”Proces”, pentru care parametrii de rulare sunt indicați în tab-ul ”Parametru”.

    • Atenție! procesul trebuie să aibă acordate drepturi de execuție read/write  pentru rolul celui indicat în Responsabil Flux!

• • "Setare Variabilă" - valoarea selectată în câmpul Valoare Proprietate va fi setată pentru coloana din tabela aferentă documentului/înregistrării la care se aplică fluxul;

  • "Alegere Utilizator" - responsabilul de flux poate alege, prin intermediul ferestrei Flux Activități, o valoare pentru o coloană din tabela aferentă documentului/înregistrării la care se aplică fluxul;

  • "Așteaptă (Repaus)" - fluxul va fi în stare de repaus pentru perioada de timp introdusă în câmpul Wait Time;

  • "Email" - acest nod va fi utilizat pentru a trimite email-uri către următorii destinatari după cum urmează:

• • • emailul trimis va conține un atașament cu documentul de pe care a fost declanșat fluxul, în format PDF;

      • formatul de tipărire implicit este cel de pe tipul de document (valabil și pentru Plăți începând cu v20.09);

    • bifa ”După finalizare flux” - indică sistemului să aștepte finalizarea fluxului și implicit a documentului și abia apoi să genereze pdf-ul pentru documentul respectiv!

      • Machetă Email - este permisă utilizarea de machete de e-mail în format HTML pentru notificarea escaladărilor. Pentru trimiterea e-mailurilor datorate escaladărilor se folosesc setările de la nivel de titular System!;

        • începând cu v18.09 s-a adăugat posibilitatea obținerii unui link direct către fereastra ”Flux Activități”, cu filtrare pe ID-ul tabelei şi ID-ul înregistrării. Acesta este util în formarea notificărilor pe email, prin intermediul machetelor de email, trimise din nodurile fluxurilor de procesare/aprobare a documentelor. Astfel, direct din email-ul primit se poate accesa fereastra de aprobare a documentelor, cu documentul aferent gata filtrat. Exemplu pentru documentul (tabela) Necesar de Aprovizionare:

        • <a href="https://dev.socratecloud.com/soweb/locale=ro_RO#Workflow$AD_Table_ID=702&Record_ID=@ID@">Click aici pentru aprobare</a>

        • începând cu v18.12 s-a adăugat posibilitatea completării automate în macheta e-mail folosită, a textului introdus ca răspuns de către aprobator. Acesta se adaugă prin parametrul:

        • @*UserMsg@

    • Adresă fixă - se completează câmpul "email" cu adresa la care se dorește transmiterea mesajelor.

    • Adresă dinamică: se selectează una din valorile din "Email Recipient" cu următoarele valori și semnificație:

      • • regulă generală: e-mail se va trimite doar dacă contactele determinate după regulile descrise mai jos au adresa de email validă și au acceptul de a primi notificări pe e-mail (= au setat ”Tip Notificare” cu ”EMail” sau ”EMail+Notificare”) !

      • Societate Terț - trimite e-mail la supervizorul societății pe care este definit terțul de pe documentul procesat;

      • Terț Document - trimite e-mail la toate contactele terțului de pe document care au adresa de email.

        • lista acestora poate fi redusă controlat dacă se folosește ”Postul”, caz în care va trimite mail doar la contactele terțului de pe document care au în definire același post ca și cel completat în Nod;

        • Terț (Reprezentant) - trimite e-mail la contactul terțului selectat în câmpul ”Terț (Reprezentant)” de pe documentul procesat;

      • Contacte Terț -  trimite e-mail (bcc) la toate contactele terțului de pe document (nu doar la contactul de pe document) și la Reprezentant de pe document (to)

      • Document Owner -  trimite e-mail către:

        • Reprezentantul de pe document pentru: Comenzi, Facturi, Avize, Receptii, Cerere entitate noua

        • Utilizatorul care a introdus documentul pentru: Alocari, Registru Casa, Note Contabile - Simple, Note Contabile - Calup, Bonuri de Transfer, Încasări şi Plăţi

        • Utilizatorul care a actualizat ultima dată documentul pentru: Alocări Cost - Resursă, Capitalizare Cheltuieli Auto pe Proiecte, Capitalizare Om/Ore pe Proiecte, Extrase de Cont, Ajustare Costuri, Confirmări Livrări/Recepţii, Bonuri de Consum, Bonuri de Primire, Confirmări BP/BC, Confirmări Bonuri Transfer, Bonuri de Autorecepţie, Proiecte, Consumuri pe Proiecte, Reevaluare Solduri Conturi în Valută, Reevaluare Stoc cu Notă Credit, Comandă de Lucru, Redevenţe Calculate, Colete, Obligaţii de Plată, Repartizări Generale, Promisiuni Furnizor (F64), Centralizator Documente Aprobate (RDS), TVA Exigibilă, Centralizator Accize, Amortizare, Reevaluare Imobilizări, Alocare Imobilizări, PIF Proiecte Imobilizări, Capitalizare 

        • Angajat pentru: Necesar aprovizionare

      • Reprezentant terț document - trimite e-mail către reprezentantul legat de terțul de pe document = reprezentantul din definirea terțului;

      • Responsabil flux - trimite e-mail către reprezentant sau utilizatorul care a introdus documentul și escaladează la Supervizor Reprezentant;

      • Aprobatori - trimite e-mail către toți cei care au aprobat documentul (inclusiv solicitantul) până la nivelul de la care apare respingerea;

      • Contact Facturare Document - trimite e-mail către contactul de facturare indicat pe document - valabil doar pentru comenzi sau facturi;

        • Contact Livrare Document - trimite e-mail către contactul de livrare indicat pe document - valabil doar pentru comenzi sau avize;

      • Contacte Facturare Terț - trimite e-mail către toate contactele terțului de pe documentul procesat, care sunt marcate cu ”Contact Factură”.

• • "Apps Report" - raportul din SocrateCloud completat în câmpul Proces va fi rulat în momentul procesării nodului;

• • • tab Parametri - se utilizează pentru a defini parametrii raportului;

    • rapoartele generate prin intermediul unui flux document vor fi disponibile sub formă de atașament PDF în fereastra Mesagerie;

      • dacă se apasă butonul ID înregistrare din fereastra Mesagerie se va deschide documentul de pe care s-a generat atașamentul aceasta nota.  

    • procesarea unui nod de tip "Apps Report" va genera o înregistrare în fereastra Fișiere Atasate;

      • dacă se apasă butonul ID înregistrare din fereastra Fisiere Atasate se va deschide înregistrarea din fereastra Mesagerie unde a fost atașat raportul în format PDF;

• • ”Actualizare Înregistrări” - sistemul lansează o actualizare a înregistrării indicate prin intermediul ”Tabelă destinație” și ”Coloană destinație” folosind Lookup SQL -urile indicate în ”SQL destinație” pentru a determina înregistrarea asupra căreia se realizează actualizarea și respectiv ”SQL valoare” pentru a determina valoarea care se înscrie în coloana destinație. Mecanismul înregistrează actualizarea în audit.

• Machetă mail escaladare - se folosește pentru a configura conținutul e-mail-ului care se trimite în urma acțiunii de ”Înainte:” (”Forward”) sau a acțiunii automate de escaladare, de pe fluxul de aprobare a unui document.

• Machetă cere detalii - se folosește pentru a configura conținutul e-mail-ului care se trimite în urma acțiunii de ”cere detalii suplimentare de la:”, de pe fluxul de aprobare a unui document.

• Machetă răspuns cerere detalii - se folosește pentru a configura conținutul e-mail-ului care se primește în urma acțiunii de răspuns la cererea de detalii suplimentare, de pe fluxul de aprobare a unui document.

• Durată, Cost, Working Time, Waiting Time - sunt folosite pentru escaladarea fluxului şi sunt exprimate în unitatea de măsură stabilită în definiţia fluxului.

Observații:

• • toate fluxurile de tip document conțin patru noduri standard ce nu pot fi editate: Start, DocPrepare, DocComplete, DocAuto;

  • textul scris în câmpul "Descriere" de pe nod se va afişa în bara de stare din vizualizarea documentului respectiv, la execuția fluxului.

  • pe documentul cu noduri de aprobare setat se poate genera un nod ad-hoc, din fereastra Flux Activități, folosind "Cere detalii de la". Documentul este direcționat către un alt utilizator căruia i se cer detalii suplimentare.  În listă sunt întorși utilizatori activi de SocrateCloud, legați de un terț cu bifa de Angajat și cu rol asignat. Acesta poate răspunde cu informațiile respective și returna documentul doar către inițiatorul cererii. Această acțiune nu reprezintă o aprobare! Pe formularul de aprobări, aceste ”cereri” sunt marcate cu fundal de culoare galbenă pentru a se putea diferenția ușor de celelalte documente de pe fluxul de aprobare. Dacă există astfel de cereri, pe lângă cele standard de aprobare, procesarea în calup este limitată, fiind aplicabilă doar dacă se selectează documente spre aprobare! Cererile pentru detalii suplimentare trebuie prelucrate individual.

  • aprobarea în calup a activităților selectate vor fi procesate asincron (pe un thread separat); 

    • vor fi vizibile în lista dar sunt ReadOnly și au bifa ”În coadă de aprobare” setată;

    • în cazul în care în timpul aprobării una din activități generează o eroare, acea activitate va fi scoasă din coada aprobare, iar în câmpul mesaj de eroare va apărea eroarea dată (activitatea va apărea în listă cu roșu). 

    • la re-încercarea aprobării unei activități care are eroare, campul ”Mesaj eroare” se va goli, iar dacă erorea a fost soluționată procesul se va rula cu succes.

Tranziții

Pentru a defini un flux sunt necesare reguli de tranziție intre noduri. Acestea se definesc în tab-ul Tranziții. Aici, Următorul Nod poate fi selectat pentru fiecare nod creat. Reguli de tranziție multiple pot fi definite, permițând procesarea în paralel. Cu ajutorul acestei funcționalități, scenarii complexe de fluxuri pot fi modelate în SocrateCloud. Câmpul Secvență din tab-ul Tranziții determină ordinea în care tranzițiile sunt procesate. Felul în care acestea sunt procesate este determinat de câmpurile Join Element și Split Element din tab-ul Noduri. Pentru tranziții definite de utilizator secvența trebuie să fie mai mică de 100 !

Căsuța Std User workflow - dacă este selectată, limitează tranziția numai pentru documente cu o stare deschisă (ex: spre aprobare, sau e-mail, dar nu către complete, void etc). Se recomandă ca pentru nodurile/tranzițiile adăugate de dvs să nu setați această bifă, mai ales pentru nodurile care se execută după DocComplete!

Tip Entitate - pentru toate tranziţiile adăugate de utilizator este obligatorie alegerea tipului "User maintained", astfel încât aceste modificări să nu se piardă în procesul de migrare la o versiune nouă.

Condiții

Pentru orice tranziție se pot seta condiții. O condiție trebuie respectata pentru ca o tranziție intre noduri sa aibă loc. Acestea sunt definite în tab-ul Condiții prin completarea câmpurilor corespunzătoare:

• Tranziție - tranziția pentru care se verifica condiția;

• Secvență - ordinea în care condițiile sunt verificate (dacă sunt definite mai multe condiții);

• And/Or - operatorul logic folosit în condiție (descrie relația intre doua condiții consecutive conform secvenței);

• Coloană - câmpul al cărui valoare va fi comparata;

• Operație - operator folosit în condiție (e.g. ">", "<", "=");

• Valoare - valoarea cu care variabila din coloana este comparată (sunt valori brute, fără posibiltatea de aplicare de conversii funcţie de valuta documentului);

  • pentru comparații cu câmpuri de tip dată singura variantă implementată este cea de tip dată fixă indicată în formatul: yyyy-mm-dd 00:00:00.000

• Tip Entitate - pentru toate condiţiile adăugate de utilizator este obligatorie alegerea tipului "User maintained", astfel încât aceste modificări să nu se piardă în procesul de migrare la o versiune nouă;

Exemple de condiții sql folosite în tranzițiile pentru aprobări din WF:

• Exemplul 1 - condiție folosită pentru intrarea pe fluxul de aprobare a comenzilor care au în câmpul descriere cuvântul "test"

• Exemplul 2 - condiție folosită pentru intrarea pe fluxul de aprobare a comenzilor care au valoarea (fără tva) >=10000, convertită tot timpul la valuta de referință 

Audit Fluxuri

Procesele de flux reprezintă o instantă a unui flux pentru un document. Procesul începe odată cu crearea documentului și se finalizează când ajunge în nodul final. Fereastra Procese flux afișează toate instanțele unui flux de tip document pentru toate documentele din SocrateCloud. Fiecare înregistrare conține informații despre documentul pe bază, starea fluxului și data la care au fost efectuate toate înregistrările asociate procesului.

Activitățile unui proces de flux reprezintă acțiuile care au loc în cadrul procesului de flux și sunt determinate de nodurile aferente, definite pentru flux. Tab-ul Activități afișează activitățile unui proces de flux. Fereastra Activitati flux (toate) afișează acțivitațile pentru toate procesele de flux.

Pe fereastra Procese Flux, în tab-urile Activităţi şi Evenimente s-a adăugat mesajul opţional scris de aprobator in coloana UserMsg. 

Cu ajutorul butoanlelor Gestiune Proces sau Gestiune activitate este posibilă reluarea sau anularea tranziției în curs de desfașurare pentru un proces de flux. Documentul aferent procesului de flux poate fi vizualizat folosind butonul Id Înregistrare.

Procesor Fluxuri

Procesorul de flux este mecanismul responsabil de executarea acelor activităţi ale fluxurilor care ajung în starea "Suspendat". O activitate ajunge în această stare dacă nodul din definiţia fluxului are o acţiune de tipul:

• Aşteaptă (Sleep) sau

• Alegere Utilizator

Dacă în definiţia fluxului nu există astfel de noduri, atunci execuţia fluxului se realizează complet la momentul Finalizării documentului respectiv.

Procesorul de Flux este util doar pentru situaţiile în care avem (definim) fluxuri de tip document la care adăugăm noduri a căror activitate va trebui să aştepte un timp sau o acţiune umană (o aprobare).

Frecvenţa cu care se va seta rularea automată a Procesorului de Flux este dată de unitatea de măsură de timp, cea mai mică folosită, din definirea tuturor fluxurilor de tip document.

Tot la nivel de procesor se pot indica:

• numărul de zile după care se trimite o alertă de inactivitate ("Inactivity Alert Days");

• numărul de zile după care se trimite un email de re-notificare ("Reminder Days").

Acestea fiind atinse, procesorul va trimite un email către "Supervisor". Atenţie! utilizatorul indicat aici (implicit "System"), trebuie neapărat să aibă definită adresa de e-mail în fereastra de definire a utilizatorilor.

Pentru ca sistemul să poată trmite e-mail-uri, este obligatorie configurarea datelor de acces aferente serverului de e-mail, în fereastra Titular, atât pentru titularul curent cât și pentru titularul System.

În amănunt, Procesorul de Flux realizează următoarele:

1. Pornește toate procesele de flux de tip document care:

   • sunt in starea “Pornit”, și 

   • au “Scheduled Start date” = <null> sau < data curentă;

2. Porneste toate activitațile de flux care:

   • sunt în stare suspendată, și

   • pentru care data “Așteptare Stop” < data curentă, și

   • nodul de flux legat are acțiunea = “Aşteaptă (Sleep)”;

3. Actualizează prioritatea pentru activitățile de flux care:

   • sunt în stare suspendată, și

   • doar pentru acțiuni cu nodul de flux de tip "Alegere Utilizator" și cu valori indicate pentru “UM Schimbare Prioritate” și “Schimbă Prioritatea” (= schimbare dinamică de prioritate):

     • pornind de la nivelul de prioritate stabilit în definiția nodului (de tip Acțiune utilizator), prioritatea se poate schimba dinamic odată cu fiecare rulare a procesorului de flux.

       • exemplu se poate obține o creștere cu +5 la fiecare rulare a procesorului.

       • se pot seta noduri care să crească cu o prioritate mai mare sau mai mică odată cu fiecare rulare a procesorului de flux.

       • UM indică perioada care, dacă a trecut, duce la creșterea priorității cu valoarea din câmpul ”Schimbă Pioritatea”

4. Trimite alerte astfel:

   • Alerte de Prioritate - se trimit doar daca “Alertă prioritate” de pe procesorul de flux > 0.

   • Alertele pentru Activități de Flux

     • se trimit doar dacă activitățile:

     • sunt în stare suspendată, și

     • au prioritate >= “Alerta prioritate” de la procesorul de flux, şi

     • data “Ultima alertă” = null sau data “Ultima Alertă” + ”Zile Ramase” (de pe procesor) < data curentă (ultima condiție doar dacă "Zile Ramase” > 0);

     • Alerta se trimite la:

       • “Utilizator/contact” de pe activitate, și

       • “Utilizator/contact” de pe proces flux, și

       • “Supervizor” de pe procesor flux, și

       • “Responsabil flux” de pe activitate flux după cum urmează:

         • dacă responsabilul este de tip "Individ", la utilizator;

         • dacă responsabilul este de tip "Societate", la supervizorul de pe societatea documentului pentru care s-a pornit fluxul;

         • dacă responsabilul este de tip Rol la toți utilizatorii din rol;

         • “Responsabilul flux” de pe proces flux doar dacă a mai fost trimisă cel puțin o alertă înainte (data “Ultima Alertă” de pe activitate de flux are deja valoare) si “Responsabilul flux” de pe proces flux <> “Responsabil flux” de pe activitate flux. Destinatarul final se determină în funcție de tipul de responsabil, ca mai sus.

   • Alerte pentru Expirare timp maxim aşteptare pentru activitate

     • se trimit pentru toate activitățile de flux care:

       • sunt în stare suspendată, și

       • data [“Aşteptare stop” (de pe activitate) - ”Zile Ramase” (de pe procesorul de flux, de pe system)] < data curentă, și

       • data “Ultima alertă” = <null> sau data “Ultima alertă” + ”Zile Ramase” < data curentă (ultima condiție doar dacă "Zile Ramase” > 0), și

       • nodul de flux legat de activitate are acțiunea <> “Asteaptă (Sleep)”

       • Alerta se trimite la:

         • “Utilizator/contact” de pe activitate, și

         • “Utilizator/contact” de pe proces flux, si

         • “Responsabil flux” de pe activitate flux după cum urmează:

           • dacă responsabilul este de tip "Individ", la utilizator;

           • dacă responsabilul este de tip "Societate", la supervizorul de pe societatea documentului pentru care s-a pornit fluxul;

           • dacă responsabilul este de tip "Rol", la toți utilizatorii din rol;

           • “Responsabilul flux” de pe proces flux doar dacă a mai fost trimisă cel puțin o alertă înainte (data “Ultima Alertă” de pe activitate de flux are deja valoare) si “Responsabilul flux” de pe proces flux <> “Responsabil flux” de pe activitate flux. Destinatarul final se determină în funcție de tipul de responsabil ca mai sus;

   • Alerte de inactivitate - se trimit doar dacă “Zile inactivitate” de pe procesorul de flux > 0.

     • se trimit pentru toate activitățile de flux care:

       • sunt in stare suspendată, și

       • (data ultimei actualizări + “Zile inactivitate”) < data curentă, și

       • data “Ultima alerta” = null sau data “Ultima alertă” + ”Zile Rămase” (de pe procesor) < data curentă (ultima condiție doar dacă "Zile Rămase” > 0);

       • Alerta se trimite la:

         • “Utilizator/contact” de pe activitate, și

         • “Utilizator/contact” de pe proces flux, și

         • “Responsabil flux” de pe activitate flux după cum urmează:

           • dacă responsabilul este de tip "Individ", la utilizator;

           • dacă responsabilul este de tip "Societate", la supervizorul de pe societatea documentului pentru care s-a pornit fluxul;

           • dacă responsabilul este de tip "Rol" la toti utilizatorii din rol;

           • “Responsabilul flux” de pe proces flux doar daca a mai fost trimisa cel puțin o alertă înainte (data “Ultima alertă” de pe activitate de flux are deja valoare) și “Responsabilul flux” de pe proces flux <> “Responsabil flux” de pe activitate flux. Destinatarul final se determină în funcție de tipul de responsabil ca mai sus.

5. Verificare - escaladare aprobări

   • se verifică toate activitățile de flux care:

     • sunt în stare suspendată, și

     • pentru care data “Așteptare Stop” < data curentă, și

     • au acțiunea, de pe nodul de flux legat, de tip "Alegere Utilizator"

   • se determină utilizatorul de pe activitate şi se caută supervizorul pentru a face escaladarea astfel:

     • supervizor direct, sau

     • supervizor societate document, sau

     • supervizor societate părinte al societății document (în conformitate cu definiţiile din "Info Societăţi" !)

   • dacă nu găseşte supervizor -> activitatea şi procesul în întregul său se termină cu starea "abort" (Anulat);

   • dacă găseşte supervizor pune o nouă dată “Aşteptare Stop” = data curentă + “Limită durata” de pe nodul legat de activitate (în UM indicată în definirea fluxului) şi alocă activitatea de aprobare către noul utilizator.

Cerere definire entitate nouă

Această nouă funcționalitate (v20.09) oferă posibilitatea de a gestiona cerințele utilizatorilor cu privire la adăugarea de entități noi (ex: articole, gestiuni, terți etc), cerințe care trebuie analizate, verificate, aprobate și la final adăugate în nomenclatoarele aferente entității respective. Pentru a putea gestiona acest flux, de la cerere la aprobare și definirea finală a entității, se folosește fereastra denumită ”Cerere entitate nouă”, localizată în meniul ”Setup inițial”. Prin intermediul acesteia se gestionează documentele prin care se efectuează cererile de definire de noi entități. Funcționalitatea este în curs de dezvoltare și deocamdată suportă următoarele entități:

• • Gestiuni

Prin adăugarea unui nou document se cere definirea unei noi entități. Documentul se supune unui flux standard ce include stările: Draft, In Pregătire, Finalizat. În momentul în care documentul a ajuns în starea Finalizat, entitatea cerută poate fi definită în nomenclatorul aferent acesteia.

Fluxul documentului poate fi ajustat și completat pentru a respecta regulile interne ce se impun în cadrul companiei privind definirea de noi entități. Astfel, se pot adăuga pași de verificare, de aprobare, pe unul sau mai multe nivele, astfel încât, la final, cerința să fie corectă și completă și entitatea să poată fi definită cu succes în sistem.