NO332028B1 - Procedure and system for transmitting notifications to users of a logistical system - Google Patents

Abstract

A method and system for transmitting notifications to users of a logistic system. Different events within the logistic system are used to call up different modules having respectively associated functions. The modules produce notification orders which are transmitted to a central sending component, which produces notifications which correspond to orders and sends said notifications to the users.

Description

Procedure and system for the transmission of notifications to users of a logistic system

The present invention relates to a method for transmitting notifications to users of a logistic system, where the logistic system includes one or more parcel room systems with one or more registered users, and by which method the notification orders are transferred to a central dispatch component which, on the basis of the orders, generate appropriate notifications and send them to the users, whereby the sending component, in order to generate the notifications, accesses one or more databases.

The invention also relates to a system for transmitting notifications to users of a logistic system that operates one or more parcel room systems.

In order to be able to operate logistics systems with a variety of users and one or more logistics suppliers, certain information must be transferred to the subscribers in the system. The transmission of information is hereinafter referred to as notification. Such notifications can take place via one or more different types of communication.

Notifications are sent on the basis of events that have occurred in the logistics system. In this context, an event in the logistics system can trigger no notification or one or more notifications. The allocation of events in the logistic system to notifications can be performed within a notification component as a function of a business logic.

Notifications can be transmitted via different types of communication. Here, the type of communication is the way in which a notification is delivered. As a principle, a notification with the same information content can be delivered via several different types of communication.

A logistic system with different notifications and communication types is necessary, especially when a parcel room system for registered users is operated by a transport and delivery company. Such parcel room systems or automatic parcel delivery machines are operated, for example, by a postal service provider for registered users to whom a supplier delivers parcels or other consignments in a room in the system. The user must then be notified that a package has been delivered to him. Furthermore, the logistic system must be informed about whether, for example, a user has collected his package. Furthermore, information on registration of new clients, client data, collection deadlines and COD fees must be exchanged in the logistic system.

In a logistics system for parcel room systems, notifications are typically sent by e-mail or SMS. Formation, administration and sending of the notifications preferably include different databases and process sequences.

Logistical systems for the distribution of goods are known. The goods to be distributed can be all types of products, materials and objects. Logistics systems work to organize and monitor the distribution of the goods in question, for example between warehouses, intermediate storage facilities, containers, vehicles, senders and receivers via different transport routes. The functions of the logistic systems are advantageously adapted to the requirements in such a way that the distribution of the goods can be optimised, for example with regard to transport routes, capacity utilization, storage times and data transmission.

The applicant makes special use of logistic systems for the distribution of letters and goods (parcels, packaging), transport boxes, pallets and containers. The associated logistic systems work preferably to distribute consignments between a sender and a recipient, whereby criteria such as transport speed, utilization of warehouses and vehicles and transfer of consignment data are important.

German utility model 201 03 564 U1 describes, for example, a system for the delivery and reception of shipments which seems to be particularly suitable for e-commerce. The system includes several automatic dispensing machines (ADM) in which the consignments are placed and retrieved. The system also includes a LAM IS server computer program for handling the operations in the system. The client is informed, for example via communication types such as e-mail, about the shipments that have been delivered to him via

ADM.

International patent application WO 02/50705 A describes an electronic document distribution system including a building module that integrates creative content with a document template to form an electronic master document that is transferred to a recipient list by a sending module in accordance with delivery and scheduling details. A capture module automatically receives and processes receipts from recipients of the electronic document. The system is used in campaigns with e-mails sent out in large volumes for the marketing of goods and services. It may also include a fulfillment interface that tracks fulfillment of orders received from recipients and an electronic commerce interface that assists with financial transactions for payment of ordered goods or services.

Furthermore, the U.S. describes patent no. 6,047,264 a method for transferring the status of a shipment to a user, where an entry is generated in a central database when a user orders a shipment. If the status of the shipment changes, for example when it is transferred to a distribution company, when it is transported to different stations or when it arrives at its destination, the status change will be collected in the database. This collection can be done manually or electronically. Via a query module, a notification component will continuously request status changes from the database and generate messages to the user of a shipment for which the status has changed. Notification is preferably via e-mail.

U.S. patent no. 6,220,509 B1 describes a package tracking system where status information about a shipment is registered directly into the client database. In this case, the client database is preferably accessed via an internet web page.

