EP1414591B1 - Method for automatically producing actual distributed data sequences - Google Patents

Description

The invention relates to a method for automatic generation including current distribution order data from stored in databases and by data transmission transmitted, central address directories as Verteilfolgefolgedaten.

Modern postal organizations have a centralized electronic Address directory (ZAV), in which all to be delivered Addresses (delivery points) are recorded. The address directory (ZAV) provides the information base for several postal applications, and is regularly updated, e.g. per month. Changes are typically based on of applications of users of ZAV dependent postal Applications, e.g. Post delivery, carried out. The ZAV data is often structured hierarchically: delivery districts, Delivery sections (groups of delivery points) and delivery points.

The introduction of new services and in particular new levels of automation, e.g. distribution order, leads to new requirements for a ZAV system. Additional application-specific data must be stored become. To avoid changes to the ZAV system, new Application systems installed on which the application-specific Data can be stored and processed. In Typically, such an application system internally stores one Copy of the ZAV that has an existing file-oriented Interface is transferred. Changes to the central ZAV dataset requires the replication of the new dataset in the application systems.

Such an application system, the distribution order manager (VFM), is necessary to make a distribution order sorting perform. At this level of automation, the Shipments sorted by machine in the order in which the Shipments are delivered by the deliverer. This will be the Time-consuming manual sorting of shipments before delivery spared. With the VFM sorting plans are prepared, in the order of the letters is given, and which are loaded by the distribution order sorting machines. The VFM must also have Quality of Service (QoS) features such as, for Example, "take only Tuesdays" with the address data store. These QoS characteristics are evaluated by the VFM to determine the Keep sorting plans up-to-date every day.

A problem with the processing of the ZAV data in the VFM are erroneous or incomplete records. Either includes the ZAV has no or only inaccurate sequence information, to specify the distribution order. The one of the deliverers required delivery order may also be due to other reasons, e.g. Disease replacement, change daily. These changes must be immediately feasible for efficiency not affect the distribution order sorting. For this reason and to maintain the QoS information locally To make the VFM systems are preferred on separate Computers installed on site at the sorting facilities.

Each VFM is therefore usually for a separate postal Area responsible and his data does not have to that of the other VFMs. New versions of the However, ZAVs must be based on this architecture on multiple VFMs replicated and there with local changes in the previous one Version to be integrated. This replication would be easy too if the ZAV system provides a log file of the changes would provide (as usual with merge replication between database systems (Microsoft SQL Server 2000 Reference Library (ISBN 0-7356-1280-3))) or if the VFM system to leave no changes to the data (readonly snapshots (Buretta, Marie "Data Replication: Tools and Techniques for Managing Distributed Information ", (ISBN 0-471-15754-6))). If the VFM with an industry standard DBMS (Database Management System) and Replica Action Service implemented, you could get the missing change history (Log file). The VFM should but of several Terminals be operable, which together with the number of distributed VFM machines considerable license costs for can mean a DBMS. The ZAV data is also supposed to be a master version Serve the distribution order data as a replica (asymmetric replication [Buretta, Marie "Data Replication: Tools and Techniques for Managing Distributed Information ", (ISBN 0-471-15754-6)]). A realization without DBMS or Log files of the ZAV changes would therefore be automatic Make conflict resolution difficult.

The invention is based on the object, a simple method for automatically generating current distribution order data with the replication of ZAV databases and with local changes without a Database Management System too create.

The invention is also intended to integrate centrally maintained Quality of service features, e.g. Forwarding requests, the easy integration of parallel changes as well as the addition and correction of an existing address directory by incremental changes.

According to the invention the object is achieved by the features of the claim 1 solved.

