EP1916627A1 - Verfahren zum Erzeugen eines Labels, Computerprogrammprodukt, Netzwerkknoten und System zur Durchführung des Verfahrens - Google Patents

Verfahren zum Erzeugen eines Labels, Computerprogrammprodukt, Netzwerkknoten und System zur Durchführung des Verfahrens Download PDF

Info

Publication number
EP1916627A1
EP1916627A1 EP06022477A EP06022477A EP1916627A1 EP 1916627 A1 EP1916627 A1 EP 1916627A1 EP 06022477 A EP06022477 A EP 06022477A EP 06022477 A EP06022477 A EP 06022477A EP 1916627 A1 EP1916627 A1 EP 1916627A1
Authority
EP
European Patent Office
Prior art keywords
label
der
server
die
document
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP06022477A
Other languages
English (en)
French (fr)
Inventor
Henning Endruscheit
Volker Klös
Thomas Ogilvie
Boris Mayer
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Deutsche Post AG
Original Assignee
Deutsche Post AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Deutsche Post AG filed Critical Deutsche Post AG
Priority to EP06022477A priority Critical patent/EP1916627A1/de
Priority to EP14164250.4A priority patent/EP2800065B1/de
Priority to US12/447,264 priority patent/US8477345B2/en
Priority to PCT/EP2007/009183 priority patent/WO2008049579A1/de
Publication of EP1916627A1 publication Critical patent/EP1916627A1/de
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B17/00—Franking apparatus
    • G07B17/00459—Details relating to mailpieces in a franking system
    • G07B17/00508—Printing or attaching on mailpieces
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B17/00—Franking apparatus
    • G07B17/00016—Relations between apparatus, e.g. franking machine at customer or apparatus at post office, in a franking system
    • G07B17/00024—Physical or organizational aspects of franking systems
    • G07B2017/00048—Software architecture
    • G07B2017/00056—Client-server
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B17/00—Franking apparatus
    • G07B17/00016—Relations between apparatus, e.g. franking machine at customer or apparatus at post office, in a franking system
    • G07B17/00024—Physical or organizational aspects of franking systems
    • G07B2017/00048—Software architecture
    • G07B2017/00056—Client-server
    • G07B2017/00064—Virtual meter, online stamp; PSD functions or indicia creation not at user's location
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B17/00—Franking apparatus
    • G07B17/00016—Relations between apparatus, e.g. franking machine at customer or apparatus at post office, in a franking system
    • G07B17/0008—Communication details outside or between apparatus
    • G07B2017/00145—Communication details outside or between apparatus via the Internet
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B17/00—Franking apparatus
    • G07B17/00185—Details internally of apparatus in a franking system, e.g. franking machine at customer or apparatus at post office
    • G07B17/00435—Details specific to central, non-customer apparatus, e.g. servers at post office or vendor
    • G07B2017/00443—Verification of mailpieces, e.g. by checking databases
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B17/00—Franking apparatus
    • G07B17/00459—Details relating to mailpieces in a franking system
    • G07B17/00508—Printing or attaching on mailpieces
    • G07B2017/00572—Details of printed item
    • G07B2017/0058—Printing of code
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B17/00—Franking apparatus
    • G07B17/00459—Details relating to mailpieces in a franking system
    • G07B17/00508—Printing or attaching on mailpieces
    • G07B2017/00612—Attaching item on mailpiece
    • G07B2017/0062—Label

