Întrebri frecvente i rspunsuri specifice Schemei SAF-TDECLARAIEI INFORMATIVE D406 FIIERUL STANDARD DE CONTROL FISCAL
(SAF-T)
Seciune Master Files
GeneralLedgerAccounts / MF.GLA.4/ StandardAccountID - De ce un asemenea câmp, care ar trebui s standardizeze conturile furnizate prin AccountID este cu titlu opional?
Rspuns: Conturile raportate la elementul MF.GLA.2/AccountID sunt conturile analitice folosite de contribuabil pornind de la planul de conturi standard conform reglementarilor in vigoare. Contul sintetic corespunztor fiecrui cont analitic este cel definit in planul de conturi aplicabil si se poate stabili pe baza contului analitic (AccountID) raportat de contribuabil in SAF-T.
In schema SAF-T elementul MF.GLA.4/StandardAccountID reprezint contul conform standardului utilizat in principal de catre contribuabil in ERP in cazul societilor care folosesc un alt plan de conturi in scopul contabilizrii pentru nevoile grupurilor din care fac parte.
2.3 Customers / MF.C.5 / AccountID - Motivul pentru care acest câmp este opional este deoarece putem avea pe un client sume având conturi GL diferite?
Rspuns 1: In versiunea revizuita a schemei câmpul este obligatoriu.
2.4 Suppliers/ MF.S.5/ AccountID - Motivul pentru care acest câmp este opional este deoarece putem avea pe un furnizor sume avand conturi GL diferite?
Rspuns 2: In versiunea revizuita a schemei câmpul este obligatoriu.
2.5 TaxTable/ MF.TT.11/ BaseRate – V rugm s ne furnizai un exemplu concret pentru aceast seciune.
Rspuns 3: BaseRate reprezint pro-rata aplicata de contribuabil (daca este cazul) pentru deducerea TVA si se va complet in funcie de codul de taxa ales. Spre exemplu, daca un contribuabil aplica o pro- rata de 90%, pentru operaiunile pentru care se aplica pro-rata va completa BaseRate 90%.
2.6 UOMTable/ MF.UOM.2/ UnitOfMeasure - Exist coduri de uniti de msur pentru care nu exist coduri ISO în standardele internaionale. Cum se va proceda cu acestea?
Rspuns 4:
Nomenclatorul cuprinde codurile i descrierile standard ale unitilor de msur utilizate, în majoritatea lor uniti de msur tolerate, cel mai bine adaptate diferitelor categorii de produse, modului lor de
3
prezentare comercial, împachetare, aprovizionare i desfacere. În nomenclator sunt incluse unitile de msur din sistemul internaional de uniti de msur (MKS) – standardizat ISO, dintre care unele sunt mai puin adaptate utilizrii comerciale (de exemplu unitatea de msur pentru volum m3 pentru împachetarea comercial a buturilor în recipiente mici (butelii, sticle) cu volumul mai mic de 1 dm3
pentru care mai potrivit este litrul, o unitate de msur tolerat.
Utilizarea unitilor de msur tolerate din nomenclator – mai bine adecvate tranzacionrii comerciale de bunuri – simplific pregtirea Declaraiilor informative D406 de ctre contribuabili, acetia putând utiliza codurile pentru uniti de msur identice cu cele utilizate în tariful vamal combinat, pe baza cruia au fcut aprovizionarea cu bunuri, materii, i materiale, înregistrarea acestora în stoc i inventare, etc. eliminând conversiile de uniti de msur, care necesit calcule aritmetice pentru normalizarea valorilor în cazul utilizrii exclusive doar a unitilor de msur din sistemul internaional de uniti de msur.
În cazul în care unitile de msur utilizate comercial de anumii contribuabili pentru mrfurile din stocurile lor nu sunt regsite printre unitile de msur tolerate din nomenclator – contribuabilul trebuie s pregteasc înregistrrile privind stocurile prin raportare la unitatea de msur din sistemul internaional de msuri (standardizat ISO, sistem MKS) i s declare în câmpul UOMToUOMBaseConversionFactor din înregistarea Products – factorul de conversie utilizat fat de unitatea de msur specific (de exemplu metru cub m3 pentru uniti de volum de exemplu pentru lichide sau mrfuri în vrac, metru ptrat m2 pentru uniti de suprafa de exemplu pentru textile, etc.).
2.8 MovementTypeTable/ MF.MT.2/ MovementType - În cazul în care exist o clasificare mult mai detaliat decât nivelele prezentate ca exemplu trebuie s existe o mapare a sistemului companiei cu valori precum cele prezentate? Daca da, când se va primi lista complet a acestor valori?
Rspuns 5: Nomenclatorul aplicabil este Nomenclator Codificare micri de produse în stocuri. Tipurile de micri de stocuri definite in ERP-ul societii trebuie mapate la cele definite în nomenclator.
2.9 Products / MF.P.2 /ProductCode - Sistemul utilizat de companie permite înregistrarea de tranzacii, pe anumite procese, fr a utiliza un cod de produs ci doar un text. Ce se va exporta în acest caz?
Rspuns 6: Din întrebarea Dvs. înelegem c în cazul menionat, diferitele categorii de produse sunt identificate în evidentele de gestiune doar prin denumirea standard fr a fi alocate coduri de produse. Aadar, dac denumirea are rolul de cheie unic de identificare a tipurilor de produse, aceasta poate fi utilizat drept cod de produs i raportat în condiiile în care respecta formatul de raportare pentru câmpul ProductCode.
2.9 Products/ MF. P.6 ProductCommomdityCode – explicai utilizarea acestui câmp?
Rspuns 7: Cod NC (8 cifre) va fi raportat acolo unde este cerut conform legislaiei române, în special în cazuri precum:
tranzacii de import / export
micri intracomunitare supuse raportrii Intrastat
achiziii/livrri supuse taxei locale inversate de TVA in funcie de codul NC
tranzaciile cu produse accizabile pentru care accizele se determina pe baza codului Cod NC.
Câmpul este de tipul text – SAFTmiddle1TextType – deci primete valori iruri de caractere:
Atunci când codul NC nu este cunoscut sau nu este alocat se va completa cu irul NULL – format din patru caractere alfabetice.
Atunci când este cunoscut acest cod – se trimite irul alfanumeric format doar din cifrele din coloana Cod NC (cate 1 pana la 8 cifre pentru categoriile din ce în ce mai detaliate). În nomenclatorul ataat Fiierului SAF-T - Nomenclatorul Tarifar vamal combinat - vei gsi cele mai generale categorii – codificrile cu o cifr sunt numite clase.
2.9 Products/ MF.P.9/ UOMBase - Nu exist o legtur cu Unit of Measure din seciunea 2.6 UOMTable. Deci se furnizeaz unitatea de msur Intern (i nu ISO)?
Rspuns 8: Nomenclatorul cuprinde codurile i descrierile standard ale unitilor de msur utilizate, în majoritatea lor uniti de msur tolerate, cel mai bine adaptate diferitelor categorii de produse, modului lor de prezentare comercial, împachetare, aprovizionare i desfacere. În nomenclator sunt incluse unitile de msur din sistemul internaional de uniti de msur (MKS) – standardizat ISO, dintre care unele sunt mai puin adaptate utilizrii comerciale (de exemplu unitatea de msur pentru volum m3
pentru împachetarea comercial a buturilor în recipiente mici (butelii, sticle) cu volumul mai mic de 1 dm3 pentru care mai potrivit este litrul, o unitate de msur tolerat.
Utilizarea unitilor de msur tolerate din nomenclator – mai bine adecvate tranzacionrii comerciale de bunuri – simplific pregtirea Declaraiilor informative D406 de ctre contribuabili, acetia putând utiliza codurile pentru uniti de msur identice cu cele utilizate în tariful vamal combinat, pe baza cruia au fcut aprovizionarea cu bunuri, materii, i materiale, înregistrarea acestora în stoc i inventare, etc. eliminând conversiile de uniti de msur, care necesit calcule aritmetice pentru normalizarea valorilor în cazul utilizrii exclusive doar a unitilor de msur din sistemul internaional de uniti de msur.
În cazurile extreme, când contribuabilul raportor utilizeaz alte uniti de msur decât cele din nomenclatorul derivat din tariful vamal combinat, care include uniti de msur din sistemul internaional de msuri i uniti de msur tolerate, larg utilizate comercial – acesta va face conversia valorilor la unitatea de msura din sistemul internaional de msuri (MKS, ISO) cea mai potrivit.
Care este maparea dintre UOM standard(TARIR) i UOM contribuabil?
Rspuns 9: Fiecare contribuabil în parte folosete uniti de msur specifice produselor cu care opereaz comercial (fie sunt produse i vândute, fie sunt aprovizionate s revândute, fie sunt materii, materiale i subansamble utilizate la fabricarea produselor proprii, sau la efectuarea unor servicii proprii pe care le vinde). UOM Contribuabil este o selecie fcut de fiecare contribuabil în parte din
5
nomenclatorul de uniti de msur (bazat pe unitile de msur din tariful vamal combinat), care pentru operativitate este utilizat de contribuabilul raportor.
Nomenclatorul cuprinde codurile i descrierile standard ale acestor uniti de msur, în majoritatea lor uniti de msur tolerate, cel mai bine adaptate diferitelor categorii de produse, modului lor de prezentare comercial, împachetare, aprovizionare i desfacere. În nomenclator sunt incluse unitile de msur din sistemul internaional de uniti de msur (MKS), dintre care unele sunt mai puin adaptate utilizrii comerciale (de exemplu unitatea de msur pentru volum m3 pentru împachetarea comercial a buturilor în recipiente mici (butelii, sticle) cu volumul mai mic de 1 dm3 pentru care mai potrivit este litrul, o unitate de msur tolerat.
2.10 PhysicalStock /MF.PS.12/ UnitPrice - în sistem unitatea de pre poate fi diferit de la document la document i astfel nu va fi asociat în mod unic la tot stocul existent. Care este relevana acestui câmp?
Rspuns 10: Conform reglementarilor contabile in vigoare, societatea trebuie sa organizeze evidenta cantitativa si valorica a stocurilor. Elementul MF.PS.12 reprezint costul unitar folosit pentru evidenta stocurilor conform fisei de magazie.
În situaia în care evidenta stocurilor se ine conform metodei FIFO i exist intrri de aceleai produse cu acelai cod la costuri diferite, se va completa unit price de mai multe ori pentru acelai cod de produs – în înregistrri corespunztoare unor date diferite.
2.12 Assets/ MF.A.10/ Suplier - Ce se întâmpl în cazul mijloacelor fixe realizate în regie proprie la care nu se poate asocia furnizorul?
Rspuns 11: În cazul mijloacelor fixe dezvoltate intern, se vor declara detaliile societii (contribuabilul raportor care a realizat mijlocul fix în regie proprie) care se raporteaz la elementul MF.A.10/Supplier.
2.12 Assets/ MF.A.29/ ExtraordinaryDepreciationsForPeriod - Fiind informaie obligatorie, ce se va completa când nu exist valori pentru aceast tipologie?
Rspuns 12: Daca nu exist valori, se va raporta zero.
În fiierul excel exist foarte multe seciuni în care sunt solicitate coduri (de ex. ProductCode) sau tipologii (de ex. Account type, Movement type; Record ID vs Transaction ID din sheet-ul General Ledger Entries ) – nu este clar dac e vorba de codurile/tipologiile interne ale fiecrui contribuabil sau dac va exista o mapare a acestora la nite coduri/tipologii standard. De asemenea, exist câmpuri pentru care nu este deloc clar informaia dorit (cum este la Assets/MF.A 14).
Rspuns 13: Nomenclatoarele predefinite sunt publicate împreuna cu Schema. Pentru celelalte elemente, se raporteaz informaii conform regulilor aplicabile pentru acel element pe baza evidentelor contribuabilului. Elementul Assets/MF.A 14 face referire la scopul evalurii activului care poate fi: contabil, fiscal sau comercial. In fiierul SAF-T se vor raporta doar informaiile contabile referitoare la mijloacele
6
fixe – adic registrul de mijloace fixe conform evidentelor contabile ale societii. De exemplu, nu se raporteaz informaii cu privire la reevalurile efectuate si valorile raportate in scopul stabilirii impozitelor locale. Aadar la elementul Assets/MF.A 14 va raporta faptul ca este vorba despre evaluare contabila.
Cine va defini taxonomia i când va fi pus la dispoziie? (MF.T.2).
Rspuns 14: Sub-seciunea Taxonomie nu se va raporta.
Ce reprezint Tax point date din structura facturii (Suppliers / S.I.43)
Rspuns 15: Tax point date reprezint data exigibilitii taxei – acest element este clarificat în variant actualizat a Schemei SAF-T.
Raportarea se face la nivel de factur sau la nivel de linie? (Invoice line/ S.I.20)
Rspuns 16: Raportarea se va face la nivel de linie de factura.
Pentru documentarea sub-seciunii „2.3 Customers” este obligatoriu s completm câmpul „cont bancar”. Din punctul nostru de vedere, este imposibil s avem informaii referitoare la contul bancar pentru toi clienii notri, menionm ca nu deinem aceste informaii i nici nu ne sunt utile.
Rspuns 17: In versiunea actualizata a Schemei SAF-T acest element este opional
Sub-Sectiunea „2.12 Assets” elementul „ExtraordinaryDepreciationsForPeriod” – ne putei detalia, la ce se refer?
Rspuns 18: Elementul MF.A.29 ExtraordinaryDepreciationsForPeriod se refera la ajustrile de depreciere înregistrate pentru respectivul mijloc fix (de exemplu ajustari de depreciere inregistrate in situatia in care mijlocul fix este trecut in conservare , etc.).*
Seciune GeneralLedgerEntries
Journal/ GL.7/Type - Ce valori sunt ateptate pentru acest element?
Rspuns 19: Acest element va include codificarea jurnalelor auxiliare folosite de contribuabil in sistemul contabil (de exemplu pentru operaiunile de banca, facturile de la furnizori, facturile ctre clieni, mijloace fixe, etc.). In situaia in care nu se folosesc jurnale auxiliare, iar toate înregistrrile contabile se înregistreaz direct in registrul jurnal general, se va raporta un singur tip de jurnal corespunztor registrului jurnal general.
7
Seciune Structures
5.10 InvoiceStructure / S.I.9/ Invoice type - Sunt mai multe tipuri de facturi de client decât valorile menionate. Se poate transmite conform gruprii utilizate în companie pentru raportare intern?
Rspuns 20: NU. Valorile menionate la descrierea elementului S.I.9/Invoice Type sunt cu titlu de exemplu. Se va raporta unul din cele 5 coduri prevazute pentru raportare conform nomenclatorului Nom_Tipuri_facturi prevzut pentru acest element.
Seciune Source documents
SD.P.9 - În cazul în care sunt pli efectuate ctre angajai pentru care raporteaz expense report, se raporteaz aceast plat?
Rspuns 21: In seciunea Source Documents, sub-seciunea Payments se raporteaz toata plile efectuate de societate, inclusiv cele ctre salariai pentru decontarea unor cheltuieli.
În Sub-seciunea „4.3 Payments” se vor documenta doar plile efectuate de societate sau i încasrile?
Rspuns 22: In sub-seciunea “4.3 Payments” se vor raporta atât plile cât i încasrile.
Seciunea „4.3 Payments” subsectiunea „DocumentTotals” se refer la impozitul pe pltit ? Alte impozite decât comisioanele bancare?
Rspuns 23: Da, in cazul impozitelor cu retinere la sursa, in aceasta seciune se raporteaz distinct baza de impunere, taxele asociate si suma bruta aferenta plailor efectuate.
Sub- seciunea „StockMovement” - are legtur cu modulul de furnizori & clieni?/ Înregistrarea la nivel de reper (micarea stocului) trebuie asociat cu factura de achiziie i evideniat cu nota contabil?
Rspuns 24: In sub-seciunea “StockMovement” se raporteaz micrile de stocuri pe baza documentelor corespunztoare i este independent de raportarea facturilor de achiziie i a facturilor de vânzare. In cazul achiziiei, înregistrarea la nivel de reper se efectueaz în baza documentelor justificative primare de recepie a stocului, de exemplu NIR. Factura de achiziie se raporteaz în seciunea de documente sursa – facturi achiziii.
Înregistrarea la nivel de reper (micarea stocului) este verificat prin asociere cu facturile de achiziie i evideniat în notele contabile.
Care e diferena între Tax Percentage i Flat Tax Rate?
Rspuns 25: Tax percentage reprezint procentul de taxa aplicabil pentru codul de tax respectiv. Flat
8
Tax Rate nu este o informaie raportabil având în vedere specificaia fiierului SAF-T avut în vedere pentru raportarea din Romania.
In sheet-ul TAX-IMP – Impozite sunt codificate toate tipurile de taxe i impozite – cum se va face legtura între toate acestea i informaiile care trebuie raportate (GL, AP/AR, Stocuri, mijloace fixe)? V rugam dac se poate s ne ajutai cu câteva exemple.
Rspuns 26: În schema actualizata sunt disponibile nomenclatoare privind tipurile de taxe avute în vedere prin raportarea SAF-T. De exemplu la selectarea Tax Type TVA, exist mai multe nomenclatoare privind codurile de taxa – TVA, care vor fi alocate tranzaciilor raportabile prin SAF-T. Drept exemplu, a se vedea legtura între TaxCode i seciunile privind facturi i plti din documente surs, respectiv GL.
Cum ar trebui s procedm în cazul în care nu avem în sistem un anumit câmp care este obligatoriu pentru raportarea SAF-T (e.g. MF.C.5 - General ledger account code for this customer - nu exist un cont analitic pentru fiecare client), dar nu este obligatoriu potrivit legislaiei contabile?
Rspuns 27: Elementul AccountID din sub-sectiunea Customer (General ledger account code for this customer) se refer la contul analitic în care se înregistreaz tranzaciile cu respectivul client. Schema nu cere ca pentru fiecare client sa existe un cont analitic diferit. Tranzaciile pentru mai muli clieni (identificai prin customerID diferit) vor fi întregistrate într-un singur cont analitic (AccountID). Altfel, toate informaiile ce sunt etichetate ca fiind obligatorii vor trebui raportate în fiierul SAF-T.
Întrebare: Campul „Suplier ID” si „Customer ID” din sectiunea General Ledger trebuie declarat doar pentru facturile de furnizori si facturile de clieni? In registrul Jurnal avem si diverse note contabile care se întocmesc pe cumulat ( note contabile pt minusuri/plusuri de inventar, nota contabila de trecere TVA neexigibila in TVA deductibila, conturile FAR) cum putem aloca acestora un „Suplier ID”/„Customer ID” , nu exista nici o regula de completare pentru acestea. De asemenea noi nu avem un cod client asociat in mod unic pentru vanzarile ocazionale catre persoane fizice ( vanzare de masini catre persoane fizice) motiv pentru care atunci cand nu avem CNP-ul acestora nu ne putem folosi de regula stabilita de dv si anume: „04 urmat de cod client asociat în mod unic de ctre operatorul economic, pentru pers. fizice care nu îi declar CNP-ul pe tranzacii” Pentru aceste vanzari avem un singur cod client ce este alocat pentru toate vanzarile catre persoanele fizice. Cum o sa tratam acest caz? A sa avem eroare deoarece in master files avem un singur cod client iar in Source documents o sa avem toate facturile emise catre persoanele fizice (factura cu factura)?
Rspuns 28: Informaiile se raporteaz în fiierul standard de audit prin urmtoarele seciuni i înregistrri:
1. În seciunea 2. MasterFile, sub-seciunea GeneralLedgerAccounts (conturi contabile Registrul Jurnal), cu rulajul i soldurile acestora pentru perioada de raportare
2. În seciunea 3. GeneralLedgerEntries 3. În seciunea Source Documents, sub seciunile Sales Invoice (facturi de vânzare emise), Purchase
Invoices (Facturi de achiziie primite) i Payments (pli efectuate / primite).
9
Informaiile corelative despre clieni i furnizori sunt raportate prin Seciunea Master File, subseciunile Customer (clieni) i Suppliers (furnizori). Legtura dintre înregistrrile contabile i clienii i furnizorii contribuabilului declarant se face prin intermediul codurilor de client i respectiv de furnizor – definite în subseciunile 2.3 Customers i 2.4 Suppliers în câmpurile CustomerID i respectiv SupplierID. Drept urmare – este obligatorie completarea câmpurilor „SupplierID” i ”CustomerID” în seciunea 3. GeneralLedgrEntries – la nivelul fiecrei înregistrri i în subseciunile 2.4 Suppliers (furnizori) i 2.3 Customers (clieni) din seciunea 2. Master File.
Campurile “SupplierID” si “CustomerID” sunt obligatorii si trebuie raportate la liniile relevante din seciunea 3.GeneralLedgerEntries, respectiv acolo unde sunt înregistrri de datorii si creane pentru care, conform reglementarilor contabile aplicabile, exista obligaia de contabilizare pe fiecare persoana fizica sau juridica. Se va raporta fie CustomerID, fie SupplierID (in functie de situatie: incasare/plata, factura de vazare/factura de achizitie), iar celalalt element se completeaza cu NULL.*
Pentru tranzaciile si liniile corespunztoare din seciunea 3.GeneralLedgerEntries care nu reprezint înregistrri de datorii si creane pentru care, conform reglementarilor contabile aplicabile, exista obligaia de contabilizare pe fiecare persoana fizica sau juridica, in campurile “SupplierID” si “CustomerID” se va completa cu codul unic al contribuabilului raportor. Aceste înregistrri sunt difereniate prin faptul c SupplierID = CustomerID = RegistrationNumber (din structura 5.5 CompanyHeaderStructure), prefixat cu „00”, fr particula „RO” (în RegistrationNumber se completeaz CUI-ul contribuabilului raportor).
Cod unic pentru client este format în acest caz astfel: tip (dou cifre zecimale) urmat de codul unic al clientului, dup cum urmeaz: 1. 00 urmat de CUI - unde tipul este 00, iar CUI este codul unic de identificare pentru operatorii economici înregistrai în România. Codul este un numr întreg zecimal, cu 1 pân la 9 cifre, urmat de o cifr de control - Exemplu: 004221306 - pentru Ministerul Finanelor Publice 2. 01 urmat de codul de ar (conform ISO 3166-1 - 2 litere) i de Codul unic de identificare pentru TVA din statul membru respectiv- pentru operatorii economici din statele membre ale UE, mai puin România, verificate conform sistemului VIES (VAT Information Exchange System) - Exemplu: 01GR123456789 sau 01HU12345678 3. 02 urmat de codul de ar i de codul unic de identificare din statul respectiv, care nu este nici România, nici stat membru UE - pentru operatorii economici din alte state care nu sunt România sau membre UE - Exemplu: 02TK123005284 4. 03 urmat de CNP pentru persoane fizice ceteni români sau 03 urmat de codul unic personal pentru persoane fizice rezidente în România (acelai format cu CNP-ul, dar la care prima cifra este 7 sau 8) 5. 04 urmat de cod client asociat în mod unic de ctre operatorul economic, pentru pers. fizice care nu îi declar CNP-ul pe tranzacii (exemplu: comer online). 6. 05 urmat de codul de ar i de cod client asociat în mod unic de ctre operatorul economic - pentru operatorii economici care nu sunt înregistrai în scopuri de TVA din statele membre ale UE, mai puin România 7. 06 urmat de codul de ar i de cod client asociat în mod unic de ctre operatorul economic - pentru operatorii economici care nu sunt înregistrai în scopuri de TVA din statele non-UE
Întrebare: De asemenea noi nu avem un cod client asociat in mod unic pentru vanzarile ocazionale catre persoane fizice ( vanzare de masini catre persoane fizice) motiv pentru care atunci cand nu avem CNP-ul acestora nu ne putem folosi de regula stabilita de dv si anume: „04 urmat de cod client asociat în mod unic de ctre operatorul economic, pentru pers. fizice care nu îi declar CNP-ul pe tranzacii” Pentru aceste vanzari avem un singur cod client ce este alocat pentru toate vanzarile
10
catre persoanele fizice. Cum o sa tratam acest caz? A sa avem eroare deoarece in master files avem un singur cod client iar in Source documents o sa avem toate facturile emise catre persoanele fizice ( factura cu factura)?
Rspuns 29: Conform reglementrilor contabile în vigoare, contabilitatea furnizorilor i clienilor, a celorlalte datorii i creane se ine pe categorii, precum i pe fiecare persoan fizic sau juridic Prin fiierul standard de audit (SAF-T) se transmit informaiile corelative despre clieni i furnizori, care sunt raportate prin Seciunea Master File, subseciunile Customer (clieni) i Suppliers (furnizori). Legtura dintre înregistrrile contabile i clienii i furnizorii contribuabilului declarant se face prin intermediul codurilor de client i respectiv de furnizor – definite în subseciunile 2.3 Customers i 2.4 Suppliers în câmpurile CustomerID i respectiv SupplierID. Drept urmare – este obligatorie corelarea informaiilor despre identitatea clienilor persoane fizice i identitatea clienilor i furnizorilor aa cum este înscris în documentele surs. Completarea câmpurilor „SupplierID” i ”CustomerID” în seciunea 3. GeneralLedgrEntries – la nivelul fiecrei înregistrri i în subseciunile 2.4 Suppliers (furnizori) i 2.3 Customers (clieni) din seciunea 2. Master File se va face conform instruciunilor i definiiilor din Schema SAF-T.
Întrebare: In campul „ Invoice Line Amount” se va declara valoarea pentru fiecare linie din factura , fara taxe si cost de transport ? ce se va intampla cu valoarea transportului aceasta rmâne nedeclarata sau trebuie alocata pe fiecare linie din factura?
Rspuns 30: Prin fiierul standard de audit se transmit datele contabile aa cum sunt înregistrate în evidenele contribuabililor operatori economici cu obligaii de declarare D406. Informaia din facturile de achiziii i vânzri se transmite fr repartizri de costuri (suplimentare) de transport pe fiecare linie din factur. Prin seciunea SourceDocuments se raporteaza TOATE facturile de achiziie, respectiv facturile de vânzare, atât cele emise pentru bunuri, cât i cele pentru servicii, la nivel de linie. Intre elementele de raportat exista elementul GoodServicesID care arat dac este vorba despre bunuri sau servicii iar la elementul ProductDescription se mentioneaza descrierea bunurilor sau a serviciilor. Aadar, pentru valoarea transportului se vor raporta una sau mai multe linii de factur separate, aa cum acestea apar pe factur. Dac în factur sunt enumerate înregistrri de produse i servicii vândute sau cumprate cu transport inclus, caz în care pe factur nu apar poziii separate pentru transport, atunci acestea se raporteaz aa cum sunt înregistrate în factur.
În situatia facturilor de achiziii sau de vânzare pentru servicii sau materiale nestocate în seciunea Source documents raportarea la nivel de linie se va face conform înregistrrilor din evidena contabil (fie agregat fie la nivel de linie).
Întrebare: Codurile de taxa (cod tax) se vor aloca doar facturilor de vânzri si cumprri? Ce coduri de taxa alocam diverselor note contabile de exemplu, note de provizioane, note privind minusurile/plusurile de inventar, etc. In nomenclatoare nu gasesc decat coduri de taxa pentru facturile de vanzari si cumparari precum si coduri de taxa pentru impozitele declarate in D100. Nu am gasit un nomenclator pentru impozitul pe profit.
Rspuns 31: Tipurile de taxe raportabile de ctre contribuabilul raportor sunt transmise prin subseciunea 2.5 TaxTable prin elementele TaxTableEntry, câte o înregistrare pentru fiecare tip de tax raportabil. Schema SAF-T i specificaiile tehnice sunt construite pentru a permite raportarea tuturor tipurilor de taxe i impozite stabilite legal în România, nu doar TVA i impozitul pe veniturile cu reinere la surs.
11
TAX-IMP_Impozite - Nomenclatorul de coduri pentru impozitele i taxele la bugetul statului - conine codurile pentru completarea câmpului TaxType din 5.15 TaxInformationStructure, respectiv TaxType din TaxTableEntry. Este un cod numeric format din 3 cifre zecimale. În raportarea SAF-T se vor selecta taxele pentru care sunt definite coduri de tax (TaxCode) în acest sens, adica TVA si impozite cu retinere la sursa. Utilizarea acestor coduri în raportarea SAF-T este obligatorie.
Tipurile de taxe sunt descrise prin dou elemente: - TaxType (tipul taxei) – cu coduri descrise în nomenclatorul TAX-IMP_Impozite i - TaxCode (codul de tax) - codul individual al unei taxe – cu coduri detaliate descrise în
nomenclatoarele detaliate pentru TVA i pentru impozite cu reinere al surs. Pentru a uura cutarea i utilizarea codurilor de TVA aplicabile, acestea sunt puse în tabelele urmtoare din Schema SAF-T:
- Legenda coduri taxa TVA - Livrri - Achiziii deductibile 100% - Achiziii deductibile 50% baserate - Achiziii ded 50%_not_known - Achiziii ded 50% - Achiziii neded - Achiziii baserate - Achiziii not known
Pentru Sectiunea General Ledger Entries, Sectiunea Source Documents, subsectiunile Sales Invoices, Purchases Invoices sau Sectiunea Source Documents, subsectiunea Payments se vor avea in vedere urmatoarele reguli de raportare a elementelor TaxType, respectiv TaxCode:
Pentru TVA: TaxType TVA asa cum a fost definit in nomenclatorul Tax_Imp i codurile de taxa (TaxCode)
aferente corespunztor înregistrrilor contabile cu impact pentru înregistrarea in evidentele contabile a TVA, asa cum au fost ele definite in Schema:
Pentru WHT: TaxType WHT asa cum a fost definit in nomenclatorul Tax_Imp i codurile de taxa (TaxCode)
aferente corespunztor înregistrrilor contabile de constituire de WHT, asa cum au fost ele definite in Schema - WHT – nomenclator
Pentru alte taxe si impozite:
In cazul celorlalte tipuri de taxe si impozite, pentru raportarea SAF-T, contribuabilii au 2 optiuni, acestia putand decide cum le este favorabil sa declare, in functie de rationamente de business, tehnice sau alte considerente
Optiunea 1: Pentru TaxType se va selecta tipul de impozit asa cum a fost definit in nomenclatorul Tax_Imp (altul decat 000 – Taxe) si TaxCode - 000000 (ase de zero) cu care se completeaz acest câmp atunci când TaxType este diferit de TVA sau WHT
Optiunea 2: Pentru TaxType se va selecta tipul de impozit GENERIC asa cum a fost definit in nomenclatorul Tax_Imp, 000 – Taxe (cod nou introdus) si TaxCode - 000000 (ase de zero) cu care se completeaz acest câmp atunci când TaxType este diferit de TVA sau WHT
12
Prin aceasta abordare se raspunde solicitarii venite din partea unor contribuabili de a simplifica raportarea, dar nici nu se ingradeste posibilitatea de raportare integrala, defalcata pe toate tipurile de taxe, in cazul in care contribuabilii doresc acest lucru
Pentru inregistrarile contabile si platile care nu sunt relevante pentru niciun fel de impozite si taxe, se va raporta Tax Type 000 si TaxCode 000000
Întrebare: In sectiunea „2.5 TaxTable” va fi declarat doar un dictionar ( nomenclator) fcând referire la toate tipurile de impozite Gestionate de contribuabil?
Rspuns 32: În seciunea MasterFiles, subsectiunea TaxTable se vor declara tipurile de taxe raportabile de ctre contribuabil i codurile de taxe aferente. În fapt aceste taxe raportabile de ctre contribuabilul raportor sunt toate categoriile de impozite i taxe pentru care contribuabilul declarant este înscris sau / i are obligaii fiscale.
Tipurile de tax se transmit cu coduri din TAX-IMP_Impozite, iar codurile de taxa se transmit cu coduri din nomenclatorul TaxCode. Pentru TVA si pentru impozite reinute la sursa au fost definite coduri de taxe (TaxCode) si au fost publicate nomenclatoarele:
- Nomenclator Coduri de Tax TVA pentru operaiuni de vânzare, - Nomenclator Coduri de Tax TVA pentru operaiuni de achiziie cu TVA deductibil 100%, - Nomenclator Coduri de Tax TVA pentru operaiuni de achiziie cu TVA deductibil 50% la care se
aplic pro-rata - Nomenclator Coduri de Tax TVA pentru operaiuni de achiziie cu TVA 50% i pentru care nu se
cunoate în momentul primirii facturii dac factura este deductibil conform pro-rata - Nomenclator Coduri de Tax TVA pentru operaiuni de achiziie cu TVA deductibil 50% - Nomenclator Coduri de Tax TVA pentru operaiuni de achiziie cu TVA nedeductibil - Nomenclator Coduri de Tax TVA pentru operaiuni de achiziie cu pro-rat - Nomenclator Coduri de Tax TVA pentru operaiuni de achiziie cu TVA si pentru care nu
cunoate în momentul primirii facturii dac factura este deductibila conform pro-rata - Nomenclator Codificri taxe i impozite reinute la surs
Întrebare: Care este diferenta intre elementele „ProductCommodityCode” si „StockAccountCommodityCode” – in ambele câmpuri se vor completa codurile NC? Codurile NC vor fi obligatorii de completat doar pentru operaiunile de import export iar pentru celelalte câmpul poate sa fie nul? S-au adus lamuriri pentru ProductCommodityCode” se aplica aceleasi lamuriri si pentru campul „StockAccountCommodityCode”?
Rspuns 33: Pentru transmiterea informaiilor despre produsele stocate i pentru micrile de bunuri din stocuri se utilizeaz sub-seciunile 2.8 MovementTypeTable i 2.9 Products. Produsele sunt codificate uniform la nivel internaional conform Nomenclatorului Tarifar vamal combinat (NCB_2021_TARIC3), care are definiii precise pentru aproape toate categoriile de produse comercializate, la nivel internaional. Aceast codificare se bazeaz pe Tariful Vamal Combinat, care este larg utilizat pentru operaiuni de import – export i pentru tranzacii comerciale, pentru a clasifica distinct produsele. Nomenclatorul Tarifar vamal combinat (NCB_2021_TARIC3) cuprinde codurile utilizate pentru completarea câmpului ProductCommodityCode în subseciunea Product din documentele surs - facturi vânzare, facturi achiziie, stocuri.
Utilizarea acestor coduri în raportarea SAF-T este obligatorie.
13
Conform schemei publicate, atat la elementul Product CommodityCode (in subseciunea Product) cat si la elementul StockAccountCommodityCode (in subsectiunea PhysicalStockEntry) se raporteaz clasificarea pentru import /export (NC code). Aceasta informaie va fi raportat acolo unde este ceruta conform legislaiei în vigoare (a se vedea rspunsul inclus în ghid in acest sens).
Întrebare: Fisierul s-ar poate splita in mai multe sub-fisiere?
Rspuns 34: DA. Contribuabilii cu obligaii de depunere trebuie s pregteasc i s depun Declaraiile informative D406 pân la data limit stabilit prin actul normativ.
În cazul contribuabililor cu activitate economic mare, materializat într-un numr foarte mare de înregistrri contabile i informaii de transmis prin Fiierul Standard de Control Fiscal (SAF-T) – modul de pregtire i depunere a Declaraiei Informative D406 permite depunerea folosind mai multe formulare D406, fiecare cu seciuni sau sub-seciuni din declaraia informativ, transmise succesiv de ctre contribuabilii respectivi pentru perioada de depunere (lun, trimestru), pân la data limit. Sistemele ANAF asigur primirea, procesarea i pstrarea integral a Declaraiilor informative D406.
Raportarea modal reprezint raportarea datelor în mai multe pri (nu aceeai declaraie de mai multe ori) – mai multe D406 în aceeai lun pentru fiecare contribuabil.
Raportarea modal – privete strict planul de transport al datelor de la contribuabil la ANAF, pentru raportarea în format electronic. Raportarea modal se aplic pe un fiier XML generat i funcioneaz identic pentru toate fiierele extrase / pregtite, indiferent de numrul câmpurilor i coninutul lor.
Împrirea fiierelor XML pentru raportare modal cu mai multe formulare D406 pentru aceeai lun este în sarcina contribuabilului, la pregtirea Declaraiei informative D406. Aceast metod se folosete în cazul unor Declaraii de dimensiuni foarte mari, iar împrirea se face la nivel de Sub- Seciune.
Validarea unui fiier XML cu informaii SAF-T se face individual fiier cu fiier.
Detaliile sunt descrise în Ghidul Contribuabilului pentru pregtirea i depunerea DECLARAIEI INFORMATIVE D406 FIIERUL STANDARD DE CONTROL FISCAL (SAF-T), în capitolul 8.3 Raportarea modal.
Întrebare: Ar putea fi o abordare a implementarii SAF-T pe faze ? (ca spre ex. Norvegia ) ex. Faza 1 – fisierul sa cuprinda spre ex. Master File + General ledger Entries , ca apoi intr-o faza 2 sa cuprinda si ‘’Source documents’’. Colegii mei cu experienta in multiple tari cu implementare SAF-T spun ca 01.01.2022 nu ar fi un termen realizabil daca ne propunem sa fie toate informatiile de la inceput.
Desi complexitatea ramane mare, totusi data de 01.01.2022 nu s-a schimbat, si ramane obligativitatea - raportare lunara… (Obligaia de depunere a Declaraiei Informative D406 privind Fiierul Standard de Control Fiscal (SAF-T) devine efectiv pentru fiecare categorie de contribuabili de la datele de referin stabilite prin OP ANAF [...], astfel: Pentru contribuabilii aflai deja în categoria mari contribuabili – de la data de 1 ianuarie 2022 (data de referin pentru mari contribuabili)
14
Din intelegerea noastra nici o tara (exceptand Polonia) nu a cerut raportare obligatorie pentru SAF-T lunar. Am inteles ca ar exista intentia sa fie inlocuite o parte din declaratiile de TVA (300,390,394…) Acesta sa fie motivul ? Dar daca da cand s-ar inlocui acestea? (in Ghid apare doar: Simplificarea unor declaraii, precompletarea i chiar eliminarea unora, întrucât ANAF va avea un set semnificativ de date din sistemul financiar-contabil.) Asteptam sa vedem unde si cand va fi publicat D406T (inclusiv validatorul) ….inteleg ca ne asteptam undeva in august sa fie , asa este?
Rspuns 35: Da, va fi o abordare etapizata per categorii de contribuabili, incepand cu marii contribuabili, cu raportare lunara, urmand linia de declarare TVA. Intr-adevar, obiectivul este de eliminare /precompletare a unor declaratii si orientarea catre desk-audit. Analiza simplificarii procesului de declarare se va face in perioada urmatoare si se va valida pe parcursul primei etape de raportare efectiva. Chiar daca unele tari au inceput simplificat, au extins pe parcurs schema SAF-T.
Întrebare: In ghid pagina 40 se face referire la : Anexa 13.1: Fiierul Standard de Control Fiscal SAF-T i nomenclatoare. Urmeaza sa fie publicata o asftfel de anexa?
Rspuns 36: Schema SAF-T în format MS EXCEL publicat este Anexa 13.1 Fiierul Standard de Control Fiscal SAF-T i nomenclatoarele.
Întrebare: 1) Header H.2 TaxAccountingbasis
In XSD apare ca valoare unica A
Dar in Excell pare asa:
15
Deci cum va fi correct?
Rspuns 37: Pentru entitile care organizeaz contabilitatea în partid dubl se va selecta A (Accounting), pentru entitile înregistrate doar în scop de TVA care nu au obligaia organizrii contabilitii în Romania, se va selecta I (Invoice Accounting). Fiierul XSD i Ghidul contribuabilului se vor actualiza în consecin.
Întrebare: Observatii/inconsistente la schema XSD comparand cu EXCEL:
1. S.CMH.1 – Registration number In Excell :
In XSD pare sa fie o copie din XSD Norvegia!!!!!
16
Întrebare: MF.GLA.7 – Account type
Rspuns 40: Fiierul a fost corectat.
Întrebare:
17
1. Lunar sau trimestrial D406 trebuie transmisa si contine sectiunea 2.7 AnalysisTypeTable [Tabel Tipuri Analiz] cu 3 elemente din care primele 2 sunt Mandatory si ultimul este optional. (AnalysisType M, AnalysisID M si AnalisysAmount de tip optional ).
Poate ca nu am citit cu atentie sau nu am regasit eu informatia insa Întrebarea este cum va fi completata acesta sectiune de catre :
a. un contribuabil care nu are organizata evidenta/analize interne pe centre de cost ? b. un contribuabil care are acesta organizare insa nu doreste sa transmita acesta informatie ?
Sunt de parere ca organizarea inregistrarilor si analizele pe center de cost/ directii de bussines/departament este pana la urma o optiune interna a contribuabilului conform nevoilor intene de raportare si urmarire a afecerii proprii! De ce trebuie sa raporteze acest lcuru in Saf-t ?
Este optionala raportarea acestei sectiuni sau este obligatorie caz in care cum va fi transmisa in cazul unui contribuabil de la punctul a?
Rspuns 41: Informaiile cu privire la structura de centre de cost/direcii de business/departamente sunt obligatorii de raportat in sub-seciunea “AnalysisTypeTable” din seciunea “Masterfiles”. La nivel de linie in “GeneralLedgerEntries” sau “SourceDocuments”raportarea elementelor/structurii “Analysis” este opionala.
Conform legii contabilitii, entitatile au obligaia organizrii contabilitii de gestiune adaptate la specificul activitii. În funcie de specificul activitii desfurate, contabilitatea de gestiune va asigura, între altele, înregistrarea operaiilor privind colectarea i repartizarea cheltuielilor pe destinaii, respectiv pe activiti, secii, faze de fabricaie, centre de costuri, centre de profit, dup caz, precum i calculul costului de achiziie, de producie, de prelucrare al bunurilor intrate, obinute, lucrrilor executate, serviciilor prestate, produciei în curs de execuie, imobilizrilor în curs etc..
Aadar, în sub-sectiunea “AnalysisTypeTable” se vor raporta structurile de centre de cost, centre de profit, sau alte structuri prin intermediul crora se asigur cerinele de organizare a contabilitii de gestiune la nivelul entitii. Cardinalitatea stabilit pentru elementul AnalysisTypeTableEntry este 0..*, ceea ca permite depunerea raportrii fr a include informaii la acest câmp (atunci când contribuabilul nu are nimic de declarat pentru perioada de raportare).
Întrebare: In documentul PDF trimis ( Ghid), la pagina 40 regasim textul de mai jos :
"Informaiile despre PARTENERI se raporteaz sub forma Catalogului de Parteneri (clieni, furnizori i proprietari ai activelor) astfel: Prin Declaraia informativ D406 depus vor fi raportai TOI clienii i furnizorii ai fiecrui
contribuabil, folosind structura de date Clients (Clieni) i respectiv cea de Suppliers (Furnizori) din seciunea MASTERFILES (Fisiere Master) cu toate datele lor de identificare fiscal i comercial, cu soldul la începutul i sfâritul primei perioade de raportare (de ex. luna ianuarie 2022)."
Cum procedam in situatia descrisa mai jos pnetru clientii din baza de date ( similar si pentru furnizorii din baza de date ) ?
- in baza de date a contibuabilului nomenclatorul de clienti contine peste 30.000 de clienti distincti - la inceputul lunii ianuarie aveau sold 100 de clienti
18
- la sfarsitul lunii ianuarie ( luna =perioada de raportare ) aveau sold 30 de clineti , altii decat cei 100 ce aveau sold la inceputul lunii inuarie ( perioada de raportare) - in cursul lunii ianuarie (perioada de raportare ) un numar de 77 de clienti , ce nu aveau sold la inceputul perioadei ( diferiti/altii decat cei 100), au avut facturi si eu efectuat plata lor integrala astfel incat au in balanta doar rulaj debit= rulaj credit in luna ianuarie deci nu au nici sold initial si nici sold final la sfarsitul lunii ianuarie ( perioada de raportare).
Ce inseamna ca delaram TOTI clientii si furnizorii ?
varinata A: doar cei 100 ( cu sold la inceputul lunii) + 30 ( cei cu sold la sfarsitul lunii) =130 clienti
varinata B : doar cei 100 ( cu sold la inceputul lunii) + 30 ( cei cu sold la sfarsitul lunii) + 77 ( cei cu rulaj in luna si fara sold initial si fara sold final) = 207 clienti
Cred ca de fapt se doreste varianta B ? caz in care textul ar trebui sa devina in ghid ( e doar o sugestie pentru a corela nomenclatorul de clienti/furnizori cu facturile si incasarile/platile realizate in perioada de raportare, din sectiunile 4.1,4.2 si 4,.3):
"Informaiile despre PARTENERI se raporteaz sub forma Catalogului de Parteneri (clieni, furnizori i proprietari ai activelor) astfel: Prin Declaraia informativ D406 depus vor fi raportai TOI clienii i furnizorii ai fiecrui
contribuabil, folosind structura de date Clients (Clieni) i respectiv cea de Suppliers (Furnizori) din seciunea MASTERFILES (Fisiere Master) cu toate datele lor de identificare fiscal i comercial, cu soldul la începutul, cu rulaj in perioada de raportare (facturi si sau încasri/plti) i cu sold la sfâritul primei perioade de raportare (de ex. luna ianuarie 2022)."
Rspuns 41: Aa cum se menioneaza în ghid, în MasterFile se vor raporta datele pentru TOTI clienii si furnizorii.
Cazul prezentat de dumneavoastra este referitor la un model ce a fost supus analizei in cadrul proiectului si viza “raportarea incremental” si care a fost exclus din specificaiile schemei SAF-T. Drept urmare adugirea pe text efectuata “cu rulaj in perioada de raportare (facturi si sau încasri/plti) i “ nu este conform cu textul aprobat i publicat de ANAF.
Textul corect din Ghid este:
„Informaiile despre PARTENERI se raporteaz sub forma Catalogului de Parteneri (clieni, furnizori i proprietari ai activelor) astfel:
Prin Declaraia informativ D406 depus vor fi raportai TOI clienii i furnizorii ai fiecrui contribuabil, folosind structura de date Clients (Clieni) i respectiv cea de Suppliers (Furnizori) din seciunea MASTERFILES (Fisiere Master) cu toate datele lor de identificare fiscal i comercial, cu soldul la începutul i sfâritul primei perioade de raportare (de ex. luna ianuarie 2022).”
Întrebare:
19
Potrivit Ghidului publicat, seciunea "2.2. Taxonomies" nu se raporteaza (pag 38), insa, atat in schema xsd, cat si in structura SAF-T in format xls, exista trei campuri din cadrul acestei subsectiuni (i.e. TaxonomyReference, TaxonomyCode si Account ID) care apar mandatory.
Rspuns 42: Seciunea 2.2. Taxanomies NU SE RAPORTEAZ. Fiind marcat OPIONAL la nivelul sub-seciunii (2.2) nu se raporteaz nimic deocamdat. Câmpurile marcate ca OBLIGATORII / MANDATORY nu sunt raportate, iar logica de verificare prezentat mai sus asigur c contribuabilul nu are nimic de fcut.
Schema XSD a fost proiectat astfel înc s poat primi în viitor seciuni 2.2. Taxanomies, fr s mai fie necesar modificarea schemei, programelor de validare i a bazei de date ANAF. De aici unele diferene intre schema SAF-T i schema XSD.
Deocamdat seciunea 2.2. Taxonomie nu se raporteaz, aa cum este explicat în Ghidul Contribuabilului.
Întrebare: Exista mai multe sub-sectiuni (e.g. InvoiceDocumentTotals, PaymentDocumentTotals etc.) care sunt optionale, dar cuprind campuri (e.g. GrossTotal etc.) care sunt mandatory.
- Sub-seciunile opionale menionate (Section 5 Source Documents - probail 5.1o InvoiceStrcuture - câmpurile S.I.21 InvoiceSettlement i respectiv S.I.22 InvoiceDocumentTotal) care se raporteaz OPIONAL – conin în SI.66 InvoiceDocumentsTotals câmpurile obligatorii NetTotal i GrossTotal – care sunt MANDATORY / Obligatorii, atunci când e raporteaz informaiile pentru o factur. Dac nu exist facturi emise în perioada de raportare, nu e transmite nimic prin fiierul standard de audit (SAF-T)
- Identic pentru Invoice Document Totals, PaymentDocumentTotals se raporteaz o singur dat, într-un singur modul i doar atunci când exist documente surs de raportat.
Alt exemplu este - TaxType se regsete in schema doar in sub-seciunea TaxTable din seciunea MasterFiles. Atributul TaxType este Mandatory in XSD, aa cum este si in XLS. Se poate verifica in XSD la linia 306, unde se vede ca atributul nu are specificat nici minOccurs, nici maxOccurs, ceea ce înseamn ca fiecare are valoarea implicita "1". adic Mandatory.
20
- În seciunea Masterfiles incluzând elementele de la sub-seciunile 2.3 Customers respectiv 2.4 Suppliers.
- În seciunea SourceDocuments, sub-seciunile 4.1 SalesInvoices, respectiv 4.2 PurchaseInvoices la elementul Invoice unde se raporteaz structura facturii care cuprinde informaii despre clieni, respectiv furnizori (sub-seciunile CustomerInfo respective SupplierInfo).
Seciunile din fiierul XML sunt gândite s fie raportate ca liste separate, într-un fiier cu înregistrri secveniale, iar legtura între aceste categorii de informaii se realizeaz prin identificatorul unic pentru clieni (CustomerID), respectiv furnizori (SupplierID).
Întrebare:
Schema xsd nu corespunde cu structura SAF-T in format xls (e.g. tax type apare in schema xsd opional, dar in structura xls este mandatory, similar si pentru alte campuri: analysis type table, etc.)
Potrivit Ghidului publicat, seciunea "2.2. Taxonomies" nu se raporteaza (pag 38), insa, atat in schema xsd, cat si in structura SAF-T in format xls, exista trei campuri din cadrul acestei subsectiuni (i.e. TaxonomyReference, TaxonomyCode si Account ID) care apar mandatory.
21
Exista mai multe sub-sectiuni (e.g. InvoiceDocumentTotals, PaymentDocumentTotals etc.) care sunt optionale, dar cuprind campuri (e.g. GrossTotal etc.) care sunt mandatory.
Rspuns 44:
Potrivit Ghidului publicat, seciunea "2.2. Taxonomies" nu se raporteaza (pag 38), insa, atat in schema xsd, cat si in structura SAF-T in format xls, exista trei campuri din cadrul acestei subsectiuni (i.e. TaxonomyReference, TaxonomyCode si Account ID) care apar mandatory.
Seciunea 2.2. Taxanomies NU SE RAPORTEAZ. Fiind marcat OPIONAL la nivelul sub-sectiunii (2.2) nu se raporteaz nimic deocamdat. Câmpurile marcate ca OBLIGATORII / MANDATORY nu sunt raportate, iar logica de verificare prezentat mai sus asigur c contribuabilul nu are nimic de fcut.
Schema XSD a fost proiectat astfel înc s poat primi în viitor seciuni 2.2. Taxanomies, fr s mai fie necesar modificarea schemei, programelor de validare i a bazei de date ANAF. De aici unele diferene intre schema SAF-T i schema XSD.
Întrebare:
As avea o mica neclaritate legata de Raportarea modala si sper ca ma veti ajuta cu un raspuns.
In cazul in care fisierul XML are o dimensiune mai mare decat 500MB, se mentioneaza ca fisierul va putea fi impartit in sub-sectiuni (pag. 28). Totodata, in legatura cu validarea fisierului, sunt precizate urmatoarele:
“Seciunile MASTERFILES, GENERAL LEDGER i SOURCE DOCUMENTS se raporteaz de oricâte ori este nevoie pentru a acoperi coninutul informaional al acestora, respectând criteriul de dimensiune maxim permis a fiierului XML.”
Imi puteti confirma daca in cazul in care o sub-sectiune (de exemplu, GENERAL LEDGER ENTRIES) are peste 500MB, aceasta va putea fi impartita pe perioade mai mici de timp si trimise mai multe fisiere pentru aceeasi sub-sectiune?
Rspuns 45:
Din considerente tehnice o sub - seciune nu poate fi împrit în mai multe extracii i trebuie obligatoriu transmis printr-un singur formular D406.
Limita tehnic de 500 de MB este îns pentru dimensiunea fiierului XML în format compresat – atunci când este ataat formularului electronic D406/D406T, nu pentru dimensiunea fiierului XML care cuprinde o seciune (de ex. GENERAL LEDGER ENTRIES).
Rata de compresie medie pentru fiiere XML ataate formularelor electronice D406/D406T variaz între 1:10 i chiar 1:25, în funcie de coninutul fiierului (înregistrrile contabile).
Dimensiunile maxime pentru fiierele XML pregtite – cu una sau mai multe sub-seciuni sunt de cca. 5 GB (Gigabytes), sau chiar mai mari în funcie de coninutul sub-seciunii extras din sistemul informatic al contribuabilului.
22
Constrângerea tehnic de a transmite obligatoriu o sub-seciune printr-un singur formular D406 este dat de necesitatea de a depune atât declaraiile cât i declaraiile rectificative prin acelai mecanism i cu acelai formular (fr bife suplimentare etc.) este realizat astfel:
- Prima Declaraie informativ D406 depus pentru o lun / trimestru de ctre contribuabil – este considerat declaraia iniial.
- O a doua Declaraie informativ D406 depus pentru o anumit perioad (lun / trimestru) este automat considerat declaraie rectificativ.
Diferena dintre Declaraia informativ D406 i declaraiile rectificative se face prin TIMP – momentul depunerii – prima declaraie depus pentru o anumit perioad (lun / trimestru) este cea iniial, iar orice declaraie urmtoare este o declaraie rectificativ.
Mecanismul permite trimiterea, primirea i procesare de mai multe rectificative pentru fiecare seciune, sau pentru întreaga Declaraie informativ D406.
Întrebare:
1. In ghid apare:
Ne puteti spune o data estimativa cand vor aparea aceste schimbari oficial – cel putin in stare de proiect de lege?
Rspuns 46: Publicarea proiectelor de acte normative privind introducerea obligailor de raportare pentru declaraia informativ D406 fiierul standard de control fiscal (SAF-T) cu respectarea termenelor legale pentru consultarea public, în raport cu data estimat pentru introducerea obligativitii depunerii pentru anumite categorii de contribuabili.
Întrebare:
Taxonomy
23
Daca Taxanomy nu face obiectul raportarii de ce apar unele campuri ca si obligatorii?
Rspuns 47:
Sub-seciunea Taxonomies conine detalii cu privire la taxonomii care se aplic conturilor din Registrul- Jurnal.
Sub-seciunea Taxonomies (Taxonomii) din MasterFiles (Fiierele Master) NU SE RAPORTEAZ prin D406, în România. Aceasta este o msur de simplificare a raportrii pentru contribuabili, în condiiile în care în România categoriile raportate sunt clar specificate.
Standardul SAF-T OECD prevede c aceste câmpuri sunt obligatorii la raportare, atunci când sub- seciunea trebuie raportat.
În cazul specific al sub-seciunii Taxonomies – acest element este opional i prin simplificarea introdus pentru contribuabilii din România – nu se raporteaz. Lipsa acestei subseciuni nu produce erori sau avertismente.
2.2 Taxonomies
Taxonomies Taxonom y GL Optional
24
Întrebare:
La campurile/elementele cu descrieri: Descrierea sa fie in Romana sau Engleza?
Rspuns 48: Descrierile din câmpuile Description (în verde mai jos in tabelul din text) se completeaz cu valorile din Nomenclator în limba ROMÂN pentru descrierea taxei sau cotei de taxare. De exemplu:
2.5 TaxTable
Mand atory
/A x x
/A N /A
TaxT ype pentr u cuta rea în tabel e
SAFcode Type
Vali dare baza t pe TAX _IM P - Imp ozite
N /A
N /A
N /A 1
Filled in according to the codes in the nomencla ture TAX- IMP - Impozite
Completarea acestui câmp se face cu codul asociat conform nomenclatorul ui TAX-IMP - Impozite
x X N /A x x
Descrip tion
Desc riere a TaxT ype
SAFlong textType
TaxCod eDetails
TaxCode Details
/A N /A
TaxType pentru cutarea în tabele SAFcodeType ER
P Mandatory Mandatory
TaxCode pentru cutare în tabele. SAFcodeType ER
P Mandatory Mandatory
P Optional Optional
TaxBase
The base on which the tax is calculated. This can be an amount
Baza pe care se calculeaz impozitul. Aceasta poate fi o sum
Decimal ER P Optional Optional
TaxBaseDescription Description of the value in the TaxBase.
Descrierea valorii TaxBase
TaxExemptionReason Tax exemption or reduction reason or rationale
Motivul sau raionamentul scutirii sau reducerii fiscale
SAFmiddle2textTyp e
TaxDeclarationPeriod
The identification of the declaration/return in which the tax amount is reported to the Revenue body.
Identificarea declaraiei în care suma taxei este raportat organului fiscal.
SAFmiddle1textTyp e
26
Modul în care interpreteaz unii contribuabili schema SAF-T i fiierul XSD este neuniform si facem urmtoarele precizri:
1. Schema SAF-T OECD 2.0 este o descriere tehnic a intrrilor în aplicaia de colectarea i analiz a datelor pentru Declaraia informativ D406 fiierul standard de audit (SAF-T). În schema sunt explicate formatul i semnificaia datelor care formeaz fiierul standard de audit aliniat cu specificaia OECD 2.0. Fiierul standard de audit este pregtit i formatat în XML Extensible Markup Language (XML), care este un meta- limbaj de marcare recomandat de W3C World Wide Web Consortium pentru crearea de alte limbaje de marcare, cum ar fi XHTML, RDF, RSS, MathML, SVG, OWL etc. SAF-T OECD 2.0 este un astfel de limbaj din familia de limbaje XML, proiectat pentru transferului de date financiare, fiscale i contabile între aplicaii, prin intermediul reelelor Internet, care conine propria descriere de structur de date.
2. Pentru a formaliza transmiterea datelor financiare, fiscale i contabile au fost adugate codificri specifice României, aliniate cu actele normative în vigoare (Legea Contabilitii, Codul Fiscal, Codul de Procedur Fiscal, hotrâri de guvern, norme de aplicare i Ordine MF i OP ANAF). Cele mai multe codificri i precizri sunt introduse prin intermediul nomenclatoarelor care completeaz schema SAF-F, iar altele sunt introduse i explicate detaliat la fiecare câmp de date în parte.
3. Ghidul contribuabilului pentru pregtirea i depunerea declaraiei informative D3406 fiierul standard de audit (SAF-T) descrie semnificaia de ansamblu a declaraiei informative, detalii despre fiecare segment, seciune, sub-seciune i structur de date utilizate.
4. Schema XSD pentru SAF-T OECD 2.0 este XML Schema Definition – care specific modul de descriere formal a elementelor într-un document XML Extensible Markup Language (XML), în cazul de fa – descrierea tehnic pentru datele care POT fi transmise prin fiierul standard de audit (SAF-T). Schema XSD este folosit de programatori pentru a crea programe de validare care verifica coninut fiecrui articol sau câmp de date din fiierul standard de audit. Prin verificri se asigura c respect descrierea fiecrui câmp de date, din punct de vedere sintactic i al amplasrii în fiier.
Legtura dintre Schema SAF-T OECD 2.0 i schema XSD este dat de numele seciunilor, subseciunilor i câmpurilor – care sunt pstrate ad litteram în specificaiile pentru pregtirea i depunerea declaraiei informative D406.
Prin schema XSD sunt introduse tehnic regulile prin care se fac validrile fiierelor standard de audit privind:
Validarea numelor de câmpuri (fixe, obligatorii, cf SAF-T OECD 2.0) – adic a marcajelor XML
Validarea structurilor de date (la nivel de câmp) din punct vedere al amplasrii – adic crei seciuni, sub-seciuni sau structuri de date aparin. SAF-T XML folosete imbricarea datelor / câmpurilor în structuri, sub-seciuni i seciuni de date ierarhizate.
27
Pentru fiecare structur, sub-seciune i câmp de date – exist o structur „printe” – o structur ierarhic superioar. Pentru fiecare structur i sub-seciune exist fie structuri „copil”, fie câmpuri elementare („frunze”) în ierarhia datelor. Structurile de date XML se numesc NODURI.
Seciunile, sub-seciunile, structurile i câmpurile pot fi de dou feluri – obligatorii (Mandatory) care raporteaz mereu, în fiecare fiier de audit, în mod obligatoriu. Lipsa lor este o eroare fatal, care conduce la invalidarea fiierului.
Seciunile, sub-seciunile, structurile i câmpurile pot fi Opionale (Optional) care raporteaz DOAR atunci când sunt necesare – acest lucru depinzând de situaia datelor de raportat prin fiierul standard de audit.
Lipsa unor sub-seciuni, structuri sau câmpuri opionale în schem – indic faptul c nu exist date de raportat din acele categorii, într-un fiier de audit anume. În alt fiier – aceste putând fi gsite completate cu datele existente. Logica de validare este c dac printele este Opional, toat structura care aparine acelui nod poate s lipseasc. În schimb, dac seciunea, subseciunea sau structura printe este raportat specific în XML, structurile de date i câmpurile copil care sunt marcate ca OBLIGATORII (Mandatory) trebuie s fie completate în fiierul standard de audit.
Astfel – seciuni care trebuie raportate obligatoriu prin fiierul SAF-T sunt marcate dpdv tehnic ca opionale în schema XSD, pentru a putea fi raportate în module diferite (fiiere XML ataate unor formulare D406 succesive).
Ghidul contribuabilului pentru pregtirea i depunerea declaraiei informative D406 fiierul standard de audit (SAF-T) explic modul de raportare MODAL, prin care contribuabilii cu foarte multe de date de raportat (zeci de milioane de înregistrri) pot depune fiierul standard de audit pe module, cu ajutorul unor formulare D406 încrcate succesiv.
Seciunile obligatorii din fiierul standard de audit sunt depuse o singur dat, într-un singur modul. Schema XSD este pregtit s valideze orice fel de modul – fie el unul cu o declaraie informativ complet, unitar (de obicei cele mai
scurte, cu mai puine date), fie orice modul dintr-o declaraie mai lung, cu mai multe date, transmis prin formulare succesive D406. Asamblarea declaraiei informative transmis modal se face pe serverele ANAF- din toate modulele trimise i este verificat suplimentar pentru completitudine, folosind informaii din schema SAF-T.
28
Întrebare
Conform Ghidului contribuabilului pentru pregatirea si depunerea declaratiei informative D406, contribuabilii persoane juridice române i unitile fr personalitate juridic din Romania ale persoanelor juridice strine care in contabilitatea în partid dubl vor avea i obligaia de a furniza organului fiscal central o declaraie cuprinzând informaii din eviden contabil i fiscala, denumita D406.
Prin prezentul e-mail, dorim sa aducem in discutie si faptul ca persoanele juridice cu sediul in Romania pot avea si uniti fr personalitate juridic/sedii permanente in strainatate, iar acest aspect nu este reglementat in Ghidul mentionat mai sus.
Suntem de parere ca nu exista obligativitatea pentru persoanele juridice cu sediul in Romania de a raporta in declaratia D406 informatiile din eviden contabil i fiscala aferente unitilor fr personalitate juridic/sediilor permanente din strainatate, pentru cel putin urmatoarele motive:
- unitile fr personalitate juridic/sediile permanente din strainatate conduc evidenta contabila si fiscala conform reglementarilor statului in care sunt inregistrate aceste sucursale/sedii permanente; - conform specificatiilor tehnice pentru intocmirea declaratiei 406, contribuabilii vor trebui sa raporteze tratamentul fiscal si contabil conform reglementarilor aplicabile in Romania; - consideram ca nu poate exista o mapare a tratamentului fiscal din punct de vedere TVA si al impozitului asupra veniturilor nerezidentilor aplicat in jurisdictia fiscala in care este inregistrata sucursala/sediul permanent si tratamentul fiscal aplicabil in Romania si prevazut in nomenclatoarele aferente D406; - nu exista identitate de abordare in ceea ce priveste o entitate nerezidenta conform legislatiei fiscale din Romania si o entitate nerezidenta conform legislatiei fiscale din statul in care este inregistrata sucursala/sediul permanent. Astfel, in statul sucursalei/sediului permanent, un furnizor care are sediul in acelasi stat cu sucursala/sediul permanent reprezinta o entitate locala, in timp ce din perspectiva Romaniei, furnizorul rezident in statul sucursalei/sediului permanent este nerezident.
Va rugam sa ne precizati daca intelegerea noastra este corecta.
Rspuns 49:
Avand in vedere prevederile Ordinului MFP 1802/2014 prin care, conform:
Art 3. (2) Activitatea desfurat în strintate de subunitile fr personalitate juridic, care aparin persoanelor juridice cu sediul în România, se include în situaiile financiare ale persoanei juridice române i se raporteaz pe teritoriul României, cu respectarea prevederilor Reglementrilor contabile privind situaiile financiare anuale individuale i situaiile financiare anuale consolidate. (3) În înelesul prezentului ordin, prin subuniti fr personalitate juridic, care aparin persoanelor juridice cu sediul în România, se înelege sucursale, agenii, reprezentane sau alte asemenea uniti fr personalitate juridic, înfiinate potrivit legii.
(5) Din punct de vedere contabil, sediile permanente din România care aparin unor persoane juridice cu sediul în strintate reprezint subuniti fr personalitate juridic ce aparin acestor persoane juridice i
29
au obligaia întocmirii situaiilor financiare anuale i a raportrilor contabile cerute de Legea contabilitii nr. 82/1991, republicat, cu modificrile i completrile ulterioare.
Anexa nr. 1 pct.5 (2) Activitatea desfurat în strintate de subunitile fr personalitate juridic, care aparin persoanelor juridice cu sediul în România, se include în situaiile financiare ale persoanei juridice
române i se raporteaz pe teritoriul României, cu respectarea prevederilor pct. 7 i pct. 317 324 din
prezentele reglementri.
Societatile din Romania au obligatia sa declare activitatea desfasurata in strainatate de subunitatile fara personalitate juridica.
Astfel, in cadrul Seciunii 3 – Înregistrri Contabile / Registrul Jurnal, se vor raporta i tranzaciile desfurate în strinatate de subunitile fr personalitate juridic care aparin persoanelor juridice cu sediul în Romania, conform reglementrilor contabile aplicabile în România. Înregistrrile contabile aferente facturilor de achiziie i de vânzare care nu sunt emise / primite utilizând codul de înregistrare de TVA din Romania trebuie identificate prin menionarea în cadrul structurii Tax Information, câmpul TaxCode, a codurilor de taxa pentru TVA relevante pentru operaiunile care nu se declar în decontul de TVA din România.
Totodata, in cadrul Seciunii 4 – Documente surs, se vor raporta informaiile din facturile de vânzare i facturile de achiziii aferente codului de înregistrare în scopuri de TVA din România al societii care face raportarea SAF-T.
Întrebare Serverul pentru testare va putea fi folosit cu date incomplete sau incorecte, fr a exista sanciuni, doar pentru a verifica funcionalitatea sistemului propriu?
Rspuns 50:
DA. ANAF ofer asisten pentru contribuabili sub forma testrii voluntare pentru pregtirea i depunerea declaraiei informative D406 fiierul standard de control fiscal. Asistena cuprinde:
- Furnizarea de specificaii pentru pregtirea i depunerea declaraiei informative D406 prin Ghidul contribuabilului (pentru detalii consultai capitolul 9 din Ghid)
- Programul VALIDATOR (SoftJ) - Testarea voluntar pe serverele ANAF, prin depunerea formularului D406T – pentru testare se
pot depune declaraii informative de test D406T În programul de testare voluntar – declaraiile de test se transmit folosind formularul D406T. Declaraiile de test transmise cu formularul D406T sunt utilizate strict pentru testarea, verificarea i validarea fiierului în format XML SAF-T 2.0 OECD ataat formularului, fr a fi reinute sau pstrate de ANAF, fr a fi utilizate ulterior în cadrul analizelor de risc / inspeciilor fiscale.
Întrebare
30
Faptul ca raportarea pentru mijloacele fixe se face o dat pe an implic c prima raportare se va face la sfâritul primului an de raportare? Tranzaciile se vor raporta la nivel anual?
Rspuns 51: DA. Pentru clarificare v rugm s revedei cap. 5 Calendarul de depunere a declaraiei informative D406 i figura 1 – unde se menioneaz c prima depunere a declaraiei informative cu seciunea / modul Active se face la nivelul anului financiar aplicat de ctre contribuabilul raportor i se va depune pân la termenul de depunere a situaiilor financiare - de exemplu, declaraia 406 Active aferent anului financiar ianuarie – decembrie 2022 se va depune cel târziu pân la termenul de depunere a situaiilor financiare, respectiv pân la 30 mai 2023, . Mai multe precizri sunt disponibile în cap.5 din Ghid – pagina 9, par. 3.
Depunerea declaraiei informative cu seciunea / modul Active se face la nivelul anului financiar aplicat de ctre contribuabilul raportor,pân la termenul de depunere a situaiilor financiare.
Întrebare
Cum se raporteaz tranzaciile fr client/ furnizor (ex: vânzri în staiile de distribuie carburani)?
Rspuns 52:
Sectiunea General Ledger Entries:
Vanzarile efectuate de comercianti pentru care se emit bonuri fiscale, se vor raporta la nivel centralizat, in baza rapoartelor Z, in sectiunea « General Ledger Entries », cu codurile de taxa pentru TVA asociate fiecrui tip de operatiune. In acest caz, se va utiliza un cod de CustomerID care sa identifice clientii persoane fizice pentru care nu se cunoaste identitatea la momentul emiterii bonurilor fiscale, respectiv 08-000000000000000000 (13 de 0).
Codurile de taxa asociate pentru raportarea in Sectiunea General Ledger Entries sunt urmtoarele:
TaxType - 300 TaxCode dupa cum urmeaza:
310309 - Livrri de bunuri i prestri de servicii taxabile cu cota 19% 310310 - Livrri de bunuri i prestri de servicii taxabile cu cota 9% 310311 - Livrri de bunuri i prestri de servicii taxabile cu cota 5% 310314 - Livrari de bunuri si /sau prestari de servicii scutite cu drept de deducere,
altele decat Exporturile 310326 - Livrri de bunuri i prestri de servicii scutite fr drept de deducere
In cazul in care pentru vanzarile efectuate de comerciati pe baza de bon fiscal, se emit facturi la cererea clientului, la raportarea acestor facturi este relevant codul:
310327 - Livrri de bunuri i prestri servicii pentru care este evideniat suma taxei colectate * (cod nou)
31
* acest cod se foloseste in cazul in care factura emisa pe baza de bon fiscal contine mai multe bunuri si pestari de servicii cu cote de TVA diferite.
Pentru situatiile in care un client persoana fizica solicita factura in baza bonului fiscal, se va utiliza un cod CustomerID care sa identifice clientii persoane fizice pentru care nu se cunoaste identitatea la momentul emiterii facturilor in baza bonurilor fiscale 08-000000000000000000 (13 de 0).
Pentru situatiile in care un client persoana juridica solicita factura in baza bonului fiscal, se va utiliza un cod Customer ID dupa cum urmeaza:
- - Codul unic de identificare/codul unic de inregistrare in scopuri de TVA, conform instructiunilor de la linia S.I.23 din Schema SAF-T,
Sectiunea Source Documents, subsectiunea Sales Invoices:
Bonurile fiscale nu se vor raporta in sub-sectiunea Sales Invoices. Facturile emise pe baza bonurilor fiscale, la cererea clientilor, vor fi raportate TOATE in Sectiunea Source Documents – Sales Invoices. Modalitatea de emitere a acestor facturi se va realiza în conformitate cu prevederile Codului Fiscal i cu modul de operare al fiecrui contribuabil – factur detaliat la nivel de poziie din Bonul fiscal, factur consolidata în funcie de cota de TVA aplicabil sau conform unui model simplificat, « Factura emisa conform bon fiscal nr./data »..
Pentru situatiile in care un client persoana fizica solicita factura in baza bonului fiscal, se va utiliza un cod CustomerID care sa identifice clientii persoane fizice pentru care nu se cunoaste identitatea la momentul emiterii facturilor in baza bonurilor fiscale 08-000000000000000000 (13 de 0).
Pentru situatiile in care un client persoana juridica solicita factura in baza bonului fiscal, se va utiliza un cod Customer ID dupa cum urmeaza:
Codul unic de identificare/codul unic de inregistrare in scopuri de TVA, conform instructiunilor de la linia S.I.23 din Schema SAF-T.
În cazul facturilor simplificate emise pentru cumprri fcute pe baz de bon fiscal, cu mrfuri i servicii taxate cu o singur cot de tax, raportarea facturilor de vânzare se face astfel:
Tax Type - 300 TaxCode dupa cum urmeaza:
310309 - Livrri de bunuri i prestri de servicii taxabile cu cota 19% 310310 - Livrri de bunuri i prestri de servicii taxabile cu cota 9% 310311 - Livrri de bunuri i prestri de servicii taxabile cu cota 5% 310314 - Livrari de bunuri si /sau prestari de servicii scutite cu drept de deducere,
altele decat Exporturile 310326 - Livrri de bunuri i prestri de servicii scutite fr drept de deducere
În cazul facturilor emise pentru cumprri fcute pe baz de bon fiscal, cu bunuri i servicii taxate cu diferite cote de TVA (mai mult de o cot de TVA pe acelai bonul fiscal) raportarea facturilor de vânzare se face în Seciunea 4.SourceDocuments în subseciunea 4.1 SalesInvoices astfel:
SD.SI.1 Number of entries – numr de intrri = 1 .. n (în acest caz particular de factur simplificat se pot acumula mai multe linii dintr-un bon sau mai multe bonuri, fiecare cu mai multe
32
elemente, fiecare cu categoria lui de tax pe valoare adugat), care pentru simplificare se cumuleaz pe aceeai factur
SD.SI.2 Total Debit = Totalul tuturor sumelor debitoare / suma total de pe bon sau sumele de plat aferent tuturor bonurilor de cas, cumulat (in valuta implicit a antetului = RON, se aplic doar la vânzri în România, care se fac doar în moneda naional)
SD.SI.3 Total Credit = 0 – este factur pentru vânzri (nu credit note)
Urmate de elementele: - S.I.1 Invoice No = numrul facturii (emis de vânztor) - S.I.2 CustomerInfo - obligatoriu - S.I.3 SupplierInfo - obligatoriu - S.I.4 AccountID = ID-ul contului analitic pentru astfel de vânzri (contul de client folosit la
inregistrarea facturii)) - obligatoriu. In coditiile in care facturile emise pentru vanzari pe baza de cod fiscal nu se inregistreaza in contabilitate, se va raporta un cont generic 411XXX – unde XXX numr intern alocat de ctre contribuabil
- S.I.8 InvoiceDate = data emiterii facturii – obligatoriu - S.I.9 InvoiceType sa se completeaz cu valoarea / codul 751 Factur - informaii în scopuri
contabile / Invoice information for accounting purposes din Nom_Tipuri_facturi - Nomenclator pentru raportarea tipurilor de facturi (emise i primite). Coduri utilizate pentru completarea câmpului S.I.9. Invoice type din 5.10 InvoiceStructure – un cod special pentru aceasta categorie de facturi.
Câmpul InvoiceType este OPIONAL, dar aici este NECESAR, deci se transmite pentru a indica ce fel de factur este. În absena acestei precizri, tipul facturii este considerat i pus în b.d. 380 = FACTUR INIIAL.
- S.I.13 Self-billing indicator = 0 (adic NULL) – OBLIGATORIU
Urmate de înregistrarea / înregistrrile cu liniile facturii (1..n), astfel:
- S.I.29 InvoiceLine = 1 - obligatoriu - S.I30 AccountID = ID-ul contului analitic pentru astfel de vânzri (contul de venit folosit la
inregistrarea fiecarei linii din factura; in cazul in care facturile emise in baza bonului fiscal nu sunt inregistrate in contabilitate, se va raporta contul generic 707XXX)- obligatoriu, S.I.39 Quantity = 1, se completeaz cu 1 pentru simplitate (este vorba de un grup de linii dintr-un bon / bonuri raportate cumulat)
- S.I.42 UnitPrice = Suma sumelor totale se pune în câmpul de pre unitar pentru întregul lot, este egal cu suma din câmpul SD.SI.2 Total Debit = Totalul tuturor sumelor debitoare / suma sumele de plat de toate bonurile de cas, cumulat (in valuta implicit a antetului = RON, se aplic doar la vânzri în România, care se fac doar în moneda naional)
- S.I.43 TaxPointDate = se completeaz cu data facturii în acest caz (aceeai dat din S.I.8 Invoice Date) pentru data eligibiliti taxei -valoarea implicit care se utilizeaz atunci când nu putem distinge alte date (datele emiterii bonurilor de cas) – este element OBLIGATORIU
- S.I.45 Description = se completeaz liber de ctre Vnztor, de exemplu: „Factur emisa pentru vânzri de bunuri pe baz de bon fiscal” – element OBLIGATORIU
- S.I.46 Invoice Amount = valoarea NET a facturii (fr taxe, fr transport) – element OBLIGATORIU, format din
- S.AM.1 Amount = suma NET a facturii în RON - OBLIGATORIU
33
- S.AM.2 CurencyCode = RON - OBLIGATORIU - S.AM.3 CurrencyAmount = 0 (nu exist sum în valut strin) - OBLIGATORIU
- S.I.47 DebitCreditIndicator = D (debit) – OBLIGATORIU - S.I.49 TaxInformation – element OBLIGATORIU, cu cardinalitate 1..* (cardinalitatea multipl
permite în viitor declararea mai multor tipuri de taxe aplicabile la nivel de factura, separat, dar la acest moment se declara informatii doar despre TVA, iar aici se declar CUMULAT, deci un singur set de câmpuri de taxe) format din
S.TI.1 TaxType = 300 pentru TVA S.TI.2 TaxCode = 310327 - Livrri de bunuri i prestri servicii pentru care
este evideniat suma taxei colectate S.TI.6 TaxAmount = valoarea CUMULAT a TVA pe toate categoriile / cotele
aplicabile, adunat – OBLIGATORIU, astfel S.AM.1 Amount = SUMA TAXEI COLECTTE (suma cumulat de TVA,
în RON – OBLIGATORIU S.AM.2 CurencyCode = RON – OBLIGATORIU S.AM.2. CurrencyAmount = 0 – OBLIGATORIU
SD.SI.2 Total Debit = Totalul tuturor sumelor debitoare = S.I.46 InvoiceAmount / S.AM.1 Amount + S.TI.6 TaxAmount/S.AM.1 Amount (total brut factur).
Acest tip de raportare implic asocierea unui cod de taxa pentru TVA care va fi folosit pentru raportarea facturilor emise în baza bonurilor fiscale în seciunea Source Documents – Sales Invoices, dup cum urmeaz: Tax Type – 300 Tax Code:
o 310327 - Livrri de bunuri i prestri servicii pentru care este evideniat suma taxei colectate - cod ce va fi utilizat dedicat pentru acest tip de factura
Sectiunea Source Documents, subsectiunea Payments:
Încasrile aferente vânzrilor pentru care se emit bonuri fiscale se vor raporta cumulat, la nivel de zi, în seciunea Source Documents, subseciunea Payments.
Aceast abordare acoper situaiile urmtoare: - Toate plile în numerar - Toate plile cu card - Toate plile cu bonuri valorice / alte mecanisme
Toate plile combinate – card + numerar + bon valoric, etc. (inclusiv cazurile plilor cu bonuri de mas la comerciantii din segmentul alimentar, etc.)
Mecanismul se aplic i bonurilor fiscale pe care s-a înscris la cererea cumprtorului codul de inregistrare in scopuri de TVA – în sensul c nu se raporteaz la vânztor în mod detaliat i separat de alte bonuri fiscale sau încasri.
In acest caz, se va utiliza un cod de CustomerID care sa identifice clientii persoane fizice pentru care nu se cunoaste identitatea acestora la momentul emiterii bonurilor fiscale, respectiv 08- 000000000000000000 (13 de 0).
34
Întrebare
Pentru vânzrile în staiile de distribuie carburani trebuie raportate pentru fiecare client atât vânzrile pentru care clientul a solicitat factura, cât i cele pentru care a solicitat codul fiscal pe bonul fiscal, sau numai cele pentru care a fost solicitat factur?
Rspuns 53: În seciunea General Ledger Entries se vor raporta toate tranzaciile, aa cum sunt înregistrate în contabilitate (e.g. pe baza raportului Z, inclusiv facturile simplificate emise pe baza bonului fiscal). În seciunea Source Documents, subseciunea Sales Invoices, se vor raporta doar facturile de vânzare (excluzând bonurile fiscale care au înscris codul fiscal al clientului).
Întrebare Cum se raporteaz facturile emise în perioada curent, la solicitarea clienilor, pentru bonurile fiscale aferente achiziiilor din staiile de distribuie efectuate în perioada curent sau în perioade anterioare lunii de raportare?
Rspuns 54: În seciunea General Ledger Entries se vor raporta toate tranzaciile, aa cum sunt înregistrate în contabilitate (e.g. pe baza raportului Z, inclusiv facturile simplificate emise pe baza bonului fiscal).
În seciunea Source Documents, subseciunea Sales Invoices, se vor raporta facturile de vânzare emise în baza bonului fiscal, la solicitarea clientului.
Întrebare
În contextul în care avem nomenclatoare de coduri de taxa stabilite doar pentru TVA i WHT, în Ghidul contribuabilului, la seciunea 12 am regsit urmtoarea meniune: „La liniile din seciunea GeneralLedgerEntries care nu reprezint înregistrri relevante pentru TVA sau pentru impozite cu reinere la surs se va raporta codul de tax ,,000000", împreuna cu categoria de tax corespunztoare (cod de cifre zecimale din TAX-IMP_Impozite)." Nu înelegem, în aceast faz a proiectului, care este relevana completrii categoriei de taxe corespunztoare pentru celelalte înregistrri din registrul jurnal care nu se refer la TVA sau la impozite cu reinere la surs.
Rspuns 55:
Pentru TVA:
TaxType TVA asa cum a fost definit in nomenclatorul Tax_Imp i codurile de taxa (TaxCode) aferente corespunztor înregistrrilor contabile cu impact pentru înregistrarea in evidentele contabile a TVA, asa cum au fost ele definite in Schema:
35
Pentru WHT:
TaxType WHT asa cum a fost definit in nomenclatorul Tax_Imp i codurile de taxa (TaxCode) aferente corespunztor înregistrrilor contabile de constituire What impozitelor retinute la sursa, asa cum au fost ele definite in Schema - WHT – nomenclator
Pentru alte taxe si impozite:
In cazul celorlalte tipuri de taxe si impozite, pentru raportarea SAF-T, contribuabili pot avea 2 optiuni, fiecare dintre acestia putand decide cum le este favorabil sa declare, in functie de rationamente de business, tehnice sau alte considerente
o Optiunea 1: Pentru TaxType se va selecta tipul de impozit asa cum a fost definit in nomenclatorul Tax_Imp (altul decat 000 – Taxe) si TaxCode - 000000 (ase de zero) cu care se completeaz acest câmp atunci când TaxType este diferit de TVA sau WHT
o Optiunea 2: Pentru TaxType se va selecta tipul de impozit GENERIC asa cum a fost definit in nomenclatorul Tax_Imp, 000 – Taxe (cod nou introdus) si TaxCode - 000000 (ase de zero) cu care se completeaz acest câmp atunci când TaxType este diferit de TVA sau WHT
Prin aceasta abordare se rspunde solicitrii venite din partea unor contribuabili de a simplifica raportarea, dar nici nu se îngrdete posibilitatea de raportare integral, defalcat pe toate tipurile de taxe, în cazul în care contribuabilii doresc acest lucru. Recomandm utilizarea opiunii 2. Aceste reguli sunt aplicabile urmtoarelor seciuni: Seciunea General Ledger Entries, sau Sectiunea Source Documents, subseciunea Payments.
Pentru inregistrarile contabile si platile care nu sunt relevante pentru niciun fel de impozite si taxe, se va raporta Tax Type 000 si TaxCode 000000.
Informaii suplimentare pentru zona tehnic
Codificarea taxelor i impozitelor folosind categoriile din TAX-IMP-Impozite (care cuprinde toate categoriile de taxe i impozite, grupate pe categorii de venituri la buget) i codificarea suplimentar cu categorii de detaliu pentru TVA i WHT este construit pentru a permite transmiterea informaiilor relevante despre taxe i impozite în toate cazurile de utilizare din schema SAF-T:
- Pentru evidenierea taxelor i impozitelor datorate pe documentele surs precum facturile emise ctre clieni i primite de la furnizori (Customer Invoice i Supplier Invoices)
- Pentru explicitarea sumelor pltite pentru taxe i impozite (în Payments) - Pentru explicitarea obligaiilor fiscale transmise prin Tax Table din seciunea Master File
.a.
Principiul de codificare a categoriilor de taxe i impozite cuprinde raportarea cu trei nivele de detaliu:
- Nivel 0 (rdcin) - TAX-IMP - Bugete - NOMENCLATOR CATEGORII DE BUGETE, este prezent în schema SAF-T cu scop informativ pentru a clarifica informaiile din cadrul nomenclatorului TAX-IMP - Impozite
36
- Nivel 1 - categorie principal TaxType- NOMENCLATOR ANAF PENTRU IMPOZITE I TAXE (tabela TAX-IMP-Impozite din Schema SAF-T pentru România), "Nomenclatorul de coduri pentru impozitele i taxele la bugetul statului”. Nomenclatorul conine codurile pentru completarea câmpului TaxType din 5.15 TaxInformationStructure. Este un cod numeric format din 3 cifre zecimale. În raportarea SAF-T se vor selecta taxele pentru care sunt definite coduri de tax (TaxCode) în acest sens.
Tabela cu categoriile principale – Tax-IMP-Impozite cuprinde TOATE categoriile de taxe i impozite care se pot constitui în obligaii fiscale pentru contribuabili. Acest nomenclator este unul general al ANAF – valabil pentru toate declaraiile i formulare fiscale (obligatorii / vectorizate sau informative).
- Nivel 2 - categorie de detaliu Tax-Code – create pentru TVA i WHT
Pentru anumite categorii (cele referitoare la TVA i cele referitoare la WHT) s-au definit pentru moment subcategorii mai detaliate care trebuie raportate prin fiierul standard de control fiscal SAF-T, raportabile ctre ANAF. Aceste categorii de detaliu au fost stabilite prin nomenclatoarele de TVA i WHT.
- Codurile de nivel 0 – NU SUNT UTILIZATE în declaraia informativ D406 fiierul standard de control fiscal. Sunt incluse în Schema SAF-T pentru România pentru a clarifica modul de clasificare.
- Codurile de nivel 1 – SUNT UTILIZATE în declaraia informativ D406 fiierul standard de control fiscal, la Fiier Master (Master File), Facturi de Vânzare (Sales Invoices), Facturi de Aprovizionare (Purchase Invoices), Registrul Jurnal (GL General Ledger), Produse în stoc (Products) i la Pli (Payments)
- Codurile de nivel 2 – SUNT UTILIZATE în declaraia informativ D406 fiierul standard de control fiscal – pentru detalierea categoriilor de TVA (cod de nivel 1 – 300), i pentru WHT taxe i Impozite cu reinere la surs (cod de nivel 1 – din grupele 150, 600…, .a.).
Codurile de nivel 1 – altele decât cele pentru care avem detaliate coduri de nivel 2 – se raporteaz OBLIGATORIU cu TaxType = Cod Categorie Impozit – din tabela TAX-IMP-Impozite I cu TaxCode = 000000.
Codurile de nivel 1 – pentru care avem detaliere cu coduri de nivel 2 – se raporteaz OBLIGATORIU cu
TaxType = Cod Categorie Impozit – din tabela TAX-IMP-Impozite I cu
TaxCode = din nomenclatorul detaliat de TVA i WHT – vezi exemplu de raportare cu corelaia codurilor din WHT - Nomeclator
ÎÎntrebare Considerm necesare clarificri suplimentare i la obiect cu privire la elementele marcate ca "Opionale" în cadrul fiierului Excel, care sunt parte component a unor seciuni i subseciuni marcate ca obligatorii, dar care, în fapt, se constat c trebuie declarate de care contribuabil. În acest fel, considerm c ar fi facilitate raportarea i ar fi diminuare situaiile de erori de raportare.
Rspuns 56: Elementele marcate ca opionale pot fi raportate în funcie de opiunea i aplicabilitatea contribuabilului raportor. Dac o sub-seciune este opional, elementele din acea sub-sectiune devin obligatorii în cazul în