Release notes RetailVista voorjaar 2021 update versie 21.11

Nieuw in RetailVista

=============

- Verwijzing naar (toekomstige) nieuwe support website achter login naam

U-nummer achter login

Achter de Gebruikersnaam waarmee ingelogd is staat nu een U-nummer. Dit nummer is gelinkt aan de nieuwe support website die nu in ontwikkeling is. Door te klikken op dit nummer wordt automatisch de support website opgestart. De website is nog niet operationeel, daarom krijgt u nu nog een foutmelding als u hier op klikt. Naar verwachting is de website over enkele maanden operationeel.

- Wijziging Verkooporder menu

Verkooporder menu gesplitst

Verkooporders was tot nu opgebouwd uit 2 onderdelen: Verkooporders en Reserveringen.

Reservering functionaliteit is de afgelopen jaren zo sterk uitgebreid dat dit nu een eigen menu onderdeel is geworden, namelijk Fulfilment

- RetailVista Mobile X

RetailVista Mobile volledig vernieuwd   

Omdat het ontwikkelplatform wat wij voor RetailVista Mobile gebruikten stopte met verdere ontwikkeling en ondersteuning waren wij genoodzaakt om een ander ontwikkelplatform te gebruiken. Nadeel hiervan was dat wij van voren af aan opnieuw moesten beginnen met de ontwikkeling van RM. Voordeel was dat wij nu van een aantal beperkingen af konden komen die in het gebruikte platform bleken te zitten.

Wij zijn dan ook trots dat wij nu RetailVista Mobile X (RMx) kunnen presenteren. Sneller, nog gebruiksvriendelijker en functioneel uitgebreider dan RetailVista Mobile.

Functionaliteit van RMx:

• Artikel info • Arrangement • Artikel locaties

• Artikellijst • Bestel artikel • Derving

• Gealloceerde voorraad • Herkomst artikel • Inventarisatie

• Magazijntelling • Omzet statistiek • Ontvangsten

• Order picking • Orderpicking controle • Print etiket

• Print ontvangsten • Uitgifte • Uitgifte controle

• Verkooporder • Verplaats artikel • Verplaats locatie artikelen

• Wijzig prijs • Wijzig voorraad • Winkelmand

In ontwikkeling

• Guided order picking • Voorscanning

- Verkooporders Plus  

Aanvullend op verkooporder module: Verkooporders Plus  

Binnen RetailVista zijn er een aantal modules waar dermate veel ontwikkeling op geweest is dat dit niet binnen de bestaande module verwerkt kon worden zonder aanzienlijke aanpassing van de licentieprijs. Deze nieuwe ontwikkelingen zijn daarom verwerkt in een Plus licentie. Om met de Plus licentie te kunnen werken is de module “Verkooporders” noodzakelijk.

Plus licenties worden gefactureerd op basis van verbruik. Daarvoor worden er tellingen gedaan van het aantal aangemaakte orders per periode.

SLA is conform het SLA RetailVista.

Onderstaande functionaliteit zit er op dit moment in Verkooporders Plus:

Verkooporders Plus

• Afhaal locaties

Indien u meerdere afhaal locaties heeft, bijvoorbeeld winkelmagazijn en extern magazijn, kunt u per reservering aangeven wat de afhaal locatie is.

• Order raap controle

Alle artikelen van een geraapte reservering worden opnieuw gescand om er zeker van te zijn dat alle artikelen geraapt zijn en dat het ook de goede artikelen zijn. Hierbij is goed zichtbaar wat de nog niet gescande reservering-artikelregels zijn. Als er goed geraapt is blijft er geen regel over na de controle.

• Order uitgifte

Bij het scannen van de reservering barcode kan gecontroleerd worden of de reservering al aanbetaald is (of dat de levering op rekening plaats mag vinden) en of de reservering al niet afgehaald is.

• Order uitgifte controle

Eventueel kan er gekozen worden om bij uitgifte nog een keer alle artikelen te scannen. Hiermee wordt bij met name bezorging gecontroleerd of de overhandigde goederen inderdaad overeenkomen met de levering.

• Handtekening bij uitgifte

Op de pda kan een naam ontvangst en handtekening geplaatst worden als bewijs van aflevering. Dit wordt bij de reservering/verkooporder opgeslagen.

• Rembours functionaliteit

Er kan gekozen worden om het te betalen bedrag onder rembours te voldoen als er gebruik gemaakt wordt van de uitgifte functionaliteit. Bij het overhandigen wordt de bezorger geattendeerd op het te betalen rembours bedrag. Dit kan vervolgens afgestort worden op een speciaal daarvoor bedoelde RetailVista POS installatie.

• Fleurop import

Met de Fleurop import kunnen bestellingen van bloemen geïmporteerd worden.

• Orders rapen/Orderpicking

Met de module “Magazijn” is het al mogelijk om locaties in het magazijn te definiëren. Voor de winkel is dit nu ook mogelijk. Door het vastleggen van locaties wordt het order raap proces veel efficiënter doordat er geraapt kan worden op volgorde van artikelen/locaties. De te rapen artikelen worden in de pda aangegeven. Elk geraapt artikel wordt afgevinkt. Als de opdracht volledig geraapt is ontvangt de medewerker de volgende raap opdracht.

Orders rapen/Orderpicking is een toepassing binnen RetailVista Mobile en loopt qua licenties mee in het aantal mobiele toepassingen

• Nog in ontwikkeling: Gestuurd orders rapen/Guided orderpicking (kan gezien worden als een lichte WMS oplossing)

Met de module “Magazijn” is het al mogelijk om locaties in het magazijn te definiëren. Voor de winkel is dit nu ook mogelijk. Door het vastleggen van locaties wordt het order raap proces veel efficiënter doordat er geraapt kan worden op volgorde van artikelen/locaties. Bij gestuurd orders rapen kan een medewerker meerdere reserveringsopdrachten tegelijkertijd door elkaar rapen. De pda geeft raapinstructies van één of meerdere reserveringen achter elkaar. Deze worden instructie voor instructie afgewerkt. Meerdere medewerkers kunnen tegelijkertijd met dezelfde reserveringsopdracht bezig zijn.

Orders rapen/Orderpicking is een toepassing binnen RetailVista Mobile en loopt qua licenties mee in het aantal mobiele toepassingen

- RetailVista schermen voor orderpicking types, carriers/dragers en afkeur redenen – Taak 19812 (versie 21.1.7675.30807)   