Definitions

  • the invention relates to a method for producing a label that can be applied to a mailpiece.
  • the invention further relates to a computer program product, a network node and a device for carrying out the method.
  • Such labels are generated for example by a suitable data processing unit - for example a personal computer.
  • this object is achieved by a method having the features of patent claim 1, a computer program product according to claim 14, a network node according to claim 15 and by a system according to claim 16.
  • a method for generating a label is performed such that a network node provides a data service that is executed in at least one provider server of a service provider, wherein data for insertion into the label is generated.
  • a development of the method, the computer program product, the network node and the system is characterized in that the data service is an Internet service.
  • Return labels are labels that allow a user of the computer system to return mail received from him to a sender.
  • a further development of the method, of the computer program product, of the network node and of the system is characterized in that a checking step is carried out to check a voucher and, depending on the result of the checking step, the generation of the label is influenced.
  • a further development of the method, of the computer program product, of the network node and of the system is distinguished by the fact that it precedes the checking step Process step, the coupon is transmitted to a user.
  • a further development of the method, of the computer program product, of the network node and of the system is characterized in that a program module is introduced into the intelligent document which is designed to provide a displayable indication of a result of the checking step or of a further checking step for checking the existence of the prerequisite within the intelligent document.
  • a development of the method, the computer program product, the network node and the system is characterized in that at least one of the test steps is performed by means of the program module.
  • a further development of the method, of the computer program product, of the network node and of the system is characterized in that in the checking step it is checked whether the program execution environment is available.
  • a development of the method, the computer program product, the network node and the system is characterized in that a program controls a one-time printing of the label and that an intelligent document is transmitted from a server to a client via a network.
  • a further development of the method, of the computer program product, of the network node and of the system is distinguished by the fact that, at the first printing of the label, a message is transmitted from the user client to the server and that the print due to the message is logged in the server becomes.
  • a further development of the method, of the computer program product, of the network node and of the system is characterized in that the program for controlling the printing of the label can only be executed if there is a network connection between the client and the server and if it is determined by means of a query of the server has been that the label has not yet been printed.
  • a further development of the method, of the computer program product, of the network node and of the system is characterized in that it is checked in at least one of the checking steps whether there is access to the network.
  • a refinement of the method, of the computer program product, of the network node and of the system is characterized in that in at least one of the checking steps a query of the server is made, in which it is checked whether contents of the intelligent document have already been printed once.
  • a further development of the invention includes a system that enables customers to request and print labels via an online interface via a PC, which is referred to below as a user client.
  • the interface is provided by a server, hereafter referred to as POP server (POP: Parcel Online Postage).
  • the customer first generates one or more entries for mailpieces to be sent in a shopping cart on a first page provided by the POP server (referred to below as NOW 1). Contains this the website NOW 1 a button through which the user can access another website (hereinafter referred to as NOW2, the shipment details represents) on the data of a broadcast can be detected and manipulated.
  • NOW 1 a button through which the user can access another website (hereinafter referred to as NOW2, the shipment details represents) on the data of a broadcast can be detected and manipulated.
  • the data include, for example, the sender address, the recipient address and a selection of the products and services as well as the destination countries, from which in particular the postage value for the shipment results.
  • the user can specify one or more additional services for the shipments. These include, for example, a roll service for round packaging or a specific bulky goods service, whereby these forms are only examples of additional services.
  • the shopping cart contains at least one entry, another button is active on the website NOW 1, via which the customer can initiate a payment process.
  • NOW 3 a website which contains links to PDF documents which enable the printing of the acquired franking label. Furthermore, after the payment has been made, an e-mail will be sent to the customer which contains a link to the website NOW 3, which will allow the website to be called up again at a later date. The e-mail will be sent to an address previously entered by the customer on the NOW 1 website. If the value of the shopping cart exceeds a certain amount, the access to the website NOW 3 becomes over The link contained in the e-mail is secured by a PIN, which is presented to the user on the NOW 3 page but not transmitted by e-mail.
  • a further development of the invention includes a voucher functionality that allows a customer to purchase vouchers and use them for the payment of postage indicia.
  • the vouchers can be added to the shopping cart on the website NOW 1. Via a corresponding button on this website, the user can access another website (NOW 2 - Voucher Details) where voucher sets for a base product also selected on this page can be added to the shopping cart. After payment of the shopping cart, the user is offered a possibility on the website NOW 3 to display or save the purchased coupon codes. For the later redemption of the voucher the voucher code is entered by the customer when generating the shopping cart on the website NOW 1.
  • the invention is suitable for creating different labels, in particular for producing labels for controlling logistical functions of the mailpieces, in particular their transport, sorting and / or forwarding.
  • the labels contain, for example, monetary information as proof of payment, so that it is an example of franking labels.
  • the labels may contain further information for handling the mailpieces-for example a sender address, a recipient address, a mailing identification code or other data describing the mailing (eg weight or dimensions). This is a use of the label to monitor the shipment history (Tracking) or to a proof of the shipment history (tracing) possible.
  • the labels contain, in addition to the address of the recipient and the sender, a routing code assigned to the recipient address, which is used in the production of the mailpieces in a parcel or letter center of a mailing service provider.
  • the label includes a unique label identification code.
  • abuse cases can be determined in which a franking label is used several times for the franking of mail.
  • the label identification codes of the issued franking label are stored in a payment assurance system.
  • the label identification code is marked as used in the pay-as-you-go system.
  • Guide code and label identification code are inserted into the label both in plain text and in the form of a bar code.
  • the franking labels are provided to the customer on the basis of intelligent PDF documents.
  • the invention includes various embodiments for generating the label and for its expression. Particularly preferred embodiments are mentioned below:
  • the POP server receives notification of the payment transaction from the payment provider.
  • a Document database generates a record for the purchased by the customer franking label.
  • the record contains a unique document identification code for the intelligent PDF document, an indication of whether the label has already been printed with valid codes, and form data.
  • the form data includes the sender and recipient address of the mail to be franked, the routing code.
  • the form data includes the label identification code that is extracted after payment from a pool of previously generated codes. This code will also be transferred to the pay-as-you-go system. It also generates an intelligent PDF document, which is an empty form with form fields for the form data mentioned above.
  • the designation of the PDF document is the document identification code.
  • the label is printed as part of the iPDF mechanism by means of a communication between the user client and the POP server or a license server connected to the POP server, which can access the document database.
  • the SOAP interface of the Acrobat Reader is used for communication between the user client. After opening the PDF document, it is first checked successively whether an Internet connection is present, whether the document identification code is valid and whether the label has not already been printed. To perform the last two test steps, a service of the POP server is called via the SOAP interface of the Acrobat Reader, which returns after a corresponding query the database whether a record for the document identification code in the document database is present, and if the postage indicium already as printed has been marked.
  • the form data stored in the database are loaded via the interface of the Acrobat Reader from the POP server and inserted into the form fields of the PDF document.
  • the PDF document initially only contains dummy codes to prevent the user from making a copy of a valid label.
  • the content of the document is first clearly marked as a pattern.
  • the PDF document provides its own functionality, in which test prints and a print of a valid label - referred to as postage printing - can be carried out via corresponding buttons within the document.
  • postage printing - can be carried out via corresponding buttons within the document.
  • the pattern of the label initially contained in the PDF document is printed with the dummy codes.
  • the valid label is printed, with the valid barcodes being retrieved from the POP server after pressing the appropriate button. Further, by pressing the button for the postage printing in the document database of the POP server is registered that a print of the valid label has been made and the button is hidden or disabled.
  • the label can have different shapes. It is preferably designed so that it allows identification and / or control of mail and possibly also the coordination of a storage space.
  • Coded information is incorporated into the labels as control instruments for the parcel logistics.
  • the labels may contain a consecutive numbering - possibly with check digit -, other numbering and address information or other information that classify the shipment or serve for advertising purposes, for example.
  • RFID identification systems "smart labels” - make it possible to optimize logistics processes.
  • a transmission of the label to the operating unit preferably takes place in the form of an intelligent document.
  • an intelligent document which comprises a program which, if a prerequisite is present, can be executed by means of a program execution environment and contains contents which can be displayed by means of a presentation program.
  • the intelligent document is characterized by comprising a program module adapted to generate a displayable indication of a result of the checking step for checking the existence of the prerequisite within the intelligent document.
  • a further embodiment of the method, the intelligent document and the device includes that the program execution environment is part of the presentation program.
  • a label can also be generated independently of a business transaction described above, which for example serves for private shipping purposes or has the goal of generating a postage indicium with the aim of using it for the return of one or more articles to a sender.
  • the shipping and / or franking relevant data from the shipping information system or the listing tools are automated - i. without further action by the seller - handed over via an interface to a means for creating a label (Labelerstelldienst).
  • a label is preferably a graphical representation - for example, an expression or a screen display of an intelligent document.
  • a further development of the invention includes a method for generating an intelligent document comprising a program which, if a prerequisite is present, can be executed by means of a program execution environment and contains contents that can be displayed by means of a presentation program.
  • a preferred embodiment of the invention is characterized in that the displayable contents consist of static content and dynamic content, wherein an introduction of the dynamic content into the intelligent document takes place separately from an introduction of the static content.
  • address data and / or franking-relevant data are examples of dynamic contents in the sense of preferred developments of the invention.
  • Static information is information that, in particular, allows data to be embedded.
  • the frames may also be so-called frames.
  • a frame is a subarea of a graphical representation, in particular a screen page, for example a graphical user interface.
  • a single segment is referred to as a frame (English expression for frame), the definition of all frames as a frameset.
  • the use of frames enables the parallel display of several individual documents, which can be moved independently of each other if necessary.
  • the frames can be used to combine content from different sources or from different data sources.
  • inline frames can be used. They allow a particularly simple data integration into a displayed screen page.
  • the intelligent document comprises a program, which, if a prerequisite is available, can be executed by means of a program execution environment and contains the content that can be displayed by means of a presentation program.
  • the method is performed such that two different types of content are introduced into the intelligent document, which may originate from one or more sources.
  • a first type of content is static content.
  • Static content preferably matches multiple documents.
  • the static contents are preferably those contents that are suitable for generating multiple documents. Generating multiple documents is very beneficial, but not necessary.
  • the static contents are, for example, frame information for the generation of documents or other information whose update occurs less frequently than in the case of the dynamic contents, preferably only at the end of a predefinable time interval or when an event is reached. Alternatively, it is possible to leave the static data completely unchanged.
  • an intelligent document which comprises a program which, if a prerequisite is available, can be executed by means of a program execution environment and which contains contents which can be displayed by means of a presentation program.
  • the intelligent document is characterized by the fact that a program module is included, which is designed to is to produce a presentable indication of a result of the checking step for checking the existence of the prerequisite within the intelligent document.
  • An embodiment of the invention provides that the program module is a component of the static content.
  • a development of the invention is characterized in that the program module is a component of the dynamic content.
  • a particularly preferred embodiment of the invention provides that the program module is either part of the dynamic content or the static content.
  • a device for generating a smart document which comprises a program which, if a prerequisite is available, can be executed by means of a program execution environment and which contains contents that can be displayed by means of a presentation program.
  • the apparatus is arranged to introduce a program module into the intelligent document that is configured to generate a displayable indication of a result of the checking step for checking the existence of the prerequisite within the intelligent document.
  • the intelligent document provides that a program module is contained in the intelligent document itself with which an indication of the result of a checking step can be generated. This is the intelligent document itself to indicate the result of a test step so that the result of the checking step is displayed regardless of the configuration of the presentation program.
  • an indication that can be displayed within an intelligent document is an indication that can be displayed by means of the presentation program, for example, on a screen.
  • intelligent documents may contain further contents, such as program codes, which are not displayed by means of a presentation program, at least in a normal presentation mode.
  • the method according to the invention for generating a smart document comprising a program that can be executed in the presence of a prerequisite by means of a program execution environment that contains displayable content by means of a presentation program can be developed in various ways.
  • the intelligent document and the device provides that the static contents are transmitted from a server to a client via a network.
  • An embodiment of the method, the intelligent document and the device provides that the dynamic contents are transmitted from a server to the client via a network.
  • a transmission of the dynamic contents, independent of a transmission or non-transmission of the static contents, has the advantage that the data transmission expense for the generation of a smart document is reduced.
  • a further development of the method, the intelligent document, the computer program product and the device provides that the static contents and the dynamic contents are transmitted separately from one another.
  • a development of the method, the intelligent document, the computer program product and the device provides that the transmission takes place separately in time.
  • An embodiment of the method, the intelligent document, the computer program product and the device is characterized in that the transmission takes place on different transmission paths.
  • a further development of the method, the intelligent document, the computer program product and the device provides that the static contents are provided by a different data source than the dynamic contents.
  • An embodiment of the method, the intelligent document, the computer program product and the device is characterized in that the static contents are transmitted from a first server and that the dynamic contents are transmitted from another server.
  • a further development of the method, the intelligent document, the computer program product and the device provides that the static data is stored in an area of a client.
  • the documents are used in particular by a client.
  • the client is advantageously available to a user of the system and is therefore also referred to as a user client in the present application.
  • the client is preferably equipped to recognize whether the document transmitted is an intelligent document. This is done in a development of the invention in that the presence of a confirmation information is checked.
  • the confirmation information is a signature.
  • One embodiment of the method, the intelligent document, the computer program product, and the device provides that the client, upon opening a document, checks to see if it has been signed.
  • the static content is preferably transmitted separately from the dynamic content.
  • the static contents are, for example, layout information for the design of the document.
  • the static contents of the dynamic content differ by the time of each generation.
  • the static content and the dynamic content can also differ from one another by the event that triggers them each time.
  • a development of the method, the intelligent document, the computer program product and the device provides that the static contents are transmitted in the presence of a first event.
  • An embodiment of the method, the intelligent document, the computer program product and the device is characterized in that the static information is transmitted in the presence of an event of a first type of event.
  • a development of the method, the intelligent document, the computer program product and the device provides that the dynamic contents are transmitted in the presence of a second event.
  • An embodiment of the method, the intelligent document, the computer program product and the device is characterized in that the dynamic information is transmitted in the event of an event of a second type of event.
  • a development of the method, the intelligent document, the computer program product and the device provides that a presence of the second event is determined taking into account a checking step.
  • An embodiment of the method, the intelligent document, the computer program product and the device is characterized in that the first event differs from the second event.
  • a further development of the method, the intelligent document, the computer program product and the device provides that the first type of event differs from the second type of event.
  • an intelligent document which comprises a program which, if a prerequisite is available, can be executed by means of a program execution environment and which contains contents which can be displayed by means of a presentation program.
  • the intelligent document is characterized in that it includes a program module adapted to generate a displayable indication of a result of the checking step for checking the existence of the prerequisite within the intelligent document.
  • a device for generating a smart document which comprises a program which, if a prerequisite is available, can be executed by means of a program execution environment and which contains contents that can be displayed by means of a presentation program.
  • the apparatus is arranged to introduce a program module into the intelligent document that is configured to generate a displayable indication of a result of the checking step for checking the existence of the prerequisite within the intelligent document.
  • a further development of the invention of the invention is that in the intelligent document itself a program module is included, with which an indication of the result of a test step can be generated.
  • the intelligent document itself is capable of indicating the result of a checking step, so that the result of the checking step is displayed regardless of the configuration of the presentation program.
  • a representable indication within a smart document is understood in the context of the invention to be an indication which can be displayed by means of the presentation program, for example on a screen.
  • intelligent documents may contain other contents, such as program code, which are not displayed by means of a presentation program, at least in a normal presentation mode.
  • the intelligent document and the device it is provided that the checking step is carried out by means of the program module.
  • the program module in this embodiment is also designed to carry out the checking step, so that the intelligent document can check itself independently of the specific configuration of the presentation program.
  • a refinement of the method, the intelligent document and the device is characterized in that it is checked in the checking step whether the program execution environment is available.
  • This development has the advantage that it is checked whether the program execution environment is available, so that the user can be informed if necessary that the program execution environment is not present and therefore certain functions of the intelligent document are not available.
  • the verification step can not be performed directly by executing a program.
  • the indication of a negative result of the checking step can not be introduced into the intelligent document by means of the program module.
  • An embodiment of the method therefore comprises inserting into the intelligent document a displayable indication of a negative result of the checking step, and in that the program module is adapted to convert the indication of the negative result of the checking step into a representable indication of a positive result of the checking step.
  • an embodiment of the intelligent document provides that the intelligent document contains a displayable indication of a negative result of the checking step, which can be converted by means of the program module into a displayable indication of a positive result of the checking step.
  • an embodiment of the device is characterized in that the device is designed to introduce a displayable indication of a negative result of the checking step in the intelligent document, and that the program module is arranged to convert the presentable indication of the negative result of the checking step into an indication of a positive result of the checking step.
  • the test of whether the program execution environment is present can advantageously be made implicitly by means of the program module generating the indication of the result of the verification step within the intelligent document. This is achieved by virtue of the execution of the program module, which can only take place when the program execution environment is available, an indication of a positive result of the checking step by conversion of an indication of a negative result of the checking step already present in the intelligent document. If the program execution environment is not available, the program module can not be executed and the indication of the negative result of the verification step is retained.
  • the program controls the one-time printing of a postage indicium and that the intelligent document is transmitted from a server to a client via a network.
  • An embodiment of the method, the intelligent document and the device is further characterized in that at a first print of the postage indicium, a message is transmitted from the client to the server and that the pressure due to the message is logged in the server.
  • the intelligent document and the device that the program for controlling the printing of the postage indicium is executable only if there is a network connection between the client and the server and if it is determined by means of a query of the server in that the franking mark has not yet been printed.
  • An embodiment of the method, the intelligent document and the device is characterized in that it is checked in the checking step, whether an access to the network exists.
  • the intelligent document and of the device includes that in the checking step a query is made of the server, in which it is checked whether contents of the intelligent document have already been printed once.
  • a further embodiment of the method, the intelligent document and the device includes that the program execution environment is part of the presentation program.
  • a computer program product which includes a computer program for carrying out a method of the kind described above.
  • the invention includes various possibilities for generating a label that can be applied to a mailpiece.
  • the method for generating a label that can be applied to a mailpiece is developed further into a method for producing a mailpiece.
  • the invention is also a method and a system for transporting mailpieces.
  • the static contents relate, for example, to frame information.
  • This frame information preferably forms a graphically displayable frame.
  • Dynamic content can be included in this framework.
  • Batch jobs are written before a parallel, i. Protected against multiple starts, to prevent unwanted side effects.
  • FIG. 2 shows an overview of particularly advantageous interfaces.
  • the interfaces serve for a connection between a provider server according to the invention with a provider server (called a provider).
  • the invention advantageously takes place via the Internet.
  • the provider server can be connected to a client (user system).
  • the client is a user system that is equipped to receive data from the server and / or to communicate data to the server.
  • the client is a personal computer, a corporate network, or a mobile user terminal, such as a mobile phone.
  • the client is designed to include browser functionality.
  • the list of mentioned browsers can be extended at any time to take account of developments.
  • HTTP can be used instead of HTTPS.
  • the numbers generated by the application - vouchers, documents, shopping cart, PIN - are generated in such a way that they can not be guessed by the user.
  • these numbers are stored in the database and so their "consumption" controlled.
  • Access data required for the use of the external interfaces are stored in the database via a symmetric encryption method (contained in the web application). H. These can also not be viewed by a database administrator.
  • the actual payment transactions are carried out on the websites of the payment platform, so that this transaction is encapsulated for the application.
  • Data is not deleted in the database, but only in accordance with z. For example, an attribute is highlighted.
  • the subsequent access of a user to his shopping cart is made from a certain price volume via the additional input of a PIN or PIN2.
  • the configuration management with the time-dependent data (eg prices, vouchers) and the static resources is designed in such a way that once created and already productively switched configurations can no longer be removed from the database. Furthermore, the configuration data valid at that time can be reconstructed for each point in time in the past.
  • Input fields are specially marked (Edit, Input); otherwise the fields described are pure display fields without any further function. Possibly. the following information in parentheses such as AN (64) means "maximum 64 digits alphanumeric"; analogous to N (6) "maximum 6 digits numerically”. If not specified more precisely, these are single-line input fields with free input (no drop-down list or similar). For validation errors (wrong format, missing input), the corresponding field or area is highlighted in color.
  • This page shows the shopping cart and included items in an overview. The user can create or manipulate entries in the shopping cart and ultimately initiate payment.
  • This entry appears after all consignment and voucher set items and only if a pickup for the shopping cart is booked. The displayed price will be recalculated every time the basket is changed.
  • the user can post individual services to a shipment item.
  • the change becomes active immediately after the selection, i. h., the website will be reloaded after each action. If no corresponding product exists for the selected combination, an error message is displayed.
  • it can also be achieved by technical methods that no complete reload of a page is required to reconfigure a price.
  • the default address for the sender address is the address of the first program, if available.
  • the entry is a coupon number.
  • the voucher is assigned to the consignment in whose line the number was entered. If the code is incorrect, an error text such as "Invalid coupon code", "Coupon code expired” or "Coupon does not match the shipment” will be displayed at the defined location. If no product has been selected for the shipment, it will be set using the coupon code.
  • TAS collection If a TAS collection is included in the voucher, it will be automatically booked for the whole shopping cart.
  • the user Via the pop-up window that appears, the user enters the collection date and the collection address. The costs for collecting the TAS will then be displayed in a separate shopping cart position.
  • the user can use a drop-down list to enter a pickup date and a pickup address.
  • the date list contains n consecutive days in chronological, ascending order. The first day is preselected. Sundays are not offered in the list. Whether the next day is still displayed in the list is decided with the help of a configurable time: If the current system time is still before this time, the next day is offered; Otherwise at the earliest the next but one. The total number of entries in the list can also be configured.
  • the sender address of the first shipment is used as the initial default for the pickup address.
  • the window can only be exited with "Confirm" if the fetch address is coded. In the event of an error, a message appears as shown in the screenshot.
  • the user wants to pay for the shopping cart, he will be asked to confirm the e-mail address entered in the shopping cart with the help of this pop-up window. (Exception: the address is the e-mail address transmitted via Maptos). If necessary, the information in this window can be overwritten.
  • the routing codes of the receiver addresses are determined. This process is synchronized to immediately display the results.
  • the particular routing code or status address is not conductively coded is stored within the user session at each address to minimize the number of Leitcodierier Stamme for performance reasons.
  • the data of a shipment such as addresses and product can be captured and manipulated. If the product is not set, the product matching the recipient country (highest sort key value) is preselected.
  • the sender and recipient address are recorded in the upper part of the page.
  • a drop-down list is offered for the sender and receiver country from which the user can select the country.
  • a free input is not possible, but generally conceivable. If there is no explicit indication for the country, "Germany" will be used as default.
  • the country list is stored in the system.
  • the possible basic products are displayed (usually “packet”, “packet 10kg”, “packet 20kg”, which are only examples of basic products), from which the user must select exactly one. If no product has been stored for the shipment, the first entry is automatically selected. When selecting a product, the page is updated and the product price valid for the selected product and the current combination of services is displayed.
  • the services available for the combination of recipient country and basic product are offered for selection.
  • the page is updated and the current price for the selected services is displayed.
  • the consignment will be updated and the shopping cart page NOW1 will be displayed again.
  • This page contains user-acquired trademarks in the form of links to the PDF documents and, if applicable, a list of purchased coupon codes. It will be displayed after successful payment of the basket. Alternatively, the user can return to this page via a link in his confirmation e-mail.
  • the user can also later access the NOW3 page via a link contained in the e-mail. If the shopping cart exceeds a certain minimum value, this access is secured by entering a PIN or PIN2 in the NOW3 Login screen
  • a block describes a rectangular area of a website.
  • the content of the building block is static.
  • the building blocks can also be described in their nature only by data conventions, so that the design of the building blocks themselves can take place completely through a marketplace.
  • a building block can be dynamically loaded by the POP application and embedded in its own pages.
  • this module may contain a simple link to the shopping cart page (NOW1), via which a marketplace customer can access the POP application.
  • This block is displayed on the NOW1 page on the bottom left.
  • a FAQ block Clicking on a question in the module opens a popup window with the FAQ text.
  • the result is a sum of 101 characters (upper limit PayPal: 127 characters).
  • the POP application can be addressed via Maptos, initially displaying the NOW1 page.
  • Maptos initially displaying the NOW1 page.
  • direct access to the NOW3 page - possibly with additional login via PIN or PIN2 - is possible via the link in the confirmation e-mail.
  • the service "pickup TAS" can only be selected completely for the entire shopping cart. Here an indication of a collection date is mandatory. In a further development, a time window for picking up a mail item can also be selected during pickup.
  • a single service is preferably defined using the following attributes.
  • Products can be administered country-specific.
  • a special identifier "EU” is introduced.
  • EU identifier
  • products can then be assigned to several countries at the same time.
  • the assignment "EU” is used only as long as no product is assigned to a "real" country.
  • new marketplaces can be defined via the admin web.
  • the marketplaces are, for example, the provider shown.
  • the positive list contains all products available in the system. Each line describes a single product. The "left" side (product number, product name, basic product specification, country) can occur several times. The right-hand sides of the table lines then specify all valid combinations of services that can be assigned to this "left-hand side". Each line always includes the base product itself.
  • the list it is useful to design the list so that it applies to all marketplaces.
  • the list and the system are matched to each other such that combinations not contained are invalid.
  • each line one or more countries can be referenced via a list of iso-codes (3-digit analog Maptos).
  • EU The special abbreviation "EU” stands for all EU countries (these are in a list).
  • the products can be selected depending on the recipient country: only the products that are assigned to this country are offered.
  • Objects that support this approach have an MZF (Marketplace TimeWindow) header that includes the following attributes:
  • the total price of a product line then results first from the sum of the individual prices.
  • the default price list (marketplace-independent) can look like this:
  • each base product and service with the exception of the TAS Pickup, must be priced as a "landless" entry. All other entries are optional. For example, if no price were defined for (package, DEU), the price of (package, *) would be used as default.
  • a suitable search order can be used to calculate a clear price for each line in the positive list (and, if applicable, depending on the marketplace and a point in time). This is simply the sum of the price for the base product + land and the associated services + land.
  • a special price for a packet DEU is defined (start and end of the period can be specified to the minute):
  • Example Results I (the Roman numerals behind the prices indicate the price table used).
  • the search criteria will be as above, but the current server time will be chosen as an adjustable time slot, for example a day, a week or a month.
  • Example Results II (the Roman numerals behind the prices indicate the price table used).
  • a pick-up takes place for parts of the basket or, what is particularly preferred, for the entire cart.
  • the collection of the pickup is done explicitly on the NOW1 side or implicitly by entering a coupon code that includes a TAS pickup.
  • the invention is developed into a method for handling returns.
  • the prices for the collection are staggered (maximum 5 entries), for example as in the following table:
  • the number of all collectable shipments (based on positive list) in the shopping cart is used to find the price in the table. For more than 5 shipments, the last price of the table is used (according to the example table, a pickup from 5 shipments is always free of charge - which is an exemplary representation).
  • the price scale for the pickup can be specified hierarchically in the same way as the other prices.
  • Building blocks represent a rectangular area on a web page and can be configured hierarchically. They contain an HTML fragment, which in turn may be individual Images, css files, etc. can reference. Blocks are addressed by a logical name.
  • vouchers Before coupons can be purchased by the user or distributed as part of marketing campaigns, vouchers must be defined at the administrative level.
  • Voucher definitions are addressed by their name ( screen name ) , which can be freely assigned but which is as unambiguous as possible in the attachment.
  • the coupon definition When the coupon definition is created, it is determined whether it is a promotional coupon or a coupon (code) to be purchased by the user.
  • a voucher can either represent an absolute amount of money ("value 10 euros”) or be redeemable exactly for the product for which it is deposited ( 100% voucher ) .
  • the 100% voucher covers the product "package including TAS collection", for the consignment in the shopping cart the product "package with TAS pick-up and roll” is selected by the user. As a result, the user only has to pay for the "role” service.
  • the "value" of a voucher can be exhausted incompletely, for example, if a voucher price is above the current price for "covered” products; the residual value of the voucher expires in this case.
  • the user can buy coupons in packages.
  • a denomination with up to 5 different denominations can be defined (eg "5s, 10s, 20s, 50s, 100s").
  • a separate absolute price including sales tax is defined.
  • One of the denominations is defined as the default value.
  • a time window defines the period during which the coupon is offered for sale to the user.
  • the end of the time window can be limited or unlimited.
  • Purchasable coupons can only be redeemed after purchase, that is, only after they have been paid and are available to the user in the form of coupon codes.
  • a time window is used to set the period in which a single coupon code can be redeemed. Either this is a relative indication in days ("maximum 30 days after purchase redeem") or an absolute date ("until 31.12.2007”).
  • Purchase vouchers can only ever be used once. For promotional vouchers, you can alternatively specify whether the codes can be used any number of times. These are then redeemable for one or more shipments within a single basket of goods.
  • vouchers can be generated for print actions that can be used as often as desired.
  • promotion vouchers can also be generated for e-mail promotions, which can only be used once, just like purchase vouchers.
  • a coupon type can be assigned to a single marketplace.
  • the vouchers will then be offered for sale only on this marketplace.
  • the purchased coupon codes are redeemable exclusively on this one marketplace.
  • Each voucher is assigned a numerical sorting number, which can be used to determine the display order.
  • Coupon codes are generated either when purchasing a coupon set or when generating promotion codes via the admin web.
  • coupon code A single coupon is defined by this unique alphanumeric identifier ( coupon code ), which should not be easily guessed.
  • the code is stored with associated data in the system.
  • Each newly created shopping cart is associated with the generation of a unique numeric shopping cart ID. This will be displayed to the customer on page NOW3. It also appears on the account statement of the user on successful booking. With this ID, users can refer to their shopping cart, for example, during telephone support inquiries.
  • the preliminary tests have shown that the data of the shopping basket are valid and the payment process can be prepared.
  • a link is embedded with an attached key, which also allows him to subsequently open the NOW3 page. If the shopping cart exceeds a certain value, this entry is additionally made via the entry a PIN or PIN2 secured (four-digit numerical values).
  • the PIN is displayed by the user immediately after purchasing the shopping basket on page NOW3 - provided with a corresponding note text. Alternatively, he can also enter the PIN2 that he can find on his bank statement.
  • the "PDF Label” application generates PDFs with labels that can be printed by the user and pasted onto the package (parcel, parcel, etc.).
  • the product / logo block contains a logo of a company and the product name of the basic product.
  • the product name is determined from the product configuration.
  • the sender block complies with the Common Label specification in the following table: field name Type description Name (addition String (35) 2 lines First and last name Company name Street, house number String (35) Postcode & City String (35) The country is not imprinted by the application. country String (35) Country in capital letters
  • the recipient block complies with the Common Label specification in the following table: field name Type description Name (addition String (35) 2 lines First and last name Company name Street, house number String (35) Postcode & City String (35) country String (35) Country in capital letters
  • product-specific characters can be printed.
  • the content of the impression is configured per product.
  • shipment information block field name Type description Billing No string Contains EKP number + participation + procedure EKP number is configured for the combination of payment platform and marketplace in the application. Participation is always "00" Procedure is configured per product in the application.
  • Shipment No. string Contains identity code of the shipment Dimension / Weight string Dimension: If data corresponding to the shipment is supplied by Maptos, these will be filled. Weight: If data corresponding to the shipment is supplied by Maptos, these will be filled. Otherwise, a default weight configured per base product will be printed
  • the customer information block is not used by the application.
  • This delivery document has a standard paper format (for example DIN A 6 to DIN A 4).
  • Preferred dates of the delivery receipt are: field name description identcode Identcode (IDC) Numeric receiver Recipient address (name, street, number, zip code, city, country) product Name of the product, see product / logo block. Weight Weight of the shipment in kg. See Shipment Information Block Services Services from the handling information block cash on delivery Amount and currency, project phase I empty date Current date (print date) name of the client Sender (name) EKP number EKP number. Shipment information block. Cart number Application number for a shopping cart / payment campaign.
  • the label to be printed is provided with a PDF envelope.
  • this envelope in communication with a license service, the printing of the document contained in the PDF envelope is controlled.
  • these documents are referred to in the present application as iPDF.
  • this document ID is 'embedded' in the iPDF, on the other hand it is also inserted in a database table of the POP application.
  • Fig. 3 shows a schematic representation of an integration of a document production in a system according to the invention.
  • the illustrated system includes a server that allows transfer of displayable content.
  • the content that can be displayed consists of static content and dynamic content.
  • the static contents are incorporated as PDF templates in a document to be generated.
  • Dynamic content is introduced from a suitable server, preferably a POP web server 302, into a document record 303. These dynamic contents may be supplemented by further contents. Other content may be static content or dynamic content, depending on the intended use. Addition of dynamic content is preferred as it allows to create identifiable documents in a particularly simple and convenient manner.
  • this is done by linking the dynamic contents to licensing information 304.
  • the labels are, for example, address labels and / or franking labels.
  • Such labels are particularly suitable for controlling logistical processes, for example tracking and tracing, and for controlling logistical processes, for example for the sorting of mailpieces.
  • the labels are preferably made machine-readable.
  • the label to be printed is provided with a PDF envelope. Within this envelope, communication of the licensing information 304 is enabled in communication with the server.
  • a license service for printing the PDF envelope is thus provided.
  • the license service controls the printing of the document contained in the PDF envelope.
  • this document ID is 'embedded' in the iPDF, on the other hand it is also inserted in a database table of the POP application.
  • mechanisms are installed within the PDF delivered to the user, which check before every print whether the document has already been printed once.
  • Acrobat Reader must connect to a service provided by the POP application that will perform this check.
  • the server application generates a record for each PDF to be generated from the shopping cart, in which all the information required for the generation is already completely resolved.
  • PK field name Type description Document ID ID
  • This ID is also embedded in the delivered iPDF envelope.
  • CreateDate timestamp Timestamp of the generation of the PDF ValidUntil timestamp Date of Expiry Printed timestamp Was the PDF already printed? Downloaded First timestamp When was the PDF loaded for the first time? Downloaded load timestamp When was the PDF last loaded. download Counter integer How often has the PDF been loaded.
  • form Data Blob The form data of the PDF. These include: sender and recipient addresses. Codes for barcodes.
  • Product templates e.g., package green
  • FormularData keeps in a structured form (XML) all already resolved data regarding the data to be printed. So z. B. the already generated packet identifiers, routing codes and possibly further information (even prices, even if this is currently not provided) already held up as numbers or strings. A subsequent calculation of such data is not provided, as this could possibly lead to different results.
  • XML structured form
  • the document record has, for example, the previously described field contents.
  • the user After calling a suitable request, the user can be made available via URL a document ID for later download in the form of a URL.
  • a PDF can be generated directly.
  • the servlet that delivers the PDF now just needs to rename the filename for the PDF so that the document ID is included in the filename.
  • the templates are signed offline during the development or preparation phase for a new product by the Acrobat Reader Extension Server.
  • the document signed by ARES 306 is then imported into the configuration repository in the application.
  • the envelope of the PDF is displayed on the first page.
  • a service provided by the application is called via the SOAP interface of the Acrobat Reader, which returns whether the submitted document ID exists and / or has already been marked as printed in the database.
  • the document ID then uses the SOAP interface to load the form fields from the POP server and fill them in the form fields.
  • the document ID could not be determined - e.g. since the user renamed the PDF document, he is prompted to enter the document ID via an Acrobat form field.
  • the document IDs are also communicated to the user in the e-mail sent to him.
  • the ARES 306 it is useful to use the ARES 306 to introduce new types of documents, especially when launching new service provider products, in order to sign the PDF once. Within the application, the signed document is then introduced as a resource. This installation of the ARES 306 can be done on any computer.
  • the interface for signing a document template can be simple.
  • Downloading PDFs is a simple - quasi-static - delivery of a file through the Pop application. Eventually performance-relevant processes for the impression are eliminated.
  • the PDFs can be created using standard tools provided by, for example, the Adobe company (Acrobat-Professional allows you to define the position of the form fields). Filling the PDF form fields within the Acrobat Reader is a standard feature.
  • the previously selected presentation refers to PDF documents. However, it is also possible to use documents and programs with similar features.
  • Documents in the sense of the present invention are preferably graphically representable. Depending on the application, they can be detected manually or by machine. Depending on the field of use, it is also expedient to provide encryption.
  • the invention also includes documents that are not graphically representable. Documents within the meaning of the invention are in particular smart labels. Smart labels are RFID identification means (transponders). These are suitable for use of control processes in the processing or transport of physical objects, in particular postal items or other goods to be transported.
  • the servlet that delivers the PDF now just needs to rename the filename for the PDF so that the document ID is included in the filename.
  • the templates are signed offline during the development or preparation phase for a new product by the Acrobat Reader Extension Server.
  • ARES itself does not have to be installed in the product environment but must be installed externally on a simple PC with Linux.
  • a command line tool is used, with which one can provide any PDF documents with the necessary rights via the ARES.
  • the document signed by ARES is then imported into the configuration repository in the application.
  • the envelope of the PDF is displayed on the first page.
  • a service provided by the application is called via the SOAP interface of the Acrobat Reader, which returns whether the submitted document ID exists and / or has already been marked as printed in the database.
  • the document ID then uses the SOAP interface to load the form fields from the POP server and fill them in the form fields.
  • the document ID could not be determined - e.g. since the user renamed the PDF document, he is prompted to enter the document ID via an Acrobat form field.
  • the document IDs are also communicated to the user in the e-mail sent to him.
  • the codes can be used for example as Leitcodmaschine.
  • the leading code module of the Online Label Printing application is used for the lead coding of the recipient addresses.
  • the pickup address and the recipient addresses are checked for Leitcodierles.
  • the interface does not return a routing code.
  • Non-Leitcodiersteade addresses are marked as such in the GUI.
  • MinTreffer probability Type Globals: TypeHitsPricability Formation: Element Father Element: Request Minimum hit probability for alternative addresses in percent: Always "100", since the address must be codable. No alternative addresses are evaluated.
  • trailer Type Trailer: TypeTrailer Character: Element Vaterelement: Request System and time of inquiry. z. POP, 24.12.2006T09: 00: 00 address
  • Postcode Type xsd: string Formation: element Parent element: - Postcode of the address place
  • Type xsd: string Formation: element Parent element: - Location of the address
  • TypePruefStatus Formulation Element Parent Element: CheckedAddress Check status: OK, if code-codable TASFehler Type: TypePruefStatus Formulation: Element Parent Element: CheckedAddress Set if PruefStatus is "Non-Condable”.
  • TypeAlternativeAddress Designation Element Parent element: CheckedAddress List of Alternative Addresses at PruefStatus, Alternatives' Not used address
  • Postcode Type xsd: string Formation: element Parent element: - Post Code place Type: xsd: string Formation: element Parent element: - place
  • Country code Type TypePruefStatus Formulation: Raw dataset: LandType Parent element: - Three-digit country code according to ISO 3166-1; id Type: Globals: TypeId Expression: Attributes Father Element: - Unique ID of the address to be checked. hit probability Type: Globals: Type Hit Probability Formation: Element Father Element: - The hit probability of this address in percent
  • an ID for the search address is defined.
  • the address with the same ID must be selected in the XML node ⁇ CheckedAddresses>. If the check status of this address is "OK", the address is code-coded. If one of the addresses can not be coded, the service is not available.
  • the Giropay server responds with suitable parameters.
  • parameter Type description command string Constant "open” payment options
  • String Constant "bank transfer” orderid
  • (17) Unique order number across all marketplaces amount Fix-point number The amount to be paid.
  • currency (3) Currency code according to ISO 4217. Here, the currency configured for the marketplace is used (in Euro I only Euro) bankcode Number (8) Bank code of the bank details, no check is performed by POP.
  • Session ID basketid String (50) order number label0 String (30) Constant "Your order number” text0 String (80) Markplatzkürzel (2) + order number (9) + "many thanks for the use of DHL Express” eg for provider eb123456789, many thanks for the use of DHL Express.
  • the PaySolution server sends a confirmation of the payment to the url stored in the Controlcenter (application of the payment provider). This could be defined as follows: http://pop.dhl.de/Giropay/confirm.do
  • parameter Type description example orderid String (17) clear transaction number across all marketplaces 060626132225 265 amount Fix-point number The amount to be paid. 0.01 currency
  • the application can now load the shopping cart (possibly HTTP session) from the database.
  • the application then checks to see if the amounts and currency specified match those in the shopping cart. Furthermore, a check is carried out via the Message Authentication Code (MAC), which is supplied in response.
  • MAC Message Authentication Code
  • NOW3 displays an error message and of course a corresponding message is logged.
  • the user can now download the PDF documents on NOW3.
  • POP In response to the confirmation of the payment process, POP sends the PaySolution server the url for the return.
  • the PaySolution server performs a redirect in the user's browser to the sent url.
  • Another preferred payment system is the PayPal payment system.
  • the billing of a transaction is done with the PayPal option: "Buy Now and Donations".
  • the total amount incl. Tax is communicated to the PayPal system and billed.
  • the PayPal interface provides two methods for checking the status and correctness of the payment transaction.
  • IPN Instant Payment Notification
  • PayPal addresses a fixed URL of the application defined in the merchant account configuration at PayPal. Parameters are used to transmit the status and data of the payment transaction to the application.
  • IPN is asynchronous to the payment process.
  • the time when an IPN is generated can not be guaranteed by PayPal.
  • the IPN is also processed by the application after the end of the user session.
  • an IPN will be triggered immediately after confirming payment on the PayPal pages.
  • the application retrieves the status of the payment transaction by means of a request to the URL https://www.PayPal.com/cgi-bin/webscr . See procedure PayPal in the positive case, step 5.
  • a parameter set is transmitted via HTTPS in a point-to-point connection with the following parameters: field name Type description cmd string Constant: "notify-synch" tx string
  • TransactionID is passed to the application during the redirect from PayPal back to the application in the parameter tx. at string Dealer identification. Will be assigned by PayPal during the configuration of the merchant account and saved in the configuration of the application.
  • the return parameters in the PDT procedure are provided by PayPal as key-value pairs in the body of the response. Deviating from the IPN, a string is additionally transmitted in the PDT in the first line, which indicates with the value "SUCCESS" that the PDT request was technically successful.
  • FIG. 5 there is shown a flowchart for performing a PayPal payment transaction.
  • the application checks the shopping cart again for possible price changes or other inconsistencies (missing information).
  • the session of the application is appended to the URL.
  • the payment process is checked using the return parameter tx by means of the PDT procedure at PayPal.
  • the application If the first line is not SUCCESS or the payment_status parameter is not "Completed," the application assumes that the payment was unsuccessful. In this case, the user will get an error message on NOW3. In all other cases, the application checks the payment transaction data. For this, the relation to the corresponding shopping cart in the database of the application is created via the parameter custom, which contains the Shopping BasketID.
  • the value of the mc_gross parameter is compared to the amount in the database.
  • the value of the parameter mc_currency is compared with the currency in the database.
  • the user can now download the PDF documents on NOW3.
  • the application Since an IPN occurs asynchronously, the application sets a status associated with the cart to In Progress in the event of a successfully completed payment transaction in the database. Cancel
  • NOW3 is displayed to the user with a corresponding error message.
  • the administration system is an administration web.
  • the administration web is part of the POP web application.
  • the user administration of the administration web is controlled by a simple configuration file, which is managed versioned via the configuration repository.
  • Each user is assigned a list of roles. These roles correspond to the rights to use the individual components (ie masks) of the administration web.
  • the illustrated system makes it possible to carry out a method for producing a label that can be applied to a mail item in various convenient ways.
  • the method is performed such that a network node (Maptos) provides a data service that is executed in at least one provider server of a service provider, generating data for insertion into the label.
  • Maptos network node
  • the data service is an Internet service.
  • the generation of the label is controlled in such a way that printing of the label is only enabled when a test step has been carried out.
  • the test step serves, for example, to check the validity of a voucher or to check whether a requested franking label has been paid.
  • a program module is introduced into the intelligent document that is designed for this purpose is to produce a presentable indication of a result of the checking step or another checking step for checking the existence of the prerequisite within the intelligent document.
  • One or more further testing steps may be performed in the provider server, the network node, or another server-based computing unit.
  • the checking step it is checked whether the program execution environment is available.
  • a program to control one-time printing of the label and for a smart document to be transmitted from a server to a client over a network.
  • the method is performed so that at a first pressure of the label, a message from the user client is transmitted to the server and that the pressure is logged due to the message in the server.
  • the program used to control label printing is designed to be executable only if there is a network connection between the client and the server, and if queried by the server it has been determined that the label has not yet been printed.
  • a refinement provides that in at least one of the checking steps, a query of the server is made, in which it is checked whether contents of the intelligent document have already been printed once.
  • the vouchers may be, for example, pre-paid postage amounts or credits for making order or delivery transactions.
  • the vouchers preferably contain valid information. In developments of the invention, they can also be used for payment transactions.
  • the recipients of the consignments can create labels as users of the system.
  • label as a return label for a return of mail to an original Senders - especially a mail order company.
  • a coupon is transmitted to a user on a first transmission path. Later, in particular if the user desires a return of a mail item or of a product contained in it, the coupon (code) is transmitted to a server by a control unit located in an area of influence of the user.
  • This development of the invention provides for a multi-step generation of a label.
  • This multi-step generation is distinguished by the fact that a coupon is transmitted to a user on a first transmission path, that the coupon is transmitted to a server by a control unit located in an area of influence of the user and that the server carries out a verification step for verifying the coupon and depending on the result of the test step affects the generation of the label.
  • the transmission of the voucher to the user can be done in various ways.
  • a development of the invention provides that the coupon or a part of the coupon is transmitted to different transmission paths to the user.
  • a transmission to the user takes place even if the coupon or a component is transmitted to an operating unit located in an area of influence of the user.
  • a development of the method, the computer program product and the device is characterized in that the coupon is attached to a mail addressed to the user.
  • An embodiment of the method, the computer program product and the device provides that the coupon is transmitted electronically to the user.
  • a further development of the method, the computer program product and the device is characterized in that the coupon is transmitted to the user when an event occurs.
  • An embodiment of the method, the computer program product and the device provides that the coupon is transmitted upon the occurrence of a shipping event.
  • a development of the method, the computer program product and the device is characterized in that the coupon is transmitted to a request.
  • An embodiment of the method, the computer program product and the device provides that the operating unit is a computer.
  • a development of the method, the computer program product and the device is characterized in that the Check step includes a validity check of the voucher.
  • An embodiment of the method, the computer program product and the device provides that the checking step includes a validity check of the voucher.
  • a development of the method, the computer program product and the device is characterized in that, taking into account the voucher, a recipient address for the mail item is determined.
  • An embodiment of the method, the computer program product and the device provides that, taking into account the voucher, a sender address for the mail item is determined.
  • the invention also includes documents that are not graphically representable. Documents within the meaning of the invention are in particular also smart labels. Smart labels are RFID identification means (transponders). These are suitable for use of control processes in the processing or transport of physical objects, in particular postal items or other goods to be transported.
  • identification data are preferably recognized by the fact that a signature is created for the respective dynamic content and that this signature is transmitted with the respective dynamic content.
  • the signature is expediently recreated in the destination of a respective communication (target system) and the Resulting value - in particular hash value - compared with the value resulting from the transmitted signature.
  • the invention also includes using other programs than those shown.
  • the documents are able to check which version or which implementation of a computer program and / or which operating system are installed on a client.
  • the labels prefferably contain customer and / or billing information.
  • the illustrated labels serve as information carriers and allow, for example, an acceptance, payroll, sorting, loading, special treatment, delivery, issue, billing, research, post-processing, operating data processing, tracking and tracing and archiving a shipment.
  • the intelligent documents - in particular the labels for application to the mailpieces - have information blocks in further developments of the invention. It is expedient to specify data types and / or data sizes for the information blocks. This determination is expediently made according to the respective logistical requirements.
  • Examples of dynamic content introduced into the static framework are the recipient address and indications that allow for shipment identification, for example, a shipment identification number.
  • the transmitted frame information serves for a clear, structured and formatted presentation of the dynamic contents.
  • FIG. 5 shows a graphical representation of intelligent documents produced according to the invention.
  • the graphic representations For example, they can be displayed on a screen of a client or printed out and optionally printed out for use as a shipping label for a mailing.
  • static content is transmitted separately from the dynamic content.
  • the static contents are, for example, the frames shown in the illustrations and company information such as "DHL".
  • Dynamic contents that are introduced into the mailings are, for example, sender information, recipient information, invoice number, size information, shipment identification number and / or possibly also a product name.
  • 5 shows the label content by way of example in a DIN A 4 landscape format, lying side by side.
  • the dynamic contents are transmitted in a continuation of the invention of a client of a shipping process (sender) in electronic form.
  • the electronic transmission of the shipment data may take place before, during and after a physical transfer of the shipments to a shipping company.
  • a suitable number range is preferably specified.
  • the label handling information for example, for employees of the shipping company, in particular a deliverer - included. It is possible and expedient to choose a format deviating from other label contents for the graphic reproduction of individual handling functions.
  • the invention is not limited to the illustrated types of transmission, formats or test steps.
  • the person skilled in the art recognizes that within the scope of the invention, other types of transmission can be selected and / or other formats used and / or other test steps can be carried out, the results of which are optionally displayed in the document.
  • the intelligent documents can, for example, be intelligent documents with animated graphics or forms.
  • the invention can be used with forms that are used in communication with authorities and executed as intelligent documents. On the basis of the test steps, the results of which are presented in the invention, it can be checked in particular whether certain mandatory fields of a form have been completed.
  • the invention can also be used in intelligent documents that are protected by the "intelligence" from unauthorized access.
  • texts should be mentioned that can only be displayed and / or printed if the user is authorized to do so, whereby the authorization of the user is checked by the intelligent document, for example by means of a server query taking place via a network.
  • Returns logistics processes are logistic processes for the handling of returns.
  • the invention includes both the development of a logistics system as returns logistics system and the design of a logistics system with handling operations for handling returns.
  • the invention includes a logistics system for conveying a mail item on a transport path within a postal distribution network, wherein the transport path contains a plurality of nodes of the postal distribution network, in particular a node that corresponds to a delivery point.
  • the transport path additionally contains one or more nodes, each corresponding to a sorting point.
  • logistics system is to be understood in the context of the invention in a broad meaning.
  • it comprises systems which contain the means and facilities for carrying out the transport of mailpieces from a point of departure to a delivery point on a transport path within a postal distribution network.
  • the point of departure is, for example, a storage location or place of delivery of the object to be transported.
  • the delivery point is preferably selected by the client of the transport. For a return, this is for example a warehouse of a dealer or manufacturer.
  • a coupon is transmitted to a user, that the coupon is transmitted by a control unit located in an area of influence of the user to a server and that the server performs a verification step to check the coupon and depending influenced by the result of the test step generating the label.
  • the transmission of the voucher is expediently carried out upon the occurrence of a mailing event, for example when the mail item addressed to the user is delivered, during a transport or processing step of the mail item or when the item of mail is delivered to the user.
  • the invention includes various ways of transmitting the voucher and allows for integration of different transmission paths.
  • the verification step is carried out so that it includes a validity check of the voucher.
  • a recipient address for the mail item is determined.
  • a sender address for the mail item is determined.
  • End user who uses the POP application to buy brands or coupons.
  • Rectangular static surface in a web page which can be displayed in time and marketplace.
  • Remuneration insurance (means for determining abusive label.
  • An instance of a coupon type can be identified by a unique coupon code.
  • a class of a coupon A class of a coupon.
  • Term is not used because ambiguous.
  • Each user session is assigned to a marketplace that specifies some framework conditions such as the currency.
  • a combination of base product and services is identified by a product key.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zum Erzeugen eines auf eine Postsendung aufbringbaren Labels. Dieses Verfahren zeichnet sich dadurch aus, dass ein Netzwerkknoten (Maptos) einen Datendienst bereitstellt, der in einem Anbieterserver eines Dienstanbieters ausgeführt wird, wobei Daten zum Einbringen in das Label erzeugt werden. Die Erfindung betrifft ferner ein Computerprogrammprodukt, einen Netzwerkknoten und ein System zum Erzeugen eines auf eine Postsendung aufbringbaren Labels.

Description

    Technisches Gebiet
  • Die Erfindung betrifft ein Verfahren zum Erzeugen eines auf eine Postsendung aufbringbaren Labels.
  • Die Erfindung betrifft ferner ein Computerprogrammprodukt, einen Netzwerkknoten und eine Vorrichtung zur Durchführung des Verfahrens.
    • Hintergrund und Stand der Technik
  • Es ist bekannt, Postsendungen mit Labeln zu versehen. Derartige Label werden beispielsweise durch eine geeignete Datenverarbeitungseinheit - zum Beispiel einen Personalcomputer - erzeugt.
    • Darstellung der Erfindung
  • Es ist wünschenswert, in das Label möglichst automatisch für einen Versand der Postsendung relevante Informationen einzubringen.
  • Daher ist es eine Aufgabe der vorliegenden Erfindung, ein Verfahren zum Erzeugen eines auf eine Postsendung aufbringbaren Labels so durchzuführen beziehungsweise ein System zum Erzeugen eines auf eine Postsendung aufbringbaren Labels so auszugestalten, dass ein hoher Bedienkomfort für einen Benutzer mit einem hohen Schutz vor Manipulationen verbunden wird.
  • Erfindungsgemäß wird diese Aufgabe durch ein Verfahren mit den Merkmalen des Patentanspruchs 1, ein Computerprogrammprodukt nach Anspruch 14, einen Netzwerkknoten nach Anspruch 15 sowie durch ein System nach Anspruch 16 gelöst.
  • Somit wird ein Verfahren zum Erzeugen eines Labels so durchgeführt, dass ein Netzwerkknoten einen Datendienst bereitstellt, der in wenigstens einem Anbieterserver eines Dienstanbieters ausgeführt wird, wobei Daten zum Einbringen in das Label erzeugt werden.
  • Eine Weiterbildung des Verfahrens, des Computerprogrammprodukts, des Netzwerkknotens und des Systems zeichnet sich dadurch aus, dass der Datendienst ein Internetdienst ist.
  • Es ist insbesondere zweckmäßig, das Verfahren, das Computerprogrammprodukt, den Netzwerkknoten und/oder das System für eine Erstellung von Rücksendelabeln einzusetzen.
  • Rücksendelabel sind Label, die es einem Benutzer des Computersystems ermöglichen, von ihm erhaltene Postsendungen an einen Absender zurückzusenden.
  • Eine Fortentwicklung des Verfahrens, des Computerprogrammprodukts, des Netzwerkknotens und des Systems zeichnet sich dadurch aus, dass ein Prüfungsschritt zur Überprüfung eines Gutscheins durchführt und in Abhängigkeit von dem Ergebnis des Prüfungsschritts das Erzeugen des Labels beeinflusst wird.
  • Eine Weiterbildung des Verfahrens, des Computerprogrammprodukts, des Netzwerkknotens und des Systems zeichnet sich dadurch aus, dass in einem dem Prüfungsschritt vorangehenden Verfahrensschritt der Gutschein an einen Benutzer übermittelt wird.
  • Eine Fortentwicklung des Verfahrens, des Computerprogrammprodukts, des Netzwerkknotens und des Systems zeichnet sich dadurch aus, dass ein Programmmodul in das intelligente Dokument eingebracht wird, das dazu ausgebildet ist, eine darstellbare Angabe eines Ergebnisses des Prüfungsschrittes oder eines weiteren Prüfungsschritts zur Prüfung des Vorliegens der Voraussetzung innerhalb des intelligenten Dokuments zu erzeugen.
  • Eine Weiterbildung des Verfahrens, des Computerprogrammprodukts, des Netzwerkknotens und des Systems zeichnet sich dadurch aus, dass wenigstens einer der Prüfungsschritte mittels des Programmmoduls durchgeführt wird.
  • Eine Fortentwicklung des Verfahrens, des Computerprogrammprodukts, des Netzwerkknotens und des Systems zeichnet sich dadurch aus, dass in dem Prüfungsschritt überprüft wird, ob die Programmausführungsumgebung zur Verfügung steht.
  • Eine Weiterbildung des Verfahrens, des Computerprogrammprodukts, des Netzwerkknotens und des Systems zeichnet sich dadurch aus, dass ein Programm einen einmaligen Druck des Labels steuert und dass ein intelligentes Dokument von einem Server über ein Netzwerk an einen Client übermittelt wird.
  • Eine Fortentwicklung des Verfahrens, des Computerprogrammprodukts, des Netzwerkknotens und des Systems zeichnet sich dadurch aus, dass bei einem ersten Druck des Labels eine Nachricht von dem Nutzerclient an den Server übermittelt wird und dass der Druck aufgrund der Nachricht in dem Server protokolliert wird.
  • Eine Weiterbildung des Verfahrens, des Computerprogrammprodukts, des Netzwerkknotens und des Systems zeichnet sich dadurch aus, dass das Programm zur Steuerung des Drucks des Labels nur dann ausführbar ist, wenn eine Netzwerkverbindung zwischen dem Client und dem Server besteht und wenn anhand einer Abfrage des Servers festgestellt worden ist, dass das Label noch nicht gedruckt worden ist.
  • Eine Fortentwicklung des Verfahrens, des Computerprogrammprodukts, des Netzwerkknotens und des Systems zeichnet sich dadurch aus, dass in wenigstens einem der Prüfungsschritte überprüft wird, ob ein Zugriff auf das Netzwerk besteht.
  • Eine Weiterbildung des Verfahrens, des Computerprogrammprodukts, des Netzwerkknotens und des Systems zeichnet sich dadurch aus, dass in wenigstens einem der Prüfungsschritte eine Abfrage des Servers vorgenommen wird, bei der überprüft wird, ob Inhalte des intelligenten Dokuments bereits einmal gedruckt worden sind.
  • Eine Weiterbildung der Erfindung beinhaltet ein System, das Kunden ermöglicht, Label mittels eines PC, der im Folgenden als Nutzerclient bezeichnet wird, über eine Online-Schnittstelle anzufordern und zu drucken. Die Schnittstelle wird von einem Server bereitgestellt, der im Folgenden als POP-Server (POP: Parcel Online Postage) bezeichnet wird.
  • Zur Erzeugung der Label generiert der Kunde zunächst einen oder mehrere Einträge für zu versendende Postsendungen in einem Warenkorb auf einer ersten von dem POP-Server bereitgestellten Webseite (nachfolgend NOW 1 genannt). Hierzu enthält die Webseite NOW 1 einen Button, über den der Nutzer auf eine weitere Internetseite ( nachfolgend NOW2 genannt, die Sendungs-Details darstellt) zugreifen kann, auf der Daten einer Sendung erfasst und manipuliert werden können.
  • Die Daten umfassen beispielsweise die Absenderadresse, die Empfängeradresse und eine Auswahl der Produkte und Services sowie der Zielländer, aus der sich insbesondere auch der Portowert für die Sendung ergibt. Ferner kann der Nutzer einen oder mehrere Zusatzservices für die Sendungen angeben. Hierunter fallen zum Beispiel ein Rollenservice für runde Verpackungen oder ein spezifischer Sperrgutservice, wobei diese Ausprägungen nur beispielhaft für weitere Zusatzservices stehen.
  • Wenn der Warenkorb wenigstens einen Eintrag enthält, ist auf der Webseite NOW 1 ein weiterer Button aktiv, über den der Kunde einen Bezahlvorgang einleiten kann. Dieser erfolgt anhand eines Online-Zahlungsverfahrens, wobei der Kunde insbesondere zwischen verschiedenen Online-Überweisungsformen wählen kann, worunter zum Beispiel der Bezahldienst PayPal oder eine Kreditkartenzahlung subsumiert werden kann, wobei diese Zahlverfahren nur beispielhaft erwähnt sind.
  • Nach erfolgter Bezahlung des Warenkorbs gelangt der Kunde auf eine Webseite (nachfolgend NOW 3 genannt), die Links zu PDF-Dokumenten enthält, welche den Druck der erworbenen Frankierlabel ermöglichen. Ferner wird nach der Bezahlung eine E-Mail an Kunden gesendet, die einen Link auf die Webseite NOW 3 enthält, über den die Webseite auch zu einem späteren Zeitpunkt wieder aufgerufen werden kann. Die E-Mail wird an eine Adresse gesendet, die der Kunde zuvor auf der Webseite NOW 1 eingegeben hat. Überschreitet der Wert des Warenkorbs einen bestimmten Betrag, so wird der Zugriff auf die Webseite NOW 3 über den in der E-Mail enthaltenen Link durch eine PIN abgesichert, der dem Nutzer auf der Seite NOW 3 dargeboten, aber nicht per E-Mail übermittelt wird.
  • Eine Weiterbildung der Erfindung beinhaltet eine Gutscheinfunktionalität, die es einem Kunden ermöglicht, Gutscheine zu erwerben und für die Bezahlung von Frankiervermerken einzusetzen. Die Gutscheine können dem Warenkorb auf der Webseite NOW 1 hinzugefügt werden. Über einen entsprechenden Button auf dieser Webseite gelangt der Nutzer auf eine weitere Webseite (NOW 2 - Gutschein-Details), auf der dem Warenkorb Gutschein-Sets für ein ebenfalls auf dieser Seite ausgewähltes Basisprodukt hinzugefügt werden können. Nach der Bezahlung des Warenkorbs wird dem Benutzer auf der Webseite NOW 3 eine Möglichkeit geboten, die erworbenen Gutscheincodes anzuzeigen oder zu speichern. Zur späteren Einlösung des Gutscheins wird der Gutscheincode von dem Kunden bei der Generierung des Warenkorbs auf der Webseite NOW 1 eingegeben.
  • Die Erfindung eignet sich für eine Erstellung unterschiedlicher Label, insbesondere zur Erzeugung von Labeln zur Steuerung von logistischen Funktionen der Postsendungen, insbesondere ihrer Beförderung, Sortierung und/oder Weiterleitung. Die Label enthalten hierfür beispielsweise geldwerte Informationen als Zahlungsnachweis, so dass es sich beispielhaft um Frankierlabel handelt.
  • Es ist jedoch gleichfalls möglich, dass die Label weitere Informationen zur Handhabung der Postsendungen - beispielsweise eine Absenderadresse, eine Empfängeradresse, einen Sendungsidentifikationscode oder weitere die Sendung beschreibende Daten (z.B. Gewicht oder Abmaße) - beinhalten. Hierdurch ist ein Einsatz der Label zu einer Überwachung des Sendungsverlaufs (Tracking) beziehungsweise zu einem Nachweis des Sendungsverlaufs (Tracing) möglich.
  • In einer bevorzugten Ausgestaltung enthalten die Label neben der Anschrift des Empfängers und des Absenders einen der Empfängeradresse zugeordneten Leitcode, der bei der Produktion der Postsendungen in einem Paket- bzw. Briefzentrum eines Versanddienstleisters genutzt wird.
  • In einer besonders bevorzugten Ausführungsform beinhaltet das Label einen eindeutigen Labelidentifikationscode. Anhand des Labelidentifikationscodes können Missbrauchsfälle ermittelt werden, bei denen ein Frankierlabel mehrfach für die Frankierung von Postsendungen verwendet wird. Hierzu werden die Labelidentifikationscodes der ausgegebenen Frankierlabel in einem Entgeltsicherungssystem gespeichert. Bei der Produktion einer Sendung wird der Labelidentifikationscode in dem Entgeltsicherungssystem als verwendet markiert. Ferner wird für jede produzierte Sendung überprüft, ob der Labelidentifikationscode als ungültig markiert ist. Ist dies der Fall, wird ein Missbrauchsfall festgestellt. Leitcode und Labelidentifikationscode werden sowohl in Klarschrift als auch in Form eines Barcodes in das Label eingebracht. Die Frankierlabel werden dem Kunden anhand von intelligenten PDF-Dokumenten bereitgestellt.
  • Die Erfindung beinhaltet verschiedene Ausführungsformen zur Erzeugung des Labels und zu seinem Ausdruck. Besonders bevorzugte Ausführungsformen sind nachfolgend genannt:
  • Nach der Bezahlung des Warenkorbs durch den Kunden erhält der POP-Server eine Benachrichtigung über die erfolgte Zahlungstransaktion von dem Zahlungsprovider. Daraufhin wird in einer Dokumentendatenbank ein Datensatz für das von dem Kunden erworbene Frankierlabel erzeugt. Der Datensatz enthält insbesondere einen eindeutigen Dokumentenidentifikationscode für das intelligente PDF-Dokument, eine Angabe darüber, ob das Label bereits mit gültigen Codes gedruckt worden ist, sowie Formulardaten. Die Formulardaten umfassen die Absender- und Empfängeradresse der zu frankierenden Postsendungen, den Leitcode. Zudem beinhalten die Formulardaten den Labelidentifikationscode, der nach der Bezahlung aus einem Pool mit zuvor generierten Codes entnommen wird. Dieser Code wird zudem auch an das Entgeltsicherungssystem übertragen. Ferner wird ein intelligentes PDF-Dokument erzeugt, bei dem es sich um ein leeres Formular mit Formularfeldern für die zuvor genannten Formulardaten handelt. Als Bezeichnung des PDF-Dokuments dient der Dokumentenidentifikationscode.
  • Der Druck des Labels erfolgt im Rahmen des iPDF-Mechanismus anhand einer Kommunikation zwischen dem Nutzerclient und dem POP-Server bzw. einem mit dem POP-Server verbundenen Lizenzserver, der auf die Dokumentendatenbank zugreifen kann. Für die Kommunikation zwischen dem Nutzerclient wird die SOAP-Schnittstelle des Acrobat Readers genutzt. Nach dem Öffnen des PDF-Dokuments wird zunächst sukzessive geprüft, ob eine Internetverbindung vorhanden ist, ob der Dokumentenidentifikationscode gültig ist und ob das Label nicht bereits gedruckt worden ist. Zur Durchführung der letzten beiden Prüfungsschritte wird über die SOAP-Schnittstelle des Acrobat Readers ein Service des POP-Servers aufgerufen, der nach einer entsprechenden Abfrage der Datenbank zurückmeldet, ob ein Datensatz für den Dokumentenidentifikationscode in der Dokumentendatenbank vorhanden ist, und ob der Frankiervermerk bereits als gedruckt markiert worden ist.
  • Nach erfolgreicher Durchführung der Prüfungsschritte werden die in der Datenbank gespeicherten Formulardaten mit Ausnahme der gültigen Codes über die Schnittstelle des Acrobat Readers vom POP-Server geladen und in die Formularfelder des PDF-Dokuments eingebracht. Anstelle der gültigen Codes enthält das PDF-Dokument zunächst nur Dummy-Codes, um zu verhindern, dass der Nutzer eine Kopie eines gültigen Labels anfertigen kann. Ferner ist der Inhalt des Dokuments zunächst deutlich als Muster markiert. Für den Druck stellt das PDF-Dokument eine eigene Funktionalität bereit, bei der Testdrucke sowie ein Druck eines gültigen Labels - nachfolgend Portodruck genannt - über entsprechende Schaltflächen innerhalb des Dokuments durchgeführt werden können. Bei einem Testdruck wird das zunächst in dem PDF-Dokument enthaltene Muster des Labels mit den Dummy-Codes gedruckt. Bei einem Portodruck wird das gültige Label gedruckt, wobei die gültigen Barcodes nach einer Betätigung der entsprechenden Schaltfläche von dem POP-Server abgerufen werden. Ferner wird aufgrund der Betätigung der Schaltfläche für den Portodruck in der Dokumentendatenbank des POP-Servers eingetragen, dass ein Druck des gültigen Labels erfolgt ist und die Schaltfläche wird ausgeblendet bzw. funktionslos geschaltet.
  • Bei einem erneuten Öffnen des Dokuments nach einem Portodruck wird anhand der zunächst durchgeführten Prüfungsschritte festgestellt, dass das Label bereits einmal ausgedruckt worden ist. Zumindest ein Portodruck wird in diesem Fall nicht mehr gestattet.
  • Das Label kann unterschiedliche Gestalt aufweisen. Es ist vorzugsweise so gestaltet, dass es eine Identifikation und/oder Steuerung von Postsendungen und gegebenenfalls auch die Koordination eines Lagerplatzes ermöglicht.
  • Zweckmäßigerweise sind die Label kratz- und schlagfest sowie temperaturbeständig.
  • Beispiele derartiger Label sind:
    • Barcode-Label,
    • EAS-Etiketten,
    • Etiketten für Warenverfolgung,
    • intelligente Etiketten,
    • Inventuretiketten,
    • Palettenetiketten,
    • Sicherheitsetiketten,
    • Thermoetiketten,
    • Thermotransferetiketten,
    • Transponderetiketten.
  • In die Label werden codierte Informationen als Steuerungsinstrumente für die Paketlogistik eingebracht.
  • Insbesondere können die Label eine fortlaufende Nummerierung - gegebenenfalls mit Prüfziffer -, sonstige Nummerierungen sowie Adressangaben oder sonstige Informationen, die die Sendung klassifizieren oder beispielsweise zu Werbezwecken dienen, enthalten.
  • Besonders umfassende Datenmengen können in Smart-Label eingebracht werden.
  • RFID-Identifikationssysteme - "Smart-Label" - ermöglichen eine Optimierung der logistischen Vorgänge.
  • Sie sind damit ein geeignetes Mittel zur Beeinflussung - einschließlich Steuerung flexibler Distributionssysteme für die wegeoptimierte Bereitstellung der Postsendungen.
  • Eine Übermittlung des Labels an die Bedieneinheit erfolgt vorzugsweise in Form eines intelligenten Dokuments.
  • In einer Weiterbildung der Erfindung wird ein intelligentes Dokument eingesetzt, das ein Programm umfasst, das bei Vorliegen einer Voraussetzung mittels einer Programmausführungsumgebung ausführbar ist und das mittels eines Darstellungsprogramms darstellbare Inhalte enthält. Das intelligente Dokument zeichnet sich dadurch aus, dass ein Programm-Modul enthalten ist, das dazu ausgebildet ist, eine darstellbare Angabe eines Ergebnisses des Prüfungsschritts zur Prüfung des Vorliegens der Voraussetzung innerhalb des intelligenten Dokuments zu erzeugen.
  • Eine weitere Ausgestaltung des Verfahrens, des intelligenten Dokuments und der Vorrichtung beinhaltet, dass die Programmausführungsumgebung Bestandteil des Darstellungsprogramms ist.
  • Nach dem Erwerb eines Artikels durch einen Käufer - beispielsweise durch das Ende einer Auktion oder den Erwerb zu einem Festpreis bei z.B. einem Versandhändler - beginnt für den Verkäufer der Prozess der Versandabwicklung, der durch die vorliegende Erfindung optimiert wird. Alternativ kann auch unabhängig von einem oben beschriebenen Geschäftsvorfall ein Label erzeugt werden, das z.B. privaten Versandzwecken dient oder das Ziel hat ein Frankiervermerk mit dem Ziel zu erzeugen, dieses für den Rückversand eines oder mehrerer Artikel an einen Versender zu nutzen.
  • Vorzugsweise werden die versand- und/oder frankierrelevanten Daten vom Versandinformationssystem bzw. der Listingtools automatisiert - d.h. ohne weiteres Zutun des Verkäufers - über eine Schnittstelle an ein Mittel zur Erstellung eines Labels (Labelerstelldienst) übergeben.
  • Ein Einsatz der Erfindung in Systemen zum Erzeugen von Labeln oder anderen Aufdrucken zum Versehen von Postsendungen oder anderen zu transportierenden Gütern ist besonders vorteilhaft.
  • Ein Label ist vorzugsweise eine grafische Darstellung - beispielsweise ein Ausdruck oder eine Bildschirmdarstellung eines intelligenten Dokuments.
  • Eine Weiterbildung der Erfindung beinhaltet ein Verfahren zum Erzeugen eines intelligenten Dokuments, das ein Programm umfasst, das bei Vorliegen einer Voraussetzung mittels einer Programmausführungsumgebung ausführbar ist und das mittels eines Darstellungsprogramms darstellbare Inhalte enthält.
  • Eine bevorzugte Ausführungsform der Erfindung zeichnet sich dadurch aus, dass die darstellbaren Inhalte aus statischen Inhalten und dynamischen Inhalten bestehen, wobei ein Einbringen der dynamischen Inhalte in das intelligente Dokument von einem Einbringen der statischen Inhalte getrennt erfolgt.
  • In diesem Fall ist es besonders vorteilhaft, dass Adressdaten und/oder frankierrelevante Daten Beispiele dynamischer Inhalte im Sinne bevorzugter Weiterbildungen der Erfindung sind.
  • Eine Weiterbildung der Erfindung eignet sich jedoch auch für einen Einsatz anderer dynamischer Informationen und in anderen technischen Zusammenhängen, beispielsweise für eine Automatisierung von sonstigen Logistikvorgängen, von Produktionsvorgängen sowie von der Erzeugung und Verarbeitung von Informationen. Besonders vorteilhaft sind Einsatzgebiete, bei denen dynamische Informationen in einem statischen Rahmen wiedergegeben und/oder bearbeitet werden.
  • Bei den statischen Informationen handelt es sich um Angaben, die insbesondere ein Einbetten von Daten ermöglichen.
  • Bei den Rahmen kann es sich beispielsweise auch um so genannte Frames handeln.
  • Ein Frame ist ein Teilbereich einer graphischen Darstellung, insbesondere einer Bildschirmseite, beispielsweise einer grafischen Benutzeroberfläche. Ein einzelnes Segment wird dabei als Frame (englischer Ausdruck für Rahmen) bezeichnet, die Definition aller Frames als Frameset.
  • Der Einsatz von Frames ermöglicht die parallele Darstellung von mehreren Einzeldokumenten, die sich gegebenenfalls unabhängig voneinander verschieben lassen. Über die Frames lassen sich Inhalte aus unterschiedlichen Quellen bzw. aus verschiedenen Datenquellen miteinander kombinieren.
  • Ferner können Inlineframes (iframes) eingesetzt werden. Sie erlauben eine besonders einfache Dateneinbindung in eine dargestellte Bildschirmseite.
  • Demgemäß wird ein Verfahren der eingangs genannten Art geschaffen, bei dem das intelligente Dokument ein Programm umfasst, das bei Vorliegen einer Voraussetzung mittels einer Programmausführungsumgebung ausführbar ist und das mittels eines Darstellungsprogramms darstellbare Inhalte enthält.
  • Erfindungsgemäß wird das Verfahren so durchgeführt, dass zwei verschiedene Arten von Inhalten in das intelligente Dokument eingebracht werden, die aus einer oder mehreren Quellen stammen können.
  • Bei einer ersten Art von Inhalten handelt es sich um statische Inhalte. Statische Inhalte stimmen vorzugsweise bei mehreren Dokumenten überein.
  • Bei den statischen Inhalten handelt es sich vorzugsweise um solche Inhalte, die sich für eine Erzeugung mehrerer Dokumente eignen. Eine Erzeugung mehrerer Dokumente ist sehr vorteilhaft, jedoch nicht notwendig.
  • Bei den statischen Inhalten handelt es sich beispielsweise um Rahmeninformationen für die Erzeugung von Dokumenten oder um andere Informationen, deren Aktualisierung seltener als bei den dynamischen Inhalten, vorzugsweise erst bei Ablauf eines vorgebbaren Zeitintervalls oder bei Erreichen eines Ereignisses, erfolgt. Alternativ ist es möglich, die statischen Daten vollständig unverändert zu lassen.
  • Ferner wird ein intelligentes Dokument geschaffen, das ein Programm umfasst, das bei Vorliegen einer Voraussetzung mittels einer Programmausführungsumgebung ausführbar ist, und das mittels eines Darstellungsprogramms darstellbare Inhalte enthält. Das intelligente Dokument zeichnet sich dadurch aus, dass ein Programmmodul enthalten ist, das dazu ausgebildet ist, eine darstellbare Angabe eines Ergebnisses des Prüfungsschritts zur Prüfung des Vorliegens der Voraussetzung innerhalb des intelligenten Dokuments zu erzeugen.
  • Eine Ausführungsform der Erfindung sieht vor, dass das Programmmodul ein Bestandteil der statischen Inhalte ist.
  • Eine Weiterbildung der Erfindung zeichnet sich dadurch aus, dass das Programmmodul ein Bestandteil der dynamischen Inhalte ist.
  • Eine besonders bevorzugte Ausführungsform der Erfindung sieht vor, dass das Programmmodul entweder Bestandteil der dynamischen Inhalte oder der statischen Inhalte ist.
  • Zudem wird eine Vorrichtung zum Erzeugen eines intelligenten Dokuments geschaffen, das ein Programm umfasst, das bei Vorliegen einer Voraussetzung mittels einer Programmausführungsumgebung ausführbar ist, und das mittels eines Darstellungsprogramms darstellbare Inhalte enthält. Die Vorrichtung ist dazu eingerichtet, ein Programmmodul in das intelligente Dokument einzubringen, das dazu ausgebildet ist, eine darstellbare Angabe eines Ergebnisses des Prüfungsschritts zur Prüfung des Vorliegens der Voraussetzung innerhalb des intelligenten Dokuments zu erzeugen.
  • Eine Weiterbildung des Verfahrens, des intelligenten Dokuments, des Computerprogrammprodukts und der Vorrichtung sieht vor, dass in dem intelligenten Dokument selbst ein Programmmodul enthalten ist, mit dem eine Angabe des Ergebnisses eines Prüfungsschritts erzeugt werden kann. Hierdurch ist das intelligente Dokument selbst zur Angabe des Ergebnisses eines Prüfungsschritts in der Lage, so dass das Ergebnis des Prüfungsschritts unabhängig von der Konfiguration des Darstellungsprogramms angezeigt wird.
  • Unter einer darstellbaren Angabe innerhalb eines intelligenten Dokuments wird im Rahmen der Erfindung eine Angabe verstanden, die mittels des Darstellungsprogramms beispielsweise an einem Bildschirm angezeigt werden kann. Intelligente Dokumente können neben den darstellbaren Inhalten weitere Inhalte, wie beispielsweise Programmcodes enthalten, die zumindest in einem normalen Darstellungsmodus nicht mittels eines Darstellungsprogramms angezeigt werden.
  • Das erfindungsgemäße Verfahren zum Erzeugen eines intelligenten Dokuments, das ein Programm umfasst, das bei Vorliegen einer Voraussetzung mittels einer Programmausführungsumgebung ausführbar ist, das mittels eines Darstellungsprogramms darstellbare Inhalte enthält, kann auf verschiedene Weise fortgebildet werden.
  • Eine Weiterbildung des Verfahrens, des intelligenten Dokuments und der Vorrichtung sieht vor, dass die statischen Inhalte von einem Server über ein Netzwerk an einen Client übermittelt werden.
  • Eine Ausgestaltung des Verfahrens, des intelligenten Dokuments und der Vorrichtung sieht vor, dass die dynamischen Inhalte von einem Server über ein Netzwerk an den Client übermittelt werden.
  • Hierdurch ist eine besonders rasche Dokumentenerzeugung möglich.
  • Eine unabhängig von einer Übermittlung oder Nichtübermittlung der statischen Inhalte erfolgende Übermittlung der dynamischen Inhalte hat den Vorteil, dass der Datenübertragungsaufwand für die Erzeugung eines intelligenten Dokuments verringert wird.
  • Dieser Vorteil ist noch ausgeprägter, falls mehrere intelligente Dokumente erzeugt werden.
  • Bei einer Erzeugung mehrerer intelligenter Dokumente ist es vorteilhaft, einmal die statischen Inhalte zu übertragen und diese mit verschiedenen dynamischen Inhalten zu verschiedenen intelligenten Dokumenten zu kombinieren.
  • So ist es möglich, mit einmal erzeugten statischen Inhalten mehrere voneinander verschiedene intelligente Dokumente zu erzeugen.
  • Eine Weiterbildung des Verfahrens, des intelligenten Dokuments, des Computerprogrammprodukts und der Vorrichtung sieht vor, dass die statischen Inhalte und die dynamischen Inhalte getrennt voneinander übertragen werden.
  • Eine Weiterbildung des Verfahrens, des intelligenten Dokuments, des Computerprogrammprodukts und der Vorrichtung sieht vor, dass die Übertragung zeitlich getrennt erfolgt.
  • Eine Ausgestaltung des Verfahrens, des intelligenten Dokuments, des Computerprogrammprodukts und der Vorrichtung zeichnet sich dadurch aus, dass die Übertragung auf verschiedenen Übertragungswegen erfolgt.
  • Eine Weiterbildung des Verfahrens, des intelligenten Dokuments, des Computerprogrammprodukts und der Vorrichtung sieht vor, dass die statischen Inhalte von einer anderen Datenquelle bereitgestellt werden als die dynamischen Inhalte.
  • Eine Ausgestaltung des Verfahrens, des intelligenten Dokuments, des Computerprogrammprodukts und der Vorrichtung zeichnet sich dadurch aus, dass die statischen Inhalte von einem ersten Server und dass die dynamischen Inhalte von einem anderen Server übertragen werden.
  • Eine Weiterbildung des Verfahrens, des intelligenten Dokuments, des Computerprogrammprodukts und der Vorrichtung sieht vor, dass die statischen Daten in einem Bereich eines Clients gespeichert werden.
  • Dies hat den Vorteil, dass die statischen Daten auf eine besonders einfache und vorteilhafte Weise für eine Erzeugung mehrerer - vorzugsweise verschiedener - intelligenter Dokumente bereitstehen.
  • Eine Nutzung der Dokumente erfolgt insbesondere durch einen Client. Der Client steht vorteilhafterweise einem Benutzer des Systems zur Verfügung und wird deshalb in der vorliegenden Anmeldung auch als Nutzerclient bezeichnet.
  • Der Client ist vorzugsweise so ausgestattet, dass er erkennt, ob er sich bei dem übermittelten Dokument um ein intelligentes Dokument handelt. Dies geschieht bei einer Weiterbildung der Erfindung dadurch, dass ein Vorhandensein einer Bestätigungsinformation überprüft wird. Bei der Bestätigungsinformation handelt es sich beispielsweise um eine Signatur.
  • Eine Ausführungsform des Verfahrens, des intelligenten Dokument, des Computerprogrammprodukts und der Vorrichtung sieht vor, dass der Client bei dem Öffnen eines Dokuments prüft, ob es signiert wurde.
  • In einer Weiterbildung der Erfindung wird - vorzugsweise durch einen weiteren Prüfungsschritt - überprüft, ob die Signatur, mit der das Dokument signiert wurde, gültig ist.
  • Die statischen Inhalte werden vorzugsweise getrennt von den dynamischen Inhalten übertragen. Die statischen Inhalte sind beispielsweise Layoutinformationen zur Gestaltung des Dokuments.
  • Weiterbildungen der Erfindung sehen vor, die statischen Inhalte teilweise, überwiegend oder vollständig anders zu bearbeiten als die dynamischen Inhalte.
  • Beispielsweise unterscheiden sich die statischen Inhalte von den dynamischen Inhalten durch den Zeitpunkt der jeweiligen Erzeugung.
  • Ferner können sich die statischen Inhalte und die dynamischen Inhalte auch durch das sie jeweils auslösende Ereignis voneinander unterscheiden.
  • Eine Weiterbildung des Verfahrens, des intelligenten Dokuments, des Computerprogrammprodukts und der Vorrichtung sieht vor, dass die statischen Inhalte bei Vorliegen eines ersten Ereignisses übermittelt werden.
  • Eine Ausgestaltung des Verfahrens, des intelligenten Dokuments, des Computerprogrammprodukts und der Vorrichtung zeichnet sich dadurch aus, dass die statischen Informationen bei Vorliegen eines Ereignisses einer ersten Ereignisart übermittelt werden.
  • Eine Weiterbildung des Verfahrens, des intelligenten Dokuments, des Computerprogrammprodukts und der Vorrichtung sieht vor, dass die dynamischen Inhalte bei Vorliegen eines zweiten Ereignisses übermittelt werden.
  • Eine Ausgestaltung des Verfahrens, des intelligenten Dokuments, des Computerprogrammprodukts und der Vorrichtung zeichnet sich dadurch aus, dass die dynamischen Informationen bei Vorliegen eines Ereignisses einer zweiten Ereignisart übermittelt werden.
  • Eine Weiterbildung des Verfahrens, des intelligenten Dokuments, des Computerprogrammprodukts und der Vorrichtung sieht vor, dass ein Vorliegen des zweiten Ereignisses unter Berücksichtigung eines Prüfungsschritts ermittelt wird.
  • Eine Ausgestaltung des Verfahrens, des intelligenten Dokuments, des Computerprogrammprodukts und der Vorrichtung zeichnet sich dadurch aus, dass sich das erste Ereignis von dem zweiten Ereignis unterscheidet.
  • Eine Weiterbildung des Verfahrens, des intelligenten Dokuments, des Computerprogrammprodukts und der Vorrichtung sieht vor, dass sich die erste Ereignisart von der zweiten Ereignisart unterscheidet.
  • Ferner wird ein intelligentes Dokument geschaffen, das ein Programm umfasst, das bei Vorliegen einer Voraussetzung mittels einer Programmausführungsumgebung ausführbar ist, und das mittels eines Darstellungsprogramms darstellbare Inhalte enthält. Das intelligente Dokument zeichnet sich dadurch aus, dass ein Programmmodul enthalten ist, das dazu ausgebildet ist, eine darstellbare Angabe eines Ergebnisses des Prüfungsschritts zur Prüfung des Vorliegens der Voraussetzung innerhalb des intelligenten Dokuments zu erzeugen.
  • Zudem wird eine Vorrichtung zum Erzeugen eines intelligenten Dokuments geschaffen, das ein Programm umfasst, das bei Vorliegen einer Voraussetzung mittels einer Programmausführungsumgebung ausführbar ist, und das mittels eines Darstellungsprogramms darstellbare Inhalte enthält. Die Vorrichtung ist dazu eingerichtet, ein Programmmodul in das intelligente Dokument einzubringen, das dazu ausgebildet ist, eine darstellbare Angabe eines Ergebnisses des Prüfungsschritts zur Prüfung des Vorliegens der Voraussetzung innerhalb des intelligenten Dokuments zu erzeugen.
  • Eine Weiterentwicklung der Erfindung der Erfindung besteht darin, dass in dem intelligenten Dokument selbst ein Programmmodul enthalten ist, mit dem eine Angabe des Ergebnisses eines Prüfungsschritts erzeugt werden kann. Hierdurch ist das intelligente Dokument selbst zur Angabe des Ergebnisses eines Prüfungsschritts in der Lage, so dass das Ergebnis des Prüfungsschritts unabhängig von der Konfiguration des Darstellungsprogramms angezeigt wird.
  • Unter einer darstellbaren Angabe innerhalb eines intelligenten Dokuments wird im Rahmen der Erfindung eine Angabe verstanden, die mittels des Darstellungsprogramms beispielsweise an einem Bildschirm angezeigt werden kann. Intelligente Dokumente können neben den darstellbaren Inhalten weitere Inhalte, wie beispielsweise Programmcode enthalten, die zumindest in einem normalen Darstellungsmodus nicht mittels Darstellungsprogramms angezeigt werden.
  • Innerhalb der Prüfungsschritte wird vorteilhaft überprüft werden, ob bestimmte Voraussetzungen für die Nutzung der Funktionalität des intelligenten Dokuments vorliegen. Sind diese Voraussetzungen erfüllt, wird ein positives Ergebnis des Prüfungsschritts angezeigt. Falls die Voraussetzungen nicht erfüllt sind, wird ein negatives Prüfungsergebnis angezeigt, so dass der Nutzer Kenntnis darüber erhält, welche Voraussetzung nicht erfüllt ist. Diese Kenntnis kann er dazu nutzen, die entsprechende Voraussetzung zu schaffen.
  • In einer Ausführungsform des Verfahrens, des intelligenten Dokuments und der Vorrichtung ist es vorgesehen, dass der Prüfungsschritt mittels des Programmmoduls durchgeführt wird.
  • Vorteilhaft ist das Programmmodul in dieser Ausgestaltung auch zur Durchführung des Prüfungsschritts ausgebildet, so dass sich das intelligente Dokument unabhängig von der speziellen Konfiguration des Darstellungsprogramms selbst prüfen kann.
  • Eine Weiterbildung des Verfahrens, des intelligenten Dokuments und der Vorrichtung zeichnet sich dadurch aus, dass in dem Prüfungsschritt überprüft wird, ob die Programmausführungsumgebung zur Verfügung steht.
  • Diese Weiterbildung hat den Vorteil, dass geprüft wird, ob die Programmausführungsumgebung zur Verfügung steht, so dass der Nutzer gegebenenfalls darüber informiert werden kann, dass die Programmausführungsumgebung nicht vorhanden ist und daher bestimmte Funktionen des intelligenten Dokuments nicht verfügbar sind.
  • Falls die Programmausführungsumgebung nicht zur Verfügung steht, kann der Prüfungsschritt jedoch nicht direkt durch die Ausführung eines Programms vorgenommen werden. Ebenso kann die Angabe eines negativen Ergebnisses des Prüfungsschritts nicht mittels des Programmmoduls in das intelligente Dokument eingebracht werden.
  • Eine Ausführungsform des Verfahrens beinhaltet daher, dass in das intelligente Dokument eine darstellbare Angabe eines negativen Ergebnisses des Prüfungsschritts eingebracht wird, und dass das Programmmodul dazu ausgebildet wird, die Angabe des negativen Ergebnisses des Prüfungsschritts in eine darstellbare Angabe eines positiven Ergebnisses des Prüfungsschritts umzuwandeln.
  • Ferner sieht eine Ausführungsform des intelligenten Dokuments vor, dass das intelligente Dokument eine darstellbare Angabe eines negativen Ergebnisses des Prüfungsschritts enthält, die mittels des Programmmoduls in eine darstellbare Angabe eines positiven Ergebnisses des Prüfungsschrittes umwandelbar ist.
  • Zudem ist eine Ausführungsform der Vorrichtung dadurch gekennzeichnet, dass die Vorrichtung dazu ausgebildet ist, eine darstellbare Angabe eines negativen Ergebnisses des Prüfungsschritts in das intelligente Dokument einzubringen, und dass das Programmmodul dazu eingerichtet ist, die darstellbare Angabe des negativen Ergebnisses des Prüfungsschritts in eine Angabe eines positiven Ergebnisses des Prüfungsschritts umzuwandeln.
  • Bei diesen Ausführungsformen kann die Prüfung, ob die Programmausführungsumgebung vorhanden ist, vorteilhaft implizit mittels des Programmmoduls vorgenommen werden, das die Angabe des Ergebnisses des Prüfungsschritts innerhalb des intelligenten Dokuments erzeugt. Dies wird dadurch erreicht, dass aufgrund der Ausführung des Programmmoduls, die nur bei verfügbarer Programmausführungsumgebung erfolgen kann, eine Angabe eines positiven Ergebnisses des Prüfungsschritts durch eine Umwandlung einer bereits in dem intelligenten Dokument vorhandenen Angabe eines negativen Ergebnisses des Prüfungsschritts erzeugt wird. Falls die Programmausführungsumgebung nicht verfügbar ist, kann das Programmmodul nicht ausgeführt werden, und die Angabe des negativen Ergebnisses des Prüfungsschritts bleibt erhalten.
  • Bei einer Weiterbildung des Verfahrens, des intelligenten Dokuments und der Vorrichtung ist es vorgesehen, dass das Programm den einmaligen Druck eines Frankiervermerks steuert und dass das intelligente Dokument von einem Server über ein Netzwerk an einen Client übermittelt wird.
  • Eine Ausführungsform des Verfahrens, des intelligenten Dokuments und der Vorrichtung zeichnet sich weiterhin dadurch aus, dass bei einem ersten Druck des Frankiervermerks eine Nachricht von dem Client an den Server übermittelt wird und dass der Druck aufgrund der Nachricht in dem Server protokolliert wird.
  • Ferner ist es bei einer Ausgestaltung des Verfahrens, des intelligenten Dokuments und der Vorrichtung vorgesehen, dass das Programm zur Steuerung des Drucks des Frankiervermerks nur dann ausführbar ist, wenn eine Netzwerkverbindung zwischen dem Client und dem Server besteht und wenn anhand einer Abfrage des Servers festgestellt wird, dass der Frankiervermerk noch nicht gedruckt worden ist.
  • Hierdurch wird verhindert, dass ein einmal bezahlter Frankiervermerk mehrfach ausgedruckt wird.
  • Eine Ausgestaltung des Verfahrens, des intelligenten Dokuments und der Vorrichtung ist dadurch gekennzeichnet, dass in dem Prüfungsschritt überprüft wird, ob ein Zugriff auf das Netzwerk besteht.
  • Zudem beinhaltet eine Weiterbildung des Verfahrens, des intelligenten Dokuments und der Vorrichtung, dass in dem Prüfungsschritt eine Abfrage des Servers vorgenommen wird, bei der überprüft wird, ob Inhalte des intelligenten Dokuments bereits einmal gedruckt worden sind.
  • Eine weitere Ausgestaltung des Verfahrens, des intelligenten Dokuments und der Vorrichtung beinhaltet, dass die Programmausführungsumgebung Bestandteil des Darstellungsprogramms ist.
  • Darüber hinaus wird ein Computerprogrammprodukt bereitgestellt, das ein Computerprogramm zur Ausführung eines Verfahrens der zuvor beschriebenen Art enthält.
  • Diese und weitere Vorteile, Besonderheiten und zweckmäßige Weiterbildungen der Erfindung werden auch anhand der Ausführungsbeispiele deutlich, die im Folgenden unter Bezugnahme auf die Figuren beschrieben werden.
    • Kurze Beschreibung der Figuren
  • Von den Figuren zeigt:
    • Fig. 1
    eine schematische Darstellung eines Nutzerclients, der mit einem Server verbunden ist, von dem intelligente Dokumente an den Nutzerclient übermittelbar sind;
    Fig. 2
    eine Übersicht über erfindungsgemäß eingesetzte Schnittstellen;
    Fig. 3
    eine schematische Darstellung einer Integration einer Dokumentenerzeugung in ein erfindungsgemäßes System;
    Fig. 4
    einen Ablaufplan einer bevorzugten Integration von Zahlungsvorgängen und
    Fig. 5
    ein erfindungsgemäß erzeugtes Label.
    Darstellung der Erfindung anhand der Figuren
  • Die Erfindung beinhaltet vielfältige Möglichkeiten zur Erzeugung eines auf eine Postsendung aufbringbaren Labels. Durch das Aufbringen des Labels auf eine Postsendung wird das Verfahren zum Erzeugen eines auf eine Postsendung aufbringbaren Labels zu einem Verfahren zur Erstellung einer Postsendung weiterentwickelt.
  • Falls in dem Label enthaltene Daten sendungsrelevante Informationen enthalten, beispielsweise zur Entgeltsicherung, Sendungsverfolgung oder Weiterleitung, handelt es sich bei der Erfindung auch um ein Verfahren und ein System zum Transport von Postsendungen.
  • Nachfolgend werden besonders bevorzugte Ausführungsformen der Erfindung dargestellt, bei denen ein einfaches und sicheres Einbringen von Inhalten in die Label mit einem besonders hohen Nutzen für den Transport der Postsendungen verbunden wird.
  • Bei der Erzeugung der Label ist es besonders vorteilhaft, sowohl dynamische Inhalte als auch statische Inhalte in die Label einzubringen.
  • Die statischen Inhalte betreffen beispielsweise Rahmeninformationen. Diese Rahmeninformationen bilden vorzugsweise einen graphisch darstellbaren Rahmen.
  • Dynamische Inhalte können in diesen Rahmen eingebracht werden.
  • Es ist vorteilhaft, dass die dynamischen Inhalte bei Auftreten eines Ereignisses - beispielsweise bei erfolgter Durchführung eines Prüfungsschritts - übermittelt werden.
  • Erfindungsgemäß sind verschiedene Lösungen für die Übernahme von dynamischen Inhalten vorgesehen.
  • So ist es beispielsweise möglich, dynamische Inhalte unmittelbar vor einer Bildschirmdarstellung und /oder vor einem Druckvorgang zu übermitteln.
  • Dies kann beispielsweise auf eine der folgenden Arten geschehen:
    • per Textdatei (csv),
    • durch Direktübertragung aus einer Datenbank oder
    • über SOAP-Calls.
      In Figur 1 ist schematisch ein Server dargestellt.
      Der Server ist über ein Netzwerk mit einem Benutzerclient (Benutzersystem) verbunden. Bei dem Netzwerk handelt es sich beispielsweise um das Internet oder ein Intranet.
      Intelligente Dokumente werden von dem Server über das Netzwerk an einen Nutzerclient übermittelt. Hierzu verfügt der Server über eine beispielsweise als Softwareprogramm ausgebildete Einrichtung zur Erzeugung intelligenter Dokumente.
      In einer Ausführungsform ist der Server als Server ausgebildet, der intelligente Dokumente für den Druck von Labelen bereitstellt. In dieser Ausführungsform umfasst der Server eine Datenbank mit jeweils einem Eintrag für jedes erzeugte und an einen Nutzerclient übermittelte Label.
      Der dargestellte Server ist über ein Netzwerk mit einem Client verbunden. Bei dem Netzwerk handelt es sich beispielsweise um das Internet oder ein Intranet. Bei dem Client handelt es sich beispielsweise um einen PC (Personal Computer).
      Der Einsatz eines Personalcomputers ist lediglich beispielhaft zu verstehen. Hiermit ist jede Datenverarbeitungseinheit gemeint, die Bearbeitungsvorgänge ausführen kann. Insbesondere sind hierbei Systeme inbegriffen, die mit voneinander verschiedenen Betriebssystemen arbeiten können. Beispielsweise ist es möglich, Windows, Mac oder Linux-Betriebssysteme einzusetzen.
      Insbesondere handelt es sich bei dem Client (Nutzerclient) um einen Computer, der über das Internet angeschlossen ist. Die Verbindung mit dem Server erfolgt zur Erhöhung der Datensicherheit insbesondere via https "hyper text transfer Protocol" mit verschlüsselter Übertragung. Dies erschwert "Man in the Middle" Attacken.
      Es ist vorteilhaft, SOAP-Calls zusätzlich noch mit einer eigenen Signatur zu versehen und Informationen nur dann zu verarbeiten, wenn die jeweils angebrachte Signatur als gültig erkannt wurde.
      Bei den Informationen handelt es sich beispielsweise um Daten die mit der XML "Extended Markup Language" erstellt werden.
      Es ist vorteilhaft, einen Datenaustausch entsprechend SOAP "Simple Object Access Protocol" durchzuführen.
      In einer bevorzugten Ausführungsform werden die Daten auf den Client per Download übertragen.
      Auf dem Client ist beispielsweise ein Adobe-Reader, Version 6.0.2, eine jüngere Version dieses Programms oder Adobe Professional Software installiert. Inhalte werden über PDFs, per Adobe-Reader geöffnet und anschließend werden die dynamische Inhalte (insbesondere anwenderspezifische Daten) per Soap-Call in den Hauptspeicher der Anwendung Adobe-Reader geladen und dann zusammen mit den statischen Daten durch einen Druckauftrag an einen Drucker geschickt.
      Zweckmäßigerweise ist der Client so ausgestattet, dass er über eine Anzeigeeinrichtung und wenigstens eine Eingabeeinrichtung sowie über einen Speicher und einen Prozessor verfügt. In dem Speicher ist insbesondere ein Darstellungsprogramm gespeichert, das in dem Client ausführbar ist und dazu in der Lage ist, herkömmliche Dokumente eines bestimmten Formats, wie beispielsweise PDF-Dokumente zu öffnen und deren Inhalt an der Anzeigeeinrichtung darzustellen. Ferner erlaubt das Darstellungsprogramm die Verarbeitung von intelligenten Dokumenten, d.h., es ist dazu ausgebildet, darstellbare Inhalte von intelligenten Dokumenten an der Anzeigeeinrichtung darzustellen und Programme auszuführen, die in dem intelligenten Dokument enthalten sind. Hierfür stellt das Darstellungsprogramm eine Programmausführungsumgebung bereit, mit der in den Programmen enthaltene Programmbefehle interpretiert und ausgeführt werden können. Darüber hinaus ist der Client über eine Schnittstelle mit einer Druckeinrichtung verbunden und verfügt über eine Netzwerkschnittstelle zur Verbindung mit dem Netzwerk.
      Intelligente Dokumente werden von dem Server über das Netzwerk an den Client übermittelt. Hierzu verfügt der Server über eine beispielsweise als Softwareprogramm ausgebildete Einrichtung zur Erzeugung intelligenter Dokumente. In einer Ausführungsform ist der Server als Server ausgebildet, der intelligente Dokumente für den Druck von Frankiervermerken bereitstellt. In dieser Ausführungsform umfasst der Server eine Datenbank mit jeweils einem Eintrag für jeden erzeugten und an einen Client übermittelten Frankiervermerk.
      Die intelligenten Dokumente umfassen Inhalte, die mittels des Darstellungsprogramms an der Anzeigeeinrichtung dargestellt werden können und aus Text- und/oder Grafikelementen bestehen.
      Ferner sind in die intelligenten Dokumente Programme eingebettet, die mittels der Programmausführungsumgebung des Darstellungsprogramms ausführbar sind. Bei den Programmen handelt es sich um Skripte, die den Programmcode umfassen, der von der Programmausführungsumgebung interpretiert werden kann. Anhand der Programme können darstellbare Inhalte der intelligenten Dokumente verändert werden. Ferner ermöglichen die Programme die Ausführung weiterer Prozesse, wie beispielsweise die Ansteuerung der Druckeinrichtung für den Druck von Inhalten des intelligenten Dokuments oder Zugriffe auf die Netzwerkschnittstelle. Der Programmcode wird in dem normalen Darstellungsmodus des Darstellungsprogramms nicht an der Anzeigeeinrichtung dargestellt. Grundsätzlich kann jedoch das Darstellungsprogramm über einen Sonderdarstellungsmodus verfügen, in dem auch der Programmcode darstellbar ist.
      Ein von dem Server bereitgestelltes intelligentes Dokument enthält im Rahmen der vorliegenden Erfindung ferner eine Statusinformation zur Angabe des Ergebnisses eines oder mehrerer Prüfungsschritte. Darstellbare Angaben der Prüfungsergebnisse werden dabei mittels eines oder mehrerer Programmmodule erzeugt, die ebenfalls in dem intelligenten Dokument enthalten sind. Die Programmmodule können als eigenständige Programme ausgebildet oder Teil eines Programms sein, das zur Ausführung der Hauptfunktionalität des intelligenten Dokuments vorgesehen ist. Innerhalb der Prüfungsschritte wird ermittelt, ob bestimmte Voraussetzungen für die Nutzung der Hauptfunktionalitäten des intelligenten Dokuments vorliegen. Hierdurch erlangt der Nutzer im Falle einer nicht nutzbaren Funktionalität insbesondere Kenntnis einer möglicherweise nicht erfüllten Voraussetzung. Diese Kenntnis kann er verwenden, um die Voraussetzung zu schaffen und so die Funktionalitäten des intelligenten Dokuments zu nutzen.
      Eine Voraussetzung für die Nutzung der Funktionalität eines intelligenten Dokuments ist die Verfügbarkeit der Programmausführungsumgebung. In der Regel enthalten jedoch nicht alle Darstellungsprogramme zur Darstellung von Dokumenten im Format des intelligenten Dokuments eine geeignete Programmausführungsumgebung. So kann die Programmausführungsumgebung beispielsweise in älteren Versionen des Darstellungsprogramms nicht vorhanden sein. In einer Ausführungsform wird daher in einem Prüfungsschritt insbesondere geprüft, ob das Darstellungsprogramm des Clients über eine Programmausführungsumgebung verfügt, die zur Ausführung des in dem intelligenten Dokument enthaltenen Programms geeignet ist. Um das Ergebnis dieses Prüfungsschritts auch dann korrekt darstellen zu können, wenn die Programmausführungsumgebung nicht vorhanden ist, wird bereits bei der Erstellung des intelligenten Dokuments eine darstellbare Angabe eines negativen Ergebnisses des Prüfungsschritts in das Dokument eingebracht. Ferner wird in das intelligente Dokument ein Programmmodul eingebracht, das die Angabe des negativen Ergebnisses des Prüfungsschritts in die Angabe einer erfolgreichen Durchführung des Prüfungsschritts umwandelt, wenn es ausgeführt wird. Das intelligente Dokument wird dabei vorzugsweise so konfiguriert, dass das Programmmodul nach dem Öffnen des intelligenten Dokuments in dem Darstellungsprogramm bei vorhandener Programmausführungsumgebung automatisch gestartet wird.
      Die Prüfung, ob die Programmausführungsumgebung zur Verfügung steht, wird vorzugsweise implizit durchgeführt und liefert ein positives oder negatives Ergebnis, je nachdem ob das Programmmodul ausgeführt werden kann oder nicht.
      Neben diesem Prüfungsschritt, in dem eine Entscheidung über das Vorhandensein der Programmausführungsumgebung getroffen wird, können gleichfalls andere Prüfungsschritte mittels eines in dem intelligenten Dokument enthaltenen Programms ausgeführt werden. Die Ergebnisse dieser Prüfungsschritte können dann in der gleichen Weise dargestellt werden, indem mittels eines Programmmoduls eine Umwandlung der Angabe eines negativen Ergebnisses in die Angabe eines positiven Ergebnisses vorgenommen wird.
      Die Umwandlung der Angabe des negativen Ergebnisses des Prüfungsschritts in die Darstellung eines positiven Ergebnisses des Prüfungsschritts kann durch eine Veränderung der Angabe erfolgen. Beispielsweise können der negativen Angabe eine oder mehrere Zeichen hinzugefügt werden, um eine Angabe eines positiven Ergebnisses des Prüfungsschritts zu erzeugen. Ferner kann die Statusangabe beispielsweise farbig ausgebildet sein. Die Umwandlung der Angabe des negativen Ergebnisses des Prüfungsschritts in eine Angabe eines positiven Ergebnisses kann hierbei durch eine Farbänderung erfolgen, die mittels des Programms vorgenommen wird. Darüber hinaus kann es auch vorgesehen sein, dass Zeichen oder Symbole der Angabe des negativen Ergebnisses des Prüfungsergebnisses zumindest teilweise durch Zeichen oder Symbole ersetzt werden, mittels derer ein positives Ergebnis des Prüfungsschritts dargestellt wird. Die Darstellung der Prüfergebnisse kann hierbei für den Nutzer sichtbar oder unsichtbar erfolgen.
      Die intelligenten Dokumente umfassen Inhalte, die mittels des Darstellungsprogramms an einer Anzeigeeinrichtung dargestellt werden können und aus Text- und/oder Grafikelementen bestehen. Ferner sind in die intelligenten Dokumente Programme eingebettet, die mittels der Programmausführungsumgebung des Darstellungsprogramms ausführbar sind.
      Bei den Programmen handelt es sich beispielsweise um Skripte, die den Programmcode umfassen, der von der Programmausführungsumgebung interpretiert werden kann. Anhand der Programme können darstellbare Inhalte der intelligenten Dokumente verändert werden. Ferner ermöglichen die Programme die Ausführung weiterer Prozesse, wie beispielsweise die Ansteuerung einer Druckeinrichtung für den Druck von Inhalten des intelligenten Dokuments oder Zugriffe auf die Netzwerkschnittstelle. Der Programmcode wird in dem normalen Darstellungsmodus des Darstellungsprogramms nicht an der Anzeigeeinrichtung dargestellt. Grundsätzlich kann jedoch das Darstellungsprogramm über einen Sonderdarstellungsmodus vorfügen, in dem auch der Programmcode darstellbar ist.
      Ein von dem Server bereitgestelltes intelligentes Dokument enthält im Rahmen der vorliegenden Erfindung ferner eine Statusinformation zur Angabe des Ergebnisses eines oder mehrerer Prüfungsschritte. Darstellbare Angaben der Prüfungsergebnisse werden dabei mittels eines oder mehrerer Programmmodule erzeugt, die ebenfalls in dem intelligenten Dokument enthalten sind. Die Programmmodule können als eigenständige Programme ausgebildet oder Teil eines Programms sein, das zur Ausführung der Hauptfunktionalität des intelligenten Dokuments vorgesehen ist. Innerhalb der Prüfungsschritte wird ermittelt, ob bestimmte Voraussetzungen für die Nutzung der Hauptfunktionalitäten des intelligenten Dokuments vorliegen. Hierdurch erlangt der Nutzer im Falle einer nicht nutzbaren Funktionalität insbesondere Kenntnis einer möglicherweise nicht erfüllten Voraussetzung. Diese Kenntnis kann er verwenden, um die Voraussetzung zu schaffen und so die Funktionalitäten des intelligenten Dokuments zu nutzen.
      Eine Voraussetzung für die Nutzung der Funktionalität eines intelligenten Dokuments ist die Verfügbarkeit der Programmausführungsumgebung. In der Regel enthalten jedoch nicht alle Darstellungsprogramme zur Darstellung von Dokumenten im Format des intelligenten Dokuments eine geeignete Programmausführungsumgebung. So kann die Programmausführungsumgebung beispielsweise in älteren Versionen des Darstellungsprogramms nicht vorhanden sein. In einer Ausführungsform wird daher in einem Prüfungsschritt insbesondere geprüft, ob das Darstellungsprogramm des Nutzerclients über eine Programmausführungsumgebung verfügt, die zur Ausführung des in dem intelligenten Dokument enthaltenen Programms geeignet ist. Um das Ergebnis dieses Prüfungsschritts auch dann korrekt darstellen zu können, wenn die Programmausführungsumgebung nicht vorhanden ist, wird bereits bei der Erstellung des intelligenten Dokuments eine darstellbare Angabe eines negativen Ergebnisses des Prüfungsschritts in das Dokument eingebracht. Ferner wird in das intelligente Dokument ein Programmmodul eingebracht, das die Angabe des negativen Ergebnisses des Prüfungsschritts in die Angabe einer erfolgreichen Durchführung des Prüfungsschritts umwandelt, wenn es ausgeführt wird. Das intelligente Dokument wird dabei vorzugsweise so konfiguriert, dass das Programmmodul nach dem Öffnen des intelligenten Dokuments in dem Darstellungsprogramm bei vorhandener Programmausführungsumgebung automatisch gestartet wird.
      Die Prüfung, ob die Programmausführungsumgebung zur Verfügung steht, wird vorzugsweise implizit durchgeführt und liefert ein positives oder negatives Ergebnis, je nachdem, ob das Programmmodul ausgeführt werden kann oder nicht.
      Neben diesem Prüfungsschritt, in dem eine Entscheidung über das Vorhandensein der Programmausführungsumgebung getroffen wird, können gleichfalls andere Prüfungsschritte mittels eines in dem intelligenten Dokument enthaltenen Programms ausgeführt werden. Die Ergebnisse dieser Prüfungsschritte können dann in der gleichen Weise dargestellt werden, indem mittels eines Programmmoduls eine Umwandlung der Angabe eines negativen Ergebnisses in die Angabe eines positiven Ergebnisses vorgenommen wird.
      Die Umwandlung der Angabe des negativen Ergebnisses des Prüfungsschritts in die Darstellung eines positiven Ergebnisses des Prüfungsschritts kann durch eine Veränderung der Angabe erfolgen. Beispielsweise können der negativen Angabe eine oder mehrere Zeichen hinzugefügt werden, um eine Angabe eines positiven Ergebnisses des Prüfungsschritts zu erzeugen. Ferner kann die Statusangabe beispielsweise farbig ausgebildet sein oder für den Nutzer unsichtbar bleiben, außer im Falle, dass das Prüfergebnis negativ ist, um den Nutzer so über das negative Prüfergebnis zu informieren. Die Umwandlung der Angabe des negativen Ergebnisses des Prüfungsschritts in eine Angabe eines positiven Ergebnisses kann hierbei durch eine Farbänderung erfolgen, die mittels des Programms vorgenommen wird. Darüber hinaus kann es auch vorgesehen sein, dass Zeichen oder Symbole der Angabe des negativen Ergebnisses des Prüfungsergebnisses zumindest teilweise durch Zeichen oder Symbole ersetzt werden, mittels derer ein positives Ergebnis des Prüfungsschritts dargestellt wird.
      Die dargestellten Schritte erfolgen vorzugsweise unter Einsatz des in Fig. 1 dargestellten Systems.
      Dieses System beinhaltet einen Anbieterserver und einen Netzwerkknoten (nachfolgend Maptos genannt).
      In der Übersicht steht Maptos für einen externen Einstiegspunkt in die Anwendung POP. Weitere Zugriffe auf die einzelnen Webseiten der Anwendung POP werden ggf. transparent durch Maptos geschleust.
      Maptos bezeichnet einen Netzwerkknoten zum Bereitstellen wenigstens eines Internetdienstes, der in wenigstens einem Anbieterserver eines Dienstanbieters ausgeführt wird.
      Eine Weiterbildung des Netzwerkknotens Maptos umfasst wenigstens einen äußeren Konnektor zum Empfangen einer Dienstanforderung, deren Erzeugung in einem Nutzercomputer eines Internetmarktplatznutzers initiierbar ist, und zum Übermitteln eines in dem Anbieterserver ermittelten Bearbeitungsergebnisses an den Nutzercomputer, wobei der äußere Konnektor in der Lage ist, eine an den Internetmarktplatz angepasste Formatänderung der Dienstanforderung und des Bearbeitungsergebnisses vorzunehmen.
      Ferner ist es zweckmäßig, den Netzwerknoten so auszubilden, dass er eine mit dem äußeren Konnektor verbundene Transformationseinheit zum Ermitteln wenigstens eines Anbieterservers zur Ausführung des Dienstes anhand von Angaben, die in der Dienstanforderung enthalten sind, und zum Adressieren der Dienstanforderung an den ermittelten Anbieterserver aufweist.
      Eine Weiterbildung des Netzwerkknotens umfasst wenigstens einen mit der Transformationseinheit verbundenen inneren Konnektor zum Übermitteln der Dienstanforderung an den Anbieterserver und zum Empfangen des in dem Anbieterserver ermittelten Bearbeitungsergebnisses von dem Anbieter-Server.
      Der Begriff Internetmarktplatz ist dabei im Rahmen der Erfindung in seiner weitesten Bedeutung zu verstehen und umfasst insbesondere Webportale, wie beispielsweise Auktionsportale Tauschbörsen oder Diskussionsforen im Internet sowie Webseiten, die beispielsweise von Online-Shops bereitgestellt werden.
      Der Netzwerkknoten ermöglicht es, von einem Dienstanbieter bereitgestellte Internetdienste auf einem Internetmarktplatz bereitzustellen, ohne dass Anpassungen der Anbieterserver, welche die Internetdienste ausführen, an den Internetmarktplatz erforderlich sind. Die Interpretation der Dienstanforderung, d.h. insbesondere die Vornahme erforderlicher Formatänderungen, die Ermittlung des zur Ausführung des Dienstes notwendigen Anbieterservers und die Adressierung der Dienstanforderung an den Anbieterserver erfolgt in dem Netzwerkknoten, so dass die zur Ausführung des Internetdienstes erforderlichen Angaben in einer marktplatzspezifischen Weise erfasst und in die Dienstanforderung eingebracht werden können, ohne dass bereits durch den Internetmarktplatz eine Anpassung an die Erfordernisse des Anbieterservers vorgenommen werden muss.
      Darüber hinaus ist die Schnittstelle zwischen dem Netzwerkknoten und dem Internetmarktplatz von der Schnittstelle zwischen dem Netzwerkknoten und dem Anbieterserver entkoppelt, wodurch eine besonders große Flexibilität bei der Anpassung des Transformationsknotens erreicht wird.
      Durch die äußeren Konnektoren wird mit Vorteil erreicht, dass der Netzwerkknoten selbst in einfacher und flexibler Weise an einen Internetmarktplatz und insbesondere an ein bei der Kommunikation mit einem Internetmarktplatz verwendetes Datenformat angepasst werden kann, ohne dass bei der Anpassung Änderungen der inneren Funktionalität des Netzwerkknotens, d.h. insbesondere Anpassungen der Transformationseinheit erforderlich sind.
      Der POP-Server läuft auf mehreren Instanzen z.B. innerhalb eines BEA 9.x Clusters.
      Ein vorgeschalteter Webserver ist bei einer bevorzugten Ausführungsform der Erfindung nicht erforderlich, falls die Anwendung alle Daten (HTML, PDF) dynamisch generiert.
      Für die Verteilung der HTTP-Requests auf die einzelnen Instanzen innerhalb des BEA-Clusters werden Sticky-Sessions benutzt. Sticky-Sessions stellen sicher, dass eine einzelne Session eines Anwenders immer von derselben Clusternode bearbeitet wird.
      Für die persistente Speicherung der Daten verwendet die Anwendung POP für alle Instanzen eine gemeinsame Datenbank, beispielsweise Oracle 9.x oder 10.x.
      Für die Aggregation von Logging-Daten für Statistiken ist als CronJob ein Java-Prozess vorgesehen, der auf die die Datenbank des POP-Servers zugreift. Dieser Prozess kann optional auch alte Logging-Daten periodisch löschen.
      Ein weiterer Batchjob verwendet die vorher von dem POP-Server in die Datenbank geschriebenen Daten für das Melden von spezifischen Daten (nachfolgend PAN-Daten genannt) an Drittsysteme (nachfolgend ECICC genannt).
      Eine Speicherung von Daten des POP-Servers außerhalb der Datenbank in einem Dateisystem ist möglich, jedoch nicht erforderlich. Es ist vorteilhaft, dass das EDICC-Modul temporäre Dateien (/tmp) für das sFTP-Protokoll anlegt.
    Bemerkung:
  • Batch-Jobs werden vor einem parallelen, d.h. mehrfachen Starten geschützt, um zu verhindern, dass hierdurch unerwünschte Nebeneffekte auftreten.
  • In Fig. 2 ist eine Übersicht über besonders vorteilhafte Schnittstellen dargestellt.
  • Die Schnittstellen dienen zu einer Verbindung zwischen einem erfindungsgemäßen Anbieterserver mit einem Providerserver (Provider genannt). Die Erfindung erfolgt vorteilhafterweise über das Internet.
  • Der Anbieterserver ist mit einem Client (Benutzersystem) verbindbar. Bei dem Client handelt es sich beispielsweise um ein Benutzersystem, das so ausgestattet ist, dass es Daten von dem Server empfangen und/oder Daten zu dem Server übermitteln kann. Beispielsweise handelt es sich bei dem Client um einen Personalcomputer, ein Unternehmensnetzwerk oder um ein mobiles Benutzerendgerät, beispielsweise ein Mobiltelefon.
  • Vorzugsweise ist der Client so gestaltet, dass er Browser-Funktionalitäten beinhaltet.
  • Hierbei handelt es sich beispielsweise um einen Webbrowser (mit aktiviertem Javascript, HTML 4.0), wobei es vorteilhaft ist, dass die Applikation so ausgebildet ist, dass sie mit einer Vielzahl unterschiedlicher Browsertypen gestartet und benutzt werden kann. Hierunter fallen z.B. folgende Browsertypen:
    • Internet Explorer Version 6.0,
    • Mozilla Firefox 1.5,
    • Netscape 7.1,
    • Safari 2.0.4 (Mac OS).
  • Die Liste der genannten Browser ist jederzeit erweiterbar, um Fortentwicklungen berücksichtigen zu können.
  • Es ist zweckmäßig, Sicherungsmechanismen einzuführen, um die Kommunikation zwischen dem Client und dem Anbieterserver vor einem unberechtigten Abhören durch Dritte zu sichern.
  • Ebenso ist eine Sicherung der Kommunikation zwischen dem Anbieterserver und weiteren externen Systemen - insbesondere Zahlungssystemen - zweckmäßig.
  • Es ist daher vorteilhaft, bei der Kommunikation sichere Protokolle einzusetzen. Dies sind beispielsweise:
    • HTTPS (POST, GET, XML),
    • sFTP (EDICC).
  • Beide Protokolle sind von Manipulation oder Abhören durch Dritte abgesichert.
  • Falls die Kommunikation mit einen unternehmensinternen System über ein internes Netz erfolgt und die übertragenen Daten keine sensiblen Daten enthält, kann optional HTTP anstatt HTTPS verwendet werden.
  • In den versendeten E-Mails werden direkt keine Codes, Passwörter o. ä. versendet, sondern lediglich ein Link mit einer ID (vorzugsweise von der Transaktions-ID verschieden) eingebettet, der auf eine HTML-Seite (NOW3) verzweigt.
    • Missbrauchsicherung
  • Die von der Anwendung generierten Nummern - Gutscheine, Dokumente, Warenkorb, PIN - werden so generiert, dass sie nicht durch den Anwender erratbar sind. Außerdem werden diese Nummern in der Datenbank gespeichert und so ihr "Verbrauch" kontrolliert.
    • System-Zugangsdaten
  • Zugangsdaten, die für die Benutzung der externen Schnittstellen nötig sind, werden über ein symmetrisches Verschlüsselungsverfahren (in der Webanwendung enthalten) in der Datenbank abgelegt, d. h. diese können auch durch eine Datenbank-Administrator nicht eingesehen werden.
    • Sicherungsprotokolle der Bezahlplattformen
  • Die Standardmechanismen zur Absicherung der Kommunikation zwischen Anwendung und Bezahlplattform werden verwendet.
  • Die eigentlichen Bezahlvorgänge werden auf den Webseiten der Bezahlplattform durchgeführt, so dass diese Transaktion für die Anwendung gekapselt ist.
    • Nutzerbezogene Daten
  • Vorzugsweise enthält der Anbieterserver nur die Daten, die für die Durchführung des Verfahrens zweckmäßig sind. Dies sind beispielsweise:
    • Inhalt des Warenkorbes, solange es notwendig ist, dem Nutzer die entsprechenden Funktionen zur Verfügung zu stellen (PDF-Dokumente beispielsweise 32 Tage; für Gutscheincodes auch länger, wobei diese Werte aus technischer Hinsicht beliebig konfigurierbar sind, so dass die vorgegebene Setzung lediglich exemplarischen Charakter hat).
    • Die gekauften Label inkl. der notwendigen Daten (32 Tage - siehe vorherigen Punkt).
    • E-Mail-Adresse des Nutzers aus der Kurzregistrierung mit Teilnahme an Mailing-Aktionen (unbegrenzt).
    • Enthält der Warenkorb Gutscheine, die noch nicht aufgebraucht sind, so ist der Warenkorb mit diesen Gutscheinen entsprechend länger gültig (Gültigkeit der Gutscheine).
  • Daten werden in der Datenbank nicht gelöscht, sondern lediglich entsprechend über z. B. ein Attribut markiert.
  • Der nachträgliche Zugriff eines Anwenders auf seinen Warenkorb erfolgt ab einem gewissen Preisvolumen über die zusätzliche Eingabe einer PIN oder PIN2.
    • Nachvollziehbarkeit durch Protokollierung (Logging)
  • Alle wichtigen Aktionen der Anwendung sowie die Aufrufe von externen Schnittstellen werden in der Datenbank protokolliert.
  • Ist die Protokollierung in der Datenbank nicht möglich, z. B. bei Datenbankfehlern, werden die Logging-Mechanismen des Applikationsservers verwendet.
    • Konfigurationsmanagement
  • Das Konfigurationsmanagement mit den zeitbehafteten Daten (z. B. Preise, Gutscheine) und den statischen Ressourcen ist so angelegt, dass einmal angelegte und bereits produktiv geschaltete Konfigurationen nicht mehr aus der Datenbank entfernt werden können. Weiterhin sind für jeden Zeitpunkt in der Vergangenheit die zu diesem Zeitpunkt gültigen Konfigurationsdaten rekonstruierbar.
    • Oberfläche
  • Die für den Benutzer sichtbare Oberfläche der Anwendung gliedert sich im Wesentlichen in folgende Webseiten:
    • NOW1: Anzeige des kompletten Warenkorbes,
    • NOW2-Sendung: Detaildarstellung einer Sendung,
    • NOW2-Gutschein: Detaildarstellung eines Gutschein-Sets,
    • Now2-Abholung: Detaildarstellung einer Abholungsbeauftragung
    • NOW3: Angaben zum im vorherigen Schritt bezahlten Warenkorb.
    Felddefinitionen
  • Um eine Beeinflussung des Seitenlayouts durch die Anzeige überlanger Feldinhalte zu verhindern (beispielsweise sehr lange Straßennamen), werden diese entweder in nicht editierbaren Textboxen mit fester Länge angezeigt oder nach einer festgelegten Anzahl von Zeichen abgeschnitten (natürlich nur für die Anzeige).
  • Eingabefelder sind speziell markiert (Edit, Input); ansonsten sind die beschriebenen Felder reine Anzeigefelder ohne weitere Funktion. Ggf. folgende Angaben in runden Klammern wie AN(64) bedeuten "maximal 64 Stellen alphanumerisch"; analog etwa N(6) "maximal 6 Stellen numerisch". Falls nicht genauer spezifiziert, handelt es sich um einzeilige Eingabefelder mit freier Eingabe (keine Dropdown-Liste o.ä.). Bei Validierungsfehlern (falsches Format; fehlende Eingabe) wird das entsprechende Feld oder der Bereich farbig markiert.
    • NOW1: Warenkorb
  • Diese Seite zeigt den Warenkorb und enthaltene Positionen in einer Übersicht an. Der Benutzer kann Einträge im Warenkorb erzeugen oder manipulieren und schließlich die Bezahlung anstoßen.
    • Erreichbar von
    • NOWO: Link auf Eingangsseite
    • NOW1: Reload (beispielsweise Fehlermeldungen anzeigen; Gutschein einlösen)
    • NOW2: Rücksprung nach Bearbeitung einer einzelnen Listenposition
  • Die Anzeige einer einzelnen Sendung des Warenkorbes besteht aus folgenden Elementen:
    • Icon "Ausrufezeichen" bei fehlerhaften Sendungsdaten; in diesem Fall ist die Position auch mit einer anderen Farbe hinterlegt,
    • Absender-Adresse, bestehend aus den Zeilen Name1, Name2, Straße, Hausnummer, Postleitzahl, Ort und Land (Land nur, falls nicht Deutschland),
    • Empfänger-Adresse, bestehend aus den Zeilen Name1, Name2, Straße, Hausnummer, Postleitzahl, Ort und Land (Land nur, falls nicht Deutschland).
    • Produkt-Zelle
      • o Gewähltes Produkt und Liste aller möglichen wählbaren Services zum Produkt. Die vom Benutzer bereits gewählten Optionen sind markiert. Falls noch kein Produkt ausgewählt wurde, wird ein statischer Text "Kein Produkt gewählt" angezeigt.
      • o Aktion "Service (de-)selektieren".
    • Preis-Zelle
      • o Ein Gesamtpreis inklusive Währung für die komplette Sendung. Falls kein Preis bestimmbar ist, wird auch kein Preis angezeigt.
      • o Ist für diese Sendung bereits ein Gutschein eingelöst, erscheint der statische Text "Gutschein eingelöst".
      • o Alternativ: Aktion: "Gutschein einlösen" (Button "Ok") mit Eingabefeld für die Gutschein-Nummer.
    • Aktion "Entfernen",
    • Aktion: (Position) "Ändern ...". Aufruf von NOW2,
    • Optionale Meldungen zur Sendung, die die volle Breite einer Sendung einnehmen.
    Position - Abholung
  • Dieser Eintrag erscheint hinter allen Sendungs- und Gutschein-set-Positionen und nur, wenn eine Abholung für den Warenkorb gebucht ist. Der angezeigte Preis wird bei jeder Änderung des Warenkorbes neu berechnet.
  • Die Anzeige besteht aus folgenden Elementen:
    • Die Zellen "Absender" und "Empfänger" bleiben leer,
    • Zelle "Produkt": Statischer Text "Abholung aller Sendungen",
    • Zelle "Preis": Der Gesamt-Aufpreis für die Abholung; hier werden die Beträge pro Sendung summiert,
    • Aktion "Position entfernen" storniert eine gebuchte Abholung,
    • Aktion "Position ändern": Aufruf des Popup-Fensters.
    Position - Rabatt-Information
  • In dieser Position werden dem Anwender Informationen zu einem eventuell eingeräumten Rabatt angezeigt.
  • Die Anzeige besteht aus folgenden Elementen:
    • In den Zellen "Absender" und "Empfänger" kann ein in der Rabattregel hinterlegter Text eingeblendet werden.
    • In der Zelle "Produkt" wird der statische Text "Rabatt" und der Name der entsprechenden Rabattdefinition angezeigt.
    • In der Zelle "Preis" wird die Rabattsumme inklusive Währung als negativer Posten angezeigt.
    • Aktion "Position entfernen" und Aktion "Position ändern" entfallen.
    Aktion "Service (de-)selektieren"
  • Der Anwender kann einzelne Services auf eine Sendungsposition buchen. Die Änderung wird direkt nach der Selektion aktiv, d. h., die Webseite wird nach jeder Aktion neu geladen. Existiert kein entsprechendes Produkt zu der gewählten Kombination, so wird eine Fehlermeldung angezeigt. In einer besonders bevorzugten Ausprägungsform kann durch technische Verfahren auch erreicht werden, dass zur Neukonfiguration eines Preises kein kompletter Reload einer Seite erforderlich ist.
    • Aktion "Weitere Sendung hinzufügen ..."
  • Direkte Anzeige der Seite NOW2-Sendung. Als Vorgabe für die Absenderadresse wird die Adresse der ersten Sendung benutzt, falls vorhanden.
    • Aktion "MwSt.-Aufschlüsselung"
  • Anzeige des Popups.
    • Aktion "Wieso ist eine gültige E-Mail-Adresse erforderlich?"
  • Anzeige des Popups.
    • Aktion: "Allgemeine Geschäftsbedingungen aufrufen"
  • Anzeige des Popups.
    • Aktion: (Position) "Ändern"
  • Aufruf von NOW2-Sendung.
    • Aktion "Gutschein einlösen"
  • Als Eingabe dient eine Gutscheinnummer. Der Gutschein ist der Sendung zugeordnet, in dessen Zeile die Nummer eingegeben wurde. Bei fehlerhaftem Code wird an der definierten Stelle ein Fehlertext wie "Ungültiger Gutscheincode", "Gutscheincode abgelaufen" oder "Gutschein passt nicht zur Sendung" eingeblendet. Ist für die Sendung noch kein Produkt ausgewählt, so wird es anhand des Gutscheincodes gesetzt.
  • Ist im Gutschein auch eine TAS-Abholung enthalten, so wird diese automatisch für den ganzen Warenkorb gebucht.
    • Aktion "Weiter zur Bezahlung"
  • Diese Aktion ist deaktiviert, wenn
    • der Warenkorb leer ist,
    • eine Sendung mit fehlerhaften Daten existiert,
    • die Abhol-Adresse nicht TAS-leitcodierbar ist.
      Sollten während des Bezahlungsvorganges Fehler auftreten, so wird wieder NOW1 angezeigt und an der definierten Stelle eine textuelle Fehlermeldung eingeblendet. Im Erfolgsfall springt die Anwendung zu NOW3.
    Aktion "Position entfernen"
  • Zunächst muss der Anwender die Aktion bestätigen ("Wollen Sie wirklich ..."). Bei Zustimmung wird die Position aus dem Warenkorb entfernt. Ein auf dieser Position eingelöster Gutschein wird wieder freigegeben.
    • Aktion (Abholung) "Buchen"
  • Über das nun erscheinende Popup-Fenster erfasst der Anwender das Abholdatum und die Abholadresse. Die Kosten für die TAS-Abholung werden dann in einer eigenen Warenkorb-Position angezeigt.
    • Aktion "Gutscheine auswählen"
  • Ruft die Seite NOW2-Gutschein auf.
    • Optionale Meldungen zu einer Sendung
  • Meldung "Für diese Sendung ist keine Abholung möglich" wird angezeigt, wenn für den Warenkorb eine Abholung gebucht ist, das der Sendung zugrunde liegende Produkt aber nicht mit diesem Service kombiniert werden kann.
  • Meldung "Die Empfängeradresse konnte nicht verifiziert werden", falls die Empfängeradresse nicht leitcodierbar ist.
  • Fehlermeldung "Die Sendungsdaten sind nicht vollständig. Bitte korrigieren Sie Ihre Angaben", falls die Sendungsdaten fehlerhaft sind.
    • Baustein NOW1
  • Auf der Seite wird unten links der dynamische Baustein NOW1 eingeblendet.
  • In einer Eingabemaske (Popup-Fenster) kann der Anwender mit Hilfe einer Dropdownliste ein Abholdatum und eine Abholadresse erfassen. Die Datumsliste enthält n Folgetage in chronologischer, aufsteigender Reihenfolge. Der erste Tag ist vorselektiert. Sonntage werden nicht in der Liste angeboten. Ob der nächste Tag noch in der Liste angezeigt wird, entscheidet sich mit Hilfe einer konfigurierbaren Zeitangabe:
    Liegt die aktuelle Systemzeit noch vor dieser Uhrzeit, wird der nächste Tag angeboten; ansonsten frühestens der übernächste. Die Gesamtzahl der Einträge in der Liste lässt sich ebenfalls konfigurieren. Als initiale Vorgabe für die Abholadresse wird die Absenderadresse der ersten Sendung benutzt. Das Fenster kann erst mit "Bestätigen" verlassen werden, wenn die Abholadresse leitcodierbar ist. Im Fehlerfall wird eine Meldung wie im Screenshot ersichtlich angezeigt.
  • In einer Weiterführung der Erfindung ist es ebenfalls möglich, auch Abholung für denselben Tag respektive für spezifische Zeitfenster zu buchen.
    • Popup E-Mail-Bestätigung
  • Will der Benutzer den Warenkorb bezahlen, so wird er mit Hilfe dieses Popup-Fensters aufgefordert, die im Warenkorb erfasste E-Mail-Adresse zu bestätigen. (Ausnahme: Bei der Adresse handelt es sich um die per Maptos übertragene E-Mail-Adresse). Bei Bedarf kann die Angabe in diesem Fenster überschrieben werden.
    • Zustimmung zu AGBs
  • Für jeden Warenkorb muss der Anwender erneut den AGBs zustimmen, indem er die entsprechende Selectbox markiert, d.h. der Defaultwert ist "nicht gesetzt".
    • Fehlerhafte Sendungsdaten
  • Jede fehlerhafte Sendung wird durch ein führendes "!" gekennzeichnet und muss durch den Anwender korrigiert oder entfernt werden, bevor der Warenkorb bezahlt werden kann.
  • In einem ersten Schritt wird für Absender- und Empfänger-Adresse geprüft, ob die Pflichtfelder
    • Name,
    • Straße,
    • Postleitzahl,
    • Ort
    gefüllt sind. Ist beispielsweise der Name einer Empfängeradresse für eine Sendung leer, so gilt die ganze Adresse und damit die Sendung als fehlerhaft.
  • Analog wird verfahren, wenn
    • kein oder ein ungültiger Produktschlüssel hinterlegt oder
    • bei einer gebuchten Abholung die Abholadresse nicht leitcodierbar ist.
  • Gewisse, im folgenden Absatz beschriebene, Funktionen sind zusätzlich von der Leitcodierbarkeit von Absender- oder Empfängeradresse abhängig.
    • Leitcodes prüfen
  • Bei (Wieder)-Eintritt in NOW1 werden die Leitcodes der Empfänger-Adressen bestimmt. Dieser Vorgang erfolgt synchron, um die Ergebnisse sofort anzeigen zu können. Die bestimmten Leitcodes bzw. der Status Adresse nicht leitcodierbar wird innerhalb der Anwendersession bei jeder Adresse gespeichert, um die Anzahl der Leitcodieraufrufe aus Performancegründen zu minimieren.
    • NOW2: Sendungs-Details
  • Auf dieser Seite können die Daten einer Sendung wie Adressen und Produkt erfasst und manipuliert werden. Bei nicht gesetztem Produkt wird das zum Empfängerland passende Produkt (höchster Sortierschlüssel-Wert) vorausgewählt.
  • Erreichbar von:
    • NOW1: Aktion "Weitere Sendung hinzufügen"
      (Anzeige von NOW2 mit Vorgabewerten)
    • NOW1: Aktion "Ändern ..."
      (Anzeige mit den Daten der entsprechenden Sendung)
  • Im oberen Teil der Seite werden Absender- und Empfängeradresse erfasst. Für das Sender- und Empfänger-Land wird eine Dropdownliste angeboten, aus der der Anwender das Land auswählen kann. Eine freie Eingabe ist nicht möglich, aber generell vorstellbar. Ist für das Land keine explizite Angabe vorhanden, so wird "Deutschland" als Voreinstellung benutzt.
  • Die Länderliste ist im System hinterlegt.
  • Im zweiten Teil werden abhängig vom Empfängerland die möglichen Basisprodukte angezeigt (normalerweise immer "Päckchen", "Paket 10kg", "Paket 20kg", wobei dies lediglich Beispiele für Basisprodukte sind), von denen der Anwender genau eines auswählen muss. Ist für die Sendung noch kein Produkt hinterlegt, so wird der erste Eintrag automatisch selektiert. Bei Selektion eines Produktes wird die Seite aktualisiert und der für das selektierte Produkt und die aktuelle Kombination der Services gültige Produktpreis angezeigt.
  • Im dritten Teil der Seite werden die für die Kombination aus Empfängerland und Basisprodukt möglichen Services zur Auswahl angeboten. Bei (De-)Selektion wird die Seite aktualisiert und der aktuelle Preis für die selektierten Services angezeigt.
  • Durch ein geeignetes Darstellungsmedium - insbesondere eine Webseite - wird eine Auswahl einzelner, mehrerer oder sämtlicher der nachfolgenden Aktionen ermöglicht.
    • Aktion "Gutscheincode entfernen"
  • Falls für diese Sendung ein Gutscheincode erfasst ist, wird er nach einer Sicherheitsabfrage ("Wollen Sie wirklich ...?") wieder entfernt.
    • Aktion "Abbrechen"
  • Die Änderungen auf der Seite werden verworfen und wieder NOW1 angesprungen.
    • Aktion "Gutschein entfernen"
  • Diese Aktion ist nur aktiviert, wenn bereits ein Gutschein auf diese Sendung eingelöst ist. Der Code wird nach einer Sicherheitsabfrage ("Wollen Sie wirklich ...") aus der Sendung entfernt und wieder dieselbe Seite angezeigt.
    • Aktion "Ok" (Sendung bestätigen)
  • Anhand der ausgewählten Kombination aus Empfängerland, Produkt, Services und dem Abholstatus des Warenkorbes wird geprüft, ob ein passendes Produkt in der Produktliste existiert. Falls nicht, so wird dem Anwender erneut dieselbe Seite mit einer Fehlermeldung angezeigt.
  • Falls ein passendes Produkt bestimmt werden konnte, so wird die Sendung aktualisiert und wieder die Warenkorbseite NOW1 angezeigt.
    • NOW2: Gutschein-Details
  • Mit Hilfe dieser Seite können neue Gutschein-Sets in den Warenkorb gelegt werden. Der Anwender wählt zunächst ein Basisprodukt aus, wodurch die Dropdownliste mit den für dieses Basisprodukt erhältlichen Gutscheindefinitionen aktualisiert wird. Wählt er eine neue Gutscheindefinition, so wird analog die Dropdownliste mit den verschiedenen Stückelungen aktualisiert (unter Beachtung einer Vorgabe-Stückelung).
  • Zusätzlich wird im oberen Bereich der Seite eine Liste mit maximal 3 Einträgen angezeigt. Diese Einträge beschreiben die ersten drei der auch in der Dropdown-Liste angebotenen Gutscheindefinitionen zusammen mit der in der Gutscheindefinition hinterlegten Standard-Stückelung und dem zugehörigen Preis. Für jeden Eintrag wird eine Aktion "Jetzt kaufen!" angeboten.
  • Erreichbar von:
    • NOW1: Aktion "Gutschein hinzufügen"
    Aktion "Ok"
  • Legt das ausgewählte Gutschein-Set in den Warenkorb und springt wieder zu NOW1.
    • NOW3
  • Diese Seite enthält die vom Anwender erworbenen Marken in Form von Links auf die PDF-Dokumente sowie ggf. eine Liste von erworbenen Gutscheincodes. Sie wird nach erfolgreicher Bezahlung des Warenkorbes angezeigt. Alternativ kann der Benutzer über einen Link in seiner Bestätigungs-E-Mail wieder auf diese Seite gelangen.
  • Unter gewissen Bedingungen wird der Zugriff auf die Daten der Seite durch Eingabe einer PIN bzw. PIN2 abgesichert.
  • Erreichbar von:
    • NOW1: Aktion "Weiter zur Bezahlung"
    • NOW3-Login
  • Die Textdarstellung der PDF-Links auf der Seite wird auf folgende Weise zusammengestellt:
    • Text "Label",
    • Empfänger-Namel,
    • Empfänger-Name2,
    • Tagesdatum in der Form "31.12.2006",
    • Laufende Nummer,
    • Text "PDF".
      Diese Felder werden auf eine Einzellänge von jeweils 15 Zeichen gekürzt und mit "_" verbunden. Sonderzeichen und Umlaute werden ersetzt.
    • Header für Liste mit den Spaltenköpfen "Gedruckt", "Gutscheincode" und "Gutscheintyp":
      • o Ein "Häkchen", falls verbraucht
      • o Gutscheincode
      • o Gutscheintyp (Kurzbezeichnung aus der Gutscheindefinition)
    • Box "Per E-Mail erhalten und bequem zu Hause bearbeiten":
      • o Dynamisch eingeblendete E-Mail-Adresse mit einem Hinweis, dass die Unterlagen an diese Adresse gesendet wurden.
      • o Eine Warenkorb-ID mit dem Hinweis, diese bei Rückfragen an den Support griffbereit zu haben.
      • o Die PIN für den Warenkorb mit einem weiteren Hinweis, falls benötigt.
    • Einblendung des dynamischen Bausteins NOW3 (0) links unten
    • Box "Abholung" (falls im Warenkorb gebucht)
      • o Text "Sie haben eine Abholung Ihres Warenkorbes zum 30.12.2006 gebucht" (dynamisches Datum), gefolgt von der Abholadresse.
    • Alternativ zu Box "Abholung": Box "Befindet sich eine Packstation in Ihrer Nähe?"
      • o Falls nein, wird in der Box ein Text "Es kann leider keine Packstation in Ihrer Nähe gefunden werden" angezeigt.
      • o Falls ja, wird in der Box ein Text "Nutzen Sie die Vorteile der Packstation. Sie können Ihre Sendungen rund um die Uhr in Ihre Packstation einliefern", dahinter ein Link auf den Packstationfinder (externe Webseite). Dahinter wird die Adresse der gefundenen Packstation angezeigt.
    • Aktion: "Fenster schließen"
    NOW3-Login
  • Der Anwender kann über einen in der E-Mail enthaltenen Link auch später auf die Seite NOW3 gelangen. Übersteigt der Warenkorb einen gewissen Mindestwert, so wird dieser Zugriff über die Eingabe einer PIN bzw. PIN2 in der Maske NOW3-Login abgesichert
  • Nach Eingabe einer gültigen PIN oder PIN2 wird der Anwender auf die Seite NOW3 weitergeleitet. Im Fehlerfall erscheint eine Meldung innerhalb derselben Seite und der Anwender kann erneut seine Anmeldedaten eingeben.
  • Hinweis: Diese zusätzliche Absicherung des Warenkorbes wird ggf. erst in Phase II umgesetzt.
    • Bausteine
  • In Abhängigkeit von Uhrzeit und Marktplatz können verschiedene Bausteine in einer Webseite eingeblendet werden. Ein Baustein beschreibt hierbei eine rechteckige Teilfläche einer Webseite. Der Inhalt des Bausteines ist statisch.
  • In einer Weiterentwicklung der Darstellungsmethode können die Bausteine in ihrer Beschaffenheit auch lediglich durch Datenkonventionen beschrieben werden, so dass die Ausgestaltung der Bausteine selbst komplett durch einen Marktplatz erfolgen kann.
    • Mögliche Ausgestaltungsformen der Bausteine können sein: Portal -Baustein
  • Auf den Webseiten eines Marktplatz-Betreibers kann dynamisch ein Baustein von der POP-Anwendung geladen und in die eigenen Seiten eingebettet werden. Beispielsweise kann dieser Baustein einen einfachen Link auf die Warenkorb-Seite (NOW1) enthalten, über den ein Marktplatz-Kunde zur POP-Anwendung gelangen kann.
    • NOW1-Baustein
  • Dieser Baustein wird auf der Seite NOW1 unten links eingeblendet. Hier kann z.B. ein FAQ-Baustein vorkonfiguriert sein. Bei Klick auf eine Frage im Baustein wird ein Popup-Fenster mit dem FAQ-Text geöffnet.
    • NOW3-Baustein
  • Auf der Seite NOW3 wird unten links ein weiterer Baustein eingeblendet. Dieser ist separat zum vorherigen Baustein konfigurierbar, wird aber initial mit identischem Inhalt gefüllt sein.
    • E-Mail-Bestätigung
  • Ist der Warenkorb eines Anwenders abgegolten, so wird Ihm eine Benachrichtigung per E-Mail zugesandt. Diese E-Mail besteht aus folgenden Bestandteilen:
    • statischer Text,
    • ein einziger - mit einem eindeutigen Schlüssel versehener - Link auf die Seite NOW3; über diesen Link erfolgt die nachträgliche Zuordnung zum Warenkorb,
    • Warenkorb-Id für Support-Anfragen,
    • Zahlungsbestätigung über den Warenkorb analog Mehrwertsteuer-Popup,
    • falls vorhanden, ein Hinweis inklusive Adresse einer Packstation in der Nähe der ersten Sendungs-Absender-Adresse.
    Buchungstext
  • Auf dem Kontoauszug des Anwenders erscheinen folgende Angaben (beispielhaft) :
    • "Ihre Warenkorb-Id: ABCDEFGHKL," (31 Zeichen)
    • Optional: "Ihre PIN2: 9999," (17 Zeichen),
    • "Vielen Dank für die Nutzung von DHL Express" (43 Zeichen).
  • Es ergibt sich eine Summe von 101 Zeichen (Obergrenze PayPal: 127 Zeichen).
    • Einsprungspunkte in die Anwendung
  • Die POP-Anwendung kann über Maptos angesprochen werden, wobei initial die Seite NOW1 angezeigt wird. Alternativ ist der direkte Zugriff auf die Seite NOW3 - ggf. mit zusätzlicher Anmeldung über PIN oder PIN2 - über den Link in der Bestätigungs-E-Mail möglich.
    • Services
  • In der Anwendung sind folgende Services fest integriert (exemplarisch) :
    • Abholung TAS,
    • Rollenservice,
    • "Grün".
  • Der Service "Abholung TAS" kann nur komplett für den gesamten Warenkorb selektiert werden. Hier ist eine Angabe eines Abholdatums zwingend erforderlich. In einer Weiterentwicklung kann bei einer Abholung ferner ein Zeitfenster für die Abholung einer Postsendung ausgewählt werden.
  • Bei den restlichen Services werden keine weiteren Daten vom Anwender abgefragt, insbesondere auch keine Gewichte und Maße.
  • Services werden in der Datenbank hinterlegt. Einfache Services (ohne spezielle Logik) können nachträglich über Datenbankänderungen ohne Programmierung hinzugefügt werden. Hierbei ist jedoch zu beachten, dass abhängige Daten wie etwa Preise nachgepflegt werden müssen.
    • Service-Attribute
  • Ein einzelner Service wird vorzugsweise über folgende Attribute definiert.
    Figure imgb0001
    • Länder
  • Produkte (Kombinationen aus Basisprodukten und Services) können länderspezifisch administriert werden. Um nicht für jedes EU-Land identische Produkte definieren zu müssen, wird eine besondere Kennung "EU" eingeführt. Mittels einer im System hinterlegten Länderliste können dann Produkte mehreren Ländern gleichzeitig zugeordnet werden. Die Zuordnung "EU" wird jedoch nur so lange benutzt, wie kein Produkt einem "echten" Land zugeordnet ist.
    • Beispiel:
  • In einer fiktiven Länderpreisliste sind mehrere Produkt mit Länderkennung "EU" und ein einzelnes Produkt mit Länderkennung "AT" für Österreich definiert. Wird jetzt nach allen Produkten für das Empfängerland Österreich gesucht, liefert der eingesetzte Algorithmus nur ein Produkt zurück. Wird aus der Produktivliste das "AT"-Produkt entfernt, so liefert der Algorithmus alle Produkte mit Länderkennung "EU".
    • Adressen
  • Adressen werden in der Anwendung POP in folgenden Feldern abgelegt:
    • Name1,
    • Name2,
    • Straße,
    • Hausnummer,
    • Postleitzahl,
    • Ort,
    • Land.
      Adressen, die durch Maptos weitergegeben werden, enthalten kein separates Feld für die Hausnummer. Diese wird analog zur Leitcode-Bibliothek von Online Label Druck aus dem kombinierten Straße-Hausnummer-Feld abgespalten.
    Marktplätze
  • In der Anwendung können über das Admin-Web neue Marktplätze definiert werden. Bei den Marktplätzen handelt es sich beispielsweise um den dargestellten Provider.
  • Elemente wie
    • Bausteine,
    • Preise und
    • Gutscheine
    können marktplatzabhängig definiert werden. In der Session des Anwenders ist immer auch ein Marktplatz gesetzt.
    Figure imgb0002
     Positivliste
  • Die Positivliste enthält alle im System verfügbaren Produkte. Jede Zeile beschreibt ein einzelnes Produkt. Die "linke" Seite (Produktnummer, Produktname, Basisproduktangabe, Land) kann mehrmals vorkommen. Die rechten Seiten der Tabellenzeilen geben dann alle gültigen Kombinationen an Services an, die dieser "linken Seite" zugeordnet werden können. Jede Zeile beinhaltet immer auch das Basisprodukt selbst.
  • Es ist zweckmäßig, die Liste so zu gestalten, dass sie für alle Marktplätze gilt. Vorzugsweise sind die Liste und das System so aufeinander angepasst, dass nicht enthaltene Kombinationen ungültig sind.
  • Die folgende Tabelle beschreibt die Spalten, aus welchen die Positivliste aufgebaut ist.
    Figure imgb0003
    • Ein verkürztes Beispiel einer Positivliste:
  • Figure imgb0004
  • In jeder Zeile können über eine Liste von Iso-Codes (3-stellig analog Maptos) ein oder mehrere Länder referenziert werden.
  • Das spezielle Kürzel "EU" steht für alle EU-Länder (diese sind in einer Liste hinterlegt).
    • Produkt-Attribute
  • Neben den Preisangaben sind jeder Zeile der Positivliste noch weitere Attribute zugeordnet:
    • Produktschlüssel (zur Verbesserung der Entgeltsicherung).
    • Produktschlüssel ESI,
    • Produktcode (Bestandteil des Leitcodes, 2-stellig),
    • Verfahrensnummer (ESI und Labeldruck),
    • Teilnahme (ESI und Labeldruck),
    • ProductcodeLabel (für Labeldruck erforderlich),
    • ServicecodeLabel (für Labeldruck erforderlich),
    • Featurestringlabel (für Labeldruck erforderlich),
    • Sortierschlüssel; bestimmt die Reihenfolge der Anzeige bzw. welches Produkt als Default benutzt wird.
    Produktauswahl nach Land
  • Auf der Seite NOW2 kann die Auswahl der Produkte abhängig vom Empfängerland vorgenommen werden: es werden nur die Produkte angeboten, die diesem Land zugeordnet sind.
    • Hierarchische Daten
  • Elemente wie
    • Preise,
    • Bausteine,
    • Gutscheindefinitionen und
    • Rabatte
    können auf der Ebene von
    • Marktplatz-Aktionen (gültig für genau einen Marktplatz und einen konfigurierbaren Zeitraum),
    • eines Marktplatzes (gültig ohne Zeitfenster für genau einen Marktplatz) oder
    • vollkommen Marktplatz-unspezifisch (gültig für jeden Marktplatz ohne Zeitfenster)
    definiert werden, wobei die "höhere" Definition maßgeblich ist, auch wenn weitere Preise oder Bausteine existieren. Die Elemente der Marktplatz-unspezifischen Ebene sind Pflichtelemente, die der beiden anderen Ebenen sind optional.
  • Objekte, die diese Vorgehensweise unterstützen, sind mit einem MZF-Header (Marktplatz-ZeitFenster) versehen, der folgende Attribute umfasst:
    Figure imgb0005
  • Ist beispielsweise für den aktuellen Zeitpunkt keine Marktplatz-Aktions-Preis für "Päckchen D" definiert, wir nach einem Marktplatz-Preis für "Päckchen D" gesucht. Ist auch dieser nicht definiert, so wird der Preis in der Marktplatzunabhängigen Preisliste verwendet.
  • Informationen, die auf diese Weise abgelegt sind, werden nicht internationalisiert. Im Zweifelsfall kann dies über eine marktplatz-abhängige Konfiguration abgebildet werden.
    • Preise
  • Für die Produkte in der Positivliste können Teilpreise definiert werden, und zwar für Kombinationen aus
    • Basisprodukt und Land ("Päckchen D"),
    • Service und Land ("Rollenservice D").
  • Der Gesamtpreis einer Produktzeile ergibt sich dann zunächst aus der Summe der Einzelpreise.
  • Die Default-Preisliste (marktplatz-unabhängig) kann folgendermaßen aussehen:
    Figure imgb0006
    Figure imgb0007
  • In dieser Liste muss jedes Basisprodukt und jeder Service - mit Ausnahme der TAS-Abholung -, als "land-loser" Eintrag mit einem Preis versehen sein. Alle anderen Einträge sind optional. Falls beispielsweise kein Preis für (Päckchen, DEU) definiert wäre, würde der Preis von (Päckchen,*) als Vorgabe benutzt.
  • Diese Liste kann mehrfach für verschiedene Ebenen definiert werden. Für die anderen beiden Ebenen sind alle Preisangaben optional, d.h. hier können Preise definiert sein, müssen aber nicht. Dieses Verfahren stellt sicher, dass zu beliebigen Kombinationen aus (Basisprodukt, Land) bzw. (Service, Land) ein Preis bestimmbar ist.
  • Über eine geeignete Suchreihenfolge kann zu jeder Zeile der Positivliste (und ggf. abhängig vom Marktplatz und einem Zeitpunkt) ein eindeutiger Preis berechnet werden. Dieser ist einfach die Summe des Preises für das Basisprodukt+Land und die zugeordneten Services+Land.
  • In einer Weiterentwicklung kann ein detaillierteres Preismodell umgesetzt werden, in dem auch einzelne Zellen der Positivliste mit Preisen versehen werden können ("Produkt/Service-Kombipreise").
    • Beispiel
  • Zusätzlich zur Default-Preisliste oben sind zwei weitere Preislisten definiert. Zuerst spezialisierte Preise für den Marktplatz Provider:
    Figure imgb0008
  • Für eine Marketingaktion auf dem Marktplatz Provider in der Kalenderwoche 50 wird ein spezieller Preis für ein Päckchen DEU definiert (Begin und Ende des Zeitraumes können minutengenau angegeben werden):
    Figure imgb0009
    • Beispiel-Ergebnisse I
  • Suchkriterien:
    • Der aktuelle Zeitpunkt (die Serverzeit ist hier maßgeblich) befindet sich in der KW 49, d.h. dass außerhalb des Zeitraumes, für den Tabelle III gültig ist.
    • Das Zielland der exemplarischen Sendung ist Deutschland (DEU).
    • Der Marktplatz des Anwenders ist Provider
  • Die folgende Tabelle enthält die Teilpreise für das Produkt Päckchen+Rollenservice und Paket 10kg:
    Figure imgb0010
  • Beispiel-Ergebnisse I (die römischen Ziffern hinter den Preisen geben die Preistabelle an, die jeweils zur Anwendung kommt).
    • Beispiel-Ergebnisse II
  • Die Suchkriterien werden wie oben gewählt, jedoch die aktuelle Serverzeit als ein angebbares Zeitfenster, beispielsweise ein Tag, eine Woche oder ein Monat.
  • Die folgende Tabelle enthält die Teilpreise für das Produkt Päckchen+Rollenservice und Paket 10kg:
    Figure imgb0011
  • Beispiel-Ergebnisse II (die römischen Ziffern hinter den Preisen geben die Preistabelle an, die jeweils zur Anwendung kommt).
    • Preis-Attribute
  • Die folgende Tabelle beschreibt die Attribute eines einzelnen Preises:
    Figure imgb0012
    • Abholung und Abholpreis
  • Eine Abholung erfolgt für Teile des Warenkorbes oder, was besonders bevorzugt ist, für den gesamten Warenkorb.
  • Die Buchung der Abholung geschieht explizit auf der Seite NOW1 oder implizit durch die Eingabe eines Gutscheincodes, der eine TAS-Abholung beinhaltet.
  • Durch die Beifügung des Gutscheincodes an eine Postsendung oder durch eine Übermittlung des Gutscheinscodes an einen ersten Empfänger einer Postsendung ist es möglich, Retourenlabel zu erzeugen. Durch die Erzeugung von Retourenlabeln wird die Erfindung zu einem Verfahren zur Handhabung von Retouren weitergebildet.
  • Die Preise für die Abholung werden gestaffelt (maximal 5 Einträge) angegeben, beispielsweise wie in folgender Tabelle:
    Figure imgb0013
  • Es wird die Anzahl aller abholfähigen Sendungen (anhand Positivliste) im Warenkorb benutzt, um den Preis in der Tabelle zu finden. Bei mehr als 5 Sendungen wird der letzte Preis der Tabelle benutzt (nach der Beispieltabelle ist also eine Abholung ab 5 Sendungen immer kostenlos - wobei es sich hier um eine exemplarische Darstellung handelt).
    • Definition der Staffelung
  • Die Preisstaffelung für die Abholung kann analog zu den anderen Preisen hierarchisch angegeben werden.
    Figure imgb0014
    • Bausteine
  • Bausteine stellen einen rechteckigen Bereich auf einer Webseite dar und können hierarchisch konfiguriert werden. Sie enthalten ein HTML-Fragment, welches ggf. wiederum einzelne Images, css-Files etc. referenzieren kann. Bausteine werden über einen logischen Namen angesprochen.
    Figure imgb0015
    • Gutscheine
  • Über den Verkauf von Gutscheinen auf der Webplattform in Paketen sollen dem Kunden Preisvorteile eingeräumt werden können. Weiter sollen spezielle Marketingaktionen möglich sein, in deren Rahmen Gutscheine bzw. deren Codes beispielsweise über Printmedien verteilt werden.
    Figure imgb0016
    Figure imgb0017
    • Gutscheindefinition
  • Bevor Gutscheine vom Anwender gekauft oder im Rahmen von Marketingaktionen verteilt werden können, müssen auf administrativer Ebene Gutscheine definiert werden.
    • Gutscheinname
  • Gutscheindefinitionen werden über ihren bei der Anlage frei vergebbaren, aber möglichst eindeutigen Namen (Screenname) angesprochen.
    • Gutscheintyp
  • Bei der Anlage der Gutscheindefinition wird festgelegt, ob es sich um einen Promotionsgutschein oder um einen vom Anwender käuflich zu erwerbenden Gutschein (Code) handelt.
    • Produktreferenz
  • Bei der Definition eines Typs wird genau ein Produkt der Positivliste referenziert. Diese Angabe bestimmt, ob ein Gutschein auf eine Sendung angewandt werden kann:
    • Stimmen die Basisprodukte überein und sind alle Services des referenzierten Produktes im Sendungsprodukt enthalten, so ist ein Anwenden möglich. Eine gewählte Sendung kann damit mehr Services enthalten als im referenzierten Produkt definiert, jedoch nie weniger.
    Wert eines Gutscheines
  • Ein Gutschein kann entweder einen absoluten Geldbetrag darstellen ("Wert 10 Euro") oder genau für das Produkt einlösbar sein, für welches er hinterlegt ist (100%-Gutschein).
  • Die Verrechnung erfolgt dann nur für diese Bestandteile, d.h. sich eventuell durch die Gutscheinverrechnung ergebende negative Preise werden auf den Preis 0 Euro abgebildet.
    • Beispiel:
  • Der 100%-Gutschein deckt das Produkt "Paket inklusive TAS-Abholung" ab, für die Sendung im Warenkorb ist das Produkt "Paket mit TAS-Abholung und Rolle" vom Anwender ausgewählt. Als Folge muss der Anwender nur noch den Service "Rolle" bezahlen.
  • Der "Wert" eines Gutscheines kann unvollständig ausgeschöpft werden, beispielsweise wenn ein Gutscheinpreis über dem aktuell gültigen Preis für "abgedeckte" Produkte liegt; der Restwert des Gutscheines verfällt in diesem Fall.
    • Stückelung (nur für Kaufgutschein)
  • Der Anwender kann Gutscheine in Paketen kaufen. Hierzu kann eine Stückelung mit bis zu 5 verschiedenen Stückelungsgrößen definiert werden (z.B. "5er, 10er, 20er, 50er, 100er"). Für jede Stückelungsgröße wird ein separater absoluter Preis inklusive Umsatzsteuerangabe definiert. Eine der Stückelungen wird als Vorgabewert definiert.
    • Gültigkeit für Verkauf
  • Über ein Zeitfenster wird definiert, in welchem Zeitraum der Gutschein dem Anwender zum Kauf angeboten wird. Das Ende des Zeitfensters kann begrenzt oder unbegrenzt sein.
    • Informationen zur Einlösbarkeit
  • Käuflich erwerbbare Gutscheine können erst nach dem Kauf eingelöst werden, d.h., erst nachdem sie bezahlt worden sind und dem Anwender in Form von Gutscheincodes vorliegen.
  • Über ein Zeitfenster wird festgelegt, in welchem Zeitraum ein einzelner Gutscheincode eingelöst werden kann. Entweder ist dies eine relative Angabe in Tagen ("maximal 30 Tage nach Kauf einzulösen") oder ein absolutes Datum ("bis 31.12.2007").
  • Kaufgutscheine können immer nur einmal benutzt werden. Bei Promotionsgutscheinen kann alternativ angegeben werden, ob die Codes beliebig oft nutzbar sind. Diese sind dann auch für ein oder mehrere Sendungen innerhalb eines einzelnen Warenkorbes einlösbar.
  • Beispielsweise können für Printaktionen Gutscheine erzeugt werden, die beliebig oft nutzbar sind. Alternativ können für E-Mail-Aktionen auch Promotionsgutscheine erzeugt werden, die analog zu Kaufgutscheinen nur einmalig benutzbar sind.
  • Unabhängig vom Gutscheintyp gilt jedoch immer, dass pro Sendung nur maximal ein Code einlösbar ist.
    • Markplatz
  • Optional kann ein Gutscheintyp einem einzelnen Marktplatz zugeordnet werden. Die Gutscheine werden dann nur auf diesem Marktplatz zum Kauf angeboten. Die gekauften Gutscheincodes sind ausschließlich auf diesem einen Marktplatz einlösbar.
    • Anzeige-Sortierung
  • Jedem Gutschein ist eine numerische Sortierzahl zugeordnet, über die die Anzeige-Reihenfolge bestimmt werden kann.
    • Gutscheincodes
  • Gutscheincodes werden entweder beim Kauf eines Gutscheinsets oder bei der Generierung von Promotionscodes über das Admin-Web erzeugt.
  • Ein einzelner Gutschein ist über diesen eindeutigen alphanumerischen Bezeichner (Gutscheincode) definiert, der nicht ohne weiteres erratbar sein sollte. Der Code ist mit zugehörigen Daten im System hinterlegt.
  • Als Bestandteil des 8-stelligen Gutscheincodes sind folgenden 31 Zeichen gültig:
    • Ziffern "2" bis "9" und die
    • Buchstaben "A"-"H", "K"-"N", "P"-Z"
      Dies ergibt eine theoretische Menge von 852.891.037.441 (ca. 850 Milliarden) Gutscheincodes. Kollisionen, d. h. mehrfache Verwendung desselben Codes und die Erratbarkeit eines fremden Codes, soll somit verhindert werden.
    Warenkorb-ID
  • Jeder neu erstellte Warenkorb ist mit der Generierung einer eindeutigen numerischen Warenkorb-ID verbunden. Diese wird dem Kunden auf der Seite NOW3 angezeigt. Außerdem erscheint sie bei erfolgreicher Buchung auf dem Kontoauszug des Anwenders. Anhand dieser ID können Anwender beispielsweise bei telefonischen Support-Nachfragen ihren Warenkorb referenzieren.
    • Validierungen vor der Anzeige von NOW1
  • Diese Prüfungen werden jedes Mal vor Anzeige der Warenkorb-Seite NOW1 durchgeführt. Status- und Fehlermeldungen werden sendungsbasiert oder für den ganzen Warenkorb angezeigt.
    • Jede Sendung wird überprüft, ob sie fehlerfrei ist; dies wird ggf. über Status-Informationen in der Sendungsposition optimiert. Die pro Sendung angezeigten Informationen und Fehlermeldungen werden aktualisiert.
    • Bei gebuchter TAS-Abholung wird überprüft, ob der Abholzeitpunkt noch gültig ist und die Abhol-Adresse TAS-leitcodierbar ist, falls dies noch nicht geprüft wurde. Im Fehlerfall wird dem Anwender eine warenkorb-bezogene Fehlermeldung auf NOW1 angezeigt.
    Gutschein einlösen
  • Wird ein Gutscheincode für eine Sendung eingelöst, so wird anhand der in der Datenbank hinterlegten Daten überprüft, ob er gültig ist:
    • Ist der Code überhaupt ein gültiger Code, d. h. in der Datenbank vorhanden?
    • Passt der hinterlegte Gutscheintyp zum Produkt der Sendung, d.h. ist das Sendungsprodukt in der Positivliste des Gutscheintyps enthalten?
    • Ist der Gutschein nicht bereits abgelaufen ("Haltbarkeit")?
    • Bei Einmal-Gutscheinen:
      • Ist der Gutschein nicht bereits eingelöst worden (sowohl im aktuellen Warenkorb als auch in der Datenbank)?
    Warenkorb bezahlen
  • In diesem Absatz werden die Vorgänge beschrieben, die durchgeführt werden, wenn der Anwender auf der Seite NOW1 die Aktion "Weiter zur Bezahlung" ausführt.
    • Grundsätzliche Validierungen
  • Zuerst werden die Prüfungen wie in Paragraph 0 beschrieben durchgeführt. Falls diese oder eine der folgenden Bedingungen nicht erfüllt ist, wird dies dem Anwender in Form eines Fehlertextes auf der Seite NOW1 angezeigt.
    • Ist der Warenkorb leer?
    • E-Mail-Adresse erfasst und plausibel (Regular-Expression-Validierung)?
    • ABGs akzeptiert?
    • Falls der Preis des Warenkorbes nicht "0" ist (beispielsweise alle Sendungen über Gutschein abgegolten):
      • o Payment-Art ausgewählt? Ggf. auch BLZ erfasst?
      • o Liegt der Wert des Warenkorbes innerhalb des für den Marktplatz und Payment-Art konfigurierten Bereichs?
    • Falls eine TAS-Abholung gebucht ist:
      Validierung der Empfänger-Adressen (Anforderung der TAS-Schnittstelle; kann in einem Aufruf für n Adressen erfolgen).
    • Sind eingelöste Gutscheincodes immer noch gültig? (Diese Validierung wird zwar bereits bei der Eingabe der Codes durchgeführt, hier aber sicherheitshalber wiederholt, da der Code in einer anderen Session ebenfalls verwendet werden konnte.)
    • Hat sich der Warenkorb-Preis im Vergleich zur letzten Preisberechnung und dem aktuell neu berechneten Preis verändert? Falls ja, werden dem Anwender die aktualisierten Preise in NOW1 mit einem Hinweistext angezeigt, worauf er erneut die Bezahlaktion anstoßen kann.
    Vorbereitung der Bezahlung
  • Die Vorprüfungen haben ergeben, dass die Daten des Warenkorbes gültig sind und der Bezahlvorgang vorbereitet werden kann.
  • Hieran schließt sich ein Persistieren der Warenkorb-Daten in der Datenbank als weiterer Schritt an.
  • Ist dieser Schritt fehlerfrei verlaufen und ist der Preis des Warenkorbes nicht "0", so wird der Anwender auf die Seiten des Payment-Providers weitergeleitet (Redirect-Anweisung an den Web-Browser des Anwenders).
  • Bricht er dort den Bezahlvorgang ab, so wird er wieder auf die Seite NOW1 geleitet, bekommt dort eine entsprechende Meldung angezeigt und kann den Warenkorb weiterhin bearbeiten.
  • Ist der Bezahlvorgang erfolgreich durchgeführt worden, so geht es mit dem nächsten Schritt weiter.
    • Aktionen unmittelbar nach Bezahlung
  • Nach erfolgreicher Bezahlung bekommt POP eine Rückmeldung vom Payment-System. Anschließend werden folgende Aktionen durchgeführt:
    • Warenkorb-Daten als bezahlt markieren,
    • Gutscheincodes verbrauchen,
    • Daten für PDF-Generierung ablegen; Document-IDs generieren; Nummern aus Nummernkreisen entnehmen,
    • ggf. TAS-Abholungen beauftragen,
    • Umschlagdaten für EDICC in DB ablegen,
    • E-Mail an den Anwender versenden.
  • Treten während dieser Schritte Fehler auf, so versucht die Anwendung trotzdem, möglichst alle weiteren Schritte durchzuführen. Ein Rollback wird nicht durchgeführt, da die Schnittstellen teilweise keine Stornomöglichkeiten zur Verfügung stellen. Warnungen und Fehlermeldungen, die während dieser Prozesse auftreten, werden natürlich persistent in die Datenbank abgelegt.
    • PIN / PIN2
  • In der BestätigungsE-Mail des Anwenders ist ein Link mit angehängtem Schlüssel eingebettet, über den er die Seite NOW3 auch nachträglich öffnen kann. Falls der Warenkorb einen gewissen Wert übersteigt, wird dieser Zugang zusätzlich über die Eingabe einer PIN bzw. PIN2 abgesichert (jeweils vierstellige numerische Werte). Die PIN bekommt der Anwender unmittelbar nach Erwerb des Warenkorbes auf der Seite NOW3 - versehen mit einem entsprechenden Hinweistext - angezeigt. Alternativ kann er auch die PIN2 eingeben, die er auf seinem Kontoauszug finden kann.
    • PDF Label
  • Die Anwendung "PDF Label" erzeugt PDFs mit Labeln, die vom Nutzer ausgedruckt und auf die Sendung (Päckchen, Paket, etc.) geklebt werden kann.
  • In einer bevorzugten Ausführungsform hat das PDF folgende Bestandteile:
    • Das eigentliche Postage-Label: Label
      • o als Musterdruck und
      • o als Portodruck.
    • Einlieferbeleg.
    • Ein elektronischer bzw. PDF-Umschlag um das Postage-Label, der den Einmaldruck steuert.
    Produktabhängige Label
  • Zu jeder Produkt- Service- Kombination kann - aber muss nicht
    • in der Anwendung eine entsprechende PDF-Vorlage für die Erzeugung des Labels hinterlegt werden.
    Felder des Labels
  • Die folgende Aufteilung der Bestandteile entspricht der Fachspezifikation Common Label.
    • Produkt / Logo-Block
  • Der Produkt/Logo-Block enthält ein Logo eines Unternehmens und den Produktnamen des Basisprodukts. Der Produktname wird der aus der Produktkonfiguration ermittelt.
    • Absenderblock
  • Der Absenderblock entspricht der Common Label Spezifikation in der nachfolgenden Tabelle:
    Feldname Typ Beschreibung
    Name, Zusatz String (35) 2 Zeilen Vor- und Nachname Firmennamen
    Strasse, Hausnummer String (35)
    PLZ Stadt String (35) Das Land wird von der Anwendung nicht eingedruckt.
    Land String (35) Land in Großbuchstaben
  • Ist ein Datenfeld zu lang für die von der Common Label Spezifikation vorgesehene Anzahl der Zeichen, wird der Eindruck rechts abgeschnitten.
    • Empfängerblock
  • Der Empfängerblock entspricht der Common Label Spezifikation in der nachfolgenden Tabelle:
    Feldname Typ Beschreibung
    Name, Zusatz String (35) 2 Zeilen Vor- und Nachname Firmennamen
    Strasse, Hausnummer String (35)
    PLZ Stadt String (35)
    Land String (35) Land in Großbuchstaben
  • Es gelten die gleichen Einschränkungen wie bei dem Absenderblock.
    • Produkteigenschaftsblock
  • In den Produkteigenschaftsblock können produktspezifische Zeichen eingedruckt werden. Der Inhalt des Eindrucks wird pro Produkt konfiguriert.
    • Sendungsinformationen-Block
  • Im Sendungsinformationen-Block werden folgende Informationen eingedruckt:
    Feldname Typ Beschreibung
    Billing No String Enthält EKP-Nummer+Teilnahme+Verfahren EKP-Nummer ist für die Kombination von Paymentplattform und Marktplatz in der Anwendung konfiguriert. Teilnahme ist immer "00" Verfahren ist pro Produkt in der Anwendung konfiguriert.
    Shipment No. String Enthält Identcode der Sendung
    Dimension/Weight String Dimension: Wenn zu der Sendung entsprechende Daten von Maptos geliefert werden, werden diese befüllt. Weight: Wenn zu der Sendung entsprechende Daten von Maptos geliefert werden, werden diese befüllt. Andernfalls wird ein pro Basisprodukt konfiguriertes Standardgewicht eingedruckt
    • Kundeninformationen-Block / 2D-Barcode-Block
  • Der Kundeninformationen-Block wird von der Anwendung nicht verwendet.
  • Es ist vorteilhaft, einen Einlieferbeleg zu erstellen.
  • Dieser Einlieferbeleg weist ein übliches Papierformat (beispielsweise DIN A 6 bis DIN A 4) auf. Bevorzugte Daten des Einlieferbeleges sind:
    Feldname Beschreibung
    Identcode Identcode (IDC) Numerisch
    Empfänger Empfänger Adresse (Name, Straße, Nummer, PLZ, Ort, Land)
    Produkt Name des Produktes, siehe Produkt / Logo-Block.
    Gewicht Gewicht der Sendung in kg. Siehe Sendungsinformationen-Block
    Services Services aus dem Handlinginformationenblock
    Nachnahme Betrag und Währung, Projektphase I leer
    Datum Aktuelles Datum (Druckdatum)
    Name des Auftraggebers Absender (Name)
    EKP-Nummer EKP-Nummer. Sendungsinformationen-Block.
    Warenkorbnummer Anwendungseigene Nummer für einen Warenkorb/Bezahlaktion.
    • Allgemein
  • Bei einer Weiterbildung der Erfindung wird das zu druckende Label wird mit einem PDF-Umschlag versehen. Innerhalb dieses Umschlags wird in Kommunikation mit einem Lizenzservice der Druck des in dem PDF-Umschlag enthaltenen Dokumentes gesteuert. Zur Berücksichtigung hiervon werden diese Dokumente in der vorliegenden Anmeldung als iPDF bezeichnet.
  • Folgende Prozessschritte werden hierbei vorgenommen:
    • POP-Anwendung:
    • Während der Generierung (oder eventuell auch im Vorfeld) des PDF wird jedes PDF mit einer eindeutigen, durch den Nutzer nicht durch Ausprobieren zu erratende Dokument-ID verknüpft.
  • Diese Dokument-ID wird einerseits in das iPDF 'eingebettet', andererseits auch in einer Datenbanktabelle der POP-Anwendung eingefügt.
  • Fig. 3 zeigt eine schematische Darstellung einer Integration einer Dokumentenerzeugung in ein erfindungsgemäßes System.
  • Das dargestellte System beinhaltet einen Server, der eine Übertragung darstellbarer Inhalte ermöglicht.
  • Die darstellbaren Inhalte bestehen aus statischen Inhalten und dynamischen Inhalten.
  • In der dargestellten Ausführungsform werden die statischen Inhalte als PDF-Templates in ein zu erzeugendes Dokument eingebracht.
  • Dynamische Inhalte werden von einem geeigneten Server, vorzugsweise einem POP-Web-Server 302 in einen Dokumentendatensatz 303 eingebracht. Diese dynamischen Inhalte werden ggf. durch weitere Inhalte ergänzt. Bei den weiteren Inhalten kann es sich - je nach beabsichtigtem Einsatz - um statische Inhalte oder um dynamische Inhalte handeln. Eine Hinzufügung von dynamischen Inhalten ist bevorzugt, da sich hierdurch auf eine besonders einfache und zweckmäßige Weise identifizierbare Dokumente erstellen lassen.
  • Dies geschieht in einer besonders bevorzugten Ausführungsform der Erfindung dadurch, dass die dynamischen Inhalte mit Lizenzierungsinformationen 304 verknüpft werden.
  • Nachfolgend wird die Erfindung am Beispiel der Erzeugung von Labeln erläutert. Bei den Labeln handelt es sich beispielsweise um Adresslabel und/oder Frankierlabel. Derartige Label eignen sich insbesondere für eine Steuerung logistischer Vorgänge, beispielsweise Tracking und Tracing sowie für die Steuerung logistischer Prozesse beispielsweise für die Sortierung von Postsendungen.
  • Für diesen Zweck sind die Label vorzugsweise maschinenlesbar ausgestaltet.
  • Das zu druckende Label wird mit einem PDF-Umschlag versehen. Innerhalb dieses Umschlags wird in Kommunikation mit dem Server eine Übertragung der Lizenzierungsinformationen 304 ermöglicht.
  • Durch Einbeziehung der Lizenzierungsinformationen 304 wird somit ein Lizenzservice für den Druck des PDF-Umschlages bereitgestellt. Der Lizenzservice steuert den Druck des in dem PDF-Umschlag enthaltenen Dokumentes.
  • Da auf diese Weise intelligente Dokumente bereitgestellt werden, werden sie nachfolgend als iPDF bezeichnet.
  • Folgende Prozessschritte werden hierbei vorgenommen:
    • POP-Anwendung:
    • Während der Generierung (oder eventuell auch im Vorfeld) des PDF wird jedes PDF mit einer eindeutigen, durch den Nutzer nicht durch Ausprobieren zu erratende Dokument-ID verknüpft.
  • Diese Dokument-ID wird einerseits in das iPDF 'eingebettet', andererseits auch in einer Datenbanktabelle der POP-Anwendung eingefügt.
  • Für die Umsetzung der Verhinderung von Mehrfachdrucken werden innerhalb des zum Anwender gelieferten PDFs Mechanismen eingebaut, die vor jedem Druck überprüfen, ob das Dokument bereits einmal gedruckt wurde.
  • Für diese Überprüfung muss aus dem Acrobat Reader eine Verbindung mit einem von der POP Anwendung gestellten Service aufgenommen werden, über die diese Überprüfung vorgenommen wird.
  • Nachdem der Nutzer über die Bezahlfunktionalität der Anwendung ein Produkt gekauft hat, sind auch alle Daten für die Generierung der PDFs vorhanden.
  • Zu diesem Zeitpunkt generiert die Serveranwendung für jedes aus dem Warenkorb zu generierenden PDF einen Datensatz, in dem alle für die Generierung notwendigen Angaben bereits vollständig aufgelöst sind.
  • Ein für die Kontrolle des Einmaldrucks vorteilhafter Datensatz ist nachfolgend dargestellt.
    • Dokumenten-Datensatz
  • Feldname Typ Beschreibung
    Dokument-ID ID (PK) ID des Dokumentes. Diese ID ist auch im dem ausgelieferten iPDF-Umschlags eingebettet.
    CreateDate TimeStamp Zeitstempel der Erzeugung der PDF
    ValidUntil TimeStamp Gültig bis
    Printed TimeStamp Wurde das PDF bereits gedruckt.
    DownloadedFirst TimeStamp Wann wurde das PDF erstmals geladen.
    DownloadedLast TimeStamp Wann wurde das PDF zuletzt geladen.
    DownloadCounter Integer Wie oft wurde das PDF geladen.
    FormularData Blob Die Formulardaten des PDF. Hierunter fallen: Absender- und Empfängeradressen. Codes für Barcodes. Produkt-Vorlagen (z.B. Paket grün) Informationen zu gewählten Zusatzservices, soweit diese den Eindruck betreffen.
  • FormularData hält in einer strukturierten Form (XML) bezüglich der einzudruckenden Daten alle bereits aufgelösten Daten. So werden z. B. die bereits generierten Päckchen-Identifizierer, Leitcodes und evt. weitere Angaben (auch Preise, auch wenn dies zurzeit nicht vorgesehen ist) bereits als Zahlen oder Zeichenketten vorgehalten. Eine nachträgliche Berechnung solcher Daten ist nicht vorgesehen, da diese evtl. zu anderen Ergebnissen kommen könnte.
  • Weiterhin müssen in diesem FormularData-Feld Referenzen auf die PDF-Vorlage sowie die Koordinaten für den Eindruck vorgehalten werden. Hierfür werden Ressourcen-IDs aus dem Konfigurations-Repository verwendet. Da sich die hinter einer Ressourcen-ID stehende Ressource während der Lebenszeit der Anwendung (sprich auch bei geänderter Version durch Änderung der Anwendungskonfiguration) nicht ändert, wird eine Generierung des PDF stets zu gleichen Ergebnissen kommen.
  • Auf die dargestellte Weise ist es möglich, PDFs oder andere intelligente Dokumente im Sinne der Erfindung anhand eines Dokumenten-Datensatzes zu generieren. Der Dokumenten-Datensatz hat beispielsweise die zuvor dargestellten Feldinhalte.
  • Nach Aufruf einer geeigneten Aufforderung kann dem Nutzer über eine URL eine Dokument-ID für den späteren Download in Form einer URL zur Verfügung gestellt werden.
    • Beispiel: http://pop.dhl.de/getPDF?documentId=abxkd12fszo8afwg30y
  • Anhand der Dokument-ID kann direkt ein PDF erzeugt werden.
  • Da das vom Nutzer downgeloadete Dokument lediglich ein leeres Formular darstellt, kann ein allgemeines - eventuell für jedes Produkt (Produktschlüssel) individuelles - PDF zur Verfügung gestellt werden.
  • Das Servlet, das das PDF ausliefert, muss nun lediglich den Dateinamen für das PDF so umbenennen, dass die Dokument-ID im Dateinamen enthalten ist.
    • Signieren des Dokumentes über ARES 306
  • Die Vorlagen werden offline während der Entwicklung bzw. Vorbereitungsphase für ein neues Produkt durch den Acrobat Reader Extension Server signiert.
  • Das durch ARES 306 signierte Dokument wird dann in der Anwendung in das Konfigurations-Repository eingespielt.
    • iPDF Umschlag, Muster- und Portodokument
  • Nachdem der Anwender das generierte PDF heruntergeladen hat, wird ihm auf der ersten Seite der Umschlag des PDF angezeigt.
  • Es ist vorteilhaft bei dem Laden des PDFs in einem geeigneten Leseprogramm, insbesondere einem Acrobat Reader einzelne, mehrere oder sämtliche folgender Prüfschritte vorzunehmen:
    • Kompatibilität des Leseprogramms
    • Bestehen einer Internetverbindung
    • Gültigkeit der Dokumenten-ID
    • Überprüfung, ob bereits ein Ausdruck erfolgte.
  • Für die letzten beiden Prüfungen wird über die SOAP-Schnittstelle des Acrobat Readers ein von der Anwendung zur Verfügung gestellter Service aufgerufen, der zurück gibt, ob die übermittelte Dokumenten-ID vorhanden ist und/oder bereits als gedruckt in der Datenbank markiert wurde.
  • Mittels der Dokument-ID werden dann die Formularfelder über die SOAP-Schnittstelle vom POP-eigenen Server geladen und in die Formularfelder gefüllt.
  • Konnte die Dokumenten-ID nicht ermittelt werden - z.B. da der Anwender das PDF-Dokument umbenannt hatte -, wird er über ein Acrobat Formfeld aufgefordert, die Dokumenten-ID einzugeben. Die Dokumenten-IDs werden dem Nutzer in der ihm zugesendeten E-Mail zusätzlich mitgeteilt.
  • Für den Musterdruck werden für die Barcodes Dummy-Codes verwendet. Die korrekten Barcodes werden erst für den Portodruck durch JavaScript kurzzeitig gesetzt.
    • Verwendete PDF-Reader Funktionalität (Technologie)
  • Für die dynamische Abfrage des Lizenzservers aus dem Acrobat Reader heraus nutzt die Anwendung folgende JavaScript-Funktionen:
    • app.viewerVersion: Für das Überprüfen der Reader-Version.
    • SOAP.*: Für das Prüfen auf Internetverbindung.
    • document.getField("feldname").display = display.hidden /display.visible: Für das Ein- und Ausblenden von "Muster" Überdrucken.
    • document.print({bUI: true, nStart: 1, nEnd: 1, bSilent: true, bAnnotation: true}) bzw. document.print({bUI: false, nStart: 1, nEnd: 1, bSilent: true, bAnnotation: true}): Für das direkte Drucken des Dokumentes ohne Nutzerinteraktion.
    • Die eigentlich zu druckenden PDFs werden als Annotation-Formfelder hinterlegt (ursprünglich für ein visuelles Feedback - z.B. beim Drücken eines Buttons - gedacht, um zwischen gedrücktem und nicht gedrücktem Zustand zu unterscheiden) und nur unmittelbar vor dem Druck auf "visible" geschaltet.
    • Barcode-Felder. Der Acrobat Reader unterstützt Formfelder, die zu einem Wert (i.d.R. Zahlenwert) einen entsprechenden Barcode anzeigen.
    • Alternativ können für Barcode-Felder spezielle Fonts verwendet werden, die im dem Dokument eingebettet werden.
    • Für Barcodetypen, die der Acrobat Reader weder intern, noch durch zusätzliche Schriftarten unterstützt, kann der Barcode als Bitmap-Image über eine externe URL geladen werden. Hierzu müsste in der Anwendung ein Servlet-Service implementiert werden, der das entsprechende Bitmap generiert und zur Verfügung stellt.
  • Die dargestellten Funktionalitäten weisen mehrere Vorteile auf:
  • Da der Nutzer keine individualisierten PDF downloaded, müssen die PDFs nur pro Template/Produkt über den ARES-Server signiert werden.
  • Das hat zur Konsequenz, dass ein ARES 306 während des Normalbetriebes von der Anwendung nicht benötigt wird.
  • Es ist zweckmäßig, den ARES 306 für eine Einführung neuer Dokumenttypen - insbesondere für eine Einführung neuer Produkte eines Diensteanbieters - einzusetzen, um einmal das entsprechende PDF zu signieren. Innerhalb der Anwendung wird dann das signierte Dokument als Ressource eingeführt. Diese Installation des ARES 306 kann auf einem beliebigen Rechner geschehen. Das Interface für das Signieren einer Dokumentvorlage kann einfach gestaltet sein.
  • Der Download der PDFs ist ein einfaches - quasi statisches - Ausliefern einer Datei durch die Pop-Anwendung. Eventuell Performance-relevante Prozesse für den Eindruck entfallen.
  • Die PDFs können mit Standardwerkzeugen, die beispielsweise von dem Unternehmen Adobe bereitgestellt werden, erstellt werden (mit Acrobat-Professional können die Position der Formfelder definiert werden). Das Befüllen der PDF-Formfelder innerhalb des Acrobat Readers ist eine Standardfunktion.
  • Weiterhin entfallen durch den Wegfall der Notwendigkeit des Signierens jedes einzelnen individuellen PDFs auch an dieser Stelle eventuell auftretende Fehlerquellen bzw. Performance-Engpässe.
  • Die zuvor gewählte Darstellung bezieht sich auf PDF-Dokumente. Es ist jedoch gleichfalls möglich, Dokumente und Programme mit vergleichbaren Funktionen einzusetzen.
  • Dokumente im Sinne der vorliegenden Erfindung sind vorzugsweise graphisch darstellbar. Je nach Einsatzgebiet sind sie manuell oder maschinell erfassbar. Es ist je nach Einsatzgebiet ferner zweckmäßig, eine Verschlüsselung vorzusehen.
  • Die Erfindung umfasst auch Dokumente, die nicht graphisch darstellbar sind. Dokumente im Sinne der Erfindung sind insbesondere Smart-Label. Smart-Label sind RFID-Identifikationsmittel (Transponder). Diese eignen sich für einen Einsatz von Steuerungsprozessen bei der Bearbeitung oder Beförderung von physischen Objekten, insbesondere von Postsendungen oder anderen zu transportierenden Gütern.
  • Die dargestellten Ausführungsformen der Erfindung sind mit einer Vielzahl von Vorteilen verbunden:
    • Es ist möglich, das Layout der Label auf einfache Weise zu ändern und in begrenztem Umfang sogar die Funktionalität des "intelligenten PDFs" anzupassen, ohne die Anwendung neu ausrollen zu müssen, d.h. es wird nur die PDF-Vorlage ausgetauscht.
      Alternativ ist es möglich, eine neue Formatvorlage via Konfigurations-Update / Admin-Tool auf die Produktionssysteme bereitzustellen.
    • Es wird eine Performance-Steigerung erzielt, so dass weniger Serverkapazität benötigt wird.
    • Datenschutz und Sicherheit werden erhöht, denn im PDF - in der PDF-Vorlage - sind keine anwendungsspezifischen Daten, Adressen, Produktinformationen,...) enthalten, auch nicht, wenn das PDF abgespeichert wird, nachdem die Daten via SOAP-Call zum Drucken übertragen wurden und/oder der Druck angestoßen wurde.
    • In besonders bevorzugten Ausgestaltungen der Erfindung ist es möglich, die Konfiguration von Benutzersystemen - insbesondere von eingesetzten Computern der Benutzer - ggf. einschließlich eingesetzter Programmversionen - zu ermitteln und ggf. auch zu protokollieren.
  • Das Servlet, das das PDF ausliefert, muss nun lediglich den Dateinamen für das PDF so umbenennen, dass die Dokument-ID im Dateinamen enthalten ist.
    • Signieren des Dokumentes über ARES
  • Die Vorlagen werden offline während der Entwicklung bzw. Vorbereitungsphase für ein neues Produkt durch den Acrobat Reader Extension Server signiert.
  • ARES selbst muss nicht in der Produktumgebung installiert sein, sondern extern auf einen einfachen PC mit Linux installiert werden. Hierzu wird ein Kommandozeilenwerkzeug eingesetzt, mit dem man beliebige PDF-Dokumente mit den notwendigen Rechten über den ARES versehen kann.
  • Das durch ARES signierte Dokument wird dann in der Anwendung in das Konfigurations-Repository eingespielt.
    • iPDF Umschlag, Muster- und Portodokument
  • Nachdem der Anwender das generierte PDF herunter geladen hat, wird ihm auf der ersten Seite der Umschlag des PDF angezeigt.
  • Hier werden beim Laden des PDFs im Acrobat Reader folgende Überprüfungen vorgenommen.
    • Acrobat Reader kompatibel (Version>= 6.02)?
    • Besteht eine Internetverbindung?
    • Ist die Dokument-ID gültig?
    • Wurde das Produkt bereits gedruckt?
  • Für die letzten beiden Prüfungen wird über die SOAP-Schnittstelle des Acrobat Readers ein von der Anwendung zur Verfügung gestellter Service aufgerufen, der zurückgibt, ob die übermittelte Dokument-ID vorhanden ist und/oder bereits als gedruckt in der Datenbank markiert wurde.
  • Mittels der Dokument-ID werden dann die Formularfelder über die SOAP-Schnittstelle vom POP-eigenen Server geladen und in die Formularfelder gefüllt.
  • Konnte die Dokumenten-ID nicht ermittelt werden - z.B. da der Anwender das PDF-Dokument umbenannt hatte -, wird er über ein Acrobat Formfeld aufgefordert, die Dokumenten-ID einzugeben. Die Dokumenten-IDs werden dem Nutzer in der ihm zugesendeten E-Mail zusätzlich mitgeteilt.
  • Für den Musterdruck werden für die Barcodes Dummy-Codes verwendet. Die korrekten Barcodes werden erst für den Portodruck durch JavaScript kurzzeitig gesetzt.
  • Die Codes können beispielsweise als Leitcodierung eingesetzt werden.
    • Leitcodierung
  • Für die Leitcodierung werden zwei verschiedenen Schnittstellen verwendet:
    • Für die Überprüfung auf Leitcodierbarkeit der Abhol- und Empfängeradressen wird die Schnittstelle "Webbooking - Leitcodeprüfung (eShop, FBE)-Schnittstelle" verwendet.
    • Für die Generierung von Leitcodes für Empfängeradressen - die auch auf dem PDF Label als Leitcode oder Routing Code als Barcode eingedruckt werden - wird die bestehende Implementation der Anwendung Online Label Druck in der aktuellen Version verwendet.
    Online Label Druck Leitcodierung
  • Für die Leitcodierung der Empfängeradressen wird das Leitcode-Modul der Anwendung Online Label Druck verwendet.
  • Es wird davon ausgegangen, dass von Seiten der POP-Anwendung über eine im Applicationserver konfigurierte Datasource transparent auf die entsprechenden Tabellen zugegriffen werden kann.
  • Die Implementierung, die auf diese Leitcodetabellen zugreift, wird von der Anwendung Online Label Druck 1:1 übernommen. Die Pflege und Updates dieser Tabellen bzw. Daten sind nicht Bestandteil dieses SRS.
    • Webbooking - Leitcodeprüfung (eShop, FBE)-Schnittstelle Grundlage
  • Grundlage der Schnittstellenbeschreibung ist das Dokument "FBE-Schnittstellenuebersicht_eFiliale_2_0.doc", im Weiteren als Referenzdokument bezeichnet.
    • Beschreibung
  • Mit Hilfe der Schnittstelle werden die Abholadresse und die Empfängeradressen auf Leitcodierbarkeit geprüft. Die Schnittstelle liefert keinen Leitcode zurück.
  • Die Prüfung der Leitcodierfähigkeit erfolgt über eine Funktion des TAS. Es wird somit die Schnittstelle verwendet, die bei der Schnittstelle "Webbooking - Leitcodeprüfung (FBE, TAS)" implizit verwendet wird.
  • Nicht leitcodierfähige Adressen werden als solche in der GUI markiert.
    • Semantik der Schnittstelle
  • Eingabe (LeitcodeRequest.xsd) Tabelle 1 - Eingabeparameter Leitcodierfähigkeit (LeitcodeRequest.xsd)
    Element Zweck Beschreibung
    Request Typ : Ausprägung: Element Vaterelement: - Der Request zur Leitcodeprüfung. Vaterelement <Request> ... </Request>
    Adressliste Typ: TypeAdressliste Ausprägung: Element Vaterelement: Request Liste der zu prüfenden Adressen. Vaterelement über Adressen <AdressListe> ... </Adressliste>
    MaxGroesse-ListeResponse Typ: TypeMaxGroesseListe-Response Ausprägung: Element Vaterelement: Request Beschreibung: Maximale Anzahl der Liste der Alternativ-Adressen (je zu prüfender Adresse) in der Antwort. Es werden keine Alternativeadresse ausgewertet, daher immer "0".
    MinTreffer-Wahrscheinlichkeit Typ: Globals:TypeTrefferWahrscheinl ichkeit Ausprägung: Element Vaterelement: Request Minimale Trefferwahrscheinlichkeit für Alternativ-Adressen in Prozent : Immer "100", da die Adresse codierbar sein muss. Es werden keine Alternativadressen ausgewertet.
    Trailer Typ: Trailer:TypeTrailer Ausprägung: Element Vaterelement: Request System und Uhrzeit der Anfrage. z. B. POP, 24.12.2006T09:00:00
    Adresse Typ: PruefAdresse:TypeAdresseRequest Ausprägung: Element Vaterelement: Adressliste Beschreibung: zu überprüfende Adresse
  • Adresse Request (TypeAdresseRequest aus PruefAdresse.xsd) Tabelle 2 - Adresse Request (TypeAdresseRequest aus PruefAdresse.xsd)
    Element Zweck Beschreibung
    Strasse Typ: xsd:string Ausprägung: Element Vaterelement: - Strasse der Adresse.
    Hausnummer Typ: xsd:string Ausprägung: Element Vaterelement: - Hausnummer der Abholadresse.
    StrasseHausnummer Typ: xsd:string Ausprägung: Element Vaterelement: - Nicht verwendet.
    Plz Typ: xsd:string Ausprägung: Element Vaterelement: - PLZ der Adresse
    Ort Typ: xsd:string Ausprägung: Element Vaterelement: - Ort der Adresse
    Laendercode Typ: TypePruefStatus Ausprägung: Rohdatensatz:LandType Vaterelement: - Dreistelliges Länderkürzel nach ISO 3166-1, z. B. "DEU".
    ID Typ: Globals: TypeId Ausprägung: Attribute Vaterelement: - Eindeutige Id der zu prüfenden Adresse. Diese ist bei der Response als Referenz für die Adresse wieder anzugeben. Fortlaufende Nummer in der Anfrage.
  • Ausgabe (LeitcodeResponse.xsd) Tabelle 3 - Ausgabeparameter Leitcodierfähigkeit (LeitcodeResponse.xsd)
    Element Zweck Beschreibung
    Response Typ: Ausprägung: Element Vaterelement: - Die Response zur Leitcodeprüfung
    Status Typ: Status: TypeStatus Ausprägung: Element Vaterelement: Response Bearbeitungsstatus
    GepruefteAdressen Typ: TypeGepruefteAdressen Ausprägung: Element Vaterelement: Response Liste der geprüften Adressen. Muss nicht vorkommen, wenn Fehler bei der Bearbeitung aufgetreten ist
    Trailer Typ: Trailer:TypeTrailer Ausprägung: Element Vaterelement: Response System und Uhrzeit der Anfrage. z. B. POP, 24.12.2006T09:00:00
    GepruefteAdresse Typ: TypeGepruefteAdresse Ausprägung: Element Vaterelement: GepruefteAdressen Die geprüfte Adresse mit zusätzlichen Angaben
    PruefStatus Typ: TypePruefStatus Ausprägung: Element Vaterelement: GepruefteAdresse Status der Überprüfung: OK, wenn leitcodierbar
    TASFehler Typ: TypePruefStatus Ausprägung: Element Vaterelement: GepruefteAdresse Wird gesetzt, wenn PruefStatus "Nicht leitcodierbar" ist. Enthält einen TAS-Code und eine Fehlerbeschreibung
    AlternativAdressen Typ: TypeAlternativAdressen Ausprägung: Element Vaterelement: GepruefteAdresse Liste der Alternativ-Adressen bei PruefStatus ,Alternativen' Wird nicht verwendet
    Adresse Typ: PruefAdresse: TypeAdresseResponse Ausprägung: Element Vaterelement: GepruefteAdresse Alternative Adresse. Wird nicht ausgewertet.
  • Adresse Response (TypeAdresseResponse aus PruefAdresse.xsd) Tabelle 4 - Adresse Response (TypeAdresseResponse aus PruefAdresse.xsd)
    Element Zweck Beschreibung
    Strasse Typ: xsd:string Ausprägung: Element Vaterelement: - Angabe der Strasse
    Hausnummer Typ: xsd:string Ausprägung: Element Vaterelement: - Angabe der Hausnummer.
    StrasseHausnummer Typ: xsd:string Ausprägung: Element Vaterelement: - Wird nicht verwendet.
    Plz Typ: xsd:string Ausprägung: Element Vaterelement: - Postleitzahl
    Ort Typ: xsd:string Ausprägung: Element Vaterelement: - Ort
    Laendercode Typ: TypePruefStatus Ausprägung: Rohdatensatz:LandType Vaterelement: - Dreistelliges Länderkürzel nach ISO 3166-1;
    Id Typ: Globals: TypeId Ausprägung: Attribute Vaterelement: - Eindeutige Id der zu prüfenden Adresse.
    TrefferWahrscheinlichkeit Typ: Globals: Type-TrefferWahrscheinlichkeit Ausprägung: Element Vaterelement: - Die Trefferwahrscheinlichkeit dieser Adresse in Prozent
  • In der Suchanfrage ist eine ID für die Suchadresse definiert. In der Antwort ist die Adresse mit der gleichen ID im XML-Knoten <GepruefteAdressen> zu selektieren. Ist der Prüfstatus dieser Adresse "OK", gilt die Adresse als leitcodierbar. Ist eine der Adressen nicht codierbar, steht der Service nicht zur Verfügung.
    • Fehlerhandling
  • Ist die Schnittstelle nicht verfügbar oder hat der Statuscode einen Wert <> 0, steht der Service nicht zur Verfügung. Die fehlgeschlagenen Suchanfragen werden geloggt.
    • Beschreibung
  • Erteilt POP Aufträge für TAS-Abholung(en), erfolgt die Beauftragung mit Hilfe der Schnittstelle "Webbooking - Sendungsbeauftragung (eShop, FBE)". Für jede Warenkorb-Position wird ein Auftrag generiert, d.h. die Abholadresse und Empfängeradresse müssen leitcodierbar sein. Die Leitcodierbarkeit der Abholadresse und aller Empfängeradressen wird zuvor über die Schnittstelle "Webbooking - Leitcodeprüfung (eShop, FBE)-Schnittstelle" sichergestellt.
  • Eine Stornierung wird nicht durchgeführt.
    • Giropay-Schnittstelle
  • Mit Hilfe der Schnittstelle erfolgt die Abrechnung der vom Anwender beauftragten Produkte und Services.
    • Verwendung der Schnittstelle Integration Giropay Button
  • Auf der Seite NOW1 gibt es ein Button Giropay und ein Eingabefeld für die Bankleitzahl. Dieser Button verzweigt nicht direkt auf Giropay-Seite, sondern öffnet ein Popup, in dem der Anwender aufgefordert wird, seine E-Mail noch einmal zu überprüfen. Wenn der Nutzer die Korrektheit seiner E-Mail-Adresse bestätigt, wird die NOW1 Seite erneut geladen. In diesem Requestzyklus wird von der Anwendung noch einmal der Warenkorb bezüglich eventueller Preisänderungen oder sonstigen Inkonsistenzen (fehlende Angaben) überprüft.
  • Bleibt der Warenkorbpreis unverändert, werden folgende Aktionen durchgeführt:
    • Erzeugen der Dokumentdefinitionen in der DB (Dokument-ID).
    • Erzeugen des Warenkorbes in der DB (WarenkorbID. Anmerkung: der in der DB persistierte Warenkorb enthält nur diejenigen Daten, die für die Überprüfung der Transaktion und weitere Schritte nach der Bezahlung (NOW3 anzeigen, Erstellung der E-Mail etc.) notwendig sind.
    • Prüfen der Bankleitzahl.
    • Senden der Transaktionsdaten an den PaySolution-Server.
    Bankleitzahlprüfung
  • Es werden die folgenden Pflichtparameter in einer Punkt-zu-Punkt-Verbindung über HTTPS mit Authentifizierung übermittelt.
    Parameter Typ Beschreibung
    command String Konstante "diagnose"
    payment_options String(50) Konstante "banktransfer;bankcode "
    bankcode Number(8) Bankleitzahl aus Now1
  • Im gleichen Zyklus antwortet der Giropay-Server mit geeigneten Parametern.
  • Für die Auswertung der Bankleitzahlprüfung ist lediglich der Antwortparameter rc relevant.
  • Bei einem Antwortparameter rc = 0 wurde eine BLZ übergeben, die am giropay-Verfahren teilnimmt. Es wird ein Bezahlvorgang initialisiert.
  • Bei einem Antwortparameter rc = 1 wurde eine BLZ übergeben, die nicht am giropay-Verfahren teilnimmt. Der Anwender erhält auf der Seite NOW1 die Meldung "Die Bank nimmt nicht am giropay-Verfahren teil".
  • Bei einem Antwortparameter rc = 2 wurde eine ungültige BLZ übergeben. Der Anwender erhält auf der Seite NOW1 die Meldung "Die BLZ ist ungültig. Bitte prüfen Sie die BLZ".
    • Initialisierung des Bezahlvorganges
  • Es werden die folgenden Parameter in einer Punkt-zu-Punkt-Verbindung über HTTPS mit Authentifizierung übermittelt:
    Parameter Typ Beschreibung
    command String Konstante "open"
    payment options String(50) Konstante "banktransfer"
    orderid String(17) Eindeutige Auftragsnummer über alle Marktplätze
    amount Fix-Komma-Zahl Der zu zahlende Betrag.
    currency String (3) Währungscode gemäß ISO 4217. Hier wird die für den Marktplatz konfigurierte Währung verwendet (in Phase I ausschließlich Euro)
    bankcode Number(8) Bankleitzahl der Bankverbindung, es wird keine Prüfung durch POP durchgeführt.
    sessionid String (255) Session-ID
    basketid String(50) Auftragsnummer
    label0 String (30) Konstante "Ihre Auftragsnummer"
    text0 String(80) Markplatzkürzel(2) + Auftrags-nummer(9) + "vielen Dank für die Nutzung von DHL Express" z.B. für Provider eb123456789, vielen Dank für die Nutzung von DHL Express.
    • Rückmeldung über Bezahlvorgang
  • Nachdem der Anwender bei Giropay bezahlt hat, sendet der PaySolution-Server eine Bestätigung der Bezahlung an die im Controlcenter (Anwendung des Payment-Providers) hinterlegte Url. Diese könnte wie folgt definiert werden:
    http://pop.dhl.de/Giropay/confirm.do
  • Es wird vorrausgesetzt, das in einem definierten Zeitfensterfenster eine Antwort der Schnittstelle erfolgt.
  • In der Antwort werden die folgenden Parameter übergeben.
    Parameter Typ Beschreibung Beispiel
    orderid String ( 17) eindeutige Vorgangsnummer über alle Marktplätze 060626132225 265
    amount Fix-Komma-Zahl Der zu zahlende Betrag. 0,01
    currency String( 3) Währungscode gemäß ISO 4217. Hier wird die für den Marktplatz konfigurierte Währung verwendet (Phase 1 nur Euro) EUR
    basketid String( 50) WarenkorbID 060626132225 281
    rc Number(4) Returncode des Giropay-Server 4000
    directPosErrorCode Number (3) Primärer Rückgabecode des Systems, enthält Informationen über den Ausgang der Zahlung. 0
    Mögliche Werte sind '0' für erfolgreiche und z. B. '100' für fehlgeschlagene oder abgebrochene Zahlungen
    directPosErrorMessage String( 50) Rückgabecode als Text Transaction authorized
    Mac String( 50) Message Authentication Code, dient der Absicherung gegen Manipulationen der Shopbenachrichtigung 7732a717b57f Oa62a06c6ef4 5c0162b76096 c266
    retrefnum String ( 32) giropay Transaktions-ID SEOWQTYZKT
    trefnum String( 20) Transaktionsnummer PaySolution-Service 060626132225 265 01
  • Mittels des Parameters basketid kann die Anwendung nun den Warenkorb (evt. HTTP-Session) aus der Datenbank laden.
  • Danach überprüft die Anwendung, ob die angegebenen Beträge und Währung mit denen im Warenkorb übereinstimmen. Weiterhin wird eine Prüfung über den Message Authentication Code (MAC), der in Antwort mitgeliefert wird, durchgeführt. Die MAC wird über die Werte aller übergebenen Parameter in alphabetischer Reihenfolge gebildet.
  • Falls diese nicht übereinstimmen, wird auf NOW3 eine Fehlermeldung angezeigt und natürlich eine entsprechende Meldung geloggt.
  • Nach erfolgreicher Prüfung des Warenkorbes werden die Aktionen für die Lieferung des Produktes durchgeführt (ESI/GLOBUSS, E-Mail an Anwender, TAS-/Express-Abholung Beauftragung, etc. pp.).
  • Der Anwender kann nun auf NOW3 die PDF-Dokumente herunterladen.
    • Rücksprung von GiroPay zur Anwendung
  • Als Antwort auf die Rückmeldung des Bezahlvorganges schickt POP dem PaySolution-Server die Url für den Rücksprung zu.
  • Dies geschieht in Form eines URL-kodierten Dokumentes, das lediglich den Parameter "rurls" enthält. Die Antwort auf die Benachrichtigung erfolgt möglichst zeitnah.
  • Der PaySolution-Server führt ein Redirect im Browser des Anwenders auf die gesendete Url durch. Die Rücksprungadresse sieht dann beispielsweise wie folgt aus:
    rurls=http%3A%2F%2Fpop.dhl.de%2FGiropay%2Fresponse.do;jsession id=1234123
  • Ein anderes bevorzugtes Bezahlsystem ist das PayPal-Zahlungssystem.
  • Bevorzugte Schnittstellen zur Einbeziehung des PayPal-Zahlungssystems sind nachfolgend dargestellt:
    • PayPal-Schnittstelle
  • Mit Hilfe der Schnittstelle erfolgt die Abrechnung der vom Anwender beauftragten Produkte und Services. Die Kommunikation zwischen der Anwendung und PayPal erfolgt über einen verschlüsselten (128 Bit Schlüssellänge) HTTP-Request (GET bzw. POST).
    • Verwendung der Schnittstelle
  • Die Fakturierung eines Vorganges erfolgt mit der PayPal-Option: "Buy Now and Donations". Es wird der Gesamtbetrag inkl. Steuer dem PayPal-System mitgeteilt und abgerechnet.
    • Verwendete Verfahren zur Prüfung der Bezahltransaktion
  • Die PayPal-Schnittstelle bietet zwei Methoden zur Überprüfung des Status und der Korrektheit der Bezahltransaktion.
  • IPN (Instant Payment Notification) Bei der IPN wird von PayPal eine feste in der Konfiguration des Händleraccounts bei PayPal definierte URL der Anwendung angesprochen. Über Parameter werden Status und Daten des Bezahlvorgangs an die Anwendung übermittelt.
  • IPN ist asynchron zum Paymentablauf. Der Zeitpunkt, zu dem eine IPN generiert wird, kann von PayPal nicht garantiert werden. Die IPN wird von der Anwendung auch nach Beendigung der Nutzer-Session verarbeitet.
  • In der Regel wird eine IPN unmittelbar nach dem Bestätigen der Zahlung auf den PayPal-Seiten ausgelöst.
    • PDT (Payment Data Transfer)
  • Beim PDT-Verfahren wird von der Anwendung mittels eines Requests auf die URL https://www.PayPal.com/cgi-bin/webscr der Status des Bezahlvorgangs abgerufen. Siehe Ablauf PayPal im Positiv-Fall, Schritt 5. Hierzu wird in einer Punkt-zu-Punkt-Verbindung ein Parameterset über HTTPS mit folgenden Parametern übermittelt:
    Feldname Typ Beschreibung
    cmd String Konstant: " notify-synch"
    tx String TransaktionsID wird beim Redirect von PayPal zurück zur Applikation im Parameter tx an die Anwendung übergeben.
    at String Händler Identifizierung. Wird bei der Konfiguration des Händleraccounts von PayPal vergeben und in der Konfiguration der Anwendung gespeichert.
  • Die Rückgabeparameter beim PDT-Verfahren werden von PayPal als Key-Value Paare im Body des Responses geliefert. Abweichend zum IPN wird im PDT zusätzlich in der ersten Zeile ein String übermittelt, der mit dem Wert "SUCCESS" kennzeichnet, dass die PDT Anfrage aus technischer Sicht erfolgreich war.
  • Die von PayPal bei den Methoden IPN und PDT im Response an die Anwendung übermittelten Daten sind in den für die Anwendung relevanten Parametern identisch:
    Feldname Typ Beschreibung
    payment_status String Status der Bezahlung siehe: PP_OrderManagement_IntegrationGuide.pdf TABLE A.3
    mc gross Festkomma Gesamtbetrag
    mc_curency String (3) Währung in ISO3. (In Phase I nur EUR).
    custom String (255). Enthält die von der Anwendung dem Bezahlvorgang zugeordnete WarenkorbID. Diese WarenkorbID wird von der Anwendung für die Zuordnung in der Datenbank verwendet.
    • Ablauf
  • Es ist vorteilhaft, das Verfahren so durchzuführen, dass bei PayPal (über die PayPal-Eigene Shop-Konfiguration) nur diejenigen Bezahloptionen aktiviert werden, die spätestens beim Wiedereintritt in die Anwendung eine eindeutige Aussage von PayPal "Bezahlt" oder "Abgebrochen/Nicht Bezahlt" ermöglichen. Ein "Pending"-Status wird von der Anwendung ignoriert bzw. als "Nicht Bezahlt" interpretiert.
  • In Fig. 5 ist ein Ablaufplan für eine Durchführung eines PayPal-Bezahlungsvorgangs wiedergegeben.
    • Ablauf PayPal im Positiv-Fall
    1. 1. Auf der NOW1 wird ein PayPal Button (POST Formular) angeboten.
    2. 2. Durch ein POP-Post-Formulars wird der Anwender zu PayPal weitergeleitet.
    3. 3. PayPal sendet optional nach erfolgter Zahlung eine IPN (Instant Payment Notification) an die Anwendung, noch bevor der Anwender wieder auf der POP-Anwendung zurückgeleitet wurde.
      Wird innerhalb der IPN die Transaktion als Bezahlt gemeldet, werden die Aktionen für die Auslieferung der PDFs vorgenommen (EDICC, Versand E-Mail, etc). Hiermit ist gewährleistet, dass der Anwender auch dann eine E-Mail erhält, wenn er direkt nach dem Bezahlen bei PayPal den Browser schließt und die Anwendung den Redirect von PayPal auf eine POP-Seite nicht mehr erhält.
    4. 4. PayPal leitet den Anwender über einen Post oder Redirect den Anwender wieder auf eine Seite der POP-Anwendung.
    5. 5. Nach dem Redirect von PayPal zurück zu der POP-Anwendung wird geprüft, ob bereits eine IPN erhalten wurde. Falls keine positive IPN erhalten wurde, wird über das PDT Verfahren von der POP-Anwendung der Status der Sendung nachgefragt.
      Falls diese von PayPal als Bezahlt gemeldet wird, werden die Aktionen für die Auslieferung der PDFs vorgenommen (EDICC, Versand E-Mail, etc).
    6. 6. Dem Nutzer wird die Seite für den PDF-Download (NOW3) angezeigt.
    7. 7. Nachfolgende IPN-Nachrichten, die von PayPal an die POP-Anwendung gesendet werden, werden von der Anwendung ignoriert.
    Grundsätzlich werden alle IPN- und PDT-Nachrichten - auch die von der Anwendung bezüglich des Workflows ignoriert werden - in der Datenbank geloggt, so dass zu einem späteren Zeitpunkt über das Adminweb diese noch nachvollzogen werden können.
    Über die Datenbank müssen die asynchron eintreffenden IPN und PDT synchronisiert werden. Integration PayPal Button
  • Auf der Seite NOW1 gibt es ein Button PayPal. Dieser Button verzweigt nicht direkt auf PayPal-Seite, sondern öffnet ein Popup, in dem der Anwender aufgefordert wird, seine E-Mail noch einmal zu überprüfen.
    • Anmerkung:
  • Wenn die E-Mail bereits durch den Maptos-Request gesetzt wurde, wird das Popup nicht angezeigt, sondern die Seite direkt wieder aufgerufen.
  • Wenn der Nutzer die Korrektheit seiner E-Mail-Adresse bestätigt, wird die NOW1 Seite erneut geladen. In diesem Requestzyklus wird von der Anwendung noch einmal der Warenkorb bezüglich eventueller Preisänderungen oder sonstiger Inkonsistenzen (fehlende Angaben) überprüft.
  • Bleibt der Warenkorbpreis unverändert, werden folgende Aktionen durchgeführt:
    • Erzeugen der Dokumentdefinitionen in der DB (DokumentID).
    • Erzeugen des Warenkorbes in der DB (WarenkorbID. Anmerkung:
      • Der in der DB persistente Warenkorb enthält nur diejenigen Daten, die für die Überprüfung der Transaktion und weitere Schritte nach der Bezahlung (NOW3 anzeigen, Erstellung der E-Mail) notwendig sind.
    • Anzeige der NOW1-Seite.
      Anstelle des PayPal-Buttons mit dem Verweis auf das E-Mail-Bestätigung-Popup wird nun ein PayPal-Buy-Now HTML-Formular hinterlegt. Die Ziel-URL dieses Formulars verweist nun auf die PayPal-Plattform. Dieses Formular wird sofort über Javascript gesteuert ausgeführt, so dass der Browser sofort zu PayPal springt.
  • In dem PayPal-Buy-Now HTML-Formular werden folgende Felder gefüllt:
    Ziel des Formulars beispielsweise:
    https://www.sandbox.PayPal.com/cgi-bin/webscr
    Feldname Typ Beschreibung
    cmd String Konstante "_xclick"
    business E-Mail DHL Account E-Mail. Diese muss bei PayPal entsprechend konfiguriert sein. z.B: popPayPal@dhl.com
    item_name String(128) Einzeilige Beschreibung des zu kaufenden Produktes. Dieses wird dem Benutzer bei Pay-Pal angezeigt.
    item_number String(128) Text mit WarenkorbID. Sichtbar für den Benutzer
    custom String (255) WarenkorbID. Wird dem Benutzer nicht angezeigt
    amount Fix-Komma-Zahl Der zu zahlende Brutto-Betrag.
    no shipping Boolean Wird immer auf 1 gesetzt.
    return URL Rücksprung-URL für den Erfolgsfall. Siehe Anmerkung Rücksprungs-URL unten im Text.
    cancel_return URL Rücksprung-URL für den Fehler-bzw. Abbruchsfall. Siehe Anmerkung Rücksprungs-URL unten im Text.
    no note Boolean immer "1"
    currency_code String(3) Währung in ISO3. Hier wird die für den Marktplatz konfigurierte Währung verwendet. (In Phase I nur Euro).
    lc String(2) Land des Käufers als ISO2. Hier wird das für den Marktplatz konfigurierte Land verwendet.
    bn String Bezahlverfahren. Immer "PP-BuyNowBF".
  • Diese Felder (außer cmd) werden innerhalb des Formulars nicht als einzelne HTML-Formfelder codiert, sondern nach dem Verfahren Public-Key RSA 1024bit in das HTML-Formularfeld verschlüsselt (encrypted) gespeichert, so dass eine Manipulation seitens des Anwenders ausgeschlossen werden kann. Der Public-Key wird von PayPal vergeben und innerhalb der Anwendung konfiguriert.
    • Rücksprungadressen:
  • Rücksprungadressen sind folgendermaßen aufgebaut:
    http://pop.dhl.de/PayPal/success;jsessionid=123456
  • Die Session der Anwendung wird an die URL angehängt.
    • Rücksprung von PayPal zur Anwendung
  • Nachdem der Nutzer bei PayPal den Betrag bezahlt hat, wird von Seiten PayPal auf die Return-URL zurückgesprungen. Bei der Rückgabe werden folgende Parameter übermittelt:
    Feldname Typ Beschreibung
    tx String Transaktionsnummer von PayPal. Dieser Parameter ist zwingend erforderlich, um im nächsten Schritt über das PDT-Verfahren (siehe weiter unten) die Zuordnung der Transaktion zu dem Warenkorb herstellen zu können.
    st String Status der Bezahlung: Wird von der Anwendung ignoriert. Die Statusüberprüfung erfolgt nur anhand der Daten aus den Verfahren PDT oder IPN.
    amt, cc, cm, sig, * String Weitere Parameter werden von der Anwendung ignoriert
    • Überprüfung der Zahlung
  • Falls der Nutzer den Bezahlvorgang nicht abgebrochen und die Zahlung durchgeführt hat, gelangt er zurück zur Anwendung.
    Ist zu diesem Zeitpunkt der Status des Warenkorbs nicht "Bezahlt", wird anhand des Rückgabeparameters tx mittels des PDT-Verfahren bei PayPal der Bezahlvorgang überprüft.
  • Falls in der ersten Zeile nicht der Wert SUCCESS steht oder der Parameter payment_status ungleich "Completed" ist, geht die Anwendung davon aus, dass die Bezahlung nicht erfolgreich abgeschlossen werden konnte. In diesem Fall wird dem Nutzer auf NOW3 eine Fehlermeldung angezeigt. In allen anderen Fällen prüft die Anwendung die Daten der Bezahltransaktion. Dazu wird über den Parameter custom, welcher die WarenkorbID enthält, die Relation zum entsprechenden Warenkorb in der Datenbank der Anwendung hergestellt.
  • Der Wert des Parameters "mc_gross" wird mit dem Betrag in der Datenbank verglichen.
  • Der Wert des Parameters mc_currency wird mit der Währung in der Datenbank verglichen.
  • Stimmen die Werte überein, wird der Warenkorb des Nutzers als "Bezahlt" markiert. Falls diese nicht übereinstimmen, wird auf NOW3 eine Fehlermeldung angezeigt.
  • Nach Erfolgreicher Prüfung des Warenkorbes werden die Aktionen für die Lieferung des Produktes durchgeführt (ESI/GLOBUSS, E-Mail an Anwender, TAS-/Express-Abholung Beauftragung, etc. pp.).
  • Der Anwender kann nun auf NOW3 die PDF-Dokumente herunterladen.
  • Da eine IPN asynchron auftritt, wird von der Anwendung im Falle einer erfolgreich abgeschlossenen Bezahltransaktion in der Datenbank ein dem Warenkorb zugeordneter Status auf "In Bearbeitung" gesetzt. Cancel
  • Falls der Nutzer den Bezahlvorgang abgebrochen hat, und die HTTP-Session noch gültig ist, wird er wieder auf NOW1 mit seinem Warenkorb weitergeleitet. Hat der Nutzer den Bezahlvorgang abgebrochen, konnte jedoch innerhalb der Anwendung wegen eines Timeouts die Session nicht fortgeführt werden, wird dem Anwender NOW3 mit einer entsprechenden Fehlermeldung angezeigt.
  • Um das System vor Missbräuchen zu schützen und um eine schnelle, zuverlässige und sichere Vornahme von Änderungen zu erreichen, ist es zweckmäßig, ein geschütztes Administrationssystem vorzusehen.
  • In einer besonders bevorzugten Ausgestaltung ist das Administrationssystem ein Administrations-Web.
  • Vorzugsweise ist das Administrations-Web Teil der POP-Webanwendung.
  • Es ist zweckmäßig, eine Protokollierung (Logging) der Aktionen des Administrations-Webs durchzuführen.
  • Modifiziert ein Anwender Konfigurationsdaten der Anwendung, werden diese Aktionen in den Reportingtabellen mit Username und Zeitstempel protokolliert.
    • Nutzerverwaltung
  • Die Nutzerverwaltung des Administrations-Webs wird über eine einfache Konfigurationsdatei gesteuert, die über das Konfigurations-Repository versioniert verwaltet wird.
  • Jedem Nutzer ist eine Liste von Rollen zugewiesen. Diese Rollen entsprechen den Rechten für die Benutzung der einzelnen Bestandteile (sprich Masken) des Administrationswebs.
  • Durch das dargestellte System ist es möglich, ein Verfahren zum Erzeugen eines auf eine Postsendung aufbringbaren Labels auf verschiedene zweckmäßige Arten durchzuführen.
  • Insbesondere wird das Verfahren so durchgeführt, dass ein Netzwerkknoten (Maptos) einen Datendienst bereitstellt, der in wenigstens einem Anbieterserver eines Dienstanbieters ausgeführt wird, wobei Daten zum Einbringen in das Label erzeugt werden.
  • Bei dem Datendienst handelt es sich beispielsweise um einen Internetdienst.
  • Die Erzeugung des Labels wird so gesteuert, dass ein Druck des Labels erst dann ermöglicht wird, wenn ein Prüfungsschritt durchgeführt wurde. Der Prüfungsschritt dient beispielsweise zur Überprüfung der Gültigkeit eines Gutscheins oder der Überprüfung, ob ein angefordertes Frankierlabel bezahlt wurde.
  • Ferner ist es zweckmäßig zu überprüfen, ob ein angefordertes Frankierlabel bereits einmal ausgedruckt wurde. In diesem Fall wird ein erneuter Ausdruck des Frankierlabels verhindert.
  • Es ist besonders vorteilhaft, die Label beziehungsweise Druckvorlagen zur Erzeugung der Label als intelligente Dokumente bereitzustellen.
  • Hierbei ist es vorteilhaft, dass ein Programmmodul in das intelligente Dokument eingebracht wird, das dazu ausgebildet ist, eine darstellbare Angabe eines Ergebnisses des Prüfungsschrittes oder eines weiteren Prüfungsschrittes zur Prüfung des Vorliegens der Voraussetzung innerhalb des intelligenten Dokuments zu erzeugen.
  • Eine Weiterbildung hiervon sieht vor, dass wenigstens einer der Prüfungsschritte mittels des Programmmoduls durchgeführt wird.
  • Ein oder mehrere weitere Prüfungsschritte können in dem Anbieterserver, dem Netzwerkknoten oder einer anderen serverbasierten Recheneinheit erfolgen.
  • Ferner ist es vorteilhaft, dass in dem Prüfungsschritt überprüft wird, ob die Programmausführungsumgebung zur Verfügung steht.
  • Um missbräuchliche Mehrfachausdrucke zu verhindern, ist es vorteilhaft, dass ein Programm einen einmaligen Druck des Labels steuert und dass ein intelligentes Dokument von einem Server über ein Netzwerk an einen Client übermittelt wird.
  • Zur weiteren Erhöhung der Datensicherheit wird das Verfahren so durchgeführt, dass bei einem ersten Druck des Labels eine Nachricht von dem Nutzerclient an den Server übermittelt wird und dass der Druck aufgrund der Nachricht in dem Server protokolliert wird.
  • Um sicherzustellen, dass serverbasierte Sicherheitsmechanismen eingesetzt werden können, ist das zur Steuerung des Drucks der Label dienende Programm so ausgestaltet, dass es nur dann ausführbar ist, wenn eine Netzwerkverbindung zwischen dem Client und dem Server besteht und wenn anhand einer Abfrage des Servers festgestellt wurde, dass das Label noch nicht gedruckt worden ist.
  • Dies erfolgt in einer besonders sicheren Ausgestaltung dadurch, dass in wenigstens einem der Prüfungsschritte überprüft wird, ob ein Zugriff auf das Netzwerk besteht.
  • Eine Weiterbildung sieht vor, dass in wenigstens einem der Prüfungsschritte eine Abfrage des Servers vorgenommen wird, bei der überprüft wird, ob Inhalte des intelligenten Dokuments bereits einmal gedruckt worden sind.
  • Auf die dargestellte Weise ist es möglich, berechtigten Benutzern auf einfache und zuverlässige Weise ein Ausdrucken von Labeln zu ermöglichen. Gleichzeitig wird eine missbräuchliche Erzeugung von Labeln verhindert.
  • Insbesondere ist es durch die Erfindung auch möglich, Gutscheine (Codes) für eine Erzeugung von Labeln einzusetzen.
  • Bei den Gutscheinen kann es sich beispielsweise um vorab bezahlte Portobeträge oder Gutschriften für die Vornahme von Bestell- oder Liefervorgängen handeln.
  • Die Gutscheine enthalten vorzugsweise geltwerte Informationen. In Weiterbildungen der Erfindung können sie auch für Bezahlvorgänge eingesetzt werden.
  • Ferner ist es möglich, die Gutscheine an Empfänger von Warensendungen zu übermitteln. Die Empfänger der Warensendungen können als Benutzer des Systems Label erstellen. So ist es möglich, auf die erfindungsgemäße Weise Label als Retourenlabel für eine Rücksendung von Postsendungen an einen ursprünglichen Absender - insbesondere ein Versandunternehmen - zu erstellen.
  • Zur Erzeugung eines als Retourenlabel dienenden Labels wird auf einem ersten Übermittlungsweg ein Gutschein an einen Benutzer übermittelt. Später - insbesondere wenn der Benutzer eine Rücksendung einer Postsendung oder eines in ihr enthaltenen Produkts wünscht - wird der Gutschein (Code) durch eine in einem Einflussbereich des Benutzers befindliche Bedieneinheit an einen Server übermittelt.
  • Diese Weiterbildung der Erfindung sieht eine mehrschrittige Erzeugung eines Labels vor. Dieses mehrschrittige Erzeugen zeichnet sich dadurch aus, dass auf einem ersten Übermittlungsweg ein Gutschein an einen Benutzer übermittelt wird, dass der Gutschein durch eine in einem Einflussbereich des Benutzers befindliche Bedieneinheit an einen Server übermittelt wird und dass der Server einen Prüfungsschritt zur Überprüfung des Gutscheins durchführt und in Abhängigkeit von dem Ergebnis des Prüfungsschritts das Erzeugen des Labels beeinflusst.
  • Die Übermittlung des Gutscheins an den Benutzer kann auf verschiedene Weise erfolgen.
  • Eine Weiterbildung der Erfindung sieht vor, dass der Gutschein oder ein Bestandteil des Gutscheins auf verschiedene Übermittlungswege an den Benutzer übermittelt wird.
  • Eine Übermittlung an den Benutzer erfolgt auch dann, wenn der Gutschein oder ein Bestandteil an eine in einem Einflussbereich des Benutzers befindliche Bedieneinheit übermittelt wird.
  • Dies ist beispielsweise bei einer Übermittlung an einen Computer oder ein mobiles Benutzerendgerät wie ein Mobiltelefon der Fall.
  • Eine Weiterbildung des Verfahrens, des Computerprogrammprodukts und der Vorrichtung zeichnet sich dadurch aus, dass der Gutschein einer an den Benutzer gerichteten Postsendung beigefügt ist.
  • Eine Ausgestaltung des Verfahrens, des Computerprogrammprodukts und der Vorrichtung sieht vor, dass der Gutschein elektronisch an den Benutzer übermittelt wird.
  • Eine Weiterbildung des Verfahrens, des Computerprogrammprodukts und der Vorrichtung zeichnet sich dadurch aus, dass der Gutschein bei Eintreten eines Ereignisses an den Benutzer übermittelt wird.
  • Eine Ausgestaltung des Verfahrens, des Computerprogrammprodukts und der Vorrichtung sieht vor, dass der Gutschein bei Eintreten eines Versandereignisses übermittelt wird.
  • Eine Weiterbildung des Verfahrens, des Computerprogrammprodukts und der Vorrichtung zeichnet sich dadurch aus, dass der Gutschein auf eine Anforderung übermittelt wird.
  • Eine Ausgestaltung des Verfahrens, des Computerprogrammprodukts und der Vorrichtung sieht vor, dass die Bedieneinheit ein Computer ist.
  • Eine Weiterbildung des Verfahrens, des Computerprogrammprodukts und der Vorrichtung zeichnet sich dadurch aus, dass der Prüfungsschritt eine Gültigkeitsprüfung des Gutscheins beinhaltet.
  • Eine Ausgestaltung des Verfahrens, des Computerprogrammprodukts und der Vorrichtung sieht vor, dass der Prüfungsschritt eine Gültigkeitsprüfung des Gutscheins beinhaltet.
  • Eine Weiterbildung des Verfahrens, des Computerprogrammprodukts und der Vorrichtung zeichnet sich dadurch aus, dass unter Berücksichtigung des Gutscheins eine Empfängeradresse für die Postsendung ermittelt wird.
  • Eine Ausgestaltung des Verfahrens, des Computerprogrammprodukts und der Vorrichtung sieht vor, dass unter Berücksichtigung des Gutscheins eine Absenderadresse für die Postsendung ermittelt wird.
  • Die Erfindung umfasst auch Dokumente, die nicht graphisch darstellbar sind. Dokumente im Sinne der Erfindung sind insbesondere auch Smart-Label. Smart-Label sind RFID-Identifikationsmittel (Transponder). Diese eignen sich für einen Einsatz von Steuerungsprozessen bei der Bearbeitung oder Beförderung von physischen Objekten, insbesondere von Postsendungen oder anderen zu transportierenden Gütern.
  • Ein Einsatz von Kennungsdaten erhöht die Datensicherheit weiter. Die Kennungsdaten werden vorzugsweise dadurch erkannt, dass eine Signatur für den jeweiligen dynamischen Inhalt erstellt und dass diese Signatur mit dem jeweiligen dynamischen Inhalt übertragen wird.
  • Zweckmäßigerweise wird die Signatur im Ziel einer jeweils erfolgenden Kommunikation (Zielsystem) erneut erstellt und der sich ergebende Wert - insbesondere Hash-Wert - mit dem sich aus der übertragenen Signatur ergebenden Wert verglichen.
  • Durch den Vergleich der Werte ist es möglich, eine Manipulation der Inhalte zu verhindern, da die jeweilige Anwendungslogik nur dann aktiv wird, wenn die Prüfungen korrekt verlaufen sind.
  • Die Erfindung beinhaltet auch einen Einsatz anderer Programme als die dargestellten.
  • Insbesondere ist es möglich, unter Einsatz der dargestellten Ausgestaltung des Systems und der Vorrichtung andere als die zuvor dargestellten Computerprogramme einzusetzen.
  • Ebenso ist es möglich, andere Dateiformate einzusetzen.
  • Eine Auswahl der Software sollte so erfolgen, dass mit ihr eine Datei erzeugbar ist, welche folgende Eigenschaften aufweist:
    1. 1. Ein Download der Datei sollte möglich sein.
    2. 2. Eine Darstellung und ein Druck des Labels in gleicher Form (Rahmen, Logos, variabler Texte) sollte möglich sein.
    3. 3. Ein Druck von Barcode-Labels sollte möglich sein, idealerweise durch Einbindung von FONTs.
    4. 4. Eine Applikationslogik (via Java-Script, Visual Basic, .net, ....) sollte in der Datei verwendbar/aktivierbar sein.
      Diese Eigenschaft erfüllen beispielsweise auch Adobe-Flash und eine Vielzahl von Microsoft/Windows Produkten aus dem Office-Umfeld.
      • 4.1 Soap-Requests (HTTPs-Requests) sollten möglich sein.
      • 4.2 Ein Druckdialog sollte über die Anwendungslogik ansteuerbar sein.
    5. 5. Die Datei sollte schreibgeschützt übertragbar sein.
    6. 6. Die Datei sollte gegen die Änderung der Applikationslogik/vor beziehungsweise während der Ausführung (insbesondere beim Drucken) geschützt sein.
  • Diese Anforderungen werden beispielsweise auch durch Microsoft Excel erfüllt. Zur Erhöhung der Datensicherheit empfiehlt sich hier eine entsprechende zusätzliche Verschlüsselung des eingebetteten Script-Codes, den man dann zusätzlich absichern sollte.
  • Es ist zweckmäßig, die intelligenten Dokumente so auszugestalten, dass sie eine Überprüfung von Programmversionen ermöglichen.
  • Insbesondere ist es zweckmäßig, dass die Dokumente in der Lage sind zu überprüfen, welche Version beziehungsweise welche Implementierung eines Computerprogramms und/oder welches Betriebssystem auf einem Client installiert sind.
  • Die Erfindung ist nicht auf die dargestellten Einsatzgebiete beschränkt.
  • Bei einer Erzeugung von Labeln für Postsendungen ist es zweckmäßig, dass diese Informationen zur Identifikation, zum Leitwege, zu Vorausverfügungen und zu mit dem Versandauftrag verbundenen Extraleistungen enthalten.
  • Weiterhin ist es zweckmäßig, dass die Label Kunden- und/oder Abrechnungsinformationen enthalten.
  • Die dargestellten Label dienen als Informationsträger und ermöglichen beispielsweise eine Annahme, Entgeltabrechnung, Sortierung, Verladung, Sonderbehandlung, Zustellung, Ausgabe, Abrechnung, Nachforschung, Nachbearbeitung, Betriebsdatenverarbeitung, Sendungsverfolgung (Tracking & Tracing) und Archivierung einer Sendung.
  • Die intelligenten Dokumente - insbesondere die Label für ein Aufbringen auf die Postsendungen - weisen bei Weiterbildungen der Erfindung Informationsblöcke auf. Hierbei ist es zweckmäßig, Datentypen und/oder Datengrößen für die Informationsblöcke festzulegen. Diese Festlegung erfolgt zweckmäßigerweise entsprechend der jeweiligen logistischen Anforderungen.
  • Beispiele für dynamische Inhalte, die in den statischen Rahmen eingebracht werden, sind Empfängeradresse und Angaben, welche eine Sendungsidentifikation ermöglichen, beispielsweise eine Sendungsidentifikationsnummer.
  • Die übermittelten Rahmeninformationen dienen zu einer übersichtlichen, strukturierten und formatierten Darstellung der dynamischen Inhalte.
  • Figur 5 zeigt eine graphische Darstellung erfindungsgemäß erzeugter intelligenter Dokumente. Die graphischen Darstellungen können beispielsweise an einem Bildschirm eines Clients angezeigt oder ausgedruckt und gegebenenfalls - für einen Einsatz als Versandlabel für eine Postsendung - ausgedruckt werden.
  • Zur Erzeugung der Dokumente werden jeweils statische Inhalte von den dynamischen Inhalten getrennt übertragen.
  • Bei den statischen Inhalten handelt es sich beispielsweise um die in den Abbildungen eingezeichneten Rahmen und um Firmenangaben wie "DHL".
  • Dynamische Inhalte, die in die Sendungen eingebracht werden, sind beispielsweise Absenderangabe, Empfängerangabe, Rechnungsnummer, Größenangaben, Sendungsidentifikationsnummer und/oder gegebenenfalls auch eine Produktbezeichnung.
  • Fig. 5 zeigt den Labelinhalt beispielhaft in einem DIN A 4-Querformat, nebeneinander liegend.
  • Es ist für den Fachmann selbstverständlich, die jeweilige graphische Gestaltung der Label einschließlich der wiedergegebenen Informationen - Klarschriftanteile und Maschinenschriftanteile und gegebenenfalls verschlüsselte Informationen - entsprechend den Anforderungen von Versandunternehmen, welche die Postsendungen transportieren beziehungsweise bearbeiten, auszuwählen.
  • Die dynamischen Inhalte werden in einer Weiterführung der Erfindung von einem Auftraggeber eines Versandvorgangs (Versender) in elektronischer Form übermittelt. Die elek-tronische Übertragung der Sendungsdaten kann vor, während und nach einer physischen Übergabe der Sendungen an ein Versandunternehmen erfolgen.
  • Eine zeitgleiche elektronische und physische Übertragung ist jedoch zur Vereinfachung der logistischen Prozesse bevorzugt.
  • Zur Übertragung der Daten wird vorzugsweise ein geeigneter Nummernkreis vorgegeben.
  • Ferner können die Label Handhabungsinformationen - beispielsweise für Mitarbeiter des Versandunternehmens, insbesondere einen Zusteller - enthalten. Es ist möglich und zweckmäßig, für die graphische Wiedergabe einzelner der Handhabungsfunktionen ein von sonstigen Labelinhalten abweichendes Format zu wählen.
  • Die vorherige Beschreibung von Ausführungsbeispielen der Erfindung anhand der Figuren ist illustrativ und beispielhaft zu verstehen. Die Erfindung ist nicht auf die dargestellten Ausführungsbeispiele beschränkt.
  • Im Zusammenhang mit dem Druck von Labeln mittels eines intelligenten Dokuments ist die Erfindung insbesondere nicht auf die dargestellten Übertragungsarten, Formatarten oder Prüfungsschritte beschränkt. Vielmehr erkennt der Fachmann, dass im Rahmen der Erfindung auch andere Übertragungsarten gewählt und/oder andere Formate genutzt und/oder andere Prüfungsschritte durchgeführt werden können, deren Ergebnisse gegebenenfalls in dem Dokument dargestellt werden.
  • Der Fachmann erkennt ferner, dass die Erfindung auch auf anderen Gebieten als den dargestellten eingesetzt werden kann.
  • So ist es beispielsweise möglich, das Vorhandensein der Programmausführungsumgebung bei jedem beliebigen intelligenten Dokument zu prüfen und das Ergebnis der Prüfung darzustellen.
  • Bei den intelligenten Dokumenten kann es sich beispielsweise um intelligente Dokumente mit animierten Graphiken oder um Formulare handeln. Insbesondere ist die Erfindung bei Formularen einsetzbar, die im Verkehr mit Behörden verwendet werden und als intelligente Dokumente ausgeführt sind. Anhand der Prüfungsschritte, deren Ergebnisse bei der Erfindung dargestellt werden, kann dabei insbesondere auch geprüft werden, ob bestimmte Pflichtfelder eines Formulars ausgefüllt worden sind.
  • Darüber hinaus kann die Erfindung auch bei intelligenten Dokumenten eingesetzt werden, die mittels der "Intelligenz" vor einem unberechtigten Zugriff geschützt werden. In diesem Zusammenhang sind etwa Texte zu nennen, die nur dann angezeigt und/oder gedruckt werden können, wenn der Nutzer hierzu berechtigt ist, wobei die Berechtigung des Nutzers beispielsweise durch eine über ein Netzwerk erfolgende Serverabfrage von dem intelligenten Dokument geprüft wird.
  • Die unterschiedliche Handhabung von dynamischen und statischen Inhalten ermöglicht weit reichende Gestaltungsmöglichkeiten für individuell oder in zeitlichen Abständen zu erstellende und/oder zu aktualisierende Dokumente.
  • Zur Weiterentwicklung von Retourenlogistikprozessen sind Online-Frankierlösungen vorteilhaft, wobei sowohl die Einsparung von Prozesskosten als auch die Optimierung der Informationstransparenz möglich ist.
  • Retourenlogistikprozesse bezeichnen logistische Prozesse zur Handhabung von Retouren.
  • Die Erfindung beinhaltet sowohl die Weiterbildung eines Logistiksystems als Retourenlogistiksystem als auch die Ausgestaltung eines Logistiksystems mit Handhabungsvorgängen zur Handhabung von Retouren.
  • Die Erfindung beinhaltet ein Logistiksystem zum Befördern einer Postsendung auf einem Transportweg innerhalb eines Postverteilnetzes, wobei der Transportweg mehrere Knoten des Postverteilnetzes enthält, insbesondere einen Knoten, der einem Zustellpunkt entspricht.
  • Gegebenenfalls enthält der Transportweg zusätzlich einen oder mehrere Knoten, die jeweils einem Sortierpunkt entsprechen.
  • Der Begriff Logistiksystem ist im Rahmen der Erfindung in einer weiten Bedeutung zu verstehen. Er umfasst insbesondere Systeme, welche die Mittel und Einrichtungen enthalten, um den Transport von Postsendungen von einem Abgangsort zu einem Zustellpunkt auf einem Transportweg innerhalb eines Postverteilnetzes durchzuführen.
  • Bei dem Abgangsort handelt es sich beispielsweise um einen Lagerort oder Einlieferungsort des zu transportierenden Gegenstandes. Der Zustellpunkt wird vorzugsweise von dem Auftraggeber des Transports ausgewählt. Bei einer Rücksendung ist dies beispielsweise ein Lager eines Händlers oder Herstellers.
  • Auf die dargestellte Weise ist es möglich, die Label schnell, zuverlässig und bedarfsgesteuert zu übermitteln. Insbesondere ist eine Berücksichtigung von Anforderungen eines Versanddienstleisters, der zunächst eine Ware mit einer ersten Postsendung an den Benutzer übermittelt und eine gezielte Rückführung der Ware durch eine zweite Postsendung wünscht, möglich.
  • Dies geschieht erfindungsgemäß zweckmäßigerweise dadurch, dass auf einem ersten Übermittlungsweg ein Gutschein an einen Benutzer übermittelt wird, dass der Gutschein durch eine in einem Einflussbereich des Benutzers befindliche Bedieneinheit an einen Server übermittelt wird und dass der Server einen Prüfungsschritt zur Überprüfung des Gutscheins durchführt und in Abhängigkeit von dem Ergebnis des Prüfungsschritts das Erzeugen des Label beeinflusst.
  • Die Übermittlung des Gutscheins erfolgt zweckmäßigerweise bei Eintreten eines Versandereignisses, beispielsweise bei einer Einlieferung der an den Benutzer gerichteten Postsendung, bei einem Beförderungs- oder Verarbeitungsschritt der Postsendung oder einer Auslieferung der Postsendung an den Benutzer.
  • Die Erfindung beinhaltet verschiedene Arten der Übermittlung des Gutscheins und ermöglicht eine Integration verschiedener Übermittlungswege.
  • Um eine besonders hohe Datensicherheit zu gewährleisten, erfolgt der Prüfungsschritt so, dass er eine Gültigkeitsprüfung des Gutscheins beinhaltet.
  • Zur Beschleunigung der Verarbeitung ist es zweckmäßig, dass unter Berücksichtigung des Gutscheins eine Empfängeradresse für die Postsendung ermittelt wird.
  • Ferner ist es zweckmäßig, dass unter Berücksichtigung des Gutscheins eine Absenderadresse für die Postsendung ermittelt wird.
    • Glossar Abholung TAS
  • Termin-Abholungs-System
    • Anwender
  • Endanwender, der die POP-Anwendung nutzt, um Marken oder Gutscheine zu kaufen.
    • Anwendung
  • Die Webanwendung Parce1OnlinePostage.
    • Basisprodukt
  • "Päckchen", "Paket 10 kg", "Paket 20 kg";
    Wird beispielsweise für die Gruppierung innerhalb der Produktauswahl verwendet.
    • Baustein
  • Rechteckige statische Fläche in einer Webseite, die zeit- und marktplatzgesteuert eingeblendet werden kann.
    • BLNN
  • Beleglose Nachnahme
    • BHNN
  • Belegbehaftete Nachnahme
    • Dokumenten-ID
  • Eindeutige Nummer, über die ein Anwender eine von ihm erworbene Marke referenzieren kann.
    • EKP-Nummer
  • Eine Art Kundennummer für den Marktplatz.
    • ESI
  • Entgeltsicherung (Mittel zum Ermitteln missbräuchlich erzeugter Label.
    • Gutschein
  • Eine Instanz eines Gutscheintypes; kann über einen eindeutigen Gutscheincode identifiziert werden.
    • Gutscheintyp
  • Eine Klasse eines Gutscheines.
    • Kunde
  • Begriff wird nicht benutzt, da zweideutig.
    • LP
  • License Plate.
    • Marktplatz
  • Jeder Anwendersession ist ein Marktplatz zugeordnet, der einige Rahmenbedingungen wie die Währung vorgibt.
    • PALS
  • Photo Anschriften Lese System
    • PAN
  • Pre Advice Notification
    • POC
  • Proove of Collection
    • POD
  • Proove of Delivery
    • POM
  • Proove of Money
    • POT
  • Proove of Transport
    • Produkt
  • Eine Kombination aus Basisprodukt und Services; wird über einen Produktschlüssel identifiziert.
    • Produktcode
  • Numerischer, zweistelliger Code für Basisprodukt
    • Produktschlüssel
  • Eindeutiger Schlüssel für eine Basisprodukt-/Services-Kombination.
    • Service
  • Bepreiste Eigenschaft eines Produktes.
    • Warenkorb-ID
  • Über diese eindeutige Nummer kann ein Anwender bei Supportanfragen seinen Warenkorb referenzieren.
  • Bezugszeichenliste:
    • 301
    PDF-Template
    302
    POP-Web-Server
    303
    Dokumentendatensatz
    304
    Lizenzierungsinformationen
    305
    Intelligentes Dokument (beispielsweise iPDF)
    306
    ARES

Claims (16)

  1. Verfahren zum Erzeugen eines auf eine Postsendung aufbringbaren Labels,
    dadurch gekennzeichnet,
    dass ein Netzwerkknoten (Maptos) einen Datendienst bereitstellt, der in einem Anbieterserver eines Dienstanbieters ausgeführt wird, wobei Daten zum Einbringen in das Label erzeugt werden.
  2. Verfahren nach Anspruch 1,
    dadurch gekennzeichnet,
    dass der Datendienst ein Internetdienst ist.
  3. Verfahren nach einem der Ansprüche 1 oder 2,
    dadurch gekennzeichnet,
    dass ein Prüfungsschritt zur Überprüfung eines Gutscheins durchführt und in Abhängigkeit von dem Ergebnis des Prüfungsschritts das Erzeugen des Labels beeinflusst wird.
  4. Verfahren nach Anspruch 3,
    dadurch gekennzeichnet,
    dass in einem dem Prüfungsschritt vorangehenden Verfahrensschritt der Gutschein an einen Benutzer übermittelt wird.
  5. Verfahren nach einem der vorangegangenen Ansprüche,
    dadurch gekennzeichnet,
    dass ein Programmmodul in das intelligente Dokument eingebracht wird, das dazu ausgebildet ist, eine darstellbare Angabe eines Ergebnisses des Prüfungsschrittes oder eines weiteren Prüfungsschritts zur Prüfung des Vorliegens der Voraussetzung innerhalb des intelligenten Dokuments zu erzeugen.
  6. Verfahren nach Anspruch 5,
    dadurch gekennzeichnet,
    dass wenigstens einer der Prüfungsschritte mittels des Programmmoduls durchgeführt wird.
  7. Verfahren nach einem der Ansprüche Anspruch 3 bis 6,
    dadurch gekennzeichnet,
    dass in dem Prüfungsschritt überprüft wird, ob die Programmausführungsumgebung zur Verfügung steht.
  8. Verfahren nach einem der vorangegangenen Ansprüche,
    dadurch gekennzeichnet,
    dass ein Programm einen einmaligen Druck des Labels steuert und dass ein intelligentes Dokument von einem Server über ein Netzwerk an einen Client übermittelt wird.
  9. Verfahren nach einem der vorangegangenen Ansprüche,
    dadurch gekennzeichnet,
    dass bei einem ersten Druck des Labels eine Nachricht von dem Nutzerclient an den Server übermittelt und dass der Druck aufgrund der Nachricht in dem Server protokolliert wird.
  10. Verfahren nach einem der Ansprüche 8 oder 9,
    dadurch gekennzeichnet,
    dass das Programm zur Steuerung des Drucks des Labels nur dann ausführbar ist, wenn eine Netzwerkverbindung zwischen dem Client und dem Server besteht und wenn anhand einer Abfrage des Servers festgestellt worden ist, dass das Label noch nicht gedruckt wurde.
  11. Verfahren einem der Ansprüche Anspruch 3 bis 10,
    dadurch gekennzeichnet,
    dass in wenigstens einem der Prüfungsschritte überprüft wird, ob ein Zugriff auf das Netzwerk besteht.
  12. Verfahren einem der Ansprüche Anspruch 3 bis 11,
    dadurch gekennzeichnet,
    dass in wenigstens einem der Prüfungsschritte eine Prüfung der Version der Programmausführungsumgebung stattfindet.
  13. Verfahren einem der Ansprüche Anspruch 3 bis 12,
    dadurch gekennzeichnet,
    dass in wenigstens einem der Prüfungsschritte eine Abfrage des Servers vorgenommen wird, bei der überprüft wird, ob Inhalte des intelligenten Dokuments bereits einmal gedruckt worden sind.
  14. Computerprogrammprodukt,
    dadurch gekennzeichnet,
    dass es ein Computerprogramm zur Durchführung des Verfahrens nach einem der Ansprüche 1 bis 13 enthält.
  15. Netzwerkknoten,
    dadurch gekennzeichnet,
    dass er einen Datendienst bereitstellt, der in wenigstens einem Anbieterserver eines Dienstanbieters ausgeführt wird, wobei Daten zum Einbringen in ein Label erzeugt werden.
  16. System zum Erzeugen eines auf eine Postsendung aufbringbaren Labels,
    dadurch gekennzeichnet,
    dass ein Netzwerkknoten (Maptos) mit einem Anbieterserver verbunden ist und dass ein Datendienst bereitgestellt und in dem Anbieterserver ausgeführt wird, wobei Daten zum Einbringen in das Label erzeugt werden.
EP06022477A 2006-10-27 2006-10-27 Verfahren zum Erzeugen eines Labels, Computerprogrammprodukt, Netzwerkknoten und System zur Durchführung des Verfahrens Ceased EP1916627A1 (de)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP06022477A EP1916627A1 (de) 2006-10-27 2006-10-27 Verfahren zum Erzeugen eines Labels, Computerprogrammprodukt, Netzwerkknoten und System zur Durchführung des Verfahrens
EP14164250.4A EP2800065B1 (de) 2006-10-27 2006-10-27 Verfahren zum Erzeugen eines Labels, Computerprogrammprodukt und System zur Durchführung des Verfahrens
US12/447,264 US8477345B2 (en) 2006-10-27 2007-10-23 Method for producing a label, computer program product, network node and system for carrying out the method
PCT/EP2007/009183 WO2008049579A1 (de) 2006-10-27 2007-10-23 Verfahren zum erzeugen eines labels, computerprogrammprodukt, netzwerkknoten und system zur durchführung des verfahrens

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP06022477A EP1916627A1 (de) 2006-10-27 2006-10-27 Verfahren zum Erzeugen eines Labels, Computerprogrammprodukt, Netzwerkknoten und System zur Durchführung des Verfahrens

Related Child Applications (1)

Application Number Title Priority Date Filing Date
EP14164250.4A Division EP2800065B1 (de) 2006-10-27 2006-10-27 Verfahren zum Erzeugen eines Labels, Computerprogrammprodukt und System zur Durchführung des Verfahrens

Publications (1)

Publication Number Publication Date
EP1916627A1 true EP1916627A1 (de) 2008-04-30

Family

ID=37814386

Family Applications (2)

Application Number Title Priority Date Filing Date
EP06022477A Ceased EP1916627A1 (de) 2006-10-27 2006-10-27 Verfahren zum Erzeugen eines Labels, Computerprogrammprodukt, Netzwerkknoten und System zur Durchführung des Verfahrens
EP14164250.4A Active EP2800065B1 (de) 2006-10-27 2006-10-27 Verfahren zum Erzeugen eines Labels, Computerprogrammprodukt und System zur Durchführung des Verfahrens

Family Applications After (1)

Application Number Title Priority Date Filing Date
EP14164250.4A Active EP2800065B1 (de) 2006-10-27 2006-10-27 Verfahren zum Erzeugen eines Labels, Computerprogrammprodukt und System zur Durchführung des Verfahrens

Country Status (3)

Country Link
US (1) US8477345B2 (de)
EP (2) EP1916627A1 (de)
WO (1) WO2008049579A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010075902A1 (de) * 2008-12-29 2010-07-08 Deutsche Post Ag System zum frankieren einer postsendung

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7937331B2 (en) * 2006-06-23 2011-05-03 United Parcel Service Of America, Inc. Systems and methods for international dutiable returns
US8667394B1 (en) * 2007-06-19 2014-03-04 William C. Spencer System for generating an intelligent cross-platform document
US10032239B2 (en) 2010-06-10 2018-07-24 United Parcel Service Of America, Inc. Enhanced payments for shipping
US20140006128A1 (en) * 2012-06-28 2014-01-02 Bank Of America Corporation Systems and methods for presenting offers during a shopping experience
US8918341B2 (en) * 2013-03-06 2014-12-23 United States Postal Service System and method for international merchandise return service
US20140279425A1 (en) * 2013-03-15 2014-09-18 Elwha Llc Methods, systems, and devices for handling multiple disparate systems
US20140279426A1 (en) * 2013-03-15 2014-09-18 Elwha Llc Devices, methods, and systems for technologically shifting options and modalities
EP3074903A4 (de) * 2013-11-29 2017-08-02 Fedex Corporate Services, Inc. Verfahren und systeme zur verwaltung der sendung eines elements unter verwendung eines drahtlosknotennetzwerkes
JP5974024B2 (ja) * 2014-01-18 2016-08-23 株式会社モリサワ フォント配信システム、及びフォント配信方法
CA2983745C (en) 2015-05-04 2024-02-20 United States Postal Service System and method for processing items for international distribution
US10931848B2 (en) 2015-06-08 2021-02-23 Docsolid Llc Adding a graphical symbol to a print stream for a document file
US10621239B2 (en) * 2015-06-08 2020-04-14 Docsolid Llc Managing printed documents in a document processing system
US11687868B2 (en) * 2017-10-25 2023-06-27 KlearNow Corporation Delivering international shipped items
US11281850B2 (en) * 2017-12-28 2022-03-22 A9.Com, Inc. System and method for self-filing customs entry forms
CN108763171B (zh) * 2018-04-20 2021-12-07 中国船舶重工集团公司第七一九研究所 一种基于格式模板的文档自动化生成方法
CN111176588B (zh) * 2019-12-11 2023-09-29 中国平安财产保险股份有限公司 业务单据出单方法、装置、介质及电子设备
CN113961956B (zh) * 2021-10-28 2024-09-24 平安科技（深圳）有限公司 标签化网络信息服务生成及应用方法、装置、设备、介质
CN115271889B (zh) * 2022-09-26 2022-11-29 深圳永贵技术有限公司 智能化标签自动联动生成方法、装置、设备及存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001035346A2 (en) 1999-11-10 2001-05-17 Neopost Inc. System and method of printing labels
WO2005029265A2 (en) 2003-09-19 2005-03-31 Pitney Bowes, Inc. System and method for preventing duplicate printing in a web browser
DE102004046051A1 (de) 2004-09-21 2006-03-30 Deutsche Post Ag Verfahren und Vorrichtung zum Frankieren von Postsendungen

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5771289A (en) * 1995-06-06 1998-06-23 Intel Corporation Method and apparatus for transmitting electronic data using attached electronic credits to pay for the transmission
US6671813B2 (en) * 1995-06-07 2003-12-30 Stamps.Com, Inc. Secure on-line PC postage metering system
US20020023057A1 (en) * 1999-06-01 2002-02-21 Goodwin Johnathan David Web-enabled value bearing item printing
US20030074324A1 (en) * 2000-02-11 2003-04-17 Kresina Roman P. Apparatus and method for providing postal services
DE10020402C2 (de) * 2000-04-27 2002-03-14 Deutsche Post Ag Verfahren zum Versehen von Postsendungen mit Freimachungsvermerken
AU2001271763A1 (en) * 2000-06-30 2002-01-14 Zinio Systems, Inc. System and method for encrypting, distributing and viewing electronic documents
US7103578B2 (en) * 2001-05-25 2006-09-05 Roche Diagnostics Operations, Inc. Remote medical device access
US20020182578A1 (en) * 2001-06-01 2002-12-05 Rachman Bruce A. Online course support method and system
US20030172354A1 (en) * 2002-03-08 2003-09-11 Rafael Antonio Martinez Ponce Administration of customized document production system and method
US7319989B2 (en) * 2003-03-04 2008-01-15 Pitney Bowes Inc. Method and system for protection against replay of an indicium message in a closed system meter
US20050138469A1 (en) * 2003-09-19 2005-06-23 Pitney Bowes Inc. Fraud detection in a postage system

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001035346A2 (en) 1999-11-10 2001-05-17 Neopost Inc. System and method of printing labels
WO2005029265A2 (en) 2003-09-19 2005-03-31 Pitney Bowes, Inc. System and method for preventing duplicate printing in a web browser
DE102004046051A1 (de) 2004-09-21 2006-03-30 Deutsche Post Ag Verfahren und Vorrichtung zum Frankieren von Postsendungen

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010075902A1 (de) * 2008-12-29 2010-07-08 Deutsche Post Ag System zum frankieren einer postsendung

Also Published As

Publication number Publication date
EP2800065A1 (de) 2014-11-05
US8477345B2 (en) 2013-07-02
US20100067041A1 (en) 2010-03-18
WO2008049579A1 (de) 2008-05-02
EP2800065B1 (de) 2017-05-10

Similar Documents

Publication Publication Date Title
WO2008049579A1 (de) Verfahren zum erzeugen eines labels, computerprogrammprodukt, netzwerkknoten und system zur durchführung des verfahrens
DE60018217T2 (de) Techniken zur ausgabe von postwertzeichen über ein netzwerk
WO2008049601A1 (de) Verfahren zum erzeugen eines labels sowie vorrichtung zur durchführung des verfahrens
US7680737B2 (en) Systems and methods for processing payments with payment review features
US20020023057A1 (en) Web-enabled value bearing item printing
US7941744B2 (en) System and method for electronic document generation and delivery
US20040088271A1 (en) Media type identification
EP1695178A4 (de) Verfahren und vorrichtung zur bereitstellung eines versandaufklebers über ein elektronisches beschaffungssystem
EP2017791A1 (de) Verfahren, Vorrichtung und Logistiksystem zum Befördern einer Postsendung
WO2008049580A1 (de) Verfahren zum erzeugen eines intelligenten dokuments und vorrichtung zur durchführung des verfahrens
WO2002007104A1 (en) Web-enabled value bearing item printing
DE60313424T2 (de) Methode und System für eine automatisierte Dokumentverarbeitung
EP2595104B1 (de) Elektronisches Transaktionsverfahren
JP2020017140A (ja) 情報処理装置、プログラム、及び情報処理システム
US20030033222A1 (en) Electronic shop management system
JP2002203174A (ja) 電子商店管理システム、商品データ提供方法、電子商店管理サーバ、および、記録媒体
WO2002039390A1 (de) Verfahren zum versehen von postsendungen mit frankierungsvermerken
WO2007042136A1 (de) Warenauslieferungssystem, verfahren zur auslieferung von waren, versandkomponente und ausgabestelle für waren
DE102007018394A1 (de) Verfahren zur Frankierung einer Postsendung sowie Vorrichtung, Netzwerkknoten, Logistiksystem und Bearbeitungseinheit zur Durchführung des Verfahrens
AU2005270489B2 (en) Method and device arrangement for digitally franking postal articles
JP2005084915A (ja) 情報処理装置、情報処理方法及び情報処理プログラム
WO2000073963A2 (en) Online value bearing item printing
EP1909224A1 (de) Anwendungsarchitektur zum Bereitstellen von Diensten auf Internetmarktplätzen

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA HR MK RS

17P Request for examination filed

Effective date: 20080808

AKX Designation fees paid

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

17Q First examination report despatched

Effective date: 20110906

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20140211