Release notes RetailVista najaar 2020 update versie 20.17

Algemeen / diversen

(Versie 20.16.7570.17932) Taak 19704 - Bij heropenen verkooporder nooit reserveringen verwijderen met een logistieke status >= wordt geraapt

Bij het heropenen van een verkooporder kan aangegeven worden dat openstaande reserveringen verwijderd mogen worden. Dit gebeurd vanaf nu alleen nog voor reserveringen waarvan de logistiekek status zich nog niet in of na het raap proces bevindt. Van reserveringen waar men bezig is met rapen (of daar al mee klaar is) moet het magazijn besluiten wat ze met dat soort reserveringen willen gaan doen.

(Versie 20.16.7570.17932) Taak 19703 - Functie heropenen verkooporder graag kunnen autoriseren

Het heropenen van een verkooporder is nu autoriseerbaar met functie autorisatie.

(Versie 20.11.7472.28236) Taak 19429 - Omgeving ondersteuning inbouwen

Met de nieuwe omgevingen tabel kan een gebruiker vrij eenvoudig selecteren op welke 'omgeving' hij/zij actief is. Denk bij een omgeving bijvoorbeeld aan afdelingen waar een gebruiker zich bevindt. Op die afdeling of in de buurt van die afdeling bevinden zich bepaalde printers waar men gebruik van kan maken. Per omgeving kunnen dus de te gebruiken printer vooraf ingesteld worden. Het gaat in dit geval om het nieuwe type 'bridge' printers. De actieve omgeving kan worden gekozen in de linker kolom van de start pagina van RetailVista en wordt per gebruiker bewaard. In de nieuwe versie van RetailVista Mobile (RetailVista Mobile X) wordt de keuze van een omgeving ook ondersteund.

De omgeving met bridge printers wordt op dit moment al ondersteund in de verkooporder module. Daar kunnen verkooporder rapportages automatisch worden geprint naar deze nieuwe type printers. Hierdoor is het mogelijk om verkooporders die gemaakt zijn in RetailVIsta Mobile automatisch te printen naar A4 printers.

De komende tijd de de hele rapportage omgeving van RetailVista worden omgebouwd naar de bridge printers, waarbij rekening wordt gehouden met de geselecteerde actieve omgeving. Daardoor is het straks niet meer nodig om van een rapportage altid eerst de afdruk op het scherm getoond te krijgen en daarna via een truuk de Windows printer te kiezen: rapportages kunnen straks direct zonder verdere tussenkomst naar een bridge printer worden geprint. De bridge printer is feitelijik de opvolger van RetailVista Local Services waarbij dus niet alleen thermische printers ondersteund worden, maar ook A4/pagina printers.

Er wordt met ingang van deze versie strict gecontroleerd of de API integratie licentie aanwezig is. Voorheen bestond die controle niet en bleek dat veel partijen zonder licentie toch gebruik maken van onze API functionaliteit. Vanaf deze versie is dat niet langer mogelijk en wordt er actief gecontroleerd bij API communicatie of de bijbehorende licentie aanwezig is.

Artikellijsten

(Versie 20.13.7534.25412) Taak 19101 - Artikellijst naar levering op rekening om kunnen zetten

Het omzetten van een artikellijst naar een levering op rekening is verbeterd qua gebruikers interface. Zo kunnen nu alleen de geselecteerde regels worden overgezet en is het scherm voor het overzetten opnieuw ontworpen.

Inkoopfactuur controle

(Versie 20.13.7534.25412) Taak 19438 - EDI bericht graag geformatteerd weergeven

In de inkoop factuur controle wordt in het tabblad 'EDI' het bericht vanaf nu geformatteerd weergeven. Dit houdt in dat er per EDI regel een nieuwe regel op het scherm wordt gestart. Er waren leveranciers die een bericht zelf niet voorzien van die regel eindes, RetailVista herformatteert vanaf nu dergelijke berichten.

Kasverantwoording

(Versie 20.12.7485.21011) Taak 19531 - In journaal verkoop betaling regel niet alleen aanbetalingsnummer vermelden maar ook webshop order referentie, verkooporder nr waar aanbetaling bij hoort, gevolgd door originele aanbetaling nr

