| 1.1 |
User initates new order
The user initiates the order process by clicking on the order now link
on the public website.
|
| 1.2 |
Customer login
The process of logging a customer into the BPR website is done through a
single, uniform system. The login form page also offers links to
resetting a password and creating a new customer account.
|
| 1.3 |
Contact information section
This portion of the order form is rather critical since we need to know
specific information about the customer's contact information in order
to successfully process a new order. Since the user either authenticated
their account with the system prior to reaching this form or entered the
required basic information to initiate an order, the form behaves
differently based on either scenario:
Authenticated Customer (shown as "_form(order now - existing
customer)" template @ Protoshare)
The user's first and last names along with their email address are shown
as text (not editable form fields). The password, password (confirm) and
email address (confirm) fields are not present. Similarly, the user's
default billing and shipping profile information is displayed as
pre-populated form fields that are not editable (if the customer needs
to edit either address, then they must check the "edit this address"
checkbox to enable the form fields for editing). Similarly, if the user
has multiple address profiles assigned in the system, a drop-down box is
provided for them to select which address they would like to use for
this order for the appropriate section (billing vs. shipping).
Similarly, if the "edit this address" checkbox is selected then some
sort of boolean flag is flipped indicating the address profile has been
changed so that the form data is then updated with the customer account
in the system. Finally, if the user selects "new" from the address
selector drop-down then the "edit this address" checkbox is removed and
a text field is displayed allowing the user to "name" this address
profile when it is saved to their account.
New Customer (shown as "order now" template @ Protoshare)
The user's email address is populated in the email address field,
however the user must fill in all required form fields to place an
order. Similarly, when a user enters their first and last name in the
account section then the data is automatically copied to the first and
last name fields under the "billing" section, respectively, once the
user clicks/tabs out of the form field. The user can still override a
billing person's first and last name without it affecting the account's
first and last name fields. The remaining required fields are to be
filled out by the customer
Requirements
Performed By
 |
Name |
Description |
Type |
 |
Customer
|
User model representing the customer making a purchase on the BPR website
|
Person |
|
| 1.4 |
Recell service order section
This section of the order form contains the details of the service order
itself. The form will default to having three order lines which each are
blank on form load. If the user enters data into the third order line
then an additional line is added to the order form (and subsequently any
data added in the new, fourth line, will prompt for a fifth order line
to appear). The user must select the total number of unique battery
packs they are shipping, the manufacturer of the battery pack and the
voltage size of the pack. Once the quantity and voltage size is selected
then the price is populated based on the voltage size recell cost
multiplied by the quantity selected.
Also, if the customer selects to "upgrade" their pack to an extended
run-time cell and checks the box to the left of the order line then the
price is then re-calculated as the quantity x battery voltage x pack
upgrade. The customer can perform this "upgrade" at either the per pack
level or via one checkbox in the order options section. If they chose to
upgrade all packs on their order then by them checking the "upgrade all
packs" in the order options section the application will automatically
check each box to the left of each order item and perform the price
recalculations.
If the user choses to pre-pay their shipping expense to BPR's office by
checking the box "include pre-paid" in the order options section the
application will determine shipping costs with USPS based on an
anticipated weight of each pack (plus a little extra, this variable is
to be assigned as an application constant) and their shipping zipcode.
If the user selects this service, the cost of the inbound shipping is
displayed as a line item labeled "options" in the order calculation
form. IMPORTANT: if the user selects the pre-paid inbound service then
they cannot pay by mail order at which time the that payment type is
grayed out and not a selectable payment option (possible additional text
next to this payment type may be needed as well to explain the exclusion
of the payment type).
Finally, in order to calculate the order total the ship-to zipcode is
used to determine if the items will be returned to an address within the
state of Texas. If they are Texas residents then sales tax is calculated
on the order sub-total (not including tax on inbound shipping, if
selected) and then shown as a line item entry. The only time this line
item should appear is if the sales tax is required for the order
otherwise this field is hidden. The order total is the total of each
line item, any options and sales tax (if applicable).
Requirements
|
Name |
Description |
Type |
 |
