Release Notes versie 3.42 GD Product Management

Transcriptie

1 Release Notes versie 3.42 GD Product Management Versie 2.00 GD Venlo, december 2009

2 Inhoudsopgave 1 INLEIDING TECHNISCHE ISSUES Requirements Update instructie Instructies bij calamiteiten Compatibiliteit met lagere versies! TOELICHTING DOCUMENTINDELING TOELICHTING NOTATIES BLUERETAIL BEGRIPPEN BLUERETAIL GEWIJZIGDE EN NIEUWE FUNCTIONALITEITEN Verkoop Wijzigingen kassajournaal Versnelling bepalen of kassa definitief geteld is Verwijderingsbijdrage ( ) Retourscannen kassabon Kortingscouponnen ( ) Inkoop Relatie-notities tonen Inkooporder op basis van afleverdatum ( ) Logistiek Case Voorraadprognose ( ) Case Multimagazijn ( ) Case Printen Crediteuren Pakbon ( ) Diverse uitbreidingen met de HHT Case Uitbreiding artikelexport naar HHT met instelling voor verkoop- en handelsprijs ( ) Financieel Case Boekstuknummer ( ) Service Retail CRM Rapportage (Applicatie) Beheer Aanpassingen artikel-beheer Uit Collectie (CASE ) Bewaren focus op invoervelden na wisselen tabblad Opschonen temp-mappen NWKM en NWAUTO Aanpassingen menu Scrollbalken tabellen op Zoeken-tabblad gewijzigd Export historie overzicht Intern nummer HK zichtbaar onder dealer-code BUGS 1 Uitvoer instructie!! Deze BlueRetail installatie moet absoluut dedicated gedraaid worden met betrekking tot de BlueRetail database, omdat er mogelijk een database conversie moet kunnen worden uitgevoerd. Dit houdt in dat: De automatische procedures niet mogen draaien De eventuele database back-up NIET mag worden uitgevoerd Alle werkstations (server, info-points, kassa s en overige werkstations) BlueRetail verlaten moeten hebben Er géén andere Newway producten of producten van 3 e die de database kunnen gebruiken gedraaid mogen worden Product Management zal het document updaten zodra daar toe vanuit de Newway Product Portfolio of vanuit enig ander technisch oogpunt noodzaak toe is van 87

3 1 Inleiding Inhoud Aandachtspunt 1 Deze release notes hebben betrekking op de Global Deployed (GD) versie van 3.42 van BlueRetail. In deze release notes worden de belangrijkste wijzigingen beschreven ten opzichte van eerdere versies van BlueRetail en zijn bedoeld om klanten en partners inzicht te verschaffen in de wijzigingen en nieuwe functionaliteit van BlueRetail. Let op!! Deze versie is de opvolger van BlueRetail Deze versie bevat: - Alle patches uitgebracht op 3.31 d,3,40 & 3.41 na de release van BlueRetail Nieuwe functionaliteit 3.42 zie hoofdstuk 6 - Deze versie kan niet meer converteren vanuit KassaMatic. - Deze versie zal vanuit de MMS voucher, niet meer volledig compatibel zijn met versies 2.xx of lager. Aandachtspunt 2 Eerdere release notes zijn op te vragen bij Newway of te raadplegen in de map documentatie op de installatie CD-Rom. De release notes zijn met de grootst mogelijke zorg samengesteld, mochten er toch fouten in voorkomen dan biedt Newway u bij voorbaat haar excuses daarvoor aan. Newway accepteert géén schadeclaims als gevolg van eventuele fouten in de release notes. Er kunnen géén rechten worden ontleend aan de inhoud. Vragen Bij eventuele vragen betreffende deze release kunnen Newway eindgebruikers contact opnemen met de desbetreffende Newway Business partner of met de afdeling Product Management via adres productmanagement@newway.nl van 87

4 2 Technische issues Type update Prioriteit Grootte update X X ± 40 MB Kopieslag Patch verz. Update Upgrade Servicepack Urgent / Spoed Hoog Gemiddeld Laag Nader te bepalen Reboot nodig JA NEE Backup nodig JA NEE Rollback functionaliteit JA NEE 2.1 Requirements Installatie voorwaarden Deze versie kan geïnstalleerd worden als opvolger van BlueRetail 3.41 GD. De bestandconversie zal geheel automatisch worden uitgevoerd. Indien de uitvalmodule aanwezig is en geactiveerd is en het pakket is conform de Newway richtlijnen geïnstalleerd, dan zal op het lokale netwerk werkstation geheel automatisch het pakket worden geüpdated en de bijbehorende database conversie van de uitval database geschieden van 87

5 Hyperfilemutaties In 3.42 zijn een flink aantal bestanden (hyperfiles) gewijzigd als gevolg van de nieuwe module Multimagazijn. Hiervoor was het noodzakelijk om 2 extra linkvelden te definieren in de transactie- en voorraad-bestanden. Dit betekent dat er rekening gehouden moet worden met een lange database-conversie tijd. Afhankelijk van het aantal transacties dat in het bedrijf aanwezig zijn. ARTIKEL AR Artikelen CCRKOP C2 Crediteuren creditnota's kop CCRLEV L5 Leveringen crediteuren creditnota's CCRREG C5 Crediteuren creditnota regels CFAKOP C0 Crediteuren factuur kop CFALEV LR Leveringen crediteuren facturen CFAREG CR Crediteuren factuur regels CORLEV L6 Leveringen crediteuren orders CORREG C6 Crediteuren order regels CPALEV L7 Leveringen van crediteuren pakbonnen CPAREG C7 Crediteuren pakbon regels DCRREG D5 Debiteuren creditnota regels DFAREG D1 Debiteuren factuur regels DORREG D6 Debiteuren order regels IMPGOED IM Importeren goederenregels KASREG K0 Debiteuren kassa regels MUTTABR M3 Tabel reden van retour MUTTABS M4 Tabel mutatie soort VCOPNAME V3 Voorraadcorrecties VRDOPN VO Voorraadopname VRDOPNAR VK Voorraadopname artikelen VRZREG V2 Debiteur verz.rek. regels In VRDOPN is tevens een extra veld SW_OPNAME toegevoegd. Ten behoeve van de case kortingscoupons is aan de volgende hyperfiles het veld voor een barcode (RETGEBOEKT) toegevoegd: RELATIE RE Relaties Ten behoeve van de case kortingscoupons is aan de volgende hyperfiles het veld voor een barcode (BARCODENR) toegevoegd: KRTTABEL KT Kortingtabellen MIMAKOP MK Mixmatch kop Als gevolg van de redesign van het kassajournaal zijn de volgende hyperfiles flink gewijzigd: KASDAG K2 Dagjournaal KASDIENS K3 Dienstjournaal Ten behoeve van de case Inkooporder op basis van Afleverdatum is er een veld voor de leverbetrouwbaarheid (LEVERBETR) toegevoegd. RELATIE RE Relaties Tot slot is er een STATUSFILEXP toegevoegd aan het AUTOLOG bestand, zodat dit logboek ook in spiegel-omgevingen te bekijken is. AUTOLOG AU Logboek betaalautomaat Nieuwe hyperfiles In 3.42 zijn de volgende hyperfiles toegevoegd aan de analyse als gevolg van de nieuwe module MultiMagazijn: GOEDVERPLAATS GV Goederen verplaatsingen MAGAZIJN MA Magazijnen MAGAZIJNLOCATIE ML Magazijnlocaties VOORRAAD VQ Voorraad per locatie van 87

