Februari 2021

VERSIE: 6.0.20210201.xx t/m 6.0.20210228.xx

INHOUDSOPGAVE

ALGEMEEN

Functionele wijzigingen

1. Korting over korting mogelijk maken bij actie op bontotaal

LET OP!: Deze aanpassing in de actiemodule is op dit moment alleen nog maar van toepassing op acties in de categorie "Actie op Bontotaal".

Door de storesetting AllowDiscountOverDiscount op true te zetten komt er in de actiemodule van ASPOS bij het bewerken van een actie een extra vinkje beschikbaar, "Sta korting over korting toe". 

afbeelding vinkje "Sta korting over korting toe" 

Als dit vinkje aan staat bij de actie op bontotaal dan wordt korting getriggerd (eventueel met toevoeging van een verplichte voucher op het tabblad extra) op het moment dat het bonbedrag de drempel waarde behaalt ingevuld bij bontotaal. Deze korting gaat ook af over producten op de bon waar al een korting voor is berekend. 

Zodra het vinkje "Sta korting over korting toe" aan staat in de actie wordt de bontotaal korting berekend als een bonkorting en komt er onder de transactie een regel te staan met de verleende korting.


Zoals in onderstaand voorbeeld te zien is, is de Actie op bontotaal actief met het vinkje Sta korting over korting toe aan.

Bij een besteding van minimaal € 25,00 en de inlevering van een voucher krijgt de consument een korting van € 25,00.

Ook is er een actie actief op het eerste product op de bon, deze is oorspronkelijk € 10,00 maar door de actie is deze nog maar € 5,00. Omdat het vinkje korting over korting aan staat wordt de actie op bontotaal getoond als een bonkorting. 

afbeelding korting over korting actie in de POS.

Bugfixes

Aanpassing gemaakt op de POS dat dimensieartikelen in 4 cijfers achter de komma worden weer gegeven.

2.  POSAddReceiptLineMemo werkt niet als er een klantorder wordt opgehaald in de POS

Ticket 961364

Fix geïmplementeerd waarbij de memo's niet werden getoond bij het ophalen van een klantorder in de POS. 

ASPOS KASSA

Functionele wijzigingen

RFC 18023

Aanpassing gemaakt in de POS die het mogelijk maakt om na het scannen van een retourbarcode op de kassabon de producten achter elkaar door te scannen. Er wordt op dat moment maar 1 keer om een retourreden gevraagd die vervolgens bij alle overige artikelen in de retourtransactie worden opgeslagen. De barcode die gebruikt moet worden bij het retourscannen is de barcode die opgeslagen is in de originele transactie.

2. Kleur indicatie na pinnen Fout/Goed

RFC 18314

Aanpassing gemaakt in de pinkoppeling zodat bij een betaling die op de Pinterminal wordt afgerond als akkoord de pop-up van de pintransactie een groene rand krijgt en een pinbetaling die niet akkoord is een rode rand. Als de storesettings en rechten goed staan voor het retourpinnen wordt ook bij een geslaagde retourpin transactie de rand van de Pop-up groen. Deze groene rand komt bij de vraag om handtekening melding.

Bugfixes

Ticket 962243

Aanpassing gemaakt op de POS zodat een bedrag van bijvoorbeeld -2000 niet van het scherm van de POS valt.

2. POS crasht bij het afslaan van kas uit transactie

Ticket 964834

Fix gemaakt, zodat de POS niet meer crasht bij het afhandelen van een kas uit transactie. 

3. POS: het afhaalbewijs toont verkeerd bedrag bij kitartikelen

Ticket 963651

Fix gemaakt zodat bij de kit artikelen de juiste prijs wordt weergeven op de afhaalpakbon.

4. 100% korting op een bon gaat niet goed

Bug gefixed in de POS zodat 100% bonkorting ook verrekend wordt als er bestelde artikelen op de Bon staan.

ASPOS BACKOFFICE

Rapportage's

Functionele wijzigingen

1. Facturatietaak: transactiedatum gebruiken voor factuurdatum

