WO2007098930A1 - Verfahren und kommunikationsanordnung zur datenübermittlung zwischen mindestens zwei teilnehmern eines transportgut- oder personen-transportprozesses - Google Patents

Verfahren und kommunikationsanordnung zur datenübermittlung zwischen mindestens zwei teilnehmern eines transportgut- oder personen-transportprozesses Download PDF

Info

Publication number
WO2007098930A1
WO2007098930A1 PCT/EP2007/001696 EP2007001696W WO2007098930A1 WO 2007098930 A1 WO2007098930 A1 WO 2007098930A1 EP 2007001696 W EP2007001696 W EP 2007001696W WO 2007098930 A1 WO2007098930 A1 WO 2007098930A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
central computer
local
computer
transport
Prior art date
Application number
PCT/EP2007/001696
Other languages
English (en)
French (fr)
Inventor
Stefan Alexander Ganskow
Original Assignee
Act Aviation Centre Of Technology Gmbh
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 Act Aviation Centre Of Technology Gmbh filed Critical Act Aviation Centre Of Technology Gmbh
Publication of WO2007098930A1 publication Critical patent/WO2007098930A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/02—Reservations, e.g. for tickets, services or events
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/04—Forecasting or optimisation specially adapted for administrative or management purposes, e.g. linear programming or "cutting stock problem"
    • G06Q10/047—Optimisation of routes or paths, e.g. travelling salesman problem

