Posted on

eFactura

Stare facturi

În soluția Sfera ERP există suport complet pentru utilizarea sistemului eFactura impus de ANAF, atât pentru facturile trimise cât și pentru cele primite.
Soluția dezvoltată de Sfera Software include operațiile de comunicare cu serverele ANAF, obținerea automată de token-uri de autorizare și gestionarea integrală a documentelor transmise prin acest sistem.

Lista facturi trimise.

Situația facturilor se poate vizualiza  în tabelul, „Situatie eFactura”, în care vor apărea informațiile despre toate  facturile care sunt încă în stadiul de a fi trimise către platforma e-Factura. Facturile care încă nu au fost trimise sau acceptate de către platformă și au data mai mare de 5 zile lucrătoare decât data curentă, vor fi marcate cu roșu.

La intrarea în aplicație, poate fi configurat să apară un mesaj cu sinteza stadiului facturilor care nu au fost trimise cu succes.

Printout XML factura trimisa.

Fișierul XML al facturii de trimis, se poate vizualiza în printout-ul eFactura din documente de vânzare.

Lista facturi primite prin SPV.

În cazul facturilor primite prin SPV, acestea se pot vizualiza sub formă de tabel și se pot deschide una câte una pentru vizualizarea detaliilor. Este prezentă și o operație de asociere cu documentele introduse în Sfera ERP astfel încât urmărirea perechii Factură de cumpărare – Factură primită prin SPV sa fie completă.

Posted on

SAF-T

Sfera Software vine în sprijinul companiilor care sunt implicate în procesul de digitalizare a transferului de informații contabile către autoritățile fiscale, presupus de noul standard de audit SAF-T.
Simplificăm procesul de raportare SAF-T, prin includerea Declarației 406 în aplicația Sfera ERP. Am redus aproape la zero impactul acestei declarații asupra utilizatorilor SferaERP, singurele date necesare fiind cele din nomenclatorul tarifar, care se completează asistat de către Sfera Software.

Posted on

Soluție de turism cu Sfera ERP

Unul dintre atuurile deosebit de puternice ale sistemului Sfera ERP este flexibilitatea sa. Iată cum, cu minime modificări ale aplicației am implementat o soluție pentru operarea, urmărirea și managementul activității unei agenții de turism.

Elementul central este pachetul turistic care reprezintă legătura între operațiunile asociate unui contract de servicii turistice între agenția de turism și client. Aceste pachete turistice se definesc în Sfera ERP în modulul de Global Management ca proiecte de tip PT.

Astfel, o vînzare de PT se face pe baza unui document de vînzare normal (FV_PT),  care are ca și caracteristică asocierea cu PT-ul în linia cu serviciul turistic. Prin asocierea PT-urilor pe liniile documentelor implicate se va putea face ulterior o urmărire consolidată a fluxului de documente asociat unui PT.

Serviciile și cheltuielile incluse în pachetul turistic sunt achiziționate de către agenție cu documente de cumpărare (FC_PT) similare FV_PT-ului sau, în cazul diurnelor, direct prin avansuri spre decontare, ambele tipuri de documente fiind asociate PT-ului respectiv. În cazul în care un FC_PT include servicii ce se vor constitui ulterior în mai multe pachete turistice (de ex. se achiziționează mai multe camere într-un hotel, urmînd ca acestea să facă obiectul unor vînzări separate spre clienți diverși), aceste servicii se vor distribui pe pachete printr-un document de distribuție valorică (DV_PT).

De asemenea, relaționarea documentelor de vînzare/cumpărare cu documentele financiare (Plata în avans, OP, Chitanță) permite urmărirea închiderii dpdv financiar a PT-urilor.

Situația în fiecare moment a pachetului turistic poate fi urmărită în mod centralizat, aplicația afișînd toate documentele implicate structurate într-un tabel, utilizatorul avînd la dispoziție o imagine clară a PT-ului.

Iată un scenariu:

Pentru Revelionul anului nou se achiziționează în luna mai de la Hotel Orizont un set de 25 de camere pentru 6 nopți fiecare și un set de 10 camere pentru 4 nopți fiecare. Acestea vor face obiectul a mai multor contracte de servicii de turism separate.

Această achiziție va apărea pe documentul FC_PT.1400 cu data de 25 mai 2018.

10 Camere vor fi “vîndute” în luna septembrie, 10 în luna octombrie și alte 15 în luna noiembrie. Pe măsura vînzării se vor crea cîte pachete turistice (PT) este necesar (maxim 35) care vor fi urmărite și operate individual.

Pentru fiecare dintre PT-uri va apare un document DV_PT ce va conține valoarea de vînzare a serviciului de turism și PT-ul aferent. În cazul nostru, o cameră sau mai multe la Hotel Orizont pentru numărul respectiv de zile.

 

Posted on

Coduri dinamice

