Callback
  • De la tarabă la magazin

  • -

  • De la magazin la lanț de retail

  • -

  • De la retail la producție

Terminalul bancar afișează „ANULAT” sau „RESPINS”, iar vânzarea în Torgsoft este închisă: cum se verifică rezultatul plății

Vladimir Vitishchenko
Vladimir Vitishchenko

Expert în automatizarea tranzacțiilor la Torgsoft

În timpul plății integrate cu cardul, Torgsoft transmite suma cumpărăturii către terminalul POS bancar, primește răspunsul băncii și, după o operațiune reușită, înregistrează plata fără numerar. Antreprenorii apelează la specialiști atunci când terminalul imprimă «ANULAT», «RESPINS» sau un alt statut negativ, iar vânzarea în Torgsoft s-a închis deja; când cumpărătorul primește o notificare privind debitarea, dar programul nu a primit rezultatul; când în Torgsoft apare mesajul «RRN nu a fost primit»; sau când nu este clar dacă plata poate fi pornită din nou. În astfel de cazuri trebuie verificate separat tranzacția bancară, plata în Torgsoft și bonul fiscal PCM. Plata repetată se inițiază numai după stabilirea rezultatului primei operațiuni.

Cum are loc plata cu cardul prin Torgsoft

Dacă se utilizează opțiunea «Integrare cu terminalul bancar», o vânzare obișnuită se desfășoară astfel:

  1. Casierul creează vânzarea în Torgsoft.

  2. Alege plata fără numerar.

  3. Torgsoft transmite suma către terminalul POS.

  4. Cumpărătorul apropie cardul sau telefonul și confirmă operațiunea.

  5. Terminalul contactează banca.

  6. Banca transmite rezultatul.

  7. Terminalul POS transmite rezultatul în Torgsoft.

  8. După autorizarea reușită, Torgsoft înregistrează plata în contul de decontare corespunzător.

  9. Dacă PCM este conectat, datele operațiunii cu cardul pot ajunge în bonul fiscal. 

În scenariul normal, toate cele trei componente trebuie să corespundă între ele:

Ce verificăm

Rezultatul corect

Terminal bancar

operațiune reușită

Torgsoft

o singură plată fără numerar

PCM

un singur bon fiscal cu forma corectă de plată

Problema apare atunci când una dintre aceste etape se încheie diferit.

Ce înseamnă «ANULAT» și «RESPINS»

Textul de pe slipul terminalului bancar arată rezultatul generat de terminalul de plată.

«RESPINS» înseamnă de obicei că banca sau sistemul de plată nu a confirmat operațiunea.

«ANULAT» poate apărea după anularea operațiunii sau atunci când terminalul nu a putut finaliza întregul schimb tehnic cu sistemul de casă.

Pentru Torgsoft este descris separat scenariul în care, la lucrul prin RDP și pe un canal instabil, terminalul poate imprima «ANULAT». Pentru astfel de conexiuni, în documentație este recomandată utilizarea BPOS1 cu așteptarea confirmării din partea casei și, dacă este posibil, conectarea terminalului prin Ethernet. 

Textul de pe slip trebuie luat în considerare, însă dacă există indicații contradictorii, operațiunea trebuie verificată în jurnalul terminalului sau în serviciul bancar.

De ce notificarea de debitare de pe telefonul cumpărătorului nu este suficientă

Cumpărătorul poate arăta o notificare push sau un SMS privind debitarea sumei. Aceasta este o informație utilă, dar nu trebuie să fie singurul temei pentru decizia casierului.

Operațiunea cu cardul trece prin mai multe etape. În aplicația bancară a cumpărătorului poate apărea autorizarea sau rezervarea sumei înainte de finalizarea completă a schimbului dintre bancă, terminal și programul de casă.

Prin urmare, dacă:

  • telefonul arată debitarea;

  • POS-ul imprimă «ANULAT»;

  • Torgsoft afișează un timeout,

trebuie stabilit statutul final al tranzacției. Cardul nu trebuie procesat din nou imediat.

Ce este RRN și de ce este necesar

RRN — este identificatorul tranzacției bancare, pe care serviciul de plată îl poate transmite împreună cu rezultatul operațiunii.

De exemplu, în documentația monobank, în răspunsul la o operațiune reușită a terminalului sunt transmise separat:

  • status;

  • responseCode;

  • approvalCode;

  • rrn;

  • identificatorii tranzacției;

  • masca cardului;

  • data și ora.

