Download System documentation

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts
no text concepts found
Transcript
System documentation
QualityMark Web System (QMWS)
Side 1 av 21
Table of Contents
1
INTRO ............................................................................................................................ 3
2
SYSTEM COMPONENTS ................................................................................................. 3
2.1
2.2
2.2.1
2.2.2
2.2.3
2.2.4
2.2.5
2.2.6
2.3
HIGH-LEVEL OVERVIEW OF SYSTEM COMPONENTS ...........................................................................3
MAIN COMPONENTS DESCRIPTION ...............................................................................................4
Membership/authentication ...............................................................................................4
Form Engine.........................................................................................................................4
Scoring Engine .....................................................................................................................4
Guest satisfaction surveys ...................................................................................................4
Hotel Surveys .......................................................................................................................4
Inspections...........................................................................................................................4
ROLES OF THE FORM ENGINE, SCORING ENGINE AND .NET FRAMEWORK ............................................5
3
USER ROLES AND PRIVILEGES ........................................................................................ 5
3.1
3.2
USER TYPES .............................................................................................................................5
SYSTEM PRIVILEGES ...................................................................................................................6
4
SYSTEM FUNCTIONALITY – USER STORIES ..................................................................... 7
5
WORKFLOWS - MAIN PROCESSES ................................................................................ 12
5.1
5.2
5.2.1
APPLICATION PROCESS FLOWCHART ...........................................................................................12
APPLICATION PROCESS DESCRIPTION...........................................................................................13
Hotel Application Statuses.................................................................................................13
6
INTEGRATIONS - OVERVIEW ........................................................................................ 14
6.1
6.1.1
6.1.2
6.1.3
6.1.4
MAP OF INTEGRATION POINTS ..................................................................................................14
Integration with the Content Management System (CMS) ...............................................14
Brønnøysundregisterne (BRREG) .......................................................................................15
Web Services API for 3rd party integrations ......................................................................15
Microsoft Dynamics NAV 5.0 (Navision) ............................................................................16
7
DATABASE STRUCTURE ............................................................................................... 18
7.1
7.2
7.2.1
7.2.2
7.2.3
7.2.4
7.2.5
7.2.6
7.2.7
7.3
DATABASE DIAGRAM ...............................................................................................................18
DATABASE TABLE DESCRIPTIONS ................................................................................................19
Membership entities ..........................................................................................................19
Form Engine entities ..........................................................................................................19
Hotel evaluation process entities ......................................................................................20
Guest survey entities .........................................................................................................20
Hotel Appeal ......................................................................................................................20
Invoices ..............................................................................................................................20
Configuration .....................................................................................................................20
STORED PROCEDURES ..............................................................................................................21
8
SYSTEM REQUIREMENTS ............................................................................................. 21
Side 2 av 21
1 Intro
The QualityMark WebSystem has been developed to facilitate the collection of metrics from hotels
and quality classification (scoring) based on these data.
The system allows hotel representatives to create accounts, log on and submit applications for
quality classification on behalf of the hotel(s) they represent. The hotel representative must also
initiate a guest satisfaction survey by uploading email addresses of guests who have recently
stayed at the hotel. The metrics provided in the application process are combined with data from
the guest satisfaction survey and result in a star rating for the hotel.
Inspectors can be dispatched to verify the information given in the application before final
approval or rejection. The system supports the workflow from the initial application is sent through
guest satisfaction surveys, inspections, rating appeals, final classification and all the way to the
invoice has been paid.
2 System components
2.1
High-level overview of system components
The QMWS application consists of 6 main modules which connects an ERP system for invoicing and
a CMS for web content management.


Content Management system
 MojoPortal
Application
Cluster
Membership Module
Guest Satisfaction
Form Engine
Side 3 av 21
Database
Scoring Engine
Hotel Surveys
Inspections
Economy / ERP system
 Navision 5.0
These modules connect to one or more MSSQL databases, preferably running on the
same server.
Data Access Layer

