Mesaje

Merge si fara a scrie calea completa, dar trebuie modificat in loc de:

Cod Selectează Extinde


${catalina.home}


in

Cod Selectează Extinde


${catalina.base}



PS: am incercat si pe debian 7 cu tomcat7 si pe windows tot cu tomcat7

Cred ca ar fi o idee buna instalarea unor modificari la forum, pe partea de SEO (search engine optimization), pentru o mai buna indexare in google...implicit un trafic mai mare. Adica, in loc de un url de forma forum.webgest.ro/index.php?action=;topic=2387, url-ul va deveni forum.webgest.ro/post-seo-forum.html. Pentru asta, webserverul ar trebui sa aiba suport pentru mod_rewrite si .htaccess

Traficul mai mare, ar trebui sa genereze un numar mai mare de utilizatori de Webgest, un numar mai mare de useri pe forum, respectiv un numar mai mare de probleme dar si idei 

Pentru cresterea traficului, in paralel cu optimizarea SEO, trebuie crescuta prezenta pe Facebook (in principal), Twitter, Google+, etc.

Pentru sustinerea efortului (programare, vps inchiriat, etc...) poate ar fi util adaugarea la forum si a posibilitatii useri-lor de a face donatii (vezi modulul de paypal DONATE). Eu sunt primul care as dona!

Astazi am avut timp sa verific functionarea importului!

1. Functioneaza preluarea fisierului, dar nu introduce si pretul de vanzare (ultima coloana din fisierul de import). Foloseste in mod automat pentru calcul procentul de adaos stabilit in setari.
2. La produsele noi nu ataseaza "Grupa" si "Subgrupa" - le introduce automat in grupa DV si subgrupa DV
3. La produsele care nu se gasesc in baza de date, nu le ataseaza cod produs si cod EAN

Cam astea sunt primele impresii!


PS: Se pare ca nu prea a fost dorit acest modul de import, pentru ca vad ca nu este niciun feedback!!

Ultimul update primit (4.8.0u1) a rezolvat problema cu update-ul bazei de date!

Legat de fisier: am observat ca, "capul de tabel" are ca delimitator //, iar datele au ca delimitator #. Banuiesc ca fisierul de import contine numai date, fara cap de tabel, corect?

Legat de modul de identificare a produselor, mi se pare un pic ciudat ca principalul mod de identificare nu se face dupa cod EAN, care este unic.(Aici vorbesc de brand-uri, de producatori care au solicitat alocarea codului EAN la nivel european. Marlboro are acelasi cod si in RO si in DE si GB).
Exista situatii (destul de multe) cand denumirea unui produs sa fie diferita, dar codul EAN este acelasi. In acelasi timp, exista situatia cand un produs poate fi comandat de la mai multi furnizori (intr-o perioada de timp) in functie de pretul cel mai bun obtinut. Daca de fiecare data se importa in baza de date acelasi produs doar pentru ca are denumire diferita se va incarca baza de date fara rost. E doar o parere!

La update-ul bazei de date la noua versiune imi apare un mesaj de eroare:

Cod Selectează Extinde


--Actualizări la zi în baza de date Webgest!
Încep actualizare firma ...
--Rulez update 4.8.0.10
--EROARE--Duplicate column name tip
Terminată firma ....
Terminate toate firmele alese

Si la versiune baza de date imi apare "4.8.0.10 -Nefinalizat"

Am facut eu update-ul de webgest gresit? (undeploy versiunea veche, restart tomcat, deploy versiunea noua si pe urma incercat update la baza de date, pt ca altfel nu se poate intra in program)

Formularul de facturare va fi oricum refăcut, după ce s-au făcut experimente pe cel de recepție (nici acela nu-i încă perfect!). Actualul are neajunsuri pe toate 3 nivelele: tehnologie, logică, aspect. Unul dintre cele mai importante e că nu merge pe alte browsere în afară de Firefox, ceea ce la recepție s-a rezolvat.

Cu ocazia aceea o să vedem și posibilitatea de cumulare, poate funcție de setarea unei variabile, cu rezolvarea în spate a descărcării de gestiune detaliate, cum se mai face în alte părți. Însă, cea mai importantă este posibilitatea de a urmări produsul la ieșire la nivel de lot, serie, nrbi...

Posibilitatea de urmarire a produsului la iesire este foarte utila, ( in special pentru industria alimentara - productie, distributie, retail), dar cred ca ar trebui dezvoltat un alt modul "DEPOZIT" care sa prei rolul de receptie/livrare produse.
Astfel, ca si flux (dupa logica mea ):
- ACHIZITIILE emit o comanda catre furnizor
- DEPOZITUL receptioneaza cantitativ produsele livrate de furnizor (aici sunt introduse date legate de cantitate, EAN, lot, expirare, rand depozit, raft, etc...)
- CONTABILITATEA, valideaza receptia
- VANZARILE inregistreaza o comanda de la un client
- DEPOZITUL livreaza cantitatile respective catre client
- CONTABILITATEA valideaza livrarea si emite factura catre client

