EP1414591A1

EP1414591A1 - Method for automatically producing actual distributed data sequences

Info

Publication number: EP1414591A1
Application number: EP02754489A
Authority: EP
Inventors: Graeme Mclintock
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 2001-08-09
Filing date: 2002-08-02
Publication date: 2004-05-06
Anticipated expiration: 2022-08-02
Also published as: WO2003015940A1; NO20031596L; US20040153470A1; AU2002320933B2; NO325251B1; NO20031596D0; DE50204696D1; EP1414591B1; DE10139249A1

Abstract

The invention relates to a method for automatically producing actual distributed data sequences, integrating, as distributed data sequences, central address tables which are stored in data bases and transmitted by electronic data transfer. The inventive method comprises the following steps: the actual central address table, or parts thereof concerning the relevant area, is locally copied; locally stored modification instructions are transferred, in terms of the relative change of position of feed points in the distributed sequence, for the previous version of the central address table or relevant parts thereof, the feed points being identified by identification data containing at least the sorting code, to the local copy of the actual central address table or the relevant parts thereof; it is checked whether the modification instructions in the copied actual address table have already been executed or whether they are still to be executed; the valid modification instructions which are still to be executed are stored in an audit file and the modification instructions are executed.

Description

description

Process for the automatic generation of current distribution order data

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

Modern postal organizations have a central electronic address directory (ZAV) in which all addresses to be delivered (delivery points) are recorded. The address directory (ZAV) is the information basis for several postal applications and is updated regularly, e.g. per month. Changes are typically made based on requests from users of the ZAV-dependent postal applications, e.g. Post deliverer, carried out. The ZAV data are often structured hierarchically: delivery districts, delivery sections (groups of delivery points) and delivery points.

The introduction of new services and in particular of new levels of automation, for example distribution order sorting, leads to new requirements for a ZAV system. Additional application-specific data must be saved. In order to avoid changes to the ZAV system, new application systems are installed on which the application-specific data can be saved and processed. As a rule, such an application system stores a copy of the ZAV internally, which is transmitted via an existing file-oriented interface. Changes to the central ZAV database require the replication of the new database in the application systems. Such an application system, the distribution order manager (VFM), is necessary to carry out a distribution order sorting. At this level of automation, the items are automatically sorted in the order in which the items are delivered by the deliverer. This saves the time-consuming manual sorting of the mail items before delivery. With the VFM, sorting plans are prepared in which the order of the mail items is specified and which are loaded by the distribution order sorting systems. The VFM must also store quality of service (QoS) features such as, for example, "only carry out on Tuesdays" with the address data. These QoS features are evaluated by the VFM in order to keep the sorting plans up to date on a daily basis.

One problem when processing the ZAV data in the VFM is incorrect or incomplete data records. The ZAV either contains no or only imprecise sequence information in order to specify the distribution order. The delivery order required by the delivery agents can also change for other reasons, e.g. Representation of illness, change daily. These changes must be immediately feasible in order not to impair the efficiency of the distribution order sorting. For this reason and to make the QoS information maintainable on site, the VFM systems are preferably installed on separate computers on site at the sorting systems.

Each VFM is therefore usually responsible for a separate postal area and its database does not have to be compared with that of the other VFMs. According to this architecture, however, new versions of the ZAV must be replicated to several VFMs and integrated there with local changes in the previous version. This replication would be easy to implement if the ZAV system made a log file of the changes available (as usual for merge replication between database systems (Microsoft SQL Server 2000 Reference Library (ISBN 0-7356-1280-3) )) or if the VFM system would not allow changes to the data (read- only snapshots (Buretta, Marie "Data Replication: Tools and Techniques for Managing Distributed Information", (ISBN 0- 471-15754-6))). If the VFM had been implemented with an industry standard DBMS (Database Management System) and replication service, the missing change history could be

Compensate (log file). However, the VFM should be operable from several end devices, which together with the number of distributed VFM computers can mean considerable license costs for a DBMS. The ZAV data should also serve as a master version, 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)]). Implementation without DBMS or log files of the ZAV changes would therefore make automatic conflict resolution difficult.

The invention has for its object to provide a simple method for the automatic generation of current distribution order data with the replication of ZAV databases and with local changes without a database management system.

The invention is also intended to integrate centrally maintained quality of service features, e.g. Forwarding requests, the simple integration of changes made in parallel 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 claim 1.

Through the steps:

- Local copying of the current central address directory or the parts that relate to the relevant area,