Ten behoeve van ondersteunde orderpicking zijn hulptabellen gemaakt in RetailVista voor de type orderpicking, de dragers en de afkeur redenen als een orderpicking instructie niet uitvoerbaar is.

De order picking types zijn bedoeld om verschillende soorten picking strategieën aan te maken, zoals discrete order picking, wave order picking etc.

De dragers tabel zijn de kratten/containers waarin reserveringen geraapt kunnen worden.

De afkeur redenen zijn een vooraf aangemaakte collectie van mogelijke redenen waarom een instructie niet uitgevoerd kan worden.

Als er behoefte is om te werken met ondersteunde orderpicking dan kan het beste contact opgenomen worden met de verkoop afdeling van NedFox.

- Gold SLA   

Aanvullend op RetailVista SLA: Gold SLA

Er kunnen zich situaties voordoen waarbij RetailVista niet functioneert zoals zou moeten waardoor de bedrijfsvoering stokt en u dit zo snel mogelijk aangepakt wilt hebben. In ieder geval sneller dan nu in het RetailVista SLA vastgelegd is.

Gold SLA is een aanvulling op het RetailVista SLA en RetailVista SLA SupportPlus (Weekend support) contract. Indien u het Gold SLA contract afgesloten heeft en het proces dat van belang is voor de bedrijfsvoering blokkeert of niet werkt zoals het zou moeten dan is de responstijd van de NedFox helpdesk 1 uur na aanmelding van het probleem.

De volgende tabel wordt gebruikt bij het bepalen van de prioriteit  

Indien u meer informatie wenst over één of meerdere van bovenstaande punten neemt u dan contact met ons op. Telefoon +31 (0)527 249 900 of mail info@nedfox.nl

RetailVista update

===========

Algemeen - diversen

-----------------------

- Omgeving ondersteuning – Taak 19429 (versie 20.17.7584.27682) + Taak 19813 (versie 21.1.7675.30807)

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 de te gebruiken printers 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 A4 printers worden aangemaakt onder Administratie – Printers.

De Windows printer naam is te vinden door in het Windows zoekscherm printers in te typen en dan op Printers en scanners te klikken. Er komt dan een overzicht van de printernamen.

Bridge printen is nu een aanvulling op en op termijn de vervanging van LocalServices. LocalServices wordt gebruikt om te printen naar labelprinters, om met een datacollector te kunnen werken en om prijscheckers te configureren. Met LocalServices is het alleen niet mogelijk om documenten te printen naar A4/pagina printers. Daarvoor is bridge printen nodig.

Met bridge printen kunnen op dit moment verkooporders, copy verkooporders en reserveringen geprint worden. Er kan ingesteld worden dat de verkooporder op een printer in de winkel geprint wordt en een copy verkooporder op een printer die in het kantoor staat. En dit printen kan vanuit de backoffice van RetailVista en vanuit de nieuwe versie van RetailVista Mobile.

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 zal 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 altijd eerst de afdruk op het scherm getoond te krijgen en daarna via een truc de Windows printer te kiezen. Rapportages kunnen straks direct zonder verdere tussenkomst naar een bridge printer worden geprint. De bridge printer is feitelijk de opvolger van RetailVista LocalServices waarbij dus niet alleen thermische printers ondersteund worden, maar ook A4/pagina printers.

Over Bridge printen is QA740 gemaakt. Deze vindt u in het documentenscherm van het hoofdmenu van RetailVista.

- IP restricties per mobiel apparaat (RetailVista Mobile) – Taak 19631 (versie 21.4.7733.20801)

Bij mobiele apparaten kan ingesteld worden dat IP restricties voor bepaalde terminals niet van toepassing zijn. Er was een tijdelijke workaround zodat IP restricties voor Mobile helemaal niet gelden. Dat is vanaf nu weer ongedaan gemaakt: als IP restricties actief zijn, dan gelden die vanaf nu dus ook voor mobiele apparaten/RetailVista Mobile.

Belangrijk is om bij deze update de mobiele apparaten uit te zoeken die buiten het netwerk gebruikt worden (dan wel 3G/4G) en die te markeren dat er geen IP restricties op gelden. Als dat niet gedaan wordt zullen die scanners melden dat RetailVista niet bereikbaar is vanwege IP restricties.

- Tabel voor uitgaande mail – Taak 19896 (versie 21.2.7692.27627)

Uitgaande emails (al dan niet verstuurd) worden in een tabel “Uitgaande emails” geplaatst. De redenen hiervoor:

• Externe CMS partijen kunnen hier vrij makkelijk op inhaken en de emails omzetten naar een definitieve layout en versturen aan consumenten.

In dat geval wordt door RetailVista geen opgemaakte email content klaargezet maar slechts

“metadata”. Hiermee kan een externe partij de email definitief samenstellen.

• Er ontstaat door deze nieuwe tabel inzicht in de verstuurde (of nog te versturen) emails. Iets wat voorheen niet mogelijk was.

• Op dit moment worden hier emails voor geactiveerde cadeaukaarten en definitieve bezorgplanningen weergegeven

Uitgaande emails zijn te vinden onder Administratie – blok Algemeen – optie Outbound Emails

In RetailVista zal op termijn instelbaar zijn welke soorten emails door RetailVista zelf verstuurd gaan worden en welke dus overblijven voor een externe partij. Op dit moment verstuurt RetailVista zelf nog niet vanuit deze tabel. Het is voor nu uitsluitend bedoeld voor externe CMS partijen om deze email uit te lezen en werkelijk te versturen.

Op dit moment worden alleen aangemaakte/uitgegeven RetailVista cadeaukaarten geplaatst in de uitgaande email tabel, zodat een klant hiervan een nette email kan ontvangen. Op korte termijn worden de definitief geplande bezorgingen van de bezorg administratie daar nog aan toegevoegd. Op termijn zal elke uitgaande email van RetailVista via dit systeem gaan verlopen (denk bijvoorbeeld aan digitale facturering, maar ook simpele zaken als een wachtwoord herstel email etc.).

- Valuta symbool – Taak 19991 (versie 21.5.7734.25822)

In de valuta tabel kan een valuta teken opgegeven worden. Waar op verschillende plekken in RetailVista nog een euro of dollar teken wordt aangetroffen zal deze vervangen gaan worden door dit valuta teken.

Voorheen:

Nu:

Indien u zelf valuta toevoegt dan dient u het symbool zelf in te voeren.