6 Verwijderde bestanden Bij versie 3.42 hoort een andere FTP-server executable. In voorgaande versies zat een executable, die gemaakt was met Windev7.5. De nieuwe executable is net als de overige executables gemaakt met Windev12, maar functioneel niet gewijzigd. Hierdoor zijn de volgende Windev-DLL s niet meer noodzakelijk, en worden bij een nieuwe installatie dan ook niet meer geïnstalleerd. (Bestaande Dll s worden niet automatisch verwijderd!): De reden voor de wijziging is, dat de oude FTP-server executable problemen gaf met de nieuwere Windows-versies (bv. Windows2008). Dit werd veroorzaakt doordat bovenstaande DLL s niet meer goed werkten. Nieuwe bestanden In de installatie-cd zijn weer de zogenaamde NWF-bestanden toegevoegd, die ervoor zorgen dat er een juiste conversie plaatsvindt van versie 2 naar versie Deze worden door NWCONVERT.EXE aangeroepen. In de versies 3.40 en 3.41 waren deze bestanden helaas niet aanwezig, waardoor de conversie van sommige velden niet goed ging van 87

7 Registermutaties Zijn er registermutaties? Nee Ja Uitleg X N.v.t. Overige mutaties Versie 3.42 is NIET meer compatible met BlueRetail Mobile versies, kleiner dan versie BlueRetail Mobile versie 2.20 wordt tegelijkertijd gereleased met BlueRetail Voor de wijzigingen van BlueRetail Mobile kunt de betreffende release-notes raadplegen. In BlueRetail zelf is de artikel-export gewijzigd, en de benaming van de verschillende te importeren bestanden, die door de BR Mobile aangeleverd worden. 2.2 Update instructie Indien men de HHT-koppeling terminal.bat gebruikt, dan dient deze ook aangepast te worden, met de nieuwe benamingen, zoals deze in de releasenotes van BR Mobile 2.20 te vinden is. Update Maak op de server een back-up van de..\<blueretail software> directory (hierin staat de oude WDL en eventueel de geïnstalleerde patches). De cliënts worden automatisch geüpdate bij opnieuw opstarten van BlueRetail op de cliënts. Let op!!! op de cliënt mogen géén oude/andere patches meer blijven staan Noot!! Zie algemene uitvoerinstructie op de inhoudopgave pagina!! 2.3 Instructies bij calamiteiten Herstellen oude situatie Indien de update niet over een rollback functionaliteit beschikt, is hieronder beschreven, hoe er terug gegaan kan worden naar de situatie voor de update! Stap Handeling 1 Verwijder op de server \<BlueRetail software> en plaats de back-up terug 2 De cliënts worden automatisch geüpdate bij opnieuw opstarten van BlueRetail op de cliënts. Géén reboot nodig. 2.4 Compatibiliteit met lagere versies! Noot!! De BlueRetail versie 3.42 MMS kan communiceren met onderliggende RMS versies: BlueRetail 3.1x BlueRetail 3.3x BlueRetail 3.40 BlueRetail 3.41 Vanaf deze release zal de bestandsuitwisselingen met de New-Way Retail software 2.4x NIET meer verdergaand ondersteund worden van 87

8 3 Toelichting documentindeling Leeswijzer Newway onderscheidt de volgende hoofdprocessen in haar BlueRetail applicatie: 1. Verkoop 2. Inkoop 3. Logistiek 4. Financieel 5. Service 6. Retail CRM 7. Rapportage 8. (Applicatie) Beheer Wanneer voor bepaalde procesonderdelen geen nieuwe functionaliteit is voorzien in deze BlueRetail versie, bevat de desbetreffende paragraaf géén tekst. Contact Voor meer informatie over de BlueRetail Productvisie kunt u contact opnemen met de afdeling Product Management (productmanagement@newway.nl). 4 Toelichting notaties Toetsen Knoppen Programmamenu s Toetsen op het toetsenbord die in de instructie worden gebruikt, worden weergegeven in vetgedrukte hoofdletters en tussen deze tekens < >. Bijvoorbeeld <ENTER>. Een alternatief voor het openen van menu s is om de juiste menupunten met de muis aan te klikken. Knoppen op het beeldscherm waar u met de muis op kunt klikken, worden weergegeven tussen deze tekens [ ]. Bijvoorbeeld [Sluiten]. Een alternatief voor het openen van menu s is om de juiste menupunten met de muis aan te klikken. Programmamenu s worden weergegeven aan de hand van de menupaden. De menupaden worden in vetgedrukte letters weergegeven en tussen deze tekens < >. Bijvoorbeeld, het menu Printerinstelling heeft het menupad <menupad IHP>. Om dit menupunt te openen dient u <Alt> + I en achtereenvolgens H en P in te toetsen. Een ander voorbeeld is het menupad voor de verkooptransacties: <VI>. Om dit menupunt te openen dient u <Alt> + V en vervolgens I in te toetsen. Een alternatief voor het openen van menu s is om de juiste menupunten met de muis aan te klikken van 87

9 5 BlueRetail begrippen POS-kassa of PC-kassa Point of Sale, POS (Front Store) Winkelmanagement, RMS (Back Store) Hoofdkantooor, MMS (Back Office, Head Quarters, Head Office) Multifunctioneelsysteemgebruik Hiermee wordt de kassa hardware bedoeld inclusief retail specifieke randapparatuur. Hiermee wordt bedoeld de verzameling functionaliteiten die worden ingezet op een POS-kassa in rechtstreeks contact met de klant. Naast Point of Sale functionaliteit is dat voor BlueRetail ook de geïntegreerde functionaliteit als Point of Information (Informatiebalie) en Point of Service (Servicebalie voor reparatie, retour, verhuur etc). Hiermee wordt bedoeld de verzameling winkelspecifieke functionaliteiten waarbij het management is betrokken. Het gaat hier om het beheren en controleren van geldstromen, goederenstromen en informatiestromen op de winkelvloer. Als voorbeeld kan gelden: het tellen, afromen en controleren van kasgeld, het beheren van voorraden en assortimenten en het opsporen en voorkomen van diefstal en fraude. Hiermee wordt bedoeld de verzameling winkelondersteunende, technische en organisatorische functionaliteiten. Er kan worden gedacht aan beheer van stamgegevens van artikelen, klanten, personeel, filialen en leveranciers maar ook aan het beheren van de interne informatiestromen (transacties tussen samenwerkende winkels) en externe informatiestromen (transacties met klanten en leveranciers). In vele situaties als de klant een kleine winkel heeft zullen veel rollen door een en dezelfde persoon worden uitgeoefend. Het is dan niet mogelijk om voor elke functionele rol een ander systeem te gebruiken. Logt men in met een andere gebruikerscode, dan schakelt het systeem om naar de functies die bij die rol horen ongeacht op welk systeem men bezig is. Indien men in online (connected) mode werkt, dan zullen alle aanwezige en aangeschafte functies het doen van 87

