NL2002332C2 - Systeem voor het verwerken van transactiegegevens. - Google Patents

Description

Titel van de uitvinding

Systeem voor het verwerken van transactiegegevens.

Vakgebied van de uitvinding 5 De uitvinding heeft betrekking op een systeem voor het verwerken van transactiegegevens, voorzien van aggregeermiddelen voor het uit de transactiegegevens afleiden van geaggregeerde informatie over transacties, en van importeermiddelen voor het importeren van de transactiegegevens van één of meer point-of-sale systemen in een database.

10

De uitvinding heeft tevens betrekking op een computerprogrammaproduct voor het realiseren van het bovengenoemde systeem met behulp van een processor.

Achtergrond van de uitvinding 15 De retail markt, in het bijzonder de de fashion retail markt, kenmerkt zich door zeer grote hoeveelheden verkooptransacties. Daarbij kan gedacht worden aan miljoenen tot meer dan 100 miljoen transacties per jaar, verdeeld over diverse filialen in een mogelijk groot geografisch gebied. Het verwerken van zulke grote aantallen transacties dient met de grootste zorgvuldigheid te gebeuren, en vereist dus ondersteuning met de juiste 20 technologie.

Een gebruikelijk technisch systeem voor dit doel functioneert kortweg als volgt. De point of sale (POS) systemen bij de diverse filialen verwerken de kassatransacties. Gegevens over deze transacties worden op vaste momenten, bijvoorbeeld eens per dag, 25 uitgelezen en doorgestuurd naar een centraal systeem voor verdere verwerking. Hierbij kan gebruik worden gemaakt van een tussenstap waarbij een computersysteem in het filiaal de individuele POS systemen uitleest en de verzamelde gegevens doorstuurt naar het centrale systeem. Ook is mogelijk dat het centrale systeem direct contact legt met de individuele POS systemen. Voorraad- en inkoopbeheer van de retailer kan dan worden 30 gebaseerd op de geaggregeerde gegevens van de POS systemen.

Een nadeel van deze aanpak is dat zij foutgevoelig is. Het blijkt in de praktijk regelmatig voor te komen dat bij een uitleesmoment geen contact kan worden gelegd met een POS systeem, bijvoorbeeld vanwege storingen in de telecommunicatie- 2 infrastructuur bij een filiaal of simpelweg omdat het POS systeem per abuis is uitgezet. Dit heeft tot gevolg dat de transactiegegevens van die periode niet kunnen worden verwerkt. Bij het volgende uitlcesmoment moeten dan gegevens van meerdere periodes worden verzameld, iets waar niet alle POS systemen tot in staat zijn.

5

Een ander probleem bij bekende oplossingen is dat indien artikelen met een foutieve productgroepcode verkocht zijn, deze verkopen geaggregeerd blijven op de foutieve productgroepcodes. Hierdoor ontstaan fouten in de geaggregeerde verkoophistorie.

10 Samenvatting van de uitvinding

De uitvinding stelt zich ten doel een verbeterd systeem voor het verwerken van transactiegegevens van POS systemen te bieden.

Dit doel wordt volgens de uitvinding bereikt middels een systeem zoals aangegeven in 15 de aanhef, gekenmerkt door het telkens na het importeren van de transactiegegevens opnieuw afleiden van de volledige geaggregeerde informatie over de transacties. Hiermee wordt bereikt dat de benodigde gegevens zo accuraat mogelijk en tevens altijd actueel zijn. Daarmee wordt voorkomen dat fouten bij het inlezen van gegevens doorwerken in de langetermijnplanning. Na een correctie op transactieniveau worden 20 immers de gecorrigeerde gegevens geïmporteerd, waarna de gehele langetermijnplanning opnieuw wordt afgeleid uit de gecorrigeerde gegevens.