Artikel onderhoud

-------------------- -

- Zoeken op “bestelcode” nu ook bij niet-voorkeurleverancier/-inkoopgegeven – Taak 19262 (versie 21.4.7733.20801)

Bij het zoeken van artikelen wordt bij gebruik van de bestelcode nu niet meer alleen gezocht op voorkeur inkoopgegevens. Ook de niet-voorkeur inkoopgegevens worden nu meegenomen bij het zoeken van artikelen. Hierdoor zijn meer artikelen vindbaar dan voorheen.

- Artikel kunnen markeren als “verwijderd” – Taak 19428 (versie 21.3.7706.25430)

Artikelen kunnen nu worden gemarkeerd als “verwijderd”. In het tabblad “algemeen” kan een vinkje geplaatst worden bij “verwijderd”.

Door een artikel als verwijderd te markeren wordt het artikel standaard niet meer gevonden bij zoekopdrachten. Alleen administrators kunnen in het artikel zoekscherm nog kiezen voor de optie “Zoeken op verwijderde artikelen ja/nee/alles”. Hierdoor kunnen administrators een verwijderd artikel weer eenvoudig ongedaan maken. Verwijderde artikelen zijn niet meer bruikbaar bij de nieuwe aanmaak van gegevens, bijvoorbeeld verkooporders, artikellijsten etc. In de kassa kunnen verwijderde artikelen niet meer verkocht worden.

Vanuit artikellijsten kunnen in bulk artikelen als “verwijderd” worden gemarkeerd. Hiervoor is een nieuwe export mogelijkheid gemaakt van artikellijsten naar verwijderde artikelen.  

- Winkelmand groep op te geven – Taak 19914 (versie 21.2.7692.27627)

Bij een artikel kan nu een winkelmand groep opgegeven worden. Hiermee kan bij bepaalde artikelen worden ingesteld dat ze in de webshop niet in combinatie met artikelen uit andere winkelmand groepen worden besteld. Behalve bij een artikel kan ook bij de artikel categorie een winkelmand groep opgegeven worden.

Deze groepen zijn gemaakt omdat het logistieke proces via de module “Verkooporders” voor verschillende artikelen dermate afwijkend kan zijn dat dit niet in 1 verkooporder proces af te handelen is.

Een voorbeeld: Er is een winkelmand groep “Evenementen”. Hierin kunnen alleen artikelen (tickets voor evenementen) verkocht worden. Als een klant een aantal artikelen op de webshop koopt, inclusief een evenementen ticket dan komt er een melding dat dit niet in één order aan te schaffen is. De klant zal dan 2 webshop transacties moeten doen.

Verdere uitleg over winkelmand groepen is opgenomen bij paragraaf “Webshop - Winkelmand groepen - Taak 19909”

- Bulk mutaties inkoopgegevens: Verwerking nu via opgegeven criteria – Taak 19775 (versie 21.6.7741.28554)

Bij bulk wijzigen van inkoopstatus met opgave van leverancier én opgave van 1 artikel kreeg alle inkoop van dit artikel de opgegeven status. Door de artikelselectie viel de leverancierselectie weg. Dat is met deze taak opgelost zodat alleen de inkoop van de opgegeven leverancier van dit artikel een statuswijziging krijgt.

Menu: Artikelen – Bulk mutaties inkoopgegevens

Artikellijsten

-------------- -

- Duidelijker scherm bij artikellijst naar levering op rekening – Taak 19101 (versie 21.1.7675.30807)

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.

Etikettering

------------- -

- Prijs per ISO eenheid toegevoegd voor etiket layout – Taak 19884 (versie 21.2.7692.27627)

RetailVista kan op etiketten de prijs per ISO eenheid printen, bijvoorbeeld € 4,95/LTR en rekent dan de normale bruto verkoopprijs en opgegeven gewicht om naar een prijs per bruto of netto eenheid. Dit staat ook beschreven in QA 754.

Er zijn nu 2 extra velden beschikbaar gemaakt zodat er niet meer onderscheid tussen gewicht of inhoud vermelding in de etiket layout gemaakt hoeft te worden.

De nieuwe velden zijn:

• grosspricepergrossunit

• grosspricepernetunit

grosspricepergrossunit: Dit veld geeft de bruto prijs en ISO eenheid info op basis van gewicht als

gewicht info beschikbaar is.

grosspricepernetunit: Dit veld geeft de netto prijs en ISO eenheid info op basis van gewicht of

(als gewicht niet opgegeven is) per netto inhoud.

Als het gewicht opgegeven/beschikbaar is dan wordt de eenheidsprijs per gewicht vermeld. Is het gewicht niet opgegeven, dan wordt bij het netto veld automatisch de netto inhoud info gebruikt.

Financiële exports

-------------------- -

- AFAS: apart veld voor aanbetaling tegenboeking referentie – Taak 19956 (versie 21.5.7734.25822)

Ten behoeve van automatisch en handmatig afletteren in AFAS wordt de referentie informatie bij een grootboek mutatie nu in een apart referentie veld aangeboden aan AFAS.

Inkooporders

--------------- -

- Filter zoekscherm “Inkooporder wel/niet geprint” – Taak 19742 (versie 21.1.7675.30807)

Inkooporders die worden gemaakt vanuit dropshipment verkooporders krijgen direct de status “Definitief”. Het was echter lastig om uit te zoeken welke inkooporders vervolgens nog geprint moesten worden. Met deze aanpassing kan in het zoekscherm gefilterd worden op wel of niet geprinte inkooporders.

- Inkooporder zoeken op “aangemaakt door scanner” – Taak 19804 (versie 21.1.7675.30807)

In het inkooporder zoekscherm kan nu ook gezocht worden op inkooporders die aangemaakt zijn door een bepaalde scanner.

Kasverantwoording

--------------------- -

Niet gebruikte kassa hoeft niet geteld te worden – Taak 19970 (versie 21.7.7748.30738)

Als er gewerkt wordt met een vaste openingskas werd bij elke kassa altijd opnieuw weer een vaste openingskas geplaatst. Daardoor moest die kassa geteld worden.

In de kasverantwoording instellingen kan nu ingesteld worden dat een ongebruikte kassa niet geteld hoeft te worden. Door het activeren van deze instelling in combinatie met een vaste openingskas wordt op een ongebruikte kassa automatisch een geteld bedrag ingevuld wat exact gelijk is aan de openingskas. Daardoor hoeft zo'n kassa dus niet meer geteld te worden. Er is bewust gekozen om dit gedrag instelbaar te maken en expliciet te moeten activeren. Immers: het feit dat een kassa niet gebruikt is wil niet betekenen dat het eindbedrag nog steeds in de lade zit.