10 6 BlueRetail gewijzigde en nieuwe functionaliteiten Leeswijzer Onderstaande hoofdstukken corresponderen met het eerder in dit document genoemde Retail Business Model. De afdeling product management van Newway hanteert dit RBM als leidraad voor haar release notes, om daarmee consistentie te verkrijgen in de lay-out van het document. 6.1 Verkoop Beschrijving algemeen In een winkel vindt het contact met de klant plaats langs diverse verkoopprocessen. We onderscheiden hier enkele onderdelen zoals kassa, verkooporder en verkoop(credit)- factuur. Uiteraard zijn er vele nuanceringen mogelijk aan de hand van gedefinieerde verkoopeisen, de producten die verkocht worden en de beleving die de klant dient te ervaren Wijzigingen kassajournaal Algemeen Vanaf 3.42 zijn er weer diverse visuele, functionele en technische aanpassingen gemaakt aan het kassajournaal. Dit was noodzakelijk omdat er al jarenlang een aantal problemen bekend waren, die een structurele wijziging vereisten. De technische aanpassingen heeft betrekking op een betere scheiding tussen omzet-gegevens en gegevens mbt de totale kasmutatie, en een betere registratie van wisselgeld en betalingen. De aanpassingen hebben de consequentie dat na de conversie naar 3.42 kassajournaals, die niet met 3.42 zijn aangemaakt, vreemde informatie zullen tonen. Bij de omzet zal alles gespecificeerd worden onder Artikelen zonder betaling, en bij de totale ontvangsten en uitgaven zullen er ook geen correcte bedragen staan. Er is gekozen om niet alle dagjournaals te converteren, naar de nieuwe werkwijze, omdat dit tijdens de eerste keer opstarten, veel tijd in beslag zou kunnen nemen, als de klant al een aantal jaren met het pakket werkt, en omdat wij vermoeden dat deze gegevens niet meer geraadpleegd zullen worden. Wel is er voor gekozen om de laatste 12 maanden te converteren. Er wordt alles vanaf de eerste dag van de maand van een jaar geleden, geconverteerd, op het moment dat het bedrijf geupdate wordt. Dus als op 14 januari 2010 wordt geupdate, dan worden alle journaals vanaf 1 januari 2009 geconverteerd. Het is altijd nog mogelijk om via NWTool een optie te maken, dat ook de overige dagjournaals geconverteerd worden, mocht in de praktijk blijken, dat dit gewenst is. Functioneel zijn er per tabblad een aantal zaken gewijzigd, die nu per tabblad beschreven zullen worden. Voor alle tabbladen is de volgorde van de getoonde records omgekeerd, net als bij de overige transactie-overzichten, zodat het laatst gemaakte journaal bovenaan staat, maar ook bij het overzicht van bonnen en kasgelden is dit het geval. In de rapporten is ook dezelfde volgorde aangehouden van 87

11 Tabblad Dagtotalen Het tabblad dagtotalen ziet er nu als volgt uit: Voorheen werden bij het openen altijd de laatste 7 dagen getoond, nu kan dit bv. ook de laatste dag of de laatste maand zijn. Nu wordt het verschil tussen de laatst gebruikte waardes voor start- en einddatum per gebruiker bewaard, net als bij de overige debiteuren overzichten. Als het venster met bovenstaande waarden wordt afgesloten, dan zal dus de volgende keer dat het venster geopend wordt, alleen de huidige dag getoond worden. Onderstaande debiteuren-instelling is niet van toepassing voor het kassajournaal: Verder is er een extra filterveld Station toegevoegd, zodat alleen kassajournaals van een bepaald station getoond kunnen worden. Default worden alle stations getoond. Daarnaast zijn de knoppen Dag, Periode en PDF verdwenen. Daarvoor in de plaats is er een knop Afdrukken, met een rechtermuis-optie Afdrukken naar PDF, en een weergave-optie Totalen toegevoegd. Ook de knop Sluiten is weer terug, die in 3.41 door plaatsgebrek verwijderd was. Door het aanvinken van 1 van de weergave-opties wordt de scherm-inhoud aangepast aan de geselecteerde opties. Hierdoor is het dus mogelijk om periodetotalen op het scherm te krijgen, terwijl dit voorheen alleen mogelijk was als afdruk. Ook op de tabbladen Bonnen, Kasgeld en Kortingscoupon worden dan alle gegevens getoond die van toepassing zijn op de aangegeven periode van 87

12 Als de weergave-optie Totalen is aangevinkt, dan is er geen selectie meer mogelijk van de tabel, en wanneer de weergave-optie Vorig jaar is aangevinkt, dan is er geen filter-mogelijkheid meer om de periode aan te passen. De optie Station blijft wel beschikbaar. Er zitten ook geen datum-controles meer op het vinkje vorig jaar. Voorheen verscheen er een melding als het verschil tussen start- en einddatum groter dan 1 jaar was. De startdatum en einddatum wordt altijd 1 jaar teruggezet. Er wordt dus niet gekeken naar weeknummers. Het is dan ook niet mogelijk om bv. de huidige dag (bv. dinsdag) te vergelijken met dezelfde dinsdag van het vorige jaar. Het werkt alleen goed bij periodes van 1 maand of groter. De knop Afdrukken drukt de gegevens af zoals deze op het scherm staan. De rechtermuis-optie Afdrukken naar PDF, blijft net als voorheen per station per dag een PDF-bestand maken. Het resultaat van de afdrukknop is te lezen in bijlage van 87