În încercarea de a defini cât mai complet o entitate – de exemplu un articol – ne putem lovi de lipsa caracteristicilor (sau codurilor) necesare. Aproape întotdeauna voi găsi în aplicații posibilitatea introducerii unui cod de bare, cod articol, cod furnizor sau chiar câteva în plus dar ce fac dacă vreau să-mi codific articolul de exemplu după culoare ori un alt criteriu, sau să am în paralel și codurile unor clienți importanți pentru care sunt furnizor (keyaccounts)?
Sfera ERP rezolvă toate aceste situații prin structura de Coduri Dinamice. Aceasta este o facilitate completă ce permite extinderea caracteristicilor unor entități (clienți, articole, servicii, itemuri contabile), în funcție de nevoi.

Codurile dinamice se pot accesa din formul entității (ART, ITEM, SV, CLT), intrând pe o înregistrare oarecare, apoi în pagina <4 Date Generale>, în secțiunea Coduri dinamice (dreapta jos), se apasă butonul cu 3 puncte […].

În mod particular, codurile dinamice ale articolelor (de tip stocabil, serviciu sau contabil) pot fi accesate direct din <Date Generale -> Coduri dinamice articole> sau cu comanda DART (Alt-X -> DART -> Enter).

Se va deschide formul de inserare/actualizare/ștergere coduri dinamice unde îmi pot defini oricâte coduri îmi sunt necesare.

În definirea unui cod dinamic pot stabili dacă acesta va avea valori numerice sau de tip text.

Pentru utilizarea efectivă a unui cod, acesta se alege pe entitatea pe care o editez prin click dreapta pe grid, apoi Add pentru selecția codului dinamic și se completează valoarea acestui cod.

Observații:
Codurile dinamice sunt supuse mecanismului de securitate al aplicației conform drepturilor utilizatorilor, pentru a se putea proteja datele sensibile, drept urmare la definirea de către supervisor a unui cod dinamic vor trebui date drepturi în consecință.

În plus, orice editare sau adăugare de cod dinamic este monitorizată de jurnalul de operații al sistemului, jurnal ce pentru acest caz poate fi consultat din pagina <3 Istoric>

Posted on

Rapoarte extinse

Orice sistem de business management are până la urmă misiunea de a consolida datele introduse, în situații și rapoarte specifice. Cu cât acestea sunt mai bine gândite și ușor de exploatat, cu atât și deciziile ce se iau pe baza consultării lor sunt mai rapide.

În Sfera ERP în afară de rapoartele de tip integrat ce au maximum 2 nivele de detaliu, există și categoria de rapoarte extinse ce pot fi construite pe un număr teoretic nelimitat de nivele de detaliere. În destule cazuri nu este necesar, dar apar situații când de exemplu contexte complexe de vânzări pot fi consultate pe familii și subfamilii de articole, grupate ulterior pe categorii de clienți ca mai apoi să fie accesibila chiar informația de la nivelul tranzacțiilor de vânzare. Exemple pot fi multe și toate pot fi implementate fără probleme. Practic, limita este dată doar de nevoile reale ale afacerii și imaginația factorilor de decizie. Generatorul de rapoarte din Sfera ERP sigur răspunde la orice cerință bazată pe datele introduse în sistem.

 

Posted on

Performanțe notabile

Sistemul Sfera foloseste modelul n-Tier cu o suită de 3 servere la stratul intermediar (servere ce au atribuţii distincte), un client subţire în partea superioară (Sfera ERP ThinClient) şi server de baze de date la baza modelului.

Serverul de baze de date, poate fi orice server relaţional bazat pe limbaj de  interogare structurat (SQL). Aceste servere pot rula pe platforme Windows, Linux, Unix, OS/400 şi altele.

Sfera Application Server, este serverul de aplicaţie propriu-zis, care înglobează toată logica Sfera ERP şi tot ce înseamnă prelucrare de date.
Sfera Messaging Server, este un server auxiliar ce rulează procese de control, licenţiere şi broadcasting între clienţii aplicaţiei (Sfera ERP ThinClient) şi între clienţi şi serverul de aplicaţie.
Sfera Query Server, este un server auxiliar cu atribuţii exclusive de interogare paralelă a bazei de date. Acest server a fost dezvoltat pentru îmbunătăţirea accesului la date şi micşorarea timpilor de răspuns a interogărilor complexe iniţiate de catre client.
Sfera ERP ThinClient, constituie interfaţa dintre utilizator şi aplicaţie, spaţiul efectiv de lucru în sistemul Sfera ERP.

Toate cele patru entităţi ce constituie aplicaţia Sfera ERP sunt dezvoltate în tehnologie multi-threading, acest lucru aducând o îmbunătăţire considerabilă a performanţelor de lucru faţă de sistemele standard single-thread.

Am avut curiozitatea să facem niște masurători de performanță. Iată-le:

Viteză de raspuns – o interogare complexă pe circa 1.250.000 înregistrări în orice nomenclator pe un server MSSQL uniprocesor durează < 15 secunde.

