Datele pentru e-Transport din Zoho Inventory: ce tine sistemul si ce lipseste
Datele pentru e-Transport pregatite din Zoho Inventory sunt articolele, clientul, adresa de livrare, depozitul si cantitatile, deja corecte si structurate pe comanda de vanzare si pe pachet inainte ca marfa sa plece. Zoho Inventory tine aceste date. Documentatia Zoho folosita in acest ghid nu descrie insa o functie nativa care sa trimita declaratia la ANAF. Transmiterea cere deci o integrare.
Declaratia e-Transport este raportarea catre ANAF a transporturilor rutiere internationale de bunuri si a transporturilor rutiere pe teritoriul national ale bunurilor cu risc fiscal ridicat. Verificati intai daca livrarile dumneavoastra intra in aceasta obligatie. Lista exacta de campuri o stabileste ANAF, nu Zoho. Acest ghid nu reproduce lista. Va recomandam sa o luati din specificatia oficiala si sa o comparati cu tabelul de verificare de mai jos.
Ghidul acopera trei lucruri:
- ce date tine Zoho Inventory pe articol, pe client, pe comanda de vanzare si pe pachet;
- cum structurati acele date ca sa poata fi citite automat, fara retastare;
- unde se termina Zoho Inventory si unde incepe integrarea catre ANAF.
Principiul de lucru este simplu. Orice informatie pe care declaratia o cere trebuie sa existe intr-un camp dedicat, nu intr-o descriere sau intr-o nota. O integrare poate citi un camp. Nu poate ghici ce a scris un operator in text liber.
Functiile fiscale din Zoho Inventory depind de editia de tara
Zoho Inventory construieste functiile fiscale si de transport pe editii de tara, iar documentatia disponibila arata o functie de transport doar in editia indiana. In acea editie, Zoho Inventory poate genera e-Way bill pentru facturi, note de credit si avize de expeditie (delivery challans). Un e-Way bill este documentul electronic cerut, peste anumite praguri de valoare, pentru transportul marfurilor in sau intre statele Indiei, conform regimului GST. Documentul descrie articolele mutate, locul livrarii si modul de transport.
Alte editii au primit functii proprii pietei lor. Editia din Marea Britanie urmareste taxarea inversa interna (Domestic Reverse Charges), implementata de HMRC de la 1 martie 2021. In editia indiana, Zoho Inventory extrage PAN-ul, adica Permanent Account Number, din GSTIN si il completeaza automat in sabloane. Tot acolo, clientii sau furnizorii pot primi pe email un link prin care isi introduc direct datele GST.
Concluzia pentru o firma din Romania este practica. Nu presupuneti ca exista un buton e-Transport pentru ca exista unul e-Way bill in alta editie. Modelul indian arata totusi ce tip de date are nevoie un document de transport: marfa, locul si modul de transport. Pe aceeasi logica pregatiti si datele dumneavoastra in Zoho Inventory.
Articolele: cod, denumire si coduri alternative structurate o singura data
Articolul este locul unde datele de marfa trebuie sa fie corecte, pentru ca fiecare comanda si fiecare pachet le preia de acolo. Daca un cod lipseste pe articol, lipseste pe toate livrarile. Corectura facuta pe articol se propaga la urmatoarele documente. Corectura facuta pe document se pierde la urmatoarea comanda.
Exemplul Indiei arata cum trateaza Zoho codurile de clasificare. CBIC, adica Central Board of Indirect Taxes and Customs, a impus coduri HSN/SAC de la 1 aprilie 2021. Zoho Inventory selecteaza implicit codul HSN de 6 cifre. Selectia se schimba din pagina Item Preferences.
Pentru declaratia din Romania, verificati in specificatia ANAF ce cod de clasificare se cere. Tineti apoi codul intr-un camp dedicat pe articol, nu in descriere.
Coduri alternative si grupuri de articole
Multe firme vand acelasi produs sub mai multe coduri. Un utilizator care lucra pentru un distribuitor de piese auto a propus o solutie pe forumul Zoho. Fiecare piesa de la un furnizor terta devine articol separat, iar codul producatorului original intra in campul Alias. Acelasi utilizator a semnalat doua limite ale grupurilor de articole (Item Groups):
- numele unui grup are cel mult 200 de caractere;
- nu puteti cauta dupa numele grupului cand adaugati linii pe o comanda.
Pentru e-Transport, regula este ca un articol fizic sa aiba un singur cod principal stabil. Codurile alternative raman in Alias, ca sa nu ajunga doua coduri diferite pe aceeasi linie de transport.
Clientul si adresa de livrare: comanda de vanzare ca sursa unica
Comanda de vanzare (Sales Order) este documentul din care o integrare ar trebui sa citeasca destinatarul si adresa de livrare. Pe comanda se leaga clientul, articolele si cantitatile. Daca operatorul alege corect adresa aici, pachetul si factura o mostenesc.
Adresele de livrare directa (dropship) au o particularitate documentata de Zoho. O adresa de dropship adaugata pe o comanda de vanzare se foloseste doar pentru acea tranzactie. Adresa nu se salveaza in lista de adrese suplimentare a clientului. Integrarea trebuie deci sa citeasca adresa de pe comanda, nu din fisa clientului, altfel declara alt loc de livrare decat cel real.
Ce verificati pe fisa clientului
Fisa clientului din Zoho Inventory ramane sursa datelor de identificare. Completati codul fiscal si adresele de livrare frecvente in campuri separate, nu intr-un singur rand de text. Un camp de adresa scris liber, cu strada, localitatea si judetul amestecate, nu poate fi impartit sigur de un program.
Zoho Inventory are si un tab Mails pe fisa clientilor si a furnizorilor. Tabul arata toate emailurile de sistem trimise acelui contact. Pentru comenzile de vanzare exista Email Insights, care arata cand a fost deschis emailul. Ambele va ajuta sa confirmati ca destinatarul a primit documentele livrarii.
Pachetul de livrare: depozit, linii, loturi si numere de serie
Pachetul (package) este documentul Zoho Inventory cel mai apropiat de transportul fizic, pentru ca arata ce pleaca efectiv, din ce depozit si in ce cantitate. Comanda poate avea zece bucati, iar pachetul de azi doar sase. Declaratia trebuie sa descrie transportul real, deci integrarea citeste pachetul, nu comanda.
La crearea pachetului, o bara laterala arata un rezumat al listei de picking. Rezumatul include numele depozitului, liniile de articole, persoana desemnata, comentariile si alte activitati. Verificati aici ca depozitul este cel din care pleaca marfa. Locul de incarcare se deduce din depozit.
Loturi si numere de serie pe pachete
Zoho Inventory poate urmari numerele de serie si de lot pe pachete si receptii, in loc de facturi, facturi de furnizor si note de credit. Pentru transport, aceasta setare este cea utila, pentru ca lotul se leaga de momentul in care marfa pleaca. Doua reguli mai noi ajuta la date curate:
- la generarea seriilor pentru intrari, numarul de serie de pornire trebuie sa se termine cu o cifra;
- un lot marcat Inactive nu mai apare in tranzactii, dar ramane in rapoarte.
Marcati loturile epuizate sau blocate ca Inactive. Astfel, un operator nu le poate alege pe un pachet care ajunge apoi intr-o declaratie.
Lista de verificare a campurilor Zoho Inventory inainte de livrare
Inainte ca un pachet sa plece, fiecare element de mai jos trebuie sa fie completat in campul indicat, nu in note sau descrieri. Tabelul compara elementele de date dupa locul in care stau in Zoho Inventory si dupa ce verificati. Comparati-l cu lista oficiala ANAF si adaugati randurile pe care specificatia le cere in plus.
| Element de date | Unde sta in Zoho Inventory | Ce verificati |
|---|---|---|
| Cod principal al marfii | Fisa articolului | Un singur cod stabil; codurile alternative in Alias |
| Cod de clasificare cerut de ANAF | Camp dedicat pe articol | Completat pe toate articolele care se transporta |
| Destinatar | Fisa clientului, legata de comanda de vanzare | Cod fiscal in camp separat, nu in nume |
| Adresa de livrare | Comanda de vanzare | Adresa de dropship citita de pe comanda, nu din fisa clientului |
| Loc de incarcare | Depozitul de pe pachet | Depozitul din bara laterala corespunde realitatii |
| Cantitati | Liniile pachetului | Cantitatea din pachet, nu cea din comanda |
| Lot sau serie | Pachetul, cu urmarire pe pachete activata | Fara loturi inactive selectate |
Daca un rand nu are un camp in Zoho Inventory, creati un camp personalizat inainte de integrare. Nu lasati integrarea sa completeze golul cu o valoare fixa sau ghicita.
Exemplu lucrat: o livrare de piese auto pregatita in Zoho Inventory
Un distribuitor de piese auto pregateste o livrare corect cand articolul, comanda si pachetul au fost verificate in aceasta ordine. Exemplul porneste de la structura propusa pe forumul Zoho pentru un astfel de distribuitor. Pasii sunt cei din Zoho Inventory, iar datele cerute de ANAF le verificati separat.
- Articolul. Filtrul pentru placute de frana de la un furnizor tert este articol separat. Codul producatorului original sta in Alias. Codul de clasificare sta in campul dedicat de pe articol.
- Grupul. Articolele echivalente sunt grupate dupa codul producatorului original. Numele grupului ramane sub 200 de caractere. La adaugarea liniilor, operatorul cauta dupa articol, nu dupa grup.
- Comanda de vanzare. Clientul, un service auto, are codul fiscal completat pe fisa. Marfa merge direct la un punct de lucru, deci operatorul adauga o adresa de dropship pe comanda.
- Pachetul. Din zece bucati comandate, pleaca sase. Bara laterala arata depozitul de plecare si liniile. Lotul ales este activ.
- Controlul final. Operatorul parcurge tabelul de verificare. Abia apoi pachetul este marcat pentru expediere.
Rezultatul este un pachet cu toate datele in campuri. Daca livrarea intra sub obligatia e-Transport, de exemplu o livrare intracomunitara sau un export, integrarea citeste destinatarul si adresa de pe comanda, iar articolele, cantitatile, depozitul si lotul de pe pachet. Nimeni nu copiaza aceste date intr-un alt formular.
Integrarea catre ANAF: API-ul Zoho Inventory, OAuth si monitorizarea apelurilor
Integrarea este componenta care citeste pachetul si comanda din Zoho Inventory si construieste declaratia, pentru ca documentatia disponibila nu arata o functie nativa e-Transport. Citirea se face prin API-ul Zoho Inventory. Formatul si transmiterea catre ANAF raman in sarcina integrarii.
Autentificare si citire
Apelurile API se autentifica prin OAuth. Zoho a scos din uz Authtokens pentru suita Finance pe 30 august 2021, dupa o prelungire a termenului. Un exemplu de pe forumul Zoho foloseste Deluge cu o conexiune numita "zinv" si o cerere GET catre API-ul Zoho Inventory. Cererea preia 200 de inregistrari pe pagina. O integrare care citeste multe documente trebuie deci sa parcurga paginile pe rand.
De ce nu exporturi manuale
Exportul in fisiere nu este o integrare. Un utilizator a raportat ca Zoho i-a blocat exporturile cu un avertisment ca exporta prea multe inregistrari prea repede. Exportul in bloc, de pana la 500.000 de inregistrari in functie de plan, este documentat pentru rapoarte precum Inventory Summary si FIFO Cost Lot Tracking. Nu este documentat pentru documentele de livrare.
Pentru control, Zoho Inventory are un panou API Usage. Panoul arata modulele, aplicatiile, adresele IP si utilizatorii care fac apeluri API in organizatie. Verificati-l dupa lansare, ca sa vedeti ca integrarea este singura care citeste pachetele.
Ce inseamna pentru o firma din Romania care livreaza din Zoho Inventory
Pentru o firma din Romania, pregatirea datelor in Zoho Inventory este partea pe care o controlati integral, iar transmiterea catre ANAF este un proiect de integrare separat. Functiile fiscale native difera pe editii de tara. Nu planificati procesul pe baza unei functii vazute in editia indiana sau britanica.
Calitatea datelor ramane responsabilitatea echipei, nu a integrarii. Integrarea transmite exact ce gaseste in campuri. Un cod lipsa pe articol sau o adresa scrisa in text liber produce o declaratie gresita sau o declaratie respinsa.
La Svennis, inainte de orice integrare, exportam comenzile de vanzare si pachetele dintr-o perioada recenta si cautam articolele fara cod de clasificare si adresele scrise doar in text liber. Corectam intai aceste date in Zoho Inventory si abia apoi construim integrarea, pentru ca altfel erorile ajung direct in declaratii.
Mai este un detaliu de organizare. Un utilizator a raportat ca persoanele de contact ale furnizorilor din Zoho Inventory nu se sincronizeaza cu Zoho CRM, spre deosebire de clienti. Daca declaratiile pentru marfa primita depind de date de furnizor, stabiliti in ce sistem se tin acele date.
Pasii urmatori pentru datele e-Transport din Zoho Inventory
Primul pas este un audit al datelor existente in Zoho Inventory fata de lista oficiala de campuri ANAF. Lucrati in aceasta ordine:
- Luati lista de campuri a declaratiei din specificatia ANAF si puneti-o langa tabelul de verificare din acest ghid.
- Creati campurile personalizate care lipsesc pe articol sau pe comanda.
- Completati codurile pe articole si mutati codurile alternative in Alias.
- Activati urmarirea loturilor si seriilor pe pachete si marcati loturile vechi ca Inactive.
- Instruiti operatorii sa aleaga adresa pe comanda si sa verifice depozitul pe pachet.
- Abia apoi specificati integrarea: ce citeste, din ce document si cand.
Daca nu ati configurat inca gestiunea, pagina despre implementarea Zoho Inventory in Romania descrie ce acopera aplicatia. Pentru partea de facturare, cititi pagina despre Zoho Books in Romania. Daca vreti sa vedeti cum se leaga aplicatiile intre ele, ghidul despre ecosistemul Zoho ofera imaginea de ansamblu. Pentru a urmari dupa lansare livrarile si erorile de date, folositi rapoarte in Zoho Analytics.
Surse
- What's New in Zoho Inventory - April 2021
- What's New in Zoho Inventory - August 2020
- What's New in Zoho Inventory | January - March 2025
- Zoho Inventory - Managing Items With Multiple Suppliers
- Fetch Purchase Orders (transactions) from Items in Zoho Inventory
- How to import item images to Inventory or is there any ftp access
- Inventory Set-up



