NO332028B1 - Fremgangsmate og system for overforing av underretninger til brukere av et logistisk system - Google Patents

Abstract

Oppfinnelsen vedrører en fremgangsmåte og et system for overføring av underretninger til brukere av et logistisk system. Oppfinnelsen er kjennetegnet ved at forskjellige hendelser i det logistiske systemet brukes til å kalle opp forskjellige moduler med respektive tilhørende funksjoner. Modulene danner underretningsordre som blir overført til en sentral sendingskomponent (30). Sendingskomponenten danner underretninger som korresponderer med ordrene og sender disse underretningene til brukerne.

Description

Fremgangsmåte og system for overføring av underretninger til brukere av et logistisk system

Foreliggende oppfinnelse vedrører en fremgangsmåte for overføring av underretninger (notifications) til brukere av et logistisk system, hvor det logistiske systemet innbefatter et eller flere pakkeromssystemer med en eller flere registrerte brukere, og ved hvilken fremgangsmåte underretningsordrene blir overført til en sentral sendingskomponent som, på basis av ordrene, generere passende underretninger og sender dem til brukerne, hvorved sendingskomponenten, for å generere underretningene, aksesserer en eller flere databaser.

Oppfinnelsen vedrører også et system for overføring av underretninger til brukere av et logistisk system som opererer et eller flere pakkeromssystemer.

For å kunne operere logistiske systemer med et mangfold brukere og en eller flere logistikkleverandører, må en viss informasjon overføres til abonnentene i systemet. Overføringen av informasjon blir i det etterfølgende betegnet som underretning. Slike underretninger kan skje via en eller flere forskjellige typer av kommunikasjon.

Underretninger blir sendt på grunnlag av hendelser som har opptrådt i det logistiske systemet. I denne kontekst, kan en hendelse i det logistiske systemet utløse ingen underretning eller en eller flere underretninger. Allokeringen av hendelser i det logistiske systemet til underretninger kan utføres innen en underretningskomponent som en funksjon av en foretningslogikk.

Underretninger kan overføres via forskjellige typer kommunikasjon. Her er typen av kommunikasjon måten som en underretning leveres på. Som et prinsipp, kan en underretning med samme informasjonsinnhold leveres via flere forskjellige typer kommunikasjon.

Et logistisk system med forskjellige underretninger og kommunikasjonstyper er nødvendig, spesielt når et pakkeromssystem for registrerte brukere blir operert av et transport- og leveringsfirma. Slike pakkeromssystemer eller automatiske pakkeutleveringsmaskiner blir operert for eksempel av en posttjenestetilbyder for registrerte brukere til hvilke en leverandør leverer pakker eller andre forsendelser i et rom i systemet. Brukeren må deretter underrettes om at det har blitt levert en pakke til ham. Videre må det logistiske systemet bli informert om hvorvidt for eksempel en bruker har hentet pakken sin. Videre må informasjon om registrering av nye klienter, klientdata, hentefrister og COD-avgifter måtte utveksles i det logistiske systemet.

I et logistisk system for pakkeromssystemer, blir underretninger typisk sendt med e-post eller SMS. Dannelse, administrering og sending av underretningene innbefatter fortrinnsvis forskjellige databaser og prosessekvenser.

Det er kjent logistiske systemer for distribusjon av gods. Godset som skal distribueres kan være alle typer av produkter, materialer og objekter. Logistiske systemer virker til å organisere og overvåke distribusjonen av det angjeldende godset, for eksempel mellom lagre, mellomlagringsanlegg, containere, kjøretøy, sendere og mottagere via forskjellige transportruter. Funksjonene til de logistiske systemene er fordelaktig anpasset til kravene på en slik måte at distribusjonen av godset kan optimaliseres, for eksempel med hensyn til transportruter, kapasitetsutnyttelser, lagringstider og dataoverføring.

Søkeren gjør spesielt bruk av logistiske systemer for distribusjon av brev og gods (pakker, forpakninger), transportbokser, paller og containere. De tilhørende logistiske systemene virker fortrinnsvis til å distribuere forsendelser mellom en sender og en mottager, hvorved for eksempel kriterier så som transporthastighet, utnyttelse av lagre og kjøretøyer og overføring av forsendelsesdata er av betydning.

Tysk bruksmønster 201 03 564 U1 beskriver for eksempel et system for levering og mottak av forsendelser som synes å være spesielt hensiktsmessig for e-handel. Systemet innbefatter flere automatiske utleveringsmaskiner (ADM) hvori forsendelsene blir plassert og hentet ut. Systemet innbefatter også et LAM IS server-datamaskinprogram for håndtering av operasjonene i systemet. Klienten blir informert, for eksempel via kommunikasjonstyper så som e-post, om forsendelsene som er levert ham via

ADM.

Internasjonal patentsøknad WO 02/50705 A beskriver et elektronisk dokumentdistribusjonssystem innbefattende en byggemodul som integrerer kreativt innhold med en dokumentmal for å danne et elektronisk hoveddokument som blir overført til en mottagerlist av en sendemodul i overensstemmelse med leverings- og tidsplanleggingsdetaljer. En innfangningsmodul mottar og prosesserer automatisk kvitteringer fra mottagere av det elektroniske dokumentet. Systemet har anvendelse ved kampanjer med epostutsendelser i stort volum for markedsføring av varer og tjenester. Det kan også innbefatte et oppfyllelsesgrensesnitt som sporer oppfyllelse av ordre mottatt fra mottagerne og et elektronisk handelsgrensesnitt som hjelper til med finansielle transaksjoner for betaling av bestilte varer eller tjenester.

Videre beskriver U.S. patent nr. 6,047,264 en fremgangsmåte for overføring av statusen til en forsendelse til en bruker, hvor det blir generert en innføring i en sentral database når en bruker bestiller en forsendelse. Dersom statusen til forsendelsen endres, for eksempel nå den overføres til et distribusjonsfirma, når den transporteres til forskjellige stasjoner eller når den ankommer ved destinasjonen, vil statusendringen bli innsamlet i databasen. Denne innsamlingen kan utføres manuelt eller elektronisk. Via en spørremodul, vil en underretningskomponent kontinuerlig forespørre statusendringer fra databasen og generere meldinger til brukeren av en forsendelse for hvilken statusen er endret. Underretningen skjer fortrinnsvis via e-post.

U.S. patent nr. 6.220.509 B1 beskriver et pakkesporingssystem hvor statusinformasjon om en forsendelse blir registrert direkte inn i klientdatabasen. I dette tilfellet blir klientdatabasen fortrinnsvis aksessert via en internett web-side.

