Moderator Dor
ModeratorRaspunsuri la forumul creat
-
SmartCash RMS 2021
Versiune: 18.0.1.12
Data Lansare: 29.01.2021
Luna: Ianuarie
Tip Lansare: Mentenanta
Aplicatii modificate:
SmartCash Shop – 32Bit – v. 18.0.1.12 [DB 769.1]
SmartCash eCommerce Framework Service – 32/64Bit – v. 1.0.0.28
SmartCash Shop
New Feature
1. Finalizare implementare interfata API GLS. Introdus prin upgrade (DB 769) localitatile echivalente si pentru curierul GLS.Optimizare
1. La scanarea unei etichete de articol cu cod de cantar acum, pe langa identificare, se preia automat greutatea la adaugarea pe vanzari cu ridicata.
2. La scanarea unei etichete de articol cu cod de cantar acum, pe langa identificare, se preia automat greutatea la adaugarea pe bonuri de consum.
3. La scanarea unei etichete de articol cu cod de cantar acum, pe langa identificare, se preia automat greutatea la adaugarea pe transferuri la magazine din retea.
4. La scanarea unei etichete de articol cu cod de cantar acum, pe langa identificare, se preia automat greutatea la adaugarea pe transferuri la furnizori.
5. La scanarea unei etichete de articol cu cod de cantar acum, pe langa identificare, se preia automat greutatea la adaugarea pe comenzile de livrare.
6. Scanarea codurilor de cantar este acum tradusa in greutate si la localizarea articolelor de pe documentele mentionate.
7. Optimizari de interfata in cazul formelor de adaugare colete/curieri/Bug Fix
1. Fixat eroare „invalid argument to date encode” la pornirea raportului din Situatii Detaliate->Comenzi Livrare->Grupat pe clienti si tipuri de plata.
2. Fixat eroare grid „readonly” la completarea datelor de curier pentru un singur document.SmartCash eCommerce Framework Service
New Feature
1. Finalizare implementare serviciu automatizare sincronizare cu SmartCash eCommerce Framework. Acum toate site-urile gazduite pe platforma de eCommerce Magister, se sincronizeaza automat, in fundal cu solutia SmartCash RMS. -
SmartCash RMS 2021
Versiune: 18.0.1.9
Data Lansare: 26.01.2021
Luna: Ianuarie
Tip Lansare: Mentenanta
Aplicatii modificate:
SmartCash Shop – 32Bit – v. 18.0.1.9 [DB 768.5]
Plug-In Export – 32Bit – v. 8.1.3.32
SmartCash POS – 32/64Bit – v. 8.0.0.9
SmartCash Lynx – 32Bit – v. 6.1.0.116
SmartCash Everywhere Standard Server – 32/64Bit – v.5.1.0.29
SmartCash Everywhere REST Standalone Server – 32/64Bit – v.4.0.2.73
SmartCash Everywhere REST ISAPI Server – 32/64Bit – v.4.0.2.73
SmartCash NetBridge – 32/64Bit – v. 9.0.2.63 [DB Centralizare 335.4]
SmartCash Log Reader – 32Bit/64Bit – v. 1.0.0.25
SmartCash Shop
Optimizare
1. Permis returul unei facturi bazate pe clientul guest si la catre un client non guest.
2. Adaugat coloana Procesator Card si ID Tranzactie Card pe interfata cu alicatia eCommerce si in Dispeceratul de Ordine de Livrare.
3. Preluat valoarea coloanelor Curier, Procesator Card si ID Tranzactie Card pe o comanda de livrare provenita dintr-o comanda online si pe AWB-ul aferent.Bug Fix
1. Fixat pornire web browser incorporat la Retur vanzare Ridicata.
2. Fixat afisare incorecta culoare coloana Pret in catalogul de produse pentru liniile selectate.SmartCash POS
Bug Fix
1. Fixat bug incasare comanda livrare in asteptare cu discount procentual de sf de bon. Se intra in situatie de avarie.SmartCash Lynx
Optimizare
1. Preluat automat valoarea coloanelor Curier, Procesator Card si ID Tranzactie Card pe o comanda de livrare provenita dintr-o comanda online.
2. Adaugat coloanele IDCARD_GATEWAY si CARD_TRANSACTION_ID la centralizarea automata comenzilor de livarre catre centrala de magazine.SmartCash Everywhere Standard Server
Optimizare
1. Adaugat coloanele ID_FURNIZOR_DELIVERY, TYPEOF_PAYMENT_GATEWAY si CARD_TRANSACTION_ID la query-urile care aduc comenzile de livrare.SmartCash Everywhere REST Server
New Feature
1. Adaugat coloanele TYPEOF_PAYMENT_GATEWAY si CARD_TRANSACTION_ID la functia AddNewDeliveryOrder.
2. Adaugat coloana SHIPPING_COMPANY_ID la metoda UpdateDeliveryOrder.Bug Fix
1. Fixat valoare gresita la functia GetNextRetailSale la campurile totale de plata. (TOTAL_PAY_CASH_VALUE, TOTAL_PAY_CEC_VALUE, TOTAL_PAY_COUPON_VALUE, TOTAL_PAY_CARD_VALUE)SmartCash NetBridge
Optimizare
1. Incrementat versiunea minima de pachete de date. (18.0.1.5)
2. Incrementat versiunea minima a bazei de date centralizate. (335)Bug Fix
1. Urmatoarele campuri nu erau cenytralizate in tabela furnizori: ISPLATITOR_TVA, ISTAX_REVERSE, ISTRUSTED_SUPPLIER, TYPEOF_EXCHANGEINFO, IS_PAN_CURRENT, PAN_DISCOUNT, VALOARE_MINIMA_COMANDA, IDCOUNTRY_CITIES, STREET_ADRESS, ISEXTERN.SmartCash Log Reader
Optimizare
1. Actualizare necesara pentru suportul pentru log-ul noii aplicatii Smartcash eCommerce. -
Asa cum am verificat impreuna nu exista un bug in aceasta speta. Motivul afisarii incorecte este diferenta intre sablonul raportului de comanda personalizat pe care il utilizati si cel standard.
Odata cu versiunea 18, SmartCash, campurile utilizate pentru preturi pe comenzile de livrare s-au diversificat. Asadar trebuie sa actualizati si sablonul personalizat in vederea afisarii campurilor corecte pe rapoarte.
Folositi ca model sablonul standard ce este actualizat automat prin upgrade.
-
Va recomand sa folositi noua functie, disponibila in SmartCash RMS 2021 de avizare directa a unei comenzi catre o alta ocatie din retea.
Astfel ordinul de livrare inteleg ca contine articole mixte (adica ce se gasesc in doua depozite fizice).
Facturarea se va face dintr-un singur depozit totdeauna, ca in cazul B. iar diferenta se avizeaza automat din gestiunea 2 catre 1, aceasta putand fi apoi receptionata in gestiunea principala pentru livrarea pe flux a aceleiasi comenzi care asteapta in dispecerat de asta data reavizata. (Poate e cam lunga formularea dar ar trebui sa sunati la suport sa va explice procesele)
A doua varianta ar fi sa livrati cu doua facturi/AWB la o comanda, dar nu stiu daca site-ul este compatibil cu acest proces.
-
In acest moment nu este o prioritate pentru noi sa multiplicam numarul de criterii de clasificare simultana dincolo de cele 10.
In 99% din cazuri, utilizatorii care se plang ca sunt putine categorii inteleg gresit modul lor de utilizare.
Ele nu sunt categorii de fapt ci „Dimensiuni” iar in retail, oricate integrari ai avea e greu sa intretii practic mai mult de 10 dimensiuni pentru fiecare articol.
-
Cred ca avem nevoie de mai multe detalii. la ce aplicatie va referiti? Shop sau in Mobility?
-
Salut,
Este o practica gresita crearea de utilizatori multipli pentru aceeasi persoana in SmartCash RMS pe baza functiei de program folosite.
De aceea exista roluri si acestea sunt adresabile si per functie si per aplicatie. Acelasi Alex Pop adaugat odata ca si casier, apoi ca si operator cu alt user este in sine o inutilitate.
El trebuie setat o singura data pe reuniunea rolurilor pentru cele doua functii si gata.
Scopul unui user este de a fi unic (identificat pana la urma cu acelasi „numar de marca” peste tot). In fond el poate fi integrat si in pontaj. Atunci ce facem cu el? Ii dam cate un card de acces pentru firecare duplicat al sau?
Cu faptul ca ar fi utila afisarea si a username-ului, in interfata, pot fi de acord, in anumite situatii. In general insa evitam utilizarea lui, acesta fiind pana la urma o informatie tehnica. Daca username-ul e „12jasjdgwyesg” la ce foloseste afisarea lui?
-
Pe de alta parte desi butonul se numeste „Anuleaza Transfer” acesta nu functioneaza in acest sens.
De fapt el sterge pachetul de date care contine transferul din locatia de salvare. Astfel la urmatoarea verificare el nu mai apare in lista si poti crede ca s-a anulat.
Daca insa un utilizator din gestiunea expeditoare retransmite transferul, acesta reapare in lista de receptii in asteptare.
Singura metoda prin care el nu mai este „in asteptare” este aceea de a inchide o receptie si a genera un NIR in gestiunea destinatie pentru acel transfer.
Pe de alta parte, raportul de verificare a marfii in tranzit verifica avizele de transfer care nu au o receptie NIR corespondenta in gestiunea destinatie. Prin urmare, pana cand receptia nu este operta, marfa va figura „in tranzit” pe termen nedefinit, chiar daca cineva a apasat butonul „Anuleaza Transfer”. Deci nu este posibila „ascunderea” transferurilor nereceptionate deoarece au fost „anulate”.
-
Acum inteleg. Da aveti dreptate. Accesul la aceasta functie trebuie restrictionat. O sa avem in vedere includerea unei restrictii in editorul de profile. Multumesc pentru sugestie.
-
Iata raportul mentionat:
-
Este o functionalitate ce poate fi integrata in modulul de automatizare procese. Totusi exista destul de multe scenarii in care inchiderea automata nu este de preferat, in special in cazul firmelor care lucreaza din pacate si pe „stoc negativ”.
Vom analiza oportunitatea si validarile ce trebuiesc implementate pentru a face acest proces sigur si serializabil.
Multumim pentru sugestie.
-
Buna ziua,
Functia de anulare a unui transfer nu exista in programul SmartCash RMS in mod justificat, tocmai pentru a controla mai strict aceasta operatie. Poate e o neintelegere.
Odata generat un transfer catre un magazin din retea, acesta este transmis automat catre gestiunea destinatie.
In cazul unei erori singura solutie este contactarea gestionarului din locatia de destinatie pentru rezolvarea problemei. Acesta va receptiona transferul si il va retransmite integral (cu functia Importa receptie) inapoi catre magazinul expeditor.
La randul sau, gestionarul din magazinul expeditor, receptioneaza din nou transferul integral, asa cum a fost generat prima data si stocul este reincarcat.
Acest mecanism reprezinta o verificare incrucisata absolut necesara intr-un sistem distribuit.
Nu va ascund ca metoda transferului (inainte de inventare) era folosita in trecut de gestionari pentru a acoperi „gaurile de inventar”. Este o metoda de furt simpla si rudimentara prin care un gestionar, in cooperare cu un altul, la fel de „cinstit” sau nu, se acopera reciproc atunci cand stiu ca urmeaza un inventar.
Am avut si un proces in urma cu cativa ani la un lant de distributie de carte finalizat cu o condamnare pe aceasta speta.
De regula, cei care au folosit aceasta metoda tin marfa „in tranzit” pe durata inventarelor iar la final, contacteaza gestionarul din magazinul de destinatie pe motiv ca au gresit, sa le retransmita marfa inapoi dupa metoda descrisa mai sus.
Din acest motiv, in meniul Rapoarte/SmartCash Everywhere exista un raport centralizat denumit „Marfa in Tranzit”. Acesta va poate afisa toate transferurile de la si catre magazine din retea care nu sunt inca receptionate la destinatie.
Este recomandabil ca inainte de deschiderea unui inventar, comisia de control sa listeze si acest raport cu filtru pe magazinul expeditor verificat, atat in calitate de expeditor cat si de destinatar.
Inventarul nu trebuie deschis cata vreme exista marfa in tranzit nejustificata.
-
Problema a fost fixata inca din luna septembrie. Multumim.
-
Dupa ce am verificat cu echipa de dezvoltare, am ajuns la concluzia ca acest comportament este o limitare a programului in acest moment.
Pe scurt, deoarece clientul ales pentru o factura poate beneficia de scheme de fidelizare care se aplica pe masura ce articolele sunt adaugate pe aceasta, schimbarea clientului dupa deschiderea facturii nu mai este permisa.
Este o limitare introdusa ca urmare a raportarii unor erori in calcularea reducerilor promotionale la alti clienti care modificau clientul dupa deschiderea facturii.
Totusi avem in vedere implementarea unui mecanism mai elaborat, care sa duca la recalcularea integrala a facturii dupa modificarea clientului, dar pentru moment asa functioneaza.
Pentru moment solutia este sa stergi vanzarea si sa adaugi una noua daca este vorba despre alt client.
-
Am fixat problema in build-ul lunii decembrie.
Multumim pentru sesizare.
Mai precis, versiunea 17.0.12.433.
