RO | EN

1. Lichidități

Pregătirea ordinelor de plată

Procesul de pregătire a ordinelor de plată a fost îmbogățit. Acum,utilizatorul poate gestiona și plățile în avans pentru comenzi. La fel ca în procesul de planificare a plăților - unde această funcție a fost oferită în versiunea 5.9.0.0 - începând cu această versiune, în cele 3 etape ale procesului de pregătire a ordinelor de plată utilizatorul poate vizualiza și comenzile furnizor/creditor, în funcție de valoarea criteriului "Tip intrare".

Utilizatorul are astfel posibilitatea de a adăuga plăți în avans pentru cele care trebuie mai întâi aprobate și apoi, în ultimul pas, trebuie să rezulte documentul de tranzacție corespunzător (documentul de plată).

• Inițial, în etapa 1, din ecranul de pregătire a ordinelor de plată, este posibil să se vizualizeze, utilizând criteriul "Tip intrare", facturile (previziuni confirmate) și ordinele (ieșiri programate) care au fost efectuate și nu au fost încă plătite (nu au fost transformate în facturi). Noul criteriu este afișat în grupul de parametri "Toate" și se numește "Tip intrare". Valorile disponibile sunt:

• • Previziuni confirmate - facturile furnizor/creditor (valoare implicită)

  • Ieșiri planificate - comenzile furnizor/creditor

  • Toate.

• Pentru fiecare cont comercial există 2 rânduri - atâta timp cât există documente atât în categoria facturi, cât și în categoria comenzi - și fiecare rând însumează toate documentele din fiecare caz. În rândul 1 și coloana "Suma datorată", utilizatorul poate vizualiza totalul facturilor restante, iar în rândul 2 - totalul comenzilor deschise.
  Linia de comenzi va fi afișată într-o culoare distinctă verde.

  • La nivelul 2 - la fel ca în cazul facturilor deschise - puteți vedea comenzile cu suma lor deschisă în detaliu, a cărei sumă apare cumulativ la nivelul 1 sub "Suma datorată".

• După introducerea sumei de plată și cu ajutorul butonului Next, se creează documentele ordinului de plată (tip PSD).În a 2-a etapă, "Aprobarea ordinelor de plată", utilizând din nou criteriul "Tip intrare", utilizatorul poate vizualiza DSP-urile care au rezultat din facturi și/sau comenzi. Selectarea acestora și finalizarea acțiunii semnalează aprobarea lor.

• În cele din urmă, în etapa a-3-a, ordinele de plată aprobate sunt convertite în documente de tranzacție. Și în acest caz, ca și în Planificarea plăților, pentru documentele care vor rezulta din ordinele de plată, tipul de document este specificat în parametrul societății "Procesul de planificare a plăților" = 16 (Tip document pentru crearea automată a "depozitelor").

2. Îmbunătățiri diverse

• În pagina "Documente" din cadrul contractelor de cont comercial, a fost făcută o îmbunătățire, astfel încât utilizatorul să poată vizualiza documentele de cheltuieli de vânzare pentru cazurile de contracte cu furnizorii.

• În vizualizarea "Jurnal istoric tipuri de date", pentru o mai bună gestionare a pachetelor de date, a fost adăugat parametrul "Consum", cu valorile disponibile: Toate, Nu, Da.

• În căutarea clientului, în Retail, numărul de telefon mobil al clientului a fost adăugat la rezultate.

• Planul de proprietate 2-CARD a fost mărit. S-a rezolvat o problemă care stabilea tipul de linie al contului de lichidități la valoarea Actual, atunci când contul de lichidități nu este legat de o tranzacție cu cardul.

• Îmbunătățirea timpului de căutare atunci când se caută un client după numărul său de telefon, în acțiunea "Selectare client" din vânzarea cu amănuntul.

• Suport pentru salvarea documentelor relevante în vouchere.

3. Funcționalitate orizontală (framework)

Export imagine