Order entry required fields
|
Description of the required form fields in the order entry portion of the form
|
Requirement |
Performed By
|
Name |
Description |
Type |
|
Customer
|
User model representing the customer making a purchase on the BPR website
|
Person |
|
| 1.5 |
Payment section
This section requires the customer to indicate their payment method. If
they are going to use their credit card and process with the BPR site
then they must enter a properly formatted credit card number, expiration
date and the CVV code. Selecting a payment type of PayPal or print order
form has no additional requirements.
Requirements
|
Name |
Description |
Type |
|
Payment method required fields
|
Description of the required form fields in the shipping/billing section of the order form
|
Requirement |
Performed By
|
Name |
Description |
Type |
|
Customer
|
User model representing the customer making a purchase on the BPR website
|
Person |
|
| 1.6 |
Process order entry data
Once the customer has entered all of their information the application
should do server-side validation of the data to make sure all required
information has been entered by the customer. Customer information
should either be updated (in the case of a user authenticating with the
system) or a new user bean instance instantiated (and stored in session
variables). The order information and payment data should also
instantiate an order bean (or the like, programmer preference). If there
are errors with the information the system should store these errors in
the session scope so they may be referenced when the user is directed to
the order entry form again to fix any issues. If this is necessary
(which hopefully will not be the case since most errors should be
checked client-side with JS and AJAX), then on return to the order entry
form the form should display the customer and order information from the
session beans previously populated on the post of the order entry form.
Finally, the customer's shipping address must be verified with the US
Postal Service as an acceptable address and must match at the street
address, city and state level. The zipcode+4 information should be
updated in the customer bean as well.
SPECIAL NOTE: in the case that this is the first order for the
customer and they have entered their chosen password then when they
return to the order processing form, special care must be taken to
protect the password they originally entered. Should the password be in
a hidden field and an idicator "flagged" so as not to display the
password entry and password (confirm) fields? Also, should the same be
true for the email confirmation? (pay attention to the "form entry
error" redirection)
Requirements
Incoming Links
|
Name |
Description |
Link Label |
 |
Payment section
|
Order form section pertaining to order payment
|
Verify order entry |
Outgoing Links
|
Name |
Description |
Decision |
|
Verify address differences
|
A difference was noted in the address entered by the customer and the official USPS address database.
|
|
|
Contact information section
|
Order form section detailing the account/billing/shipping sections
|
form entry error |
|
Confirm order
|
The customer must confirm their order before payment processing occurs
|
|
|
| 1.7 |
Confirm order
The customer must confirm their order before payment is processed. If
the user needs to edit any portion of the order they are sent back to
the order form to change their processing information.
|
| 1.8 |
Process credit card
Process the customer's credit card with the merchant bank for
authorization of charges.
Incoming Links
|
Name |
Description |
Link Label |
 |
Record order data
|
Record the order details in the database
|
|
Outgoing Links
|
| 1.9 |
Process PayPal
The customer has chosen to pay their order using PayPal. Order
processing details are sent along to the PayPal server and the user is
re-directed to their site to either login to their account or pay using
PayPal's network. Details pertaining to the data transmitted to PayPal
are not fully known at this time other than than the redirect to
PayPal's server for additional customer data entry.
Incoming Links
|
Name |
Description |
Link Label |
|
Record order data
|
Record the order details in the database
|
|
Outgoing Links
|
| 1.10 |
Record order data
The customer has confirmed the order and therefore the customer account
should be created/saved in the data tier (customer bean instance?).
Also, the order details should be saved to the order management table
structure and assigned an order number (this number is required for
integration with PayPal as well as a third-party merchant processing
system for credit card payments). All orders should be marked with the
status of "pending payment confirmation".
NOTE: this sequence is up to discussion with programmer staff
|
| 1.11 |
Record payment processing data
Record the payment processing information details for the order,
regardless of whether or not it was a failure or a success.
|
| 1.12 |
Verify address differences
Since there was an issue with the customer's shipping address not
matching the USPS database, send the customer to an address verification
page showing the address discrepencies so the used can chose to accept
the address as recorded by the USPS. If they choose not to accept the
address then they should be sent back to the order entry form to enter
their new shipping address information.
|
| 1.13 |
Generate USPS in-bound shipping label
Since the payment has been captured, generate the in-bound shipping
label.
Incoming Links
|
Name |
Description |
Link Label |
|
Record payment processing data
|
Record the payment processing data returned by the processing system
|
pre-paid in-bound label? |
Outgoing Links
|
| 1.14 |
Order confirmation
The order has been successfully placed. Display the order confirmation
screen to the customer stating the next steps they must take in order to
ensure their order is processed quickly. If they chose to pre-pay their
in-bound shipping then display the PDF file representing the postage in
a small-ish iframe (open for programmer discussion) as well as a link to
save the postage file locally. Similarly, if they are shipping the order
along with payment, then provide a link to the order form PDF
pre-populated with their order details (also, possibly show the order
form in an iframe).
|
| 1.15 |
Record pre-paid label
Since we are dealing with an electronic file representing the customer's
money, make sure and record the specifics about the pre-paid lable
generation as well as save the PDF file representing the label to the
server's file system (potentially store the PDF as a blob in the
database too).
|
|
Expand / Collapse