13 In het rechtergedeelte is weer wat met de gegevens geschoven, en zijn er een aantal nieuwe velden bijgekomen. Dit in verband met de verbeterde scheiding tussen omzet-gegevens en kasmutatie-gegevens. De omzet-specificatie is gebaseerd op de regelgegevens van alle kassatransacties. Hierbij wordt er een onderscheid gemaakt in een 3-tal soorten kassatransactieregels, omdat dit van invloed is op de omzet-bepaling: 1. Artikelregels. Deze doen altijd mee met de omzetbepaling. Deze worden onderverdeeld in regels met en zonder betaling. In de voorgaande versies waren dit de velden Verkoop met betaling, Verkoop zonder betaling, Retour met betaling en Retour zonder betaling bij ontvangsten en uitgaven. 2. Statiegeldregels. Deze doen of wel of niet mee met de omzetbepaling, afhankelijk van de kassa-instelling op het tabblad Dagjournaal: 3. E-Gift opwaarderingen (alleen als module aktief is). Deze doen nooit mee met de omzetbepaling. Voor elk type regel, wordt er een verschil gemaakt tussen verkoop en retour, en de kolom Omzet is het verschil tussen beide. (Behalve bij de totaalregel, omdat niet alle regels mee hoeven te doen in de omzetbepaling!) De kolom omzet bevat alleen een waarde, als het type regel meetelt in de omzetbepaling. Of het statiegeld meedoet in de omzetbepaling is eveneens rechtsonder te zien bij de omzet-totalen. De bepaling wanneer een artikelregel op een kassatransactie nu met betaling is, en wanneer zonder betaling, is afhankelijk van de wijze waarop de kassatransactie betaald is. Hierbij wordt er door BlueRetail een onderscheid gemaakt tussen de volgende 3 situaties: 1. Volledig op rekening (alleen betaalwijzen met dagjournaaltype Rekening). Alle artikelregels worden geboekt bij Artikelen zonder betaling, gesplitst in verkoopregels en retourregels. 2. Volledig NIET op rekening (alleen betaalwijzen met dagjournaaltype ongelijk aan Rekening). Alle artikelregels worden geboekt bij Artikelen met betaling, gesplitst in verkoopregels en retourregels. 3. Gedeeltelijk op rekening (zowel betaalwijzen met dagjournaaltype Rekening als andere betaalwijzen). a. Als de kassatransactie positief is (Totaal incl. > 0), dan wordt alles bij Verkoop geboekt (ook als er retourregels op de bon staan!). Het bedrag dat op rekening is gezet wordt geboekt bij Artikelen zonder betaling, het overige op Artikelen met betalingen. b. Als de kassatransactie negatief is (Totaal incl. < 0), dan wordt alles bij Retour geboekt (ook als er verkoopregels op de bon staan!). Het bedrag dat op rekening is gezet wordt geboekt bij Artikelen zonder betaling, het overige op Artikelen met betalingen. De ontvangsten en uitgaven-specificatie is nu uitgebreid met een aantal nieuwe soorten, en daarnaast wordt er geen gebruik meer gemaakt van transactie-regel van 87

14 gegevens. Voorheen gebeurde dit wel. De opties Verkopen met betaling en Statiegeld, die in 3.41 geintroduceerd zijn, zijn weer komen te vervallen omdat zij hier niet thuishoren. Hierdoor is het ook niet meer mogelijk dat er afrondingsverschillen waren, bij het bepalen van de totale kasmutatie. Voorheen was dit wel mogelijk als gevolg van het afronden op 5 cent. Ontvangst en uitgave-specificatie 3.41 Is in 3.42 vervangen door: Nieuw toegevoegd zijn: - Betalingen Kassa, Is het totaal van alle betaalwijzen, met uitzondering van type Op Rekening, behorende bij positieve kassatransacties (Totaal incl. > 0) - Uitbetalingen Kassa, Is het totaal van alle betaalwijzen, met uitzondering van type Op Rekening, behorende bij negatieve kassatransacties (Totaal incl. < 0) - Ontvangen Wisselgeld, Is het totaal van het ontvangen wisselgeld van negatieve kassatransacties (Totaal incl. < 0) - Uitbetaald Wisselgeld, Is het totaal van het uitbetaalde wisselgeld van positieve kassatransacties (Totaal incl. > 0) - Betalingen Verzamelrekening, Is het totaal van alle betalingen op verzamelrekeningen die vanuit de kassa gemaakt zijn (via F7). Voorheen zaten deze in de post Betalingen Facturen. Tevens worden voor alle nieuwe soorten ook de aantallen bijgehouden. De soort Betalingen Orders, wordt nu ook niet meer verlaagd, indien er orders van een andere dag, in de kassa afgerekend worden. Voorheen, gebeurde dit wel en kon het bedrag zelfs negatief worden. De totale kasmutatie is het verschil tussen de totale ontvangsten en de totale uitgaven. Het bedrag is de waarde van het extra geld, dat er die dag van buitenaf is binnengekomen. Eventuele af- en bijstortingen van en naar de kassa worden niet meegeteld. De nieuwe bepaling van de kasmutatie wordt ook gebruikt tijdens het tellen (BEREKEND IN KAS), alleen wordt daar wel rekening gehouden met de af- en bijstortingen van 87

15 Tabblad Bonnen Het tabblad bonnen ziet er nu als volgt uit: Allereerst is er een kolom datum toegevoegd, die alleen getoond wordt, als op het tabblad dagtotalen de optie Totalen is aangevinkt. Helaas zal deze kolom initieel geheel rechts geplaatst worden vanwege de USERKOLOM-instellingen. Hierdoor lijkt het alsof de kolom niet getoond wordt. Na het verplaatsen van de kolom is dit probleem opgelost. De knoppen raadplegen en dagtotalen zijn verwijderd, en de knoppen ontvangen en uitbetaald, zijn verplaatst en hernoemd naar Betalingen en Uitbetalingen. Rechtsonder zijn toegevoegd het totaal van eventuele af- en bijstortingen en het totaal Openstaande Orderbedrag. Soortgelijke gegevens stonden voorheen op het tabblad dagomzet. Het veld Openstaande Orderbedrag bevat het totaalbedrag van alle in de kassa aangemaakte orders (via F12) alle aanbetalingen die op deze order zijn gedaan (ook buiten de kassa om). Het is de totale waarde van wat men in de toekomst nog aan geld zal ontvangen op de gemaakte orders. Tevens kan men zo ook controleren of het geld van alle orders van de vorige maand reeds ontvangen is. In de tabel met bonnen worden nu ook alle orders getoond (regels met grijze tekst), die in de kassa zijn aangemaakt (via F12). De bedragen van deze orders worden NIET meegeteld bij de totaal-bedragen. Door de toevoeging krijgt men een compleet overzicht van alles wat via de kassa is afgehandeld. De kolom Bonnummer is derhalve vervangen door Bonnr. / Ordernr., tenminste als men de module Verkooporder heeft. Op het rapport van de afdrukknop is de volgorde eveneens gewijzigd, en is de kolom betalingen iets verbeterd, qua mintekens van 87

16 Tabblad Raadplegen Het tabblad Raadplegen is qua informatie ongewijzigd gebleven, behalve als men op het tabblad Bonnen een order-regel geselecteerd heeft. Dan worden er enkele specificieke ordergegevens extra getoond, zoals de Orderstatus, en de leverdatum. Van de order wordt tevens het totaal aanbetaalde, en openstaande bedrag getoond in het kader waar de betaal-informatie staat. Wel zijn de kopgegevens alleen geherrangschikt en in grootte veranderd. Relatiegegevens zijn naar boven geplaatst. Tabblad Kasgeld Het tabblad Kasgeld is niet gewijzigd, behalve dan dat de volgorde is omgedraaid, en de Afdruk-instelling is verplaatst. Ook op het rapport is de afdruk gewijzigd. Ook hier is er een kolom datum toegevoegd, die alleen getoond wordt, als op het tabblad dagtotalen de optie Totalen is aangevinkt. Helaas zal deze kolom initieel geheel rechts geplaatst worden vanwege de USERKOLOM-instellingen. Hierdoor lijkt het alsof de kolom niet getoond wordt. Na het verplaatsen van de kolom is dit probleem opgelost van 87