În vizualizarea de export sau în Bit-ul Excel, este acum posibil să exportați corect fotografii. Din acest motiv, în dialogul "Export avansat de date" care apare în vizualizările și în bara de instrumente a Bit, a fost adăugat flagul "Export imagini", care este implicit doar în cazul exportului în Excel. Dacă, de exemplu, în vizualizarea produsului: "Catalog articole cu fotografii", utilizatorul selectează exportul fotografiilor articolelor, rezultatul va fi următorul: 

În cazul unui volum mare de date fotografice, se recomandă de-selectarea indicatorului, pentru a evita întârzierile lungi și o povară de timp în exportul în Excel.

Am îmbunătățit ecranul "Export avansat de date" utilizat în vizualizări și Bits pentru a exporta rezultatele în diferite formate (xls, xml, ascii etc.), pentru a-i conferi aspectul seriei 5.

Livrarea de e-mailuri

În această versiune, a fost efectuată implementarea necesară pentru a sprijini livrarea de e-mailuri prin Gmail prin intermediul aplicației, după modificările efectuate de Google în metoda de certificare.

În special, autentificarea clasică prin nume de utilizator și parolă a încetat să mai funcționeze și acum, urmând metodele moderne de certificare, este afișat un dialog cu autentificare multifactorială (MFA).

Mai exact, au fost efectuate următoarele modificări:

1. S-a adăugat parametrul de companie ES_MAIL_CLIENT_info_FILE

2. În câmpul Profil de comunicare a fost adăugat ClientInfoFile 

În opțiunile câmpului Metoda de livrare (Send_Mail_Service) din Profil de comunicare, cum ar fi cu Office 365, au fost adăugate două noi metode de livrare, prin Gmail (Server) și Gmail (Client). 

- Gmail (Server)

O nouă metodă de livrare a e-mailurilor prin Gmail. Aceasta utilizează bibliotecile open-source MimeKit și Google.Api care rulează pe .NET Framework 4.8. E-mailul este trimis direct prin API-ul Gmail. Acesta este utilizat în principal pentru livrările server-side, unde nu este permisă utilizarea interfeței de utilizator și, prin urmare, automatizarea dialogului. Cu toate acestea, poate fi utilizat și în livrările prin client. Implementarea fluxului OAuth cu 2-laggs (2LA) pentru comunicarea de la server la server.

Cerințele Google pentru a sprijini acest flux sunt următoarele:

1. Spațiul de lucru Google (Google Workspace)

2. Aplicație cu acces la API-ul de Gmail

3. Cont de serviciu cu acces la nivel de domeniu pentru aplicație

4. Secret-client pentru aplicație.

Aplicația poate trimite e-mailuri ca serviciu. Utilizatorul folosit pentru livrare este expeditorul e-mailului. Aceasta înseamnă că se poate trimite cu orice utilizator, atât timp cât administratorul a acordat aplicației permisiunile corespunzătoare.

Fiți precauți atunci când utilizați acest mecanism pe partea de client. Aplicația are permisiunea de a trimite prin intermediul oricărui utilizator, ceea ce ridică probleme de securitate. Se recomandă ca funcționalitatea  să fie utilizată numai în partea de server sau în medii foarte controlate.

- Gmail (Client)

Avem o nouă metodă de livrare a e-mailurilor prin Gmail. Aceasta utilizează bibliotecile open-source MimeKit și Google.Apis care rulează pe .NET Framework 4.8. E-mailul este trimis direct prin API-ul Gmail. Acesta este utilizat numai pentru livrări de la clienți care permit utilizarea UI și, prin urmare, afișarea unui dialog de autorizare. Utilizarea acestuia în cadrul EAS cu o excepție și un mesaj de descurajare adecvat nu este permisă. Cu toate acestea, apelantul trebuie să se asigure că poate afișa UI-ul.

Acesta a fost implementat folosind fluxul de autentificare OAuth 3-leggs (3LA) pentru comunicarea client-server. El necesită un ID al utilizatorului și un id al clientului, specificate. Procesul de certificare va afișa o fereastră de dialog Oauth2/MFA pentru ca utilizatorul să se conecteze la contul de Gmail al companiei sale.

