„Plată în avans” de câțiva copeici într-un bon PCM: cum identificați cauza rotunjirii

„Plată în avans” de câțiva copeici într-un bon PCM: cum identificați cauza rotunjirii și DocumentValidationError

În vânzările pe bază de facturi, clientul poate achita un avans, poate plăti comanda în mai multe tranșe sau poate efectua plata finală la primirea mărfii. PCM trebuie să reflecte fiecare etapă a plății și să asocieze bonul final cu plata în avans fiscalizată anterior. Antreprenorii îi întreabă pe specialiști de ce în bon apare rândul „Plată în avans” cu 0,01–0,59 UAH, deși nu a existat o nouă plată în avans, de ce Serviciul Fiscal de Stat respinge documentul cu DocumentValidationError, dacă rotunjirea numerarului a influențat situația, cum a fost distribuită plata între două PFA și ce document concret trebuie verificat. Răspunsul depinde de etapa la care a apărut diferența: în factura inițială, bonul fiscal anterior, documentul curent de plată, setările de rotunjire sau distribuirea vânzării între întreprinderi.

Noțiuni de bază și situația actuală

Plata în avans este suma achitată de client înainte de predarea integrală a mărfii sau de finalizarea plății. În Torgsoft, aceasta poate fi înregistrată simultan:

• în documentul de comandă sau în factura de vânzare;

• în documentul financiar de plată;

• în bonul fiscal PCM;

• în detaliile plății ulterioare sau ale decontării finale.

Plata în avans fiscalizată nu este doar o înregistrare a datoriei sau a mișcării banilor în program, ci o operațiune de plată al cărei bon a fost înregistrat pe serverul fiscal al Serviciului Fiscal de Stat.

Plata ulterioară este următoarea parte a plății pentru aceeași comandă. Decontarea finală închide soldul rămas aferent documentului, ținând cont de plățile primite anterior.

DocumentValidationError sau codul 9 în răspunsul PCM este o eroare generală de validare a documentului. Important nu este doar codul, ci întregul text care urmează după acesta. De exemplu, serverul poate indica faptul că totalul pozițiilor de marfă nu corespunde totalului documentului sau sumei totale pe metode de plată. Codul în sine nu indică o anumită setare Torgsoft.

Un rând „Plată în avans” de câțiva copeici nu înseamnă întotdeauna că vânzătorul a încasat bani suplimentari. Deseori este un rest calculat pe care programul l-a obținut comparând:

1. componența și sumele mărfurilor din factura curentă;

2. plata în avans deja înregistrată;

3. plata curentă;

4. rotunjirea;

5. distribuirea plății între PFA sau persoane juridice.

În diferite versiuni Torgsoft au fost incluse remedieri pentru anumite scenarii cu codul 9: reduceri fracționare, plăți parțiale, rotunjirea numerarului, combinații de mărfuri fiscale și nefiscale, bonusuri, facturi în valută și distribuirea vânzărilor între întreprinderi. De aceea, diagnosticarea corectă începe cu verificarea versiunii actuale a programului, însă actualizarea în sine nu modifică un bon deja înregistrat și nu restabilește o legătură întreruptă între documentele vechi.

Ce egalitate trebuie respectată într-un bon fiscal

Într-o formă simplificată, PCM verifică dacă trei părți ale documentului sunt coerente între ele: suma pozițiilor fiscale după reduceri și rotunjire = suma decontării curente = suma totală pe metode de plată.

În cazul plății în avans, verificarea este mai complexă, deoarece bonul curent trebuie să țină cont corect și de sumele fiscalizate anterior, precum și de soldul restant. Programul poate utiliza simultan următoarele valori:

• „Sumă” — suma calculată a documentului înainte de rotunjirea numerarului;

• „De plată” — suma pe care clientul trebuie să o achite efectiv după aplicarea regulii de rotunjire;

• plățile anterioare;

• plata curentă;

• datoria;

• sumele bonurilor individuale, dacă vânzarea este împărțită între întreprinderi.