European Patent No. EP 0 491 367 A2 describes a method for processing messages where orders are stored in a queue to be executed in a controlled manner. Here, the orders can be adapted to different conditions and features of the destinations and communicate links. The procedure is particularly well adapted for use in e-mail systems.

The purpose of the invention is to provide a method and a device for the transmission of notifications to users of a logistic system which allows the most flexible response to various events in the system and the formation of user-specific notifications.

According to the invention, this purpose is achieved with the features of the independent claims 1 and 5. Advantageous embodiments of the invention appear from the non-independent claims 2 to 4.

According to the invention, this purpose is achieved in that, in response to different events in the logistic system, different modules with associated functions are called up in each case, whereby the modules generate different notification orders which are transmitted to a central dispatch component which, on the basis of the orders, generates appropriate notifications and sends them to the users.

The purpose is also achieved by a system for practicing the method.

The modules with the associated functions for reaction to events in the logistic system form an external interface via different Use Cases are registered. In a particularly advantageous embodiment of the invention, notification orders generated by the modules are only transmitted directly to the sending component in special cases, while they are usually written into a communication request queue. A queue reader reads the orders from the communication request queue in a time-controlled manner and transfers them to a central dispatch component. Before this, the status of the notification is checked. A status change can be made, for example by the fact that a package has been picked up in the meantime or the person picking up the package has been changed.

According to a feature of the invention, the sending component generates the notifications on the basis of data from one or more databases. These databases are advantageously at least a client database, an automatic package delivery machine database and a document database. The client database contains, for example, data relating to registered clients in the logistic system, whereby each client receives an ID for identification purposes. This data may contain addresses, telephone numbers or other information. The parcel database contains information about the parcels that are transported within the system, whereby the parcels are correspondingly identified by means of an ID. The automatic package delivery machine database contains information regarding the package room systems used within the system. This also includes IDs.

The document database contains templates to generate user-specific notifications. To this end, it preferably includes templates for e-mail and SMS notifications. The templates have placeholders into which the user-specific data from the databases is entered.

The sending component transfers the generated notifications to a system port so that they can be sent to the users.

Further advantages, special features and practical embodiments of the invention will be apparent from the subordinate claims and from the subsequent presentation of preferred embodiments, with reference to the figures.

The figures show the following:

Figure 1 shows the process sequence between an external interface, a central sending component and a communication request queue of a particularly preferred embodiment; Figure 2 shows the process sequence between a communication request queue, a central dispatch component and a delivery contract logic of a particularly preferred embodiment; Figure 3 shows the process sequence between a central sending component, various databases and a system port; and Figure 4 shows a general overview of the sequences in the system for transmitting notifications.

Below is described a logistical system for operating a system including one or more parcel room systems with a variable number of registered users. This is a particularly preferred embodiment of the invention, but the method according to the invention is also suitable for other logistic systems where notifications are sent.

The logistic system for the operation of one or more parcel room systems is divided, for example, into at least the following process steps on the basis of the functions:

UC NBK1 confirmation of the registration of a client

UC NBK2 change of client data

UC BNK3 notification 'new package'

UC BNK5 notification 'package was collected'

UC BNK6 notification 'package was sent back'

UC BNK7 notification 'substitute added'

UC BNK8 notification 'substitute removed'

Notifications are sent to the user for the above events in the system and these notifications inform the user of the event and/or confirm it. In a particularly preferred embodiment of the invention, the execution of the individual processing steps is carried out with different modules and/or units of the logistic system. These modules can be, for example, a client database, a registration unit or a system management unit for the logistic system. The modules, possibly together with other components, form an external interface 10.

The sequence and function procedure call within the module is explained below. The notification orders generated by the modules are either transferred to a central sending component 30 so that they can be sent immediately or they can be read into a communication request queue 40 so that they can be sent in a delayed manner. All pending notification orders are periodically read from this queue and appropriate notifications are sent. Formed notifications are preferably sent by e-mail or SMS.

UC BNK1 confirmation of registration

After the registration of a new client in the logistics system of the parcel room systems, a registration module calls a function.

newRecipient (User)

to send a confirmation notification. The function determines the necessary notifications on the basis of the client logic of the client associated with the client and said function puts this into a communication request queue so that they can be sent in a delayed manner.

UC BNK2 Changing the client data

After a client is changed, its client data is stored in a client database, which client database calls a function

updateRecipient (User)

to send a confirmation notification. This function similarly determines the necessary notifications based on client logic to the client associated with the client and said function enters than

