Import Nomenclator Produse/Categorii/Subcategorii

[cios]

Într-adevăr, nu mai este funcțional formularul de preluare din fișier, pe nicio variantă. În format xml nu au fost niciodată furnizori care să pună la dispoziție, iar de la ceilalți doi pentru care au fost făcute convertoarele din csv nu s-au mai primit facturi de mulți ani. Între-timp s-au făcut tot felul de schimbări în formularele legate de recepție și partea asta nu s-a mai actualizat.

Chiar zilele acestea n-o să ne putem ocupa de problemă, dar o s-o abordăm cât de curând. Așteptăm între timp și ceva idei legate de identificarea cataloagelor-categoriilor. Furnizorii voștri folosesc și coduri interne, care se regăsesc și în fișierele primite și s-ar putea extrage ceva informații de acolo? 

[stefg27]

Da, majoritatea furnizorilor folosesc propriile coduri interne, care se regasesc si pe factura. La furnizorii intracomunitari, pe langa codul intern mai exista si EAN si atunci e mai usor de identificat. Este foarte utila implementarea mai multor referinte ale produsului, gen EAN si cod furnizor in cazul in care se rezolva si modulul de "Comenzi Furnizori"

In momentul de fata (cu actualul "sistem de gestiune" - sper ca se intelege de ce sunt ghilimele ) facem 2 operatiuni:
a) import produse noi in nomenclator ( cu un fisier txt, care contine informatii de cod intern, EAN, denumire, TVA, grupa, subgrupa, etc...), apoi
b) import factura (NIR) (tot fisier txt, cu informatii doar: cod intern, cantitate, pret intrare, pret vanzare cu TVA).
In cazul in care exista produsele in nomenclator, nu facem decat operatia b)

[cios]

Revenind la subiectul initial al postului - "Import nomenclator produse/Factura din e-mail" nu am reusit operatiunea. Am incercat toate variantele, si nu functioneaza, nici pe sistemul meu si nici pe varianta online-demo. Un mic "howto..." ar fi binevenit !

Pregătim zilele acestea o nouă versiune a Webgest, 4.8. Au fost modificări mai mari, inclusiv a structurii bazei de date, legate mai ales de partea de contabilitate, tva și istoricul unor schimbări pe perioade. Am putea prinde cu această ocazie și acest punct, măcar demonstrativ.

Pentru că de mult timp nu s-a mai folosit opțiunea de generare a recepției pe baza facturii primite pe mail, formul respectiv nu s-a mai actualizat și nu mai era funcțional în ultimele versiuni. Am început să-l refacem și ar fi posibil să rezolvăm și o preluare dintr-un format nou, csv, pe lângă cea din xml. Pentru asta ne-ar trebui un exemplu de date, într-unul din formatele ce le primiți voi mai frecvent. Sper că nu-i o problemă să ni-l trimiți, după ce ați scos din ele datele confidențiale. Apoi mai vedem cum facem cu categorisirea...

[cios]

Am primit pe mail exemplele de date, dar care sunt legate mai mult de procedura de lucru și de structura aplicației respective. Noi am dori să încercăm preluarea direct din formatul venit de la furnizor și pentru asta te-aș ruga să ne trimiți un astfel de exemplu, pe mail sau atașat aici pe forum.

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.

[stefg27]

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.

[cios]

Am introdus în noua versiune și posibilitatea de a adăuga, la recepția normală, și articole preluate prin importul din fișiere. E acum funcțională, în paralel, și recepționarea "automat din fișier", cu date din xml.

Pentru această parte de import doar a articolelor din fișier vor fi două formate disponibile, deocamdată: dintr-un xml (generic) și dintr-un csv. Am pus în attach un exemplu de csv, generat din combinarea celor două folosite de voi, de bază fiind nomstoc la care s-au adăugat câmpurile din nir. Am vrea să știm dacă vă e la îndemână să obțineți și acest format prin acele prelucrări în excel.

Ne-ar interesa de asemenea un feedback despre structura acestui fișier și de la alți utilizatori pentru care ar fi de folos preluarea din facturile primite de la furnizori în format electronic. Pot fi adăugate pe parcurs mai multe astfel de formate. Acum vrem să pornim cu acesta, pe care să-l apropiem de unul cât mai general.

Ca principiu de lucru, în Webgest preluarea se face într-o singură etapă - din punctul de vedere al utilizatorului. În spate se generează automat cataloage/nomenclatoare noi pentru articolele ce nu se regăsesc în baza de date. Modul de identificare se face acum după denumire, explicație, cod, um și furnizor. El poate fi îmbunătățit, ca și cel de încadrare pe categorii.

[stefg27]

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!

[cios]

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?

Capul de tabel este pus doar informativ, oricum nu se ia în seamă și bineînțeles că poate să lipsească. În noua variantă, integrată deja în aplicație, a și fost modificat, folosindu-se "--" pentru comentarii, așa cum se folosește și la MySQL.

Pentru a putea discuta la concret, ți-am și trimis pe mail noua versiune a Webgest, cu problema de update baza de date rezolvată (urmează să punem și la download după ce se rezolvă și celălalt bug descoperit).

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!

O să le luăm pe rând, pornind de la modelul pus în noua versiune. Se pot face multe ajustări, dar trebuie documentate, negociate.  Sperăm să iasă ceva cât mai acoperitor.

[stefg27]

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!!

[cios]

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.

Acea coloană am lăsat-o acolo forțat, să se vadă că s-a luat tot din nir. În mod normal ea nu trebuie să existe, fiindcă furnizorul nu-ți scrie pe factură (decât în cazuri excepționale) prețul de vânzare. Probabil că la voi se obișnuiește editarea în excel, și de acolo apare în fișierul nir acel preț. În felul cum am făcut noi, se consideră că importul se face direct din fișierul primit de la furnizor și eventualele corecții/editări se fac în formularul de recepție. Se poate face, după cum am mai spus, și preluarea din xls. Ne trebuie un format de exemplu.

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

Păi... de unde?! Aici e încă mult de lucru, la standardizare. Ar fi interesant de ținut cont și de formatele și structura din PrestaShop, să se potrivească până la capăt.

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!!

Puterea obișnuinței... Dacă merge și așa...
Pentru noi e o reluare după mulți ani, dar sigur e pe un nivel mai sus al spiralei. Acum și mai mulți ani, când am început lucrul, lumea spunea că o astfel de aplicație web nu va fi folosită niciodată de gestionari și contabili! (Pe acele vremuri managerii nici nu foloseau calculatorul, așteptau și primeau totul tipărit!)