QMWS modules
1. Membership/authentication
2. Form engine
3. Scoring engine
4. Guest satisfaction surveys
5. Hotel surveys
6. Inspections
Economy system
database
QMWS WebService
CMS
2.2
2.2.1
Main components description
Membership/authentication
The Membership module is based upon standard Microsoft membership engine with necessary
extensions to fit application requirements. It is responsible for creating (registering) new users,
authenticating them and checking access rights depending on the roles given.
The system system uses several as defined in chapter 4.1.
2.2.2
Form Engine
This is one of the key modules of the application. It is responsible for definition and rendering of
survey forms.
2.2.3
Scoring Engine
This is another key module of the application. It is responsible for collecting and proper calculation
of survey score.
2.2.4
Guest satisfaction surveys
This component handles import of email addresses, sending of invitation emails and the workflow
for collecting guest satisfaction metrics from hotel guests.
2.2.5
Hotel Surveys
This component handles the workflow of the hotel classification surveys. A representative for the
hotel needs to fill an application for the hotel to be evaluated. The application is a long survey with
questions covering all areas that are significant for evaluation process.
2.2.6
Inspections
This component handles the workflow of the inspection process. Each application needs to be
verified by inspectors and confirmed by a person authorized for giving final approval.
Side 4 av 21
2.3
Roles of the Form Engine, Scoring engine and .NET framework
The following table shows responsibility areas of these main components.
Core system
(.NET)




Account creation
Authentication
Design / navigation
Interface with other
systems
Form engine






Define forms
Store forms
Render HTML
Handle form versioning
Receive and store form
data (applications)
Handle application
versioning
Scoring engine




Define scoring rules
Store scoring rules
Perform scoring process
Handle scoring rules
versioning
3 User roles and privileges
3.1
User types
The system and it’s documentation relates to 8 user roles:








“Anonymous” – users who have not yet authenticated
“Any user” – any authenticated or not authenticated user
“Hotel guest” – hotel guests (guest satisfaction survey participants)
“Hotel representatives” – users who represent a hotel
“Inspectors” – users who are authorized to verify hotel applications
“Staff” – users employed by the organization operating the system
“Admin” – users authorized to approve quality ratings
“Sysadmin” – technical users with system administration privileges
Side 5 av 21
3.2
System privileges
Hotel
”my pages”








Create account
Reset forgotten
pw
See current
status of the
application
Manage
company info
and hotel info
Change pw
Send application
Appeal an
application
decision
View delta report
Inspector
section



View
application
lists
Manage
applications
Manage
exemptions
Staff section



Manage
company info
and hotel info
View reports
All activities of
Inspector
Sysadmin
section
Admin section









Manage articles
(CMS)
Manage forms
Manage prices
Manage users
Assign inspectors
Send invoices
Import email
addresses for
guest satisf.
survey
Manage appeals
All activities of
NHO Staff

Manage
system
settings
Hotel guest
section

