[Dor]

Salut Norocel!
Nu-mi dau seama care poate fi cauza vitezei reduse de raspuns. Dupa cum ai observat si tu, ea se „muta” cu cantarul. Asadar putem suspecta o interfata seriala mai lenta la seria respectiva de cantare.
Din punctul nostru de vedere, comunicatia seriala nu s-a schimbat.
Am introdus insa un nou model de cantar, provenind din portofoliul DIGI, si anume modelul DS788 parca, pentru a putea oferi alternative de la alti producatori in cazul in care fabricatia lasa de dorit cateodata la aceste modele entry-level.
Mai multe de talii telefonic.

[Dor]

Formatul micro functioneaza si in prezent dar numai pentru varianta cu formulare pretiparite si nu pe coli A4.
Numarul de exemplare se seteaza din optiuni (implicit 3) dar nu va impiedica nimeni sa selectati 2 sau 1 chiar.
Inca o data, fiti mai expliciti in cerinte. Nu se intelege cerinta dvs. din mesaj.

[Dor]

Nu cred ca s-a scos vreo situatie din program. Va rog sa fiti mai explicit. Indicati meniul din care selctati situatie.
Oricum verificati daca programul este activat pentru o distributie care include situatia respectiva.

[Dor]

Pe avizele de insotire puteti decide din optiunile programului daca sa fie sau nu afisat pretul de achizitie si/sau pretul de vanzare.
Depinde deci de setarile pe care le are utilizatorul.
Selectati setarile corespunzatoare pentru a lista avizele la pret de achizitie.

[Dor]

Raspunsul este in mod firesc, nu.
Si asta pentru ca bug-ul probabil ca a fost de mult fixat (versiunea 7.0 are cel putin 1 an si jumatate).
Solutia este sa efectuati un upgrade la ultima versiune 8.0.2.160.

[Dor]

Nu suntem noi cei care producem aceste programe. Contactati firma Danibius Exim pentru amanunte tehnice (producator si distribuitor pentru aceste aplicatii).

Din experienta noastra insa, va putem comunica cu certitudine ca in modul Online casele de marcat indiferent de model (Datecs, Elka, Sapel, Samsung) NU PERMIT OPTIUNEA de spargere a codului de cantar in greutate pe bon. Motivul: nu exista functionalitatea interna de parsare a codului de bare de cantar. Ca urmare casa trateaza codul de bare ca un articol vandut la bucata, cerand din partea PC-ului un pret pentru o bucata. In cazul aplicatiei noastre (SmartCash ECR Server) calculam pretul corect, corespunzator cantitatii reale si il trimitem catre casa ca si pret unitar. Pe bon insa nu are cum sa apara decat 1 x valoare = valoare de fapt.
Singura solutie este un upgrade la un terminal POS cu imprimanta fiscala si abandonarea solutiei low cost bazata pe case de marcat.
Totusi, daca stai sa te gandesti este un amanunt… si omul pleaca din magazin cu o eticheta tiparita de cantar cu toate cele pe ea, iar pe bon apare valoarea corecta.. Nu vad unde clientul s-ar simti dezinformat sau indus in eroare…din perspectiva Protectiei Consumatorului Bineinteles… Acuma ce sa mai zicem? Daca e de spaga se gaseste nod in papura la orice…

[Dor]

Consultati cel mai apropiat partener certificat Magister Software. Vezi lista completa la: http://www.magister.ro/corporate/portal … fault.aspx

[Dor]

Stimate d-le Barlutiu,
Acest forum este unul public.. Ca urmare se pot formula numai intrebari strict la modul general, care au legatura cu subiectul in dreptul caruia ati postat.
Nu este permis sa postati numele clientului sau si mai rau datele sale de contact. Aceste informatii sunt personale si nu avem voie sa le afisam fara permisiunea clientului.
Legat de problema dvs. aceasta se poate explica in modul urmator:
Magazinul din Cluj a fost cuplat la reteaua de magazine x. Odata cuplat el nu mai are puterea de decizie (chiar daca seful de magazin s-a suparat…:))
Toti clientii se introduc din centrala de magazine de unde sunt replicati in toata reteaua.
Este vorba despre clientii calificati al caror nume si date merita pastrate.
Solutia clientului respectiv a fost deja transmisa catre centrala si daca va mai suna va rog sa-i transmiteti sa solicite instructiuni de acolo.
Pentru a lamuri insa problema facturilor, aceasta este urmatoarea:
– Un magazin satelit nu poate emite decat Facturi la Bon Fiscal
– De la POS (nu din Backoffice) el poate emite facturi la bonul fiscal emis cu nr. X, CHIAR SI FARA SA AIBA DATELE DE CONTACT ALE CLIENTULUI!
– Interfata le solicita inainte de imprimarea facturii, iar clientul apare numai pe factura si nu este pastrat nicaieri.
– Daca se doreste pastrarea sa in baza de date cu clienti el va fi introdus numai de la centrala.
– Oricum de la POS in magazin se solicita facturi sporadic si in majoritatea cazurilor de catre persoane fizice sau juridice cu care a doua oara nu te mai intalnesti. Pastrarea acestor date intr-o baza de date nationala unica este o problema si pentru biroul Evidenta Populatiei, asa incat cerintele sefului de magazin sunt exagerate. El vrea de fapt sa poata emite facturi si asta se poate face in orice moment direct de la POS.