In een voordelige uitvoeringsvorm zijn de importeermiddelen geconfigureerd voor het bepalen van een oudste transactiedatum van de transactiegegevens, voor het op basis 25 van deze oudste transactiedatum verwijderen van reeds in de database aanwezig zijnde transactiegegevens die eenzelfde of een jongere transactiedatum hebben als de oudste transactiedatum, en voor het vervolgens importeren van de transactiegegevens van de één of meer point-of-sale systemen. Dit realiseert op een eenvoudige maar doeltreffende manier dat de meest actuele transactiegegevens worden gebruikt in plaats van mogelijk 30 verouderde of onjuiste transactiegegevens uit een eerdere importslag. Dit vergroot de accuratesse en de actualiteit van de transactiegegevens die worden geaggregeerd.

Tevens biedt de uitvinding een computerprogrammaproduct voor het realiseren van het bovengenoemde systeem met behulp van een processor.

Enkele andere voordelige uitvoeringsvormen van de uitvinding staan genoemd in de volgconclusies.

3 5 Korte beschrijving van de figuren

De uitvinding zal hierna worden toegelicht aan de hand van de figuren, waarin:

Fig. 1 schematisch een systeemarchitectuur volgens de uitvinding illustreert;

Fig. 2 schematisch een procesverloop volgens de uitvinding illustreert.

10

Beschrijving van enkele uitvoeringsvormen

Fig. 1 toont schematisch een systeemarchitectuur volgens de uitvinding. In deze architectuur wordt uitgegaan van een systeem waarbij meerdere POS systemen 101-a t/m 101-n van een retailer elk hun transactiegegevens versturen naar een Enterprise 15 Retail Planning (ERP) systeem 110 van de retailer. In een alternatieve uitvoeringsvorm verzamelt een centrale verwerkingseenheid in elk filiaal de transactiegegevens van alle POS systemen 101-a t/m 101-n in dat filiaal en verstuurt deze in gecombineerde vorm naar het ERP systeem 110. Het versturen van de transactiegegevens kan op diverse manieren gebeuren. Veelgebruikte opties zijn datatransmissie via een directe telefoon-20 of ISDN-verbinding en datatransmissie via het internet.

Het ERP systeem 110 is gekoppeld aan het Darwin Retail Planner (DRP) 120 systeem, dat zorgdraagt voor merchandise planning en de planning van voorraad en inkoop . Het DRP systeem 120 beschikt onder andere over een aggregeermodule 121 voor het uit de 25 transactiegegevens afleiden van geaggregeerde informatie over transacties, en over een importeermodule 122 voor het importeren van de transactiegegevens van de POS systemen 101-a,..., 101-n, alsmede over een database 124. De werking van het DRP systeem 120 wordt hieronder nader besproken. De koppeling wordt bij voorkeur gerealiseerd door eens per nader te kiezen periode, zoals dagelijks om twee uur ’s 30 nachts, alle relevante gegevens te exporteren naar een bestand dat het DRP systeem 120 vervolgens inleest naar haar eigen database 124. Dit kan worden geautomatiseerd door middel van bekende technieken. Een real-time koppeling is natuurlijk ook mogelijk, maar in de meeste gevallen niet nodig.

4

De koppeling tussen ERP systeem 110 en DRP systeem 120 kan op vele manieren technisch worden gerealiseerd. De keuze zal afhangen van bijvoorbeeld welke ERP-software in gebruik is bij de retailer en welke mogelijkheden voor koppeling, export of uitwisseling van gegevens deze software biedt. Een bekende en veelgebruikte manier is 5 om het ERP-pakket de gegevens te laten exporteren naar een kommagesepareerd bestand (CSV) dat door DRP systeem 120 kan worden geïmporteerd. Export in XML-formaat of elk ander gewenst formaat is ook mogelijk.

Het DRP systeem 120 kan worden geïmplementeerd als een 10 computerprogrammaproduct dat met behulp van een processor wordt uitgevoerd.

Daarbij valt te denken aan een softwarcapplicatie die op een personal computer of vergelijkbaar computersysteem wordt ingeladen en uitgevoerd. De softwareapplicatie bevat dan de computerinstmcties die de stappen uitvoeren waarmee het DRP systeem 120 wordt gerealiseerd. Deze stappen hebben betrekking op het procesverloop dat 15 hieronder bij Fig. 2 besproken wordt. Bij voorkeur wordt het DRP systeem 120 dan geïmplementeerd met behulp van de .NET omgeving van Microsoft, hoewel ook andere talen zoals Java in principe geschikt zijn.