Bij een aantal van onze klanten loopt er in de nacht een facturatietaak. Om er voor te zorgen dat alle pakbonnen van de dag ervoor gefactureerd worden en de bijbehorende transacties (inclusief omzet als sprake is van het kasstelsel) ook nog op die dag vallen, worden deze transacties geantedateerd. In dergelijke gevallen passen we nu dan ook de factuurdatum aan op de nieuwe transactiedatum.

2. Nieuw rapport klantorder details.

Door bij een gebruiker het beveiligingsrecht "Klantorder details" aan te zetten wordt, in de klantordermodule onder de rapportages, de rapportage Klantorder details beschikbaar.

Op deze rapportage staan de volgende gegevens in de header:


De volgende velden worden getoond in de Productregel.


Bugfixes

In het rapport Factuur overzicht werd bij factuurbetalingen de betaalsoort niet getoond. 

Producten

Functionele wijzigingen

Ticket 951956

Aanpassing gemaakt zodat in de mailtemplate voor de inkooporder, de gegevens uit de inkooporder meegestuurd kunnen worden als platte tekst. In het template moeten deze regels tussen de tags <!--[PURCHASEORDERLINE]--> vallen. 

Velden die worden ondersteund zijn:

Deze velden ondersteunen we vanuit de header:


SupplierStreetName

SupplierHouseNumber

SupplierHouseNumberExtension

SupplierPostalCode

SupplierCity

SupplierCountryCode

SupplierCountry

SupplierPhoneNumber

SupplierFaxNumber

SupplierDefaultEmailAddress

SupplierOrderEmailAddress

SupplierContactPerson

StoreCode

StoreName

StoreStreetName

StoreHouseNumber

StoreHouseNumberExtension

StorePostalCode

StoreCity

StoreCountryCode

StorePhoneNumber

StoreFaxNumber

StoreEmail

StoreTaxNumber

StoreCoCNumber

StoreBank

StoreWebsite

StoreFullStreetName

PurchaseOrderNr

Description

DebtorCode

Remarks


En deze velden ondersteunen we uit de regels:

ProductNumber

SupplierProductCode

ProductDescription

PurchaseUnitDescription

Factor

TotalQuantity

NettPurchasePrice

PurchasePrice

ScanCode

PromotionID

ABC

ProductQuantity

LineRemarks


Als Voorbeeld template kan de volgende HTML tekst worden gebruikt:

<html>

   <head> </head>

   <body >

      Aan leverancier:<br /> <!--[%CompanyName%]--> <br /> <!--[%SupplierStreetName%]--> <br /> <!--[%SupplierHouseNumber%]--> <!--[%SupplierHouseNumberExtension%]--> <br /> <!--[%SupplierPostalCode%]--> <!--[%SupplierCity%]--> <br />

      <p>

         In de bijlage de inkooporder <!--[%PurchaseOrderNr%]--> met status: <!--[%StatusDescription%]-->.

      </p>

      <table>

         <tr>

            <th>Bestelcode</th>

            <th>Omschrijving</th>

            <th>Aantal</th>

            <th>Inkoopeenheid</th>

            <th>Prijs</th>

         </tr>

         <!--[PURCHASEORDERLINE]-->

         <tr>

            <td height="10">

               <!--[%SupplierProductCode%]-->

            </td>

            <td height="10">

               <!--[%ProductDescription%]-->

            </td>

            <td height="10" style="text-align:center;">

               <!--[%ProductQuantity%]-->

            </td>

            <td height="10" style="text-align:center;">

               <!--[%PurchaseUnitDescription%]-->

            </td>

            <td height="10" style="text-align:right;">

               &euro; <!--[%PurchasePrice%]-->

            </td>

         </tr>

         <!--[PURCHASEORDERLINE]-->

      </table>

      <p>

         Met vriendelijke groet,<br /> <!--[%StoreName%]--> <br /> <!--[%StoreFullStreetName%]--> <br /> <!--[%StorePostalCode%]--> <!--[%StoreCity%]--> <br /> <!--[%StorePhoneNumber%]--> <br />

      </p>

   </body>

</html>


2. Matrixartikelen worden ook centraal getrokken als moeder- of kindproduct centraal worden getrokken

Ticket 944836