Operare fluentă – Aprox. 90 secunde la introducerea unui document. (Factura de vânzare cu elementele constituente definite (articole, etc..) şi care are între 5 şi 10 linii).

Rapoarte rapide – 210 pagini în < 30 secunde – raport complex de mişcare stocuri.

Calcul stocuri în timp real – Prin optimizarea extensivă a fluxului de procesare intern aplicatiei, se calculează on-line la validarea documentului (cantitativ şi valoric) indiferent de data acestuia.

Număr de utilizatori – Nelimitat teoretic (limitele sunt impuse doar de maşinile pe care rulează serverele).

Posted on

Tehnologie si infrastructura state-of-art.

Structura majorităţii aplicaţiilor de tip ERP este construită după modele client-server. Acest tip de model presupune existenţa a două nivele. Primul sau cel mai de jos este serverul de baze de date (responsabil în principal cu gestionarea şi stocarea datelor), iar cel de-al doilea este nivelul client sau aplicaţia propriu-zisă. Ca aplicaţia să se constituie într-un sistem de prelucrare a datelor funcţional, este necesară implementarea de funcţii şi proceduri de prelucrare a datelor (validări, verificări, consolidări, etc…) denumite generic business-logic (BL). BL este ”împărţit“ pe cele două nivele în funcţie de modul de concepţie al aplicaţiei ERP, această difuzie ducând inevitabil la dificultăţi şi timpi mari de dezvoltare ulterioară acesteia şi a adaptării sale la noi cerinţe.

 

Următorul pas în evoluţia sistemelor de baze de date îl constituie modelul MultiTier (sau n-Tier), model din care face parte si Sfera ERP. În acest model, între cele două nivele amintite mai sus apare stratul de mijloc (sau middle-tier), strat care poate fi constituit dintr-o serie de servere intermediare (numite în general servere de aplicaţie), fiecare având rolul său specific în cadrul sistemului. Odată cu apariţia acestui strat intermediar, structura celor două nivele de la extreme se schimbă radical, astfel încât în serverul de baze de date implementarea logicii aplicaţiei devine opţională, iar în extrema de sus (la client) nu mai este nevoie de nici o formă de prelucrare a datelor acest atribut revenind în general în totalitate serverelor din middle-tier. Aşa se face că aplicaţia client devine o aplicaţie care tratează doar aspecte ale interfeţei cu utilizatorul (numită şi aplicaţie thin-client – client subţire) iar serverul de baze de date va fi degrevat de tot ce înseamna BL, în sarcina sa rămânând doar procesele de stocare şi gestiune la nivel jos ale acestora (securitate, logare, stocare fizică, izolări tranzacţionale, etc…). Rolul major în prelucrarea logică le revine serverelor (sau serverului – în cazul 3-tier) de aplicaţie.

 

Ca urmare, modelul n-Tier (inclus in Sfera ERP) are o serie de avantaje faţă de modelul 2-tier (sau Client-Server) :

  • Adaptare imediată la nevoile de prelucrare distribuită a bazelor de date. Asta inseamna ca acest model se pretează oricărei configuraţii de lucru a organizaţiei, indiferent câte departamente, filiale, puncte de lucru sau de centralizare a informaţiei are şi indiferent cum sunt poziţionate acestea în diagrama de funcţionare a organizaţiei.
  • Portabilitate aproape nelimitată pe diverse baze de date ca urmare a faptului că logica aplicaţiei nu se scrie la nivelul serverului de baze de date. Sistemele n-Tier se pot folosi de practic oriceserver de baze de date relaţionale (Oracle, MSSQL, PostGreSQL, MySQL, DB2, ş.a.),  portarea aplicaţiei de pe un server pe altul fiind o chestiune ce nu necesită timp de dezvoltare îndelungat.
  • O mai mare flexibilitate a lucrului în medii hibride cu sisteme de operare multiple (de ex. clienţi Windows şi servere de baze de date Linux). Interfaţarea clientului cu serverul de baze de date se face prin middle-tier, acesta putând fi dezvoltat pentru diverse platforme (Windows, Linux, etc…). Odată cu acest avantaj apar şi beneficii cu aspect financiar prin folosirea de sisteme de operare şi servere de baze de date cu preţuri reduse.
  • Micşorarea spectaculoasă a traficului între client şi servere astfel încât utilizatorii pot lucra on-line (chiar daca astazi cazul se întalneşte prea rar) şi pe linii dial-up. Odată ce partea de BL a fost concentrată în middle-tier, între client şi serverele de aplicaţie traficul este de redus, acesta rezumându-se la transmiterea în exclusivitate a modificărilor de date şi lansarea în execuţie prin comandă a diverse procese ce se desfăşoară la middle-tier.
    Astfel, costurile de comunicaţie scad drastic nefiind necesare canale de volum mare de trafic între clienţi şi servere.