Vanwege afletteren in de boekhouding is het essentieel dat de afzonderlijke aanbetalings journaalposten meer informatie in het omschrijving veld bevatten als uitsluitend het aanbetalingsnummer. Vanaf nu wordt er daarom meer informatie getoond in het omschrijving veld in het journaal van die aanbetaling.

Offertes

(Versie 20.12.7485.21011) Taak 19523 - Geen onderliggende artikelen van set artikel toevoegen aan verkooporder bji omzetten offerte naar verkooporder

Bij het copieeren van een offerte naar een verkooporder worden vanaf nu de onderliggende artikelen van een set artikel niet meer overgenomen. Het toevoegen van die artikelen doet de verkooporder omgeving zelf al en door deze aanpassing wordt voorkomen dat dat soort artikelen dubbel ontstaan in een verkooporder.

Ontvangsten

(Versie 20.16.7570.17932) Taak 19696 - Bij genereren reserveringen vanuit ontvangsten het ontvangst boekstuk vastleggen bij de reservering

In het tabblad 'geavanceerd' van reserveringen is vanaf nu zichtbaar wat het ontvangst boekstuk is waardoor de reservering ontstaan is. Dit wordt gevuld als bij het genereren van reserveringen een ontvangst boekstuk opgegeven is. Op dat moment wordt uitsluitend gekeken naar de artikelen uit die specifieke ontvangst en wordt berekend of daar artikelen voor klanten tussen zitten. Dergelijke reserveringen krijgen dat ontvangst boekstuk toegekend en het is dan de bedoeling dat die reserveringen direct geraapt worden uit de artikel ontvangst, nog voordat de artikelen de winkel in gaan.

Via het automatisch printen van raaplijsten kunnen reserveringen als gevolg van artikel ontvangst op specifieke printers geprint worden. Zo is het mogelijk om bijvoorbeeld te kiezen voor een printer met een aparte kleur papier, zodat duidelijk is dat dat soort raaplijsten direct gepakt moeten worden, omdat anders de artikelen al in de winkel staan.

(Versie 20.16.7570.17932) Taak 19692 - Product type in ontvangst regels grid kunnen kiezen als kolom

In de artikel ontvangst regels kan als kolom nu voor het 'product type' gekozen worden. Daarmee kan zichtbaar worden gemaakt welke regels over 'maatwerk' artikelen gaan. Dat soort artikelen moeten immers handmatig gereserveerd worden bij binnenkomst. Het automatisch reserveren van dat soort regels gaat niet omdat er van maatwerk artikelen geen voorraad bijgehouden kan worden. Het zijn immers verzamel artikelen waar van alles en nog wat op besteld wordt. Als zichtbaar is dat er maatwerk artikelen in een ontvangst zitten (en welke regels dat dan zijn) dan kan gekozen worden om die handmatig te gaan reserveren.

Reserveringen

(Versie 20.16.7570.17932) Taak 19697 - Bij reservering een afleg locatie vast kunnen leggen

Bij een reservering kan vanaf nu een afleg locatie worden opgeslagen. Dit is een vrije tekst veld waar dus elke willekeurige omschrijving in kan worden vastgelegd.

(Versie 20.15.7559.27956) Taak 19652 - Bij printen reserveringen rapportages ook kunnen filteren op vervallen ja/nee/alles

Vanaf nu kan bij het printen van reservering rapporrtages ook gekozen worden voor het wel of niet negeren van vervallen reserveringen. Uiteraard worden standaard de vervallen reserveringen niet geselecteerd en geprint.

(Versie 20.13.7534.25412) Taak 19587 - Genereren reserveringen vanuit linker taakbalk bij handmatig reserveren moet verkooporder op kunnen geven

Bij het genereren van reserveringen tijdens handmatig maken van reservering regels kan nu ook een verkooporder opgegeven worden. Hierdoor wordt alleen een reservering gegenereerd voor de verkooporder waarvoor op dat moment handmatig reservering regels gemaakt worden.

(Versie 20.12.7485.21011) Taak 19535 - Bij genereren reserveringen kan nu aangegeven worden dat reserveringen voor zover mogelijk ook direct automatisch op rekening worden gezet