Acest lucru arată bine principiul: RRN este unul dintre elementele tranzacției, iar rezultatul operațiunii este determinat prin ansamblul datelor primite, inclusiv statutul.

Prin urmare, regula «Există RRN — banii au fost primiți cu siguranță» este greșită.

RRN ajută la identificarea operațiunii, la efectuarea returului și la reconcilierea datelor cu banca. Pentru verificarea finală trebuie analizate statutul operațiunii și datele achizitorului.

Codul de autorizare, RRN și codul de răspuns sunt date diferite

În timpul tranzacției, terminalul poate transmite mai multe valori de serviciu. Codul de autorizare confirmă o autorizare concretă în sistemul de plată. RRN este utilizat pentru identificarea tranzacției. Codul de răspuns indică rezultatul transmis de bancă sau de protocolul terminalului.

Codurile exacte depind de:

  • bancă;

  • modelul terminalului;

  • protocol;

  • serviciul de plată.

Prin urmare, casierul nu trebuie să memoreze un tabel de coduri numerice. Dacă pe terminal apare un cod necunoscut, acesta trebuie verificat în documentația băncii respective sau prin suportul tehnic al acesteia.

Cea mai importantă regulă pentru casier: nu repetați plata înainte de verificare

În cazul unei finalizări neobișnuite a operațiunii, casierul trebuie să se oprească la vânzarea curentă.

Nu trebuie:

  • să apăsați din nou «Plătiți»;

  • să cereți cumpărătorului să apropie din nou cardul;

  • să creați o a doua vânzare;

  • să modificați manual tipul plății;

  • să eliberați marfa numai pe baza notificării din aplicația bancară a cumpărătorului.

Mai întâi trebuie stabilită starea primei tranzacții.

În caz contrar, poate apărea următorul scenariu:

  1. prima operațiune cu cardul este de fapt reușită;

  2. Torgsoft nu primește răspunsul din cauza pierderii conexiunii;

  3. casierul inițiază o a doua plată;

  4. banca procesează ambele tranzacții.

Tocmai a doua debitare trebuie evitată.

Cea mai importantă regulă pentru casier

Algoritm pas cu pas dacă POS-ul afișează «ANULAT» sau «RESPINS»

Pasul 1. Păstrați slipul

Nu aruncați documentul terminalului.

Notați:

  • suma;

  • data;

  • ora;

  • Merchant ID, dacă este imprimat;

  • identificatorul terminalului;

  • RRN;

  • codul de autorizare;

  • codul sau textul rezultatului operațiunii.

Pentru diferite bănci, componența datelor poate fi diferită.

Pasul 2. Verificați dacă vânzarea s-a închis în Torgsoft

Verificați dacă vânzarea curentă a dispărut din formularul de vânzare și dacă a fost creată plata financiară. Dacă Torgsoft a lăsat vânzarea neachitată, este un scenariu. Dacă vânzarea este deja închisă ca plată fără numerar, situația este diferită.

Pasul 3. Verificați PCM

Dacă se utilizează CM software, deschideți: Setări → CM software → Analiză CM software.

Verificați:

  • dacă s-a format bonul;

  • data și ora;

  • suma;

  • forma de plată;

  • datele tranzacției bancare.

Conform cerințelor actuale ale Serviciului Fiscal, la plata cu cardul prin terminal conectat sau integrat cu CM/PCM, bonul fiscal include datele achizitorului, terminalului, instrumentului de plată și codul care identifică operațiunea în sistemul de plată. 

Pasul 4. Verificați operațiunea bancară

Dacă rezultatul rămâne neclar, tranzacția trebuie verificată din partea băncii.

În funcție de modelul terminalului și bancă, acest lucru se poate face:

  • prin jurnalul operațiunilor POS;

  • prin funcția de verificare a ultimei operațiuni;

  • în cabinetul de acquiring;

  • prin serviciul de suport al băncii.

Transmiteți băncii:

  • suma;

  • ora;

  • Merchant ID;

  • Terminal ID;

  • RRN;

  • codul de autorizare, dacă există.

După aceasta se poate stabili dacă operațiunea a fost reușită, respinsă sau anulată.

Scenariul 1. Banca confirmă refuzul, iar Torgsoft nu a creat plata

Acesta este cazul cel mai simplu.

De exemplu:

  • POS-ul a imprimat «RESPINS»;

  • Torgsoft nu a închis vânzarea;

  • bonul PCM nu s-a format;

  • banca confirmă că achiziția nu a avut loc.

După aceasta, cumpărătorului i se poate propune din nou să plătească marfa:

  • cu același card;

  • cu alt card;

  • prin altă metodă.