Het DRP systeem 120 wordt bij voorkeur gerealiseerd als een webgebaseerde 20 softwareapplicatie. Deze applicatie kan binnen het netwerk van de retailer worden geïnstalleerd zodat alle (immers gevoelige) gegevens onder zijn controle blijven. Een alternatief is om het DRP systeem 120 onder te brengen op een gecentraliseerde locatie bij een leverancier. Zo kunnen diverse retailers tegelijkertijd gebruik maken van het DRP systeem 120 zonder elk zorg te moeten dragen voor installatie, configuratie en 25 onderhoud van het DRP systeem 120. Natuurlijk moeten in dat geval wel volgende maatregelen worden getroffen om de veiligheid van de gegevens bij de leverancier te kunnen garanderen. Voor de database 124 zijn vele producten beschikbaar van diverse leveranciers. Bij voorkeur wordt gebruik gemaakt van een SQL database.

30 Fig. 2 illustreert schematisch een procesverloop, welk door het DRP systeem 120 bij voorkeur wordt geïmplementeerd. De eerste stap 201 in het proces is het importeren van de gegevens uit het aangekoppelde ERP systeem 110, welke stap wordt uitgevoerd door bovengenoemde importeermodule 122. Hierbij wordt geen gebruik gemaakt van de bekende delta-techniek waarbij alleen verschillen (delta’s) ten opzichte van eerder 5 geïmporteerde gegevens worden binnengehaald. De delta-techniek is foutgevoelig. Volgens de uitvinding importeert de importeermodule 122 alle gegevens die beschikbaar zijn naar de database 124, zelfs als deze reeds eerder aanwezig waren in deze database 124.

5

In een voorkeursuitvoeringsvorm bepaalt de importeermodule 122 daarbij de oudste transactiedatum van de gegevens die worden geïmporteerd. Op basis van deze oudste transactiedatum worden in de eigen database 124 alle transactiegegevens verwijderd die eenzelfde of een jongere transactiedatum hebben. Daarna worden de aangeleverde 10 transactiegegevens in de database 124 geplaatst. Voor extra zekerheid kunnen de te verwijderen gegevens in een backup tabel worden geplaatst, zodat bij een onjuiste of voortijdig afgebroken import deze gegevens eenvoudig teruggezet kunnen worden.

Het DRP systeem 120 draagt onder andere zorg voor de planning van in te kopen producten. Dit vereist aggregatie van voorraad- en verkoopgegevens naar verschillende 15 niveaus, van een specifieke artikel/kleur/maat (SKU) combinatie naar hogere aggregatieniveaus zoals “winterkleding” of “sportkleding”. Ook dienen de gegevens naar periode inzichtelijk te worden gemaakt, bijvoorbeeld per week, maand of wisselende periodes van aantallen weken. Daartoe is het DRP systeem 120 uitgerust met aggregatiemodule 121.

20

In de retail industrie, met name de fashion retail industrie, dient rekening te worden gehouden met snel wisselende collecties met veel artikelen. Het DRP systeem 120 is hiervoor geschikt gemaakt doordat voorraad- en verkoopgegevens op het meest specifieke niveau, namelijk het SKU niveau, worden opgeslagen in de database 124.

25 Alle andere gegevens worden hiervan afgeleid. Deze aggregatiestap 202 gebeurt bij voorkeur nadat nieuwe gegevens zijn geïmporteerd in stap 201, hoewel afleiden in (semi) real-time wanneer de gegevens nodig zijn ook tot de mogelijkheden behoort.