Dit is ingebouwd en mogelijk gemaakt om te zorgen dat verzend notificaties vanuit een WMS omgeving automatisch leiden tot een levering o prekening (omzet/ verkoop van de reservering) en daarmee het sluiten van de bijbehorende verkooporders. Bij andere klanten was dat ongewenst omdat daar onbedoeld reserveringen direct verkocht worden én ook nog eens ongewenst op rekening worden gezet. Bij deze klanten is het maar de vraag of een reservering al verkocht moet worden, en zo ja, of een klant er voor kiest om dat op rekening te doen. Dat is bij die klanten een handmatige keuze op het moment dat de reservering klaar staat. Bovendien wordt de reservering nu gesloten waardoor klanten service niet goed kan zien wat er nog wel en niet openstaat en afgehandeld moet worden. Bij de verkooporder classificatie kan vanaf nu ingesteld worden of automatisch op rekening zetten van reserveringen gewenst is. Het standaard gedrag doet dat niet, in feite zoals het tot voorheen ook werkte. Als het dus gewenste is om van een reservering automatisch een levering op rekening te maken, dan moet dat ingesteld worden in de verkooporder classificatie.

(Versie 20.12.7485.21011) Taak 19524 - Set 'hoofd' artikel ook toevoegen bij eerste mogelijke reservering

Het 'hoofd' artikel van een set wordt vanaf nu niet meer aan een aparte reservering toegevoegd, maar wordt vanaf nu toegevoegd aan een 'wilekeurige' reservering die aangemaakt is voor de zelfde verkooporder als waar het set hoofdartikel bij hoort.

Dit speelt alleen als reserveringen worden geplitst naar afdelingen. Een hoofd artikel heeft niet altijd een afdeling en zou daarom in zo'n geval worden toegevoegd aan een reservering zonder afdeling. Bij splitsen van reserveringen naar afhaal locaties speelt dit probleem niet, in dat scenario kan een hoofd artikel ook een afhaal locaite krijgen en zal deze dan automatisch aan de juiste reservering worden toegevoegd.

(Versie 20.12.7485.21011) Taak 18824 - Printen reserveringen moet automatisch naar twee printers plaats kunnen vinden, instelbaar via scenario

Vanaf nu kunnen diverse rapportages vanuit verkooporders en reserveringen automatisch geprint worden. Dit werkt via de nieuwe bridge printer technologie. In de verkooporder classificaties kunnen layouts en printers ingesteld worden die worden toegepast bij het automatisch printen van rapportages. In de najaars release wordt dit onderdeel definitief vrijgegeven, het bevindt zich nu in test stadium. Dan kan ook vanuit RetailVista Mobile goed geprint worden op deze nieuwe manier.

Statistiek

(Versie 20.16.7570.17932) Taak 19700 - In statistiek 236 moet zichtbaar worden gemaakt wat de oorspronkelijke verkooorder referentie van een verkoopregel was

In statistiek 236 is een extra kolom 'Order referentie' toegevoegd. Hier wordt de verkooporder referentie in vermeld als een reservering verkocht is. Met deze order referentei kan een match worden gemaakt naar de originele verkooporder.

Verkooporders

(Versie 20.16.7570.17932) Taak 19713 - Bij sluiten verkooporders dan niet de gekoppelde reserveringen verwijderen

Vanaf nu worden bij sluiten van verkooporders niet meer automatisch alle nog openstaande reserveringen verwijderd. Dat was een foutieve ontwerp keuze uit het verleden: als het restant van een verkooporder niet meer gewenst is dan kan die worden gesloten. Maar dat wil niet perse zeggen dat wat al gereserveerd staat, niet meer uitgeleverd hoeft te worden. Of het besluit kan worden genomen om de gereserveerde artikelen op te heffen en terug de voorraad in te brengen. Door het verwijderen van de reserveringen zijn die daarna ook onvindbaar waardoor niet meer duidelijk is van wie die reserveringen waren, wat de status er van was etc etc. Het is aan het magazijn om na het sluiten van een verkooporder te beslissen over de nog aanwezige openstaande reserveringen.

(Versie 20.16.7570.17932) Taak 19686 - Meer mogelijkheden realiseren voor adres wijzigen vanuit verkooporder zelf