In addition to these roles, the content management system and the ERP system have their own
lists of users authorized for managing web content, generating invoices etc.
Side 6 av 21
Send guest
satisfaction
survey
4 System functionality – user stories
The functionality descriptions are presented in user story format and should be read as follows:
As <Role> I want to be able to <What> so that I can <Purpose>. A column with more info is also supplied.
Ref. Role
What
Purpose
More info
1 an anonymous user
create an account
gain access to the
system
Use email as username. User
generated password. The user
also gives information about
the hotel (org.nr + Tellus-ID).
Welcome-email sent after
account creation.
2 an anonymous user
accept Terms of Service
continue with my first
login
• Accept contract / purchase
order online (general terms?)
Terms of service as PDF file.
Must require two check boxes
to continue the process:
1. I have read and understood
the contract (link)
2. I agree to the contract terms
The "confirm" button should
be located on the screen in
such a way that you cannot
accidentally double-click from
the previous screen and end
up confirming the Terms
involuntarily.
3 an anonymous user
log in to a web based
perform my work as the
system for hotel
role I have been given
classification, that allows
me to access the
functionality I have
sufficient privileges to use
4 any user
review account
information
verify the recorded
information and make
updates if necessary
Connect to BRREG interface:
Send orgnr. and fetch
organization data
5 any user
reset forgotten password
log in if I've lost my
password
Generate random pw and
send to recorded email
address
6 a "hotel guest"
send guest satisfaction
survey
Simple (yes/no) form with
reports of aggregated results
7 a "hotel guest"
perform an extended
guest satisfaction survey
Questions with values 0-10).
Statistical calculations and
scoring as defined in the
documentation.
Side 7 av 21
Ref. Role
What
Purpose
More info
8 a "hotel guest"
see a confirmation page
after the guest
satisfaction survey form,
and also receive a thankyou email
know that my survey was
submitted sucessfully
9 a "hotel rep"
see an introduction info
article
better understand what
the system allows me to
do, and how I can get
assistance if I need it
HTML content from Mojo CMS
10 a "hotel rep"
manage company info
and hotel info
verify the recorded
information and make
updates if necessary
Some fields are read-only
11 a "hotel rep"
send an application for
hotel classification
get a rating for the hotel I
represent
12 a "hotel rep"
quit the without
submitting the application
during any step of the
process, and come back
to finish the draft later
check documentation etc. Save draft data on each step
the user completes, so that it
can be picked up later if the
application process is aborted
13 a "hotel rep"
delay a question when
filling out the application
for hotel classification
come back to
unanswered questions
later (in case I need to
check documentation
etc.)
14 a "hotel rep"
change my password
choose a password I will
remember
15 a "hotel rep"
Import email addresses
for guest satisfaction
surveys and send out
survey invitations
send out survey invites to To maintain anonymity: Import
guests of each given
emails, generate unique IDs,
hotel
send email with unique URL,
delete email address
Single multiline textfield for
import of email addresses
16 a "hotel rep"
see the completion rate
of the application process
17 a "hotel rep"
avoid the first step of the
application process
18 a "hotel rep"
be unable to change the
ambition level to a lower
level than whats
calculated by the system
19 a "hotel rep"
print all questions in a
form (with my answers)
from “my page”
20 a "hotel rep"
see info about guest
satisfaction surveys
How many replies + first and
last date of reply. NOT details
of each reply.
21 a "hotel rep"
Import email addresses
for guest satisfaction
surveys and send out
survey invitations
We require multiple fields
when importing emails: email,
checkin date, checkout date
22 a "hotel rep"
set "position" in the
contact person profile
23 a "hotel rep"
set "legal contact" in the
company profile
Side 8 av 21
see how much I have left
to answer in the
questionaire
"You have completed 27% of
the survey"
get a 100% accurate
rating that's not possible
to cheat
Ref. Role
What
Purpose
24 a "hotel rep"
see a list of unanswered
questions (delayed
questions) at the end of
the application process
come back to unanswered
questions later, and don't
have to see all the answered
questions.
25 a "hotel rep"
see information about
my current rating, and
status of new
applications
upgrade my application
when applying for a new
level (ie. from 3 to 4) in
a way that allows me to
see my previous
answers
know the application status
and how the hotel I
represent has scored.
Status of application and
rating of finished application.
avoid reanswering the same
questions
Assuming that the form
version has not changed
26 a "hotel rep"
More info
27 a "hotel rep"
submit a complaint for
overrides that the
inspector has made to
my anwers
Use web system instead
28 a "hotel rep"
see extended scorecard
information about my
current rating
29 a "hotel rep"
show the delta list from
"my page"
30 a "hotel rep"
view a "delta report"
see which things my hotel
must change to get a better
rating
31 an "inspector"
manage hotel info,
applications and assign
inspector(s) from the list
of hotels and
applications
easily manage
Sortable list showing hotel
hotels/applications/resources info, application date, due for
next reevaluation, geography
etc. Dynamically sortable and
filterable (ie. I want to see all
hotels in Bergen that are up
for reevaluation).
know the application status
and how the hotel I
represent has scored.
Rating, customer satisfaction
score, application status
Save the delta-list during the
application process, then
show the list as a report in
"my page"
Only the role "nho-admin"
can assign inspectors and
manage hotel info
32 an "inspector"
manage applications
(extended)
effectively handle
applications
Sortable / dynamic table.
Possible to sort by
geography setc.
Inspect, review and give
recommedation to approve or
reject
Side 9 av 21
Ref. Role
33 an "inspector"
What
Purpose
More info
manage applications
see his own applications
and choose to set
inspection status
Necessary views: New
applications, in processing,
approved, rejected
Simple table
Functionality: view his own
applications (assigned to him),
perform inspection, disagree
to answers (override hotel rep
answers - must have
comment), suggest status,
also change status to
unsubmitted.
All changes must require
comments, and the new edit is
saved as a new version of the
application.
34 an "inspector"
view hotels that are up for know which hotels to visit
evaluation or periodic
reevaluation.
35 a "NHO staff user"
manage company info
and hotel info
36 a "NHO staff user"
view inbox statistics
Show how many applications
have various statuses (new,
processing, rejected,
accepted)
37 a "NHO staff user"
send invoices
Use shared table with the
economy system. Write
invoice data to this table and
see status of invoices.
38 a "NHO admin user"
assign an inspector to an
application
be sure that all hotels get
the followup they require
39 a "NHO admin user"
set global variables for
scoring
control basic features of
the scoring engine
40 a "NHO admin user"
create test forms that are
not exposed to real users
test new forms without
affecting live users
41 a "NHO admin user"
manage users
42 a "NHO admin user"
manage forms
Side 10 av 21
Sortable list showing hotel
info, due for next reevaluation.
Must be dynamically sortable
and filterable. Must be
possible to show only
applications for inspector X, in
the "Akershus" county.
verify the recorded
information and make
updates if necessary
Manage all users except
sysadmin
change existing forms
without loosing historic
data or change the score
results for existing
applications. I also want
to be able to make new
forms.
Must be possible to target a
form towards a specific market
segment.
Includes scoring
Ref. Role
43 a "NHO admin user"
What
Purpose
More info
assign two inspectors to
an application
prevent corruption
Option to assign two
inspectors, both of which must
approve the application until
it's finally approved
Workflow description:
1. The admin user assigns
one primary inspector and one
secondary inspector
2. The primary inspector
recommends approval (gives
a recommended status
"Recommended acceptance")
3. The secondary inspector
verifies the primarys
recommendation (new status "Recommended acceptance,
verified")
4. The NHO-admin gives the
final approval (or rejection)
status
44 a "NHO admin user"
manage appeals
handle appeals from
hotels
Accept or reject. Change
application and rescore (with
comment).
The appeal is in the web
system and the NHO admin
should be able to
change/correct the application.
45 a "NHO admin user"
manage prices
get the invoice grounds
correctly
46 a "NHO admin user"
see an applications score
card
see the scores of the
application, notations and
customer survey
47 a "NHO admin user"
manage articles (CMS)
update all info content
without having to contact
Reaktor
This is done via Reaktors
Mojo CMS.
Link to Mojo admin site from
the admin menu
48 a "sysadmin"
Side 11 av 21
manage system settings
make changes without
changing the system
code
5 Workflows - main processes
5.1
Application process flowchart
A hotel representative signs up
and logs in
Uploads list of email
addresses for guest
satisfaction survey
Submits hotel survey form
”Inspector 1" verifies the
survey (overrides hotel
answers if necessary)
”Inspector 2" verifies the
survey (overrides previous
answers if necessary)
Hotel guests fill guest
satisfaction surveys
Score results available for review (prescoring)
Admin verifies inspection results (selects
appropriate answer if inspectors differ)
Accepted by the
hotel
Not accepted by
the hotel
Hotel rep. submits complain
about the inspection results
Admin handles complaint
Scoring engine calculates the
final score
Final score is assigned to the
hotel
Side 12 av 21
5.2
Application process description
In a likely scenario the process starts by a hotel representative creating an account and logging in
to the system. The next step is filling a hotel classification application, which is a survey form to
collect data about the hotel. As the survey may take long time to complete, the user may stop
answering the survey anytime and come back later to continue from the point where he/she left
off. Pre-score results from the survey are available as soon as the form is submitted. The results
are not final until the guest satisfaction survey and the inspection process is complete, and an
Admin user has approved the survey.
To start the guest satisfaction survey, the hotel representative must also compile a list of email
addresses from guests who have recently stayed at the hotel, and upload this to the system. These
guests will receive an invitation to take part in a survey to help determine the rating of the hotel.
The invitation email contains a link to a web based survey form with questions about the stay.
After the survey is complete, inspections begin. The system allows the staff of the quality rating
organization to allocate two independent inspectors working separately. The inspectors then verify
the statements from the hotel survey and make corrections if necessary. Corrections must be
commented.
Finished inspections have to be approved by an Admin user. In case there are any difference
between inspection results from “Inspector 1” and “Inspector 2” it is Admin user who decides
which answer should be taken into consideration when calculating the final score.
If the hotel representative does not agree with the inspection results, he/she may submit a
complaint. Complaints must be either sustained or rejected by an Admin user before the
evaluation process with is finished.
The final score is calculated automatically and is assigned to the hotel. This triggers administrative
processes in the quality rating organization, such as sending new decals to the hotel, and
generating an invoice. The rating will be available on the main page and through the Web Services
interface as soon as the invoice is paid.
5.2.1
Hotel Application Statuses
Applications in the system will be given statuses based on where they are in the workflow.










”New” – application created
“Open” – draft saved, but no application submitted
“Submitted” – waiting for inspectors to be assigned
“Under Inspection” – inspector(s) are assigned and in the process of verifying
“Pending second inspector” – one inspector finished, pending second inspector review
“Inspection completed” – inspection finished, pending final review by admin user
“Hotel complaint submitted” – a hotel rep. has submitted a complaint to the inspection
“Hotel complaint rejected” – hotel complaint rejected
“Hotel complaint sustained” – hotel complaint sustained
“Finished / accepted” – application accepted (final)
Side 13 av 21
6 Integrations - overview
6.1
Map of integration points
The system interacts with several other systems such as the ERP system and Brønnøysundregisterne’s Web Services. The system does not have an API that exposes the core (internal)
functionality such as submitting applications or score processing, but exposes scoring results
through a Web Service API so 3rd party systems can fetch hotel ratings.
Navision
Writes
directly to
external
database
CMS
Reads directly
from database
QMWS
Exposes ratings
via webservice
3rd party systems
Gets data
from
webservice
BRREG
The figure (above) illustrates the subsystems the QMWS application connects to.
6.1.1
Integration with the Content Management System (CMS)
The frontpage (main web page - accessible by all internet users) is setup using mojoPortal CMS
system. It contains descriptions and introductory articles about the system. This also handles a
browsable and searchable list of evaluated hotels, including scores and notations.
The CMS is a separate system and does not share user accounts with QMWS application.
The CMS uses data from the QMWS system for two specific features: One is to show latest three
hotels evaluated on the front page (name of the hotel, city where it is located and star rate). The
second feature is to show a complete list of all evaluated hotels (hotel name, address, star rate and
notations assigned to the hotel during evaluation process). All the data is taken directly from the
QMWS application database.
Side 14 av 21
6.1.2
Brønnøysundregisterne (BRREG)
BRREG is a directory of all Norwegian organizations. The system uses this directory to verify user
entry during the signup process. To receive data from BRREG the system uses the Web Service
method hentBasisdataMini.
The full XML definition of the Web Service method can be seen as an attachment (“Attachment 3 –
BRREG XML definition .xml”).
The method hentBasisdataMini takes three parameters. The first two are login and password to
verify access to the data that’s being requested. The last parameter is Organization number of the
hotel we would like to receive the data. As a response we receive following data:


Response status code (0 = Success)
Response data:
o Organization number
o Name
o Business address (full address, city, municipality)
o Post address(full address, city, municipality)
o Organization form
o Organization form description
QMWS uses the retrieved data to pre-fill some of the fields the user has to provide during the
signup (account creation) process. This also allows the user to verify that the entered data is
correct.
6.1.3
Web Services API for 3rd party integrations
The QMWS offers data from the hotel evaluation application through a web service. This is a
service to provide data from the application for third party users, such as hotel booking sites and
travel agents. The web service provides a list of all hotels with approved quality ratings.
The Web Service provides two web methods which allow retrieving list of ranked hotels.


GetRatedHotelList
GetRatedHotelListEx
Both methods takes a string parameter.
The GetRatedHotelList-method expects comma separated organization numbers as input (ID). The
method searches the database to find all records matching the given IDs. If the ID(s) given is not
complete it finds all the records containing the given ID.
The GetRatedHotelListExone-method expects comma separated TellUs IDs. The method searches
the database to find all records matching given IDs. If the ID(s) given is not complete it finds all the
records containing the given ID.
Both methods return list of hotels as an XML document. The response structure follows:
Side 15 av 21
<hotels>
<hotel>
<orgnum>123456789</orgnum>
<tellusid>XXXXXX</tellusid>
<hotelname>NAME</hotelname>
<rating>5</rating>
<notations>Business hotel</notations>
<approved>10.05.2008</approved>
</hotel>
<hotel>
<orgnum>123456788</orgnum>
<tellusid>XXXXXY</tellusid>
<hotelname>NAME2</hotelname>
<rating>4</rating>
<notations></notations>
<approved>11.11.2008</approved>
</hotel>
</hotels>
The response string is serialized from a list of objects with following structure. It can easily be
deserialized and handled in a third party application.
public class Hotel
{
public string orgnum { get; set; }
public string tellusid { get; set; }
public string hotelname { get; set; }
public string rating { get; set; }
public string notations { get; set; }
public string approved { get; set; }
}
The QMWS Web Service takes all the data directly from the QMWS database.
6.1.4
Microsoft Dynamics NAV 5.0 (Navision)
Invoices are issued using external application – Microsoft Navision. The main system stores only a
minimal set of data related to invoices.
When an invoice is to be created the appropriate order records are created in data exchange
tables within the Navision database. Navision fetches these records and uses it’s own internal
mechanisms to create order records in Navision. An authorized Navision user can then fill in the
required data and generate the invoice
The following tables from Navision application are shared and updated by QMWS:


Billing Record Header
Billing Record Line
The Billing Record Header table stores invoice description data (issue date, customer etc). It is
important to set Ready_to_post field value to 1 and Invoice_Paid value to 0 to allow invoice being
created properly.
Side 16 av 21
The Billing Record Line table contains order lines. The QMWS system use predefined codes which
identify purchased item or service. It is the “sysadmin”-user’s responsibility to define the codes
that match codes already defined in Navision. Only then appropriate prices can be assigned.
Screenshot showing invoice grounds from QMWS available in Navision:
Screenshot showing order details:
Side 17 av 21
7 Database structure
7.1
Database diagram
The following image shows structure of the database which is used by the QMWS application.
You can find a high resolution image of the drawing above as an attachment to this document
(“Attachment 1 - Database diagram.png”).
More database details (field descriptions etc.) can be found in the attached database CREATEscript (“Attachment 2 - Database definition.sql”).
Side 18 av 21
7.2
Database table descriptions
Most of the tables in the system are self explanatory, but some require more information.
7.2.1
Membership entities
The QMWS application uses extended version of standard ASP.NET Membership functionality.
Custom extension gives several additional fields we need to handle different user category data
(Hotels, Inspectors etc.)
Standard ASP.NET membership functionality contains following tables:





aspnet_Membership (user data)
aspnet_Users (user name)
aspnet_Application (application the user has access to)
aspnet_UsersInRoles (user roles)
aspnet_Roles (role definition table)
Custom extension contains one table:

MembershipData (extended user data)
The MembershipData table contains additional columns which can handle following extended
information: Organization number, Tellus ID, NHO number, post address, etc.
7.2.2
Form Engine entities
The Form Engine handles form definition and rendering. It collects and stores necessary data in
following tables:









FormEngineApplication (application data)
FormEngineFormDefinition (definition of the survey form)
FormEngineFormType (type of the form e.g. hotel survey, guest survey)
FormEngineFormStatus (status of the form e.g. completed)
FormEngineQuestionGroup (question group definition)
FormEngineQuestionGroupCategory (question category definition)
FormEngineQuestion (question definition)
FormEngineQuestionType (question type)
FormEngineQuestionHotelSpecific (hotel specific data for question)
The main table is FormEngineApplication which is the center point for Form Engine data storage. It
defines application form entity which will be assigned to the hotel. It contains questions and valid
answers to those questions. To determine which questions are assigned to the application it uses a
link to FormEngineFormDefinition table. Every form definition is versioned to handle structure
changes in the hotel evaluation survey and avoid user confusion with unexpected changes of the
survey form.
Side 19 av 21
7.2.3
Hotel evaluation process entities
The hotel evaluation process starts when hotel representative logs in to the system and selects “fill
survey” option. First, the current version of application form is assigned to the hotel. Then the
form is rendered and shown to the user. In the hotel evaluation process the following tables are
used in addition to some of the tables from Form Engine entities list):