- Transfer of locally stored change commands regarding relative position changes from delivery score in the distribution order for the previous version of the central address directory or the relevant parts, the delivery points being identified on the basis of identification data, which contain at least the sort code, on the local copy of the current central address directory or the relevant parts,

- Check whether the change commands have already been implemented in the copied current address directory or whether they are still to be executed,

- If the valid change commands still to be executed are saved in an audit file and the change commands are executed, it is no longer necessary to carry out and manage the changes using a database management system.

If a new version of the central address directory is released at a later date, the new database is simply imported by the VFM as a new version of the distribution order data. The change commands saved in the audit file of the previous version can then be automatically applied to the new version by an editor program. The changes are also written to the initially empty audit file of the new version and thus passed on from version to version.

According to the method, context information from the identification data is provided in the audit file in order to enable a semantic check of the validity of the audit file entries during their use. This means that only the changes that are still valid are transferred from one version to the next. It is also an important basis of this procedure that the audit entries are designed in such a way that they not only enable the data changes to be transferred easily, but also allow the change instructions to be checked at the same time. Every time a new version of the ZAV data is replicated, a new version of the distribution order data is created on each VFM. Each VFM only processes the ZAV data for its area of responsibility, which means a distribution and parallelization of the work. Complicated merging of the ZAV and distribution order databases is not necessary with this master / slave procedure. By creating a new version of the distribution order data, the old data stock will automatically still be available for backup. When generating the sorting plans for the sorting systems, only one, the current, version of the distribution order data is used.

By using multiple audit files, multiple operators can make changes to the same version of the distribution order data at the same time. After an operator has finished working, the content of his audit file is automatically applied to the current database as described above. As a result, his changes are only valid. If there are changes that cannot be made due to changes made by another operator, the operator can be informed and then edit the changed distribution order data again. The structure of the audit file allows an audit file to be created based on changes to a version of the distribution order data, and then applied to a version of the distribution order data that has since been changed.

Advantageous embodiments of the invention are shown in the subclaims.

It is therefore advantageous if the identification data also contain house number extensions.

It is also advantageous if the identification data also contain characteristic comments, for example “none Delivery on Tuesday "or" Delivery from a certain date to a new address ".

To include these forwarding or distribution instructions in the copied address directory, it is advantageous to first check whether the delivery point for the respective forwarding and / or distribution instructions exists in the copied current address directory for the distribution order data. If so, the new forwarding and / or distribution information is inserted into the copied address directory, new information replaces the old information of the same type, and the complete change data for the forwarding and / or distribution information is transferred to the audit file.

Centrally maintained QoS features are thus integrated into a copy of the current distribution order data of the address directory by adding the new features to the existing features or correcting them accordingly. In contrast to the ZAV data, a completely new entry is written in the audit file belonging to the new version for each change in characteristics. Characteristics that are entered locally and centrally will be transferred to new databases in the future. This procedure only works because the audit entries for characteristics are saved in the audit file as the only one, not as a change instruction, but as a changed data record. As a result, the feature data can be transferred completely and without great effort from one version of the distribution order data to the next. This combined logging of change instructions and data sets distinguishes the method of this invention.

In a further advantageous embodiment, only incremental changes are transmitted via data transmission in order to update the central address directory or parts of the central address directory. These incremental changes are merged with the copied, up-to-date address directory or part of the address directory, by using the identification data at each delivery time in the previously current address directory or part of the address directory to check whether the respective delivery point of the incremental change already exists. If this is not the case, it is included in the copied address directory or part of the address directory in the position of the distribution order that was transmitted. If the delivery point already exists in the incremental change in the address directory or part of the address directory, it will be moved to the changed position in the address directory. The moving process is advantageously carried out by deleting the delivery point at the previous position in the address directory and re-entering it at the changed position.

As a result, the large number of changes that came with the new ZAV data are not mixed with the local changes. That Local changes change the database, but are also logged separately in the new audit file. Local corrections that have now become superfluous can simply be omitted. This procedure only works because of the limited nature and scope of the changes in the ZAV data and therefore only makes it useful for use in the postal area, i.e. Addresses are more likely to be added or moved and relatively rarely deleted.

The invention is then explained in more detail in an exemplary embodiment with reference to the drawings.

Show

1 shows a structural diagram of distribution order

Sorting systems; 2 shows a flowchart for correcting / supplementing the

Distribution order data by an operator; 3 shows a flowchart of the import of new ones

distribution order; 4 shows a flowchart of the import of incrementally changed distribution order data. 5 shows a flowchart of the import of a