Aanpassing gemaakt in de manier waarop producten worden opgeslagen, op het moment dat een lokaal product op een andere winkel wordt opgeslagen wordt er een regel weggeschreven in het beveiligingslog waarmee wordt aangegeven dat het product is verplaatst naar het centrale niveau. Ook worden hiermee, in het geval van Matrixen en Matrix-artikelen, alle artikelen naar het centrale niveau verplaatst.

3. Het vinkje bij Incl. lokaal blijft bij uitgebreid zoeken wordt niet onthouden na het openen en opslaan/annuleren van een product

Ticket 963451

Aanpassing gemaakt waardoor het vinkje bij incl. lokaal wordt onthouden in productbeheer.

Bugfixes

Bug gefixed waardoor de BTW verdeling over 0% BTW nu ook goed gaat als de standaard verdeling op 0 staat. 


Fix doorgevoerd die ervoor zorgt dat aantal bij barcode, in de import nu ook goed gaat via de interface


Ticket 962186

Bug gefixed zodat na het openen van een artikel het ordertype in het besteladvies niet meer wijzigt en het de bestelsessie niet vastloopt.


Fix geïmplementeerd zodat bij het kopiëren van een product een controle wordt uitgevoerd of de gebruiker de juiste rechten voor de subgroep heeft. 

Gebruikers

Functionele wijzigingen

Binnen ASPOS is in het gebruikersbeheer de mogelijkheid gemaakt om een gebruiker te kopiëren. Als de gebruiker waarmee je inlogt het recht "Medewerkers toevoegen/wijzigen" actief heeft heb je ook de mogelijkheid tot kopiëren. Als je gebruik maakt van de kopiëren knop zal hetzelfde scherm worden geopend als wanneer je een nieuwe medewerker toevoegt met als verschil dat het tabblad beveiliging is gevuld met de gebruikersrechten die zijn ingevuld bij de gebruiker waar een kopie van is gemaakt.

Bugfixes

--Geen noemenswaardige  wijzigingen--

Menu's kassa

Functionele wijzigingen

--Geen noemenswaardige functionele wijzigingen--

Bugfixes

1. Bug, zelfde Intralotsessie controltabs uitsluiten

Bug gefixed in de nieuwe Intralot koppeling die het mogelijk maakte om op 2 bonnen in de POS dezelfde sessie in te laden 

Instellingen

Functionele wijzigingen

Aanpassing gemaakt die ervoor zorgt dat als de storesetting POSPrintGCActivation op True staat dat er per geactiveerde giftcard een activatiebewijs wordt geprint i.p.v. 1 activatiebewijs voor alle giftcards samen. 

2. Meerede Channelengine omgevingen binnen 1 Aspos omgeving

Het is nu mogelijk om meerdere ChannelEngine omgevingen te koppelen aan 1 ASPOS omgeving.

Dit kan je verzorgen door onder instellingen - Generic settings meerdere ChannelEngine configuraties op te nemen.

De configuratie is hiervoor uitgebreid met 'ProductsWebnode'


Hiermee bepaal je welke webknoop uitgelezen moet worden om de producten naar ChannelEngine te bepalen. Als deze niet bestaan vallen we terug op de standaard webknoop 'CHANNELENGINE', de as-is situatie. Letop! deze webnodecode moet uniek zijn in de omgeving, als er meerdere bestaan met dezelfde code dan pakken we de eerste die we tegenkomen waardoor je als gebruiker niet 100% zeker weet of de juiste wordt gepakt. Tevens mogen beide omgevingen niet de orders naar dezelfde vestiging in ASPOS versturen dat wordt bepaald in het stuk 'PlatformMappings'.


Verder werkt de koppeling volledig as-is en gaat dus per configuratie de producten versturen/orders ophalen/orders afmelden.


Voorbeeld config:

<GenericSettings>


<ChannelEngine ApiKey="XXXXXXX" AccountName="YYYYYYY">

<ProductsStore Code="340" />

<ProductsWebnode Code="ChannelOW" />






<Stock>






<Free>






<Store Code="340" />






</Free>






<Safety>






<Store Code="340" />






</Safety>






<UnprocessedReceivings>






<Store Code="340" />






</UnprocessedReceivings>






<Interstore>






<Store Code="340" />






</Interstore>






</Stock>






<PlatformMappings>