17 Tabblad Kortingscoupons Dit tabblad is nieuw en toont de in de kassa gescande kortingscoupons (in de ingestelde periode op tabblad dagtotalen), waarop ook daadwerkelijk korting is verleend. Met behulp van deze informatie kan men het succes van een bepaalde kortingscoupon bekijken. Wellicht dat dit in de toekomst nog uitbreid wordt met een filtermogelijkheid op het veld barcode. Tabblad Dagomzet Het tabblad Dagomzet is komen te vervallen, omdat de hier getoonde informatie, nu op de andere tabbladen terug te vinden is. Zo kan men op het tabblad Dagtotalen, nu de gegevens van alle systemen van de huidige dag tonen, met de nieuwe filter-mogelijkheden op station. Het veld Orders debiteuren incl. BTW is in gewijzigde vorm terug te vinden op het tabblad Bonnen. Hierop staat nu het totaal aan openstaande orders in de geselecteerde periode. Het veld totale verkoopwaarde is komen te vervallen, aangezien deze verkeerde informatie kon bevatten. Bv. als orders dezelfde dag ook nog afgerekend werden. De optie om een afdruk te maken van de huidige dagomzet vergeleken met vorig jaar is eveneens komen te vervallen, o.a. door tijdsgebrek en omdat zij nog op het oude dagjournaal gebaseerd was. Deze functionaliteit zal in een volgende versie in gewijzigde vorm terugkeren, indien hier behoefte aan mocht zijn. Tevens is dus bij de printer-instellingen onderstaande optie verdwenen, omdat zij niet meer aangeroepen kan worden van 87

18 6.1.2 Versnelling bepalen of kassa definitief geteld is Beschrijving Vanaf 3.41 was aangepast dat als onderstaande instelling op Nee stond, er voor het schrijven van een kassabon gecontroleerd werd of het station al definitief geteld was. Deze controle kon heel wat tijd in beslag nemen, wanneer er grote database-bestanden aanwezig waren. Vanaf 3.42 is ervoor gezorgd dat deze controle niet veel tijd in beslag neemt, zodat de instelling weer bruikbaar wordt voor iedereen Verwijderingsbijdrage ( ) Beschrijving Noodzaak wijziging Vanaf 3.41 is het met patch 004 mogelijk om het statiegeld-bedrag voor artikelen en secundaire artikelen in te voeren tot maximaal 6 decimalen. Voorheen was dit beperkt tot 2. De noodzaak voor de wijziging is, omdat men soms het statiegeld-veld gebruikt om de verwijderingsbijdrage van een artikel te bepalen. Op verwijderingsbijdrage zit echter BTW en er is slechts 1 invoer-veld voor statiegeld. Dit veld wordt altijd als de inclusief-prijs beschouwd. Hierdoor was het onmogelijk om bv. een excl. Prijs van 0,12 euro te hanteren voor verwijderingsbijdrage. Dit is wel wenselijk indien men heeft ingesteld dat de basis voor het afronden van verkoopprijzen excl. Btw is. Voorheen kon alleen invoer van (incl.) 0,14 euro gebeuren, hetgeen resulteerde in een excl. Prijs van 0, van 87

19 Werking Door nu een prijs in te voeren van 0,1428 euro, zal het systeem op een exclusief bedrag van 0,12 uitkomen. Als men nu 50 stuks van dit artikel verkoopt, zal dit resulteren in onderstaande kassabon: Retourscannen kassabon Nieuwe functie-toets CTRL+F11 Wanneer men in de kassa de toets-combinatie CTRL+F11 gebruikt, dan verschijnt er een popup-venster, waar men een bonnummer in kan voeren of scannen. Hiertoe dient men dan wel het bonnummer als barcode in de bonlayout toe te voegen. Vervolgens wordt er gecontroleerd of er op de bon verkoopregels voorkomen, die nog niet eerder zijn retour geboekt. Als een kassabon gescand wordt, waarop geen verkoopregels staan, dan verschijnt de volgende melding: van 87

20 Als de bon nog niet retourgeboekte verkoopregels bevat, dan worden alleen die artikels-regel ingelezen, en er per artikel om een reden van retour gevraagd. Bij bonnen met veel artikelen kan dit dus bewerkelijk zijn, en is het vaak handiger om de artikelen handmatig retour te nemen. De regels die eventueel niet retour genomen worden, kunnen via de DEL-toets verwijderd worden. Overige functies zoals het geven van korting, wijzigen van aantal en/of prijs blijft toegestaan. Het toevoegen van artikelen is ook mogelijk. Mogelijkheden en beperkingen Kassabon-regels kunnen slechts eenmaal via F11 retour genomen worden. Als in bovenstaande bon de Bahama short verwijderd wordt, en vervolgens de bon opgeslagen wordt, dan zal de volgende keer dat de bon via CTRL+F11 retourgescand wordt enkel de Bahama short ingelezen worden. Let op, het niet meer inlezen van regels geldt ook als er bv. 4 artikelen verkocht zijn, en er wordt er bv. maar 1 retour geboekt. De overige 3 artikelen kunnen dan niet meer via F11 retourgeboekt worden. Als ook deze regel afgehandeld wordt, dan zal de volgende keer dat deze bon retour gescand wordt, onderstaande melding verschijnen: van 87

21 6.1.5 Kortingscouponnen ( ) Mogelijkheden en beperkingen Een kortingscoupon is een bon die via reclamedrukwerk of een website (die de bezoeker kan printen), aan klanten ter beschikking wordt gesteld, en waarmee de klant bepaalde artikelen met korting kan aanschaffen op vertoon van de kortingscoupon. De couponnen kunnen zowel anoniem als gericht aan een persoon zijn. Voorbeeld 1 (Mixmatch) Voorbeeld 2 (Kortingstabel) Voorbeeld 3 (Mixmatch) Voorbeeld 4 (Mixmatch) Voorbeeld 5 (Mixmatch) Voorbeeld 6 (Mixmatch) Op een kortingscoupon staat een barcode, waarmee aangegeven wordt, welke korting op welke artikelen van toepassing is. Er zijn voor zover wij weten geen richtlijnen gesteld aan de barcode-norm voor kortingscouponnen (Bv. vaste voorloopcijfers), omdat de coupon vaak uitgegeven wordt door een leverancier en de gebruiker geen controle over de nummering van leverancier heeft. Het is niet mogelijk om met BlueRetail zelf kortingscouponnen te creëren, of een range in te stellen voor de barcode van een kortingscoupon. Het is dan ook noodzakelijk dat de barcode die gebruikt wordt voor een kortingscoupon, niet voorkomt in bv. het (secundair) artikelbestand, het synoniem-bestand, het aanbiedingen-bestand en het alt. Leveranciers-bestand. De barcode van de kortingscoupon, dient enkel als identificatie-middel, en dient niet de informatie mbt de korting of het artikel te bevatten. Indien dit wel wenselijk is, dan dient men prijsbarcodes te gebruiken in plaats van kortingscouponnen. Het is vanaf versie 3.42 dus mogelijk om eventuele kortingscoupon-barcodes in de kassa te scannen, en op de bijbehorende artikelen korting te verlenen. Bij het invoeren van debiteurenorders en facturen/creditnota s bestaat die mogelijkheid niet. Het is eveneens niet mogelijk om een kortingscoupon per verkocht artikel te hanteren. Als een kortingscoupon geldig is voor 1 artikel, en de klant koopt 5 van die artikelen, dan zal zij met 1 kortingscoupon op alle 5 de artikelen korting krijgen. Acties waarbij men dus per kortingscoupon slechts op 1 artikel korting krijgt, zijn dus niet mogelijk van 87

