Webgest 8.10.6 - Erori

Creat de dfreddie, Februarie 08, 2024, 08:00:39 AM

« precedentul - următorul »

dfreddie

Bună dimineața,

Dupa update-ul la 8.10.6 am întâmpinat următoarele probleme:

1. validare cu erori a facturii emise
2. vizualizarea facturilor anterioare catre clienți nu mai este posibilă nici din link-ul "documente anterioare" la emiterea unei facturi noi și nici din "Rapoarte Clienți"
Not too bad for a blind man ...
  •  

elis

Sistemul pe care rulează aplicația ce versiune de java are (comanda `java -version` din terminal)?
Cu versiunea Webgest 8.10.5, pe același sistem de operare (aceeași versiune de java), totul era OK?
  •  

dfreddie

Java este 1.8.0 - nu l-am mai modificat de cel putin 1 an ...

Nu imi aduc aminte daca cu 8.10.5 era ok ... dar cu 8.10.4 sigur mergea.
Not too bad for a blind man ...
  •  

dfreddie

Văd că pe Demo funcționează cu 8.10.6.

Să fie prea veche Java la mine? Să încerc cu 1.8.10?
Not too bad for a blind man ...
  •  

elis

Versiunea de mbx presupun că este ultima. Si la noi funcționează OK. Altcineva nu a sesizat problema (încă!).
Alte modificări pe sistemul respectiv în ultima perioadă? Eroarea pare a fi legată de versiunea de java. Se poate încerca cu altă versiune, de preferat să nu fie mai mare de 1.8.
  •  

dfreddie

După un upgrade la OS (de la bullseye la bookworm) ... totul a revenit la normal!

Mulțam' frumos!
Not too bad for a blind man ...
  •  

bogdy

Vin si eu cu o problema

In "Furnizori->Listare/editare->Documente intrare"



Code eroare: 500

Mesaj eroare: java.io.IOException: An exception occurred processing [/FurLisFact.jsp] at line [276] 273: // String zipArhPath=tcroot+sep+"wg_data"+sep+"eFact"+sep+datefirma.getCf()+sep+"primite"+sep+"prod"; 274: File zipArh=new File(zipArhPath); 275: if(!zipArh.exists()){ 276: FileUtils.forceMkdir(zipArh); 277: } 278: for(String flname:zipArh.list()){ 279: iddFromFs.add(flname.replace(".zip","")); Stacktrace:

Mesaj detaliat: An exception occurred processing [/FurLisFact.jsp] at line [276] 273: // String zipArhPath=tcroot+sep+"wg_data"+sep+"eFact"+sep+datefirma.getCf()+sep+"primite"+sep+"prod"; 274: File zipArh=new File(zipArhPath); 275: if(!zipArh.exists()){ 276: FileUtils.forceMkdir(zipArh); 277: } 278: for(String flname:zipArh.list()){ 279: iddFromFs.add(flname.replace(".zip","")); Stacktrace:



Ca si detalii suplimentare:

Tomcat9
root@webgest:/home/webgest# java -version
openjdk version "1.8.0_252"
OpenJDK Runtime Environment (build 1.8.0_252-8u252-b09-1~deb9u1-b09)
OpenJDK 64-Bit Server VM (build 25.252-b09, mixed mode)



N-am idee ce nu ii place...

  •  

cios

Nu-i place de eFactura !

De când cu obligativitatea ei, atât la Clienți cât și la Furnizori trebuie memorate într-o arhivă locală (care o va înlocui pe cea fizică) facturile primite cu parafa de la ANAF. Deocamdată locul acestei arhive este fixat într-un folder direct sub Tomcat. În cazul de față soluția este să dai drepturi de scriere în acel loc.
  •  

bogdy

Revin cu aceeasi problema:


Am ajuns cu chmod 777 pe toata calea /var/lib/tomcat9/wg_data/eFact/20329190/primite/prod
si tot aceeasi problema

Singura evolutie dupa ce am creat manual calea a fost sa apara notificarea ca sunt facturi noi disponibile la ANAF



Code eroare: 500

Mesaj eroare: java.io.IOException: An exception occurred processing [FurLisFact.jsp] at line [276] 273: // String zipArhPath=tcroot+sep+"wg_data"+sep+"eFact"+sep+datefirma.getCf()+sep+"primite"+sep+"prod"; 274: File zipArh=new File(zipArhPath); 275: if(!zipArh.exists()){ 276: FileUtils.forceMkdir(zipArh); 277: } 278: for(String flname:zipArh.list()){ 279: iddFromFs.add(flname.replace(".zip","")); Stacktrace:

Mesaj detaliat: An exception occurred processing [FurLisFact.jsp] at line [276] 273: // String zipArhPath=tcroot+sep+"wg_data"+sep+"eFact"+sep+datefirma.getCf()+sep+"primite"+sep+"prod"; 274: File zipArh=new File(zipArhPath); 275: if(!zipArh.exists()){ 276: FileUtils.forceMkdir(zipArh); 277: } 278: for(String flname:zipArh.list()){ 279: iddFromFs.add(flname.replace(".zip","")); Stacktrace:
  •  

cios

Înseamnă că încă nu are drept de scriere acolo Tomcat-ul din sistem. Depinde poate și de felul în care este pornit. Eventual încercat cu drepturi specifice grupului Tomcat.

  •  

bogdy

De la tomcat9 in jos tomcat:tomcat e owner.
O sa mai sap pe partea de drepturi.
Revin cu feedback.
Multumesc.
  •  

bogdy

Am gasit pe undeva ca systemd il tine in sandbox pe tomcat sub debian.
am rezolvat prin urmatorii pasi:
- verificare director home pentru userul "tomcat", era / am modificat in /var/lib/tomcat9
- editat fisierul /etc/systemd/system/multi-user.target.wants/tomcat9.service si adaugat linia
ReadWritePaths=/var/lib/tomcat9/wg_data/ in sectiunea "#Security"

- acum functioneaza normal
  •