Het muteren van een bezorg adres vanuit de verkooporder was al mogelijk. Het is vanaf nu ook mogelijk om vanuit de verkooporder een afleveradres toe te voegen. Hiervoor moet de order eerst gewijzigd worden (volledig heropenen is niet nodig). Door de order deels te heropenen verschijnt naast het aflever adres een '+' icoon om een nieuw adres toe te voegen. Het adres wat op deze manier aangemaakt wordt, wordt als extra aflever adres bij de relatie opgeslagen.

(Versie 20.16.7570.17932) Taak 19684 - Zoek control uitbreiden met extra zoek optie

Bij het aanmaken van een verkooporder regel bestaat een zoek systeem waarmee op verschillende manieren gezocht kan worden naar een artikel. Meestal is dat op basis van barcode of artikel nummer, maar er zijn ook andere methodes selecteerbaar. Bij de verschillende methodes is een extra methode toegevoegd waarmee ook direct op de omschrijving van een artikel gezocht kan worden. De zoekmethode is 'externe code, artikel nr, barcode, omschrijving'. De standaard te gebruiken zoek methode is instelbaar in de instellingen van RetailVista.

(Versie 20.16.7570.17932) Taak 19679 - Huisnummer 0 bestaat, wordt nu niet verwerkt

Als een webshop order bericht nu een huisnummer '0' aanlevert, dan wordt door RetailVista bij de verwerking dat huisnummer als 'leeg' beschouwd en als zodanig weggeschreven in de adres informatie. Voorheen ontstond een (terechte) afkeur op zo'n bericht, omdat RetailVista geen huisnummers met een 0 accepteert.

(Versie 20.16.7570.17932) Taak 19676 - Melding geven indien onvoldoende voorraad om verkooporder regel aantal stuks direct te reserveren

In de verkooporder classificatie kan aangegeven worden dat bij het toevoegen van een verkooporder regel, er een controle plaats vindt of er voldoende vrije voorraad is voor het gevraagd aantal stuks. Als dat niet zo is, dan kan er nu een melding getoond worden op het scherm, die door de gebruiker eerst bevestigd moet worden. Deze functionaliteit is een wijziging van gedrag van RetailVista en moet daarom expliciet aangezet worden in de verkooporder classificatie.

(Versie 20.15.7559.27956) Taak 19646 - Kunnen muteren van de 'hoofd' set artikel verkoopprijs in een verkooporder

Er is een belangrijke wijzgiing doorgevoerd in verkooporders rond 'set' artikelen. Bestaande functionaliteit is dat als een set artikel wordt toegevoegd, automatisch alle onderliggende artikelen van die set worden toegevoegd. Wat aangepast is, is dat het vanaf nu mogelijk is om het aantal stuks en de prijs van het hoofd artikel te muteren. Het is niet meer mogelijk om de prijs en aantal van de onderliggende set artikelen te muteren. Uit de prijs en het aantal van het hoofd artikelen volgt een verrekening naar de onderliggende set artikelen, qua aantal en prijs. De prijs wordt netjes verdeeld over de onderliggende artikelen. En als het aantal bijvoorbeeld verdubbeld wordt, dan worden de aantallen van de onderliggende artikelen ook automatisch verdubbeld. Ook het verwijderen van een onderliggend set artikel is niet meer mogelijk: De set is één geheel en wordt als zodanig besteld, óf men moet losse onderdelen bestellen.

(Versie 20.14.7545.23961) Taak 19613 - Koppeling bewaren tussen verkooporders en inkooporders

Vanaf nu wordt er een koppeling bijgehouden tussen verkooporders en inkooporders. Er bestond al wat langer bij meerdere gebruikers de wens om van een verkooporder regel te zien in welke inkooporder(s) die regel verwerkt was. Zoals bekend zal zijn worden verkooporder regels 'ingeteld' dus meerdere verkooporder regels kunnen leiden tot één inkooporder regel. Maar dan is nog steeds handig om te weten vanuit bijvoorbeeld die inkooporder regel, welke verkooporder regels daar allemaal bij horen. Dat is vanaf nu zichtbaar. Vanuit de verkooporder regel is een grid beschikbaar die de inkooporder regels toont waar de verkooporder regel bij hoort, en omgekeerd is vanuit de inkooporder regel een grid zichbaar die toont welke verkooporder regels hebben geleid tot die inkooporder regel.