[Dor]

Multumesc Mugur.
Vreau sa mai aduc unele precizari, pentru ca ieri, din criza de timp nu am apucat.
De fapt sunt doua teme:
– Am introdus o protectie suplimentara la utilizarea neautorizata a updater-ului de catre oricine, prin solicitarea unei parole la rularea sa. Parola curenta este salvata in directorul de download in fisierul parola.txt si se va schimba cu fiecare nou release pentru a asigura utilizarea in principal de catre personalul autorizat a updater-ului.
– Legat de actualizarea bazei de date:
Aceasta se compune din urmatoarele etape elementare:
– ShutDownDatabase = deconectarea tuturor clientilor curent cuplati si permisiunea de conectare numai pt. sysdba. Cum insa in 99.99% din implementari userul de SmartCash este SYSDBA, aceasta nu inseamna ca un „iute de click”, nu se poate reconecta imediat dupa ce a fost deconectat !! Atentie. Oricum deconectarea este fortata si va genera exceptii la nivelul aplicatiilor conectate. Nu sunt insa posibile pierderi de date in afara celor continute in ferestrele de input curent deschise…lucru care nu este foarte dramatic. Oricum, este bina sa le explicati la efectuarea actualizarii, ca intai trebuie sa se opreasca statiile/programele conectate de la baza de date.
– Backup baza de date intr-un fisier in aceeasi locatie cu baza vvv_AAALLZZ.gbk. Daca nu se finalizeaza back-up-ul cu succes, nu se trece mai departe. Efectuarea unui back-up dupa shutdown database, este cea mai sigura metoda ca in back-up au fost incluse complet toate tranzactiile comise.
– Dupa finalizarea back-up-ului se redeschide baza si mai apoi se da din nou ShutDown Database. Motivul: Scoaterea celor „iuti de click” de la conexiunea cu baza de dat chiar inaintea aplicarii scripturilor DDL/SQL de update. Este esential accesul unic in acest moment deoarece unele actualizari de indecsi sau foreign_keys se pot face numai in acest regim, in caz contrar fiind ridicata o exceptie de catre serverul SQL. Deoarece back-up-ul poate dura destul de mult, in functie de dimensiunea bazei de date, este posibil ca in acest interval, vreun user sa se reconecteze la baza de date asa incat, pentru siguranta se redeconecteaza toti potentialii utilizatori chiar inainte de actualizarea propriu-zisa.
– Se aplica succesiv scripturile de actualizare… de obicei dureaza doar cateva secunde, asa incat reconectarea in acest interval de timp nu este posibila in 90% din situatii.
– Se redeschide baza pentru useri si se iese in aplicatia principala pentru actualizarea finala a fisierelor locale de pe PC-ul respectiv.
Cam asta ar fi un ciclu normal de upgrade baza cu noul updater.
In plus, in cazul in care cel putin unul din pasii scriptului de actualizare a bazei a esuat, procesul se intrerupe si se efectueaza automat restaurarea bazei de date din copia originala intr-o baza de date noua cu aceeasi denumire ca fisierul de backup. Motivul este acela de a pastra ambele baze de date cea veche si cea noua (inconsistenta in acest moment), urmand ca inlocuirea ei sa fie facuta de catre un operator manual.

[Dor]

Salut Madalin!
Exista un sambure mare de adevar in solicitarea ta….
In plus una din consecintele operatiei mentionate poate duce la diferente intre raportul de gestiune si stoc in cazul descarcarii de stoc la intervale de timp mai mari dupa inchiderea de zi propriu -zisa.
In legatura cu acest subiect te rog sa consulti bug-fix-urile din urmatorul release (8.0.1.121-Db322) pentru ca a fost fixat incepand cu aceasta versiune.
La proiectarea programului am ales insa ca inchiderea de zi si .. mai ales descarcarea de stoc, sa fie efectuate exclusiv din backoffice.
In primul rand ca aceste doua operatii pot fi efectuate de acelasi casier (poate avea dreptul acesta si atunci nu trebuie sa cheme pe nimeni sa i le faca).
In al doilea rand, chiar daca inchiderea de zi (nu Z-ul care este deja) ar fi integrata in interfata POS-ului, cu siguranta ca descarcarea de stoc nu poate fi pusa acolo din cauza ca este necesara o interfata ceva mai bogata decat cea simplificata de la nivelul POS-ului. In plus sunt niste decizii de luat in cazul descoperirilor de stoc, pe care nu cred ca e bine sa le ia chiar cel care vinde.