the communication request queue so that they can be sent in a delayed manner.

UC BNK3 Notification 'new package'

When a package is delivered to an automatic package dispensing machine in a logistic system, information about this is sent to a system management unit of the logistic system. The system management unit of the logistic system calls a function

notifyDelivery (Parcel)

to send a confirmation notification. This function determines the necessary notifications based on the client logic of the client associated with the package and this function puts them into the communication request queue so that they can be sent in a delayed manner.

UC BNK5 Notification 'package was collected'

When a parcel has been taken from an automatic parcel delivery machine to a logistic system, information about this is sent to

the system management unit of the logistic system.

The system administration unit of the logistic system will then call a function

notifyPickup (Parcel)

to send a confirmation notification. The function determines the necessary notifications based on the client logic of the client associated with the package and said function puts this into the communication request queue.

UC BNK6 Notification 'package was sent back'

When a parcel has been sent back from an automatic parcel dispensing machine to a logistic system because it was not collected before a certain collection deadline, information about this is sent to the system management unit of the logistic system. The system administration unit of the logistic system calls a function

ParcelFailed (Parcel)

to send a confirmation notification. The function determines the necessary notifications based on the client logic of the client associated with the package and said function enters

the communication request queue.

UC BNK7 Notification 'substitute added'

When a substitute has been added for a pending package in an automatic package delivery machine of a logistic system, information about this is sent to the system management unit of the logistic system. The system management unit of the logistic system then calls a function

addSubstitute (Parcel, User)

to send a confirmation notification. The function determines the necessary notifications based on the client logic of the client associated with the package and said function enters

the communication request queue.

UC BNK8 Notification 'substitute removed'

When an added substitute has been removed for a waiting package in an automatic package dispensing machine of a logistic system, information about this is sent to the system management unit of the logistic system. The system management unit of the logistic system calls a function

removeSubstitute (Parcel, User)

to send a confirmation notification. The function determines the necessary notifications based on the client logic of the client associated with the package and said function enters

the communication request queue.

In addition, the following events can be mapped with functions in the modules: Automatic package delivery machine not functional NotifyADMfailed

(parcel parcel, Boolean failure)

Generic Notification genericNotification

(Parcel parcel, Addressable add, int type)

Notification to delivery provider: package delivered

notifyDeliveryProvider (Parcel parcel)

Notification to delivery provider: package removed

notifyPickupProvider (Parcel parcel)

Department (branch)

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

Product lock

notifyWarehouseDeliver (String description, DeliveryMachine adm, Addressable recipient)

Address check failed

notifyAdressCheckFailed (String description, Addressable recipient)

Internet password

notifylnternetPassword (String description, Addressable recipient)

Generic message text

notifyGenericMessageText (String description, Addressable recipient)

Issuer returns offeror

notifyDeliveryReturnsProvider (Parcel parcel)

Pick up returns provider

notifyPickupReturnsProvider (Parcel parcel)

Collection by delivery agent provider

notifyPickupByDeliveryAgentProvider (Parcel parcel)

Email changed

notifyEmailChanged (Addressable recipient)

Mobile phone number changed

notifyMobileNumberChanged (Addressable recipient)

Post PIN changed

notifyPostPinChanged (Addressable recipient)

Password changed

notifylnternetPasswordChanged (Addressable recipient)

The notifications are preferably sent in the form of an e-mail or SMS. An e-mail or SMS portal can, for example, be used for this purpose.

In order to use the method according to the invention in practice, it has proven advantageous that the list of undeliverable notifications is revised manually at regular intervals (for example every 24 hours).

The drawings in Figures 1 to 4 show an overview of the most important sub-components of a particularly preferred embodiment of the system according to the invention. The external systems are marked with cross-hatching, while the parts belonging to the notification system are shown in white.