Een ander belangrijk onderdeel van voorraad- en inkoopbeheer is het begrip Open to 30 Buy (OTB). Dit betreft reeds gebudgetteerde producten die echter nog niet daadwerkelijk ingekocht zijn. De aggregatiemodule 121 rekent in stap 203 de OTB uit per artikelseizoen en per productgroep. Om de OTB informatie overzichtelijk te presenteren op de schermen worden onderscheiden: het actuele seizoen/de actuele seizoenen, toekomstige seizoenen, een NOOS (Never Out Of Stock) seizoen en een 6 vcrzamelgrocp voor alle artikelseizoenen die afgelopen zijn. Bestaande oplossingen houden geen rekening met seizoenen of berekenen ieder seizoen afzonderlijk door, inclusief alle oude seizoenen afzonderlijk. Zij bieden geen verzamelgroep voor oude seizoenen.

5

Om inzicht te hebben in de voorraad is de forward cover een bekend begrip. Dit is, kort gezegd, het aantal tijdseenheden in de toekomst waarvoor betreffende voorraad beschikbaar is. De aggregatiemodule 121 berekent in stap 204 de forward cover op alle niveaus van de artikelplanninghiërarchie per seizoen direct door. Bij aanpassingen van 10 budget, afprijswaarde of OTB waardes wordt direct online de forward cover herberekend. Doordat met name in de fashion retail steeds meer ‘seizoenen’ per jaar gevoerd worden, duren de seizoenen steeds korter. Direct herberekenen is dan een vereiste om inzicht te kunnen krijgen in de voorraad.

15 Verder plannen veel retailers actief met een gewenste eindvoorraad. Dit is zeer arbeidsintensief en moeilijk door het ontbreken van relevante historische informatie. Actief plannen maakt het tevens vaak lastig om een realistische forward cover uit te rekenen met traditionele methodes. De forward cover wordt dan weergegeven als “aflopend naar het einde van het seizoen”, terwijl dit niet zo is, of met een code die 20 weergeeft “meer dan tot einde seizoen” echter zonder indicatie hoeveel er dan te veel is. Het DRP systeem 120 biedt de mogelijkheid om actief te plannen met gewenste eindvoorraden per periode en aan het einde van een seizoen. Dit wordt gerealiseerd door op ieder niveau van de productplanninghiërarchie de gewenste eindvoorraad te genereren, in de gewenste dimensie (stuks, kostprijswaarde, verkoopwaarde) en op basis 25 van historische gewenste of gerealiseerde eindvoorraden.

Om met de forward cover een zo goed mogelijk inzicht te geven in het aantal periodes dat afgedekt wordt met een actieve planning, kent de forward cover berekening in de aggregatiemodule 121 twee mogelijkheden: 30 (1) Indien de voorraad niet voldoende is tot het einde van het seizoen, kan de cover uit gerekend worden door voorwaarts in de tijd te berekenen tot en met wanneer de voorraad voldoende toereikend is.

7 (2) Indien de voorraad wel voldoende is, vindt een alternatieve berekening plaats. Eerst wordt de gemiddelde verkoop per periode bepaald tot het einde van het seizoen. Hierna wordt de voorraad gedeeld door de gemiddeld verwachte verkoop en seizoenen Indien van de huidige periode al een voorraad in de tabellen met historische gegevens in 5 de database 124 staat, worden deze tabellen verwijderd zoals hierboven aangegeven bij de importeerstap 201. Hierna wordt de huidige voorraad opgeslagen in de historie-tabellen op alle niveaus.

Het DRP systeem 120 bepaalt automatisch de gewenste berekeningswijze (in batch en 10 online) voor iedere combinatie van artikelplanningniveau, seizoen en periode. Met deze werkwijze kan altijd het beste inzicht in de cover gegeven worden.

Het DRP systeem 120 biedt de mogelijkheid een seizoen op te delen in vrij te kiezen periodes. Zo kan er bijvoorbeeld gekozen worden voor weken, maanden, halve 15 maanden of periodes van 4-4-5 weken. Het seizoensbudget en de eventuele afprijswaarde per productgroep uit de merchandise planning wordt automatisch verdeeld over de periodes op basis van profielen uit het verleden. Op basis van wegingsfactoren per j aar kan een gewicht meegegeven worden aan het verleden. De verdeling vindt altijd plaats op het laagste niveau van de planninghiërarchie, aangezien 20 de profielen zeer verschillend kunnen zijn per productgroep en er worden aparte profielen gebruikt voor het verdelen van de verkoopbudgetten en de afprijsbudgetten.