In concluzie, putem considera ca inchiderea de zi ar putea fi preluata pe interfata de POS dar sincer probabilitatea e redusa…
In plus mai e ceva… Operatia de inchidere de zi efectueaza un volum mare de tranzactii care se centralizeaza pe un numar redus de tabele din baza de date. Atunci cand sunt efectuate din backoffice sunt operate unitar centralizat si nu pot sa apara lock conflict-uri. La operarea distribuita, de pe mai multe POS-uri, pericolul de aparitie a blocajelor creste enorm, in conditiile in care in care fiecare inchidere proceseaza intre 1500 si 5000 de inregistrari.

Numai bine!

[Dor]

Programul SmartCash Shop este un produs specializat, proiectat PENTRU RETAIL!!!
Repet asta tuturor partenerilor nostri!
Va inteleg pe toti ca doriti sa il vindeti si altor clienti decat cei cu o activitate specializata pe retail, dar repet, nu a fost proiectat pentru asta.
Punctul sau forte sta in utilizarea acolo unde viteza de rotatie a stocului este mare si foarte mare! Unde informatia relevanta trebuie afisata instantaneu fara sa dobori sistemul pentru un raport.
Inca si mai important, produsul este proiectat pentru CONTROLUL ACTIVITATII IN RETAIL. Asta inseamna RESTRICTII. In nici un caz nu inseamna sa-i lasi pe utilizatori sa faca ce vor in backoffice.
In concluzie, ca sa raspund insa punctual la intrebarea ta, ea dovedeste ca nu cunosti inca toate aspectele programului.
Ambele aspecte solicitate de tine, sunt disponibile in program insa in modul controlat pe care l-am explicat mai sus:
1) Ai factura de retur de la furnizor (ADIKA FURNIZORUL ITI DA O FACTURA DE MINUS). Intr-adevar asa cum ai spus tu faci un aviz de insotire pentru a descarca marfa returnata de pe gestiune, dar de ce nu introduceti datele facturii de storno in caseta factura storno si in datele aferente fiecarui articol prevazute cu acest scop? In acest mod, la inchiderea returului (Transfer la furnizor) valoarea din factura de storno este automat trecuta sub forma de compensare in lista de plati catre furnizorul respectiv, scazand soldul acestuia. Nu e nevoie de nici o chitanta. Asta se intampla automat.
2) Trebuie sa dai tu factura de minus… OK. de ce? Pai atunci cand primesti ceva inapoi de la un client si vrei „sa-i dai banii inapoi”. Ai functia de „retur de la client cu bon fiscal” si functia de „retur factura cu ridicata”. Ambele emit automat facturile de minus aferente adaugandu-le in soldul clientului respectiv similar cu furnizorii.
Detalierea despre care intrebi este afisata in Urmarire Furnizori, respectiv Urmarire Clienti. Pentru asta au fost create.

A, daca vrei tu ca omul sa dea la liber facturi de storno …. asta se poate oriunde vrei dar nu intr-un magazin controlat de SmartCash Shop. Pentru asta se gasesc programe free pe net de taiat facturi, dar nu asta este scopul nostru.

[Dor]

Sarut mana!
Functiile solicitate au fost implementate in versiunea curenta. (4.0.1.12)
In plus, in versiunea ce va fi lansata in luna februarie, impreuna cu update-ul lunar,
aplicatia include toate functionalitatile din SmartCash Shop sub forma portabila:
4.0.1.12:
– Inventar General
– Inventar / Loturi
– Verificare Preturi
– Receptie Furnizor
– Receptie magazine

4.0.1.16 (sau mai mult… deocamdata asta e versiunea in teste)
S-au adaugat:
– Transfer la Furnizor
– Transfer la Magazin
– Comanda Interna (vanzarea de pe raft cu asistenta).

[Dor]

A.. Acuma am priceput.
trebuie vorbit la Softnet sa trateze tipul asta nou de client (vid) generat la POS, sau
sa nu-l mai preia deloc.
Treaba este ca in general facturi la bon fiscal pentru clienti „de pe strada” date de la casa, nu prea se salveaza in nici o baza de date.
Ajungi in scurt timp un fel de „Evidenta polulatiei” si nu foloseste nimanui.
Am sa-i trimit un mail d-lui Virgil la Viosan.

[Dor]

Aceeasi versiune facea problema asta…cu access violation la iesire.
Daca dadea la intrare, atunci intr-adevar baza era busita si ca atare nu mai puteai intra in Smartcash.
In situatia asta intr-adevar solutia ta cu IbManager e singura aplicabila.

[Dor]

Balanta de verificare lunara se obtine dupa inchiderea lunii din Rapoarte de gestiune/Listare stoc lunar.