7.2.4
FormEngineAnswer (collects user answers)
AnswerOverride (collects all overrides made by inspectors and admin)
FormEngineApplicationStatus (shows application status)
ApplicationStatusHistory (collects historical data – all application status changes)
HotelApplicationInspection (info about inspection)
InspectionStatus (status of the inspection process)
ScorePerApplication (application score)
ScoringEngineResults (complete score for application)
ScorePerHotel (guest satisfaction score for hotel)
Guest survey entities
The hotel evaluation process includes guest evaluation of the hotel. The following tables are
involved in addition to the hotel evaluation process entities:

Guests (contains guest data required to invite him to the survey)
Guests are registered anonymously. They can provide their e-mail address to the hotel to receive
invitation with link to the guest satisfaction survey included.
7.2.5
Hotel Appeal
If the hotel representative does not agree with inspection results he/she can make a complaint
(appeal). Complaints are stored in following table:

7.2.6
Appeal
Invoices
When an admin user issues an invoice it’s data is stored in following tables:


Invoices
InvoiceItems
The above tables store basic invoice data only. Complete invoice data is stored in the Navision
system. The following remote tables are used to exchange data with Navision:


7.2.7
Billing Record Header
Billing Record Line
Configuration
There are several configuration variables stored in the database. The following table is used in this
case:
Side 20 av 21