Feature file; 6 shows a flowchart of the import of an audit file.

A distribution order manager (VFM) is supplied with at least the central address directory (ZAV) data relevant to its postal area in files by data transmission. 1 shows the systems required for processing the address data and for the distribution order sorting by a postal organization. The VFM 100 receives the ZAV data from the system 101, on which the ZAV data are maintained, and uses them to prepare the sorting plans for the distribution order sorting systems 104 by means of a generator program 106. If necessary, there is a second application system 102, which also accesses the ZAV data, on which forwarding requests are managed. Other application systems that manage further information useful for the distribution order sorting are also possible. The forwarding data is also transmitted to the VFM via data transmission, e.g. ftp, delivered. The complete ZAV data are completely adopted by the VFM and stored locally as distribution order data on a hard disk 103. Every time there is a new version of the ZAV data, a new version of the copied local distribution order data is created. In this way, the ZAV data is replicated in master / slave mode.

Quality of service (QoS) characteristics are not included in the ZAV data, these are maintained locally on the VFM by the operator and saved with the appropriate version of the distribution order data. The operator can also correct or supplement the distribution order data with an editor program 105 in order to take account of changes in the street scene, for example new houses that are not yet known in the ZAV system, in the distribution order sorting. 2 shows as a flowchart the maintenance of the distribution order data by an operator with an editor 105. First, the version of the distribution order data to be processed is read 201 from the hard disk. The editor then reacts to user inputs which make changes to the data 202. Changes to the address data can be carried out at different levels of the hierarchy in order to move 203, delete 204 or add 205 one or more delivery districts, one or more delivery sections or single / several delivery points. These operations change the data and are simultaneously used as audit entries of the types MOVE 207, DELETE 208 and ADD 209 logged. Should the operator add, delete or move QoS features for a delivery point / section / district 206, all changes are logged 210 in the audit file with a SET features entry. If the operator wants to save the changed data after editing 211, the distribution order data will be saved and the new audit entries added at the end of the audit file 212.

The interpretation of the audit entries is an essential basis of this procedure and is documented in Table 1.

Table 1

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

All details about delivery points, sections or districts are always saved, i.e. for delivery points:

District ID, section ID, sort code, post code, street name, house number, house number extension, comment; for delivery stages:

District ID, Section ID, Section Name; for delivery areas: District ID, district name.

For ADD entries, the position in the distribution order at which the delivery point / section / district is to be inserted is also identified. Instead of a position number, the corresponding position is noted based on the before / after delivery points / sections / districts. A MOVE entry also receives before / after delivery points / sections / districts as parameters. Because a MOVE entry can move more than one delivery point / section / district at the same time as a contiguous area, the area with the first and last delivery point / section / district is specified.

The use of a before or after entry instead of a position number makes the target position of a shift not dependent on the absolute, but on the relative order of the delivery points. Section changes are logged relative to a section and district changes relative to a district. This relative information, together with the fact that the real geography of the delivery points remains static, means that the audit entries are transferred very effectively.

QoS features are entered with the editor and saved as SET audit entries. An essential part of an audit file consists of SET characteristics instructions. Because each delivery point / section / district generally only has a few QoS features, the evaluation of the audit file is kept simple by always specifying all the features available for a delivery point / section / district in each SET entry. This means that only the last SET entry for each delivery point / section / district needs to be evaluated. When loading the distribution order data 201, superfluous SET entries can simply be ignored, which compresses the audit file after being saved again. Reading in a new complete 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 syntactical check of the ZAV data for correctness and completeness backing up the records is first done 401. To transfer local changes that have been made to the new version of the data, it is necessary that the records can be identified from one version to the next. Districts and sections are defined in the ZAV data only as a set of delivery point records, and are generated in the distribution order data as required. In order to identify delivery point data records, identification data are formed from the sort code + house number extension + remark of a delivery point. The sort code represents the goal of the sorting and is often printed as a barcode on mail items in automated letter distribution. The sort code does not have to consist of the postcode, street name and house number. However, the method becomes more effective if clear abstract sort codes are used. Since usually not all delivery points are given a unique sort code, the house number extension (often alphabetically) and the comment (eg "butcher's shop"), if available, must be taken into account. Districts and sections usually have an identifier that is suitable for identification It must also be ensured 402 whether the identifiers and identification data mentioned are unique, and all unique data records are stored in the new distribution order data version, together with an empty audit file 402.