Dacă într-o parte a algoritmului s-au utilizat 999,97 UAH, iar în alta suma rotunjită de 1.000,00 UAH, diferența de 0,03 UAH devine importantă pentru validare. Serviciul Fiscal de Stat nu admite o „toleranță de câțiva copeici”: totalurile de control trebuie să coincidă exact.

De unde apar unul, câțiva sau zeci de copeici

 1. Distribuirea proporțională a unei plăți parțiale între mărfuri

Când clientul achită doar o parte din sumă, Torgsoft o distribuie între mărfuri proporțional cu valoarea acestora. Înainte de rotunjire, rezultatul conține adesea mai mult de două zecimale.

De exemplu, o comandă conține mărfuri în valoare de 199,99 UAH și 100,01 UAH, în total 300,00 UAH. Plata în avans este de 100,00 UAH. Cotele matematice sunt de aproximativ 66,6633 UAH și 33,3367 UAH. În bon, acestea trebuie să devină 66,66 UAH și 33,34 UAH, astfel încât totalul să rămână 100,00 UAH.

Dacă adăugăm o cantitate fracționară, o reducere cu procent fracționar sau împărțirea în mai multe bonuri, ultimul copeic trebuie atribuit în mod intenționat uneia dintre poziții. Dacă diferite etape de calcul rotunjesc cotele în mod diferit, apare un rest de 0,01 UAH.

2. Diferența dintre suma documentului și suma în numerar „De plată”

În Torgsoft există mecanisme separate pentru:

• rotunjirea sumei totale a bonului;

• rotunjirea numai a plăților în numerar pentru Ucraina;

• aplicarea rotunjirii în modul de vânzare pe bază de facturi.

Rotunjirea generală a sumei bonului afectează întregul document și are prioritate față de rotunjirea separată a prețurilor pe tipuri de mărfuri. Rotunjirea specială a numerarului trebuie să se aplice părții plătite în numerar, nu plăților cu cardul sau altor plăți fără numerar.

Începând cu 1 octombrie 2025, Banca Națională retrage treptat din circulația numerarului monedele de 10 copeici. Acestea rămân mijloc legal de plată, însă, dacă astfel de monede lipsesc în casierie, suma totală a plății în numerar se rotunjește la 50 de copeici: 1–24 copeici — la 00, 25–49 copeici — la 50, 51–74 copeici — la 50, 75–99 copeici — la următoarea grivnă. Plățile fără numerar nu se rotunjesc. Regulile sunt explicate de Banca Națională a Ucrainei.

Scenariu practic: suma facturii este de 249,97 UAH. La efectuarea unei plăți în avans în numerar, casieria încasează 250,00 UAH după rotunjire. Dacă, la decontarea finală, din suma inițială a documentului se scad exact 250,00 UAH, iar blocul de mărfuri sau datorie este calculat pornind de la 249,97 UAH, apare o diferență de 0,03 UAH. O remediere istorică a unei astfel de situații în Torgsoft este descrisă în modificarea nr. 201060: blocul de plată, plată în avans și datorie trebuie să țină cont de valoarea „Sumă”, nu doar de valoarea „De plată”. Detaliile sunt prezentate în descrierea versiunii 2022.4.7.

3. Modificarea facturii după fiscalizarea plății în avans

Acesta este unul dintre cele mai importante scenarii. Bonul inițial de plată în avans a înregistrat deja la Serviciul Fiscal de Stat anumite mărfuri, cantități, prețuri, reduceri și suma. Dacă ulterior factura este modificată prin:

• modificarea prețului;

• adăugarea sau eliminarea unui produs;

• modificarea cantității;

• aplicarea unei alte reduceri;

• modificarea statutului fiscal al unui produs;

• redistribuirea mărfurilor între întreprinderi,

decontarea finală se bazează pe noua stare a documentului, în timp ce operațiunea fiscală anterioară rămâne în starea inițială.

De exemplu, după plata în avans, vânzătorul a majorat prețul unei poziții cu 1 UAH. La următoarea distribuire proporțională, această grivnă poate modifica cotele mai multor produse, iar rezultatul poate fi nu exact 1 UAH, ci un rest tehnic „Plată în avans” de 0,01 UAH sau 0,59 UAH. Aceste cauze sunt descrise în ghidul Torgsoft privind bonurile de plată în avans.