22 Definieren van een kortingscoupon Binnen BlueRetail zijn er twee manieren om de eigenschappen van een kortingscoupon te definieren: - Via een mixmatch, of Kortingscoupon, waarmee men in december 5% korting op een broodje kaas krijgt - Via een kortingstabel Kortingscoupon, waarmee men op 4 december 4 euro korting op Harry Potter en de vuurberker. In beide schermen is er een barcode-veld toegevoegd. Wanneer hier een waarde wordt ingevoerd van minimaal 7 cijfers, dan gaat het systeem ervan uit, dat het om een kortingscoupon gaat. Op de overzichtsschermen is eveneens een kolom met barcode toegevoegd. Helaas is het nog niet mogelijk, om ook op een barcode te filteren van 87

23 Invoercontrole kortingscoupon Het invoeren van een kortingscoupon bij een kortingstabel kan alleen als: - Het kortingstype niet Vaste Prijs is, en - Actief voor gelijk is aan Verkoop Wanneer 1 van beide voorwaarden niet geldt, dan wordt het barcode-veld onzichtbaar. Bij mixmatch blijft het barcode-veld altijd zichtbaar. Bij het opslaan van een mixmatch en kortingstabel vinden nu twee extra controles plaats op het barcode-veld: - De lengte moet minimaal 7 karakters zijn; - De waarde moet niet voorkomen in de andere bestanden. Is dit niet het geval, zal er een melding verschijnen van 87

24 Bij de controle of een barcode al voorkomt binnen de mixmatch en kortingstabellen, wordt alleen gekeken naar de records waarvan de einddatum op vandaag of in de toekomst ligt. Dus een barcode kan wel hergebruikt worden, als deze voorkomt in een mixmatch waarvan de periode reeds verstreken is. Werking van de kortingscoupon Om kortingscouponnen via mixmatch in de kassa te laten werken, dient uiteraard de mixmatch aktief te zijn in de kassa. Ook als de mixmatch aktief is bij orders of facturen, dan zullen daar de kortingscouponnen niet werken! Om kortingscouponnen via kortingstabellen in de kassa te laten werken, die voor iedereen moeten gelden, dienen deze aan hetzelfde Kenmerk gehangen te worden. Dit kenmerk dient tevens ingesteld te worden als voorkeurskortingstabel van 87

25 Kortingstabel-kortingscoupon met een ander kenmerk zullen alleen werken, indien de bijbehorende relatie geselecteerd is, voordat men via F12 naar afrekenen gaat. Dit is namelijk het moment waarop gecontroleerd wordt of er korting gegeven moet worden. Als men de relatie in het afrekenscherm selecteren, zal men via ESC eerst terug moeten, en vervolgens weer met F12 naar afrekenen, om de kortingscoupon aktief te maken. Als vervolgens tijdens het scannen van een barcode in de kassa, de barcode niet gevonden wordt in het artikelbestand, dan gaat het systeem de kortingstabelrecords en de mixmatch-records doorlopen, om te kijken of de barcode hierin voorkomt. Zo nee, dan komt er een melding dat het artikel niet gevonden is. Zo ja, dan wordt gecontroleerd of de kortingscoupon geldig is. Als de kortinscoupon niet geldig is, dan verschijnt er een melding wanneer de kortingscoupon geldig is of was. Is de coupon wel geldig, dan wordt er een opmerkingsregel in de kassa van 87

26 toegevoegd met de barcode en omschrijving van de kortingscoupon. Voor kortingtabel-kortingscouponnen is de omschrijving de titel van het kenmerk dat als voorkeur is ingesteld. Voor mixmatch-kortingscouponnen is dit of de barcode, of de omschrijving, als is ingesteld dat deze op de bon moet komen. Omdat een kortingscoupon altijd voor alle artikel-aantallen geldig is, kan deze per kassabon ook maar 1 keer gescand worden. Wordt dit een tweede keer gedaan, dan verschijnt er een melding. Als de kassiere vervolgens gaat afrekenen, controleert het systeem of er mixmatchen aktief zijn, of kortingstabel-kortingscouponnen. Zo ja, dan wordt voor iedere coupon de bon doorlopen om te controleren of de bijbehorende artikelen ook aanwezig zijn. Voor alle kortingscouponnen waarvoor geen korting berekend is, verschijnt een melding. Eventueel kan de kassiere de klant hierop attent maken, en de ontbrekende artikelen toe laten voegen van 87

27 Als de bijbehorende artikelen wel op de bon staan, wordt de korting verwerkt, en het totaalbedrag verlaagd. Kassabon. Totaal bedrag 51,36. Vervolgens naar afrekenen via F12. Nu worden de coupons aktief, en wordt totaal bedrag 47,29. Totale korting is 4,07. 4 euro op het boek, en 7 cent op het broodje kaas (5% van 1,36) Als deze bon vervolgens afgehandeld wordt, kan de klant constateren dat er korting is verleend van 87

28 De kortingscoupon-regels kunnen dus op een andere plek op de bon staan, dan de bijbehorende artikelen, dit kan soms voor verwarring zorgen. Net als dat niet zichtbaar is, welke kortingscoupon voor welk artikel geldt. In het dagjournaal kan men achteraf altijd de hoeveel korting terug zien, door de bon te selecteren, of het tabblad kortingscoupon te raadplegen van 87

29 6.2 Inkoop Beschrijving algemeen De organisatie moet op gecontroleerde wijze bij leveranciers goederen kunnen bestellen. Hiertoe beschikt de applicatie standaard over de benodigde inkoop functionaliteiten Relatie-notities tonen Instelling mbt Relatie-notities tonen Vanaf 3.42 werkt voor onderstaande instelling de optie Alleen Inkoop weer aan de crediteurenkant, en werkt de optie Alleen Verkoop ook bij het selecteren van relaties aan de debiteuren-kant. Voorheen werkte deze alleen in de kassa. Wanneer men aan de crediteuren-kant nu deze relatie selecteert, verschijnt de notitie: van 87

30 6.2.2 Inkooporder op basis van afleverdatum ( ) Inleiding Nieuwe instelling Vanaf de versie 3.42 is het mogelijk inkooporders aan te maken op basis van verkooporders rekening houdend met de gewenste leverdatum van de klant. Dat wil zeggen dat het bestelmoment bepaald wordt door de leverdatum aan de klant. Hierdoor ontstaan geen ongewenste voorraad-/magazijnkosten meer. Het aanmaken van een inkooporder op basis van de leverdatum van de verkooporder is mogelijk door de instelling Rekening houden met leverdatum order debiteur op Ja te zetten (Instellingen\Software\Crediteuren). Let op: Deze instelling is alleen beschikbaar indien men over de module verkooporder beschikt. Standaard staat deze instelling op Nee. Dit houdt in dat er aan de huidige werking van het pakket niks veranderd. Nieuw veld Binnen BlueRetail bestaat reeds het veld Levertermijn in de artikelkaart. Op basis van dit veld wordt momenteel de lever- (verkoopkant) of ontvangstdatum (inkoopkant) bepaald. Echter de betrouwbaarheid van je leveranciers beïnvloed ook je eigen leverbetrouwbaarheid naar de klant toe. Dit is dus een factor waar ook rekening mee gehouden dient te worden bij het bepalen van het bestelmoment aan de van 87

