NL2002332C2

NL2002332C2 - Point-of sale systems transaction data processing system for fashion retail market, has resources aggregated to derive aggregated information about transactions, where transaction data of point-of sale systems are imported in database

Info

Publication number: NL2002332C2
Application number: NL2002332A
Authority: NL
Inventors: Martijn Frido Hans Hendriks; Zeger Jacobus Dirk De Baat; Robert Van Serveen
Original assignee: Finch Intellectual Properties
Priority date: 2008-12-16
Filing date: 2008-12-16
Publication date: 2009-06-08
Also published as: NL2002332A1

Abstract

The system has a set of resources (122) aggregated to derive aggregated information about transactions. Transaction data of point-of sale systems (101-a-n-101) is imported in a database (124), and the transaction data are imported again to derive full aggregate information about the transactions. The resources are configured on a regular basis to import data in the database. An import unit is configured for determining an oldest transaction date of the transaction data, based on an earliest transaction date in the database. An independent claim is also included for a computer program product comprising a set of instructions for processing transaction data.

Description

Titel van de uitvindingTitle of the invention

Systeem voor het verwerken van transactiegegevens.System for processing transaction data.

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.Field of the invention The invention relates to a system for processing transaction data, provided with aggregating means for deriving aggregated information on transactions from the transaction data, and with importing means for importing the transaction data from one or more point-of-points sale systems in a database.

1010

De uitvinding heeft tevens betrekking op een computerprogrammaproduct voor het realiseren van het bovengenoemde systeem met behulp van een processor.The invention also relates to a computer program product for realizing the above-mentioned system with the aid of a 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.Background of the invention The retail market, in particular the fashion retail market, is characterized by very large quantities of sales transactions. One can think of millions to more than 100 million transactions per year, spread over various branches in a potentially large geographical area. Processing such large numbers of transactions must be done with the greatest care, and therefore requires support with the right technology.

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.A conventional technical system for this purpose functions briefly as follows. The point of sale (POS) systems at the various branches process the cash transactions. Data about these transactions is read out at fixed times, for example once a day, and forwarded to a central system for further processing. Use can be made here of an intermediate step in which a computer system in the branch reads out the individual POS systems and forwards the collected data to the central system. It is also possible that the central system makes direct contact with the individual POS systems. Stock and purchase management of the retailer can then be based on the aggregated data of the POS systems.

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.A disadvantage of this approach is that it is prone to error. It appears regularly in practice that contact cannot be made with a POS system at a readout moment, for example due to disruptions in the telecommunication infrastructure at a branch or simply because the POS system has been accidentally switched off. This means that the transaction data for that period cannot be processed. Data from several periods must then be collected at the next moment of release, something that not all POS systems are capable of.

55

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.Another problem with known solutions is that if items with an incorrect product group code are sold, these sales remain aggregated on the incorrect product group codes. This causes errors in the aggregated sales history.

10 Samenvatting van de uitvindingSummary of the invention

De uitvinding stelt zich ten doel een verbeterd systeem voor het verwerken van transactiegegevens van POS systemen te bieden.The invention has for its object to provide an improved system for processing transaction data from POS systems.

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.This object is achieved according to the invention by means of a system as indicated in the preamble, characterized by the derivation of the complete aggregated information about the transactions each time after importing the transaction data. This ensures that the required data is as accurate as possible and always up-to-date. This prevents errors in reading data from having an effect on long-term planning. After a correction at transaction level, the corrected data is after all imported, after which the entire long-term planning is derived again from the corrected data.

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.In an advantageous embodiment, the importing means are configured to determine an oldest transaction date of the transaction data, to delete transaction data already present in the database on the basis of this oldest transaction date and having the same or a younger transaction date as the oldest transaction date, and for subsequently importing the transaction data from the one or more point-of-sale systems. This realizes in a simple but effective way that the most current transaction data is used instead of possibly outdated or incorrect transaction data from a previous import stroke. This increases the accuracy and topicality of the transaction data that is aggregated.

Tevens biedt de uitvinding een computerprogrammaproduct voor het realiseren van het bovengenoemde systeem met behulp van een processor.The invention also provides a computer program product for realizing the above-mentioned system with the aid of a processor.

Enkele andere voordelige uitvoeringsvormen van de uitvinding staan genoemd in de volgconclusies.Some other advantageous embodiments of the invention are mentioned in the subclaims.

3 5 Korte beschrijving van de figurenBrief description of the figures

De uitvinding zal hierna worden toegelicht aan de hand van de figuren, waarin:The invention will be explained below with reference to the figures, in which:

Fig. 1 schematisch een systeemarchitectuur volgens de uitvinding illustreert;FIG. 1 schematically illustrates a system architecture according to the invention;

Fig. 2 schematisch een procesverloop volgens de uitvinding illustreert.FIG. 2 schematically illustrates a process flow according to the invention.