Instelling: Extra – Extra/Instellingen – Sectie Kasverantwoording – Tab Algemeen

Magazijn

---------- -

- Filter zoekscherm op een specifiek artikel – Taak 19803 (versie 21.1.7675.30807)

In het magazijn informatie scherm kan nu ook gefilterd worden op een specifiek artikel.

Promoties

----------- -

- Bijwerken bestaande kortingen via artikellijst – Taak 19936 (versie 21.4.7733.20801)

Bij het omzetten van een artikellijst naar kortingen kan in het omzetting scherm worden gekozen wat er gedaan moet worden met eventueel reeds bestaande kortingen. Er kan gekozen worden om altijd een nieuwe korting aan te maken of om bestaande kortingen bij te werken. Ook is er de mogelijkheid om bestaande kortingen te verwijderen.  

Ontvangsten

--------------- -

Magazijnverschillen scherm duidelijker – Taak 19810 (versie 21.8.7758.20716)

Er zat weinig tekst verschil tussen magazijn tellingen en magazijn verschillen.

Beide schermen zijn hernoemd en worden nog vertaald.

Oud: Magazijn verschillen → Nu: Packing slip verification (= Pakbon controle)

Oud: Magazijn tellingen → Nu: Import scanner slip verifications (= Scanner tellingen)

De menukeuze voor pakbon controle is verplaatst en zit nu direct onder de eerste artikel ontvangst menukeuze.

Promoties

----------- -

- Mixedmatch artikel meerdere keren toevoegen met verschillende barcode – Taak 19758 (versie 21.7.7748.30738)

Voor o.a. de ViridiCode is het gewenst dat een zelfde artikel meerdere keren aan dezelfde mixedmatch toegevoegd kan worden, maar dan wel met telkens een andere barcode. Hierdoor kunnen verschillende partijen steeds worden toegevoegd aan dezelfde mixedmatch. Vanaf nu is dit mogelijk gemaakt.

Statistiek

----------- -

- Artikelstatistiek: Zichtbaarheid inkoopprijs volgt beveiligingsrol – Taak 19689 (versie 21.1.7675.30807)

De zichtbaarheid van inkoopprijzen is een recht wat ingesteld kan worden in RetailVista. Vanaf nu zijn veel overzicht-grids opgeschoond zodat die data echt niet meer zichtbaar is. Belangrijkste scherm daarvan was artikel statistiek.

Als een gebruiker geen recht heeft om inkoopprijzen te zien, dan zal het genereren van inkooporders vanaf nu ook niet meer mogelijk zijn. De inkoopprijzen zijn daar immers essentieel, en als iemand die niet kan zien dan kan die persoon ook geen inkooporders genereren.  

- Oorspronkelijke verkoopordernummer is statistiek 236: Statistiek per verkoopregel – Taak 19700  (versie 21.1.7675.30807)

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 referentie kan een match worden gemaakt naar de originele verkooporder.  

- Nieuwe statistiek 112: Statistiek uitgebreid per artikelcategorie en artikelgroep – Taak 19890 (versie 21.5.7734.25822)

Dit wat een statistiek rapportage die er nog niet was.

- Artikelstatistiek: Periodeselectie op tab “Ontvangsten” – Taak 19921 (versie 21.3.7706.25430)

De periode selectie in de artikel statistiek werd nog niet toegepast op de regels in het tabblad “'Ontvangsten”. Dat wordt nu wel gedaan.  

Verkooporders/Reserveringen

--------------------------------- -

- Fiscaal land opgeven bij verkooporder - Taak 19025 (versie 20.17.7584.27682)

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 fiscale land kan via een BI tool (zoals bijvoorbeeld Qlik) of later in een nog te ontwikkelen statistiek de omzet per land worden berekend. Het fiscale 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 fiscale land aanwezig is, dan valt RetailVista terug op het standaard BTW tarief. Dat is het BTW tarief van het land van de vestiging.

Het is nu dus mogelijk om de BTW verrekening per land aan te geven.

- BTW vrijgesteld indicatie op verkooporder muteerbaar - Taak 19037 (versie 20.17.7584.27682)

Bij het muteren van een verkooporder kan de BTW vrijgesteld indicatie nu worden 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 e.d. wel verloren (worden opnieuw bepaald), immers de bruto prijs veranderd waardoor de kortingen ook niet langer geldig zouden zijn.

- Verkooporder classificatie uitgebreid met voorwaarden wel/niet toepassen dropshipment - Taak 19495 (versie 20.17.7584.27682)

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.

- Set “hoofd artikel” toegevoegd aan eerst mogelijke reservering – Taak 19524 (versie 20.17.7584.27682)

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

Dit speelt alleen als er gewerkt wordt met afdelingen voor het rapen van orders. Reserveringen worden dan gesplitst 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 dit scenario kan een hoofd artikel ook een afhaal locatie krijgen en zal deze dan automatisch aan de juiste reservering worden toegevoegd.  

- Automatisch verlagen aanbetalingsverzoek bedrag bij aanmaak of bijwerken reservering - Taak 19525 (versie 20.17.7584.27682)

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 dan 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.

- Instelling automatisch op rekening zetten – Taak 19535 (versie 20.17.7584.27682)

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 op rekening (omzet/verkoop van de reservering) en daarmee het sluiten van de bijbehorende verkooporders.

Indien er geen WMS koppeling is dan is dat ongewenst omdat daar onbedoeld reserveringen direct verkocht worden én ook nog eens ongewenst op rekening worden gezet. Hier is het maar de vraag of een reservering al verkocht moet worden, en zo ja, of je er dan voor kiest om dat op rekening te doen. Dat is een handmatige keuze op het moment dat de reservering klaar staat. Bovendien wordt de reservering nu gesloten waardoor de klantenservice 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 gewenst is om van een reservering automatisch een levering op rekening te maken, dan moet dat ingesteld worden in de verkooporder classificatie.  

- Bij vervallen verkooporder niet automatisch ook alle regels laten vervallen – Taak 19545 (versie 20.17.7584.27682)

Als een verkooporder vervallen gemarkeerd werd, 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 vervallen zijn gemarkeerd in overleg met de klant. Maar als automatisch alles vervallen gemarkeerd wordt is niet meer zichtbaar 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.

