Head Office Interface and Data Module Specifications
The head office system will enable remote safety checks, control of
the station, and report viewing. Each user of the system will have a password
and an associated level of access, and will be required to log in before
using the system, so that the information contained in the system is not
abused. Each process, when initiated, will start a counter which will automatically
log the user out after a long period of inactivity. The duration of the
wait until logout can be set at the installation of the system, but will
be fixed thereafter.
The following Data Flow Diagrams illustrate the hierarchy of menus and processes, as well as the travel of data between individual processes and the database:
Arrows carrying data into the processes from "outside" of the databases represent items which are supplied by the user. An explanation of each process, including the inputs and outputs, is given in detail below.
The login will ensure that only authorized users have access to the system. The user will be prompted for their user ID, and their password, on a screen similar to the one below. Based on this information, the system will grant or deny access to one of three subsystems:
Each of these three systems fulfills a different function, so access to each should be kept separate in the interest of keeping unwanted access and accidental changes to the database to a minimum. If it becomes necessary for one person to access two separate subsystems, they can access each through a different password.
Process Description:
The login session is used to verify if the user has the authorization to
access the system. The screen will show the Petro 451 Logo, as well as
fields for the input of the ID and the password. Once these are input,
the ID and the password are sent to the database for verification. If found
not to match and no database entry is found, an error message is displayed
breifly and the login screen is redisplayed.
If the ID and the password match the information in the database, the level
of access for the user will be retreived and, depending on this, the appropriate
menu will be activated. Each type of user will be resticted only to the
activities authorized by their access level.
Psudocode:
![[login screen]](login.gif)
BEGIN
clear screen;
display login screen;
place cursor in "User Name" field;
input user name from keyboard;
place cursor in "Password" field;
input password from keyboard;
on cliking of "Cancel" button:
restart process;
on cliking of "OK" button:
send user name and password to system configuration database
if user does not exist,
notify user that the login data does not correspond
with the database;
restrt process;
if password is incorrect,
notify user that the login data does not correspond
with the database;
restrt process;
get user's access level;
if access level = system administation,
start system administration subsystem;
if access level = fuel delivery,
start fuel delivery subsystem;
else,
start station control and reporting subsystem;
END
FUEL DELIVERY
For the purposes of fuel delivery, as well as for maintenance, a terminal
with a link to the head office system will be available at the station
sight.
When a fuel delivery to the station is made, the deliverer will be asked
to login to the system. The system will recognize the access level, and
allow the user to perform only a very restricted number of operations.
The user will be presented with a screen similar to the following:
![[fill tank screen]](FillTank.gif)
Process Description:
The user will first be asked to enter their name for record keeping purposes.
Then the screen will show the number of tanks and the type of fuel stored
in each, and allow the user to unlock one of these, by clicking on a button
corresponding to the appropriate tank. (It will be possible to open only
one tank per transaction.) A message will also be displayed, asking the
user to enter the amount of fuel dispensed into the tank once the filling
is finished.
When the tank is filled, the user will be expected to enter the amount
of fuel dispensed. The input will be checked to ensure that it is numeric.
If it is not, a message will be displayed asking the user to reenter the
value, stressing that units are not required. The input value as well as
the new gauge level reading, deliverer's name, and date and time of delivery
will will be stored in the central database. The tank is automatically
locked and the system will return to the login screen.
Pseudocode:
BEGIN
clear screen;
display fuel delivery screen;
querry database for type of fuel in each tank;
display fuel type beside tanks;
place cursor in "user name" field;
input user name from keyboard;
on cliking of one of the "open tank" buttons,
if the "user name" field has not been filled in,
ask the user to fill in this field first;
else
remind user to input amount of fuel dispensed
after filling the tank;
open selected tank;
place cursor in "amount of fuel dispensed" field;
input amount of fuel dispensed from keyboard;
while input is not numeric,
ask user to reenter the value;
clear the field;
place cursor in "amount of fuel dispensed" field;
input amount of fuel dispensed from keyboard;
send transaction date,
time,
user name,
user id,
type of fuel delivered,
amount of fuel delivered, and
new tank level gauge reading to the database;
restart login session process;
on clicking of the "Help" button,
display message explaining the input required
to open tanks;
on clicking of the "Exit" button,
start the login session process;
END
STATION CONTROL AND REPORTING
Calls the following modules:
Calling Sequence:
Process:
begin
display menu screen;
get pressed button;
switch(button)
case (Change Fuel Price):
call ChangeFuelPrice();
case (Station Operations):
call Display_Station_Submenu();
case (Report):
call Report_Submenu();
case (Help):
call Main_Menu_Help();
case (Quit):
call Logout();
endswitch
end.
Process:
Calls modules:
Calling Sequence:
Process:
begin
upper_bound = 100
prompt for Fuel Type
get Fuel Type
if (Fuel Type not equal to "Regular"
AND Fuel Type not equal to "Mid Grade"
AND Fuel Type not equal to "Premium"
AND Fuel Type not equal to "Diesel")
display error message
exit module
else
call Fuel.getFuelPrice()
display Fuel Type
display Fuel Price
get Fuel Price
if (Fuel Price<0
OR Fuel Price > upper_bound
OR Fuel Price is not a number)
display error message
exit module
else
display confirmation
get confirmation
if (confirmation is equal to Yes)
call Fuel.setFuelPrice
endif
endif
endif
end.
Calling Sequence:
Process:
begin
upper_bound = 10000
get maximum amount from configuration database
display maximum amount
prompt for maximum amount
get maximum amount from user
if (maximum amount < 0
OR maximum amount > upper_bound
OR maximum amount is not a number
display error message
exit module
else
display confirmation
get confirmation
if (confirmation is equal to Yes)
change maximum amount in configuration database
endif
endif
end.
Called by the following modules:
Calls the following modules:
Calling sequence:
Process:
begin
display all buttons;
get pressed button;
switch(button)
case (Activate/Shutdown Facilities):
Display_Activate_Screen();
case (Pump Status):
Display_Pump_Status();
case (Diagnostic Status):
Display_Diagnostics();
case (Tank Status):
Display_Tank_Lock();
case (Help):
Station_Operations_Help();
case (Back to Main Menu):
Main_Menu();
case (Quit):
Logout();
endswitch
end
Called by the following modules:
Calls the following modules:
Calling sequence:
Process:
begin
display help text info for 6 choices in Station Operations window;
display return button to return to window;
get pressed button;
if(button pressed)
return;
endif
end
Allow user to activate or shutdown any of the station facilities.
Description:
This process will diplay the status of all station facilities, and will
allow the user to change any one of them from "on" to "off"
or "off" to "on". Only one status for each of the station
facilities will be selected (ie. button pressed). No single one can ever
have both "on" and "off" pressed at the same time.
All selections will be buffered as the changes will not take effect immediately
but buttons will still be shown pressed according to any changes.
Each of these controlled station facilities will be represented by a pictoral
icon with two buttons beside it. The buttons will be tagged "on"
and "off" and only one will be shown pressed at all times.
We will assume any manual shutdowns or activations at the station site
will require advising Head Office prior to doing so. Therefore, a notification
on the system will not be required. We feel that it is not possible to
implement and simulate this type of real-time, immediate notification of
a manual shutdown or activation, on the system due to the time constraints
for the project.
Called by the following modules:
Calls the following modules:
Calling sequence:
Process:
begin
array new_pump_status[# of pumps];
array new_tank_status[# of tanks];
change := 0;
for i:= 1 to # of pumps do
pump_status[i] := Pump.status for pump #;
display icon for this pump_number;
display on/off buttons and status;
endfor
for i:= 1 to # of tanks do
tank_status[i] := Tank.status for tank #;
display icon for this tank_number;
display on/off buttons and status;
endfor
display return to Station Operations button;
display print button;
/*****check if any values changed******/
for i := 1 to # of pumps do
if (new_pump_status[i] != get_pump_status(i))
begin
change := 1;
break for;
end
endif
endfor
if (change != 1)
begin
for i := 1 to # of tanks do
if (new_tank_status[i] != get_tank_status(i))
begin
change := 1;
break for;
end
endif
endfor
endif
get pressed button
switch (button)
case (Print):
print_screen;
case (Return to Station Operations Menu):
return_to_SO_from_AS(change);
endswitch
end
To confirm that user changes to station facilities will take effect immediately.
Also write changes to database and initiate station changes if Continue button is selected. Activate/Shutdown Facilities status screen displayed if Redo button is selected. Text window displaying descriptions of each of the three buttons (Continue, Redo, Cancel) and what is the result when selected.
Description:
When something has been changed in the Activate/Shutdown Facilities screen,
a flag will be set (Change) to indicate this. So when the screen is exited,
a window will appear with a prompt to make sure the user wants to accept
the changes. At this time, the user is given four choices (buttons):
All information about changes are kept in a buffer and it is only written back to the database when the changes are accepted (ie. selected Continue button). The Help button will activate a help window with text describing each of the other three buttons. Contained in this window will also be an OK button to return to the previous window prompt.
Called by the following modules:
Calls the following modules:
Calling sequence:
Process:
begin
switch(change)
case (1): //change
choice := confirm();
switch (choice)
case cancel:
Station_Operations_Menu();
break;
case redo:
Display_Activate_Screen();
break;
case continue:
update Pump with new_pump_status array;
update Tank with new_tank
Station_Operations_Menu();
case help:
help_confirm();
endswitch
case (1): //no change
Main_Menu();
endswitch
end
Called by the following modules:
Calls the following modules:
Calling sequence:
Process:
begin
display window with 4 choices:
continue button
redo button
cancel button
help button
get pressed button;
close window;
return pressed button;
end
Called by the following modules:
Calls the following modules:
Calling sequence:
Process:
begin
display help text info for 4 choices in confirm window;
display return button to return to window;
get pressed button;
if(button pressed)
return;
endif
end
-Show user the status of all station pumps and related information.
Description:
The activated process will display relevant information about all the pumps
located at the station. The screen will be divided into the number of pumps
available at the station and each pump will have a section assigned to
it for displaying its information. Each pump section will have a numbered
icon to represent the pump. Different fuel types will be represented by
different icons along with the actual type of fuel in words. This will
help distinguish different fuel type immediately. Price per litre and totat
gas sold will just be simple numerical values. The pump status, whether
it is on or off, will be indicated by a highly visible flag.
All information displayed is taken from the database when this process
begins so any changes while the display is up will not be reflected immediately,
but will be shown the next time the display in brought up.
A Return to Station Operations Menu button will be available for the user
when finished viewing the information.
Called by the following modules:
Calls the following modules:
Calling sequence:
Process:
begin
for i:= 1 to # of pumps do
*info := get_pump_info(i);
display icon for this pump_number;
display info->pump_number;
display info->pump_status;
display info->fuel_sold;
endfor
display return to Station Operations button;
display print button;
get pressed button;
switch(button)
case (Print):
print_screen();
case (Return to Station Operations Menu):
Display_Station_Operations_Menu();
endswitch
end
Called by the following modules:
Calls the following modules:
Calling Sequence:
Process:
begin
find data for specified pump#;
info->pump_number := Pump.pump_number;
info->pump_status := Pump.pump_status;
info->fuel_sold := Pump.fuel_sold;
return info;
end
-Show user the status of all station tanks and related information.
Description:
Information about the status of all the tank locks at the station will
be shown in this display. Also included are the fuel types each tank is
holding. The display will be divided into parts equal to the number of
tanks at the station. Each section of the display will have information
on one of the tanks. All tanks will be represented by a numbered tank icon.
The fuel types will be represented by different icons depending on the
type. There will also be the type in words following the icon. The tank
status will be the main focus of this display so it will have a large area
devoted to it (in it's section) where it will show whether it is locked
or unlocked using highlighted words.
All information displayed is taken from the database when this process
begins so any changes while the display is up will not be reflected immediately,
but will be shown the next time the display in brought up.
A Return to Station Operations Menu button will be available for the user
when finished viewing the information. Called by the following modules:
Calls the following modules:
Calling sequence:
Process:
begin for i:= 1 to # of tanks do *info := get_tank_lock_info(i); display
icon for this tank type; display info->tank_type; display info->tank_status;
display info->amount_of_fuel; endfor display return to Station Operations
button; display print button; get pressed button switch(button) case (Print):
print_screen(); case (Return to Station Operations Menu): Display_Station_Operations_Menu();
endswitch end
Called by the following modules:
Calles the following modules:
Calling sequence:
Process:
begin
find data for specified tank#;
info->tank_type := Tank.tank_type;
info->tank_status := Tank.tank_status;
info->amount_of_fuel := Tank.amout_of_fuel;
return info;
end
-Show user the status of all station equipment and related information.
Description:
Information on station equipment will be displayed on this screen. Each
piece of equipment, either it be calibration equipment or tank equipment
or pump equipment, will be mentioned in this screen and it will show whether
it is OK or NOT OK. This will simply be highlighted text displayed beside
the name of the equipment and its icon. Each piece of equipment will have
its own icon so it can be identified/located faster.
All information displayed is taken from the database when this process
begins so any changes while the display is up will not be reflected immediately,
but will be shown the next time the display in brought up. So when a piece
of equipment suddenly malfunctions while this display is being viewed,
then it will not show up as NOT OK. ***Also note that due to time constraints
it is not possible to implement and simulate an real-time, interactive
malfunction.***
A Return to Station Operations Menu button will be available for the user
when finished viewing the information.
-Window with an explanation of each of the other 5 buttons on the menu.
Description:
The text window that is displayed will contain information about what the
following buttons do:
An OK button will be available for the user when finished viewing the information.
Called by the following modules:
Calls the following modules:
Calling sequence:
Process:
begin
*info := get_diagnostics();
display all diagnostics info;
display Return to Station Operations Menu button;
display print button;
get pressed button;
switch(button)
case (Print):
print_screen();
case (Return to Station Operations Menu):
Display_Station_Operations_Menu();
endswitch
end
Called by the following modules:
Calls the following modules:
Calling sequence:
Process:
begin
make info point to diagnostics;
return info;
end
Description:
This utility is called to return from submenus (offering this option) to
the Main Menu.
Inputs:
Menu selection by clicking the mouse pointer on the desired choice.
Outputs:
A menu is displayed to choose from the following choices:
1) Transaction Report and Backups
2) Statistics Report
3) Monthy Summaries
4) Delivery Report
5) Card Status Report
6) Change Reporting Periods
7) Help
8) Main Menu
Error Conditions:
a) none
Inputs:
Start Date or Report ID. The user has the option to print out the report.
Outputs:
It will display the corresponding report with Report ID, Start Date, Start Time, Stop Date, Stop Time, GST, PST and the Transactions themselves.
Error Conditions:
a) Syntactically incorrect inputs in which the system will notify the user and repromt for input.
b) Start Date or Report ID is out of range or not found in database.
Inputs:
To print it or not
Outputs:
It will display in a table format the current station's statistics. Which includes the Pump Number, Pump Status, Fuel Types, Fuel Price and amount sold for each pump
Error Conditions: none
Inputs:
Enter the month to be displayed. The user has the option to print out the report
Outputs:
The will display the transactions for the month, totals, GST and PSTs. Also the summary of the statistics for the month.
Error Conditions:
a) Syntactically incorrect input.
b) Month entered is out of range or not in database.
Inputs:
Enter a range of date to display or a specific delivery id. Also the option to print report.
Outputs:
An instance or instances of Delivery is displayed. Which includes Delivery ID, Delivery Date, Delivery Time, Delivery User Last Name, Delivery User First Name, Delivery User ID, Gas Type Delivered, Delivery Tank ID, Delivery Tank Level Before, Delivery Tank Level Added, Delivery Tank Level After and Delivery Total Value
Error Conditions:
a) Syntactically incorrect input.
b) Delivery ID is not in database or date is out of range.
Inputs:
The range of dates credit cards were rejected. Also the option to print the report.
Outputs:
The credit card number, card holder's name, status, and the action taken.
Error Conditions:
a) Syntactically incorrect input.
b) The specified range is not in the database.
Inputs:
The date/time of the new reporting period.
Outputs:
The date and time of the old reporting period is displayed. A prompt will ask the user if the change is what was intended and if yes then the period is changed.
Error Conditions:
a) Syntactically incorrect input.
b) The specified date or time is not in the database.
Inputs: None.
Outputs:
Displays the functionalties of each of the menu choices. Also how to make a selection.
Error Conditions: None.
Called by modules:
Calling Sequence:
Process:
Begin
Display Help Screen;
end.
Called by modules:
Calling Sequence:
Process:
Begin
Prompt for confirmation;
If (confirmation = Yes)
close databases
call login
endif
end.
SYSTEM ADMINISTRATION
This screen will allow the user to change the user accounts on the system.
This will be necessary to update the user database when staff changes occurr.
The administration screen will look similar to the following:
![[administration screen]](Administration.gif)
When the help button is pressed, the purpose of each option will be
displayed, as well as a description of the fields which need to be filled
for each.
The exit botton will log the user out and redisplay the login screen.
By selecting the appropriate page, one of the following processes will
be initiated.
Pseudocode:
BEGIN
clear screen;
display screen with choice of:
add user, (default)
delete user, and
change password;
on selecting add user,
start add user process;
on selecting delete user,
start delete user process;
on selecting change password,
start change password process;
on clicking the "Help" button,
display message describing the current choice;
on clicking the "Exit" button,
start the login session process;
END
For adding users, the system will send an entry to the user database to be added, according to the fields entered on the add user screen.
Pseudocode:
BEGIN
display "Add User" screen;
place cursor in "name" field;
input name of user to be added from keyboard;
place cursor in "password" field;
input password of new user from keyboard;
on clicking one of the access level checkboxes,
change access level of the potential user;
on clicking the "OK" button,
if all fields are filled,
send name,
password, and
access level to the database for addition;
else
ask user to fill in remaining fields;
on clicking the "Cancel" button,
clear all the fields;
restart the module;
on clicking the "Help" button,
display message describing the field to be filled
to add a new user to the database;
on clicking the "Exit" button,
start the login session process;
END
For deletion of users, the system will first verify if the user is in
the database, and if there is no corresponding entry, will prompt the user
to this effect. The administrative account on the system will be unable
to delete itself from the system, so that the user database can never be
sealed. Before any deletion takes place, the user will be asked to confirm
that they wish to delete the specified user from the database.
Pseudocode:
BEGIN
display "Delete User" screen;
place cursor in "name" field;
input name of user to be added from keyboard;
on clicking the "OK" button,
if name field is filled,
if user exists in the database,
send name to database for deletion
else
notify user that name not found in database;
else
ask user to fill in remaining fields;
on clicking the "Cancel" button,
clear all the fields;
restart the module;
on clicking the "Help" button,
display message describing the field to be filled
to add a new user to the database;
on clicking the "Exit" button,
start the login session process;
END
When a password change is requested, the system will first verify the
user's existance, then verify the current password. The user will then
be asked to retype the new password, to ensure that it was typed correctly,
before it is sent to the user database for updating.
Pseudocode:
BEGIN
display "Change Password" screen;
place cursor in "name" field;
input name of user to be added from keyboard;
place cursor in "old password" field;
input old password form keyboard;
if user exists in the database,
retrieve password from database;
else
notify user that name not found in database;
if input does not match old password,
notify user that incorrect password was entered;
else
place cursor in "new password" field;
input new password form the keyboard;
place cursor in "verify new password" field;
input verification of new password from keyboard;
while verification does not match new password,
notify user and ask them to retry;
place cursor in "new password" field;
input new password form the keyboard;
place cursor in "verify new password" field;
input verification of new password from keyboard;
send name, and
new password to database for updating;
on clicking the "Cancel" button,
clear all the fields;
restart the module;
on clicking the "Help" button,
display message describing the field to be filled
to add a new user to the database;
on clicking the "Exit" button,
start the login session process;
END
The following test cases are supposed to find errors in the designed program. Hence the system will be implemented to successfully handle these errors. For the valid input, the system should follow the procedure and produce the expected output. Also, the system should be consistent (eg, it should produce the same output value everytime for the same input value). Finally, the system should be as user friendly as possible.
Each individual module will be tested by specified test cases (see following section). Also, random input or selection will be made to verify that the module could handle most unexpected situations. An integration test will be made to make sure that the system works correctly altogether. A validation test (by some potential users) will make sure that the system will work correctly and easily operated.
The modules of this system will be integrated in a top-down fasion, once the database system is operational. Testing will generally proceed from the least complex modules (simple menus which do not call the databases, but only start other processes), to the more complex (lower in the menu structure, function wich querry the databases and send information to them).
Phong Tu, Les Loh, Francis Nguyen, and Dominik Royko will oversee the testing of the head office system. However, as these were the designers of the system, testers from other departments will be brought in, especially during the random testing and integration testing phases, to ensure that a user new to the system can easily find their bearings in the interface, and that the button labels and error messages are logical and informative.
Errors found will be reported to the implementation staff. The same people responsible for coding a specific module will be responsible for debugging as they will best be able to understand the code. If a design flaw is found, the error will be reported to the design team, where a solution will be sought which minimizes impact on the rest of the existing system.
The following conditions must be tested:
The following conditions must be tested:
Test Description:
The following test cases are used to make sure that the buttons in the
main menu corresponds to the correct procedures/screens that they associate
with.
Input: Change Fuel Price (button) is clicked
Expected Output: Change Fuel Price screen is displayed.
Input: Change Maximum Amount Allow (button) is clicked
Expected Output: Change Maximum Amount Allow screen is displayed.
Input: Station Operation (button) is clicked
Expected Output: Station Operation submenu is displayed.
Input: Reports (button) is clicked
Expected Output: Reports submenu is displayed.
Input: Help (button) is clicked
Expected Output: Help screen for Main Menu is displayed.
Test Description:
For invalid input value, the system should responds by displaying error
messages. Otherwise, expected output will be resulted.
Input: Fuel Price is -5
Expected Output:
Input: Fuel Price is blank
Expected Output:
Input: Fuel Price contains non-numeric character (except decimal point)
Expected Output:
Input: Fuel Price is greater than upper_bound (default = 100)
Expected Output:
Input: Fuel Price is 0.35
Output:
Test Description:
The following test cases will detect both invalid input and valid input.
If an invalid input is detected, the system should respond by displaying
error message. Otherwise, when the input is a valid value, the system should
follow the correct procedure and produce the expected output.
Input: maximum amount is -3
Expected Output:
Input: maximum amount is blank
Expected Output:
Input: maximum amount contains non-numeric character
Expected Output:
Input: maximum amount is greater than upper_bound (default = 10000)
Expected Output:
Input: maximum amount is 20
Output:
If no changes made:
If changes made:
results:
results: display Station Operations Menu
click on Quit button at Station Operations Menu
results: logout and exit system
click on Help button at Station Operations Menu
results:
click on Back to Main Menu button at Station Operations Menu
results: Main menu of automated system displayed with all buttons
All possible menu selection should be made and outputs should be the same everytime executed. Also all selections should be displayed at all executions.
Test for syntactical errors for start_date and report_ID. This would involve typing in invalid dates for one and both dates. Also test the case when start_date and report_ID are syntactically correct but out of range. When start_date and report_ID are syntactically correct but database does not have any data corresponding to the range. The null entry should be tested such that when start_date is null and/or end_date is null. Check output upon execution of data if it is correctly acquired and correctly displayed.
Test for different times executing this module since this module is time dependent. Also check for outputs of this module when executed at two identical times. Check output upon execution if it is correctly acquired and displayed.
Test for syntactical inputs for month which would involve entering in characters/symbols not recognizable for the input type. Input a syntactically correct input for its type but out of range. Also check for syntactically correct inputs but datastore for monthly summaries report has no entries matching this criteria. The null entry should be tested such that when input null. Check output upon execution if it is correctly acquired and displayed.
Test for syntactical errors for start_date, end_date and delivery_ID. This would involve typing in invalid dates for one and both dates and/or delivery_ID. Also test the case when start_date, end_date and report_ID are syntactically correct but out of range. Check when start_date, end_date and report_ID are syntactically correct but database does not have any data corresponding to the range. The null entry should be tested such that when start_date is null and/or end_date is null and/or delivery_ID is null. Check output upon execution if it is correctly acquired and displayed.
Test for syntactical errors for start_date and end_date. Take the case that start_date is inputed as invalid type and end_date is inputed as invalid type. Also test the case when start_date and end_date are syntactically correct but out of range. Check when start_date and end_date are syntactically correct but database does not have any data corresponding to the range. The null entry should be tested so when start_date is null and/or end_date is null. Check output upon execution if it is correctly acquired and displayed.
Test for syntactical errors for date and time. Take the case that date and time is inputed as invalid type. Also test the case when date and time are syntactically correct but out of range. Check when nothing or null is entered is as values for date and time.
Test for all possible section that it is displayed correctly and the same help is displayed for the same section for every execution.
The following conditions must be tested:
The following conditions must be tested:
The following conditions must be tested:
The following conditions must be tested:
Authors: Phong Tu (Reports, Screen Shots), Les Loh (Station Operations), Francis Nguyen (Main menus, Change Price), Dom Royko (Administration, Delivery).
Send Comments to Supplier Group 11
