Cloud Storage Solutions v.14

Nu, această funcție este disponibilă doar de la versiunea 15. Înainte de acea versiune, modulul lucrează cu o structură de foldere predefinită:

1. Odoo - folderul principal pentru sincronizare

2. Models - foldere pentru fiecare tip de document Odoo. De exemplu, 'Projects', 'Partners'. Distinse prin domain pot exista foldere mai specifice: de ex., 'Customer 1 Projects', 'Projects of the Customer 2', 'Internal Projects' etc.

3. Objects - foldere pentru fiecare document, de ex. 'Project 1' sau 'Customer 1'

4. Fișiere și foldere legate de acest document Odoo care vor fi sincronizate.

Ca rezultat, puteți avea de exemplu:

• Odoo / Projects / Project 1 / fișiere și foldere legate de  project 1

• Odoo / Customer 1 Projects / Project 1; Odoo / Customer 2 Projects / Project 3, ...

• Odoo / Customers / Customer 1 / fișiere și foldere legate de customer 1

Această structură este întotdeauna plată, adică există doar acele niveluri de ierarhie. Așadar, este corect că tipurile diferite de documente nu pot fi ținute în aceeași structură. În folderul 'Customer 1' nu putem păstra fișiere legate atât de comenzile de vânzare, facturi, cât și de proiecte. Fiecare dintre aceste tipuri de document are folderul (sau folderele) propriu. Altfel nu am putea face sincronizarea inversă, deoarece nu ar exista un criteriu pe care să ne bazăm.

Nu, instrumentul se bazează pe un singur punct final de utilizator. Toate procesele de sincronizare se fac sub un singur administrator cloud (aplicație). Drepturile de acces pentru dosarele / fișierele create nu sunt automatizate. Trebuie să le administrați în soluția de stocare cloud.

Aplicația presupune că conținutul binar al atașamentelor este păstrat în Cloud Client, nu pe serverul Odoo. Astfel, aceste atașamente din Odoo devin de tip URL și le puteți accesa oricând din caseta de atașamente sau din Cloud Client.

După configurare nu sunt necesare acțiuni manuale, sincronizarea fiind complet automată. Decideți ce tipuri de documente Odoo trebuie sincronizate și configurați un model asociat pentru fiecare (clienți, comenzi de vânzare sau achiziție, sarcini, proiecte etc.).

Da, puteți. În acest scop pregătiți o regulă pentru fiecare, apoi aplicați filtre: de exemplu după tipul proiectului.

Încercați să faceți filtrele mutual exclusive, astfel încât un document să poată fi atribuit cu certitudine. De exemplu, „client, dar nu furnizor”, „furnizor, dar nu client”. Altfel, dosarul unui document specific ar sări de la un model la altul.

Nu, instrumentul este doar un nucleu tehnic. Aveți nevoie și de conectorul pentru cloud client.

Da, deși în cazul multor dosare/atașamente de sincronizat procesul poate fi lent. Totodată, clienții au raportat medii cu >10k parteneri și ~5k variante de produs de sincronizat, iar procesele au fost acceptabile.

Câteva puncte de subliniat:

1. Sincronizarea este construită astfel încât orice element să fie sincronizat și să nu se piardă, deși poate să nu fie rapidă. Este garantat de cozi FIFO și de fiecare lucrare confirmată.
2. Numărul de obiecte poate fi limitat logic. Configurația modelelor vă permite să restricționați sincronizarea elementelor obsolete (de ex., nu are sens să sincronizați parteneri arhivați sau comenzi de acum 2 ani).

Nu. Avem motive temeinice să evităm sincronizarea în timp real:

• Probleme de performanță. Dacă sincronizarea este în timp real, fiecare încărcare de fișier va afișa ecranul de încărcare.

• Probleme de conflict. Dacă 2 utilizatori modifică simultan un element, pot apărea situații nerezolvate. La lucrări periodice le putem repara ulterior; în timp real ar trebui salvate ca o coadă, și mai derutantă pentru utilizatori.