Het is dus ook mogelijk dat een verkooporder regel in meerdere inkooporders terecht komt. Die kans is technisch nu erg klein, maar in een volgende update van RetailVista zullen verkooporders automatisch opnieuw besteld worden als de verkooporder regel nog open staat en niet meer voorkomt in een inkooporder. De gedachte daarachter is dat veel leveranciers niet aan backorders doen. Voorheen werd een verkooporder slechts één keer omgezet in een inkooporder. Maar door deze aanpassing kunnen we in een volgende update een verkooporder automatisch opnieuw bestellen.

(Versie 20.16.7570.17932) Taak 19586 - Datum velden in verkooporder uitbreiden met vroegste leverdatum en gewenste leverdatum

De klant kon tot dusver nooit aangeven wat de gewenste leverdatum was. In plaats daarvan werd het veld 'geplande leverdatum' vaak misbruikt als gewenste leverdatum.

Ook was er geen mogelijkheid voor een klant om aan te geven dat men artikelen niet eerder wilde ontvangen als een bepaalde datum. Met de introductie van het 'vroegste leverdatum' is dat probleem ook opgelost. Met de vroegste leverdatum wordt nu (net zo als met de uiterste leverdatum) technisch niets gedaan.

(Versie 20.12.7485.21011) Taak 19545 - Bij vervallen verkooporder niet automatisch alle regels ook als vervallen markeren

Als een verkooporder vervallen gemarkeerd wordt, dan werden ook automatisch alle regels geannuleerd. Dat was geen gewenst gedrag, vooral niet omdat bij het terugzetten van die vervallen indicatie onbekend is welke regels terug gezet moeten worden. Immers: daar kunnen regels tussen zitten die echt vervaleln zijn gemarkeerd in overleg met de klant. Maar als automatisch alles vervallen gemarkeerd wordt is niet meer om welke regels dat origineel ging. Vanaf nu worden de verkooporder regels niet meer vervallen gemarkeerd bij het vervallen verklaren van een verkooporder. Externe systemen die gebruik maken van de vervallen indicaties op regel niveau moeten rekening houden met deze aanpassing qua gedrag en moeten vooral letten op de vervallen indicatie van de verkooporder zelf.

(Versie 20.12.7485.21011) Taak 19525 - Verlaag bedrag van nog niet verwerkt aanbetalingsverzoek bij aanmaak of bijwerken van reservering

Een aanbetalingsverzoek wordt vanaf nu automatisch verlaagd bij het onderhoud van een reservering als blijkt dat het verkooporder bedrag min het totaalbedrag aan reserveringen lager is als het aanbetalingsverzoek bedrag. Dit kan gebeuren als achteraf nog mutaties plaats vinden in de verkooporder en/of reserveringen terwijl het aanbetalingsverzoek al gemaakt is. Wat er tot dusver dan fout ging, was dat de klant in RetailVista POS soms een te hoog bedrag moest betalen in bovengenoemde situatie, wat uiteraard tot klachten leidde. Vanaf nu wordt er altijd voor gezorgd dat het aanbetalingsverzoek bedrag niet te hoog zal zijn. Als het verschil tussen de verkooporder waarde en het totaalbedrag van alle reserveringen 0 is, dan zal het aanbetalingsverzoek worden verwijderd.

(Versie 20.12.7485.21011) Taak 19495 - Verkooporder classificatie uitbreiden met dropshipment wel/niet toepassen onder voorwaarden

In de verkooporder classificatie kan nu aangegeven worden hoe er omgegaan moet worden met de dropshipment suggestie. Zo kan dropshipment altijd of nooit worden gesuggereerd, of volgens een bepaalde berekening. De berekening methode is vervolgens ook instelbaar en kan onder meer rekening houden met de dropshipment indicatie op artikel niveau, al dan niet samen met bepaalde voorraad standen.

(Versie 20.12.7485.21011) Taak 19453 - Bij artikel categorie aan kunnen geven dat bij toevoegen verkooporder regel de voorraad genegeerd moet worden

Op bepaalde groepen artikelen nooit voorraad bijgehouden, zoals bv planten. Door op de plant categorieën aan te geven dat voorraad moet worden genegeerd bij toevoegen van een verkooporder regel, zal het veld 'direct reserveren' altijd worden gevuld met het verkooporder aantal.