Procedura corectă pentru modificarea unei comenzi după o plată în avans fiscală este:

1. asigurați-vă că bonul inițial este într-adevăr înregistrat la Serviciul Fiscal de Stat;

2. efectuați restituirea fiscală a plății în avans prin operațiunea standard;

3. modificați componența, cantitatea, prețul sau reducerea în document;

4. încasați din nou plata;

5. generați un nou bon de plată în avans sau un bon de decontare finală.

Nu compensați restul cu un produs sau serviciu arbitrar în valoare de 0,01 UAH: aceasta ascunde cauza, dar modifică structura operațiunii de plată.

4. Împărțirea unei vânzări între mai multe PFA

Setarea „Asociați tipul de marfă cu o întreprindere și împărțiți vânzările în funcție de acesta” permite vânzarea mărfurilor într-un singur coș, dar cu crearea unor vânzări și bonuri fiscale separate pentru întreprinderile cu care sunt asociate tipurile corespunzătoare de mărfuri. Plata totală a clientului este distribuită între vânzări proporțional cu sumele acestora.

De exemplu, clientul achită 1.000,00 UAH cu cardul, iar mărfurile aparțin la două PFA într-un raport care generează cote de 333,335 UAH și 666,665 UAH. În documentul de plată nu poate fi înregistrată o jumătate de copeică. Un bon trebuie să primească 333,33 UAH, iar celălalt 666,67 UAH; în caz contrar, totalul lor nu va fi egal cu 1.000,00 UAH.

În algoritmul actual Torgsoft, restul rezultat din rotunjire este atribuit unuia dintre bonuri, astfel încât suma totală să coincidă. Pentru o vânzare împărțită între mai mult de două întreprinderi, părțile anterioare sunt rotunjite în jos până la copeică, iar restul este atribuit ultimei. Rotunjirea numerarului la 10 sau 50 de copeici este, de asemenea, luată în considerare separat. Această modificare privind distribuirea între întreprinderi este descrisă în versiunea 2026.0.3, sarcina nr. 205082.

Totuși, o sumă totală corectă nu înseamnă că configurarea este completă. Pentru fiecare întreprindere verificați:

• dacă tipul de marfă este asociat cu PFA sau persoana juridică potrivită;

• PCM corespunzător și numărul său fiscal valabil;

• metoda de plată;

• contul bancar și acquiringul, dacă se utilizează un card;

• totalul pozițiilor de marfă și suma plății din bonul individual al întreprinderii respective.

Fiecare bon este validat separat. Serverul nu compensează un deficit de 0,01 UAH în bonul unui PFA cu un surplus de 0,01 UAH în bonul altui PFA.

5. Mărfuri fiscale și nefiscale într-un singur document

Dacă o factură conține atât mărfuri care trebuie incluse în bonul fiscal, cât și poziții care nu sunt fiscalizate, documentul de plată poate acoperi întreaga factură, în timp ce bonul PCM acoperă doar partea fiscală. În cazul unei plăți parțiale, programul trebuie să determine ce parte din plată revine fiecărui grup.

Cotele fracționare și rotunjirea în astfel de combinații au provocat anterior cazuri individuale de cod 9. Remedierile sunt descrise, în special, în versiunea 2022.0.57 și în alte actualizări. Dacă scenariul se reproduce în versiunea actuală, verificați statutul fiscal al fiecărei poziții și nu echivalați suma întregii facturi cu suma bonului fiscal fără calcul.

6. Distribuirea neuniformă a plăților cu bonusuri

Atunci când un produs este achitat integral cu bonusuri, iar restul cu o altă metodă de plată, distribuirea proporțională și rotunjirea pot genera temporar pentru un produs o cotă de bonusuri cu o copeică mai mare decât valoarea sa. Acest scenariu, inclusiv în bonurile de restituire, a fost remediat în actualizarea 2022.0.59.