• Probleme de funcționalitate. În special redenumirea și restructurarea elementelor. În sincronizarea inversă instrumentul se bazează strict pe logica directoarelor, iar la fiecare sincronizare se verifică 100% din elemente. Dacă s-ar face după fiecare actualizare, ar fi mii de cereri pe secundă. Dacă nu: modificările s-ar pierde.

Puteți atribui propriul nume directoarelor de modele (comenzi de vânzare, oportunități, furnizori etc.) pentru orice tip de document.

Pentru folderele obiectelor (SO-001, John Smith etc.), instrumentul se bazează pe metoda Odoo de a construi numele afișat al acestui tip de document. Totuși, puteți schimba asta definind expresia numelui. Se folosește exact sintaxa șabloanelor de e-mail Odoo. 

Nu, această funcție este disponibilă doar de la versiunea 15.

Da, în funcție de configurația cloud client.

Conform politicilor actuale Odoo Apps Store:

• Fiecare modul cumpărat pentru versiunea 12.0 și anterioară dă acces la toate versiunile până la 12.0.
• Începând cu versiunea 13.0, fiecare versiune de modul se cumpără separat.
• Indiferent de versiune, cumpărarea dă dreptul la toate actualizările și corecturile dintr-o versiune majoră.

Rețineți că echipa faOtools nu controlează aceste politici. Pentru întrebări contactați direct reprezentanții Odoo Apps Store.

Cea mai directă abordare este să folosiți fluxul încorporat al magazinului Odoo:

1. Deschideți pagina modulului și faceți clic pe butonul Deploy on odoo.sh

2. După aceea veți fi redirecționat la pagina GitHub. Conectați-vă la cont, apoi faceți clic pe 'Create a new repo' sau folosiți unul existent. Asigurați-vă că depozitul este privat. Nu este permisă publicarea aplicațiilor sub licența OPL-1. Dacă e necesar, creați un repo nou pentru proiectul Odoo.sh

3. Apoi mergeți la odoo.sh și faceți clic pe butonul Deploy. În fereastra pop-up trimiteți decizia și faceți clic pe 'Continue.' Această acțiune pornește instalarea.

Acești pași vor instala aplicația pe ramura de producție a proiectului. Dacă doriți să implementați aplicațiile pe alte ramuri sau să actualizați modulul, urmați acțiunile de mai jos:

1. Încărcați codul sursă al aplicației din magazinul Odoo

2. Faceți commit modulului în depozitul GitHub necesar. Asigurați-vă că niciun folder/fișier al aplicației nu este ignorat (adică nu este în .gitignore al repo-ului). Depozitele sunt create automat de odoo.sh și pot include implicit elemente esențiale (de ex. /lib). Încărcați toate directoarele, subdirectoarele și fișierele modulului, fără excepții

3. Implementați ramura țintă a proiectului odoo.sh sau, dacă setările presupun asta, așteptați până este construită automat.

Da, desigur. Totodată Odoo adaugă automat toate dependențele în coș, deci trebuie să excludeți instrumentele deja cumpărate ca să evitați plata dublă.

Un avertisment roșu/portocaliu nu influențează funcțiile aplicației. Din păcate, modulele noastre nu trec uneori testele automate standard, deoarece acestea presupun un comportament în conflict cu obiectivele aplicației. De exemplu, schimbăm calculul prețului, iar testele modulului Odoo standard compară prețul final cu un algoritm standard.

În primul rând, verificați funcțiile bazei implementate. Totul funcționează corect?

Dacă tot credeți că avertismentul afectează funcții reale, contactați-ne și trimiteți jurnalele complete de instalare și lista completă a modulelor implementate (inclusiv nucleu și terțe părți).

Nu, distribuim instrumentele doar prin magazinul oficial de aplicații Odoo.

Din păcate, nu avem mijloace tehnice pentru a oferi prețuri individuale. 

Nu, aplicațiile terțe nu pot fi folosite pe Odoo Online. Din păcate Odoo SaaS blochează această posibilitate.

Da, instrumentul necesită toate modulele marcate în dependențe pentru a funcționa corect. Prețul de pe pagina aplicației include deja toate dependențele necesare.