• Lokales Kopieren des aktuellen zentralen Adressverzeichnisses oder der Teile, die das relevante Gebiet betreffen,
• Übertragen von lokal gespeicherten Änderungsbefehlen hinsichtlich relativer Positionswechsel von Zustellpunkten in der Verteilreihenfolge für die vorherige Version des zentralen Adressverzeichnisses oder der relevanten Teile, wobei die Zustellpunkte anhand von Identifikationsdaten, die mindestens den Sortierkode enthalten, identifiziert werden, auf die lokale Kopie des aktuellen zentralen Adressverzeichnisses oder der relevanten Teile,
• Überprüfen, ob die Änderungsbefehle im kopierten aktuellen Adressverzeichnis schon realisiert sind oder ob sie noch auszuführen sind,
• Abspeichern der noch auszuführenden, gültigen Änderungsbefehle in einem Audit-File und Ausführen der Änderungsbefehle,

ist es nicht mehr notwendig, die Änderungen mit Hilfe eines Database Management Systems durchzuführen und zu verwalten.Through the steps:

• Local copying of the current central address directory or parts concerning the relevant area,
• Transmitting locally stored change orders regarding relative position changes of delivery points in the distribution order for the previous version of the central address directory or the relevant parts, wherein the delivery points are identified by means of identification data containing at least the sort code, to the local copy of the current central address directory or the relevant parts,
• Check whether the change commands in the copied current address directory have already been implemented or whether they have yet to be executed.
• Storing the valid change commands still to be executed in an audit file and executing the change commands,

It is no longer necessary to implement and manage the changes using a database management system.

Will be at a later date a new version of the central Address directory released, the new database simply as a new version of the distribution order data imported from the VFM. After that, those in the audit file of the previous Version saved change commands automatically applied by an editor program on the new version become. Here are the changes in the first written empty audit file of the new version and so on Version forwarded to version.

According to the method, context information is from the identification data provided in the audit file to a semantic review the validity of the audit file entries during their To enable application. As a result, only the still valid Transfer changes from one version to the next. An important basis of this procedure is also that the audit records are designed so that they are not just the allow easy transfer of data changes, but also the simultaneous verification of the validity of the change instructions allow.

Each time after replicating a new version of the ZAV data A new version of the distribution order data is created on every VFM. Each VFM only processes the ZAV data for his area of responsibility, causing a distribution and parallelization work means. A complicated merge the ZAV and distribution order databases are deleted in this master / slave procedure. By creating a new version of the distribution order data will be automatic to secure the old data still be present. at the generation of the sorting plans for the sorting plants only one, the current, version of the distribution order data used.

By using multiple audit files several can Operators simultaneously make changes to the same version make the distribution order data. After an operator finished with the work becomes the contents of his audit file automatically to the current database as described above, applied. This will make his changes only valid. Should there be changes that have occurred by now Changes made by another operator are not feasible the operator can be informed and then Reprocess the changed distribution order data. The structure of the audit file allows to use an audit file changes to a version of the distribution order data to produce, and this on a meanwhile changed Apply version of the distribution order data.

Advantageous embodiments of the invention are in the subclaims shown.

So it is advantageous if the identification data in addition Include house number extensions.

It is also advantageous if the identification data in addition contain distinctive comments, e.g. "none Delivery on Tuesday "or" from a certain date deliver to new address ".

To include these forwarding or distribution instructions in The copied address directory is advantageous to first check whether the delivery point for the respective forwarding and / or distribution hint in the copied current address directory exists for the distribution order data. If yes, the insertion of the new forwarding and / or Distribution hints in the copied address directory, new notes replace similar old references, and the complete change data of the forwarding and / or Distribution notes are transferred to the audit file.

Centrally maintained QoS features are thus in a copy the current distribution order data of the address directory integrated by adding the existing features to the new ones Characteristics are supplemented or corrected accordingly. Different as with the ZAV data is also a completely new entry in the audit file associated with the new version for each feature change written. This will be local and central In future, entered features will be transferred to new databases. This procedure works only because the audit entries for features as a single not an amendment, but saved as a changed record in the audit file become. This allows the feature data to be complete and without much effort from a version of the distribution order data be transferred to the next. This combined Log change statements and records records the method of this invention.