- Melding bij onvoldoende voorraad om te reserveren – Taak 19676 (versie 21.3.7706.25430)

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.

- Verkooporder dashboard – Taak 19683 (versie 21.3.7706.25430)

Vanuit een verkooporder kan via het linker taak menu nu een verkooporder dashboard pagina gestart worden. Dit scherm toont zoveel mogelijk informatie over de verkooporder, aanbetalingen, gekoppelde inkooporders, reserveringen en de uiteindelijke omzet (contant/levering op rekening) daarvan.

Als de inkooporder is doorgezet als interfiliaal order naar een andere vestiging, dan wordt de structuur van de andere vestiging (verkooporders, inkooporders etc.) ook als informatie getoond.

Als de verkooporder, die het gevolg is van een interfiliaal bestelling, op een andere vestiging wordt geopend dan wordt automatisch terug gesprongen naar de originele verkooporder op de andere vestiging waar de hele logistieke verwerking ontstaan is.

- Afleveradres toevoegen vanuit verkooporder – Taak 19686 (versie 20.17.7584.27682)

Het muteren van een afleveradres 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 afleveradres bij de relatie opgeslagen.

- Autorisatie op heropenen verkooporder – Taak 19703 (versie 20.17.7584.27682)

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

- Reserveringen met logistieke status vanaf “wordt geraapt” niet verwijderen bij heropenen verkooporder – Taak 19704 (versie 20.17.7584.27682)

Bij het heropenen van een verkooporder kan aangegeven worden dat openstaande reserveringen verwijderd mogen worden. Dit gebeurt vanaf nu alleen nog voor reserveringen waarvan de logistieke 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.

- Gekoppelde reserveringen worden niet verwijderd bij sluiten verkooporder – Taak 19713 (versie 20.17.7584.27682)

Vanaf nu worden bij sluiten van verkooporders niet meer automatisch alle nog openstaande reserveringen verwijderd. Tot nu werd dat wel gedaan: 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. Het is aan het magazijn om na het sluiten van een verkooporder te beslissen over de nog aanwezige openstaande reserveringen.

- Opgeven classificatie bij importeren offerte – Taak 19732 (versie 20.18.7591.29798)

Bij het importeren van een offerte vanuit een verkooporder moet nu ook een verkooporder classificatie opgegeven worden. Die bepaalt voor een belangrijk deel hoe de verkooporder gevuld en opgebouwd wordt.

Een offerte doorzetten naar een verkooporder kan vanuit:

• Offerte onderhoud. Na selecteren van een offerte links in het scherm bij blok “Export taken” de optie “Offerte naar verkooporder”

• Offerte menu: Naar verkooporder

- Gekoppelde taken inzichtelijk – Taak 19739 (versie 21.4.7720.18568)

Bij een reservering is een nieuw tabblad “Taken” toegevoegd. Hier zijn alle taken te zien die betrekking hebben op die reservering. Een belangrijke taak is het automatisch printen van de orderpicking rapportage. De taak die dit doet resulteert onder andere in een PDF en op die manier is de PDF snel terug te zien.  

- Direct vanuit verkooporder reserveren – Taak 19753 (versie 21.1.7675.30807)

Vanaf nu is het mogelijk om direct vanuit de verkooporder artikelen te reserveren. Hiervoor is een nieuw tabblad “reserveren” ontstaan. Daarin worden alle openstaande en qua voorraad reserveerbare verkooporder regels getoond en kan heel eenvoudig gereserveerd worden. Uiteraard biedt deze pagina ook de mogelijkheid om de voorraad te negeren en “hard” te reserveren ongeacht voorraad.  

- Status van reservering aan te geven via artikel ontvangst – Taak 19762 (versie 21.1.7675.30807)

In de verkooporder classificatie kan nu ingesteld worden wat de logistieke status moet zijn van reserveringen die zijn aangemaakt vanuit een artikel ontvangst.

Voorheen werd de logistieke status in deze situatie op “Wachten op rapen” gezet. Maar als gebruik gemaakt wordt van het automatisch printen van orderpicking rapportages dan moet de logistieke status “Nieuw” zijn. Die wordt dan na het printen automatisch omgezet naar “Wachten op rapen”.  

- Muteren verkooporder BTW indicatie – Taak 19785 (versie 21.1.7675.30807)

Er zijn de nodige aanpassingen gemaakt om van een verkooporder de BTW indicatie te kunnen muteren.  

- Verkooporder classificatie: Afhaal locatie instelbaar – Taak 19826 (versie 21.1.7675.30807)

Bij reserveringen kan tegenwoordig aangegeven worden wat de afhaal locatie is (niet te verwarren met de afleg locatie), de locatie waar de reservering op te halen is. Bij showroom orders kan het gewenst zijn om altijd met een vaste afhaal locatie te werken, bijvoorbeeld “winkel”. Standaard krijgt een reservering de afhaal locatie van de vestiging toegekend. Vanaf nu is het mogelijk om bij een verkooporder classificatie een aangepaste afhaal locatie in te stellen. Die zal dan worden toegepast bij het aanmaken van de reservering.  

- Reserveringen vervallen bij vervallen verkooporder – Taak 19828 (versie 21.1.7675.30807)

Bij het laten vervallen van een verkooporder worden vanaf nu ook automatisch de gekoppelde reserveringen die nog niet verkocht zijn vervallen gemarkeerd. Als de reservering al verkocht is, dan gebeurd dat niet en moet er handmatig een besluit genomen worden wat er moet gebeuren met de reservering (bijvoorbeeld retour nemen). Door deze aanpassing kan een verkooporder bij aanmaak nog heel eenvoudig vervallen gemarkeerd worden. Alle bijbehorende reserveringen worden dan ook vervallen gemarkeerd. Is er echter inmiddels al een reservering verkocht, dan wordt die reservering genegeerd. Reserveringen die vervallen zijn worden in het verkooporder scherm gemarkeerd met een 'x' teken.  

- Gewenste leverdatum meegenomen naar inkooporder bij dropshipment – Taak 19857 (versie 21.1.7675.30807)

De gewenste leverdatum uit de verkooporder wordt vanaf nu overgenomen naar de gewenste leverdatum in de inkooporder, mits de verkooporder een dropshipment bestelling is. In dat geval wordt namelijk elke verkooporder 1:1 overgezet naar een inkooporder, in plaats van het zogenaamde “intellen” op bestaande inkooporders. Door deze aanpassing kan de inkooporder naar de leverancier worden verstuurd en is daar bekend op welke datum een consument de bestelling graag zou willen ontvangen.  