Cerințele Google pentru a sprijini acest flux sunt următoarele:

1. Google Workspace

2. Aplicație cu acces la Gmail API

3. Secret-client pentru aplicație.

Aplicația trimite e-mailuri în numele utilizatorului conectat, care este și expeditorul e-mailului.

- App - Create

Presupunând că există deja un Google Workspace activ:

Mergeți la Google Cloud Console și selectați sau creați un nou proiect.

Creați o nouă aplicație (app) și configurați ecranul de consimțământ / brandingul. Acordați atenție tipului de audiență. Vi se va cere să selectați conturile cărora li se adresează aplicația dvs. 

• Dacă selectați Extern, atunci aplicația trebuie să treacă printr-o revizuire/evaluare din partea Google, deoarece se adresează unui public larg și conturilor din afara Workspace-ului companiei.

• Dacă selectați Intern, atunci nu aveți nevoie de o revizuire din partea Google, deoarece se adresează conturilor care aparțin Workspace-ului companiei. Dumneavoastră sunteți cel care își asumă responsabilitatea pentru securitate -  (implicit).
  
  

Dacă nu aveți un Workspace și doriți să utilizați doar livrarea din client, atunci puteți specifica tipul de public "Extern" și starea de publicare "Testare". În acest fel, aplicația este în modul de testare și nu are nevoie de revizuire din partea Google. Cu toate acestea, există unele limitări. De exemplu, trebuie să indicați ce utilizatori vor utiliza aplicația. În plus, există o limită pentru numărul de e-mailuri trimise.

Apoi, trebuie să activați API-ul Gmail pentru aplicație, pentru a oferi acces la serviciile Gmail. În plus, trebuie să setați domeniul "gmail.send" și "gmail.readonly" pentru aplicație (acces la date).

- App – Setări pentru livrare din client

Creați un "OAuth 2.0 Client ID" pentru aplicație și selectați tipul de aplicație "Desktop App". Procesul va crea ID-ul de client și secretul-client necesare pentru implementarea 3LA.

În acest moment, puteți alege să salvați elementele într-un fișier json. Plasați acest fișier într-un director EBS sincronizat cu terminalele. Apoi, introduceți calea relativă în câmpul ClientInfoFile din profilul de comunicare sau în parametrul companiei corespunzător, de exemplu CSConfig\GmailClientInfo.json.

Alternativ, puteți să faceți copy/paste cu ID-ul și secretul-client în câmpurile corespunzătoare ale profilului de comunicare sau în parametrii companiei respective.

- App – Setări pentru livrarea din server

Creați un cont de servicii. Notați ID-ul de client OAuth generat în urma procesului, deoarece veți avea nevoie de el mai jos.

Apoi, creați o cheie pentru contul de servicii. Salvați informațiile despre clientul contului de servicii într-un fișier json. Apoi, introduceți calea relativă în câmpul ClientInfoFile din Profilul de comunicare sau în parametrul companiei corespunzător, de exemplu ESNoSync\GmailServiceAccountInfo.json.

Folosind Google Admin Console, configurați "Delegarea accesului la nivel de domeniu" pentru aplicație. Utilizați ID-ul de client OAuth care v-a fost furnizat la crearea contului de serviciu. În cele din urmă, autorizați scorul https://mail.google.com/.

Atenție: Datorită ștergerii accesului la nivelul întregului domeniu, contul de serviciu are permisiunea de a trimite e-mailuri prin intermediul oricărui cont. Aveți mare grijă să evitați descărcarea informațiilor din json atunci când sincronizați terminalele. Asigurați-vă că îl plasați într-un folder de server care nu este sincronizat, cum ar fi ESNoSync.

4. Îmbunătățiri specifice versiunii în limba română

Închidere venituri și cheltuieli 

Pentru îmbunătățirea procedurii de închidere venituri și cheltuieli a fost realizat un nou scroller, accesibil din meniul Contabilitate > Procese de închidere a perioadei > închidere venituri și cheltuieli. 