1010

Beschrijving van enkele uitvoeringsvormenDescription of some embodiments

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.FIG. 1 schematically shows a system architecture according to the invention. In this architecture, a system is assumed in which multiple POS systems 101-a to 101-n of a retailer each send their transaction data to an Enterprise 15 Retail Planning (ERP) system 110 of the retailer. In an alternative embodiment, a central processing unit in each branch collects the transaction data from all POS systems 101-to-101-n in that branch and sends it in combined form to the ERP system 110. Sending the transaction data can be done in various ways . Commonly used options are data transmission via a direct telephone 20 or ISDN connection and data transmission via the 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.The ERP system 110 is linked to the Darwin Retail Planner (DRP) 120 system, which takes care of merchandise planning and inventory and purchasing planning. The DRP system 120 has, inter alia, an aggregation module 121 for deriving aggregated transaction information from the transaction data, and an import module 122 for importing the transaction data from the POS systems 101-a, ..., 101-n , as well as a database 124. The operation of the DRP system 120 is further discussed below. The link is preferably realized by exporting all relevant data to a file that the DRP system 120 subsequently reads into its own database 124 once per specific period of time, such as daily at two o'clock at night, which can be automated by known techniques. A real-time link is of course also possible, but in most cases not necessary.

44

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.The link between ERP system 110 and DRP system 120 can be technically realized in many ways. The choice will depend on, for example, which ERP software is used by the retailer and what possibilities for linking, exporting or exchanging data this software offers. A well-known and commonly used way is to have the ERP package export the data to a comma-separated file (CSV) that can be imported by DRP system 120. Export in XML format or any other desired format is also possible.