Then the entries of an existing audit file, for example from the previously current version of the data, can be applied 403 to the new data in order to transfer all local changes. Each entry must first be checked for validity 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 are applied 405 by the editor program. When processing the audit entries of the current version, audit entries are created for the new version of the distribution order data. These audit entries of the new version are saved 406. All audit entries that are no longer valid are saved 407 in a log file and can be viewed by the operator as required. After all audit entries have been processed 408, the new version of the distribution order data can be saved 409 with a generally smaller audit file.

If the updated versions of the ZAV data are only made available as incremental databases, each database is combined with the current version of the distribution order data to form a new full version of the distribution order data. As shown in FIG. 4, the current version of the distribution order data is first read 500 from the hard disk. In this case, a hash table is typically built 501 in the memory according to the usual programming technique in order to enable the delivery points to be found quickly afterwards. The identification data already mentioned, which is formed from the sort code + house number extension + remark of a delivery point, serves as the key in the hash table. However, some ZAV databases do not have any sort codes, in this case the correct sort code is generated during the import.

All new delivery points are processed 502 one after the other. The first step is to check whether the delivery point already exists 503. If the new delivery point already exists, its relative position is compared 504 with the previous relative position. If the positions are the same, no further action is necessary. If the positions are different, the delivery point is entered 505 in a list of delivery points that are to be deleted. These delivery points to be moved are also entered 506 like new delivery points in a list of the new delivery points. position points were edited 507, all delivery points to be deleted are removed 508. All new or moved delivery points are then added 509. Finally, the new version of the distribution order data can be saved 510. Empty sections and empty districts are omitted.

The QoS features from another central application system are provided as a file. A characteristics file can be combined with the current version of the distribution order data to form a new version. As shown in FIG. 5, the current version of the distribution order data is first read 600 from the hard disk. A hash table is built up 601 in memory according to the usual programming technique as already described above. All features in the file are processed 602 one after the other, whereby first it is checked whether the delivery point concerned exists at all 603. If the delivery point exists, the previous characteristics are combined with the new characteristics, the new characteristics having priority 605. The supplemented data record is stored in the distribution order data and as a complete SET entry in the audit file is saved 606. If the delivery point concerned is not available, an entry is logged in an error file 604. After all delivery points have been processed 607, the new version of the distribution order data is saved.

Individual audit files can be combined with the current version of the distribution order data to form a new full version. This functionality enables the parallel processing of the distribution order data by several operators. As shown in FIG. 6, the current version of the distribution order data is first read 700 from the hard disk. A hash table is constructed 701 in the memory according to the usual programming technique as described above. All audit entries from the audit file are processed 702, and first it is checked whether each entry is still 703 is valid. If an entry cannot be applied, for example because the delivery point is missing, the entry is saved 706 in the audit log file. If the entry can nevertheless be used, the change is made 704 and a new entry is made in the new audit file is saved 705. After all audit entries have been processed, the new version of the distribution order data is saved 708.

Claims

claims

1. A method for the automatic generation of current distribution order data, including central address directories stored in databases and transmitted by electronic data transmission as distribution order data, with the steps:

- Transfer of locally stored change commands regarding relative position changes of delivery points in the distribution order for the previous version of the central address directory or the relevant parts, the delivery points being identified on the basis of identification data which contain at least the sort code to the local copy of the current central address directory or the relevant parts,

- Storage of the valid change commands still to be executed in an audit file and execution of the change commands.

2. The method according to claim 1, wherein additional house number extensions are included locally in the identification data.

3. The method according to claim 1 or 2, wherein additional characteristic comments are included locally in the identification data.

4. The method according to claim 3, wherein the following steps are carried out to include forwarding and / or distribution instructions in the copied address directory: - Check whether the delivery point for the respective forwarding and / or distribution notice exists in the copied current address directory for the distribution order data, if yes,

- Paste the new forwarding and / or distribution information into the copied address directory, the new over the old similar forwarding and / or distribution information and

- Inclusion of the complete change data of the forwarding and / or distribution information in the audit file.

5. The method according to any one of claims 1 to 4, wherein to update the central address directory or address directory parts only incremental changes are transmitted by data transmission, which are merged with the previously updated and copied address directory or address directory part by using the identification data for each delivery point in the previously current address directory or part of the address directory, it is checked whether the respective delivery point of the incremental change already exists, if not, it is included in the copied address directory or part of the address directory in the position of the distribution order transmitted, if so, the respective delivery point is sent to changed position in the address directory moved.

6. The method according to claim 5, wherein for realizing the shifting of a delivery point, this is deleted at the previous position of the address directory and is newly entered at the changed position.