Se va defini un nou cod de jurnal - CLVC - în meniul Instrumente și configurare > Personalizare… > Contabilitate > Jurnale. 

Conturile vor fi setate ca activ, pasiv sau bifuncționale (Brut)  pe toate cardurile conturilor contabile în câmpul “Natura”.

Scrollerul va lua în considerare următoarele:

• Dacă un cont este de activ sau este bifuncțional și are doar rulaj debitor: se va închide pe credit

• Dacă un cont este de pasiv sau este bifuncțional și are doar rulaj creditor: se va închide pe debit

• Dacă un cont este bifuncțional și are rulaj atât pe debit cât și pe credit: se va închide pe sold.

Automatizarea are ca parametru un cont  121* pentru a acoperi existența unor analitice diferite pe ani diferiți sau din alte motive.

Notele contabile generate se vor genera cu ultima zi a perioadei selectate.

Instrucțiuni suplimentare pentru mentenanța datelor

Procedura de Licență, Upgrade-uri, Hotfix-uri a fost completată cu un capitol de mentenanță a datelor ce recomandă ca de la instalare să fie stabilite planuri de  backup și de optimizare a bazei de date.

Transmiterea în e-Factura a facturilor emise către persoane fizice din RO

Din 1.01.2025 este obligatorie transmiterea la ANAF în sistemul e-Factura a facturilor emise către persoane fizice din România ceea ce presupune completarea specifică în structura xml a facturilor emise, a două câmpuri - BT-47 (Identifier for a legally registered Buyer)  și BT-48 (Buyer Tax Identifier) - prin care acestea sunt identificate.

EBS-RO, îmbunătățirea documentației și a traducerilor

Pentru mai multe informații, consultați acest site.
Îl actualizăm constant cu instrucțiuni și documentație în limba română.

De asemenea, actualizăm și corectăm constant toate erorile de traducere sau localizare, astfel încât aplicația să deservească mai bine utilizatorii români.

Management comercial 

Documente

• Au fost remediate diverse probleme întâlnite la documentele care au atributul SAVE_WITHOUT_DELTADS. În detaliu, acestea s-au manifestat:

  • Atunci când se modifica pasul de evoluție, pasul de pe tabelul din Catalogul documentelor nu se modifica.

  • Atunci când pasul de evoluție a fost modificat semnificativ, mișcările documentelor au fost șterse.

  • La modificarea cantității pe o linie a documentului și la trecerea la linia următoare, precum și la utilizarea automatizărilor personalizate care modifică câmpurile din linii, mișcările documentului erau șterse.

• S-a remediat o problemă la crearea unui nou lot pe linia documentului atunci când câmpul Cod lot este completat înainte ca articolul să fie definit pe linie.
  Concret, apare o eroare la salvarea documentului. Dacă articolul ar fi fost declarat mai întâi și apoi lotul, ar fi funcționat foarte bine.

• S-a remediat o problemă care apărea la declanșarea anumitor condiții de politică comercială și atunci când există condiții concurente care analizează lucruri diferite.

• S-a remediat o problemă în introducerea documentelor LMS - transferul contabil al mijloacelor fixe.
  Problema apărea atunci când achiziția amortizabilă a mijlocului fix era într-un exercițiu financiar închis. Corecția se referă la planul de proprietate 4-LMG.

• S-a rezolvat o problemă apărută după modificarea gestionării fluxului de numerar în versiunea 5.9.0.0. A apărut o problemă la modificarea documentelor de tranzacție Cash Flow care sunt implicate în actualizarea acestuia. Mai exact, dacă există un avans (AEP/APM) pe o comandă de vânzare/cumpărare și, respectiv, dacă această comandă a fost mutată pe un document ulterior de tip confirmare/expediere/primire, atunci documentul de avans nu putea fi modificat. Această interdicție a fost considerată critică în cazul valorilor documentelor - pentru a menține corectitudinea fluxului de numerar - dar pentru celelalte câmpuri ale documentelor restricția a fost prea strictă. Din acest motiv, începând cu această versiune, modificarea lor este permisă, cu excepția valorilor.

Rapoarte