Noua operațiune va fi o tranzacție bancară separată.

Scenariul 2. Banca confirmă refuzul, dar Torgsoft a închis vânzarea

Acesta este exact cazul în care proprietarul magazinului vede ulterior o diferență:

  • Torgsoft arată o vânzare fără numerar;

  • marfa a fost scoasă din stoc;

  • banca nu a primit banii.

În versiunea Torgsoft 2026.0.5 a fost corectat un scenariu separat în care, după o plată nereușită prin terminal, plata putea fi totuși asociată contului în «Comerț cu emiterea facturii». De asemenea, a fost adăugat controlul timeout-ului pentru JSON WebSocket

Dacă situația s-a produs deja, trebuie verificate două documente:

  1. plata în Torgsoft;

  2. bonul fiscal PCM.

Dacă nu există bon fiscal

Trebuie anulată înregistrarea internă incorectă a plății și vânzarea readusă într-o stare în care poate fi plătită corect.

Acțiunea concretă depinde de modul de vânzare și de document, de aceea, dacă vânzarea este deja închisă, este mai bine să nu ștergeți aleatoriu înregistrările financiare asociate.

Dacă bonul fiscal este deja înregistrat

Trebuie corectată și operațiunea fiscală. Nu se poate șterge pur și simplu documentul financiar din Torgsoft și lăsa bonul fiscal ca plată cu cardul reușită.

Mai întâi se verifică starea turei și bonul concret, după care se utilizează scenariul prevăzut de anulare sau retur.

Scenariul 3. Banca confirmă plata reușită, iar Torgsoft nu a închis vânzarea

Aceasta este situația inversă.

De exemplu:

  • cumpărătorul a apropiat cardul;

  • banca a confirmat operațiunea;

  • terminalul are o tranzacție reușită;

  • Torgsoft a primit timeout;

  • vânzarea a rămas neachitată.

Operațiunea POS nu trebuie repetată.

În Torgsoft este prevăzut un scenariu de introducere manuală a parametrilor unei tranzacții bancare deja efectuate.

Dacă terminalul bancar nu este temporar utilizat prin conexiunea integrată, în formularul de plată se poate dezactiva «Utilizați conexiunea cu terminalul bancar». Atunci Torgsoft deschide formularul «Parametrii plății prin terminal bancar», în care se introduc datele de pe slip.

Acest lucru permite:

  • să nu fie trimisă o a doua comandă de cumpărare către POS;

  • să fie înregistrată plata existentă în Torgsoft;

  • să fie transmise datele tranzacției cu cardul către PCM, dacă setările corespunzătoare sunt active.

Înainte de această operațiune trebuie să vă asigurați că banca a confirmat într-adevăr prima tranzacție.

Scenariul 4. POS-ul a imprimat «ANULAT», iar banca arată o operațiune reușită

Acesta este un rezultat contradictoriu. Într-un astfel de caz, casierul nu trebuie să decidă singur ce este mai important: slipul pe hârtie sau notificarea cumpărătorului. Operațiunea trebuie verificată la achizitor pe baza datelor sale.

Dacă banca confirmă că operațiunea este reușită și nu a fost anulată, continuați ca în cazul unei plăți bancare deja efectuate: nu inițiați o a doua tranzacție, ci finalizați corect vânzarea în Torgsoft.

Dacă banca confirmă că operațiunea este anulată sau respinsă, plata cu cardul nu trebuie să rămână în evidență.

Prezența RRN înseamnă că plata poate fi considerată reușită

Nu. RRN este foarte important pentru găsirea operațiunii, dar singur nu înlocuiește statutul acesteia.

De exemplu, API-urile bancare moderne transmit separat:

  • status;

  • RRN;

  • codul de autorizare;

  • codul de răspuns.

Prin urmare, pentru verificarea rezultatului trebuie analizat în primul rând statutul final al tranzacției, iar RRN trebuie utilizat pentru identificare și reconciliere. 

De ce Torgsoft poate afișa «RRN nu a fost primit»

Cauza depinde de terminal și de biblioteca băncii.

Pe pagina oficială Torgsoft se menționează că pentru unele terminale Verifone, inclusiv X990, biblioteca băncii poate să nu transmită automat RRN. În cazul unui retur, în această situație poate fi utilizat codul de autorizare de pe bon. 

Prin urmare, mesajul privind lipsa RRN nu înseamnă întotdeauna că achiziția nu a avut loc în bancă. Trebuie verificat statutul bancar.