Ook indien de retailer budgetteert op nieuwe productgroepen is het mogelijk de planning te verdelen over de periodes. De aggregatiemodule 121 bekijkt daartoe of er 25 wel profielen zijn op het eerste niveau boven het laagste productgroepniveau. Indien deze bekend zijn, worden deze profielen gebruikt. Indien ook op dit niveau geen profielen uit het verleden bekend zijn, wordt weer een niveau hoger geanalyseerd of er profielen aanwezig zijn. Dit proces gaat door tot een niveau bereikt wordt waarop wel profielen bekend zijn. Met dit proces wordt de best mogelijke verdeling van de 30 budgetten over de periodes bereikt, zonder handmatig ingrijpen van de gebruiker.

In de merchandise planning wordt altijd gepland per artikelseizoen. Artikelseizoenen hebben een start- en einddatum. De OTB vindt plaats per seizoen. De geplande eindvoorraad van een seizoen wordt aan het einde van dat seizoen opgeteld bij de 8 voorraad van oude seizoenen. Bij zogenaamde NOOS of never-out-of-stock product groepen is dit niet de bedoeling. NOOS artikelen blijven courante artikelen ook aan het einde van een seizoen. Het DRP systeem 120 heeft de mogelijkheid met een parameter vast te leggen welke product groepen NOOS product groepen zijn. In de OTB 5 berekening wordt dan niet gekeken naar de start- en einddatum van een seizoen, maar de NOOS data (verkopen, voorraad, inkopen, budgetten) wordt gesommeerd van alle artikelseizoenen. De voorraad wordt ook niet oud aan het einde van een seizoen.

Bovenstaande beschrijving dient slechts ter illustratie van enkele uitvoeringsvormen van 10 de uitvinding. Het zal de vakman duidelijk zijn dat op diverse punten kan worden afgeweken van de beschreven uitvoeringen en stappen bij het hanteren van de wezenlijke maatregelen van de uitvinding. Hoewel de uitvinding is beschreven in de context van de retail industrie, met name de fashion retail industrie, is deze niet beperkt daartoe. De uitvinding kan toepassing vinden in alle situaties waarin behoefte is aan het 15 verwerken van transactiegegevens, waarbij uit de transactiegegevens geaggregeerde informatie over transacties wordt afgeleid, en de transactiegegevens van één of meer point-of-sale systemen in een database worden geïmporteerd.

Claims (6)

1. Systeem (120) voor het verwerken van transactiegegevens, voorzien van aggregeermiddelen (121) voor het uit de transactiegegevens afleiden van geaggregeerde 5 informatie over transacties, en van importeermiddelen (122) voor het importeren van de transactiegegevens van één of meer point-of-sale systemen (101-a,101-n) in een database (124), gekenmerkt door het telkens na het importeren van de transactiegegevens opnieuw afleiden van de volledige geaggregeerde informatie over de transacties. 10

2. Systeem volgens conclusie 1, waarbij de importeermiddelen (122) zijn geconfigureerd voor het op periodieke basis, zoals één maal dagelijks, importeren van de transactiegegevens in de database (124).

3. Systeem volgens conclusie 1 of 2, waarbij de importeermiddelen (122) zijn geconfigureerd voor het bepalen van een oudste transactiedatum van de transactiegegevens, voor het op basis van deze oudste transactiedatum verwijderen van reeds in de database (124) aanwezig zijnde transactiegegevens die eenzelfde of een jongere transactiedatum hebben als de oudste transactiedatum, en voor het vervolgens 20 importeren van de transactiegegevens van de één of meer point-of-sale systemen.

4. Systeem volgens conclusie 1, ingericht om transactiegegevens op het niveau van combinaties van artikel, kleur en maat op te slaan in de database (124).

5. Computerprogrammaproduct voor het realiseren van het systeem van conclusie 1 met behulp van een processor.

6. Computerprogrammaproduct volgens de vorige conclusie, uitgevoerd als een webgebaseerde softwareapplicatie. 30