In a further advantageous embodiment, the update of the central address list or parts of the central address directory only incremental changes transmitted by data transmission. These incremental Changes are made with the copied, previously up-to-date address directory or address directory part merged, by using the identification data at each delivery time in the hitherto current address directory or address directory part It checks if the respective delivery point the incremental change already exists. Is this not the case, he will be in the position with the submitted Distribution order to the copied address directory or address directory part added. Is the delivery point in the incremental change in the address directory or address directory part already exists, it will be at the changed position moved in the address directory. The relocation process takes place advantageously by the delivery point at the deleted previous position of the address directory and to the changed position is newly entered.

This will change the multitude of changes with the new ones ZAV data came along, not mixed with the local changes. That local changes will change the dataset but also logged separately in the new audit file. meanwhile superfluous local fixes can be simple be left off. This procedure only works because of the limited nature of the practice and the scope of the changes in the ZAV data, making it only for the application useful in the postal area, i. Addresses become rather added or moved and relatively rarely deleted.

Subsequently, the invention in an embodiment explained in more detail with reference to the drawings.

FIG 1

ein Strukturdiagramm von Verteilreihenfolgesortiersystemen;

FIG 2

ein Flussdiagramm zur Korrektur/Ergänzung der Verteilreihenfolgedaten durch einen Operator;

FIG 3

ein Flussdiagramm der Importierung von neuen Verteilreihenfolgedaten;

FIG 4

ein Flussdiagramm der Importierung von inkrementell geänderten Verteilreihenfolgedaten.

FIG 5

ein Flussdiagramm der Importierung einer Merkmals-Datei;

FIG 6

ein Flussdiagramm der Importierung einer Audit-Datei.

Show

FIG. 1

a structural diagram of Verteilfolgefolgesortiersystemen;

FIG. 2

a flowchart for correcting / supplementing the Verteilreihengedaten by an operator;

FIG. 3

a flow chart of the import of new distribution order data;

FIG. 4

a flow chart of the import of incrementally changed distribution order data.

FIG. 5

a flow chart of the import of a feature file;

FIG. 6

a flowchart of importing an audit file.

A distribution order manager (VFM) is sent at least the central address directory (ZAV) data relevant to his postal area in files via data transmission. 1 shows the systems required for processing the address data and for the distribution order sorting of a postal organization. The VFM 100 gets the ZAV data from the system 101 on which the ZAV data is maintained and prepares the sorting schedules therefrom by means of a generator program 106 for the distribution order sorting plants 104. Optionally, there is a second application system 102 which also accesses the ZAV data on which forwarding requests are managed. Other application systems that manage other information useful for distribution order sorting are also possible. The forwarding data is also sent to the VFM via data transmission, eg ftp.
The complete ZAV data is completely taken over by the VFM and stored locally as a distribution order data on a hard disk 103. Each time there is a new version of the ZAV data, a new version of the copied local distribution order data is generated. In this way, the ZAV data is replicated in master / slave mode.

Quality of Service (QoS) features are not in the ZAV data These are maintained locally by the operator on the VFM and with the appropriate version of the distribution order data stored. The operator can also change the distribution order data Correct with an editor program 105 or to reflect changes in the street scene, e.g. new houses that not yet known in the ZAV system, in the distribution order sorting to take into account.

FIG. 2 shows as a flow chart the maintenance of the distribution order data by an operator with an editor 105. First becomes the version of the distribution order data to be edited read from disk 201. Then the editor responds on user input that makes changes to the data 202. Changes to the address data can be made on different Levels of hierarchy are performed to one or more Delivery districts, one / more delivery sections or single / multiple Move delivery points 203, or delete 204 or 205. These operations change the data and are at the same time each as audit entries of the varieties MOVE 207, DELETE 208 and ADD 209 logged. Should the operator Add QoS features for a delivery point / section / district, delete or move 206, all changes will be included a SET characteristics entry logged in the audit file 210. Should the operator will save the modified data after editing 211, the distribution order data is stored and the new audit entries at the end of the audit file added 212.