(Versie 20.13.7534.25412) Taak 19037 - BTW vrijgesteld indicatie op verkooporder muteerbaar

Bij het muteren van een verkooporder kan de BTW vrijgesteld indicatie nu wordt aangepast. Op dat moment worden alle BTW tarieven/codes opnieuw bepaald bij de artikelen. Uiteraard worden de prijzen dan ook herberekend. Voor de bepaling van het BTW tarief wordt gebruik gemaakt van het fiscale land van de order en het artikel. Als van dat land en artikel geen BTW tarief bekend is, dan wordt het BTW tarief van de vestiging van de verkooporder gebruikt. Zou die ook niet bekend zijn (erg theoretisch) dan blijft die betreffende regel onveranderd.

Door de herberekening gaan kortingen ed wel verloren (worden opnieuw bepaald), immers de bruto prijs veranderd waardoor de kortingen ook niet langer geldig zouden zijn.

(Versie 20.12.7485.21011) Taak 19025 - Fiscaal land opgeven bij verkooporder

Bij aanmaken of onderhoud van een verkooporder moet vanaf nu ook het fiscale land worden opgegeven. Dit veld wordt in principe automatisch gevuld vanuit de relatie van de verkooporder. Met het fiscal land kan via een BI tool (zoals bijvoorbeeld Qlik) of later in een nog te ontwikkelen statistiek de omzet per land worden berekend. Het fiscal land wordt nu al gebruikt om het juiste BTW tarief te bepalen bij de artikelen. Als er bij het artikel geen specifiek BTW tarief van dat fiscal land aanwezig is, dan valt RetailVista terug op het standaard BTW tarief. Dat is het BTW tarief van het land van de vestiging.

Voorraad

(Versie 20.16.7570.17932) Taak 19610 - Gealloceerde voorraad ondersteunen

Vanaf nu is het mogelijk om te werken met gealloceerde voorraad. Dit is voorraad die fysiek nog wel aanwezig is, maar niet direct verkoopbaar is. Denk hierbij aan bijvoorbeeld aan showroom voorraad. Deze is wel aanwezig in het normale voorraad aantal stuks, en telt dus bijvoorbeeld ook mee in de totale voorraad waarde. Alleen moet showroom voorraad niet gekocht kunnen worden via de webshop. Daarom is het nu mogelijk om een bepaald aantal stuks van een artikel als gealloceerde voorraad te markeren. Dat kan onder andere via RetailVista Mobile, of via RetailVista ERP via Start, Voorraad, Gealloceerde voorraad. Door artikelen in de gealloceerde voorraad te plaatsen, gaat de vrije voorraad omlaag. Bij het plaatsen van een artikel in de gealloceerde voorraad moet het type gealloceerde voorraad aangegeven worden. De mogelijke types zijn zelf aan te maken in RetailVista ERP.

De gealloceerde voorraad is tevens een voorbereiding op arrangementen: een arrangement wat gemaakt wordt bestaat uit artikelen afkomstig uit de reguliere voorraad. Maar die artikelen zijn op dat moment niet meer 'los' verkoopbaar. De wens bestaat daarom al langer om met arrangementen een soort uitzondering te maken in de voorraad. Met de introductie van gealloceerde voorraad zijn de voorbereidingen getroffen om voorraad apart te kunnen zetten. In een volgende release van RetailVista ERP zullen arrangementen ook gebruik maken van deze functionaliteit. Het is te verwachten dat bij verkoop van een arrangement deze automatisch afgeboekt zal worden van de gealloceerde voorraad.

Webshop

(Versie 20.10.7452.28636) Taak 19419 - Het graag mogelijk maken om meerdere printer te gebruiken t.b.v. de pakketdienst integratie. Bijvoorbeeld een printer per POS terminal o.i.d.

Er is een nieuwe omgevingen tabel. Daarin kan nu een standaard thermische printer opgegeven worden en een afwijkende pakketdiensten thermische printer . Indien dit niet geconfigureerd wordt, dan blijft de standaard webshop printer uit de vestiging gebruikt worden.

Door in RetailVista POS een bepaald RetailVista system account te kiezen en in dat account de juiste 'omgeving' thermische printer in te stellen zal bij verwerken van de reservering de juiste printer gebruikt worden voor het printen van pakketdienst etiketten.