De ce este important să păstrați datele terminalului

Torgsoft utilizează datele operațiunii inițiale cu cardul și pentru operațiunile ulterioare.

De exemplu, la retur, programul poate utiliza datele tranzacției inițiale pentru a returna banii exact pentru plata corespunzătoare. Pagina oficială a opțiunii indică de asemenea că Torgsoft înregistrează datele plății și le utilizează pentru returnarea banilor pe card sau la tranzacția inițială. 

În versiunea 2026.0.5 a fost corectată separat transmiterea RRN, PAN și a altor parametri ai terminalului în documentul financiar la plata unei comenzi. 

De ce apar astfel de situații la lucrul prin RDP

Într-o schemă terminală, Torgsoft poate funcționa pe un server la distanță, iar POS-ul fizic poate fi amplasat lângă casier.

Dacă POS-ul este conectat local prin COM/USB, iar datele sunt transmise către sesiunea la distanță prin RDP, în schemă apare un canal suplimentar de comunicație.

Documentația Torgsoft indică direct că, în cazul unui RDP instabil, sunt posibile:

  • «Eroarea nr. 3»;

  • probleme de conectare;

  • imprimarea unui bon cu «ANULAT».

Pentru BPOS, documentația oficială Torgsoft recomandă:

  • BPOS1 cu așteptarea confirmării din partea casei;

  • conectarea terminalului prin Ethernet. 

Aceasta reduce dependența schimbului de plată de redirecționarea COM/USB prin sesiunea la distanță.

De ce terminalul are nevoie de confirmare din partea casei

Unele protocoale prevăd un schimb final între POS și programul de casă.

În setările BPOS din Torgsoft există:

  • «Utilizați confirmarea casei»;

  • «Ignorați confirmarea casei».

Documentația explică faptul că al doilea parametru poate fi utilizat la lucrul prin RDP într-o configurație corespunzătoare, când plata se efectuează pe POS, dar rezultatul nu ajunge în Torgsoft.

Acești parametri nu trebuie modificați de casier în timpul lucrului. Setarea trebuie să corespundă protocolului terminalului și configurației băncii.

Timeout: de ce Torgsoft poate înceta să aștepte răspunsul

Tranzacția bancară necesită un anumit timp:

  • cumpărătorul apropie cardul;

  • introduce PIN-ul;

  • banca procesează solicitarea;

  • terminalul primește răspunsul;

  • datele revin în Torgsoft.

Dacă legătura se pierde în ultima etapă, banca și Torgsoft pot avea informații diferite despre starea operațiunii.

În versiunea 2026.0.5, pentru JSON WebSocket a fost adăugat controlul timeout-ului pentru așteptarea răspunsului și posibilitatea configurării valorii acestuia. De asemenea, se creează un jurnal separat al activității terminalului, care poate fi utilizat pentru diagnosticare. 

Prin urmare, dacă timeout-urile se repetă, verificați:

  • versiunea Torgsoft;

  • protocolul POS;

  • rețeaua;

  • timeout-ul;

  • jurnalele terminalului;

  • setările echipamentului bancar.

Ce trebuie făcut dacă casierul a anulat accidental așteptarea

Dacă programul încă aștepta răspunsul POS, iar casierul a întrerupt procesul, rezultatul operațiunii bancare poate rămâne nedeterminat pentru Torgsoft.

Regula rămâne aceeași: nu inițiați o plată nouă până când cea anterioară nu a fost verificată.

Mai întâi:

  1. verificați slipul;

  2. verificați jurnalul POS;

  3. găsiți operațiunea în bancă;

  4. verificați vânzarea în Torgsoft;

  5. verificați PCM.

Abia după aceasta stabiliți acțiunea următoare.

Cum se verifică bonul fiscal după plata cu cardul

Conform Regulamentului actual privind forma documentelor de decontare, atunci când se utilizează un POS pentru carduri conectat sau integrat cu CM/PCM, bonul fiscal conține un bloc de date de plată.

Printre acestea sunt prevăzute:

  • identificatorul achizitorului și al comerciantului;

  • identificatorul dispozitivului de plată;

  • tipul operațiunii;

  • datele instrumentului electronic de plată;

  • sistemul de plată;

  • codul de autorizare sau alt identificator al operațiunii;

  • forma de plată. 

Prin urmare, după o operațiune POS contradictorie, bonul fiscal este încă o sursă de reconciliere, însă acesta arată ceea ce a fost transmis către PCM. Statutul bancar final trebuie verificat la achizitor.