The interpretation of the audit entries is an essential basis of this procedure and is documented in Table 1. surgery Parameter 1 Parameter 2 Parameter 3 MOVE delivery point First delivery point Last delivery point Before / after delivery point ADD delivery point New delivery point Before / after delivery point DELETE delivery point delivery point MOVE section first section Last section Before / After section ADD section New section Before / After section DELETE section section MOVE district First district Last district Before / after district ADD district New district Before / after district DELETE district district SET features delivery point All features

For ADD and DELETE entries, the affected delivery point, Section or district specified as a parameter in the entry.

All details about delivery points, sections or districts are always saved, ie
for delivery points:
District ID, Section ID, Sort Code, Postal Code, Street Name, House Number, House Extension, Remark;
for delivery sections:
Ward ID, Section ID, Section Name;
for delivery districts:
Ward ID, district name.

For ADD entries, the place in the distribution order, inserted at the delivery point / section / district is to be marked. Instead of a position number the corresponding job will be based on the before / after coming Delivery points / sections / districts noted. A MOVE Entry also gets as a parameter before / after coming Delivery points / sections / districts. Because a MOVE entry more as a delivery point / section / district at the same time as one moving the contiguous area becomes the area with the first and last delivery point / section / district specified.

The use of a before or after entry Position of a position number makes the target position one Shift not from the absolute, but from the relative Order of delivery points depends. Section changes are relative to a section and District changes relative to a district logged. These relative Information along with the fact that the real Geography of delivery points remains static means one very effective transfer of audit records.

QoS features are entered with the editor and as SET audit entries saved. An essential part of an audit file consists of SET characteristics instructions. Because everyone Delivery point / section / district usually only a few QoS Gets features, the evaluation of the audit file is thereby Simply kept that always all for one delivery point / section / district existing features in each SET entry be specified. This only requires the last SET entry be evaluated to each delivery point / section / district. When loading the distribution order data 201, unnecessary SET entries are simply ignored, which after the Restore the audit file compressed.

Reading in a new full version of the ZAV data and creating a new version of the distribution order data begins, as shown in FIG 3, with the transmission of the new ZAV data to 400. A syntactic review of the ZAV data, about the correctness and completeness of the records to secure is made first 401. For the transfer of meanwhile carried out local changes to the new Version of the data requires that the records from one version to the next. Districts and sections are in the ZAV data only as one Defined amount of delivery point records, and are after Demand generated in the distribution order data. To delivery point records Identification becomes identification data from the sort code + house number extension + remark a delivery point formed. The sort code represents this Target of sorting and is often on as a barcode Letters printed in automated letter distribution. The sort code does not have to be postal code, street name and house number. The procedure will however more effective when using unique abstract sort codes become. As a rule, not all delivery points are unique Sort code must have the house number extension (often alphabetically) and the remark (e.g., "Butchery"), if available. Districts and sections usually have an identifier for identification is appropriate. It must also be ensured 402, whether the mentioned identifiers and identification data clearly are. All unique records are in the new distribution order data version saved, along with one empty audit file 402.

Afterwards, the entries of an existing audit file, e.g. from the previously current version of the data, to the new ones Data is applied 403 to all local changes transfer. Each entry must first be valid be checked 404. The entry is no longer valid, for example, if the delivery point to be moved already is in the right place. All valid entries will be applied by the editor program 405. When editing the audit entries the current version will be audit entries generated for the new version of the distribution order data. These audit entries of the new version are between saved 406. All invalid audit entries will be stored in a log file 407 and can be used by the operator be viewed as needed. After all audit entries 408 can be processed, the new version of the distribution order data stored with a usually smaller audit file become 409.