- “Verwachte leverdatum” wordt “gewenste leverdatum” – Taak 19858 (versie 21.1.7675.30807)

Er is een belangrijke wijziging doorgevoerd in de data velden in de verkooporder. Voorheen bestond er een veld “verwachte leverdatum”. Dat veld op die plek in verkooporders is verwarrend omdat een verwachte leverdatum bij een reservering thuis hoort. Een klant kan bij het schrijven van een order hooguit een gewenste leverdatum opgeven. In de praktijk bleek in veel gevallen dat het veld “verwachte leverdatum” ook gebruikt en gevuld werd als “gewenste leverdatum”. Vanaf nu is er een nieuw veld “gewenste leverdatum”. Daar kan een klant een voorkeur/gewenste datum opgeven. Of er op die datum geleverd wordt is natuurlijk nog maar de vraag.

De verwachte leverdatum bestaat nog wel maar is standaard niet meer beschikbaar. In de instellingen van “Verkooporders” (Extra – Instellingen – Verkooporders – tab Geavanceerd) kan de verwachte leverdatum nog worden aangezet. In dat geval zal de gewenste leverdatum niet beschikbaar zijn.

De reden dat het veld “verwachte leverdatum” nog bestaat heeft te maken met diverse integraties die nog uitgaan van het bestaan van dit veld. In de 2021 najaarsupdate van RetailVista zal het veld “verwachte leverdatum” definitief verwijderd worden uit RetailVista. Het is dus belangrijk om indien u integraties met andere software heeft uw software leverancier te informeren dat dit veld vanaf dat moment niet meer bestaat en dat integraties moeten worden omgebouwd naar het nieuwe veld “gewenste leverdatum”.

De gewenste leverdatum wordt ook overgezet naar inkooporders in geval van dropshipment verkooporders.

- Nieuwe optie voor direct reserveren aantal type – Taak 19867 (versie 21.7.7748.30738)

Bij artikel categorieën kan nu ingesteld worden dat op bepaalde categorieën nooit voorraad bijgehouden wordt.

- Status “Definitief en in behandeling” niet meer mogelijk – Taak 19878 (versie 21.2.7692.27627)

Er heeft een belangrijke wijziging plaatsgevonden in de status van verkooporders. De status “definitief en in behandeling” bestaat niet meer en is vervangen door “Definitief”. Alle orders die voorheen stonden op “Definitief en in behandeling” zijn nu teruggezet naar “Definitief”.

Met ingang van deze versie weet RetailVista de koppeling tussen verkooporders en inkooporders. Per verkooporder regel is bekend aan welke inkooporder regel(s) deze regel is toegevoegd. Het verschil met voorheen is dat als een inkooporder nu gesloten wordt terwijl er nog items bij die leverancier nodig zijn in openstaande verkooporders, dan worden die verkooporder regels automatisch opnieuw besteld. En dat blijft net zo lang doorgaan totdat het gewenste artikel geleverd wordt, of totdat de verkooporder wordt aangepast of gesloten/vervallen gemarkeerd.

!! Als er nu nog openstaande verkooporders bestaan in uw RetailVista omgeving die al lang geleverd zijn, sluit die orders dan definitief. Dat kan relatief vlot via de startpagina “Verkooporders” en kies dan voor “Sluit verkooporders”. Als dit NIET gedaan wordt, dan zullen elke keer bij het genereren van inkooporders vanuit verkooporders de nog openstaande regels automatisch opnieuw besteld worden.

Belangrijk is hier verder om op te merken dat het bestellen van inkooporders vanuit verkooporders automatisch plaats kan vinden (via de taakplanner), of “handmatig” vanuit de startpagina “Verkooporders” - “Genereer inkooporders”.  

- Track & Trace code doorgeven aan afzender vestiging – Taak 19918 (versie 21.3.7706.25430)

In het NedFox xml pakbon bericht worden vanaf nu ook de track & trace codes doorgegeven. Als het pakbon bericht op een andere RetailVista vestiging aankomt dan wordt de track & trace info bij de artikel ontvangst (shipment reference, verzending referentie) overgenomen. Dit geldt voornamelijk bij dropshipment bestellingen vanuit de ene RetailVista vestiging naar de andere.  

- Set artikel prijsverdeling over onderliggende onderdelen – Taak 19927 (versie 21.3.7706.25430)

Er heeft een belangrijke wijziging plaatsgevonden in de manier waarop set artikelen werken. De prijs van een set artikel wordt naar rato (draagkracht) verdeeld over de onderliggende artikelen. Voorheen was het zo dat de prijs van het set artikel daarna niet meer veranderd kon worden en op 0 kwam te staan. Als je de prijs wilde aanpassen dan moesten de prijzen van de onderliggende artikelen aangepast worden. Vanaf nu is het zo dat de prijs van het set artikel blijft bestaan (uiteraard wordt op het set artikel geen omzet gemaakt) en muteerbaar blijft. De prijs van de onderliggende artikelen wordt ten allen tijde berekend en is daarom ook niet meer muteerbaar. Door deze wijziging is het veel eenvoudiger geworden om achteraf de prijs van een set nog te wijzigen. Iets wat voorheen bijna niet mogelijk was. Ook het omzetten van een verkooporder van ex- naar in- btw (en andersom) is door deze aanpassing nu mogelijk geworden.  

- Per pakketdienst instelling automatisch aanmelden – Taak 19950 (versie 21.4.7720.18568)

Sommige pakketdiensten (waaronder Sendcloud) rekenen geld per aangemaakt etiket. Het is maar de vraag of je uiteindelijk wel echt wilt gaan versturen via Sendcloud. Dat kan nog afhangen van de omvang van het pakket, maar soms ook van de bezorgdatum. Door direct een etiket aan te maken bestaat de kans dat de bezorgdienst eind van de dag al voor de deur staat, terwijl het pakket misschien pas later verstuurd mag worden. Om die reden is vanaf nu bij een pakketdienst  instelbaar of auto-aanmelding gewenst is. NB: Tekst wordt nog vertaald.

- Status “Gereed” voor webshop verkooporders – Taak 19976 (versie 21.4.7733.20801)