<Platform Name="QQQQQQQQQQQQQQQQQQQ" Store="340" />






</PlatformMappings>






<DeliveryCostProduct Code="375029" />






<DefaultPaymentType Code="145" />






</ChannelEngine>




</GenericSettings>


Bugfixes

1. Betaalsoort aanpassen toont niet de juiste overervingsgegevens

Bij het aanpassen van een betaalsoort moet geselecteerd worden voor welke winkels die aanpassingen gelden. Als er een winkel geselecteerd werd zonder overerving, dan werd niet teruggevallen op het onderliggende niveau, maar op de stamgegevens.

2. Rework beheer grootboekrekeningen: check op type uit de code halen

Ticket 964602

Fix geïmplementeerd waarbij de foutmelding "Type niet correct" niet meer tevoorschijn komt bij het invoeren van een grootboekrekening. 

EVL Beheer

Functionele wijzigingen

--Geen noemenswaardige functionele wijzigingen--

Bugfixes

Geen noemenswaardige wijzigingen--

Financeel

Functionele wijzigingen

RFC 14871

Met het gebruikersrecht Toon Transactiedetails krijg je de mogelijkheid om in het transactie beheer de transactie details te bekijken. 

Hiermee wordt er een nieuw scherm geopend waarop de transactiedetails staan zoals ze in de database zijn opgeslagen. 

Bugfixes

--Geen noemenswaardige wijzigingen--

Klanten

Functionele wijzigingen

Het is nu mogelijk om via de SMS template, die wordt verstuurd als een order opgehaald kan worden, de leverdatum en tijd mee te geven. Dit was al mogelijk binnen de email variant.


Voorbeeld template:

''Uw bestelling met ordernummer [ORDERNR] ligt klaar. Ophalen kan op [DELIVERYDATE] tot één uur na [DELIVERYTIME]." 

2. Verzamelorder direct starten zonder aantal 'weborderscollectquantity' aan te passen

RFC 18382

Aanpassing gemaakt in de werking van het handmatig verzamelen van klantorders. De storesetting WebOrdersCollectQuantity wordt nu, bij het handmatig verzamelen, gebruikt om Per een X aantal orders of regels te verzamelen in plaats dat dit het minimum aantal orders of regels aangeeft die verzamelt mogen worden.


kleine opfrisser hoe het handmatig verzamelen in zijn werk gaat.


Binnen de klantorder module van ASPOS is een nieuwe knop toegevoegd die getoond wordt als een gebruiker het recht "Orders Handmatig Verzamelen naar DC" en de storesetting "WebOrdersManualCollect" op true staat. 

Ook moet er op de omgeving de taak COLLMANUALCOSEL draaien.



Hier kun je met een dropdown alle onderliggende magazijnen selecteren waar de storesetting WebOrdersManualCollect op true staat.

In de Pop-up wordt ook weergegeven om hoeveel orders, regels en daadwerkelijke producten het gaat die verzameld gaan worden. 

Met de storesetting CollectPickorderOnStore kun je bepalen naar welk magazijn de klantorders verzameld moeten worden.

Er wordt hierbij gekeken naar de gegevens die zijn ingesteld bij de setting WebOrdersCollectQuantity om te bepalen per hoeveel orders of regels de orders verzameld moeten worden.


Bijvoorbeeld:

Bij de storesetting WebOrderCollectQuantity staat 20|0  er staan op dat moment, op winkel X staan er op dat moment 21 orders klaar om te verzamelen.

Je gebruikt de knop Verzamelen en selecteert Winkel X, je druk op Ja om te verzamelen en de taak wordt klaargezet.

Nadat de taak de orders heft opgepakt wordt er 1 Verzamelorder met 20 onderliggende orders klaargezet en 1 verzamelorder met 1 onderliggende order.


Als de klantorders eenmaal verzameld zijn dan gaat de verwerking van de order op de "reguliere manier"


Bugfixes

Ticket 957282

Aanpassing gemaakt in de factuur rapportage van DGN dat een extra spatie in een tekstregel ook juist getoond wordt. 

2. Als het facturen het omzetmoment is dan wordt de kostprijs van verkopen bepaald op het moment van levering en niet op het moment van facturatie