If the updated versions of the ZAV data are only made available as incremental databases, each database will be combined with the most recent version of the distribution order data to form a new full version of the distribution order data. As depicted in FIG. 4, the current version of the distribution order data is first read from the hard disk 500. In this case, a hash table is typically set up in the memory 501 according to the usual programming technique in order to subsequently enable the delivery points to be found quickly. The key used in the hash table is the already mentioned identification data, which is formed from the sorting code + house number extension + remark of a delivery point. However, some ZAV databases have no sort codes, in which case the correct sort code will be generated during import.
All new delivery points are processed one after the other 502, first it is checked whether the delivery point already exists 503. If the new delivery point already exists, its relative position is compared with the previous relative position 504. If the positions are the same, no further action is necessary. If the items are different, the delivery point is entered 505 into a list of delivery points to be deleted. These delivery points to be moved are also entered as new delivery points in a list of the new delivery points 506. After all delivery points have been processed 507, all are 508. After that, all new or shifted delivery points are added 509. Lastly, the new version of the distribution order data can be stored 510. Here, empty sections as well as empty areas are left out.

The QoS features of another central application system are provided as a file. A feature file can be used with the current version of the distribution order data to one new version can be combined. As shown in FIG. 5, This will be the current version of the distribution order data read from the disk 600th There will be a Hash table according to the usual programming technique as above already described built in memory 601. All features in the file are processed one after the other 602, where first It checks whether the affected delivery point at all exists 603. If the delivery point exists, the previous features combined with the new features, wherein the new features have priority 605. The supplemented record is in the distribution order data and as a more complete SET entry stored in the audit file 606. Should the affected Delivery point does not exist, will be an entry logged in an error file 604. After all delivery points 607, will be the new version of the distribution order data stored.

Individual audit files can be updated with the current version Distribution order data combined into a new full version become. This functionality enables parallel processing the distribution order data by multiple operators. As shown in FIG 6, this is the current first Version of the distribution order data read from the hard disk 700. This is a hash table according to the usual programming technique built in memory as already described above 701. All audit entries from the audit file are processed 702, and first it checks if every entry is still is valid 703. Can not apply an entry because For example, the delivery point is missing, the entry in the audit log file stored 706. Can the entry nevertheless applied the change is made 704, and a new one Entry saved in the new audit file 705. After all Audit entries have been edited, the new version of the Distribution order data saved 708.

Claims (6)

1. Method for automatically generating current distribution order data with the inclusion of central address directories, which are stored in databases and are transmitted by electronic data transfer, as distribution order data, having the following steps:

   the current central address directory or the parts relating to the relevant area is/are copied locally,

   locally stored change instructions regarding a relative positional change for delivery points in the distribution order for the previous version of the central address directory or of the relevant parts (the delivery points being identified on the basis of identification data containing at least the sorting code) are transferred to the local copy of the current central address directory or of the relevant parts,

   a check is carried out to determine whether the change instructions have already been implemented in the copied current address directory or whether they are yet to be executed,

   the valid change instructions yet to be executed are stored in an audit file and the change instructions are executed.
2. Method according to Claim 1, where the identification data additionally incorporate house number extensions locally.
3. Method according to Claim 1 or 2, where the identification data additionally incorporate distinguishing remarks locally.
4. Method according to Claim 3, where forwarding and/or distribution advice is incorporated into the copied address directory by carrying out the following steps:

   a check is carried out to determine whether the delivery point for the respective forwarding and/or distribution advice exists in the copied current address directory for the distribution order data, and if so

   the new forwarding and/or distribution advice is added to the copied address directory, with the new forwarding and/or distribution advice having priority over the old forwarding and/or distribution advice of the same type, and

   the complete change data for the forwarding and/or distribution advice are incorporated into the audit file.
5. Method according to one of Claims 1 to 4, where the central address directory or address directory parts is/are updated by transmitting only incremental changes by data transfer, which are merged with the previously current and copied address directory or address directory part by using the identification data for each delivery point to check in the previously current address directory or address directory part whether the respective delivery point in the incremental change is already present, and if not, it is incorporated into the copied address directory or address directory part at the concomitantly transmitted position of the distribution order, and if so, the respective delivery point is moved to the changed position in the address directory.
6. Method according to Claim 5, where the move of a delivery point is implemented by deleting said delivery point at the previous position of the address directory and re-entering it at the changed position.

Images