Bij de verkooporder classificatie kan nu worden aangegeven welke verkooporder status een order moet krijgen als die ontstaat vanuit een webshop order.  

- Winkelmand groep instelling voor verkooporder classificatie – Taak 19980 (versie 21.4.7733.20801)

Bij het onderhoud van de winkelmand groepen kan nu optioneel een verkooporder classificatie worden ingesteld. Als die ingesteld is en er wordt een webshop order bericht ontvangen met de winkelmand groep aanduiding, dan wordt automatisch de classificatie van de winkelmand groep aan die verkooporder gekoppeld. Daardoor kunnen bepaalde soorten winkelmandjes tot speciale classificaties leiden, wat tot bepaald gedrag kan leiden. Het is hiermee bijvoorbeeld mogelijk om horeca orders te maken waarvan de order picking rapportage direct en automatisch op een printer geprint wordt.  

- Hoge prioriteit inkooporder bij omzetten verkooporder naar inkooporder – Taak 19982 (versie 21.4.7733.20801)

Bij het omzetten van verkooporders naar inkooporders kan in de verkooporder classificatie nu ingesteld worden dat inkooporders met hoge prioriteit moeten worden gemaakt. Als die instelling actief is zal er eerst gezocht worden naar inkooporders met hoge prioriteit. Wordt een openstaande hoge prioriteit inkooporder gevonden dan worden de verkooporder regels aan die inkooporder toegevoegd. Wordt er geen inkooporder met hoge prioriteit gevonden, dan wordt een nieuwe inkooporder aangemaakt met hoge prioriteit.  

Administratie – blok “Artikelen” – Verkooporder classificaties:

- Genereren reservering nu via taak – Taak 19988 (versie 21.4.7733.20801)

Het genereren van reserveringen verloopt vanaf nu via een taak. Het voordeel daarvan is onder meer dat er een verslag aanwezig is hoe het genereren proces verlopen is.  

- Zoeken op reserveringen die wel of niet (volledig) geraapt zijn – Taak 20014 (versie 21.7.7748.30738)

In het tabblad “Regels” in reserveringen onderhoud kan nu gekozen worden voor het tonen van de reservering regels die wel of niet (compleet) geraapt zijn.

Voorraad

---------- -

- Gealloceerde voorraad kunnen verwerken - Taak 19610 (versie 20.18.7591.29798)

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.

- Andere opzet Derving - Taak 19733 (versie 20.18.7591.29798)

Derving werkte tot voorheen alleen via levering op rekening. Echter dit klopt niet. Het is geen vorm van omzet. En er hoort ook geen debiteur bij. Door deze opzet was het heel lastig om bijvoorbeeld in artikel statistiek het aantal stuks derving te tonen.

Ook het registreren van derving was lastig vanwege het verplicht op moeten geven van een relatie en debiteur, en het voorkomen dat er een wildgroei aan leveringen op rekening zou gaan ontstaan.

Om die reden is derving opnieuw ontworpen en gaan derving registraties nu naar een aparte tabel (derving). In RetailVista Mobile is het nu veel eenvoudiger gemaakt om derving aan te maken.

Als onderdeel van deze herziening is een nieuwe tabel “Type derving” gemaakt (Menu: Administratie – blok Artikelen – 4e blad: Derving types). Daar kan een onderscheid worden gemaakt in bijvoorbeeld eigen gebruik, diefstal en andere mogelijke vormen van derving. Ook kan in die tabel bij elk type derving worden opgegeven of een aanvullende omschrijving/toelichting verplicht is.

In de artikel statistiek kaart wordt het aantal stuks derving als veld nu getoond voor de twee

opgegeven periodes.

Vanuit artikellijsten en leveringen op rekening is de mogelijkheid gemaakt om deze te exporteren naar derving.

Vanuit artikellijst:

- Derving grid/overzicht uitgebreid - Taak 19829 (versie 21.1.7675.30807)

De derving grid is uitgebreid met de kolommen voorraad, vrije voorraad, winkel voorraad, locatie voorraad, leverancier nummer, naam (Voorkeur leverancier in Grid sjabloon), en de naam van de gebruiker die de derving aangemaakt heeft. De laatste is in het scherm “Grid sjabloon onderhoud” de regel “Aangemaakt door”.

In de zoek filters kan nu ook gezocht worden op leverancier en op gebruiker die de derving aangemaakt heeft.

- Gealloceerde voorraad terugboeken - Taak 19830 (versie 21.1.7675.30807)

Vanuit de verkooporder kan gealloceerde voorraad nu heel makkelijk en snel worden teruggeboekt naar de winkel/reguliere voorraad. In de linker taakbalk is een snelkoppeling gerealiseerd om gealloceerde voorraad terug te boeken. Een artikel waarvan geen vrije voorraad is kan normaal gesproken (afhankelijk van de verkooporder classificatie instelling) niet gereserveerd worden. Als van dat artikel nog een artikel in de gealloceerde voorraad zit (bijvoorbeeld showroom voorraad) dan is het door deze aanpassing nu eenvoudig om dat artikel uit de gealloceerde voorraad te verwijderen. Daardoor gaat de vrije voorraad omhoog en is het artikel alsnog reserveerbaar.

- Artikelstatistiek: Tab “Gealloceerde voorraad” - Taak 19856 (versie 21.1.7675.30807)

In het tabblad “algemeen” in de artikelstatistiek wordt al de gealloceerde voorraad vermeld. In het nieuwe tabblad “Gealloceerd” wordt een uitsplitsing van de gealloceerde voorraad getoond. Daarmee wordt zichtbaar hoe de gealloceerde voorraad verdeeld is.

Webshop

---------- -

- Meerdere printers te gebruiken bij pakketdienst integratie – Taak 19419 (versie 20.17.7584.27682)

Het is nu mogelijk om meerdere printers in te stellen voor het printen van pakketdienst etiketten. Bijvoorbeeld een printer per kassa terminal.

Dit gaat via 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 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.

Dit is in te stellen onder “Administratie” – Blok “Algemeen” – “Omgevingen”  

- Webshop code in xml webshop order bericht - Taak 19835 (versie 21.1.7675.30807)