Bug opgelost in het factuurstelsel in ASPOS. Bij de factuur werd in veel gevallen als kostprijs verkopen de actuele VVP gebruikt. Dit is nu aangepast door hiervoor de VVP op het moment van leveren voor te nemen. 

3. Buitenlandse debiteuren werden soms als anonieme debiteur gezien

Bij volledig aanbetaalde facturen die hun oorsprong hebben in internetorders bieden wij de mogelijkheid om al deze debiteuren onder één verzameldebiteurnummer aan te bieden. Dat bespaart tijd in de debiteurenadministratie en voorkomt problemen met AVG.

Voor buitenlandse debiteuren (btw 0% op aankopen) wordt hier nu een uitzondering voor gemaakt. Deze facturen komen vanaf nu altijd met het eigen debiteurnummer in de administratie.

Vestigingen

Functionele wijzigingen

RFC 14831

Binnen ASPOS is de nieuwe integratie van de intralot koppeling gebouwd op basis van Rest Services. Voor deze nieuwe koppeling zijn er, naast de bestaande storesettings, 2 storesettings bij gekomen.

POSIntralotAPIKey : Als er gebruik wordt gemaakt van de V2 dan moet hier de API Key voor de koppeling worden ingevuld.

POSIntralotVersion : Om gebruik te maken van de nieuwe versie moet hier V2 komen te staan.


Verder moeten de bestaande intralot storesettings goed worden ingevuld.


IntralotBarcodeLength : De lengte van de barcode op het sessieticket

IntralotBarcodePrefix: De Prefix van de barcode op het sessieticket

IntralotEnabled : deze moet op True staan om gebruik te maken van de intralot koppeling.

IntralotTerminalID : het Terminal ID van de Intralot Terminal.

IntralotURL : Het Endpoint waarmee gecommuniceerd moet worden.


Voor test zien de settings er als volgt uit:

Als al deze settings correct zijn ingevuld kan er gebruik worden gemaakt van de koppeling tussen de intralot terminal en de POS.

Op het moment dat er een of meerdere sessies zijn klaargezet op de intralot terminal kun je de Sessies ophalen op 2 manieren.

2. De andere manier om een sessie op te halen op de POS is door het scannen van een sessieticket, dit zal resulteren in het product of de producten die in de sessie zijn klaargezet die op de Bon komen te staan.


Afbeelding sessie gescand op de POS: 

Op het moment dat de sessie wordt verwijderd van de bon zal deze weer worden vrijgegeven waarna deze opnieuw gescand kan worden of opgehaald door gebruik te maken van de sneltoets ALT+i. Als er een sessie op de bon staat met meerdere regels erin kun je de sessie verwijderen door de complete bon te annuleren of door 1 regel weg te halen. Als er 1 regel van een sessie wordt weggehaald zal de complete sessie van de bon verwijderd worden en wordt de complete sessie weer vrij gegeven.


Afbeelding melding 1 regel verwijderen: 

Het is niet mogelijk om de prijs aan te passen van artikelen uit een sessie, ook is het niet mogelijk om een bon met een intralot sessie in de wacht te zetten, hievan zal de POS melding geven.

Afbeelding melding niet mogelijk bon in de wacht te zetten: 

Handelingen die verder worden afgevangen in de POS zijn:

Afbeeldingen Meldingen POS voor het afvangen van handelingen:

Als er een Intalotsessie wordt gestart op de POS zal deze melding worden weggeschreven in het beveiligingslog in ASPOS. In deze melding is te zien om welke sessie het gaat, vanaf welke terminal deze sessie komt en naar welk endpoint deze sessie gestuurd wordt. Ook is in deze melding het JSON bericht te zien wat vanaf intralot opgestuurd wordt, op deze manier is het duidelijk leesbaar om wat voor soort sessie het gaat.

Afbeelding Melding in beveiligingslog: 

Bugfixes

-Geen noemenswaardige wijzigingen--

Acties

Functionele wijzigingen

Binnen ASPOS was er al een nieuwe implementatie voor acties met wicht artikelen als de prijs uit de barcode gehaald wordt. Met deze nieuwe aanpassing wordt dit ook ondersteund als de barcode van het wichtartikel het gewicht bevat in de barcode.

