Construction of the service lasted 7 months (at intervals several weeks, during the customer established solutions for next modules). This service for ages will remain in the memory of Nettom employees - both on the execution time, the interesting and unusual topic as well as more later mentions in the press and of television :)
The hierarchy consists of three separate levels.
On upper horizontal is LAMBDA administrator which is describing customers, customers are owners of the installation and it is they are choosing their contractor which is dealing with correct action of the installation.
After creating the account of the customer by the administrator, the customer can personally manage supplied services by the contractor. On my part the contractor can manage installations, with access to data etc.
Different kinds of users exist with different rights.
Two basic groups it ‘ contractor ’ and ‘ customer ’.
Contractor orders elevator, he is getting a message about problems and he is intervening.
Customer is owner of elevators.
Customer the admin can create accounts for the contractor of the admin who can, on my part to create other accounts of the type contractor (except for the admin).
Client the admin's accounts are created by admin (final)
Many accounts of every type can exist except for the account of the Main Administrator who is the only one.
Contractor – acceptor of data: he receives signals of events, he can lead by hand events to data base
Contractor – consultant: perhaps only to use the database
Contractor – secretary: can implement the information about intervention of conservators
Contractor – Admin: can be a receiver, a consultant and a secretary and manage groups of elevators who stayed allotted to him
Customer: can consult about the database and statistics
Customer admin: can create complexes of elevators and assign them to the given contractor
Administrator (final) : can do everything except creating accounts for Main Administrator
Main Administrator (final) : can do everything
Installations and users are organised into groups, similarly as ‘ workgroups ’ in computer network.
The user has the permission for the insight only into installations within the own group.
The user can be current in many groups.
The installation can be current in many groups.
User of the type customer the admin can create groups whom elevators contain and users of the type customer (and customer admin).
User the admin can create groups whom elevators contain and users of the type contractor.
Manual leading of events
The user should have the possibility of manual adding the event to the list of events for the installation.
This coincidence is taking place as a result of the customer complaint on the part of the customer road by mail, with fax, over the phone etc. … and the system of cameras didn't still communicate the information to the database.
The window of leading should take the liberty of implementing the area of the text by hand or through the pop-up list (e.g.: « phone from Mr Smith »).
The mistake should be withdrawn from the list of the pop-up type, the list of mistakes is established from above.
Type of the error it or ‘ appearance ’ or ‘ disappearing ’.
The date and the hour are being registered automatically.
Deleting the events
The user must have an opportunity to click on the event in order to delete them. Namely, if the system received the message about the failure of the lift, but erasing the error was never recorded, if handing over the lift for new use is confirmed, the user can add the end of the breakdown by hand to the database.
The name of the user which deleted the event will be registered with the date and the hour of deleting.
Entering details about performed intervention by managing the lift
Every installation must have the table assigned to her which contains the list of performed repairs in the given lift.
The user should can select the installation and to add the information about performed repairs to the list.
The user must have access to the list of possible intervention, of replaced parts itp … the List will be defined through caret sign and it he will be able to I to modify.
The user should can choose positions from the list with the help of straight clicking.
The date of the introduction will let establish whether intervention took place in the morning or in the afternoon.
The user can also choose the type of intervention (repair, urgent repair, conservation), ordering the surname of the conservator and the surname with lift (automatically) the Name of the user which added intervention to the list will be registered with the date and the hour of entering data.
Looking through data concerning intervention
The customer should have the possibility of listing of intervention in one be many lifts depending on ranges of dates, of groups of lifts (residential building, CP), managing the lift.
Alert at the receipt of the event
If is a user ‘ contractor – acceptor of data ’, at the receipt of the event the window should return his attention through the pop-up or other way attracting ... eyes.
Only events obtained from installations attributed to the given user cause pop-up.
Only one pop-up should appear for the time.
The user must see the list of received rather than regulated events.
Surname, address, defect (brightly specified) sort of the vice, hour, date, should be shown.
Every event must have the area of the text possible to lead by the user to the pop-up list configured previously with texts ‘ standard ’ definite through caret sign.
Grille to marking ‘ regulation ’, (workmanship, deleting?).
Option ‘ to regulate everything ’. When the event is regulated, the surname and user data are also being registered.
The colour and the priority of the event
The priority and the colour can be associated with every defect.
Event with the high priority (ex: passengers imprisoned in the lift) will be shown at the top lists, in the bright colour. The display order of other events will depend on the priority and the order of arriving. This selection concerns not regulated events, after regulating them, events are list in chronological order, from oldest to newest (at the top lists).
Filtering events will be possible, all events won't provoke pop-up ah should be deleted.
Alert concerning lasting events
Presetting the alarm is possible, if some events last too long (e.g. presence of the conservator). It is possible to programme the event and the length of lasting him depending on the type by the user.