Slipul POS și bonul fiscal PCM îndeplinesc funcții diferite

Slipul POS descrie tranzacția de plată. Bonul fiscal descrie operațiunea de decontare pentru vânzare. Prin urmare, în cazul unei defecțiuni tehnice, este posibil ca unul dintre documente să existe, iar celălalt nu.

De aceea, în timpul diagnosticării trebuie verificate ambele.

Dacă Torgsoft a creat deja o plată incorectă

Nu trebuie compensată prin:

  • dispoziție de casă;

  • depunere de serviciu;

  • retragere de serviciu;

  • a doua tranzacție cu cardul.

Mai întâi stabiliți starea corectă a operațiunii bancare. După aceasta se corectează documentul financiar asociat sau vânzarea, în funcție de scenariu.

Dacă operațiunea a fost deja fiscalizată, PCM se verifică separat.

Dacă un terminal lucrează cu mai multe Persoană fizică autorizată

În cazul unui rezultat contradictoriu trebuie verificat suplimentar Merchant ID.

În Torgsoft, asocierea trebuie să respecte schema: Merchant ID → cont de decontare → Persoană fizică autorizată. Un merchant incorect poate duce la direcționarea plății către alt antreprenor sau la imposibilitatea identificării tranzacției inițiale pentru retur. 

După o plată de test este recomandat să verificați Merchant ID pe bonul terminalului și extrasul bancar.

Cum se organizează lucrul casierilor

Pentru casier este suficientă o regulă scurtă: dacă terminalul nu oferă un rezultat pozitiv clar, marfa nu se eliberează și plata nu se repetă până când prima tranzacție nu este verificată.

Instrucțiunea internă poate include următoarele acțiuni:

  1. Nu apăsați «Plătiți» a doua oară.

  2. Păstrați slipul POS.

  3. Verificați statutul vânzării în Torgsoft.

  4. Verificați PCM.

  5. Verificați tranzacția bancară.

  6. Dacă banca confirmă succesul — finalizați evidența plății deja efectuate fără o nouă solicitare către POS.

  7. Dacă banca confirmă refuzul — repetați plata ca operațiune nouă.

  8. Dacă Torgsoft și banca afișează rezultate diferite — transmiteți datele administratorului sau suportului tehnic.

Ce trebuie să verifice proprietarul dacă situația se repetă

Dacă situația apare regulat, problema nu mai privește o singură vânzare.

Verificați:

  • versiunea actuală Torgsoft;

  • modelul POS;

  • banca;

  • protocolul de conectare;

  • COM/USB, Ethernet sau Wi-Fi;

  • utilizarea RDP;

  • setările confirmării casei;

  • timeout-ul;

  • Merchant ID;

  • contul de decontare;

  • Persoană fizică autorizată;

  • jurnalul de funcționare al terminalului.

Pentru JSON WebSocket, în Torgsoft 2026.0.5 a fost adăugat control separat al timeout-ului, iar pentru plățile nereușite au fost corectate scenarii separate de asociere a documentelor financiare. 

Algoritm scurt: se poate repeta plata cu cardul

Starea primei operațiuni

Ce trebuie făcut

Banca a confirmat refuzul, Torgsoft nu a creat plata

poate fi efectuată o plată nouă

Banca a confirmat succesul, Torgsoft nu a creat plata

înregistrați plata în Torgsoft fără o solicitare repetată către POS

Banca a confirmat refuzul, Torgsoft a creat plata

corectați evidența în Torgsoft; verificați PCM

Banca a confirmat succesul, Torgsoft a creat plata

nu efectuați nimic din nou

Statutul băncii este necunoscut

obțineți mai întâi statutul final

POS-ul afișează «ANULAT», telefonul cumpărătorului arată debitarea

verificați operațiunea la bancă; nu repetați plata înainte de verificare

Regula principală pentru astfel de cazuri: rezultatul plății cu cardul se stabilește după statutul tranzacției bancare, iar RRN, codul de autorizare, slipul, documentul financiar Torgsoft și bonul PCM sunt utilizate pentru identificare și reconciliere. Dacă rezultatele diferă, casierul stabilește mai întâi starea primei operațiuni și abia după aceea repetă plata sau corectează documentele.


Програма обліку товару | Торгсофт



Facebook Instagram YouTube Twitter Google News Apple Podcast SounCloud

Adăugați comentariu

Adăugați comentariu
Vă mulțumim pentru feedback! Acesta va fi publicat după verificarea de către un moderator.

Articole similare