Voor partijen die via de Retail3000 API integratie zelf direct webshop berichten afleveren, is het mogelijk gemaakt om in het XML bericht een webshop code aan te geven. Hierdoor wordt de verkooporder die ontstaat uit het order bericht direct gekoppeld aan de juiste webshop. Hierdoor zal bij de uiteindelijke verkoop van de reserveringen uit de verkooporder de webshop gekoppeld worden aan de omzet en kloppen de statistieken. Voor partijen die gebruik maken van de ShopServer speelt dit probleem op zich niet omdat een ShopServer in RetailVista al gekoppeld is aan een webshop. Maar ook in dat geval zal een eventuele webshop code in het XML bericht alsnog leiden tot het vastleggen van die webshop in de verkooporder.

De webshop code is een nieuw veld in het XML bericht. Via de gebruikelijke kanalen kunnen wij third party ontwikkelaars hierover verder informeren.

- Webshop koppeling licentie controle - Taak 19877 (versie 21.1.7675.30807)

Per webshop waarvan informatie naar de webshop moet en orders terug naar RetailVista gestuurd worden is een Webshop koppeling licentie nodig. Bij de verwerking van webshop order berichten bestond nog geen controle op het aantal actieve webshops in combinatie met de aanwezige licentie. Als er meer webshops actief zijn als het aantal licenties (Webshop CALS) dan worden er vanaf nu in het geheel geen orderberichten meer verwerkt. Opmerking: Wij tellen het aantal webshops en kunnen geen onderscheid maken in webshops. Stel u heeft 3 webshops en wil van 2 webshops dat de orders naar RetailVista gaan. Daar kunnen wij geen filter op zetten. Wij weten dus niet voor welke webshop in feite geen licentie bestaat en daarom zal bij onvoldoende licenties de hele verwerking stagneren.

De webshop bouwer kan uiteraard wel zorgen dat orders van een specifieke webshop niet naar RetailVista gestuurd worden.

Mocht dit probleem optreden dan is dat vrijwel per direct oplosbaar door webshops “vervallen” te markeren die er nieuw bij gekomen zijn en waarvoor geen licentie opgave gedaan is. Het aantal actieve webshops moet door deze handeling weer overeenkomen met het aantal webshop CALS uit de licentie. Het is dan wel zo dat eventuele orderberichten voor vervallen webshops afgekeurd zullen worden. De uiteindelijke oplossing is het verzoek om even contact op te nemen met onze verkoop afdeling om de juiste licenties af te nemen.

- Shopserver integratie end-of-life - Taak 19908 (versie 21.4.7733.20801)

Bij het aanmaken van een webshop is het niet langer verplicht om ShopServer info op te geven. De ShopServer is een additionele toepassing die lang niet altijd gebruikt wordt bij webshop koppelingen. Er wordt niet langer door ontwikkeld op de ShopServer, deze is met ingang van deze release end-of-life en alleen bestaande functionaliteit zal nog onderhouden en ondersteund worden. Nieuwe toepassingen (zoals bijvoorbeeld de winkelmand groepen) worden geen onderdeel meer van de ShopServer. Nieuwe webshop integraties worden bij voorkeur ontwikkeld direct op de Retail3000 API.

- Winkelmand groepen - Taak 19909 (versie 21.3.7706.25430)

Vanaf nu is het mogelijk om winkelmand groepen aan te maken in RetailVista (basket groups). Met deze functionaliteit kan aangegeven worden dat bepaalde artikelcombinaties in één winkelmandje ongewenst zijn. Denk bijvoorbeeld aan het bestellen van horeca artikelen waarbij het niet gewenst is dat daar ook overige “hardwaren” artikelen tegelijkertijd in mee besteld worden. Het is qua verwerking bij de horeca afdeling erg ongewenst dat ze daar opeens andere artikelen aan een horeca bestelling zouden moeten toevoegen. Door winkelmandje groepen te gebruiken kan er afgedwongen worden dat er separate orders ontstaan voor bijvoorbeeld horeca bestellingen, maar denk ook aan graszoden, evenementen etc. Aan de winkelmand groep kan een aparte verkooporder classificatie gekoppeld worden, zodat bijvoorbeeld een horeca order een aparte behandeling krijgt en direct op de juiste printer bij de horeca afdeling belandt.

De winkelmand groepen functionaliteit is alleen bedoeld om uitzonderingen aan te geven, dus “bijzondere” artikelen die beslist niet samen met normale artikelen tegelijkertijd in één order besteld mogen worden. Per artikel categorie kan een winkelmand groep aangegeven worden. Daarnaast is het mogelijk om per artikel nog af te wijken via die instelling en/of eventueel stuk voor stuk bijzondere artikelen te markeren.

De webshop die gekoppeld is aan RetailVista zal de winkelmand groepen uiteraard wel moeten gaan ondersteunen en in het webshop order bericht moet de eventuele winkelmand groep wel meegestuurd worden.

Winkelmand groepen: menu “Administratie” – blok “Algemeen” – Winkelmand groepen/Basket groups.

In ontwikkeling / Langere termijn ontwikkelingen

===============================

Naast bovenstaande releasepunten is onze ontwikkelafdeling ook bezig met modules of onderdelen die meer tijd vragen. Met onderstaande onderdelen zijn wij op dit moment bezig:

- Bezorgadministratie   

Reserveringen die ontstaan vanuit verkooporders worden uiteindelijk aangemeld in de bezorgadministratie. Via een dashboard kunnen reserveringen gepland worden voor bezorging. Dit kan bezorging met eigen voertuigen zijn maar ook aanmelding bij SendCloud.

De reserveringen worden dan in “ritten” gepland.

Als een rit definitief gemaakt is worden optioneel de ritten aangemeld bij SendCloud en stickers geprint. Via Garden Connect / CMS ontvangen klanten emails over de bezorgplanning, track & trace codes etc.

- SendCloud koppeling

Sendcloud is een verzendplatform voor e-commerce. Vanuit RetailVista wordt een koppeling gemaakt met de verzendsoftware van Sendcloud. In Sendcloud zijn diverse vervoerders opgenomen waardoor er keuze is in vervoerders.

- Loyaliteit Plus   

Loyaliteit Plus is een uitbreiding op de Spaarkaart module.

Via Loyaliteit Plus worden in eerste instantie artikelen met korting verkocht onder afboeking van een bepaald aantal spaarkaart punten.

De analyse welke kortingstypen ontwikkeld moeten worden wordt met meerdere partijen gedaan.

Loyaliteit Plus functionaliteit wordt transactiegebaseerd verrekend.

- Spaaza koppeling   

Spaaza is een platform om (gepersonaliseerde) loyaliteitsprogramma’s op te zetten.

Vanuit RetailVista wordt een koppeling gerealiseerd