31 inkoopkant. Deze betrouwbaarheidsfactor kan vanaf de versie 3.42 ingegeven worden in de relatiekaart indien voor de relatiegroep, waaraan de betreffende relatie gekoppeld is, de switch Relatiesoort op Crediteur of Beide staat. v voor de betreffende relatie de Formule Rekening houdend met bovenstaande wordt het bestelmoment bepaald aan de hand van onderstaande formule: AFLEVERDATUM] -/- [LEVERTERMIJN ARTIKEL MET LANGSTE DOORLOOPTIJD OP VKO] -/- [LEVERBETROUWBAARHEID] = [BESTELDATUM] Automatisch Aanmaken Inkooporder Indien de switch Rekening houden met leverdatum order debiteur op Ja staat zijn er in de versie 3.42 volgende mogelijkheden m.b.t. het automatisch aanmaken van inkooporders: Combinatie I II III IV Splits levertermijn: NEE NEE JA JA Splits order debiteur: NEE JA NEE JA Rekening houden met leverdatum order debiteur: JA JA JA JA van 87

32 Voorbeeld met de instellingen volgens combinatie I Splits levertermijn: NEE Splits order debiteur: NEE Rekening houden met leverdatum order debiteur: JA Artikel 00 dagen levertermijn en Leverancier EEN Betrouwbaarheid 5 dagen. Artikel 10 dagen levertermijn en Leverancier EEN Betrouwbaarheid 5 dagen. Artikel 30 dagen levertermijn en Leverancier EEN Betrouwbaarheid 5 dagen. Klant EEN debiteurenorder XXXX met levertijd over 60 dagen van vandaag 15 stuks Artikel 00 dagen levertermijn en Leverancier EEN 15 stuks Artikel 10 dagen levertermijn en Leverancier EEN 15 stuks Artikel 30 dagen levertermijn en Leverancier EEN Klant TWEE debiteurenorder YYYY met levertijd over 60 dagen van vandaag 15 stuks Artikel 00 dagen levertermijn en Leverancier EEN 15 stuks Artikel 10 dagen levertermijn en Leverancier EEN 15 stuks Artikel 30 dagen levertermijn en Leverancier EEN Als ik nu vandaag kies voor Automatisch aanmaken Crediteurenorders dan wordt er géén enkele Crediteurenorder aangemaakt. Pas op de teruggerekende datum van leveren over 60 dagen dagen wordt één crediteurenorder aangemaakt bij Leverancier EEN met twee artikelregels. Daarvoor wordt NIETS besteld/geen crediteurenorder aangemaakt. Crediteurenorder UUUU bij Leverancier EEN 15 stuks Artikel 30 dagen levertermijn voor debiteurenorder XXXX Klant EEN 15 stuks Artikel 30 dagen levertermijn voor debiteurenorder YYYY Klant TWEE Hier tussenin wordt niets besteld. Op de teruggerekende datum van leveren over 60 dagen dagen wordt één crediteurenorder aangemaakt bij Leverancier EEN met twee artikelregels. Crediteurenorder VVVV bij Leverancier EEN 15 stuks Artikel 10 dagen levertermijn voor debiteurenorder XXXX Klant EEN 15 stuks Artikel 10 dagen levertermijn voor debiteurenorder YYYY Klant TWEE Hier tussenin wordt niets besteld. Op de teruggerekende datum van leveren over 60 dagen dagen wordt één crediteurenorder aangemaakt bij Leverancier EEN met twee artikelregels. Crediteurenorder WWWW bij Leverancier EEN 15 stuks Artikel 00 dagen levertermijn voor debiteurenorder XXXX Klant EEN 15 stuks Artikel 00 dagen levertermijn voor debiteurenorder YYYY Klant TWEE Dus op de leverdatum heb je uiteindelijk 3 crediteurenorders UUUU, VVVV en WWWW waarmee je de twee debiteurenorders compleet hebt en kunt uitleveren Voorbeeld met de instellingen volgens combinatie II Splits levertermijn: NEE Splits order debiteur: NEE Rekening houden met leverdatum order debiteur: JA Artikel 00 dagen levertermijn en Leverancier EEN Betrouwbaarheid 5 dagen. Artikel 10 dagen levertermijn en Leverancier EEN Betrouwbaarheid 5 dagen. Artikel 30 dagen levertermijn en Leverancier EEN Betrouwbaarheid 5 dagen. Klant EEN debiteurenorder XXXX met levertijd over 60 dagen van vandaag 15 stuks Artikel 00 dagen levertermijn en Leverancier EEN 15 stuks Artikel 10 dagen levertermijn en Leverancier EEN 15 stuks Artikel 30 dagen levertermijn en Leverancier EEN Klant TWEE debiteurenorder YYYY met levertijd over 60 dagen van vandaag van 87