Europeisk patent nr. EP 0 491 367 A2 beskriver en fremgangsmåte for behandling av meldinger hvor ordre er lagret i en kø for å utføres på en kontrollert måte. Her kan ordrene være anpasset til forskjellige betingelser og trekk ved destinasjonene og kommunisere koblinger. Fremgangsmåten er spesielt godt anpasset for bruk i e-post systemer.

Hensikten med oppfinnelsen er å tilveiebringe en fremgangsmåte og en anordning for overføring av underretninger til brukere av et logistisk system som tillater den mest mulig fleksible respons for forskjellige hendelser i systemet og dannelse av brukerspesifikke underretninger.

I henhold til oppfinnelsen, blir denne hensikten oppnådd med trekkene i de selvstendige kravene 1 og 5. Fordelaktige utførelsesformer av oppfinnelsen fremgår av de uselvstendige kravene 2 til 4.

I henhold til oppfinnelsen blir denne hensikten oppnådd ved at, som respons til forskjellige hendelser i det logistiske systemet, blir forskjellige moduler med tilhørende funksjoner kalt opp i hvert tilfelle, hvorved modulene genererer ulike underretningsordre som blir overført til en sentral sendingskomponent som, på grunnlag av ordrene, genererer passende underretninger og sender dem til brukerne.

Hensikten blir også oppnådd ved et system for utøvelse av fremgangsmåten.

Modulene med de tilhørende funksjonene for reaksjon på hendelser i det logistiske systemet danner et eksternt grensesnitt via forskjellige Use Cases blir registrert. I en spesielt fordelaktig utførelsesform av oppfinnelsen, blir underretningsordre generert av modulene kun overført direkte til sendingskomponenten i spesielle tilfeller, mens de som regel blir skrevet inn i en kommunikasjonsforespørselskø. En køleser avleser ordrene fra kommunikasjonsforespørselskøen på en tidskontrollert måte og overfører dem til en sentrale sendingskomponenten. Før dette, blir statusen til underretningen kontrollert. En statusendring kan gjøres, for eksempel ved at en pakke har blitt hentet i mellomtiden eller personen som henter pakken har blitt endret.

I henhold til et trekk ved oppfinnelsen, genererer sendingskomponenten underretningene på grunnlag av data fra en eller flere databaser. Disse databasene er fordelaktig minst en klientdatabase, en automatisk pakkeutleveringsmaskindatabase og en dokumentdatabase. Klientdatabasen inneholder for eksempel data vedrørende registrerte klienter i det logistiske systemet, hvorved hver klient mottar en ID i identifikasjonsøyemed. Disse dataene kan inneholde adresser, telefonnumre eller annen informasjon. Pakkedatabasen inneholder informasjon om pakkene som blir transportert innen systemet, hvorved pakkene på tilsvarende måte blir identifisert ved hjelp av en ID. Den automatiske pakkeutleveringsmaskindatabasen inneholder informasjon vedrørende pakkeromssystemene som brukes innen systemet. Dette innbefatter likeledes ID'er.

Dokumentdatabasen inneholder maler (templater) for å generere brukerspesifikke underretninger. I denne hensikt, innbefatter den fortrinnsvis maler for e-post og SMS underretninger. Malene har plassholdere i hvilke de brukerspesifikke dataene fra databasene blir innført.

Sendingskomponenten overfører de genererte underretningene til en systemport slik at de kan bli sendt til brukerne.

Ytterligere fordeler, spesielle trekk og praktiske utførelsesformer av oppfinnelsen vil fremgå fra de underordnede kravene og fra den etterfølgende presentasjon av foretrukne utførelsesformer, med henvisning til figurene.

Figurene viser følgende:

Figur 1 viser prosessekvensen mellom et eksternt grensesnitt, en sentral sendingskomponent og en kommunikasjonsforespørselskø til en spesielt foretrukket utførelsesform; Figur 2 viser prosessekvensen mellom en kommunikasjonsforespørselskø, en sentral sendingskomponent og en leveringskontraktslogikk til en spesielt foretrukket utførelsesform; Figur 3 viser prosessekvensen mellom en sentral sendingskomponent, forskjellige databaser og en systemport; og Figur 4 viser en generell oversikt over sekvensene i systemet for overføring av underretninger.

Under er det beskrevet et logistisk system for operasjon av et system innbefattende et eller flere pakkeromssystemer med variabelt antall registrerte brukere. Dette er en spesielt foretrukket utførelsesform av oppfinnelsen, men fremgangsmåten i henhold til oppfinnelsen er også hensiktsmessig for andre logistiske systemer hvor det sendes underretninger.

Det logistiske systemet for operasjon av et eller flere pakkeromssystemer er oppdelt, for eksempel i minst de følgende prosesstrinnene på grunnlag av funksjonene:

UC NBK1 bekreftelse av registreringen av en klient

UC NBK2 endring av klientdata

UC BNK3 underretning 'ny pakke'

UC BNK5 underretning 'pakke ble hentet'

UC BNK6 underretning 'pakke ble sendt tilbake'

UC BNK7 underretning 'substitutt lagt til'

UC BNK8 underretning 'substitutt fjernet'

Underretninger blir sendt til brukeren for de ovennevnte hendelsene i systemet og disse underretningene informerer brukeren om hendelsen og/eller bekrefter denne. I en spesielt foretrukket utførelsesform av oppfinnelsen, blir utførelsen av individuelle behandlingstrinnene utført med forskjellige moduler og/eller enheter til det logistiske systemet. Disse modulene kan for eksempel være en klientdatabase, en registreringsenhet eller en systemadministrasjonsenhet for det logistiske systemet. Modulene, eventuelt sammen med andre komponenter, danner et eksternt grensesnitt 10.

Sekvensen og funksjonsprosedyrekallet innen modulen blir forklart under. Underretningsordrene generert av modulene blir enten overført til en sentral sendingskomponent 30 slik at de kan sendes umiddelbart eller de kan leses inn i en kommunikasjonsforespørselskø 40 slik at de kan sendes på en forsinket måte. Alle de ventende underretningsordrene blir jevnlig avlest fra denne køen og passende underretninger blir sendt. Dannede underretninger blir fortrinnsvis sendt med e-post eller SMS.

UC BNK1 bekreftelse av registreringen

Etter registreringen av en ny klient i det logistiske systemet til pakkeromssystemene, kaller en registreringsmodul opp en funksjon.

newRecipient (User)

for å sende en bekreftelsesunderretning. Funksjonen bestemmer de nødvendige underretningene på grunnlag av klientell logikken til klientellet forbundet med klienten og nevnte funksjon legger denne inn i en kommunikasjonsforespørselskø slik at de kan bli sendt på en forsinket måte.