La verificare, comparați nu doar suma totală a bonusurilor, ci și distribuirea acestora pentru fiecare poziție de marfă.

7. Document în valută și decontare fiscală în grivne

Operațiunile fiscale în Ucraina se efectuează în grivne. Dacă factura sau decontarea este ținută într-o valută străină, cursuri de schimb diferite sau momente diferite ale conversiei pot genera un echivalent în grivne cu o diferență de câțiva copeici. Istoricul actualizărilor Torgsoft descrie separat codul 9 pentru plata parțială fără numerar a unei facturi în valută, atunci când suma plății nu era egală cu suma facturii în moneda națională.

Pentru PCM, verificați valorile în grivne transmise în bon. O sumă în valută nu trebuie fiscalizată ca sumă în grivne fără conversia corectă.

8. Ștergerea sau anularea unuia dintre documentele asociate

O înregistrare contabilă în Torgsoft și un bon înregistrat la Serviciul Fiscal de Stat au statute diferite. Dacă o plată anterioară este ștearsă, un document local este anulat sau baza de date este restaurată dintr-o copie de rezervă veche, serverul fiscal nu va anula automat un bon deja acceptat. La următoarea decontare, programul poate vedea un alt istoric al plăților decât cel deținut de Serviciul Fiscal de Stat.

De aceea, nu ștergeți plata, bonul, pachetul offline sau legătura dintre documente pentru a „aduce copeicile la zero”. Mai întâi determinați statutul fiscal al fiecărui bon.

Verificare pas cu pas: cum identificați cauza concretă

Salvați textul complet al răspunsului și faceți o captură de ecran. Deschideți analiza PCM și stabiliți dacă bonul:

• a fost respins de server;

• a fost înregistrat, dar răspunsul nu a ajuns în program;

• a rămas în coadă sau în pachetul offline;

• a fost anulat sau restituit.

Generarea repetată fără această verificare poate crea o operațiune de plată duplicată.

DocumentValidationError este o categorie, nu un diagnostic. Notați din mesaj următoarele informații:

• totalul pozițiilor de marfă;

• suma documentului sau suma plății curente;

• totalul pe metode de plată;

• mărimea și semnul diferenței;

• denumirea câmpului sau blocului pe care serverul îl consideră neconcordant.

Dacă textul conține două sume, scădeți suma mai mică din cea mai mare. Diferența rezultată de 0,01, 0,03, 0,50 sau 0,59 UAH vă va ajuta să corelați situația cu un anumit tip de rotunjire.

Notați exact ce se genera:

• prima plată în avans;

• o plată parțială ulterioară;

• decontarea finală;

• restituirea plății în avans;

• anularea;

• o vânzare obișnuită;

• o vânzare împărțită între întreprinderi.

Dacă rândul „Plată în avans” a apărut doar în bonul final, verificați mai întâi dacă plata în avans inițială corespunde stării actuale a facturii.

Pentru o singură comandă, deschideți și comparați:

1. factura sau comanda;

2. factura de vânzare;

3. documentul financiar al primei plăți;

4. primul bon fiscal de plată în avans;

5. plățile și bonurile ulterioare;

6. restituirile sau anulările, dacă există;

7. bonul curent care nu a trecut validarea.

Trebuie să determinați nu doar sumele curente, ci și succesiunea evenimentelor.

Comparați bonul inițial cu factura curentă după următoarele câmpuri:

• produsul și denumirea sa fiscală;

• cantitatea;

• prețul;

• reducerea;

• cota și grupa fiscală;

• statutul fiscal;

• tipul de marfă și întreprinderea asociată;

• valuta și echivalentul în grivne.

Chiar dacă suma totală s-a modificat cu o grivnă întreagă, distribuirea proporțională între poziții poate genera un rest de câțiva copeici.

Deschideți Setări → Parametri → Bon și verificați:

• „Rotunjiți suma bonului”;

• „Rotunjiți plățile în numerar (numai pentru Ucraina)”;

• pasul de rotunjire — 10 sau 50 de copeici;

• „Utilizați rotunjirea la vânzarea pe bază de facturi”.