• În fila Registrul analitic din cadrul contului contabil, titlurile coloanelor Debit progresiv și Credit progresiv au fost actualizate.

• În OLAP-ul "Profitabilitatea pe categorii de articole - Grup", s-a efectuat o corecție la calcularea costului bunurilor vândute în cazul în care existau rânduri diferite în jurnalele articolelor care actualizau cifra de afaceri și costul bunurilor vândute.

• A fost rezolvată o problemă de întârziere în vizualizarea "Compararea cantităților din documente".

• A fost corectată o eroare la deschiderea vizualizării "Mijloace de transport".

• A fost corectată o eroare la deschiderea vizualizării "Verificarea suficienței materialelor pentru executarea comenzilor".

• În tabloul de bord "Imagine 360" din cadrul paginii partenerului comercial, informațiile din "Analiză valori deschise", afișate în limba engleză, au fost corectate.

• Îmbunătățirea vitezei de execuție a vizualizării "Articole necontorizate în DSA cu sold".

• Îmbunătățirea vitezei de execuție a vizualizării din fila "Mișcare oficială" în circuitul antrepozitului vamal atunci când este definit un cod fiscal al articolului.

Proceduri

• A fost efectuată o modificare la crearea fișierului de plată pentru Eurobank, astfel încât fișierul să înceapă cu prefixul SWIFT, așa cum este cerut de bancă.

• S-a remediat o problemă în calcularea soldului pe formularele de inventar fizic care fie rezultă din înregistrare, fie sunt create prin procesul de finalizare a inventarierii, atunci când articolul are o unitate de măsură de serviciu alternativă.

• S-a remediat o problemă în interfața cu API-ul Eurobank.

• În procesul de export al fișierelor de plată către bănci, a fost adăugată o verificare pentru a se asigura că conturile beneficiarilor au un cod SWIFT (BIC) complet.

Diverse

• Atunci când căutați o persoană în Sarcini, acum sunt afișați numai clienții activi.

• A fost redenumită fila "Planuri de livrare" în "Planuri de vizită" în Vânzări > Activități > Detalii distribuție pentru a fi aceeași cu pagina corespunzătoare Adrese către client.

• S-a remediat o eroare în cazul furnizorilor alternativi ai unui articol de inventar în care, la nou prin copiere și pentru un articol cu mai mulți furnizori alternativi dintre care unul dintre era de bază, se crea o înregistrare suplimentară cu acel furnizor fără a fi codificat în articol.

• Începând cu această versiune, câmpul "Impozabil" din tranzacționări este gestionat mai corect. Concret, acesta a fost adăugat la formularele de furnizor și creditor, deoarece exista deja în formularele client și debitor. Câmpul este activat pentru parteneri comerciali noi care sunt persoane juridice, au completat codul de TVA, au Statutul de TVA = Normal sau Redus și au Statutul CIFO = Responsabil.

Cazuri asociate:
ΥΠΘ_SUP-199533, PS-107943, PS-108045, PS-107781, ΥΠΘ_SUP-199230, PS-75685, PS-77092, ΥΠΘ_SUP-132385, PS-96864, ΥΠΘ_SUP-196095, PS-74832, PS-88084, PS-96856, PS-105898, PS-106308, PS-106308, PS-106485, PS-107485, PS-58485, PS-58488, PS-58484, PS-588446, PS-69310, ΥΠΘ_SUP-120052, PS-82555, PS-107213, ΥΠΘ_SUP-123650, ΥΠΘ_SUP-161531, ΥΠΘ_SUP-194785, ΥΠΘ_SUP-194369, PS-99617, PS-104440, PS-105328, ΥΠΘ_SUP-168075, ΥΠΘ_SUP-193713, PS-106100, ΥΠΘ_SUP-199767, PS-108419, PS-107877, QA-09280, PS-101908

Corecții de erori pentru versiunea în limba română

• Au fost corectate câteva etichete netraduse din modulul de mijloace fixe.

• Amortizare nedeductibila - eroare conversie.

Cazuri asociate:

#1094236, #1095812