UC BNK2 Endring av klientdataene

Etter at en klient er endret, blir hans klientdata lagret i en klientdatabase, hvilken klientdatabase kaller opp en funksjon

updateRecipient (User)

for å sende en bekreftelsesunderretning. Denne funksjonen bestemmer likeens de nødvendige underretningene på grunnlag av klientell logikk til klientellet forbundet med klienten og nevnte funksjon går inn i enn

kommunikasjonsforespørselskøen slik at de kan sendes på en forsinket måte.

UC BNK3 Underretning 'ny pakke'

Når en pakke blir levert til en automatisk pakkeutleveringsmaskin i et logistisk system, blir informasjon om dette sendt til en systemadministrasjonsenhet til det logistiske systemet. Systemadministrasjonsenheten til det logistiske systemet kaller opp en funksjon

notifyDelivery (Parcel)

for å sende en bekreftelsesunderretning. Denne funksjonen bestemmer de nødvendige underretningene på grunnlag av klientell logikken til klientellet forbundet med pakken og denne funksjonen legger inn dette i kommunikasjonsforespørselskøen slik at de kan sendes på en forsinket måte.

UC BNK5 Underretning 'pakke ble hentet'

Når en pakke har blitt hentet fra en automatisk pakkeutleveringsmaskin til et logistisk system, blir informasjon om dette sent til

systemadministrasjonsenheten til det logistiske systemet.

Systemadministrasjonsenheten til det logistiske systemet vil da kalle opp en funksjon

notifyPickup (Parcel)

for å sende en bekreftelsesunderretning. Funksjonen bestemmer de nødvendige underretningene på grunnlag av klientell logikken til klientellet forbundet med pakken og nevnte funksjon legger dette inn i kommunikasjonsforespørselskøen.

UC BNK6 Underretning 'pakke ble sendt tilbake'

Når en pakke har blitt sendt tilbake fra en automatisk pakkeutleveringsmaskin til et logistisk system fordi den ikke ble hentet før en viss hentefrist, blir informasjon om dette sendt til systemadministrasjonsenheten til det logistiske systemet. Systmadministrasjonsenheten til det logistiske systemet kaller opp en funksjon

ParcelFailed (Parcel)

for å sende en bekreftelsesunderretning. Funksjonen bestemmer de nødvendige underretningene på grunnlag av klientell logikken til klientellet forbundet med pakken og nevnte funksjon går inn i

kommunikasjonsforespørselskøen.

UC BNK7 Underretning 'substitutt lagt til'

Når et substitutt har blitt lagt til for en ventende pakke i en automatisk pakkeutleveringsmaskin til et logistisk system, blir informasjon om dette sent til systemadministrasjonsenheten til det logistiske systemet. Systemadministrasjonsenheten til det logistiske systemet kaller deretter opp en funksjon

addSubstitute (Parcel, User)

for å sende en bekreftelsesunderretning. Funksjonen bestemmer de nødvendige underretningene på grunnlag av klientell logikken til klientellet forbundet med pakken og nevnte funksjon går inn i

kommunikasjonsforespørselskøen.

UC BNK8 Underretning 'substitutt fjernet'

Når et tillagt substitutt har blitt fjernet for en ventende pakke i en automatisk pakkeutleveringsmaskin til et logistisk system, blir informasjon om dette sendt til systemadministrasjonsenheten til det logistiske systemet. Systemadministrasjonsenheten til det logistiske systemet kaller opp en funksjon

removeSubtitue (Parcel, User)

for å sende en bekreftelsesunderretning. Funksjonen bestemmer de nødvendige underretningene på grunnlag av klientell logikken til klientellet forbundet med pakken og nevnte funksjon går inn i

kommunikasjonsforespørselskøen.

I tillegg kan følgende begivenheter kartlegges med funksjoner i modulene: Automatisk pakkeutleveringsmaskin ikke funksjonell NotifyADMfailed

(parcel parcel, Boolean failure)

Generisk underretning genericNotification

(Parcel parcel, Addressable add, int type)

Underretning til leveringstilbyder: pakke levert

notifyDeliveryProvider (Parcel parcel)

Underretning til leverinsgtilbyder: pakke fjernet

notifyPickupProvider (Parcel parcel)

Avdeling (branch)

notifyBranch (String description, DeliveryMachine adm, Addressable recipient, Boolean branchCODparcel)

Produktlås

notifyWarehouseDeliver (String description, DeliveryMachine adm, Addressable recipient)

Adressekontroll feilet

notifyAdressCheckFailed (String description, Addressable recipient)

Internet passord

notifylnternetPassword (String description, Addressable recipient)

Generisk meldingstekst

notifyGenericMessageText (String description, Addressable recipient)

Utleverer returnerer tilbyder

notifyDeliveryReturnsProvider (Parcel parcel)

Avhenter returnerer tilbyder

notifyPickupReturnsProvider (Parcel parcel)

Avhenting av leveringsagenttilbyder

notifyPickupByDeliveryAgentProvider (Parcel parcel)

E-post endret

notifyEmailChanged (Addressable recipient)

Mobiltelefonnummer endret

notifyMobileNumberChanged (Addressable recipient)

Post PIN endret

notifyPostPinChanged (Addressable recipient)

Passord endret

notifylnternetPasswordChanged (Addressable recipient)

Underretningene blir fortrinnsvis sendt I form av en e-post eller SMS. En e-post eller SMS portal kan for eksempel brukes i denne hensikt.

For å bruke fremgangsmåten i henhold til oppfinnelsen i praksis, har det vist seg fordelaktig at listen over ikke-leverbare underretninger blir revidert manuelt ved jevne perioder (for eksempel hver 24 timer).

Tegningene i figurene 1 til 4 viser en oversikt over de mest viktige delkomponentene til en spesielt foretrukket utførelsesform av systemet i henhold til oppfinnelsen. De eksterne systemene er markert med kryss-skravering, mens delene tilhørende underretningssystemet er vist i hvitt.