Definitions

  • the invention relates to a method for data transmission between at least two participants of a transport goods or person transport process according to the preamble of claim 1 and a communication arrangement for carrying out such a method according to the preamble of claim 12.
  • the logistics industry has long known various communication systems that are used to tune and track a shipment of a cargo.
  • the communication systems used so far use different communication channels.
  • a transmission of data that are necessary for the transport of a cargo for example, by telephone, fax or direct transfer of appropriate documents with the shipment from a participant of the transport process to another participant of the transport process instead.
  • IATA International Air Transport Association
  • the present invention has for its object to develop on the basis of existing Transportguttransportsysteme a communication system that automatically handles the necessary for a transport of a cargo or a person processes.
  • This object is achieved by a method for data transmission between at least two participants of a transport goods or person transport process according to claim 1 and a communication arrangement for carrying out such a method according to claim 12.
  • At least one central computer is used and each participant is assigned a local computer.
  • Transport-process-relevant data are recorded in at least one of the local computers.
  • the Local computers are connected to the central computer such that a
  • the data may be sent only to those subscribers who are actually in the transport chain. This can avoid that data that does not have a special meaning for a specific participant, burdening its resources. In this case, it can be determined for each transport process which participants should receive which information, wherein stored preference values can be used for this determination and the determination can thus be made automatically.
  • the participants or participants in the transport process are preferably handling agents, export or import carriers, consignors of a consignment to be transported, recipients of such a consignment, customs officials and / or carriers.
  • carriers in particular airlines into consideration.
  • the transported goods to be transported are preferably goods and / or goods, so that the transport process considered is preferably a freight transport process.
  • the transport process-relevant data are recorded in the local computer, it is preferable to compare these data with data provided by the central computer, the central computer being able to access one or more databases for this purpose. In this case, it is not necessary to access the central computer directly during the data acquisition, since the information stored in the central computer is regularly transmitted to the local computer. By such a synchronization of the local computer with the central computer, the actual comparison between the acquired data and the stored information is thus preferably directly on the local computer.
  • Such reconciliation may include, for example, information in the form of information about the transporter (address, etc.), the carriers' schedules or schedules, legal and / or customs regulations, international agreements (eg the GATT Agreement), Information about the available means of transport (eg load capacity, dimensions of the hold, etc.) and / or provisions of the carriers, which may sometimes deviate from the other provisions suitable.
  • a computer-controlled selection of the data to be acquired is preferably carried out as a function of the information provided via the central computer.
  • the data required for a transport process from the local machine May vary on a case-by-case basis depending on the type of cargo or countries in which the consignee or consignor is established.
  • Participant who enters the data as long as prompted to correct the errors until an error-free data entry is made. Only after the elimination of all errors, the data are considered successfully collected and transmitted to the central computer.
  • the method is preferably designed such that a language from a group of multiple languages can be selected on each local computer in which the data input and data representation takes place.
  • the data transmission itself is executed language-independently by reference codes.
  • the sender can enter transport process-relevant data in German in his local computer, these are then coded language independent first transferred to the central computer and from there, inter alia, to the receiver, which gets the data displayed on his local computer, for example in French.
  • the method is performed with only one possible language.
  • each participant can additionally record in the local computer associated therewith such data for which there is no official standard (this includes, for example, data from the data sets of the address data or article designations) and in that respect initially are not stored in the central computer and therefore can not be provided by the central computer in the form of information available. That is, in this preferred embodiment of the invention, each participant in his view for the Transport process relevant data to the communication system, within which the inventive method is performed, add and thus expand the database (s) in which the information provided by the central computer information is stored. Thus, after the first entry of the data for which there is no official standard, it becomes possible for the central computer to provide this data as information so that all other subscribers can profit from it.
  • the database (s) are thus upgraded by means of user intelligence.
  • a communication arrangement for carrying out a method according to the invention has a plurality of local computers and at least one central computer. Each participant in the transport process is assigned a local computer, wherein the local computer and the central computer are arranged in a data-transmitting network that data can be transmitted between the local computers and the central computer.
  • the Internet As a data-transmitting network preferably the Internet is used. But other networks such as the SITA system are suitable for data transmission.
  • the local computers are designed in a preferred embodiment of the invention as a local server and have only a limited range of functions. That is, they can only perform necessary applications for carrying out a method according to the invention. This avoids, among other things, capacities and errors that can occur due to the parallel execution of different applications due to incompatibilities.
  • the latter are preferably integrated into an existing server system or connected directly to a common personal computer, which acts as a client.
  • the client then serves as an interface between the local server and the subscriber.
  • the communication arrangement is preferably designed such that the number of central computers is measured by the number of conveyors that are integrated in the communication arrangement.
  • a separate central computer can be provided for each transporter.
  • the respective databases, which are accessed by the individual central computers in such a case, are synchronized with one another in order to provide an identical basic database for all central computers.
  • Fig. 1 is a schematic representation of a first known in the art communication system between the participants of a
  • FIG. 2 shows a schematic illustration of a second communication system known in the prior art between the participants of a transport process, wherein the communication system has an integrator;
  • FIG. 3 shows a schematic representation of a third communication system known in the prior art between the participants in a transport process
  • Fig. 4 is a schematic diagram of a communication system according to the present invention.
  • FIG. 5 is a schematic representation of a communication arrangement according to the invention.
  • FIG. 1 represents a schematic model of known communication processes in the air freight sector and in other transport sectors for the transmission of data. For the sake of simplicity, only the most important parties to a logistics chain or subscribers of a transport process are shown.
  • Manual communication steps (m) are shown by solid lines.
  • the term "manual" is intended to describe those communication steps that do not take place automatically between the participants in the transport process, but rather require an interaction of the subscriber who receives the data in order to feed the transmitted data into a (central) data exchange system irrespective of whether computers or other communication devices, such as, for example, telephones or fax machines, are used for this purpose of communication
  • Examples of such manual communication steps are telephone calls, fax transmissions or the sending or receiving of e-mails.
  • Online communication steps (o) are represented by dashed lines.
  • the term "online” should be understood to mean those communication steps which take place automatically between the participants in the transport process, ie require no interaction of the data-receiving subscriber in order to feed the transmitted data into a (central) data exchange system directly using computers.
  • Communication steps which alternatively can be done manually or online (m / o), are represented by dotted lines.
  • the arrowhead indicates the direction of the communication in all communication steps. Arrowheads at both ends of connecting lines show that the corresponding communication is bidirectional.
  • a transport process according to the known communication sequence shown in Figure 1 is carried out according to the following steps, based on of an example. It is assumed that the largest distance of the transport route is handled by an aircraft, a transported item is transported as air cargo. Alternatively, any other means of transport (such as rail or ship) could be used; the basic transport processes are similar.
  • a shipper 10 issues to an export carrier 11 a pick-up of a shipment from the company's headquarters in A and to organize transport of the shipment to a receiver 20 in B.
  • the export carrier 11 now determines the nearest or least accessible starting airport A from A to B nearest or most favorable to reach destination airport 22. He then determines an airline 30, which can provide the desired transport performance and books, for example, by phone or by Fax a corresponding transport for the shipment. It is often the case that the export carrier 11 does not communicate directly with the airline 30, but with a representative or a General Sales Agent (GSA) on site (not shown in Fig. 1). Alternatively, the export carrier 11 could book a transport for the shipment via an Internet portal of the airline 30 online.
  • GSA General Sales Agent
  • the export carrier 11 After successful booking with the airline 30, the export carrier 11 sends the sender 10 by fax, telephone or e-mail a booking confirmation.
  • the export carrier 11 usually fills out an air waybill (AWB) with all the data available about the consignment to be transported, whereby he usually uses a computer for this purpose.
  • ABB air waybill
  • the exporter 11 gives a printout of the bill of lading a representative of the airline 30 at the departure airport 12 from.
  • Such a representative is usually a so-called handling agent 13.
  • a handling agent 13, 23 nowadays has to operate a plurality of computer systems in parallel in order to be able to work together with as many carriers 30 as possible.
  • the data of the booking and the air waybill are in the computer system of the airline 30 internally available worldwide and editable.
  • handling agents 33; 23 are already informed at a transit station 32 and / or at the destination airport 22 at the time of booking that the corresponding consignment is to be expected.
  • the transit station 32 shown in the diagram is not mandatory required station of the explained transport process. If a direct transport from the start 12 to the destination airport 22 is possible, this is usually preferred. Conversely, it is also conceivable that the shipment is transported via more than one transit station 32; this depends on the respective schedules of the airlines 30.
  • a shipment arriving at a transit station 32 is checked and its arrival in the system confirmed. Simultaneously or subsequently, the shipment is released for further transport. If necessary, the consignment is subjected to an official operation by Customs 34. All actions performed by the handling agent 33 at the transit station 32 can be tracked by the airline 30 via its telex system SITA when the handling agent 33 notifies these actions via the SITA system.
  • the handling agent 23 at the destination airport 22 electronically confirms the proper arrival of the shipment to the airline 30.
  • the airline 30 usually notifies an import carrier 21 of the arrival of the shipment manually.
  • a check-in by the customs 24 and a communication with the receiver 20 are now equivalent to the processes described above at the sender 10, the order is exactly the opposite.
  • the shipment is finally delivered by the import carrier 21 to the receiver 20, which was not previously informed about the expected shipment in the rule.
  • FIG. 2 schematically shows the communication processes of a transport process, which are also part of the state of the art, involving a so-called integrator.
  • the communication steps may be carried out in the ways set forth in the description of Figure 1;
  • the representation of the various types is analogous to Figure 1. Participants of the transport process, which have already occurred in the figure 1, are provided with the same reference numerals.
  • an integrator 40 thus integrates the export and import carrier 11; 21, the handling agents 13; 23; 33 at the start 12 and destination airport 22 and at an optional transit station 32, the haulier of the pre-and post-run and usually also the airline 30 for air freight transport itself.
  • Such integrators include the companies DHL, UPS and Fedex.
  • the integrator system lies between the postal system and the airfreight system. In FIG. 2, all those tasks which the integrator 40 assumes, or the functional units which the integrator 40 integrates, are arranged within the centrally placed large ellipse.
  • 21 designated participants of the transport process can also be arranged transporters of the lead and lag at the same point in the communication scheme. In that case you would In summary, in the case of an integrator-based transport process, the sender 10 and the receiver 20 come into contact only with this service 11, 21 of the integrator 40.
  • the respective communication between the individual functional units of the integrator 40 takes place online via an air freight transport coordination 41.
  • the integrators 40 use computer systems which accompany all internal areas of the freight transport.
  • the communication between the integrator 40 and the sender 10 or the receiver 20 and between the integrator 40 and the inch 14; 24; 34 manually or online. Direct access by the sender 10, the receiver 20 or the customs 14; 24; 34 on the transport process relevant data of the integrator 40 is not possible in this system.
  • FIG. 3 as a further prior art, a communication model of what is known as e-logistics is shown schematically. The communication steps may be carried out in the ways set forth in the description of Figure 1; The representation of the various types is analogous to Figure 1. Participants of the transport process, which have already occurred in the figure 1, are provided with the same reference numerals.
  • e-logistics is the attempt to map a logistics process over the Internet in parallel to what is known as e-business.
  • a logistics process can, as shown in FIG. 3, be the transport of a shipment from a departure airport 12 to a destination airport 22.
  • e-logistics solutions do not provide direct access to connected airline servers, e-logistics services are currently essentially limited to online bookings and so-called tracking & tracing.
  • tracking & tracing By this term one understands the Query the status of a shipment, for example, at which location of the logistics chain a shipment is currently located. This always indicates the last place where the consignment was recorded.
  • both the shipper 10 and / or the recipient 20 and the export and / or import carrier 11; 21 send a status query for the purpose of tracking & tracing or a booking request to a web server 35, which then forwards this request to the airline 30.
  • the aforementioned participants in the transport process can carry out further work such as completing a bill of lading.
  • the communication is only one way: from each participant 10; 11; 20; 21 to the web server 35.
  • the subscribers 10; 11; 20; 21 are not actively involved in a network but can only view data stored on the web server 35.
  • FIG. 4 schematically shows a communication system according to the present invention.
  • the communication steps may be carried out in the ways set forth in the description of Figure 1;
  • the representation of the various types is analogous to Figure 1. Participants of the transport process, which have already occurred in the figure 1, are provided with the same reference numerals.
  • the core of this system is a so-called BATCH system, which consists of a central computer 50 and several local computers, each participant of the transport process has at least one local computer.
  • the system is intended for all participants of an airfreight market.
  • the conception is based on a complete solution in terms of IT processing of shipments for shippers 10, consignees 20, export and import carriers 11; 21, handling agents 13; 23, airlines 30 and all other related carriers such as pre-carriage and on-carriage, etc.
  • the transfer of information to relevant authorities - such as Customs 14; 24; 34 - an important element of functionality.
  • the BATCH system allows all relevant participants 10; 11; 13; 14; 20; 21; 23; 24; 30; 33; 34 unite a transport process in a network, wherein an active communication between the individual participants 10; 11; 13; 14; 20; 21; 23; 24; 30; 33; 34 runs through a central server 50.
  • the BATCH system offers the airlines the possibility to give an answer to the logistic concept of the integrators shown in the figure 2, in that all work processes can be completely integrated over the BATCH system.
  • the BATCH system also includes the sender 10 and the receiver 20 in the network.
  • FIG. 4 again only the relevant subscribers 10; 11; 13; 14; 20; 21; 23; 24; 30; 33; 34 reproduced on the transport process.
  • a shipper 10 If a shipper 10 has to issue a transport order, then he transmits this electronically with all relevant data to the shipment to be transported to the central computer 50 of the BATCH system. From there, he will be forwarded to the responsible export carrier 11.
  • the receiver 20 can already be included in the booking process with the new transport process.
  • the transport request is used to transmit a booking request to a suitable airline 30.
  • all participants of the transport process ie each participant who will deal with the physical shipment - such as the handling agents 13; 33; 23 of the departure airport 12, the optional transit station 32 and the destination airport 22, the airlines 30 in the transfer and the Importspediteur 21 - in advance about the shipment to be transported informed so-called "preadvise”.
  • the export carrier 11 completes the air waybill to complete its data on the consignment to be transported.
  • the data changed in this way is communicated to all participants via the server 50 of the BATCH system.
  • the handling agent 11 of the departure airport 12 now awaits the physical shipment. If he receives these, he will carry out a check-in of the shipment in his warehouse system, whereupon the BATCH system compares the data of the booking with those of the bill of lading and the stock. If the data is unique, the BATCH system releases the freight for transport.
  • the shipment can be released ("released") on the optional transit stations 32 and at the destination airport 22 immediately after the physical arrival.
  • BATCH in the sense of the word means an electronic implementation of a batch process, which means that all documents of a transport order are electronically mapped in the BATCH system.Thus, delivery notes and invoices of the shipper 10 as well as documents for customs clearance are part of this batch processing and the BATCH system. system.
  • Documents required for a specific transport process such as those for the transport of dangerous goods or live animals, are provided in the BATCH system via individual modules and assigned electronically to the corresponding transport process.
  • the communication between all participants 10; 11; 13; 14; 20; 21; 23; 24; 30; 33; 34 and the central server 50 bidirectionally.
  • the BATCH system actively notifies the user of the status of a particular shipment. The user must therefore Do not act on your own, for example to carry out a tracking & tracing. It is part of the network during the duration of a transport process.
  • FIG. 5 shows a schematic representation of a communication arrangement according to the invention.
  • such a communication arrangement has at least one user-side or local substructure L, which has the function of a local computer, and at least one server-side or central substructure Z, which has the function of a central computer.
  • the local substructure L is assigned one or more local clients 60.
  • a transmission of data AU occurs in such a communication arrangement from and to a local database 62 and a configuration database 63 via an application server 61.
  • local communication management 64 has direct access to the local database 62 and the configuration database 63, which information and information transmission AG; IU from and to a data-communicating network 65 handles.
  • a network may, for example, be the Internet or a network made up of telecommunication links in the context of the SITA system or the PSTN (Public Switched Telephony Network).
  • the local database 62 or the configuration database 63 For a direct transmission of information IU between the application server 61 and the local communication management 64 provide communication interfaces 66a, 66b, which are associated with the application server 61 and the local communication management 64. Data or information or information that can not be transmitted directly from the local communication management system to the data-transmitting network 65 or the local clients 60, the local database 62 or the configuration database 63 is buffered in a queue 641 assigned to the local communication management 64 ,
  • a central communication management 67 equivalent to the local communication management 64 controls the data flow from and to the data-transmitting network 65.
  • Data that can not be forwarded directly by the central communication management 67 are buffered in a waiting loop 671 of the central communication management 67.
  • From the central communication management 67 information can be transmitted directly to an authentication database 68.
  • this authentication database 68 inter alia, data are stored which make it possible to check data or information arriving from the data-transmitting network 65 as to whether they originate from an authorized user and thus whether a forwarding of such information or information from the central communication management 67 to a server Application 69 should take place.
  • communication takes place between the central communication management 67 and the server application 69 via communication interfaces 66c, 66d, which are assigned to the central communication management 67 or the server application 69.
  • This database interface 70 ensures activation of at least one central database 71 on which transport process-relevant data such as, for example, flight schedules or information about international regulations are stored.
  • the communication arrangement has not just one but several local substructures or computers L, for example one for each participant in the transport process. It is also possible to use a plurality of central substructures or central computer Z, for example for each transporter. The number of local computers L will generally far exceed the number of central computers Z.
  • the BATCH system reduces complex processes at the respective possible points to a few key formats that correspond to the workflow.
  • the BATCH system is provided in modules, with each user of the BATCH system receiving only those program parts that are necessary for his workflow.
  • ABB air waybill
  • IATA International Air Transport Association
  • ICAO International Civil Aviation authorities
  • An employee of a logistics company forwarding agency, handling company, export department of a shipper
  • a sender finds the same forms he first used manually when using the BATCH system for the first time.
  • a sender is shown a so-called Shippers Letter of Instruction (SLI) 1 by one of the employees of a forwarding agency, for example the air waybill (AWB) and an employee of an air freight handling company, a so-called manifest by the BATCH system.
  • SLI Shippers Letter of Instruction
  • ARB air waybill
  • manifest by the BATCH system.
  • the respective form is not encrypted, but can be filled in immediately in electronic version.
  • the respective user sees the corresponding electronic form in faithful reproduction, just as he knows the paper form from manual editing.
  • the user can have the BATCH system work in a variety of cases and is assisted in filling in the forms from one or more intrinsic database (s), as set forth in the next example.
  • the BATCH system will only accept booking requests for flights using aircraft capable of transporting live animals and withstanding loads of at least 1000 kg on the ground.
  • the BATCH system will now provide the user with information that he or she must consider in documentary form, such as quarantine regulations in any transit country or in Mexico itself.
  • the user also receives information as to whether the handling agents involved have special premises and storage facilities for animals.
  • a preadvise about the transport to be made is automatically sent to the desired airline.
  • the BATCH system also checks numerous other data, so that the actual transport process can finally be handled quickly and without avoidable complications.
  • the good data also helps to select the optimum tariff for the shipment from the database of the BATCH system.
  • the forms necessary for the transport of live animals (AVI) and those conforming to the provisions of the General Agreement on Tariffs and Trade (GATT) as well as the customs documents required for export and import are provided and prefabricated, so that these can only be made in a few moments must be supplemented.
  • the common language of airfreight is English. However, the trend is already observable that many handling staff do not speak English well enough to be able to read manuals, for example. However, the manuals are part of the database of the BATCH system. To reduce language barriers, the BATCH system therefore allows data entry in different languages. For example, if a user mentions "gas" as the content of his shipment, the BATCH system compares that word with the information stored in the database, with the databases being referenced via a key (common practice for databases) be connected to any language.
  • the BATCH system also recognizes that the consignment to be transported is a dangerous good. The user can only send the consignment if he has the necessary DGR forms (Dangerous In this context, the BATCH system supports the user, since most of the data required to complete the form is extracted from the database and entered in the corresponding form fields.
  • the BATCH system is arranged in a (global) network, which connects all users with regard to information technology, the overall data situation is available to all involved at any time. There are only individually adjustable restrictions with regard to the permitted data access by the respective user on the part of the BATCH system in order to protect personal or company-internal data of the respective user and to prevent unauthorized access of other users to this data (see Example 9).
  • the BATCH system allows its customers to repeatedly access data already entered into the global network. While after the State-of-the-Art Communication System Solutions If data is frequently entered multiple times into local, isolated computer systems, multiple processing of the same data can be excluded in the BATCH system.
  • a sender conveys the data necessary for air freight transport, for example, by fax to his carrier, who manually transfers the data to his forwarding system, prints the air waybill and hands it to the handling agent, who then transmits the data again to his internal computer system ,
  • a consignor has entered the following data in the Shippers Letter of Instruction (SLI): a consignor, a consignee, a departure airport, a destination airport, any transit stations, a desired carrier, a desired airline, a departure date, a booking proposal, the measures of Consignment, the volume of the consignment, the weight of the consignment, the contents of the consignment, details of the method of payment, details of the value of the consignment, information on the status of the consignment, details of the necessities of handling and accounting.
  • SLI Shippers Letter of Instruction
  • the forwarder then only sends the modified data over the network.
  • the handling agent can even work with drag and drop without opening or processing the forms it receives, as long as the data of the transport process is consistent (that is, if the details of the incoming air waybill are the same) desired booking and its inventory match).
  • the BATCH system thus guarantees an optimization of the deployment of the employees.
  • the following example describes the automatic error prevention by the BATCH system.
  • the BATCH system contains databases of airline-specific information such as schedules and internal regulations (embargoes, collection rules, etc.) that inform a BATCH system user about the requirements of each airline and also about international regulations. Furthermore, a comparison of the data entered by the user into the system with the stored information or a check on the basis of this information.
  • schedules and internal regulations embargoes, collection rules, etc.
  • the entered data can also be corrected on the basis of the stored information. Furthermore, a targeted control of the input process on the basis of the stored data is conceivable and intended to actually capture all relevant and required for an individual transport process data. It is very important that errors are largely excluded in order to increase the efficiency of processing and also to avoid damage - such as customs damage, planning errors, penalties, etc. -.
  • the databases of the BATCH system preferably contain all the relevant data of the airlines, such as booking information, capacity options of the aircraft and also planning proposals for the most suitable capacity utilization.
  • the BATCH system enables the user to always work at the limit of the best possible.
  • the result of this optimization is a better utilization of the capacities (for example, the capacity of the hold of an aircraft or the storage space at one of several possible transit stations) and a faster processing of the processes (the employees do not have to read manuals).
  • the BATCH system checks all entered data by comparing it with the stored data and makes necessary conversions (for instance between different currencies or units of measurement) as well as the calculation of the volume of a shipment on the basis of the entered data the dimensions of the shipment immediately before or after entry.
  • necessary conversions for instance between different currencies or units of measurement
  • the BATCH system is able to enable the respective airlines involved to optimize the utilization of the cargo holds of the aircraft, which enables the airlines to optimize the so-called load factor.
  • the BATCH system also takes into account the dimensions of the consignment to be transported in the selection of the possible flight connections, so as to ensure that only those aircraft are offered to the user for the transport of the consignment, which has a sufficiently large door or the size of the shipment. Have load compartment hatch to record the shipment can.
  • the information of, for example, the volume of a shipment is often estimated and usually no longer controlled so that there may be large differences between the booking and the actual shipments to be carried.
  • a big advantage of the BATCH system is that a user can freely choose the preferred medium for data transmission.
  • the BATCH system is able to communicate virtually using all known transmission media.
  • the BATCH system is preferably equipped with an internal communication management, which sends the data over the Internet. When transmitting data over the Internet, the market standard of the highest data security is maintained.
  • the data must be transmitted to the central computer at the latest immediately after the departure of the aircraft. For example, if the departure airport is Berlin and a shipment is to be transported to Mexico, then that shipment must be reloaded to a European airport if an airline that does not fly directly from Berlin to Mexico has been selected. In this case, only about 2 to 3 hours remain until the cargo arrives at the transit station. At the latest at this time, the data must also be on site.
  • the BATCH system does not rely on a communication path but allows alternatives.
  • the handling agent in the above example case in case of failure of the Internet can also send its data via a fax modem or a Telfonkoppler etc. It would also be possible to use the SITA system. The good availability and the favorable cost-benefit ratio alone make the Internet the preferred communication medium for the BATCH system.
  • Software Service is understood as the provision of program updates.
  • a remote computer can be used to remotely access a local computer (remote trouble shooting).
  • users are provided with updates to the system-internal databases via the BATCH system and integrated into the local system so that all users of the BATCH system always have the latest system status.
  • a central computer and one or preferably several local computers are used.
  • the task of the central computer is taken over by a network server with corresponding communication management connection.
  • the communication management connection can be designed in a multi-layered way to provide the users with a provide a wide range of communication channels (eg data transmission via the Internet, via the SITA telex system, etc.).
  • the task of the local computer is taken over by a hardware component which is used as a local server.
  • This hardware component referred to as a "black box”
  • black box can be easily connected by a user to an existing server system
  • the black box represents a reduced server system, which apart from applications of the BATCH system can not perform any further services. This limited functionality results in several advantages:
  • a unified computer system also allows easy communication with all users, for example to load updates.
  • the black box can connect to the central computer even in case of difficulties (eg via cron tables) and report any errors that have occurred (for example, the hard disk capacity or the capacity of another used memory such as a flash memory of the black box 70%, which would be indicative of a storage malfunction). Since the black box can be preconfigured, installation problems can be avoided and a simple replacement of the black box can be made possible.
  • Such a data protection law separation principle also applies to the use of the black box.
  • the BATCH system is platform-independent and can therefore be used under all common operating systems.
  • Current software standards are used, such as: B. a data exchange in XML format using application services.
  • B. a data exchange in XML format using application services.
  • In the database area both established systems of market leading companies and software systems from the so-called open source area are used.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • Tourism & Hospitality (AREA)
  • Economics (AREA)
  • Operations Research (AREA)
  • Marketing (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Quality & Reliability (AREA)
  • Development Economics (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Game Theory and Decision Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zur Datenübermittlung zwischen mindestens zwei Teilnehmern (10; 11 ; 13; 14; 20; 21 ; 23; 24; 30; 33; 34) eines Transportgut- oder Personen-Transportprozesses unter Verwendung mindestens eines Zentralrechners (Z, 50), wobei jedem Teilnehmer (10; 11 ; 13; 14; 20; 21 ; 23; 24; 30; 33; 34) ein lokaler Rechner (L) zugeordnet ist und in mindestens einem der lokalen Rechner (L) transportprozessrelevante Daten erfasst werden und wobei jeder lokale Rechner (L) mit dem Zentralrechner (Z, 50) kommunizieren kann, wobei ferner die Datenübermittlung zwischen jedem der Teilnehmer (10; 11 ; 13; 14; 20; 21 ; 23; 24; 30; 33; 34) und dem Zentralrechner (Z, 50) direkt, automatisiert und bidirektional erfolgt, wobei die transportprozessrelevanten Daten jedes Teilnehmers (10; 11 ; 13; 14; 20; 21 ; 23; 24; 30; 33; 34) über den Zentralrechner (Z, 50) jedem anderen Teilnehmer (10; 11 ; 13; 14; 20; 21 ; 23; 24; 30; 33; 34) zugänglich gemacht werden und wobei jeder der Teilnehmer (10; 11 ; 13; 14; 20; 21 ; 23; 24; 30; 33; 34) über die transportprozessrelevanten Daten jedes jeweils anderen Teilnehmers (10; 11 ; 13; 14; 20; 21 ; 23; 24; 30; 33; 34) während des Transportprozesses aktiv durch den Zentralrechner informiert wird. Die Erfindung betrifft ferner eine Kommunikationsanordnung zur Durchführung eines solchen Verfahrens.

Description

Verfahren und Kommunikationsanordnung zur Datenübermittlung zwischen mindestens zwei Teilnehmern eines Transportgut- oder Personen- Transportprozesses
Beschreibung
Die Erfindung betrifft ein Verfahren zur Datenübermittlung zwischen mindestens zwei Teilnehmern eines Transportgut- oder Personen-Transportprozesses gemäß dem Oberbegriff des Anspruchs 1 und eine Kommunikationsanordnung zur Durchführung eines solchen Verfahrens gemäß dem Oberbegriff des Anspruchs 12.
In der Logistikbranche sind seit langem verschiedene Kommunikationssysteme bekannt, die dazu eingesetzt werden, einen Transport eines Transportguts abzustimmen und zu verfolgen. Die bislang eingesetzten Kommunikationssysteme verwenden dazu unterschiedliche Kommunikationswege. So findet eine Übermittlung von Daten, die zum Transport eines Transportguts notwendig sind, beispielsweise per Telefon, Telefax oder durch direkte Übergabe entsprechender Schriftstücke mit der Sendung von einem Teilnehmer des Transportprozesses zu einem anderen Teilnehmer des Transportprozesses statt.
Die Verwendung unterschiedlicher Kommunikationsmittel hat den Nachteil, dass Daten, die das Transportgut betreffen, oft mehrfach während des gesamten Transportprozesses erfasst werden müssen. Damit geht sowohl ein hoher Arbeitsaufwand als auch eine Fehleranfälligkeit bei der Datenübermittlung einher.
Insbesondere im Luftfrachtbereich hat es sich als nachteilig erwiesen, dass eine Vielzahl von Papierformularen für einen Transportvorgang ausgefüllt werden müssen - im Durchschnitt sind 38 Dokumente pro Transportvorgang erforderlich.
Die IATA (International Air Transport Association) hat es sich daher unter dem Projektnamen „IATA e-freight" zur Aufgabe gemacht, bis zum Jahr 2010 eine papierlose Abwicklung des Lufttransports zu entwickeln. Bis dahin ist das klassische System aber noch weiterhin im Einsatz.
Der vorliegenden Erfindung liegt die Aufgabe zugrunde, auf der Grundlage bestehender Transportguttransportsysteme ein Kommunikationssystem zu entwickeln, das die für einen Transport eines Transportguts oder einer Person notwendigen Vorgänge automatisiert abwickelt.
Diese Aufgabe wird durch ein Verfahren zur Datenübermittlung zwischen mindestens zwei Teilnehmern eines Transportgut- oder Personen- Transportprozesses gemäß Anspruch 1 und eine Kommunikationsanordnung zur Durchführung eines solchen Verfahrens gemäß Anspruch 12 gelöst.
In dem erfindungsgemäßen Transportprozess wird mindestens ein Zentralrechner eingesetzt und jedem Teilnehmer ein lokaler Rechner zugeordnet. In mindestens einem der lokalen Rechner werden transportprozessrelevante Daten erfasst. Die lokalen Rechner sind mit dem Zentralrechner derart verbunden, dass ein
Datenaustausch zwischen den lokalen Rechnern und dem Zentralrechner
• stattfinden kann. Dieser Datenaustausch erfolgt erfindungsgemäß zwischen jedem
Teilnehmer des Transportprozesses und dem Zentralrechner direkt, automatisiert und bidirektional, also sowohl von den lokalen Rechnern zum Zentralrechner hin als auch in umgekehrter Richtung. Dabei werden die transportprozessrelevanten
Daten jedes Teilnehmers über den Zentralrechner jedem anderen Teilnehmer zugänglich gemacht und aktiv an jeden anderen Teilnehmer übermittelt, so dass allen Teilnehmern stets die gleichen Daten eines Transportprozesses auf ihren jeweiligen lokalen Rechnern zur Verfügung stehen.
Statt die Daten an jeden anderen Teilnehmer zu senden, können die Daten alternativ auch nur an diejenigen Teilnehmer gesendet werden, die tatsächlich in der Transportkette stehen. Dadurch kann vermieden werden, dass Daten, die für einen bestimmten Teilnehmer keine besondere Bedeutung haben, seine Ressourcen belasten. Es kann dabei vorzugsweise für jeden Transportprozess bestimmt werden, welche Teilnehmer welche Informationen erhalten sollen, wobei zu dieser Bestimmung auf gespeicherte Vorzugswerte zurückgegriffen werden kann und die Bestimmung somit automatisch erfolgen kann.
Die Teilnehmer bzw. Beteiligten des Transportprozesses sind vorzugsweise Handlingsagenten, Export- oder Import-Spediteure, Versender einer zu transportierenden Sendung, Empfänger einer solchen Sendung, Zollbedienstete und/oder Transporteure. Dabei kommen als Transporteure insbesondere Fluggesellschaften in Betracht.
Das zu befördernde Transportgut sind vorzugsweise Waren und/oder Güter, so dass es sich bei dem betrachteten Transportprozess vorzugsweise um einen Frachttransportprozess handelt.
Um eine möglichst frühzeitige Information aller Beteiligten des Transportprozesses zu gewährleisten, die die Grundlage einer möglichst reibungsfreien Abwicklung des gesamten Prozesses ist, werden alle relevanten Beteiligten bevorzugt vor dem physikalischen Kontakt mit dem Transportgut bzw. der zu befördernden Person (Passagier) mittels des Zentralrechners über das abzufertigende Transportgut bzw. die abzufertigende Person informiert. Diese Information erfolgt am besten, sobald die Daten über das Transportgut bzw. den Passagier zum ersten Mal dem Zentralrechner übermittelt wurde, was in der Regel durch den Versender des Transportguts oder den Passagier bzw. einen Reisebüro- Angestellten beim Buchen eines Flugs erfolgt.
Wenn die transportprozessrelevanten Daten im lokalen Rechner erfasst werden, erfolgt vorzugsweise ein Abgleich dieser Daten mit Angaben, die über den Zentralrechner zur Verfügung gestellt werden, wobei der Zentralrechner zu diesem Zweck auf eine oder mehrere Datenbanken zugreifen kann. Dabei ist es nicht notwendig, während der Datenerfassung direkt auf den Zentralrechner zuzugreifen, da die Angaben, die im Zentralrechner gespeichert sind, regelmäßig auf die lokalen Rechner übermittelt werden. Durch eine solche Synchronisierung der lokalen Rechner mit dem Zentralrechner erfolgt der tatsächliche Abgleich zwischen den erfassten Daten und den gespeicherten Angaben also vorzugsweise direkt auf dem lokalen Rechner.
Zu einem solchen Abgleich sind beispielsweise Angaben in Form von Informationen über den oder die Transportprozessteilnehmer (Adresse etc.), die Flug- oder Fahrpläne der Transporteure, gesetzliche und/oder zollamtliche Bestimmungen, internationale Abkommen (z. B. das GATT-Abkommen), Informationen über die zur Verfügung stehenden Transportmittel (z. B. Ladekapazität, Dimensionen des Laderaums etc.) und/oder Bestimmungen der Transporteure, welche mitunter einschränkend von den sonstigen Bestimmungen abweichen können, geeignet.
Um nur für den Transportprozess relevante Daten zu erfassen, erfolgt vorzugsweise in Abhängigkeit der über den Zentralrechner zur Verfügung gestellten Angaben eine rechnergesteuerte Auswahl der zu erfassenden Daten.
Somit können die Daten, die für einen Transportprozess vom lokalen Rechner „erfragt" werden, von Fall zu Fall je nach Art des Transportguts oder der Länder, in denen der Empfänger oder der Versender ansässig sind, variieren.
Durch den Angabenabgleich bei der Datenerfassung erfolgt vorteilhafterweise eine Überprüfung der eingegebenen Daten hinsichtlich ihrer Plausibilität. Werden falsche Daten bei der Erfassung in den lokalen Rechner eingegeben, wird der
Teilnehmer, der die Daten eingibt, solange aufgefordert, die Fehler zu korrigieren, bis eine fehlerfreie Dateneingabe erfolgt ist. Erst nach Beseitigung aller Fehler gelten die Daten als erfolgreich erfasst und werden dem Zentralrechner übermittelt.
Um eine Dateneingabe und Datendarstellung in verschiedenen Sprachen zu ermöglichen, ist das Verfahren vorzugsweise so ausgestaltet, dass auf jedem lokalen Rechner eine Sprache aus einer Gruppe von mehreren Sprachen ausgewählt werden kann, in der die Dateneingabe und Datendarstellung erfolgt. Die Datenübermittlung selbst wird sprachunabhängig durch Referenzcodes ausgeführt. Somit kann beispielsweise der Versender transportprozessrelevante Daten auf Deutsch in seinen lokalen Rechner eingeben, diese werden dann sprachunabhängig codiert erst an den Zentralrechner und von dort unter anderem an den Empfänger übertragen, welcher die Daten auf seinem lokalen Rechner beispielsweise auf Französisch dargestellt bekommt.
Alternativ ist es auch möglich, dass das Verfahren mit nur einer möglichen Sprache durchgeführt wird.
In einer bevorzugten Ausgestaltung der Erfindung ist es vorgesehen, dass jeder Teilnehmer in den ihm zugeordneten lokalen Rechner zusätzlich auch solche Daten erfassen kann, für die es keinen offiziellen Standard gibt (hierzu zählen beispielsweise Daten aus den Datenmengen der Adressdaten oder Artikelbezeichnungen) und die insofern anfangs auch nicht im zentralen Rechner hinterlegt sind und daher nicht vom zentralen Rechner in Form von Angaben zur Verfügung gestellt werden können. Das heißt, in dieser bevorzugten Ausgestaltung der Erfindung kann jeder Teilnehmer aus seiner Sicht für den Transportprozess relevante Daten dem Kommunikationssystem, innerhalb dessen das erfindungsgemäße Verfahren durchgeführt wird, hinzufügen und somit die Datenbank(en), in der die seitens des Zentralrechners zur Verfügung gestellten Angaben hinterlegt sind, erweitern. Damit wird es nach erstmaliger Eingabe der Daten, für die es keinen offiziellen Standard gibt, möglich, dass der Zentralrechner diese Daten als Angaben zur Verfügung stellt, so dass alle anderen Teilnehmer hiervon profitieren können. Die Datenbank(en) werden also mittels der Benutzerintelligenz aufgewertet.
Eine Kommunikationsanordnung zur Durchführung eines erfindungsgemäßen Verfahrens weist mehrere lokale Rechner und mindestens einen Zentralrechner auf. Jedem Teilnehmer des Transportprozesses ist dabei ein lokaler Rechner zugeordnet, wobei die lokalen Rechner und der Zentralrechner so in einem datenübermittelnden Netzwerk angeordnet sind, dass zwischen den lokalen Rechnern und dem Zentralrechner Daten übermittelt werden können.
Als datenübermittelndes Netzwerk kommt dabei vorzugsweise das Internet zur Anwendung. Aber auch andere Netzwerke wie beispielsweise das SITA-System eignen sich zur Datenübermittlung.
Die lokalen Rechner sind in einer bevorzugten Ausgestaltung der Erfindung als lokale Server ausgelegt und weisen nur einen beschränkten Funktionsumfang auf. Das heißt, sie können nur zur Durchführung eines erfindungsgemäßen Verfahrens notwendige Anwendungen ausführen. Dadurch werden unter anderem Kapazitäten geschont und Fehler, die durch die parallele Ausführung verschiedener Anwendungen infolge von Inkompatibilitäten auftreten können, vermieden.
Für eine Anbindung der Teilnehmer an die lokalen Server werden letztere bevorzugt in ein bestehendes Serversystem eingebunden oder direkt mit einem gewöhnlichen Personalcomputer verbunden, der als Client fungiert. Der Client dient dann als Schnittstelle zwischen dem lokalen Server und dem Teilnehmer. Sofern beispielsweise aus datenschutzrechtlichen Gründen eine physikalische Trennung von datenspeichernden Zentralrechnern erwünscht ist, wird die Kommunikationsanordnung bevorzugt so ausgestaltet, dass sich die Anzahl der Zentralrechner an der Anzahl der Transporteure, die in die Kommunikationsanordnung eingebunden sind, bemisst. Somit kann für jeden Transporteur ein eigener Zentralrechner bereitgestellt werden. Die jeweiligen Datenbanken, auf die die einzelnen Zentralrechner in einem solchen Fall zugreifen, werden untereinander synchronisiert, um für alle Zentralrechner eine gleiche Grunddatenbasis bereitzustellen.
Weitere Vorteile und Einzelheiten der Erfindung sollen anhand nachstehender Figuren erläutert werden. Es zeigen:
Fig. 1 eine schematische Darstellung eines ersten im Stand der Technik bekannten Kommunikationssystems zwischen den Teilnehmern eines
Transportprozesses;
Fig. 2 eine schematische Darstellung eines zweiten im Stand der Technik bekannten Kommunikationssystems zwischen den Teilnehmern eines Transportprozesses, wobei das Kommunikationssystem einen Integrator aufweist;
Fig. 3 eine schematische Darstellung eines dritten im Stand der Technik bekannten Kommunikationssystems zwischen den Teilnehmern eines Transportprozesses;
Fig. 4 eine schematische Darstellung eines Kommunikationssystems gemäß der vorliegenden Erfindung; und
Fig. 5 eine schematische Darstellung einer erfindungsgemäßen Kommunikationsanordnung. Die Figur 1 stellt als Stand der Technik ein schematisches Modell bekannter Kommunikationsabläufe im Luftfrachtbereich und in anderen Transportbranchen zur Übertragung von Daten dar. Zur Vereinfachung sind nur die wichtigsten Beteiligten an einer Logistikkette bzw. Teilnehmer eines Transportprozesses dargestellt.
Manuelle Kommunikationsschritte (m) sind mittels durchgezogener Linien dargestellt. Als „manuell" sollen dabei solche Kommunikationsschritte beschrieben werden, die nicht automatisiert zwischen den Teilnehmern an dem Transportprozess ablaufen, sondern jeweils eine Interaktion des Teilnehmers erfordern, der die Daten empfängt, um die übertragenen Daten in ein (zentrales) Datenaustauschsystem einzuspeisen. Dabei ist es unerheblich, ob zu diesem Kommunikationszweck Computer oder andere Kommunikationsgeräte, wie beispielsweise Telefone oder Faxgeräte, verwendet werden. Beispiele für solche manuellen Kommunikationsschritte sind Telefonanrufe, Faxübertragungen oder der Versand bzw. Empfang von E-Mails.
Online-Kommunikationsschritte (o) werden durch gestrichelte Linien repräsentiert. Als „online" sollen solche Kommunikationsschritte verstanden werden, die automatisiert zwischen den Teilnehmern an dem Transportprozess ablaufen, also keine Interaktion des datenempfangenden Teilnehmers erfordern, um die übertragenen Daten in ein (zentrales) Datenaustauschsystem einzuspeisen. Hierbei erfolgen die Kommunikation und die damit verbundene Datenübertragung vorzugsweise direkt mithilfe von Computern.
Kommunikationsschritte, die alternativ manuell oder online (m/o) erfolgen können, sind durch gepunktete Linien dargestellt. Die Pfeilspitze zeigen in allen Kommunikationsschritten die Richtung der Kommunikation an. Pfeilspitzen an beiden Enden von Verbindungslinien zeigen, dass die entsprechende Kommunikation bidirektional erfolgt.
Ein Transportprozess nach dem in der Figur 1 dargestellten bekannten Kommunikationsablauf erfolgt gemäß den nachfolgenden Schritten, die anhand eines Beispiels dargelegt werden sollen. Dabei wird unterstellt, dass die größte Strecke des Transportwegs von einem Flugzeug bewältigt wird, eine zu transportierende Sendung also als Luftfrachtgut befördert wird. Alternativ könnte auch jedes andersartige Transportmittel (beispielsweise Eisenbahn oder Schiff) zum Einsatz kommen; die grundsätzlichen Transportabläufe ähneln sich.
Als erster Schritt in einem Transportprozess erteilt ein Versender 10 einem Exportspediteur 11 beispielsweise telefonisch einen Auftrag, eine Sendung vom Firmensitz in A abzuholen und einen Transport der Sendung zu einem Empfänger 20 in B zu organisieren.
Der Exportspediteur 11 ermittelt nun den von A nächstgelegenen bzw. am günstigsten zu erreichenden Startflughafen 12 und den von B nächstgelegenen bzw. am günstigsten zu erreichenden Zielflughafen 22. Anschließend ermittelt er eine Fluggesellschaft 30, die die gewünschte Transportleistung erbringen kann und bucht beispielsweise telefonisch oder per Fax einen entsprechenden Transport für die Sendung. Dabei ist es häufig der Fall, dass der Exportspediteur 11 nicht direkt mit der Fluggesellschaft 30, sondern mit einem Vertreter bzw. einem General Sales Agent (GSA) vor Ort kommuniziert (in Fig. 1 nicht dargestellt). Alternativ könnte der Exportspediteur 11 einen Transport für die Sendung auch über ein Internetportal der Fluggesellschaft 30 online buchen.
Nach erfolgreicher Buchung bei der Fluggesellschaft 30 übermittelt der Exportspediteur 11 dem Versender 10 per Fax, Telefon oder E-Mail eine Buchungsbestätigung.
Der Exportspediteur 11 füllt in der Regel einen Frachtbrief (air waybill, AWB) mit allen ihm zur Verfügung stehenden Daten über die zu transportierende Sendung aus, wobei er dazu meist einen Computer verwendet. Da nur sehr wenige Spediteure an das Telextransmission-System SITA (Societe Internationale de Telecommunications Aeronautiques) angeschlossen sind, mittels dessen die Daten des Frachtbriefes direkt an alle beteiligten Fluggesellschaften übertragen werden können, händigt der Exportspediteur 11 einen Ausdruck des Frachtbriefs einem Vertreter der Fluggesellschaft 30 auf dem Startflughafen 12 aus. Ein solcher Vertreter ist zumeist ein sog. Handlingsagent 13.
Eine Exportabfertigung des Frachtbriefes und der Sendung durch den Zoll 14 erfolgt in beinahe allen Ländern nach wie vor formulargestützt und nicht elektronisch, während eine Ausfuhrbestätigung oft bereits über computergestützte Systeme erfolgt. Hierbei kann der Handlingsagent 13 (eventuell auch der Exportspediteur) oder der Zoll 14 selbst die benötigten Daten über die Sendung erfassen.
Sind sowohl der Luftfrachtbrief als auch die eigentliche Sendung bei dem Handlingsagenten 13 eingetroffen, so ist es dessen Aufgabe, die Daten des Luftfrachtbriefes mittels eines Computersystems zu erfassen. Hierzu wurde in der Vergangenheit oft auf das Computersystem der Fluggesellschaften zurückgegriffen - vorausgesetzt die Fluggesellschaft 30 war im Besitz eines solchen Systems. Aus Gründen der Kostenreduzierung erwarten die Fluggesellschaften heutzutage allerdings, dass die Handlingsagenten 13, 23 eigene Systeme für die Datenerfassung bereithalten. Diese Computersysteme kommunizieren meist über SITA/EDI (Electronic Data Interchange) mit einem Rechner der beteiligten Fluggesellschaften 30, unabhängig davon, ob es sich um Systeme, die von einer Fluggesellschaft bereitgestellt werden, oder um eigene Systeme der Handlingsagenten 13, 23 handelt.
Aufgrund der zahlreichen unterschiedlichen derzeit eingesetzten Computersysteme muss ein Handlingsagent 13, 23 heutzutage eine Vielzahl von Computersystemen parallel betreiben, um mit möglichsten vielen Fluggesellschaften 30 zusammen arbeiten zu können.
Die Daten der Buchung und des Luftfrachtbriefes sind in dem Computersystem der Fluggesellschaft 30 intern weltweit abrufbereit und bearbeitbar. So können Handlingsagenten 33; 23 an einer Transitstation 32 und/oder am Zielflughafen 22 bereits bei der Buchung informiert werden, dass die entsprechende Sendung zu erwarten ist. Die in der Grafik dargestellte Transitstation 32 ist keine zwingend benötigte Station des erläuterten Transportprozesses. Sofern ein direkter Transport vom Start- 12 zum Zielflughafen 22 möglich ist, wird dieser in der Regel bevorzugt. Umgekehrt ist es auch denkbar, dass die Sendung über mehr als eine Transitstation 32 befördert wird; dies hängt von den jeweiligen Flugplänen der Fluggesellschaften 30 ab.
Eine Sendung, die auf einer Transitstation 32 ankommt, wird überprüft und ihre Ankunft im System bestätigt. Gleichzeitig oder anschließend wird die Sendung zum weiteren Transport freigegeben. Gegebenfalls wird die Sendung einem amtlichen Vorgang durch den Zoll 34 unterzogen. Alle Aktionen, die der Handlingsagent 33 an der Transitstation 32 ausführt, können von der Fluggesellschaft 30 über ihr Telexsystem SITA verfolgt werden, wenn der Handlingsagent 33 diese Aktionen über das SITA-System mitteilt.
Gelangt eine Sendung schließlich an ihren bestimmungsgemäßen Zielflughafen 22, bestätigt der Handlingagent 23 am Zielflughafen 22 der Fluggesellschaft 30 gegenüber elektronisch die ordnungsgemäße Ankunft der Sendung. Daraufhin informiert die Fluggesellschaft 30 einen Importspediteur 21 in der Regel manuell über die Ankunft der Sendung.
Eine Abfertigung durch den Zoll 24 und eine Kommunikation mit dem Empfänger 20 laufen nun äquivalent zu den eingangs beschriebenen Vorgängen beim Versender 10 ab, wobei die Reihenfolge genau umgekehrt ist. Die Sendung wird schließlich vom Importspediteur 21 an den Empfänger 20 ausgeliefert, der in der Regel zuvor nicht über die zu erwartende Sendung informiert wurde.
Bei einem derartigen Transport besteht auch die Möglichkeit eines Transfers der Sendung von einer Fluggesellschaft 30 zu einer anderen. Ein solcher Transfer kann aber nur dann elektronisch gestützt erfolgen, wenn beide Fluggesellschaften ein SITA/EDI-gestütztes Computersystem verwenden, welches in der Lage ist, „cargoIMP Messages" (ein in der Luftfahrt übliches Protokoll) zu verarbeiten. Die mögliche weitere Kommunikation zwischen den genannten Teilnehmern an dem Transportprozess und weiteren denkbaren Beteiligten an diesem Prozess, wie etwa einem Fuhrunternehmen des Vorlaufes, einem General Sales Agent oder Vertretern anderer Transportmittel (LKW, Bahn usw.) ist in der Fig. 1 nicht durch entsprechende Linien dargestellt, da diese Kommunikation bei den bekannten Systemen in der Regel nur auf nicht elektronischem Wege stattfindet.
In der Figur 2 sind die ebenfalls dem Stand der Technik zugehörenden Kommunikationsabläufe eines Transportprozesses unter Einbeziehung eines sog. Integrators schematisch dargestellt. Die Kommunikationsschritte können auf die in der Beschreibung zur Figur 1 dargelegten Arten erfolgen; die Darstellung der verschiedenen Arten erfolgt analog zur Figur 1. Teilnehmer des Transportprozesses, die bereits in der Figur 1 aufgetreten sind, sind mit den gleichen Bezugszeichen versehen.
Als Integrator 40 werden Transportfirmen bezeichnet, die einen Transportauftrag integriert, das heißt ohne die notwendige Beteiligung weiterer Firmen durchführen.
Unter Bezugnahme auf die Figur 1 und deren Beschreibung integriert ein Integrator 40 also den Export- und Importspediteur 11 ; 21 , die Handlingsagenten 13; 23; 33 am Start- 12 und Zielflughafen 22 sowie an einer optionalen Transitstation 32, den Fuhrunternehmer des Vor- und Nachlaufes sowie zumeist auch die Fluggesellschaft 30 für den Luftfrachttransport selbst. Solche Integratoren sind beispielsweise die Firmen DHL, UPS und Fedex. Konzeptionell liegt das Integratorsystem zwischen dem System der Post und dem der Luftfracht. In der Figur 2 sind all diejenigen Aufgaben, die der Integrator 40 übernimmt, bzw. die Funktionseinheiten, die der Integrator 40 integriert, innerhalb der mittig platzierten großen Ellipse angeordnet.
Zusätzlich zu den in der Figur 1 als Export- und Importspediteur 11 ; 21 bezeichneten Teilnehmer des Transportprozesses können auch noch Transporteuren des Vor- und Nachlaufs an gleicher Stelle im Kommunikationsschema angeordnet sein. In diesem Fall würde man zusammenfassend von „Service" sprechen. Der Versender 10 und der Empfänger 20 kommen in einem Integrator-basierten Transportprozess nur mit diesem Service 11 ; 21 des Integrators 40 in Kontakt.
Die jeweilige Kommunikation zwischen den einzelnen Funktionseinheiten des Integrators 40 erfolgt online über eine Luftfrachttransport-Koordination 41. Dazu verwenden die Integratoren 40 Computersysteme, welche alle internen Bereiche des Frachttransportes begleitend abbildet. Demgegenüber läuft die Kommunikation zwischen dem Integrator 40 und dem Versender 10 bzw. dem Empfänger 20 sowie zwischen dem Integrator 40 und dem Zoll 14; 24; 34 manuell oder online ab. Ein direkter Zugriff des Versenders 10, des Empfängers 20 oder des Zolls 14; 24; 34 auf die transportprozessrelevanten Daten des Integrators 40 ist bei diesem System nicht möglich.
In der Figur 3 ist als weiterer Stand der Technik ein Kommunikationsmodell der so genannten E-Logistik schematisch dargestellt. Die Kommunikationsschritte können auf die in der Beschreibung zur Figur 1 dargelegten Arten erfolgen; die Darstellung der verschiedenen Arten erfolgt analog zur Figur 1. Teilnehmer des Transportprozesses, die bereits in der Figur 1 aufgetreten sind, sind mit den gleichen Bezugszeichen versehen.
Unter E-Logistik versteht man im Allgemeinen den Versuch - parallel zum so genannten E-Business - einen Logistikprozess über das Internet abzubilden. Ein solcher Logistikprozess kann, wie in der Figur 3 gezeigt, der Transport einer Sendung von einem Startflughafen 12 zu einem Zielflughafen 22 sein.
In der Praxis bedeutet dies, dass es Internetplattformen gibt, über die man Daten austauschen und bearbeiten kann.
Da es jedoch bei den E-Logistik-Lösungen keinen direkten Zugriff auf angebundene Server der Fluggesellschaften gibt, beschränken sich die Dienstleistungen der E-Logistik zurzeit im Wesentlichen auf Online-Buchungen und so genanntes tracking & tracing. Unter diesem Begriff versteht man die Abfrage des Status einer Sendung, also beispielsweise, an welchem Ort der Logistikkette sich eine Sendung gerade befindet. Dabei wird immer der letzte Ort, an der die Sendung erfasst wurde, angegeben.
Wie die Figur 3 zeigt, können sowohl der Versender 10 und/oder der Empfänger 20 als auch der Export- und/oder der Importspediteur 11 ; 21 eine Statusabfrage zum Zwecke des tracking & tracing oder eine Buchungsanfrage an einen Web- Server 35 senden, der diese Anfrage dann weiter an die Fluggesellschaft 30 leitet. In seltenen Fällen können die zuvor genannten Teilnehmer des Transportprozesses weiterführende Arbeiten wie etwa das Ausfüllen eines Frachtbriefes vornehmen. Die Kommunikation geht nur in eine Richtung: Vom jeweiligen Teilnehmer 10; 11 ; 20; 21 zum Web-Server 35. Die Teilnehmer 10; 11 ; 20; 21 sind nicht aktiv in ein Netzwerk mit eingebunden, sondern können nur auf dem Web-Server 35 hinterlegte Daten einsehen.
In der Figur 4 ist ein Kommunikationssystem gemäß der vorliegenden Erfindung schematisch dargestellt. Die Kommunikationsschritte können auf die in der Beschreibung zur Figur 1 dargelegten Arten erfolgen; die Darstellung der verschiedenen Arten erfolgt analog zur Figur 1. Teilnehmer des Transportprozesses, die bereits in der Figur 1 aufgetreten sind, sind mit den gleichen Bezugszeichen versehen.
Kernstück dieses Systems ist ein so genanntes BATCH-System, das aus einem zentralen Rechner 50 und mehreren lokalen Rechnern besteht, wobei jeder Teilnehmer des Transportprozesses mindestens einen lokalen Rechner besitzt. Das System ist für alle Teilnehmer eines Luftfrachtmarktes bestimmt. Die Konzeption basiert auf einer Komplettlösung in Bezug auf die informationstechnische Bearbeitung der Sendungen für die Versender 10, Empfänger 20, Export- und Importspediteure 11 ; 21 , Handlingsagenten 13; 23, Fluggesellschaften 30 und alle weiteren damit zusammenhängenden Transportträger wie Frachtführer des Vor- und Nachlaufs etc. Darüber hinaus ist die Übertragung von Informationen an die relevanten Behörden - wie etwa den Zoll 14; 24; 34 - ein wichtiges Element der Funktionalität. Im Unterschied zu den zuvor in den Figuren 1 bis 3 aufgezeigten Lösungen, welche heutzutage im Einsatz sind, ermöglicht das BATCH-System es, alle relevanten Teilnehmer 10; 11 ; 13; 14; 20; 21 ; 23; 24; 30; 33; 34 eines Transportprozesses in einem Netzwerk zu vereinen, wobei eine aktive Kommunikation zwischen den einzelnen Teilnehmern 10; 11 ; 13; 14; 20; 21 ; 23; 24; 30; 33; 34 über einen zentralen Server 50 abläuft. Somit bietet das BATCH- System den Fluggesellschaften die Möglichkeit, eine Antwort auf das in der Figur 2 dargestellte Logistikkonzept der Integratoren zu geben, indem alle Arbeitsprozesse über das BATCH-System vollständig integriert werden können. Darüber hinaus schließt das BATCH-System auch den Versender 10 und den Empfänger 20 mit in das Netzwerk ein.
In der Figur 4 sind wiederum nur die relevanten Teilnehmer 10; 11 ; 13; 14; 20; 21 ; 23; 24; 30; 33; 34 an dem Transportprozesses wiedergegeben. Weitere denkbare Teilnehmer, wie etwa Fuhrunternehmen oder General Sales Agents wurden der Übersichtlichkeit halber ebenso wenig dargestellt wie der Einsatz anderer Transportmittel (Bahn, Schiff etc.), obwohl ihre Teilnahme an dem Prozess bzw. ihr Einsatz grundsätzlich möglich ist.
Hat ein Versender 10 einen Transportauftrag zu vergeben, dann übermittelt er diesen mit allen relevanten Daten zu der zu transportierenden Sendung elektronisch an den zentralen Rechner 50 des BATCH-Systems. Von dort aus wird er an den zuständigen Exportspediteur 11 weitergeleitet. Der Empfänger 20 kann bereits bei der Buchungsanfrage mit in den neuen Transportprozess einbezogen werden.
Mit dem Transportauftrag wird eine Buchungsanfrage an eine geeignete Fluggesellschaft 30 übermittelt. Nachdem die Buchung erfolgreich abgeschlossen wurde, werden alle Teilnehmer des Transportprozesses, also jeder Teilnehmer, der mit der physischen Sendung zu tun haben wird - wie beispielsweise die Handlingsagenten 13; 33; 23 des Startflughafens 12, der optionalen Transitstation 32 und des Zielflughafens 22, die Fluggesellschaften 30 im Transfer und der Importspediteur 21 - vorab über die zu transportierende Sendung informiert so genanntes „preadvise".
Der Exportspediteur 11 ergänzt den Luftfrachtbrief zu dessen Vervollständigung um seine Daten zu der zu transportierenden Sendung. Die so geänderten Daten werden über den Server 50 des BATCH-Systems allen Beteiligten mitgeteilt. Der Handlingsagent 11 des Startflughafens 12 erwartet nun die physische Sendung. Erhält er diese, wird er in seinem Warehouse System einen Check-In der Sendung durchführen, woraufhin das BATCH-System die Daten der Buchung mit denen des Frachtbriefes und dem Lagerbestand vergleicht. Bei eindeutiger Datenlage gibt das BATCH-System die Fracht zum Transport frei. Durch die somit jederzeit intern bekannte Datenlage kann auf den optionalen Transitstationen 32 und auf dem Zielflughafen 22 die Sendung unmittelbar nach der physischen Ankunft zur Auslieferung freigegeben („released") werden.
In Ländern, in denen der Zoll 14; 24; 34 eine Vorverzollung aufgrund der Datenlage zulässt, kann das BATCH-System auch diesen Service ermöglichen. „BATCH" im Sinne des Wortes bedeutet eine elektronische Umsetzung einer Stapelverarbeitung. Das heißt, dass alle Dokumente eines Transportauftrages elektronisch im BATCH-System abgebildet werden. So sind auch Lieferscheine und Rechnungen des Versenders 10 sowie Dokumente zur Zollabfertigung Teil dieser Stapelverarbeitung und des BATCH-Systems.
Dokumente, die für einen speziellen Transportprozess benötigt werden, wie etwa für den Transport von Gefahrengut oder von lebendigen Tieren, werden im BATCH-System über einzelne Module bereitgestellt und elektronisch dem entsprechenden Transportprozess zugewiesen.
Wie aus Figur 4 zu sehen ist, findet die Kommunikation zwischen allen Teilnehmern 10; 11 ; 13; 14; 20; 21 ; 23; 24; 30; 33; 34 und dem zentralen Server 50 bidirektional statt. Anders als bei der E-Logistik-Lösung, die in Figur 3 dargestellt wurde, wird beim BATCH-System dem Benutzer aktiv der Status einer bestimmten - ihn betreffenden - Sendung mitgeteilt. Der Benutzer muss somit nicht selbst tätig werden, um beispielsweise ein tracking & tracing auszuführen. Er ist vielmehr während der Dauer eines Transportprozesses Teil des Netzwerkes.
Die Figur 5 zeigt eine schematische Darstellung einer erfindungsgemäßen Kommunikationsanordnung. Eine Übermittlung von Daten bzw. Angaben ALI, welche in einer Datenbank gespeichert sind und von dort abgerufen werden können, ist durch durchgezogene Linien gekennzeichnet. Eine Übermittlung von Daten bzw. Informationen IU1 welche einen Transport einer Sendung betreffen, ist durch gestrichelte Linien gekennzeichnet.
Grundsätzlich weist eine solche Kommunikationsanordnung mindestens eine anwenderseitige oder lokale Substruktur L, die die Funktion eines lokalen Rechners hat, und mindestens eine serverseitige oder zentrale Substruktur Z, die die Funktion eines Zentralrechners hat, auf. Der lokalen Substruktur L sind ein oder mehrere lokale Clients 60 zugeordnet.
Ausgehend von den lokalen Clients 60, auf denen lokale Applikationen ausgeführt werden, findet eine Angabenübermittlung AÜ bei einer solchen Kommunikationsanordnung von und zu einer lokalen Datenbank 62 und einer Konfigurationsdatenbank 63 über einen Applikationsserver 61 statt. Auf die lokale Datenbank 62 und die Konfigurationsdatenbank 63 hat darüber hinaus ein lokales Kommunikationsmanagement 64 direkten Zugriff, das eine Angaben- und Informationsübermittlung AÜ; IU von und zu einem datenübermittelnden Netzwerk 65 handhabt. Ein solches Netzwerk kann beispielsweise das Internet oder ein aus Telekommunikationsverbindungen im Rahmen des SITA-Systems oder des PSTN (Public Switched Telephony Network) aufgebautes Netzwerk sein.
Für eine direkte Informationsübermittlung IU zwischen dem Applikationsserver 61 und dem lokalen Kommunikationsmanagement 64 sorgen Kommunikations- Schnittstellen 66a, 66b, die dem Applikationsserver 61 bzw. dem lokalen Kommunikationsmanagement 64 zugeordnet sind. Daten bzw. Informationen oder Angaben, die nicht direkt vom lokalen Kommunikationsmanagement an das datenübermittelnde Netzwerk 65 bzw. die lokalen Clients 60, die lokale Datenbank 62 oder die Konfigurationsdatenbank 63 übermittelt werden können, werden in einer dem lokalen Kommunikations- management 64 zugeordneten Warteschlange 641 zwischengespeichert.
In der zentralen Substruktur regelt ein dem lokalen Kommunikationsmanagement 64 äquivalentes zentrales Kommunikationsmanagement 67 den Datenfluss von und zum datenübermittelnden Netzwerk 65. Daten, die vom zentralen Kommunikationsmanagement 67 nicht direkt weitergeleitet werden können, werden in einer Warteschleife 671 des zentralen Kommunikationsmanagements 67 zwischengespeichert. Vom zentralen Kommunikationsmanagement 67 können Angaben direkt an eine Authentifizierungsdatenbank 68 übermittelt werden. In dieser Authentifizierungsdatenbank 68 sind unter anderem Daten hinterlegt, die es ermöglichen, vom datenübermittelnden Netzwerk 65 eintreffende Angaben oder Informationen dahingehend zu überprüfen, ob sie von einem berechtigten Anwender stammen und ob somit eine Weiterleitung solcher Angaben oder Informationen vom zentralen Kommunikationsmanagement 67 an eine Server- Applikation 69 erfolgen soll.
Wie in der lokalen Substruktur L findet eine Kommunikation zwischen dem zentralen Kommunikationsmanagement 67 und der Server-Applikation 69 über Kommunikationsschnittstellen 66c, 66d statt, die dem zentralen Kommunikationsmanagement 67 bzw. der Server-Applikation 69 zugeordnet sind.
Von der Server-Applikation 69 können Angaben von und zu einer zentralen Datenbankschnittstelle 70 übermittelt werden. Diese Datenbankschnittstelle 70 sorgt für Ansteuerung mindestens einer zentralen Datenbank 71 , auf der transportprozessrelevante Daten wie beispielsweise Flugpläne oder Informationen über internationale Vorschriften hinterlegt sind.
Mittels einer derart ausgestalteten Kommunikationsanordnung können also Daten von den lokalen Clients 60 an die zentrale Server-Applikation 69 gesandt, über die zentralen Datenbanken 71 abgeglichen und ergänzt um weitere Daten aus den zentralen Datenbanken 71 wieder zurück an die lokalen Rechner 60 übermittelt werden. Mithin erfolgt eine Datenübermittlung zwischen einem lokalen Rechner L und einem zentralen Rechner Z. Dabei ist es im Rahmen der vorliegenden Erfindung zweckmäßig, dass die Kommunikationsanordnung nicht nur eine, sondern mehrere lokale Substrukturen bzw. Rechner L aufweist, beispielsweise für jeden Teilnehmer des Transportprozesses eine. Auch können mehrere zentrale Substrukturen bzw. Zentralrechner Z - beispielsweise für jeden Transporteur eine - eingesetzt werden. Die Anzahl der lokalen Rechner L wird die Anzahl der zentralen Rechner Z in der Regel weit übertreffen.
Weitere vorteilhafte Ausgestaltungen des erfindungsgemäßen Verfahrens und der erfindungsgemäßen Kommunikationsanordnung sollen anhand von Anwendungsbeispielen des in der Figur 4 erläuterten BATCH-Systems dargestellt werden:
Beispiel 1
In diesem Beispiel soll die im Vergleich mit dem Stand der Technik effektivere und kostengünstige Konzeption des BATCH-Systems hinsichtlich einer vereinfachten Abbildung des Arbeitsablaufs beschrieben werden.
Das BATCH-System reduziert komplexe Prozesse an den jeweils möglichen Stellen auf wenige, dem Arbeitsablauf entsprechende Schlüsselformate. Zudem wird das BATCH-System in Modulen bereitgestellt, wobei jeder Anwender des BATCH-Systems nur diejenigen Programmteile erhält, die von ihm zu seinen Arbeitsablauf notwendig sind.
So wird im BATCH-System beispielsweise ein Luftfrachtbrief (AWB), der von der IATA (International Air Transport Association) und der ICAO (International Civil Aviation Authorities) hinsichtlich des Informationsgehalts bezüglich der Sendung an sich, ihres Transports und der Haftungsregulahen entwickelt worden ist, integriert und informationstechnisch dargestellt. Aber auch andere, in der Luftfrachtindustrie bereits verwendete und etablierte Formulare werden durch das BATCH-System elektronisch dargestellt sowie zur elektronischen Datenerfassung und papierlosen Bearbeitung bereitgestellt, so dass nennenswerte Einarbeitungszeiten für die Einführung des BATCH-Systems nicht erforderlich sind.
Ein Mitarbeiter eines Logistikunternehmens (Spedition, Handlingsgesellschaft, Exportabteilung eines Versenders) findet als Anwender des BATCH-Systems bei der ersten Benutzung des BATCH-Systems die gleichen Formulare vor, die er bislang manuell bearbeitet hat. So wird einem Versender beispielsweise ein so genannter Shippers Letter of Instruction (SLI)1 einem der Mitarbeiter einer Spedition beispielsweise der Luftfrachtbrief (AWB) und einem Mitarbeiter eines Luftfrachthandlingsunternehmen beispielsweise ein so genanntes Manifest durch das BATCH-System angezeigt. Das jeweilige Formular liegt nicht verschlüsselt vor, sondern kann unmittelbar in elektronischer Fassung ausgefüllt werden.
Der jeweilige Anwender sieht das entsprechende elektronische Formular in originalgetreuer Wiedergabe vor sich, so wie er das Papierformular von der manuellen Bearbeitung her kennt. In späteren Arbeitsstufen kann der Anwender in einer Vielzahl von Fällen das BATCH-System für sich arbeiten lassen und wird beim Ausfüllen der Formulare von einer oder von mehreren systeminternen Datenbank(en) unterstützt, wie im nächsten Beispiel dargelegt wird.
Beispiel 2
Ein Großteil der Daten, die für die Vervollständigung der Transportdokumente (beispielsweise des Luftfrachtbriefs) benötigt werden, ist im BATCH-System bereits integriert. Der Anwender kann diese Daten dann ausschließlich von der oder den BATCH-intemen Datenbank(en) abfragen, aber nicht beliebig ergänzen. Dadurch wird eine sehr hohe Reproduzierbarkeit hinsichtlich der Daten, die in die entsprechenden Formulare eingetragen werden, erreicht. Möchte beispielsweise ein Berliner Versender eine Sendung mit einem Gewicht von 1000 kg, wobei der Inhalt dieser Sendung Insekten sind, nach Mexiko verschicken, so öffnet er auf seinem Modul des BATCH-Systems einen SLI (Shippers Letter of Instruction). Das Feld „Versender" ist bereits mit seinen Daten ausgefüllt, da das BATCH-System ihn als Benutzer erkennt.
Das Feld „Empfänger" kann er nun von Hand oder unter Zugriff auf die entsprechenden Empfängerdaten aus der Datenbank ausfüllen. In der Datenbank sind dabei all diejenigen Empfänger, welche mit dem jeweiligen Versender zusammenarbeiten, hinterlegt.
Der Versuch, die Sendung vom Empfänger bezahlen zu lassen, scheitert, da in der Datenbank Informationen hinterlegt sind, dass lebendige Tiere ebenso wenig wie Waren allgemein nach Mexiko auf der Basis „Charges Collect" (Empfänger bezahlt) versendet werden dürfen. Somit zwingt das BATCH-System den Versender, diesen Fehler zu korrigieren. Bevor der Fehler nicht korrigiert wurde, kann der SLI nicht vollständig ausgefüllt werden, so dass ein entsprechender Transportauftrag nicht vom BATCH-System angenommen wird.
Weiterhin werden vom BATCH-System nur Buchungsanfragen zu solchen Flügen akzeptiert, bei denen Flugzeuge zum Einsatz kommen, welche in der Lage sind, lebende Tiere zu transportieren und dabei einer Belastung des Bodens mit Gewichten von mindestens 1000 kg standhalten.
Das BATCH-System wird nun dem Anwender Informationen bereitstellen, die er dokumentarisch berücksichtigen muss, etwa Quarantänevorschriften in einem etwaigen Transitland oder in Mexiko selbst. Ferner erhält der Anwender Informationen darüber, ob die beteiligten Handlingsagenten spezielle Räumlichkeiten und Lagermöglichkeiten für Tiere besitzen. Zudem wird eine Vorabmitteilung („preadvise") über den durchzuführenden Transport automatisch an die gewünschte Fluggesellschaft gesandt. Das BATCH-System prüft auch noch zahlreiche weitere Daten, so dass der eigentliche Transportvorgang schließlich schnell und ohne vermeidbare Komplikationen abgewickelt werden kann.
Die gute Datenlage hilft zudem, aus der Datenbank des BATCH-Systems den optimalen Tarif für die Sendung herauszusuchen. Darüber hinaus werden die für den Transport lebendiger Tiere (AVI) notwendigen und die den Bestimmungen des Allgemeinen Zoll- und Handelsabkommens (GATT) entsprechenden Formulare sowie die für den Export und Import benötigten Zolldokumente bereitgestellt und vorgefertigt, so dass diese später nur noch mit wenigen Handgriffen ergänzt werden müssen.
Beispiel 3
Neben der zuvor dargestellten Minimierung der Eingabefehler bei Verwendung des BATCH-Systems soll im Folgenden die Sprachunabhängigkeit an einem Beispiel erläutert werden.
Die Verkehrssprache der Luftfracht ist Englisch. Allerdings ist bereits jetzt der Trend zu beobachten, dass viele Mitarbeiter im Handling nicht ausreichend gut Englisch sprechen, um beispielsweise Manuals lesen zu können. Die Manuals sind jedoch Teil des Datenbankbestandes des BATCH-Systems. Um Sprachbarheren abzubauen, erlaubt das BATCH-System daher die Dateneingabe in verschiedenen Sprachen. Gibt ein Anwender als Inhalt seiner Sendung beispielsweise „Benzin" an, gleicht das BATCH-System dieses Wort mit den in der Datenbank hinterlegten Angaben ab, wobei die Datenbanken über einen Schlüssel referenziert werden (übliches Vorgehen für Datenbanken). Der Schlüssel kann mit Begriffen in jeder beliebigen Sprache verbunden sein.
Der Schlüssel 12 00 0036 ist beispielsweise im Englischen mit dem Begriff „gas" referenziert (verknüpft), im Deutschen hingegen mit „Benzin" und im Chinesischen mit „shen Nu". Bei der Datenübertragung selbst ist dabei nur der Schlüssel relevant. Die Angabe des Sendungsinhalts „Benzin" im Deutschen, den der Anwender in ein Formular des BATCH-Systems eingegeben hat, erscheint bei einem Empfänger in Mexiko mit der sprachlich gewünschten (spanischen) Wortwahl im gleichen Formular auf dessen lokalem Rechner. Somit kann jeder Anwender des BATCH-Systems die ihm vertraute Sprache benutzen. Dies vermindert den Lernaufwand für den einzelnen Anwender erheblich und hilft, Fehler beim Ausfüllen der benötigten Formulare zu vermeiden.
Gibt der Anwender den Sendungsinhalt mit „Benzin" an, erkennt das BATCH- System darüber hinaus, dass es sich bei der zu transportierenden Sendung um ein Gefahrgut handelt. Der Benutzer kann die Sendung nur dann abschicken, wenn er die notwendigen DGR-Formulare (Dangerous Goods - Gefahrgut) ausfüllt und dem Vorgang (elektronisch) anhängt. Hierbei unterstützt das BATCH-System den Anwender, da es die meisten Daten, die zum Ausfüllen des Formulars benötigt werden, aus der Datenbank heraussucht und bereits in die entsprechenden Formularfelder einträgt.
Beispiel 4
Das folgende Beispiel soll eine Optimierung des Personalbedarfs, die durch den Einsatz des BATCH-Systems erreicht werden kann, erläutern.
Bedingt durch die Tatsache, dass das BATCH-System in einem (globalen) Netzwerk angeordnet ist, welches alle Anwender informationstechnisch miteinander verbindet, steht die Gesamtdatenlage allen Beteiligten jederzeit zur Verfügung. Dabei gibt es lediglich individuell einstellbare Restriktionen bezügliche des erlaubten Datenzugriffs durch den jeweiligen Anwender seitens des BATCH- Systems, um persönliche oder firmeninterne Daten der jeweiligen Anwender zu schützen und einen unberechtigten Zugriff anderer Anwender auf diese Daten zu verhindern (vgl. Beispiel 9).
Das BATCH-System ermöglicht seinen Kunden, auf bereits in das globale Netzwerk eingegebene Daten wiederholt zuzugreifen. Während nach den Kommunikationssystemlösungen aus dem Stand der Technik Daten häufig mehrfach in lokale, voneinander isolierte Computersysteme eingegeben werden, kann beim BATCH-System die mehrfache Bearbeitung gleicher Daten ausgeschlossen werden. Gemäß dem Stand der Technik übermittelt ein Versender die für einen Luftfrachttransport notwendigen Daten beispielsweise per Fax zu seinem Spediteur, dieser übernimmt die Daten manuell in sein Speditionssystem, druckt den Luftfrachtbrief aus und übergibt diesen dem Handlingsagenten, welcher die Daten sodann erneut in sein internes Computersystem überträgt.
So hat ein Versender beispielsweise folgende Daten in den SLI (Shippers Letter of Instruction) eingetragen: einen Versender, einen Empfänger, einen Startflughafen, einen Zielflughafen, eventuelle Transitstationen, einen gewünschten Spediteur, eine gewünschte Fluggesellschaft, einen Abflugtag, einen Buchungsvorschlag, die Maße der Sendung, das Volumen der Sendung, das Gewicht der Sendung, den Inhalt der Sendung, Angaben über die Art der Zahlung, Angaben über den Wert der Sendung, Angaben über den Zollstatus, Angaben über die Notwendigkeiten des Handlings und des Accountings.
Das sind bereits mehr als 85 % der Angaben, die der beauftragte Spediteur in den Luftfrachtbrief übertragen muss. Da die Daten nun bereits im BATCH-System vorhanden sind, muss der Spediteur lediglich seine Angaben ergänzen und den Gesamtvorgang noch einmal überprüfen.
Der Spediteur versendet dann über das Netzwerk nur noch die geänderten Daten. Der Handlingsagent kann bei Verwendung des BATCH-Systems sogar - ohne die bei ihm eintreffenden Formulare zu öffnen oder zu bearbeiten - mit Drag & Drop arbeiten, solange die Daten des Transportprozesses in sich konsistent sind (das heißt, wenn die Angaben des eingegangenen Luftfrachtbriefs mit der gewünschten Buchung und seinem Lagerbestand übereinstimmen).
Gleiches gilt für die Teilnehmer des Transportprozesses, die an den Transitstationen und dem Zielflughafen arbeiten. Alle weiteren Formulare, die eventuell benötigt werden, können auf der Grundlage der vorhanden Daten stark vereinfacht und daher schnell und effizient ausgefüllt bzw. um die fehlenden Daten ergänzt werden.
Das BATCH-System garantiert somit eine Optimierung des Einsatzes der Mitarbeiter.
Beispiel 5
Das folgende Beispiel soll die automatische Fehlerprävention durch das BATCH- System näher beschreiben.
Das BATCH-System enthält Datenbanken mit fluggesellschaftspezifischen Informationen wie Flugplänen (schedules) und internen Regelungen (Embargos, Inkassoregelungen etc.), mittels derer ein Anwender des BATCH-Systems durch das System über die Anforderungen der jeweiligen Fluggesellschaft und auch über internationale Vorschriften informiert wird. Ferner erfolgt ein Abgleich der von dem Anwender in das System eingegeben Daten mit den hinterlegten Angaben bzw. eine Kontrolle auf der Grundlage dieser Angaben.
Auch können die eingegebenen Daten gegebenenfalls auf der Grundlage der hinterlegten Angaben korrigiert werden. Ferner ist eine gezielte Steuerung des Eingabeprozesses auf der Grundlage der hinterlegten Daten denkbar und dazu vorgesehen, tatsächlich alle für einen individuellen Transportprozess relevanten und benötigten Daten zu erfassen. Es ist dabei sehr wichtig, dass Fehler weitgehend ausgeschlossen werden, um die Effizienz der Bearbeitung zu steigern und auch Schäden - wie beispielsweise Zollschäden, Planungsfehler, Konventionalstrafen etc. - zu vermeiden.
Wenn eine Fluggesellschaft beispielsweise einen Flughafen außerplanmäßig nicht mehr anfliegt (zum Beispiel wegen der dort vorherrschenden politischen Lage), dann würde die Fluggesellschaft nach einem Kommunikationssystem des Stands der Technik alle Flughäfen weltweit über diese Flugplanänderung per Telex informieren. Nun ist es denkbar, dass ein Mitarbeiter an einem beliebigen Flughafen dieses Telex achtlos beiseite legte oder aufgrund von Sprachschwierigkeiten dessen Inhalt nicht vollständig korrekt erfasste. Dadurch würden weiterhin Sendungen, die den nun nicht mehr angeflogenen Flughafen als Zielflughafen haben, angenommen und zum Transithub (dem Hauptsitz der Fluggesellschaft) transportiert. Dort würde ein Lager schnell an seine Kapazitätsgrenzen stoßen, da die Sendungen nicht mehr weiter transportiert werden könnten.
Bei Verwendung des BATCH-Systems werden solche Probleme umgangen, da die systemeigenen Datenbanken stets zentral auf dem aktuellen Stand gehalten werden (vgl. Beispiel 8)
Beispiel 6
Das folgende Beispiel soll eine Optimierung des Arbeitsablaufes bei Verwendung des BATCH-Systems erläutern.
In den Datenbanken des BATCH-Systems sind vorzugsweise sämtliche relevanten Daten der Fluggesellschaften wie beispielsweise Buchungsinformationen, Kapazitätsmöglichkeiten der Flugzeuge und auch Planungsvorschläge zur bestgeeigneten Kapazitätsauslastung hinterlegt. Somit versetzt das BATCH-System den Anwender in die Lage, immer an der Grenze des Bestmöglichen zu arbeiten. Das Resultat dieser Optimierung ist eine bessere Ausnutzung der Kapazitäten (also beispielsweise der Kapazitäten des Frachtraumes eines Flugzeuges oder des Lagerraums an einer von mehreren möglichen Transitstationen) sowie eine schnellere Bearbeitung der Vorgänge (die Mitarbeiter müssen nicht mehr in Manuals nachlesen).
Das BATCH-System überprüft alle eingegeben Daten durch einen Abgleich mit den hinterlegten Angaben und nimmt notwendige Umrechnungen (etwa zwischen verschiedenen Währungen oder Maßeinheiten) sowie die Berechnung des Volumens einer Sendung auf der Grundlage der eingegeben Daten hinsichtlich der Maße der Sendung unmittelbar bei oder nach der Eingabe automatisch vor. Somit ist stets eine sichere Datenlage über die zu transportierenden Sendungen vorhanden. Damit ist das BATCH-System in der Lage, den jeweiligen beteiligte Fluggesellschaften eine optimierte Ausnutzung der Frachträume der Flugzeuge zu ermöglichen, wodurch die Fluggesellschaften den so genannten Loadfaktor optimieren können.
Das BATCH-System berücksichtigt auch die Maße der zu transportierenden Sendung bei der Auswahl der möglichen Flugverbindungen, um so zu gewährleisten, dass dem Anwender nur solche Flugzeuge für den Transport der Sendung angeboten werden, die eine den Maßen der Sendung entsprechend ausreichend große Tür bzw. Laderaumluke aufweisen, um die Sendung aufnehmen zu können.
Bei Kommunikationssystemen nach dem Stand der Technik sind die Angaben beispielsweise des Volumens einer Sendung oft abgeschätzt und werden in der Regel nicht mehr kontrolliert, so dass sich starke Abweichungen zwischen der Buchung und der tatsächlich zu befördernden Sendungen ergeben können.
Bedingt durch die Tatsache, dass über das Volumen auch abgerechnet wird, kann einer Fluggesellschaft über einen großen Zeitraum (beispielsweise ein Jahr) ein erheblicher Verlust durch die Angabe zu geringer Volumina der zu transportierenden Sendungen entstehen. Andererseits sind Frachträume oft fälschlicherweise ausgebucht, weil aufgrund falscher (zu hoher) Volumenangaben das maximal mögliche Volumen eines Flugs bereits erreicht ist, obwohl noch Kapazitäten vorhanden wären. Und schließlich kann eine falsche Datenlage zur Folge haben, dass Sendungen nicht transportiert werden können, da die Transportkapazität bereits frühzeitig erschöpft ist, was nicht rechtzeitig erkannt werden konnte, da die Kommunikationssysteme des Stands der Technik keine Kontrolle über die korrekten Kapazitäten zulassen. Beispiel 7
Das folgende Beispiel soll verschiedene mögliche Kommunikationswege des BATCH-Systems näher beschreiben.
Ein großer Vorteil des BATCH-Systems ist es, dass ein Anwender das von ihm bevorzugte Medium für die Datenübertragung frei wählen kann. Das BATCH- System vermag praktisch mittels sämtlicher bekannter Übertragungsmedien zu kommunizieren. Um die Kommunikationskosten niedrig zu halten, ist das BATCH- System vorzugsweise mit einem internen Kommunikationsmanagement, welches die Daten über das Internet versendet, ausgerüstet. Bei der Datenübertragung über das Internet werden die marktüblichen Standards der höchsten Datensicherheit gewahrt.
Hat ein Handlingsagent eine zu transportierende Sendung bereits verladen, müssen die Daten spätestens unmittelbar nach dem Abflug des Flugzeuges dem Zentralrechner übermittelt werden. Ist der Startflughafen beispielsweise Berlin und soll eine Sendung nach Mexiko transportiert werden, so muss diese Sendung auf einem europäischen Flughafen umgeladen werden, wenn eine Fluggesellschaft gewählt wurde, die nicht direkt von Berlin nach Mexiko fliegt. In diesem Fall bleiben nur ca. 2 bis 3 Stunden, bis das Frachtgut in der Transitstation angekommen ist. Spätestens zu diesem Zeitpunkt müssen die Daten ebenfalls vor Ort sein.
Daher vertraut das BATCH-System nicht auf einen Kommunikationsweg, sondern gestattet Alternativen.
So kann der Handlingsagent in dem vorstehenden Beispielfall beim Ausfall des Internets seine Daten auch über ein Faxmodem oder einen Telfonkoppler etc. versenden. Ein Einsatz des SITA-Systems wäre ebenso denkbar. Allein der guten Verfügbarkeit und der günstigen Kosten-Nutzen Relation wegen wird das Internet als bevorzugtes Kommunikationsmedium für das BATCH-System betrachtet. Beispiel 8
Das nachfolgende Beispiel erläutert den so genannten Software Service des BATCH-Systems.
Unter Software Service wird hier die Bereitstellung von Programmaktualisierungen (Updates) verstanden. Um einen permanent reibungslosen Ablauf des weltweit einsetzbaren BATCH-Systems zu gewährleisten, kann mittels einer Fernwartung auf einen lokalen Rechner jedes Anwenders zugegriffen werden (remote trouble shooting). Darüber hinaus werden den Anwendern Aktualisierungen der systeminternen Datenbanken über das BATCH-System übermittelt und in das lokale System integriert, so dass alle Anwender des BATCH-Systems stets auf dem neuesten Systemstand sind.
Wie im vorherigen Beispiel 7 dargelegt, bleibt für die Datenübertragung oft nur wenig Zeit. Deshalb ist es insbesondere wichtig, dass einem Anwender sofort geholfen werden kann, wenn das BATCH-System nicht erwartungsgemäß funktionieren sollte.
Die neueste Datenlage ist dabei ein wichtiger Faktor im BATCH-System und ist vor allem für die Vermeidung von Fehlern relevant (vgl. hierzu das Beispiel 2).
Beispiel 9
Das nachfolgende Beispiel soll die strukturellen Komponenten einer erfindungsgemäßen Kommunikationsanordnung am Beispiel des BATCH-Systems näher erläutern.
Zur Anwendung des BATCH-Systems werden ein Zentralrechner und ein oder bevorzugt mehrere lokale Rechner eingesetzt. Die Aufgabe des Zentralrechners wird dabei von einem Netzwerkserver mit entsprechender Kommunikationsmanagement-Anbindung übernommen. Die Kommunikationsmanagement- Anbindung kann dabei vielschichtig ausgestaltet sein, um den Anwendern eine breite Auswahl von Kommunikationswegen zur Verfügung zu stellen (z. B. Datenübertragung über das Internet, über das Telexsystem SITA etc.).
Die Aufgabe des lokalen Rechners wird von einer Hardwarekomponente übernommen, welche als lokaler Server eingesetzt wird. Diese als „black box" bezeichnete Hardwarekomponente kann ein Anwender einfach an sein bestehendes Serversystem anschließen. Verfügt ein Anwender über kein eigenes
Serversystem, kann er auch bestehende Client-PCs direkt an die black box anschließen. Die black box stellt ein reduziertes Serversystem dar, welches neben Anwendungen des BATCH-Systems keine weiteren Dienste ausführen kann. Aus diesem eingeschränkten Funktionsumfang resultieren mehrere Vorteile:
1. Es besteht die Möglichkeit, eine Fernwartung (remote trouble shooting, s. Beispiel 8) anzubieten, ohne dass die Gefahr eines unberechtigten Eingriffs auf weitere Server eines Anwenders befürchtet werden muss.
2. Kein Anwender kann über die black box artfremde Anwendungen wie etwa Surfen im Internet, Spiele etc. durchführen.
3. Höchste Sicherheitskonzepte auch physischer Natur können an dem Server
(der black box) umgesetzt werden.
4. Durch ein einheitliches Rechnersystem ist auch eine einfache Kommunikation mit allen Anwendern möglich, um beispielsweise Aktualisierungen (Updates) zu laden.
5. Die black box kann sich selbst bei Schwierigkeiten mit dem Zentralrechner verbinden (z. B. über cron-Tabellen) und aufgetretene Fehler melden (beispielsweise, dass die Festplattenkapazität bzw. die Kapazität eines anderen verwendeten Speichers wie beispielsweise eines Flashspeichers der black box zu 70 % aufgelastet ist, was ein Anzeichen für eine Fehlfunktion der Speicherung wäre). Da die black box vorkonfiguriert werden kann, können Installationsprobleme vermieden und auch ein einfacher Austausch der black box ermöglicht werden.
Mehrere lokale Server (black boxes) kommunizieren mit dem Zentralrechner (zentraler Server), dem Herzstück des BATCH-Systems. Das bevorzugte Kommunikationsmedium zwischen den lokalen und dem zentralen Server ist das Internet.
Für jede Fluggesellschaft, die das BATCH-System einsetzt, wird aus datenschutzrechtlichen Gründen ein eigener zentraler Server eingerichtet. So kann die Möglichkeit der Einsichtnahme in die Daten einer konkurrierenden Fluggesellschaft ausgeschlossen werden. Sofern mehrere Fluggesellschaften zu einem Kooperationsnetzwerk wie beispielsweise der Star Alliance zusammengeschlossen sind, ist es auch denkbar, dass lediglich ein Server für alle Fluggesellschaften, die Partner in solch einem Netzwerk sind, zum Einsatz kommt. Dies hängt von den jeweiligen Datenschutzanforderungen der beteiligten Fluggesellschaften ab und hat keinen Einfluss auf die Funktionalität des BATCH- Systems.
Ein derartiges datenschutzrechtliches Trennungsprinzip gilt auch für den Einsatz der black box. Dabei findet bevorzugt allerdings keine physische Trennung zwischen unterschiedlichen Fluggesellschaften statt, wie sie bei der Organisation über mehrere Server vorliegt. Vielmehr wird für jede Fluggesellschaft ein eigener, passwortgeschützter Desktop auf Seiten des oder der mit der black box verbundenen Client-PCs zur Verfügung gestellt (Multiple Desktop System).
Für einen Anwender des BATCH-Systems wäre es allerdings am vorteilhaftesten, wenn er ausgehend von einem Desktop auf einem PC mit den Servern verschiedener Fluggesellschaften kommunizieren könnte. Eine solchermaßen vereinfachte Kommunikation ist mit dem BATCH-System ohne weiteres möglich. Ob sie auch tatsächlich angewendet wird, hängt von den Wünschen und Anforderungen der jeweiligen Fluggesellschaften ab. Bei besonders rigiden Datenschutzanforderungen ist es darüber hinaus auch denkbar, dass ein Anwender (z. B. ein Handlingsagent) mehrere black boxes - beispielsweise eine für jeden individuellen zentralen Server einer Fluggesellschaft - verwendet. Diese Lösung wird aber eher als unvorteilhaft angesehen, da sie mit deutlich höherem Installations- und Wartungsaufwand auf Seiten der lokalen Server verbunden ist.
Das BATCH-System ist plattformunabhängig und somit unter allen gängigen Betriebssystemen einsetzbar. Zum Einsatz kommen aktuelle Softwarestandards, wie z. B. ein Datenaustausch im XML-Format mittels Applicationservices. Im Datenbankbereich werden sowohl etablierte Systeme marktführender Firmen als auch Softwaresysteme aus dem so genannten Open-Source-Bereich verwendet.
* * * * *

Claims

Patentansprüche
1. Verfahren zur Datenübermittlung zwischen mindestens zwei Teilnehmern eines Transportgut- oder Personen-Transportprozesses unter Verwendung mindestens eines Zentralrechners, wobei jedem Teilnehmer ein lokaler
Rechner zugeordnet ist und in mindestens einem der lokalen Rechner transportprozessrelevante Daten erfasst werden und wobei jeder lokale Rechner mit dem Zentralrechner kommunizieren kann,
dadurch gekennzeichnet, dass
die Datenübermittlung zwischen jedem der Teilnehmer (10; 11 ; 13; 14; 20; 21 ; 23; 24; 30; 33; 34) und dem Zentralrechner (Z, 50) direkt, automatisiert und bidirektional erfolgt, wobei die transportprozessrelevanten Daten jedes Teilnehmers (10; 11 ; 13; 14; 20; 21 ; 23; 24; 30; 33; 34) über den
Zentralrechner (Z, 50) jedem anderen Teilnehmer (10; 11 ; 13; 14; 20; 21 ; 23; 24; 30; 33; 34) zugänglich gemacht werden und wobei jeder der Teilnehmer (10; 11 ; 13; 14; 20; 21 ; 23; 24; 30; 33; 34) über die transportprozessrelevanten Daten jedes jeweils anderen Teilnehmers (10; 11 ; 13; 14; 20; 21 ; 23; 24; 30; 33; 34) während des Transportprozesses aktiv durch den
Zentralrechner informiert wird.
2. Verfahren nach Anspruch 1 , dadurch gekennzeichnet, dass die Teilnehmer Handlingsagenten (13; 33; 23), Spediteure (11 ; 21 ), Versender (10), Zollbedienstete (14; 24; 34), Transporteure (30) und/oder Empfänger (20) sind.
3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass der Transporteur (30) eine Fluggesellschaft ist.
4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass in dem Transportprozess befördertes Transportgut Waren bzw. Güter sind.
5. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass eine Mehrzahl von Teilnehmern (10; 11 ; 13; 14; 20; 21 ; 23; 24; 30; 33; 34) bereits vor dem physikalischen Kontakt mit dem Transportgut durch den Zentralrechner (Z, 50) über das zu bearbeitende
Transportgut informiert wird, sobald die Daten über das Transportgut zum ersten Mal dem Zentralrechner (Z, 50) übermittelt werden, wobei diese erste Übermittlung insbesondere durch den Versender (10) des Transportguts erfolgt.
6. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass bei der Erfassung der Daten im lokalen Rechner (L) jeweils ein Abgleich dieser Daten mit über den Zentralrechner (Z, 50) zur Verfügung gestellten Angaben erfolgt.
7. Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass die Angaben Informationen über den oder die Teilnehmer (10; 11 ; 13; 14; 20; 21 ; 23; 24; 30; 33; 34), die Flug- oder Fahrpläne der Transporteure (30), gesetzliche und/oder zollamtliche Bestimmungen, internationale Abkommen, Informationen über die zur Verfügung stehenden Transportmittel und/oder
Bestimmungen der Transporteure (30) umfassen.
8. Verfahren nach Anspruch 6 oder 7, dadurch gekennzeichnet, dass in Abhängigkeit der über den Zentralrechner (Z, 50) zur Verfügung gestellten Angaben nur die Daten erfasst werden, die für den jeweiligen
Transportprozess benötigt werden.
9. Verfahren nach einem der Ansprüche 6 bis 8, dadurch gekennzeichnet, dass bei der Datenerfassung durch den Angabenabgleich eine logische Überprüfung der Daten erfolgt und der Teilnehmer (10; 11 ; 13; 14; 20; 21 ; 23;
24; 30; 33; 34) aufgefordert wird, zu einem erfolgreichen Abschluss der Datenerfassung ggf. aufgetretene Fehler zu korrigieren.
10. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Datenerfassung bei jedem Teilnehmer (10; 11 ; 13; 14; 20; 21 ; 23; 24; 30; 33; 34) in mindestens einer von mehreren Sprachen erfolgen kann, die Datenübermittlung unabhängig von der mindestens einen bei der Datenerfassung ausgewählten Sprache erfolgt und die Daten bei jedem der anderen Teilnehmer (10; 11 ; 13; 14; 20; 21 ; 23; 24; 30; 33; 34) in mindestens einer von mehreren Sprachen dargestellt werden, wobei die jeweils verwendete Sprache für jeden Teilnehmer (10; 11 ; 13; 14; 20; 21 ; 23; 24; 30; 33; 34) individuell auswählbar ist.
11. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass jeder Teilnehmer (10; 11 ; 13; 14; 20; 21 ; 23; 24; 30; 33; 34) zu erfassende Daten aus einer Datenmenge auswählen kann, für die keine Angaben im Zentralrechner (Z, 50) hinterlegt sind.
12. Kommunikationsanordnung zur Durchführung eines Verfahrens nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet, dass
die Kommunikationsanordnung eine Mehrzahl von lokalen Rechnern (L) und mindestens einen Zentralrechner (Z, 50) aufweist, wobei jedem Teilnehmer (10; 11 ; 13; 14; 20; 21 ; 23; 24; 30; 33; 34) des Transportprozesses ein lokaler Rechner (L) zugeordnet ist und wobei der Zentralrechner (Z, 50) und die lokalen Rechner (L) derart miteinander in einem datenübermittelnden
Netzwerk (65) angeordnet sind, dass Daten zwischen den einzelnen lokalen Rechnern (L) und dem Zentralrechner (Z, 50) übermittelt werden können.
13. Kommunikationsanordnung nach Anspruch 12, dadurch gekennzeichnet, dass die Kommunikationsanordnung derart ausgestaltet ist, dass sie das
Internet als datenübermittelndes Netzwerk (65) verwendet.
14. Kommunikationsanordnung nach Anspruch 12 oder 13, dadurch gekennzeichnet, dass die lokalen Rechner (L) als lokale Server ausgestaltet sind, die einen eingeschränkten Funktionsumfang aufweisen und die im Wesentlichen nur solche Anwendungen ausführen, die zur Durchführung eines Verfahrens nach einem der Ansprüche 1 bis 10 notwendig sind.
15. Kommunikationsanordnung nach Anspruch 14, dadurch gekennzeichnet, dass die lokalen Server (L) in ein bestehendes Serversystem eingebunden sind oder direkt mit mindestens einem Personalcomputer (60), welcher die Funktion eines Clients ausübt, verbunden sind.
16. Kommunikationsanordnung nach einem der Ansprüche 12 bis 15, dadurch gekennzeichnet, dass die Anzahl der eingesetzten Zentralrechner (Z, 50) der Anzahl der Transporteure (30), die die Kommunikationsanordnung verwenden, entspricht.
PCT/EP2007/001696 2006-02-24 2007-02-23 Verfahren und kommunikationsanordnung zur datenübermittlung zwischen mindestens zwei teilnehmern eines transportgut- oder personen-transportprozesses WO2007098930A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102006009430.1 2006-02-24
DE200610009430 DE102006009430B3 (de) 2006-02-24 2006-02-24 Verfahren und Kommunikationsanordnung zur Datenübermittlung zwischen mindestens zwei Teilnehmern eines Transportgut- oder Personen-Tranportprozesses

Publications (1)

Publication Number Publication Date
WO2007098930A1 true WO2007098930A1 (de) 2007-09-07

Family

ID=38055272

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2007/001696 WO2007098930A1 (de) 2006-02-24 2007-02-23 Verfahren und kommunikationsanordnung zur datenübermittlung zwischen mindestens zwei teilnehmern eines transportgut- oder personen-transportprozesses

Country Status (2)

Country Link
DE (1) DE102006009430B3 (de)
WO (1) WO2007098930A1 (de)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0251098A1 (de) * 1986-06-25 1988-01-07 Siemens Aktiengesellschaft Verfahren zum Erstellen und Ausfüllen von Formularen mittels einer Textstation
EP0376316A2 (de) * 1988-12-29 1990-07-04 International Business Machines Corporation Nachrichten- und Bildschirmübertragung für Rechner in einem mehrsprachigen Netzwerk
DE10022039A1 (de) * 1999-09-24 2001-04-12 Christian Brandel Verfahren zum Auswerten von Informationen
WO2001069423A1 (en) * 2000-03-15 2001-09-20 Hiawatha Island Software Co., Inc. System and method for providing computer network search services
WO2002084540A1 (de) * 2001-04-17 2002-10-24 Bucko Software Gmbh Verfahren zur automatischen steuerung und/oder regelung von warenströmen sowie versandlogistiksystem

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1350197A2 (de) * 2000-04-04 2003-10-08 Marconi Corporation PLC Logistik- und verfolgungsverwaltungssystem und verfahren
AUPR105300A0 (en) * 2000-10-27 2000-11-23 Electronic International Trade Services Pty Ltd Electronic international trading
US20050119926A1 (en) * 2003-12-01 2005-06-02 Leon Turetsky Method and system for managing multi-national integrated trade and logistics and processes for efficient, timely, and compliant movement of goods across international borders

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0251098A1 (de) * 1986-06-25 1988-01-07 Siemens Aktiengesellschaft Verfahren zum Erstellen und Ausfüllen von Formularen mittels einer Textstation
EP0376316A2 (de) * 1988-12-29 1990-07-04 International Business Machines Corporation Nachrichten- und Bildschirmübertragung für Rechner in einem mehrsprachigen Netzwerk
DE10022039A1 (de) * 1999-09-24 2001-04-12 Christian Brandel Verfahren zum Auswerten von Informationen
WO2001069423A1 (en) * 2000-03-15 2001-09-20 Hiawatha Island Software Co., Inc. System and method for providing computer network search services
WO2002084540A1 (de) * 2001-04-17 2002-10-24 Bucko Software Gmbh Verfahren zur automatischen steuerung und/oder regelung von warenströmen sowie versandlogistiksystem

Also Published As

Publication number Publication date
DE102006009430B3 (de) 2007-08-02

Similar Documents

Publication Publication Date Title
DE69628308T2 (de) Behälter-überwachungssystem und verfahren
DE102005019280B4 (de) Maschinenlesbare Kennungen nutzendes Flugzeug-Frachtladelogistiksystem
DE202014002582U1 (de) Computergerät zur Verwendung während des Fluges für eine Flugzeugkabinenbesatzung
DE102005019194A1 (de) Flugzeug-Frachtladelogistiksystem
DE102015109660A1 (de) Verfahren und System für On-Demand-Transportdienste
DE202017007516U1 (de) Optimiertes Logistikmanagementsystem
WO2004091813A1 (de) Verfahren und einrichtung zum verteilen von paketen o. dgl. beförderungsgütern
WO2015169604A1 (de) Verfahren und vorrichtungsanordnung zur abwicklung der aufgabe von reisegepäck
DE212019000268U1 (de) System zum Liefern von Gepäck
DE102018205289A1 (de) System zur Bestandsführung einer Bordverpflegung eines Fahrzeugs
DE19805465A1 (de) Verfahren und Vorrichtung zur Steuerung und Überwachung eines Materialflusses
DE202018107285U1 (de) Artikelverfolgungssystem
EP3399482A1 (de) Verfahren zur handhabung eines frachtcontainers
DE112017007948T5 (de) System und Verfahren zur Verwaltung des Betriebs eines kommerziellen Transportfahrzeugs
DE202016007418U1 (de) Abflugkontrollsystem
EP4075356A1 (de) System und verfahren für den versand von postsendungen
DE102017217926A1 (de) Verfahren zum Betrieb eines Paketautomaten und Paketautomat
DE102006009430B3 (de) Verfahren und Kommunikationsanordnung zur Datenübermittlung zwischen mindestens zwei Teilnehmern eines Transportgut- oder Personen-Tranportprozesses
DE202012104079U1 (de) System zum mobilen Einchecken
EP2617498B1 (de) Verfahren zur verbesserten Bearbeitung von Postsendungen und System zur Ermöglichung einer verbesserten Bearbeitung von Postsendungen
DE19830777A1 (de) Verfahren zur Datenübermittlung und -verarbeitung im Zusammenhang mit der Beförderung von Gütern
EP3140788A1 (de) Verfahren und vorrichtungsanordnung zur erstellung und ausgabe eines gepäckanhängers
EP2863347A1 (de) System und Verfahren für den Versand von Postsendungen
DE202018006807U1 (de) Paketautomat
EP3598383A1 (de) System zur gesicherten ausgabe von objekten

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS (EPO FORM 1205A DATED 01-12-2008)

122 Ep: pct application non-entry in european phase

Ref document number: 07722952

Country of ref document: EP

Kind code of ref document: A1