The drawing in Figure 1 shows the structure of a particularly preferred embodiment of a notification component. The notification component is connected to an external interface 10 which is called up externally when certain events in the logistic system have occurred. The interface is formed by several modules, each with associated functions. The events in the logistic system are converted into notification orders by a B2B account logic component (not shown here. For certain special cases, these orders may be sent directly via a central dispatch component 30. As a standard procedure, however, the orders are entered into a communication request queue 40 and then transferred to the central transmission component 30 in a time-controlled manner. This allows, for example, that reminder notifications can be defined at a later time (for example after 2 days or 7 days). The entry into the queue also has the advantage that failed transmission attempts are automatically repeated here.

The drawing in Figure 2 shows the process sequence after the notification orders have been written into the communication request queue 40. The orders present in the communication request queue 40 are read out by a key reader 50 in a time-controlled manner. A control procedure again checks against a B2B delivery contract logic 20 whether the status has changed in the meantime. A status change has occurred, for example, when a placed package has been picked up or the person picking it up has been changed. If the validation was successful, a communication request is transferred to the sending component 30.

The drawing in Figure 3 shows the process sequence in connection with the central transmission component 30. The process flow inside the transmission component is indicated by arrows. The sending component receives orders externally and then reads the necessary data from the associated databases in order to transmit the notification. These databases include at least a client database 70, a package database 80 and an automatic package delivery machine database 90. The automatic package delivery machine database contains data regarding the package room units of the system. Then a template 110 specified by the B2B component 20 is read from the document database 100 and placeholders inside the template are replaced with current data. The e-mail or SMS generated in this way can be sent, for example, via an e-mail or SMS portal 120.

The drawing in Figure 4 combines the three parts of the notification component in a general overview. Here you can clearly see the separation between the central sending component 30 on the right side and the parts of the business logic component on the left side.

Below, the individual components of the system and their functions in a particularly preferred embodiment of the method according to the invention will be explained in more detail.

External interface

The external interface 10 is connected to the notification component and results in a direct way from different UseCases; for each UseCase, a separate function is preferably defined which achieves the required functionality in the notification component. These functions correspond to the events in the logistic system and concern, for example, package objects and/or user objects. The functions can of course also be extended and can also relate to other objects.

newRecipient (User)

is called after registering a new client.

updateRecipient (User)

is called after a client has changed their client data stored in the client database.

notifyDelivery (Parcel)

is called when a parcel has been delivered to an automatic parcel delivery machine in a logistic system.

notifyPickup (Parcel)

is called when a parcel has been retrieved from an automatic parcel dispensing machine in a logistic system.

parcelFailed (Parcel)

is called when a parcel has been sent back from an automatic parcel delivery machine in a logistic system because it was not collected before a certain collection deadline.

addSubstitute (Parcel, User)

is called when an added substitute has been added for a pending package in an automatic package delivery machine in a logistics system.

removeSubstitute (Parcel, User)

is called when a substitute has been removed for a pending package in an automatic package dispensing machine in a logistic system.

The respective Package or User objects each receive methods. Internally, the event of the logistic system is transformed into notifications which are temporarily stored in the internal queue 40. The result provided by the methods provides feedback on whether this transformation and temporary storage worked or not.

Different types of notifications can be sent, for which it has proven advantageous to create templates 110 and store these in a document database. The types of notifications are mapped using a template name that classifies the templates at the level of the information content of the notification. In, for example, the B2B case, the following templates are required:

New client registration BNK1

Change of client data BNK2

Parcel delivery BNK3, BNK3N

Package has been waiting for 48 hours BNK4, BNK4N

Package will be sent back

in 48 hours BNK5, BNK5N

Template variants for packages with COD and packages without COD can be used for the last three types of package notifications. In addition to the name, the templates are also identified via the DeliveryContract, the communication type and the language. In addition to the templates described, any number of other templates can of course be used.

The templates should be available for all notifications to be sent in the form of SMS as well as e-mail. For sending or e-mail, the templates should preferably be available for the message text as well as for the reference line.

Database storage

In order to simplify the management of the templates 110, they are stored in a database 100.1 a particularly preferred embodiment of the invention, this database includes several fields which are indicated in tabular form below:

It should be noted that, as a function of the event in the logistic notification system, the database key 'Contract' can be a LogisticProvider or a LogisticContractor (in the case of BNK1 and BNK2) or a DeliveryContract (in cases BNK3 to BNK5).

Place holder mechanism

It has proven advantageous to use different place holders inside the templates 110 which can be replaced with specific information. With an eye towards the use of HTML-formatted e-mail, these placeholders should preferably not be defined as HTML tags.

At a minimum, the following placeholders may be provided:

In addition to the described placeholders, other placeholders can of course also be used.

Message length

The maximum length for SMS messages is typically 160 characters. Since certain information - such as the location of the event in the automatic parcel delivery machine of a logistic system - can have variable lengths, very long fields (for example, streets or cities with urban district information) can cause an 'overflow' of 160 characters. In order to avoid such an 'overcurrent', in a particularly preferred embodiment of the invention, an intelligent mechanism is used which, depending on the individual field lengths, the importance of each field and on the available remaining length, contains all essential information to the greatest extent possible.

An alternative to an intelligent mechanism is the storage of short versions of all fields in appropriate databases so that the maximum length of 160 characters is never exceeded. However, this has the disadvantage that changing the SMS templates will entail new length restrictions. Certain information such as the address entered by the client can therefore be difficult to adapt.

B2B DeliveryContract logic

The B2B deliveryContract logic 20 determines what the individual business logic should look like for a certain LogisticProvider, a certain LogisticContractor, and a certain DeliveryContract (between a certain logistics provider and a certain logistics contractor). For this purpose, the individual events are converted into notification orders. The events in the logistic system newRecipient and updateRecipient depend only on the LogisticProvider or LogisticContractor with which the corresponding user is connected. The other events in the logistic system concern the delivery of packages, that is, they depend on the LogisticProvider (which transports the package) as well as the LogisticContractor (which defines the recipient or supplier of the package). To implement the logic, a list of notifications to be sent (communication requests) is defined in each case for the logistic system. These communication requests include several parameters that can be set.

Events in the logistic system

Several notifications can be saved for each event, for example if there are repeated notifications, or if several people with different roles are to be informed.

Persons to be notified are the persons to be notified. Possible values are: Recipient, Substitute, LogisticProvider or LogisticContractor.

A date is specified on which the notification is to be sent. In the logic, only a relative date is stored and this is then calculated with the date of the event in the logistic system to generate an absolute date. Possible values are here, for example:

A certain type of communication may be specified. This is necessary, for example, if a certain logic only allows notification by SMS. Possible values are e-ma/V, SMS and user (the communication type specified for the user). In this way, for example, a delivery contract logic can be mapped that exclusively allows notifications via a specific type of communication.

Preferably, the option exists to select a template 110 to be used for the transfer. This has the advantage that different texts can be made applicable within the same delivery contract, for example for different events in the logistic system. In addition, the template can always be further restricted by the current DeliveryContract. A certain template (for example BNK1) can also have different content for two different DeliveryContracts. Furthermore, different versions of the same templates can be kept available for different types of communication.

Furthermore, additional information may be stored that is used for differentiation within the same business logic or that is used to control the logic later, such as the two possible pieces of information described below:

Differentiation in the case of COD packages

Here, a different template is used for packages with a set COD amount. This template contains, for example, the COD amount as information for the person collecting the package.

There are B2B processes in which a COD amount is present for the package, but this amount is not transferred to the person who collects the package since the COD is invoiced, for example via collective invoicing.

Checking whether a package was collected

This is a check operation that is performed to see whether a parcel is still in the automatic parcel delivery machine of the logistic system or whether it has been picked up in the meantime. This is especially useful if reminder notifications are sent, for example after a few days.

The parcel/object must provide a method that provides feedback about the expiration date on which the package will be removed from the automatic package delivery machine. This is necessary to be able to transmit notifications X days before the expiry. If no expiry date has been specified, a certain number of calendar days can be assumed as a standard procedure.

LogisticProvider DPAG (B2C case)

The following table is an example that defines the notifications to be sent (communication request) at the time of registration of users for a LogisticProvider. These are suppliers, no notifications are sent.

LogisticContractor —► final client (B2C case)

The following table is an example that defines the notifications to be sent (communication requests) at the time of registration of users for a virtual LogisticContractor 'final client'. This is where all the users registered for B2C are gathered.

Supply contract logic - final client (B2C case)

The following table is an example that defines the notifications to be sent (communication requests) for B2C logic between a logistics provider and the final client: LogisticProvider LP (B2B case)

LogisticContractor LC (B2B case) DeliveryContract logic LP -> LC (B2B case)

CommunicationRequest queue.

There is a need for a dedicated database table in which orders for notifications (communication requests) to be sent are stored temporarily. The table should preferably only serve the purpose of handling the load; specific information about e.g. packages and recipients are always read from the client database 70 or from the package database 80.

However, it may be appropriate to extend the fields of the communication request queue. For example, automatic package delivery machine numbers and free text descriptions can be added. In this way, notifications are not only linked to packages but possibly also to a combination of postcodes, events and automatic package delivery machine numbers. Furthermore, there is an option to generate notifications dynamically.

With the Comm_ Type entry, we have a value User, it can be specified that the notification should be made via the type of communication specified by the user. In a similar way, the value User can be entered for the Lang language setting if the user's settings are to be used. Whether and to what extent it is necessary to log an entry (status = 3) depends on the specific implementation.

Access to databases

Access must be provided to the following databases in the logistic system: ■ Client database provides information about a client defined by the client number ■ LogisticProvider database provides information about a logistics provider ■ LogisticContractor database provides information about a logistics contractor ■ DeliveryContract database provides information about a logistics contractor ■ Parcel database provides information about a package that has been identified by a unique package number ■ Automated Parcel Delivery Machine database provides information about the location of an automated parcel delivery machine identified by the automated parcel delivery machine ID.

Sequence when sending a notification

Hours

The notification component regularly checks all the orders in the communication queue 40. This is triggered by a timer 41 in the notification component. The time interval can preferably be designed freely.

Communication key reader

When the timer function is called, all the entries whose transmission date is after the current date are read from

the communication request queue 40.

Reconstruction of the objects

Each entry read from the queue is converted into a CommunicationReqvest object. On the basis of the unique ID for the user to be informed (Recipient-ID) and the ID for the parcel (ParcellD), the relevant partial objects are reconstructed. This is necessary to be able to request the current data of the objects, such as the e-mail address for example.

The term User in this case refers either to a User, a LogisticProvider object or a LogisticContractor object. All these objects implement a shared interface Notifiable. This provides the methods necessary to send a notification to the object in question. The Parcel object can optionally be omitted if, for example, a notification is to be sent independently of a parcel delivery, for example in the case of a client registration.

The Parcel object will in turn provide a method by means of which the automatic parcel delivery machine in which the parcel is located can be accessed.

The read-out data of the objects includes data to be transferred (such as name, address, location of the automatic

the parcel delivery machine) as well as control data (such as e-mail and/or SMS address).

Login control

The communication requests read from the queue 40 are checked against the B2B DeliveryContract logic 20 to see if they are still valid notifications. If only a single check procedure is performed, there is no need to check against the data from the package database 80 to ensure that the package has not yet been retrieved. If the package was picked up in the meantime, the notification is considered to have been completed. To this end, the status of the communication request is removed from the internal queue of the orders still to be processed (the status is set to 2 = completely processed).

If the package in the package database 80 no longer exists, it is assumed that it was retrieved in the meantime, and the communication request is similarly removed from the internal list of orders still to be processed.

Central broadcast component

The notifications are transmitted to the central sending component 30. Based on the type of communication indicated in the communication request, it is determined which type of communication will be used to deliver the message. An error can occur here if a certain type of communication is specified but the user does not support this type of communication.

If only one type of communication is desired, the desired SPI (Service Provider Interface) is called up directly. If the user wants a notification via several types of communication, measures must be taken in the event that the notification is successful via the first type of communication but not via the second. This second type of communication will then have to be attempted repeatedly without once again using the first type of communication. To this end, it is best to issue a duplicate of the CommunicationRequest object for the desired type of communication and then transfer it to the appropriate SPI.

Sending via individual types of communication

The individual types of communication are mapped via so-called SPIs (Service Provider Interfaces). There is one such SPI for each type of communication. Each SPI is called with the communication request object. As a function of the data in this object, an email and/or SMS is generated. To this end, the appropriate template 110 is read in and the placeholders are replaced with the information read from the appropriate database.

Delay in shipment

A possible desired limitation regarding the sending of the notifications is that processing at night (eg 10:00 p.m. to 6:00 a.m.) is suppressed either completely or only for SMS notifications. If a complete interruption of the transmission is desired, this can be obtained, for example, with the help of the timer. Since e-mails do not cause a disturbance, it is preferred to only suppress the sending of SMS notifications at night. To this end, the transmission is interrupted in the SMS SPIs and the transmission date is set to the next suitable time within the allowed time window. In the first case, when the timer reaches this time window, becomes

the communication request read again and executed.

Plausibility checks

The notification component performs a plausibility check of the data to be transmitted. The client must be present in the client database 70 and the package must be present in the package database 80. If, for example, a client has already been removed, a notification is no longer sent. Furthermore, there must be information about the automatic parcel delivery machine (location). It is checked whether the recipient address (e-mail or mobile phone number) is potentially correct and whether all the placeholders of the template 110 can be filled with data. Furthermore, the existing templates must have certain plausibility: as a function of the template type (this in turn will vary with regard to language, the type of communication and the B2B logic), and the following important data fields must be present in the templates:

If a template is not present or it has no suitable entries, the transmission is interrupted and a suitable error message is generated in a LOG file. The templates should be checked. If the transmission is carried out by SMS, an intelligent mechanism can adapt the messages to a maximum length of 160 characters.

Execution of the shipment

The mechanism described in the section TemplateMechanism generates the text to be sent. The text and recipient information is transferred to an e-mail or SMS system port 120 as a function of the transmission type. If the transmission to the system port fails, another transmission can be attempted at once to more easily overcome short-term errors.

Saving the result

If the entire procedure was successful, in a particularly preferred embodiment the entry will be deleted from the queue of outstanding orders by setting the field state to '2'. At the same time, the field CompletionDate is set to the current date + the time of day. Such entries in the communication queue 40 are not processed further. They should preferably be available in the communication queue for a certain period of time in the event that a notification cannot be delivered.

Errors can occur for a number of reasons:

■ The client is not in the client database 70 or the automatic package delivery engine is not in the automatic package delivery engine database 90. ■ The data entered is not plausible (eg not fully entered).

■ The templates are incorrect or not present.

■ Sending the notification is not possible for technical reasons (after several attempts).

If an error occurs, the 'RetryCount' field is increased. If the RetryCount exceeds a predetermined value (this also depends on the frequency of the timer), an error message is generated in a LOG file and, for example, a manual reprocessing starts. This could, for example, be a check of stored data or manual removal of entries for the communication queue. To prevent these erroneous notifications from being retried again and again, the status is set to '9' as soon as a certain RetryCount has been reached. These notifications are not processed. Furthermore, the current date is stored as the interruption date in the CompletionDate field. After removing the error, the status is manually set to T again. CompletionDate and RetryCount must accordingly be reset.

Regular cleaning

Regular 'cleaning' of the communication request queue is required. All the completed cases that have been closed for longer than a certain period of time (for example, a week) should be removed from the database. Furthermore, all error cases older than one month should be removed

the communication request queue. The date of completion or interruption is stored in the field CompletionDate. For example, the following is performed:

Delete from communication queue

Logging mechanism

Errors in the sending of e-mail or SMS should also be logged in a wrong LOG file. These LOG files must be monitored regularly, for example so that one is able to determine errors at a system port. Furthermore, at least in the first phase, all notifications should also be logged. In this regard, a dedicated LOG file is used to simplify error monitoring.

Design suggestions and limitations

There are several options for implementing the timer. It can be achieved

- Via the internal timer of the application server

- Via a cron job

- Via a database timer or

- Via a differently developed solution.

The first variant is preferred. There are also several possible options for performing the sending procedures for e-mail and SMS:

- JMAPI (Java Message API)

- JMS

- Application of a suitable e-mail service to the application server.

Here, the first two variants are preferred.

Floor plan

The notification component need not include any surface or Internet pages. However, different templates are needed for individual notifications. It is appropriate here that the templates are easily replaceable. The templates indicated in the following paragraphs are only examples of implementation. Of course, any desired notification text can be integrated with the appropriate placeholders.

BNK1 = confirmation of registration

Notification by e-mail

Notification by SMS

BNK2 = confirmation of change of the client data

Notification by e-mail

Notification by SMS

BNK3 = notification 'new package'

Notification by e-mail Notification by SMS

BNK3N = notification 'new package with COD'

Notification by e-mail

Notification by SMS

BNK4 = notification 'package has been waiting for 48 hours'

Notification by e-mail

Notification by SMS

BNK4N = notification 'package with COD has been waiting for 48 hours'

Notification by e-mail

Notification by SMS

BNK5 = notification 'package will be removed in 48 hours'

Notification by e-mail

Notification by SMS

BNK5 = notification 'COD package will be removed in 48 hours'

Notification by e-mail

Notification by SMS

Requirements for other components

Object Parcel

An object parcel must be provided that adds information about a parcel that is identified with a unique parcel number: - Parcel must provide a method that provides feedback on the expiry date on which the parcel will be removed from the automatic parcel delivery machine. This is necessary to transfer notifications X days before the expiry. If no expiry date has been specified, a certain number of calendar days (eg 9 days) can be assumed as a standard procedure.

- The DeliveryContract object must be provided via a method.

- The Parcel object provides a method by which access to the automatic is obtained

the package delivery machine where the package is located.

Object Machine

The Machine object provides access to the automatic package delivery machine database 90, which is identified by the automatic package delivery machine ID. - The methods in this object must add information about the location to an automatic package delivery machine.

Objects to be notified (notifiable objects): User, LogisticProvider and LogisticContractor

The User object adds information about a client that is defined by the client number. The LogisticProvider object provides access to the logistics provider database. The object LogisticContractor provides information about a logistics contractor. ■ All objects implement a shared interface Notifiable. It provides the necessary methods for sending a notification to the relevant object, for example for reading the e-mail address or address form. ■ It has been possible to identify a Notifiable object using a unique ID. For this purpose, the ID of the User, the LogisticProvider object and the LogisticContractor object, concatenated with an identification of the object type (US_, LP_, LC_), can be returned via a method getUniquelD. This method should preferably be defined in the Notifiable interface. ■ To reconstruct a Notifiable object again via this ID, an object factory is implemented which forms the appropriate object on the basis of such an ID.

The logic objects DeliveryContract, LogisticProvider and LogisticContractor ■ The B2B logic must be requested for all objects, for example via a shared interface. ■ Such an object must be identified via a unique ID. For this purpose, the ID of the Notifiable object (getUniquelD) that already exists for LogisticProvider and LogisticContractor can be used. A corresponding method can also be present in the DeliveryContract which then provides feedback about the ID of the object, combined with an identification of the object type (DC_).

To further improve the procedure, it may be advantageous to perform the following measures individually or together: ■ All the emails are sent offline by being written into a communication queue from which they are read out at regular intervals and processed. ■ The implementation can support any (but preferably fixed) language.

■ The e-mails are preferably sent as plain text.

However, particularly preferred embodiments of the invention are:

■ Support of HTML formatted email.

■ Here, at the time of registration, the client can choose in which format he wishes to receive e-mail (plain text or HTML). Different templates are thus used during the sending procedure.

■ Possibility of several languages.

The client can choose his preferred language at the time of registration. Different templates are thus used during the sending procedure.

■ Support for notifications via the RFC1149 standard

■ Furthermore, a ContentManagementSystem can be used to make it easier to handle the templates for e-mail and SMS.

Claims (5)

1. Method for transmitting notifications to users of a logistic system, where the logistic system includes one or more parcel room systems with one or more registered users and where the notification orders are transferred to a central dispatch component (30) which, on the basis of the orders, generates appropriate notifications and sends them to users whereby the sending component (30), in order to generate the notifications, accesses one or more databases, characterized by the steps: - different modules with associated functions are called up in response in each case to different events in the logistic system, whereby the modules are a client database, a registration unit and/or a system management unit for the logistic system, - the modules generate notification orders, - the notification orders generated by the modules are either transmitted to a central sending unit (30) so that they can be sent immediately or they are written into a communication request queue (40) so that they can be sent in a delayed manner, whereby the notification orders are read from the communication request queue (40) by using a key reader (50) in a time-controlled manner and transmitted to the central sending component (30), - the central sending component (30) generates the appropriate user-specific notifications, whereby, to generate the notifications, the sending component (30) accesses at least one client database ( 70), a package database (80), an automatic package delivery machine database (90) and a document database (100), - the central delivery component sends the appropriate user-specific notifications to the users via a system port (120, - the status of the notification orders is validated in a DeliveryContractLogic (60) before transmission to the central delivery component ( 30). 2. Procedure according to claim 1, characterized in that the client data, the package data and the package room system data are all allocated in the databases by means of IDs. 3. Method according to one or both of claims 1 and 2, characterized in that the events in the logistic system include at least the following: - registration of the new user - change of the user data - placement of a new package in a parcel room system - collection of a package from a parcel room system - addition of a substitute for collection of a parcel - removal of a substitute. 4. Method according to one or more of the preceding claims 1 to 3, characterized in that the notifications are sent to the users in the form of e-mail and/or SMS. 5. Device for transmitting notifications to users of a logistic system that operates one or more parcel room systems, characterized in that the logistic system consists of at least modules that each have functions for generating notification orders, of a central dispatch component (30), of a communication request queue (40), of a document database (100) with templates (110) for generating individual notifications for the specific users, by a client database (70) with information about clients, by a package database (80) with information about packages, by an automatic package delivery machine database (90) with information about the package room systems and by a system port (120) for sending the notifications , whereby the modules are a client database, a registration unit and/or a system management unit for the logistic system.