Om gebruik te maken in ASPOS van barcodes met het gewicht erin verwerkt moet de storesetting POSPriceByBarcode op False staan, ook moet de storesetting PriceBarCodes gevuld zijn met bijv. AAAAAAACWWWWC|AAAAAACWWWWWC.

Met de storesetting DiscountShowKind op True  krijg je bij het aanmaken van een actie, in de actiemodule van ASPOS, op het tabblad extra een dropdown te zien met actiesoort. In deze dropdown staan nu alleen nog maar de soorten "Standaard" en "Weegschaal".  Default staat de actiesoort op "Standaard"

Als je een actie wilt instellen op een wicht artikel i.c.m. een wicht barcode moet het actie soort op weegschaal staan, deze actiesoort werkt alleen in combinatie met een actie in de categorie product. Mocht er bijvoorbeeld een mixmatch worden aangemaakt en de actiesoort wordt op "Weegschaal" gezet dan krijg je de volgende melding bij het opslaan van de actie. 

Bij de inrichting van de actie, met categorie product en actiesoort weegschaal, wordt maar 1 staffel ondersteund. Wel kan er gekozen worden voor het type bedrag of percentage. 

Een actie voor een wichtartikel met een prijs per kilo van €2,50 voor €1,00 zal er als volgt uitzien:

Om ervoor te zorgen dat de juiste actieprijs wordt berekend op de POS na het scannen van een wichtartikel zal er op de omgeving een taak moeten lopen. De taak WEIGHTDISCOUNTPRICES, deze taak kijkt of een actie met actiesoort Weegschaal actief en lopend is waarna de prijs die ingevoerd is (of het kortingspercentage)  wordt ingevoerd bij de actieprijs van het product. 

Als de actie niet meer actief is of de looptijd is verstreken zal deze actieprijs weer leeggehaald worden, mocht de actieprijs per ongeluk handmatig leeggehaald of aangepast worden dan zorgt de taak ervoor dat de juiste actieprijs weer ingevoerd wordt.


Als er aan deze inrichting is voldaan zal het uiteindelijke resultaat op de POS er als volgt uit zien. De prijs die de consument moet gaan betalen wordt berekent op basis van het gewicht uit de barcode maal de verkoopprijs. In het geval dat de klant 1,5 KG zal kopen zal de wichtbarcode er als volgt uit zien 8712340015000, de POS zal eerst de reguliere prijs uitrekenen (dus 1,5*2,50=3,75) en daarna de korting verrekenen op een aparte regel (1,5*1,00=1,50) het verschil tussen deze 2 bedragen wordt getoond op de kortingsregels. Dit wordt dus 3.75-1.50 = 2.25 korting.

In de transactie in ASPOS wordt de korting ook weergegeven, zodat duidelijk is hoeveel korting er gegeven is. 

Let op: 

Bugfixes

-Geen noemenswaardige wijzigingen--

Kas- en kluisbeheer

Functionele wijzingen

---Geen noemenswaardige functionele wijzigingen--

Bugfixes

Geen noemenswaardige wijzigingen--

WIFI ASPOS

Functionele wijzigingen

---Geen noemenswaardige functionele wijzigingen--

Bugfixes

Ticket 957668

Bug gefixed waarmee de inkoopwaarde op de PDA die getoond wordt via de franco knop dezelfde berekening aanhoudt als de inkoopwaarde die getoond wordt in de backoffice in een bestelsessie.

WEBSHOP

Functionele wijzigingen

RFC 17236

Aanpassing gemaakt in de Channel Engine koppeling die ervoor zorgt dat een retourorder (die verwerkt is naar pakbon) vanuit ASPOS naar Channel Engine wordt gestuurd. Ook is het mogelijk om de voororders van een retour uit Channel Engine op te halen door in de GenericSettings de tag HandleReturns Code op True te zetten. Als deze op True staat dan worden retouren die aangemeld zijn in Channel Enige als retourorder in ASPOS gezet.

Bugfixes

Geen noemenswaardige wijzigingen--

SERVICES

Functionele wijzigingen

--Geen noemenswaardige functionele wijzigingen--

Bugfixes

Geen noemenswaardige wijzigingen--