Het DRP systeem 120 kan worden geïmplementeerd als een 10 computerprogrammaproduct dat met behulp van een processor wordt uitgevoerd.The DRP system 120 can be implemented as a computer program product that is executed using a processor.

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.An example is a software application that is loaded and executed on a personal computer or comparable computer system. The software application then contains the computer instructions that perform the steps by which the DRP system 120 is realized. These steps relate to the process flow that is shown below in FIG. 2 is discussed. Preferably, the DRP system 120 is then implemented using Microsoft's .NET environment, although other languages such as Java are also suitable in principle.

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.The DRP system 120 is preferably realized as a web-based software application. This application can be installed within the network of the retailer so that all (after all sensitive) data remains under his control. An alternative is to place the DRP system 120 at a centralized location with a supplier. For example, various retailers can use the DRP system 120 at the same time without having to take care of installation, configuration and maintenance of the DRP system 120. Of course, in that case the following measures must be taken to ensure the security of the data at the supplier. to guarantee. For the database 124, many products are available from various suppliers. Preferably, a SQL database is used.

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.FIG. 2 schematically illustrates a process flow, which is preferably implemented by the DRP system 120. The first step 201 in the process is to import the data from the mounted ERP system 110, which step is performed by the above-mentioned import module 122. Hereby no use is made of the known delta technique in which only differences (delta's) with respect to earlier 5 imported data are downloaded. The delta technology is error-prone. According to the invention, the import module 122 imports all data that is available to the database 124, even if it was previously present in this database 124.

55

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.In a preferred embodiment, the import module 122 thereby determines the oldest transaction date of the data being imported. Based on this oldest transaction date, all transaction data that has the same or a younger transaction date is deleted in its own database 124. The supplied transaction data is then placed in the database 124. For extra security, the data to be deleted can be placed in a backup table, so that in the event of an incorrect or prematurely interrupted import, this data can be easily restored.

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.The DRP system 120 is responsible for, among other things, the planning of products to be purchased. This requires aggregation of inventory and sales data to different levels, from a specific item / color / size (SKU) combination to higher aggregation levels such as "winter clothing" or "sports clothing". The data must also be made transparent by period, for example per week, month or changing periods of numbers of weeks. To this end, the DRP system 120 is equipped with aggregation module 121.

2020

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.In the retail industry, especially the fashion retail industry, rapidly changing collections with many items must be taken into account. The DRP system 120 is made suitable for this purpose by storing inventory and sales data at the most specific level, namely the SKU level, in the 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.25 All other data is derived from this. This aggregation step 202 preferably occurs after new data has been imported in step 201, although it is also possible to derive in (semi) real-time when the data is needed.

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.Another important part of inventory and purchasing management is the term Open to 30 Buy (OTB). This concerns already budgeted products that have not actually been purchased yet. In step 203, the aggregation module 121 calculates the OTB per item season and per product group. In order to present the OTB information in a well-organized manner on the screens, the following are distinguished: the current season / seasons, future seasons, a NOOS (Never Out Of Stock) season and a 6-item collection for all item seasons that have ended. Existing solutions do not take seasons into account or charge each season separately, including all old seasons separately. They do not offer a collection group for old seasons.

55

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.The forward cover is a well-known concept to gain insight into the stock. In short, this is the number of time units in the future for which the relevant stock is available. In step 204, the aggregation module 121 directly calculates the forward cover at all levels of the item planning hierarchy per season. For adjustments of 10 budget, discounted value or OTB values, the forward cover is recalculated directly online. Because more and more 'seasons' are fed per year, especially in fashion retail, the seasons are becoming shorter and shorter. Direct recalculation is then a requirement to gain insight into the stock.

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.15 Many retailers are also actively planning with a desired closing stock. This is very labor intensive and difficult due to the lack of relevant historical information. Active planning also often makes it difficult to calculate a realistic forward cover with traditional methods. The forward cover is then displayed as "descending to the end of the season", while this is not the case, or with a code that shows 20 "more than until the end of the season" but without indication of how much there is then too much. The DRP system 120 offers the possibility to actively plan with desired closing stocks per period and at the end of a season. This is achieved by generating the desired closing stock at each level of the product planning hierarchy, in the desired dimension (units, cost price value, selling value) and on the basis of historically desired or realized closing stocks.

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.To provide the best possible insight into the number of periods covered by active planning with the forward cover, the forward cover calculation in the aggregation module 121 has two options: 30 (1) If the stock is not sufficient until the end of the season, the cover can be calculated by calculating forward in time up to and including when the stock is sufficiently adequate.

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.7 (2) If the stock is sufficient, an alternative calculation will take place. First the average sale per period is determined until the end of the season. After this the stock is divided by the average expected sales and seasons. If a stock of the current period is already in the tables with historical data in the database 124, these tables will be deleted as indicated above at the import step 201. After this the current stock will be stored in the history tables at all levels.

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.The DRP system 120 automatically determines the desired calculation method (in batch and 10 online) for each combination of item planning level, season and period. With this method the best insight into the cover can always be given.

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.The DRP system 120 offers the possibility to divide a season into freely selectable periods. For example, you can choose for weeks, months, half 15 months or periods of 4-4-5 weeks. The seasonal budget and any discount value per product group from the merchandise planning is automatically divided over the periods based on profiles from the past. Based on weighting factors per year, a weight can be given to the past. The distribution always takes place at the lowest level of the planning hierarchy, since the profiles can be very different per product group and separate profiles are used for distributing the sales budgets and the down-payment budgets.

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.Even if the retailer budgeted for new product groups, it is still possible to divide the planning over the periods. For this purpose, the aggregation module 121 examines whether there are 25 profiles on the first level above the lowest product group level. If these are known, these profiles are used. If no profiles from the past are known at this level either, a higher level is analyzed to see whether there are any profiles present. This process continues until a level is reached at which profiles are known. This process achieves the best possible distribution of the 30 budgets over the periods, without manual intervention by the user.

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.In the merchandise planning is always planned per article season. Article seasons have a start and end date. The OTB takes place per season. The planned closing stock of a season is added to the 8 stock of old seasons at the end of that season. With so-called NOOS or never-out-of-stock product groups, this is not the intention. NOOS articles remain current articles even at the end of a season. The DRP system 120 has the option to determine with a parameter which product groups are NOOS product groups. In the OTB 5 calculation, the start and end date of a season is not considered, but the NOOS data (sales, stock, purchases, budgets) is summed for all item seasons. The stock does not get old at the end of a season.

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.The above description merely serves to illustrate some embodiments of the invention. It will be apparent to those skilled in the art that deviations can be made on various points from the described embodiments and steps in handling the essential features of the invention. Although the invention has been described in the context of the retail industry, in particular the fashion retail industry, it is not limited thereto. The invention can find application in all situations where there is a need for processing transaction data, in which aggregated transaction information is derived from the transaction data, and the transaction data from one or more point-of-sale systems are imported into a database.

Claims

A system (120) for processing transaction data, provided with aggregating means (121) for deriving aggregate information on transactions from the transaction data, and with importing means (122) for importing the transaction data from one or more point of -sale systems (101-a, 101-n) in a database (124), characterized by deriving the complete aggregated information about the transactions each time after importing the transaction data. 10

The system of claim 1, wherein the importing means (122) are configured to periodically, such as once daily, import the transaction data into the database (124).

A system according to claim 1 or 2, wherein the importing means (122) are configured to determine an oldest transaction date of the transaction data, for removing transaction data already present in the database (124) based on this oldest transaction date and having the same or have a younger transaction date as the oldest transaction date, and then import the transaction data from the one or more point-of-sale systems.

The system of claim 1, arranged to store transaction data at the level of item, color and size combinations in the database (124).

A computer program product for realizing the system of claim 1 using a processor.

A computer program product according to the preceding claim, implemented as a web-based software application. 30