33 15 stuks Artikel 00 dagen levertermijn en Leverancier EEN 15 stuks Artikel 10 dagen levertermijn en Leverancier EEN 15 stuks Artikel 30 dagen levertermijn en Leverancier EEN Als ik nu vandaag kies voor Automatisch aanmaken Crediteurenorders dan wordt er géén enkele Crediteurenorder aangemaakt. Pas op de teruggerekende datum van leveren over 60 dagen dagen wordt één crediteurenorder aangemaakt bij Leverancier EEN met twee artikelregels. Daarvoor wordt NIETS besteld/geen crediteurenorder aangemaakt. Crediteurenorder UUUU bij Leverancier EEN 15 stuks Artikel 30 dagen levertermijn voor debiteurenorder XXXX Klant EEN 15 stuks Artikel 30 dagen levertermijn voor debiteurenorder YYYY Klant TWEE Hier tussenin wordt niets besteld. Op de teruggerekende datum van leveren over 60 dagen dagen wordt één crediteurenorder aangemaakt bij Leverancier EEN met twee artikelregels. Crediteurenorder VVVV bij Leverancier EEN 15 stuks Artikel 10 dagen levertermijn voor debiteurenorder XXXX Klant EEN 15 stuks Artikel 10 dagen levertermijn voor debiteurenorder YYYY Klant TWEE Hier tussenin wordt niets besteld. Op de teruggerekende datum van leveren over 60 dagen dagen wordt één crediteurenorder aangemaakt bij Leverancier EEN met twee artikelregels. Crediteurenorder WWWW bij Leverancier EEN 15 stuks Artikel 00 dagen levertermijn voor debiteurenorder XXXX Klant EEN 15 stuks Artikel 00 dagen levertermijn voor debiteurenorder YYYY Klant TWEE Dus op de leverdatum heb je uiteindelijk 3 crediteurenorders UUUU, VVVV en WWWW waarmee je de twee debiteurenorders compleet hebt en kunt uitleveren Voorbeeld met de instellingen volgens combinatie III Splits levertermijn: JA Splits order debiteur: NEE Rekening houden met orderdatum debiteur: JA Artikel 00 dagen levertermijn en Leverancier EEN Betrouwbaarheid 5 dagen. Artikel 10 dagen levertermijn en Leverancier EEN Betrouwbaarheid 5 dagen. Artikel 30 dagen levertermijn en Leverancier EEN Betrouwbaarheid 5 dagen. Klant EEN debiteurenorder XXXX met levertijd over 60 dagen van vandaag 15 stuks Artikel 00 dagen levertermijn en Leverancier EEN 15 stuks Artikel 10 dagen levertermijn en Leverancier EEN 15 stuks Artikel 30 dagen levertermijn en Leverancier EEN Klant TWEE debiteurenorder YYYY met levertijd over 60 dagen van vandaag 15 stuks Artikel 00 dagen levertermijn en Leverancier EEN 15 stuks Artikel 10 dagen levertermijn en Leverancier EEN 15 stuks Artikel 30 dagen levertermijn en Leverancier EEN Als ik nu vandaag kies voor Automatisch aanmaken Crediteurenorders dan wordt er géén enkele Crediteurenorder aangemaakt. Pas op de teruggerekende datum van leveren over 60 dagen dagen wordt er één crediteurenorder aangemaakt bij Leverancier EEN met elk twee artikelregels. Daarvoor wordt NIETS besteld/geen crediteurenorder aangemaakt. Crediteurenorder UUUU bij Leverancier EEN 15 stuks Artikel 30 dagen levertermijn voor debiteurenorder XXXX Klant EEN 15 stuks Artikel 30 dagen levertermijn voor debiteurenorder YYYY Klant TWEE van 87

34 Hier tussenin wordt niets besteld. Op de teruggerekende datum van leveren over 60 dagen dagen wordt er één crediteurenorder aangemaakt bij Leverancier EEN met twee artikelregels. Crediteurenorder VVVV bij Leverancier EEN 15 stuks Artikel 10 dagen levertermijn voor debiteurenorder XXXX Klant EEN 15 stuks Artikel 10 dagen levertermijn voor debiteurenorder YYYY Klant TWEE Hier tussenin wordt niets besteld. Op de teruggerekende datum van leveren over 60 dagen dagen wordt er één crediteurenorder aangemaakt bij Leverancier EEN met twee artikelregels. Crediteurenorder WWWW bij Leverancier EEN 15 stuks Artikel 00 dagen levertermijn voor debiteurenorder XXXX Klant EEN 15 stuks Artikel 00 dagen levertermijn voor debiteurenorder YYYY Klant TWEE Dus op de leverdatum heb je uiteindelijk 3 crediteurenorders UUUU, VVVV, en WWWW waarmee je de twee debiteurenorders compleet hebt en kunt uitleveren Voorbeeld met de instellingen volgens combinatie IV Splits levertermijn: JA Splits order debiteur: JA Rekening houden met orderdatum debiteur: JA Artikel 00 dagen levertermijn en Leverancier EEN Betrouwbaarheid 5 dagen. Artikel 10 dagen levertermijn en Leverancier EEN Betrouwbaarheid 5 dagen. Artikel 30 dagen levertermijn en Leverancier EEN Betrouwbaarheid 5 dagen. Klant EEN debiteurenorder XXXX met levertijd over 60 dagen van vandaag 15 stuks Artikel 00 dagen levertermijn en Leverancier EEN 15 stuks Artikel 10 dagen levertermijn en Leverancier EEN 15 stuks Artikel 30 dagen levertermijn en Leverancier EEN Klant TWEE debiteurenorder YYYY met levertijd over 60 dagen van vandaag 15 stuks Artikel 00 dagen levertermijn en Leverancier EEN 15 stuks Artikel 10 dagen levertermijn en Leverancier EEN 15 stuks Artikel 30 dagen levertermijn en Leverancier EEN Als ik nu vandaag kies voor Automatisch aanmaken Crediteurenorders dan wordt er géén enkele Crediteurenorder aangemaakt. Pas op de teruggerekende datum van leveren over 60 dagen dagen worden er twee crediteurenorders aangemaakt bij Leverancier EEN met elk één artikelregel. Daarvoor wordt NIETS besteld/geen crediteurenorder aangemaakt. Crediteurenorder PPPP bij Leverancier EEN 15 stuks Artikel 30 dagen levertermijn voor debiteurenorder XXXX Klant EEN Crediteurenorder QQQQ bij Leverancier EEN 15 stuks Artikel 30 dagen levertermijn voor debiteurenorder YYYY Klant TWEE Hier tussenin wordt niets besteld. Op de teruggerekende datum van leveren over 60 dagen dagen worden er twee crediteurenorders aangemaakt bij Leverancier EEN met elk één artikelregel. Crediteurenorder RRRR bij Leverancier EEN 15 stuks Artikel 10 dagen levertermijn voor debiteurenorder XXXX Klant EEN Crediteurenorder SSSS bij Leverancier EEN 15 stuks Artikel 10 dagen levertermijn voor debiteurenorder YYYY Klant TWEE van 87

35 Hier tussenin wordt niets besteld. Op de teruggerekende datum van leveren over 60 dagen dagen worden er twee crediteurenorders aangemaakt bij Leverancier EEN met elk één artikel-regel. Crediteurenorder TTTT bij Leverancier EEN 15 stuks Artikel 00 dagen levertermijn voor debiteurenorder XXXX Klant EEN Crediteurenorder UUUU bij Leverancier EEN 15 stuks Artikel 00 dagen levertermijn voor debiteurenorder YYYY Klant TWEE Dus op de leverdatum heb je uiteindelijk 6 crediteurenorders PPPP, QQQQ, RRRR, SSSS, TTTT en UUUU waarmee je de twee debiteurenorders compleet hebt en kunt uitleveren van 87

36 6.3 Logistiek Beschrijving Newway spreekt bewust over logistiek, omdat deze functionaliteit in haar ogen de ontvangst van goederen, het leveren van verkooporders en de benodigde handelingen met betrekking tot de voorraad omvat (voorraad correcties en het voorraadopname traject). Omwille van de door klanten gewenste functiescheiding met bijbehorende verantwoordelijkheden, heeft Newway het logistieke proces gesplitst van het inkoop- en facturatieproces Case Voorraadprognose ( ) Inleiding Menupad Vanaf de versie 3.42 bestaat er een nieuwe functie genaamd VoorraadPrognose waarmee men de mogelijkheid heeft om voorraden te plannen. Op basis van de in het systeem voorhanden zijnde verkoop- en inkooporders wordt er getoond hoe de verwachte beschikbare voorraad er in de toekomst uit zal zien. Deze nieuwe functie bevindt zich in het BlueRetail menu onder Bestanden\ Logistiek van 87