Stabiliți ce setări erau active la data primei plăți în avans, nu doar care sunt setate acum. Nu le modificați în baza de date de lucru în timpul unei ture deschise fără să înțelegeți impactul asupra celorlalte case de marcat.

Verificați separat metoda de plată. Dacă întreaga plată a fost efectuată cu cardul, rotunjirea specială a numerarului nu trebuie aplicată. În cazul unei plăți mixte, se rotunjește numai partea în numerar.

Setarea „Tipăriți bonul pentru factură pe PCM” are următoarele moduri:

• „Pentru suma plății”;

• „Pentru suma plății și a datoriei”;

• „Întrebați utilizatorul”.

Aceste moduri influențează suma pe care programul trebuie să o fiscalizeze în timpul unei plăți în avans sau al unei decontări parțiale. Logica acestora este descrisă în actualizarea 2022.0.48. Dacă vânzătorul se aștepta la un bon doar pentru plata efectivă, dar modul selectat a inclus și datoria, căutarea diferenței trebuie începută de la neconcordanța tipului de bon, nu de la ajustarea manuală a sumei.

Creați un tabel simplu:

Verificați două egalități:

• în fiecare rând, suma mărfurilor este egală cu suma plății din bonul corespunzător;

• suma tuturor bonurilor individuale este egală cu plata clientului.

Dacă prima egalitate nu este respectată, cauza se află în bonul individual sau în asocierea cu întreprinderea. Dacă prima egalitate este respectată, dar a doua nu, verificați algoritmul de distribuire a restului și versiunea Torgsoft.

Nu vă bazați pe o singură „versiune minimă”. Remedierile s-au acumulat în mai multe versiuni:

• 2022.0.49 — plăți parțiale, reduceri fracționare, rotunjirea numerarului, plăți în exces și restituiri ale plăților în avans;

• 2022.0.57 — anumite diferențe legate de mărfurile fiscale și nefiscale;

• 2022.0.59 — facturi în valută și distribuirea neuniformă a plăților cu bonusuri;

• 2026.0.3 — distribuirea sumei rotunjite între întreprinderi.

Descrierile scenariilor individuale sunt disponibile în actualizarea 2022.0.49, 2022.0.59 și 2026.0.3.

Înainte de actualizare, creați o copie de rezervă a bazei de date actuale. Dacă diferența privește un document vechi, este mai sigur să reproduceți problema pe o copie a bazei de date împreună cu un specialist tehnic.

Ce trebuie făcut după identificarea cauzei

Ce nu trebuie făcut

• Nu adăugați un serviciu arbitrar „Rotunjire” sau un produs de 0,01 UAH doar pentru a echilibra bonul.

• Nu modificați prețul produsului cu câțiva copeici după fiscalizarea plății în avans.

• Nu ștergeți un bon local, o plată sau un pachet offline fără să verificați statutul documentului la Serviciul Fiscal de Stat.

• Nu înlocuiți decontarea finală cu o vânzare obișnuită: aceasta nu va avea legătura corectă cu plata în avans.

• Nu schimbați PCM, PFA sau metoda de plată după încasarea plății fără să verificați întregul lanț.

• Nu dezactivați rotunjirea simultan la toate casele de marcat până când nu ați stabilit ce regulă concretă a provocat diferența.

• Nu modificați manual tabelele fiscale din baza de date.

Cum identificați rapid sursa după simptome

Întrebări frecvente

Nu neapărat. Poate fi un rest tehnic rezultat din distribuirea proporțională sau din compararea sumei fiscale anterioare cu documentul curent. Datoria clientului se verifică în factura și documentele financiare, iar originea rândului se stabilește din lanțul bonurilor fiscale.

Serverul fiscal verifică exact concordanța aritmetică a detaliilor bonului. O diferență de o copeică înseamnă că totalurile pozițiilor, suma totală sau metodele de plată nu coincid.

Nu. DocumentValidationError acoperă diferite erori structurale și de verificare a relațiilor dintre valori. Trebuie citit întregul text al răspunsului. Logica generală a codului este explicată în ghidul Torgsoft.