La modul "simplist" cam asa vad eu fluxul documentelor de la intrare la iesire. Bineinteles ca totul trebuie detaliat si pus pe hartie toate variantele posibile, astfel incat rezultatul sa fie folositor si firmelor mici si foarte mici, dar si celor cu o activitate mai laborioasa.

Bănuim că în acel fișier primit sunt și alte date în afară de partea de articole, cum ar fi datele de identificare ale furnizorului, număr/dată factură, data scadentă, valori totale (pentru a le compara cu sumele rezultate din calcule, să nu se înregistreze cu diferențe de bănuți din cauza rotunjirilor!)... Ar trebui să fie cam tot ce-i și pe factură. Modul nostru de lucru permite și preluarea acestor date, putând fi extins la nevoie și cu preluarea unui întreg calup de facturi. Iar e o bănuială, că actualul program vă permite importul articolelor doar, și într-o fază avansată a formularului de recepție, după ce s-au introdus deja datele generale de pe factură. Dar, în timp, încercăm să facem acest proces să funcționeze cât mai automat, cu cât mai puține intervenții ale operatorului.

Acest fisier nu contine informatii despre factura (numar, data, sume). Aveti dreptate, sistemul actual de "import" folosit este semi-automat, adica se introduc manual, in formularul de receptie, Numele Furnizorului, Nr. Factura, Data Factura si gestiunea. Automatizarea se refera doar la liniile facturii. Dupa introducerea liniilor se verifica manual daca corespunde totalul receptiei cu datele de pe factura.

Exista posibilitatea ca la export/salvare factura (pdf sau xml) sa se adauge inainte de denumirea produsului si codul produsului? Asta pentru o mai usoara identificare de catre parteneri a produselor de pe factura.
Pe langa posibilitatea de export/salvare in pdf sau xml, se poate adauga si optiunea de salvare TXT sau CSV?

Dupa reinstalarea OS (debian7) si alocarea a 2GB de swap se pare ca nu se mai blocheaza serviciu tomcat7. Dar e foarte mare consumator de resurse!! In standby ocupa cam 180-200 MB din ram iar in mod de lucru normal ( 1-3 useri, doar introducere date, fara salvare pdf) sare la 350-425 MB. Cu salvare pdf ajunge sa-mi ocupe si 450MB din swap.

Cam mare consumator de resurse!!

Am observat o situatie destul de ciudata! In cazul receptiei unui produs in cantitati diferite, pe facturi diferite, dar acelasi pret, nu se cumuleaza stocul! De aici imposibilitatea de a factura tot stocul existent o data ci doar adaugand cantitatea maxima receptionata pe fiecare factura.

Un sistem destul de greoi!

In plus, la facturare, nu exista posibilitatea de a alege introducerea codului produsului facturat ( asa cum este la Receptie NIR), lucru nu tocmai placut, mai ales ca selectia produsului se face strict dupa inceputul denumirii produsului si nu dupa orice cuvant din denumire. Aceasta restrictie duce la un proces de facturare destul de greoi, mai ales daca in nomenclator ai proasta inspiratie de a alege denumiri de produse lungi.

Am introdus facturile de la un singur furnizor si se pare ca el are o problema de calcul a facturilor. Problema vine de la el, pentru ca nu face "round" la 2 zecimale (la cantitate*pret-unitar) ci face "cut" si de aici vin cele mai mari diferente.

Problema am remarcat-o si eu pe vps. Insa ... schimband OS-ul din CentOS 6 in Debian 7 problema se pare ca s-a rezolvat de la sine.

Eu aveam deja Debian 7.  La prima instalare nu am fost atent ca nu aveam alocat swap. Am reinstalat OS-ul si am alocat si 2 GB de swap (imi permite sistemul , pt ca am virtualizare kvm). Sa vedem acum daca se mai blocheaza.

Dupa introducerea a mai mult de 15 facturi furnizori, pot spune ca mai exista un bug la calculul sumelor. Lucru anormal, mai ales la coloana total fara TVA, unde se introduc sumele de pe factura furnizorului si nu exista decat o simpla suma. Diferentele sunt de 0.01 lei pana la 0.05 lei.

Diferente apar si la coloana TVA, de unde rezulta o alta valoare a receptiei decat cea de pe factura furnizorului.

Datele modificate au fost Administrare/Personal. Dupa modificare nu mai apare la "tip personal" posibilitatea de a alege "Administrator sistem", Doar Agent, sau Sofer-Agent sau Nespecificat.

A trebuit sa reinstalez tot sistemul, pentru ca nu am gasit in baza de date care era campul cu pricina si nici codificarea nu o stiam. Acum dupa reinstall la "tip personal" apare ext-admg, dar in lista de selectie tip personal, nu apare aceasta optiune.