FiscalLink
    Cloud DashboardDescarcă

    Erori cunoscute

    Probleme pe care le cunoaștem, cu cauza și rezolvarea. Pentru Shopify POS, vezi Probleme frecvente în documentația Shopify POS.

    Bluetooth sau serial fără permisiuni (Linux)

    Problemă. Pe Linux, aplicația nu poate deschide portul serial sau Bluetooth și primește erori de permisiune (EPERM / EACCES), deși Bluetooth merge din setările sistemului. Apare de obicei pe o instalare nouă sau un cont nou.

    Cauză. Linux dă acces la dispozitive prin grupuri. Porturile serial și Bluetooth (/dev/rfcomm0, /dev/ttyUSB*, /dev/ttyACM*) aparțin grupului dialout, iar pe unele distribuții Bluetooth e permis doar membrilor grupului bluetooth. Un cont care nu e în aceste grupuri primește erori de permisiune pe care nicio aplicație nu le poate ocoli. Mesajul de eroare din aplicație îți arată comanda exactă pentru grupul de care ai nevoie.

    Rezolvare.

    1. Verifică dacă grupurile există: getent group dialout și getent group bluetooth.
    2. Dacă lipsește unul, creează-l (rar: dialout vine cu sistemul, bluetooth cu pachetul bluez): sudo groupadd dialout / sudo groupadd bluetooth.
    3. Adaugă contul care rulează aplicația în ambele grupuri:
    bash
    sudo usermod -aG dialout,bluetooth $USER
    1. Înlocuiește $USER cu numele contului, dacă aplicația rulează pe alt cont (de exemplu contul casierului).
    2. Ieși din cont și intră din nou (sau repornește calculatorul). Grupurile se citesc la autentificare, deci o sesiune deja pornită nu le vede. Pentru un test rapid, în același terminal: newgrp dialout.
    3. Repornește aplicația.

    Bluetooth în Parallels (Linux)

    Problemă. O casă Datecs asociată prin Bluetooth (de exemplu WP-50MX) nu răspunde din aplicația de Linux rulată ca mașină virtuală Parallels pe macOS, cu un adaptor USB Bluetooth atașat mașinii virtuale. sdptool browse <MAC> expiră, bluetoothctl connect <MAC> eșuează cu br-connection-page-timeout, iar btmon arată Connect Complete: Status: LMP Response Timeout (0x22). Casa merge de pe alte calculatoare.

    Cauză. Două cauze se suprapun:

    • Căutarea activă blochează conectarea. Cât timp panoul Bluetooth din GNOME e deschis, adaptorul rămâne în Discovering: yes. Adaptoarele ieftine nu pot căuta și conecta în același timp, așa că fiecare conectare expiră.
    • USB-ul virtual din Parallels resetează adaptorul. Controlerul USB virtual trimite evenimente greșite; driverul xhci_hcd din Linux le tratează ca defecțiune și repornește adaptorul la câteva minute, ceea ce întrerupe conectarea.

    Rezolvare.

    1. Închide panoul Bluetooth din GNOME și oprește căutarea: bluetoothctl scan off. Verifică cu bluetoothctl show | grep Discovering: trebuie să scrie no.
    2. Verifică dacă adaptorul se deconectează: sudo dmesg | grep -iE "usb.*disconnect|HC probably|RTL: loading". Mai multe rânduri înseamnă un USB instabil.
    3. În configurația mașinii virtuale Parallels (cu mașina oprită), la Hardware → USB & Bluetooth:
      • dezactivează „Share Bluetooth devices with Linux”;
      • setează adaptorul să se conecteze mereu la această mașină virtuală (nu „ask me”);
      • dezactivează USB 3.0 pentru mașina virtuală, ca adaptorul să folosească controlerul USB 2.0;
      • scoate dispozitivele partajate inutile (camera Continuity sau iPhone etc.): Parallels resetează tot USB-ul virtual la evenimentele de pe Mac.
    4. Conectează adaptorul direct în Mac, nu printr-un hub sau adaptor USB-C cu mai multe porturi.
    5. Oprește economisirea de energie USB în Linux, ca setarea să rămână și după repornirea adaptorului:
    bash
    echo "options btusb enable_autosuspend=0" | sudo tee /etc/modprobe.d/btusb.conf
sudo udevadm control --reload
    1. Dacă bluetooth.service e oprit cu start-limit-hit: sudo systemctl reset-failed bluetooth, apoi sudo systemctl start bluetooth.
    2. Dacă asocierea casei s-a pierdut, asociaz-o din nou din panoul Bluetooth GNOME sau din bluetoothctl în modul interactiv (agent on, default-agent, scan on/off, pair, trust). Nu folosi bluetoothctl pair dintr-o singură comandă: eșuează cu AuthenticationTimeout.

    Casa refuză bonurile după 24 de ore

    Problemă. Casa refuză bonurile fiscale. Codul erorii e -111024 pe Datecs, 1100 pe Tremol sau 82 („DEPASIT 24h”) pe Daisy. Pe Datecs, aplicația arată „Casa de marcat nu mai acceptă vânzări.”

    Cauză. Au trecut 24 de ore de la prima vânzare de după ultimul raport Z.

    Rezolvare. Faci raportul Z: din programul tău, din Shopify POS, din FiscalLink Cloud, de pe casa de marcat sau, pe Datecs, din fila Stare a aplicației. După raportul Z, casa primește din nou bonuri.

    Bonul e refuzat pe o casă Daisy

    Problemă. Un bon cu vânzare după nume și preț e refuzat pe o casă Daisy. Nu se tipărește nimic, iar casa nu deschide bonul.

    Cauză și rezolvare, după codul erorii:

    • DAISY_FREE_SALE_TURNED_OFF: vânzarea liberă pe Daisy e oprită. Pornește-o în Configurare → General (vezi Setări).
    • DAISY_FREE_SALE_NO_DEPARTMENT_FOR_VAT: niciun departament din casă nu are cota TVA a liniei. Programează pe casă un departament cu acea cotă.
    • DAISY_DEPARTMENTS_UNREADABLE: aplicația nu a putut citi departamentele casei. Verifică legătura cu casa și încearcă din nou.
    • DAISY_FREE_SALE_NEGATIVE_PRICE: o linie are preț negativ. Un articol Daisy nu poate avea preț negativ; scoate linia din bon.

    Conexiunea se pierde în fundal (Android)

    Pe unele telefoane și tablete Android, sistemul oprește aplicația când trece în fundal și îi închide conexiunile. Pașii de rezolvare sunt la Shopify POS → Probleme frecvente → „Conexiunea se pierde în fundal (Android)”.