În această etapă, programul corelează componența actuală a facturii, toate plățile anterioare și soldul rămas. Dacă documentul a fost modificat după primul bon sau dacă în etape diferite s-au aplicat reguli diferite de rotunjire, diferența apare la final.

Actualizarea corectează algoritmul pentru calculele ulterioare, dar nu rescrie un bon deja înregistrat la Serviciul Fiscal de Stat. Pentru un document vechi, trebuie în continuare să determinați statutul acestuia și să procesați corect restituirea sau să finalizați decontarea.

Nu. Este un element calculat al bonului. Ștergerea manuală nu elimină diferența dintre sumele mărfurilor și plată și poate crea o altă neconcordanță.

Nu. Regulile de rotunjire a numerarului se aplică plăților în numerar. În cazul plăților mixte, partea în numerar și partea fără numerar trebuie verificate separat.

Pentru client, operațiunea poate începe cu un singur coș și o singură sumă totală. Torgsoft o împarte în vânzări și bonuri separate. Fiecare PFA trebuie să aibă propriul bon corect, propriul PCM și partea corespunzătoare din plată; suma părților individuale trebuie să fie egală cu plata clientului.

Doar după ce confirmați că încercarea anterioară nu a fost înregistrată. Mai întâi verificați analiza PCM și statutul documentului pe serverul fiscal.

Ce trebuie pregătit pentru suportul tehnic

Pentru ca specialistul să poată identifica sursa diferenței, furnizați:

• o captură de ecran completă cu codul și textul răspunsului;

• numărul versiunii Torgsoft;

• numărul și data facturii, comenzii, facturii de vânzare și vânzării;

• numărul primului bon fiscal de plată în avans;

• suma primei plăți, a plăților ulterioare și a plății curente;

• valorile „Sumă”, „De plată”, plata anterioară și datoria;

• metodele de plată și sumele acestora;

• lista PFA, PCM și părțile vânzării, dacă vânzarea este împărțită;

• informații despre modificarea produsului, cantității, prețului, reducerii sau tipului de marfă după plata în avans;

• capturi de ecran ale setărilor de rotunjire;

• statutul tuturor bonurilor asociate în analiza PCM.

Nu trimiteți fișierul cheii dvs. personale de semnătură electronică calificată și nici parola acesteia.

Puteți crea o solicitare direct din program: Ajutor → Solicitare către suportul tehnic.

Sunt disponibile și următoarele canale oficiale:

•  telefon: +38 (067) 558-37-84, luni–sâmbătă, 09:00–18:00;

•  Telegram: @torgsoft_help;

•  e-mail: info@torgsoft.ua.

Datele de contact actuale și procedura de trimitere a unei solicitări sunt publicate pe pagina de suport tehnic Torgsoft și în instrucțiunile pentru crearea unei solicitări.

Listă de verificare înainte de fiscalizarea repetată

1. Verificați dacă bonul anterior nu a fost înregistrat la Serviciul Fiscal de Stat.

2. Salvați textul complet DocumentValidationError.

3. Stabiliți tipul operațiunii și valoarea exactă a diferenței.

4. Comparați plata în avans inițială cu factura curentă.

5. Verificați „Sumă”, „De plată”, metoda de plată și setările de rotunjire.

6. Pentru mai multe PFA, verificați fiecare bon și suma totală.

7. Comparați versiunea Torgsoft cu descrierile scenariilor remediate.

8. Creați o copie de rezervă a bazei de date înainte de modificări sau actualizare.

9. Remediați sursa reală a diferenței: documentul, setarea, asocierea sau succesiunea restituirii.

10. Generați din nou bonul numai după verificarea statutelor și sumelor.

Această procedură permite diferențierea rotunjirii aritmetice de modificarea facturii, distribuirea incorectă între întreprinderi sau întreruperea legăturii cu documentul fiscal anterior. Acest lucru este important deoarece același rând „Plată în avans” poate apărea în urma unor operațiuni diferite, iar codul 9 indică doar faptul că totalurile bonului nu au trecut validarea.