7.3
ConfigurationVariables
Stored procedures
The QMWS application uses the stored procedures listed below:







ajd_activation_codegen
ajd_codegen
ajd_deleteuser
GeneratesAverageBaselineScore
ScoreGuestSurveyApplication
spInspection
spInspectionReview
The ajd_activation_codegen stored procedure generates a unique identifier. The identifier is used
to activate the newly created user account.
The ajd_codegen stored procedure also generates unique identifier. This identifier it is used to
verify hotel guest accessing Hotel Guest Survey.
The ajd_deleteuser stored procedure removes user from database. It also removes all records
related to the user.
The GeneratesAverageBaselineScore stored procedure generates average baseline score for all star
groups.
The ScoreGuestSurveyApplication stored procedure calculates score from applied guest surveys.
The spInspection stored procedure retrieves list of questions and answers (overrides) for the
inspector given.
The spInspectionReview stored procedure retrieves list of questions and answers (with both
inspectors’ overrides) for Admin user review.
8 System requirements
The system requires a Microsoft environment with the following specification to operate:






Microsoft Windows server operating system
Microsoft IIS 7
Microsoft SQL Server 2005
ASP.NET 3.5 Framework
Microsoft Dynamics NAV 5.0 NO SP1
mojoPortal 2.3.1.9
Side 21 av 21