Tegningen i figur 1 viser strukturen til en spesielt foretrukket utførelsesform av en underretningskomponent. Underretningskomponenten er forbundet med et eksternt grensesnitt 10 som blir kalt opp eksternt når visse hendelser i det logistiske systemet har oppstått. Grensesnittet er dannet av flere moduler, hver med tilhørende funksjoner. Hendelsene i det logistiske systemet blir omdannet til underretningsordre av en B2B konto logikk-komponent (ikke vist her. For visse spesialtilfeller, kan disse ordrene blir sent direkte via en sentral sendingskomponent 30. Som en standardprosedyre, blir ordrene imidlertid skrevet inn i en kommunikasjonsforespørselskø 40 og deretter overført til den sentrale sendingskomponenten 30 på en tidskontrollert måte. Dette tillater for eksempel at påminnelsesunderretninger kan defineres ved senere tidspunkt (for eksempel etter 2 døgn eller 7 døgn). Innskrivingen i køen har også den fordelen at feilslåtte sendingsforsøk automatisk blir gjentatt her.

Tegningen i figur 2 viser prosess-sekvensen etter at underretningsordrene har blitt skrevet inn i kommunikasjonsforespørselskøen 40. Ordrene som er tilstede i kommunikasjonsforespørselskøen 40 blir lest ut av en køleser 50 på en tidskontrollert måte. En kontrollprosedyre kontrollerer igjen mot en B2B leveringskontraktlogikk 20 hvorvidt statusen i mellomtiden er endret. En statusendring har skjedd for eksempel når en anbragt pakke har blitt hentet eller personen som henter den har blitt endret. Dersom valideringen var vellykket, blir en kommunikasjonsforespørsel overført til sendingskomponenten 30.

Tegningen i figur 3 viser prosess-sekvensen i forbindelse med den sentrale sendingskomponenten 30. Prosesstrømmen inne i sendingskomponenten er antydet med piler. Sendingskomponenten mottar ordre eksternt og leser deretter de nødvendige dataene fra de tilhørende databasene i den hensikt å overføre underretningen. Disse databasene innbefatter id et minste en klientdatabase 70, en pakkedatabase 80 og en automatisk pakkeuteleveringsmaskin database 90. Den automatiske pakkeutleveringsmaskin databasen inneholder data vedrørende pakkeromsenhetene til systemet. Deretter blir en mal 110 spesifisert av B2B komponenten 20 lest utfra dokumentdatabasen 100 og plassholdere inne i malen blir erstattet med nåværende data. E-posten eller SMS'en generert på denne måten kan sendes for eksempel vie en e-post eller SMS portal 120.

Tegningen i figur 4 kombinerer de tre delene av underretningskomponenten i en generell oversikt. Her kan man se klart separasjonen mellom den sentrale sendingskomponenten 30 op den høyre siden og delene til forretningslogikk komponenten på den venstre siden.

Under vil de individuelle komponentene til systemet og deres funksjoner i en spesielt foretrukket utførelsesform av fremgangsmåten i henhold til oppfinnelsen blir forklart mer detaljert.

Eksternt grensesnitt

Det eksterne grensesnittet 10 er forbundet med underretningskomponenten og resulterer i en direkte måte fra forskjellige UseCases; ofr hver UseCase, er det fortrinnsvis definert en egen funksjon som oppnår den nødvendige funksjonaliteten i underretningskomponenten. Disse funksjonene korresponderer med hendelsene i det logistiske systemet og vedrører for eksempel pakkeobjekter og/eller brukerobjekter. Funksjonene kan selvfølgelig også utvides og kan også vedrøre andre objekter.

newRecipient (User)

blir kalt opp etter registrering av en ny klient.

updateRecipient (User)

blir kalt opp etter en klient har endret sine klientdata som er lagret i klientdatabasen.

notifyDelivery (Parcel)

blir kalt opp når en pakke har blitt levert til en automatisk pakkeutleveringsmaskin i et logistisk system.

notifyPickup (Parcel)

blir kalt opp når en pakke har blitt hentet fra en automatisk pakkeutleveringsmaskin i et logistisk system.

parcelFailed (Parcel)

blir kalt opp når en pakke har blitt sendt tilbake fra en automatisk pakkeutleveringsmaskin i et logistisk system fordi den ikke ble hentet før en viss hentefrist.

addSubtitute (Parcel, User)

blir kalt opp når et tillagt substitutt har blitt lagt til for en ventende pakke i en automatisk pakkeutleveringsmaskin i et logistisk system.

removeSubstitute (Parcel, User)

blir kalt opp når et substitutt har blitt fjernet for en ventende pakke i en automatisk pakkeutleveringsmaskin i et logistisk system.

De angjeldende Pakke- eller brukerobjektene mottar hver metoder. Internt, blir hendelsen til det logistiske systemet omdannet til underretninger som temporært blir lagret i den interne køen 40. Resultatet tilveiebragt av metodene gir tilbakemelding om hvorvidt denne omdanningen og temporære lagringen virket eller ikke.

Det kan sendes forskjellige typer underretninger hvor hvilke det har vist seg fordelaktig å danne maler 110 og lagre disse i en dokumentdatabase. Typene av underretninger blir kartlagt ved hjelp av et malnavn som klassifiserer malene på nivået til innformasjonsinnholdet i underretningen. I for eksempel B2B tilfellet, er følgende maler nødvendig:

Ny klient registrering BNK1

Endring av klientdata BNK2

Pakkeutlevering BNK3, BNK3N

Pakke har ventet i 48 timer BNK4, BNK4N

Pakke vil bli sendt tilbake

om 48 timer BNK5, BNK5N

Malvarianter for pakker med COD og pakker uten COD kan brukes forde siste tre typene pakkeunderretninger. I tillegg til navnet, blir malene også identifisert via DeliveryContract, kommunikasjonstypen og sproget. I tillegg til de beskrevne malene, kan det selvfølgelig brukes ethvert antall andre maler.

Malene bør være tilgjengelige for alle underretninger som skal sendes i form av SMS så vel som e-post. For sending ev e-post, bør malene fortrinnsvis være tilgjengelige for meldingsteksten så vel som for referanselinjen.

Databaselagring

For å forenkle forvaltningen av malene 110, er de lagret i en database 100.1 en spesielt foretrukket utførelsesform av oppfinnelsen, innbefatter denne databasen flere felter som er angitt i tabellform under:

Det bør legges merke til at, som en funksjon av hendelsen i det logistiske systemet for underretning, kan databasenøkkelen 'Contract' være en LogisticProvider eller en LogisticContractor (i tilfellet med BNK1 og BNK2) ellers en DeliveryContract (i tilfeller BNK3 til BNK5).

Plassholdermekanisme

Det har vist seg fordelaktig å anvende forskjellige plassholdere inne i malene 110 som kan erstattes med konkret informasjon. Med et øye mot anvendelsen av HTML-formatterte e-post, bør disse plassholderne fortrinnsvis ikke være definert som HTML-etiketter.

I det minste kan følgende plassholdere være tilveiebragt:

I tillegg til de beskrevne plassholderne, kan det selvfølgelig også brukes andre plassholdere.

Meldingslengde

Den maksimale lengde for SMS-meldinger er typisk 160 karakterer. Siden viss informasjon - så som lokaliseringen av hendelsen i den automatiske pakkeutleveringsmaskinen til et logistisk system - kan ha variable lengder, kan meget lange felter (for eksempel gater eller byer med bydistriktsinformasjon) medføre en 'overstrøm' på 160 karakterer. For å unngå en slik 'overstrøm' blir det i en spesielt foretrukket utførelsesform av oppfinnelsen brukt en intelligent mekaniske som, avhengig av de individuelle feltlengdene, viktigheten av hvert felt og på tilgjengelig gjenværende lengde, inneholder all vesentlig informasjon i størst mulig grad.

Et alternativ til en intelligent mekanisme er lagring av kortversjoner av alle feltene i passende databaser slik at den maksimale lengden på 160 karakterer aldri overskrides. Dette har imidlertid den ulempen at endring av SMS-malene vil medføre nye lengdebegrensninger. Viss informasjon så som adresse lagt inn av klienten kan derved vanskelig tilpasses.

B2B DeliveryContract logikk

B2B deliveryContract logikken 20 bestemmer hva den individuelle forretningslogikken bør se ut for en viss LogisticProvider, en viss LogisticContractor, og en viss DeliveryContract (mellom en vise logistikk tilbyder og en viss logistikk kontraktør). I dette øyemed blir de individuelle hendelsene omdannet til underretningsordre. Hendelsene i det logistiske systemet newRecipient og updateRecipient avhenger kun av LogisticProvider eller LogisticContractor med hvilke den korresponderende bruker er forbundet. De andre hendelsene i det logistiske systemet vedrører utleveringen av pakker, det vil si de avhenger av LogisticProvider (som transporterer pakken) så vel som LogisticContractor (som definerer mottageren eller leverandøren av pakken). For å implementere logikken, blir det definert en liste over underretninger som skal sendes (kommunikasjonsforespørsler) i hvert tilfelle for det logistiske systemet. Disse kommunikasjonsforespørslene innbefatter flere parametre som kan innstilles.

Hendelser i det logistiske systemet

Flere underretninger kan lagres for hver hendelse, for eksempel dersom det gjøre gjentatte underretninger, eller dersom flere personer med forskjellige roller skal informeres.

Personer som skal underrettes er de personer som skal underrettes. Mulige verdier er: Recipient, Substitute, LogisticProvider eller LogisticContractor.

Det er spesifisert en dato på hvilken underretningen skal sendes. I logikken, er det kun lagret en relativ dato og denne blir deretter beregnet med datoen til hendelsen i det logistiske systemet for å generere en absolutt dato. Mulige verdier er her, for eksempel:

En viss type kommunikasjons kan være spesifisert. Dette er nødvendig for eksempel dersom en viss logikk kun tillater underretning med SMS. Mulige verdier er e-ma/V, SMS og user (kommunikasjonstypen spesifisert for brukeren). På denne måten kan for eksempel en leveringskontraktlogikk kartlegges som utelukkende tillater underretninger via en spesifikk type kommunikasjon.

Fortrinnsvis eksisterer muligheten for å velge en mal 110 som skal brukes for overføringen. Dette har den fordelen at forskjellige tekster kan gjøres anvendelige innen den samme leveringskontrakten, for eksempel for forskjellige hendelser i det logistiske systemet. I tillegg kan malen alltid begrenses ytterligere ved nåværende DeliveryContract. Et viss mal (for eksempel BNK1) kan også ha forskjellig innhold for to forskjellige DeliveryContracts. Videre kan forskjellige versjoner av samme maler holdes tilgjengelige for forskjellig type kommunikasjon.

Videre kan det lagres ytterligere informasjon som brukes for differensiering innen samme forretningslogikk eller som brukes for å kontrollere logikken senere, slik som de to mulige bitene av informasjon beskrevet under:

Differensiering i tilfellet med COD-pakker

Her brukes det en forskjellig mal for pakker med et sett COD-beløp. Denne malen inneholder for eksempel COD-beløpet som informasjon til personen som avhenter pakken.

Det er B2B prosesser i hvilke et COD-beløp er tilstede for pakken, men dette beløpet blir ikke overført til personen som avhenter pakken siden COD er fakturert, for eksempel via samlefakturering.

Kontroll av hvorvidt en pakke ble avhentet

Dette er en kontrolloperasjon som blir utført for å se hvorvidt en pakke fremdeles er i den automatiske pakkeutleveringsmaskinen i det logistiske systemet eller hvorvidt den har blitt avhentet i mellomtiden. Dette er spesielt nyttig dersom påminnelsesunderretninger blir sendt, for eksempel etter noen få dager.

Parce/-objektet må tilveiebringe en fremgangsmåte som tilveiebringer tilbakemelding om utløpsdatoen på hvilken pakken vil bli fjernet fra den automatiske pakkeutleveringsmaskinen. Detter er nødvendig for å kunne være i stand til å overføre underretninger X dager før utløpet. Dersom det ikke har blitt angitt noen utløpsdato, kan det som en standard prosedyre antas et visst antall kalenderdager.

LogisticProvider DPAG (B2C tilfelle)

Den følgende tabellen er et eksempel som definerer underretningene som skal sendes (kommunikasjonsforespørsel) ved tidspunktet for registrering av brukere for en LogisticProvider. Disse er leverandører, ingen underretninger blir sendt.

LogisticContractor —► endelig klient (B2C tilfelle)

Den følgende tabellen er et eksempel som definerer underretningene som skal sendes (kommunikasjonsforespørsler) ved tidspunktet for registreringen av brukere for en virtuell LogisticContractor 'endelig klient'. Dette er hvor alle brukerne som er registrert for B2C blir samlet.

Leveringskontraktlogikk - endelig klient (B2C tilfelle)

Den følgende tabellen er et eksempel som definerer underretningene som skal sendes (kommunikasjonsforespørsler) for B2C logikk mellom en logistikktilbyder og den endelige klienten: LogisticProvider LP (B2B tilfelle)

LogisticContractor LC (B2B tilfelle) DeliveryContract logikk LP -> LC (B2B tilfelle)

CommunicationRequest kø.

Der er nødvendige med en dedikert databasetabell i hvilken ordre for underretninger (kommunikasjonsforespørsler) som skal sendes blir lagret midlertidig. Tabellen bør fortrinnsvis kun tjene hensikten med å håndtere løen; konkret informasjon om f. eks. pakker og mottagere blir alltid lest fra klientdatabasen 70 eller fra pakkedatabasen 80.

Det kan imidlertid være hensiktsmessig å utvide feltene til kommunikasjonsforespørselskøen. For eksempel kan det legges til automatisk pakkeutleveringsmaskin-numre og frie tekstbeskrivelser. På denne måten blir underretninger ikke bare koblet til pakker men eventuelt også til en kombinasjon av postnummere, hendelser og automatisk pakkeutleveringsmaskin-nummere. Videre foreligger det en mulighet for å generere underretninger dynamisk.

Med Comm_ Type innleggingen, vi en verdi User, kan det spesifiseres at underretningen skal gjøres via den typen kommunikasjon som er spesifisert av brukeren. På lignende måte kan verdien User legges inn for sproginnstillingen Lang dersom innstillingene til brukeren skal anvendes. Hvorvidt og i hvilken grad det er nødvendig med en logging av en innlegging (status = 3) avhenger av den konkrete implementeringen.

Tilgang til databaser

Det må tilveiebringes tilgang til følgende databaser i det logistiske systemet: ■ Klientdatabase leverer informasjon om en klient som er definert av klientnummeret ■ LogisticProvider database leverer informasjon om en logistikk-tilbyder ■ LogisticContractor database leverer informasjon om en logistikk-kontraktør ■ DeliveryContract database leverer informasjon om en logistikk-kontraktør ■ Pakkedatabase leverer informasjon om en pakke som har blitt identifisert med et entydig pakkenummer ■ Automatisk pakkeutleveringsmaskin-database leverer informasjon om lokaliseringen til en automatisk pakkeutleveringsmaskin som er identifisert med den automatiske pakkeutleveringsmaskin-ID.

Sekvens ved sending av en underretning

Timer

Underretningskomponenten kontrollerer jevnlig alle ordrene i kommunikasjonskøen 40. Denne blir trigget av en timer 41 i underretningskomponenten. Timerintervallet kan fortrinnsvis utformes fritt.

Kommunikasjonskøleser

Når timerfunksjonen er kalt opp, blir alle innskrivningene hvis sendingsdato er etter foreliggende dato avlest fra

kommunikasjonsforespørselskøen 40.

Rekonstruksjon av objektene

Hver innskriving som er avlest fra køen blir omdannet til et CommunicationReqvest objekt. På grunnlag av den entydige ID'en for brukeren som skal informeres (Recipient-ID) og ID'en for pakken (ParcellD), blir de angjeldende delobjektene rekonstruert. Dette er nødvendig for å kunne forespørre de nåværende dataene til objektene, så som foreksempel e-post adressen.

Begrepet User i dette tilfellet refererer enten til en User, et LogisticProvider objekt eller et LogisticContractor objekt. Alle disse objektene implementerer et delt grensesnitt Notifiable. Dette tilveiebringer metodene som er nødvendige for å sende en underretning til det angjeldende objektet. Parcel objektet kan eventuelt utelates dersom for eksempel en underretning skal sendes uavhengig av en pakkeleveranse, for eksempel i tilfellet av en klientregistrering.

Parcel objektet vil i sin tur tilveiebringe en metode ved hjelp av hvilken den automatiske pakkeutleveringsmaskinen i hvilken pakken er beliggende kan bli tilgjengelig.

Read-out dataene til objektene innbefatter data som skal overføres (så som navn, adresse, lokalisering av den automatiske

pakkeutleveringsmaskinen) så vel som kontrolldata (så som e-post og/eller SMS adresse).

Innloggingskontroll

Kommunikasjonsforespørslene som blir avlest fra køen 40 blir kontrollert mot B2B DeliveryContract logikken 20 for å se hvorvidt de fremdeles er gyldige underretninger. Dersom det kun utføres en enkelt kontrollprosedyre, er det ikke noe behov for å kontrollere mot dataene fra pakkedatabasen 80 for å sikre at pakken ikke har blitt hentet enda. Dersom pakken ble hentet i mellomtiden, blir underretningen ansett å være fullstendiggjort. I dette øyemed, blir statusen til kommunikasjonsforespørselen fjernet fra den interne køen av ordrene som fremdeles skal behandles (statusen er satt til 2 = completely processed).

Dersom pakken i pakkedatabasen 80 ikke lenger eksisterer, blir det antatt at den ble hentet i mellomtiden, og kommunikasjonsforespørselen blir på samme måte fjernet fra den interne listen av ordre som fremdeles skal behandles.

Sentral sendingskomponent

Underretningene blir overført til den sentrale sendingskomponenten 30. Basert på typen av kommunikasjon som er indikert i kommunikasjonsforespørselen, blir det der fastslått hvilken type kommunikasjon som skal brukes for å levere meddelelsen. Her kan det skje en feil dersom en viss type kommunikasjon er spesifisert men brukeren ikke understøtter denne typen av kommunikasjon.

Dersom kun en type kommunikasjon er ønskelig, blir den ønskede SPI (Service Provider Interface) kalt opp direkte. Dersom brukeren ønsker en underretning via flere kommunikasjonstyper, må det tas foranstaltninger i tilfellet underretningen er vellykket via den første typen kommunikasjon men ikke ved den andre. Denne andre typen kommunikasjon vil da måtte forsøkes gjentatte ganger uten nok en gang å bruke den første kommunikasjonstypen. I dette øyemed er det best å utstede en duplikat av CommunicationRequest objektet for den ønskede typen kommunikasjon og deretter overføre den til den passende SPI.

Sending via individuelle typer av kommunikasjon

De individuelle typene av kommunikasjon blir kartlagt via såkalte SPI'er (Service Provider Interfaces). Det er en slik SPI for hver type av kommunikasjon. Hver SPI blir kalt opp med kommunikasjonsforespørselsobjektet. Som en funksjon av dataene i dette objektet, blir det generert en e-post og/eller SMS. I dette øyemed, blir den passende malen 110 lest inn, og plassholderne blir erstattet med informasjonen avlest fra den passende databasen.

Forsinkelse av sendingen

En mulig ønsket begrensning vedrørende sendingen av underretningene er at behandling om natten (for eksempel 10:00 p.m. til 6:00 a.m.) blir undertrykt enten helt eller kun for SMS underretninger. Dersom det er ønskelig med en fullstendig avbrudd av sendingen, kan dette erholdes for eksempel ved hjelp av timeren. Siden e-poster ikke medfører en forstyrrelse, er det foretrukket kun å undertrykke sending av SMS underretninger om natten. I dette øyemed blir sendingen avbrutt i SMS SPI'ene og sendingsdatoen blir innstilt til det neste passende tidspunktet innen det tillatte tidsvinduet. Ved det første tilfellet når timeren når dette tidsvinduet, blir

kommunikasjonsforespørselen avlest igjen og utført.

Plausibilitetskontrolller

Underretningskomponenten utfører en plausibilitetskontroll av dataene som skal overføres. Klienten må være tilstede i klientdatabasen 70 og pakken må være tilstede i pakkedatabasen 80. Dersom for eksempel en klient allerede har blitt fjernet, blir det ikke lenger sendt en underretning. Videre må det være tilstede informasjon om den automatiske pakkeutleveringsmaskinen (lokalisering). Det kontrolleres hvorvidt mottageradressen (e-post eller mobiltelefonnummer) er potensielt korrekt og hvorvidt alle plassholderne til malen 110 kan bli fylt med data. Videre må de eksisterende malene ha visse plausibiliteter: som en funksjon av maltypen (dette vil i sin tur variere med hensyn til sprog, typen av kommunikasjon og B2B logikken), og de følgende viktige datafeltene må være tilstede i malene:

Dersom en mal ikke er tilstede eller den ikke har noen passende innføringer, avbrytes sendingen og det dannes en passende feilmelding i en LOG fil. Malene bør kontrolleres. Dersom sendingen utføres med SMS, kan en intelligent mekanisme anpasse meldingene til en maksimal lengde på 160 karakterer.

Utførelse av sendingen

Mekanismen beskrevet i avsnittet TemplateMechanism genererer teksten som skal sendes. Teksten og mottagerinformasjonen blir overført til en e-post eller SMS systemport 120 som en funksjon av sendingstypen. Dersom overføringen til systemporten feiler, kan det forsøkes nok en sending med en gang for lettere å kunne overvinne kortvarige feil.

Lagring av resultatet

Dersom hele prosedyren var vellykket, vil i en spesielt foretrukket utførelsesform innføringen bli slettet fra køen av utestående ordre ved at feltet state settes til '2'. Samtidig blir feltet CompletionDate satt til nåværende dato + tiden på dagen. Slike innføringer i kommunikasjonskøen 40 blir ikke behandlet ytterligere. Det bær fortrinnsvis være tilgjengelige i kommunikasjonskøen for en viss tidsperiode for den eventualiteten at en underretning ikke kan leveres.

Det kan oppstå feil av en rekke årsaker:

■ Klienten er ikke i klientdatabasen 70 eller den automatiske pakkeutleveringsmaskinen er ikke i databasen 90 for den automatiske pakkeutleveringsmaskinen. ■ De innleste dataene er ikke plausible (for eksempel ikke fullstendig innført).

■ Malene er feil eller ikke tilstede.

■ Sending av underretningen er ikke mulig av tekniske årsaker (etter flere forsøk).

Dersom det oppstår en feil økes feltet 'RetryCount'. Dersom RetryCount overskrider en forutbestemt verdi (denne er også avhengig av frekvensen til timeren), blir det generert en feilmelding i en LOG fil og for eksempel en manuell gjenbehandling starter. Dette kan for eksempel være en kontroll av lagrede data eller manuell fjerning av innskrivninger for kommunikasjonskøen. For å forhindre at disse feilaktige underretningene blir forsøkt igjen og igjen, settes statusen til '9' så snart som en viss RetryCount har blitt nådd. Disse underretningene blir ikke behandlet. Videre blir nåværende dato lagret som avbruddsdato i feltet CompletionDate. Etter fjerning av feilen, blir statusen manuelt satt til T igjen. CompletionDate og RetryCount må tilsvarende tilbakestilles.

Jevnlig opprydding

Jevnlig 'opprydding' av kommunikasjonsforespørselskøen er nødvendig. Alle de ferdige sakene som har vært avsluttet lenger enn en viss tidsperiode (for eksempel en uke) bør fjernes fra databasen. Videre bør alle feiltilfellene som er eldre enn en måned bli fjernet fra

kommunikasjonsforespørselskøen. Datoen for avlutning eller avbrudd blir lagret i feltet CompletionDate. For eksempel utføres følgende:

Delete from communication queue

Loggemekanisme

Feil i sendingen av e-post eller SMS bør også bli logget I en feil LOG fil. Disse LOG filene må overvåkes jevnlig, for eksempel slik at man er i stand til å fastslå feil ved en systemport. Videre, i det minste i den første fasen, bør likeledes alle underretninger logges. I dette øyemed, brukes det en dedikert LOG fil for å forenkle feilovervåkningen.

Designforslag og begrensninger

Det er flere alternativer for implementering av timeren. Det kan oppnås

- Via den interne timeren til applikasjonsserveren

- Via en cron jobb

- Via en database timer eller

- Via en forskjellig utviklet løsning.

Den første varianten er foretrukket. Det er også flere mulige alternativer for å utføre sendingsprosedyrene for e-post og SMS:

- JMAPI (Java Message API)

- JMS

- Anvendelse av en passende e-post tjeneste til applikasjonsserveren.

Her er de to første variantene foretrukket.

Planløsning

Underretningskomponenten trenger ikke innbefatte noen overflate eller Internet-sider. Det er imidlertid nødvendig med forskjellige maler for individuelle underretninger. Det er her hensiktsmessig at malene er lett utbyttbare. Malene antydet i de følgende avsnittene er kun utførelseseksempler. Selvfølgelig kan enhver ønsket underretningstekst integreres med de passende plassholderne.

BNK1 = bekreftelse av registreringen

Underretning med e-post

Underretning med SMS

BNK2 = bekreftelse av endring av klientdataene

Underretning med e-post

Underretning med SMS

BNK3 = underretning 'ny pakke'

Underretning med e-post Underretning med SMS

BNK3N = underretning 'ny pakke med COD'

Underretning med e-post

Underretning med SMS

BNK4 = underretning 'pakke har ventet i 48 timer'

Underretning med e-post

Underretning med SMS

BNK4N = underretning 'pakke med COD har ventet i 48 timer'

Underretning med e-post

Underretning med SMS

BNK5 = underretning 'pakke vil bli fjernet om 48 timer'

Underretning med e-post

Underretning med SMS

BNK5 = underretning 'COD pakke vil bli fjernet om 48 timer'

Underretning med e-post

Underretning med SMS

Krav til andre komponenter

Objekt Parcel

Det må være tilveiebragt et objekt parcel som tilfører informasjon om en pakke som er identifisert med et entydig pakkenummer: - Parcel må tilveiebringe en fremgangsmåte som gir tilbakemelding om utløpsdato på hvilken pakken vil bli fjernet fra den automatiske pakkeutleveringsmaskinen. Dette er nødvendig for å overføre underretninger X dager før utløpet. Dersom ingen utløpsdato har blitt angitt, kan det som en standardprose3dyre antas et visst antall kalenderdager (for eksempel 9 dager).

- DeliveryContract objektet må tilveiebringes via en metode.

- Parcel objektet tilveiebringer en metode med hvilken det oppnås tilgang til den automatiske

pakkeutleveringsmaskinen hvor pakken er lokalisert.

Objekt Machine

Objektet Machine gir tilgang til den automatiske pakkeutleveringsmaskindatabasen 90, som er identifisert av automatisk pakkeutleveringsmaskin ID. - Metodene i dette objektet må tilføre informasjon om lokaliseringen til en automatisk pakkeutleveringsmaskin.

Objekter som skal underrettes (underrettbare objekter): User, LogisticProvider og LogisticContractor

Objektet User tilfører informasjon om en klient som er definert av klinetnummeret. Objektet LogisticProvider gir tilgang til den logistikkforsørgerdatabasen. Objektet LogisticContractor gir informasjon om en logistikk kontraktør. ■ Alle objektene implementerer et delt grensesnitt Notifiable. Den tilveiebringer de nødvendige metoder for sending av en underretning til det angjeldende objektet, for eksempel for avlesing av e-post adressen eller adresseformen. ■ Det har vært mulig å identifisere et Notifiable objekt ved hjelp av en entydig ID. I denne hensikt kan ID'en til User, LogisticProvider objektet og LogisticContractor objektet, sammenkjedet med en identifikasjon av objekttypen (US_, LP_, LC_), bli gitt tilbake via en metode getUniquelD. Denne metoden bør fortrinnsvis være definert i grensesnittet Notifiable. ■ For å rekonstruere et Notifiable objekt igjen via denne ID'en, blir det implementert en objektfabrikk som danner det passende objektet på basis av en slik ID.

Logikkobjektene DeliveryContract, LogisticProvider og LogisticContractor ■ B2B logikken må forespørres for alle objekter, for eksempel via et delt grensesnitt. ■ Et slikt objekt må identifiseres via en entydig ID. I denne hensikt kan det brukes den ID'en til Notifiable objektet ( getUniquelD) som allerede eksisterer for LogisticProvider og LogisticContractor. En korresponderende metode kan også være tilstede i DeliveryContract som da tilveiebringer tilbakemelding om ID'en til objektet, sammenkoblet med en identifikasjon av objekttypen (DC_).

For ytterligere å forbedre prosedyren, kan det være fordelaktig å utføre følgende foranstaltninger individuelt eller sammen: ■ Alle e-postene blir sendt offline ved at de er skrevet inn i en kommunikasjonskø hvorfra de utlese ved jevne intervaller og behandles. ■ Implementeringen kan understøtte ethvert (men fortrinnsvis fast) sprog.

■ E-postene blir fortrinnsvis sendt som ren tekst.

Spesielt foretrukne utførelsesformer av oppfinnelsen er imidlertid:

■ Støtte av HTML formatert e-post.

■ Her, ved registreringstidspunktet, kan klienten velge i hvilket format han ønsker å motta e-post i (ren tekst eller HTML). Det brukes derved forskjellige maler under sendingsprosedyren.

■ Mulighet for flere sprog.

Klienten kan velge sitt foretrukne sprog ved registreringstidspunktet. Det brukes derved forskjellige maler under sendingsprosedyren.

■ Støtte for underretninger via RFC1149 standarden

■ Videre kan det brukes et ContentManagementSystem for å gjøre det enklere å håndtere malene for e-post og SMS.

Claims (5)

1. Fremgangsmåte for overføring av underretninger til brukere av et logistisk system, hvor det logistiske systemet innbefatter et eller flere pakkeromssystemer med en eller flere registrerte brukere og hvor underretningsordrene blir overført til en sentral sendingskomponent (30) som , på basis av ordrene, genererer passende underretninger og sender dem til brukere hvorved sendingskomponenten (30), for å generere underretningene, aksesserer en eller flere databaser, karakterisert vedtrinnene: - forskjellige moduler med tilhørende funksjoner blir kalt opp i respons i hvert tilfelle til forskjellige hendelser i det logistiske systemet, hvorved modulene er en klientdatabase, en registreringsenhet og/eller en systemadministrasjonsenhet for det logistiske systemet, - modulene genererer underretningsordre, - underretningsordrene generert av modulene blir enten overført til en sentral sendingsenhet (30) slik at de kan sendes umiddelbart eller de blir skrevet inn i en kommunikasjonsforespørselskø (40) slik at de kan sendes på en forsinket måte, hvorved underretningsordrene blir avlest fra kommunikasjonsforespørselskøen (40) ved hjelp av en køleser (50) på en tidskontrollert måte og overført til den sentrale sendingskomponenten (30), - den sentrale sendingskomponenten (30) genererer de passende brukerspesifikke underretningene, hvorved, for å generere underretningene, aksesserer sendingskomponenten (30) minst en klientdatabase (70), en pakkedatabase (80), en automatisk pakkeutleveringsmaskin database (90) og en dokumentdatabase (100), - den sentrale sendingskomponenten sender de passende brukerspesifikke underretningene til brukerne via en systemport (120, - statusen til underretningsordrene blir validert i en DeliveryContractLogic (60) før overføring til den sentrale sendingskomponenten (30).

2. Fremgangsmåte i henhold til krav 1, karakterisert vedat klientdataene, pakkedataene og pakkeromssystemdataene alle er allokert i databasene ved hjelp av ID'er.

3. Fremgangsmåte i henhold til et eller begge av kravene 1 og 2,karakterisert vedat hendelsene i det logistiske systemet innbefatter i det minste følgende: - registrering av den nye brukeren - endring av brukerdataene - plassering av en ny pakke i et pakkeromssystem - avhenting av en pakke fra en pakkeromssystem - tillegging av et substitutt for avhenting av en pakke - fjerning av et substitutt.

4. Fremgangsmåte i henhold til et eller flere av de foregående kravene 1 til 3,karakterisert vedat underretningene blir sendt til brukerne i form av e-post og/eller SMS.

5. Anordning for overføring av underretninger til brukere av et logistisk system som opererer et eller flere pakkeromssystemer, karakterisert vedat det logistiske systemet består av i det minste moduler som hver har funksjoner for generering av underretningsordre, av en sentral sendingskomponent (30), av en kommunikasjonsforespørselskø (40), av en dokumentdatabase (100) med maler (110) for generering av individuelle underretninger for de spesifikke brukerne, av en klientdatabase (70) med informasjon om klienter, av en pakkedatabase (80) med informasjon om pakker, av en automatisk pakkeutleveringsmaskindatabase (90) med informasjon om pakkeromssystemene og av en systemport (120) for sending av underretningene, hvorved modulene er en klientdatabase, en registreringsenhet og/eller en systemadministrasjonsenhet for det logistiske systemet.