Professional Documents
Culture Documents
PM Artifact
PM Artifact
PM Artifact
[CLIENT LOGO]
CLARITY #: PRJ0021749
Exec Sponsor (US) / ELT Sponsor (EMEA) Joe Ferraro, Andre Meesschaert
Business Owner/Project Manager Aaron Gleason
Portfolio Lead/Portfolio Delivery Manager Moiz Masavi
(EMEA)
Project Manager Jeanne Tansey
Document Author Lohitha Ravi
Peer Reviewer Moiz Masavi, Nishank Gandhi
Date Issued 10-May-2017
Version Control
Version Date Status <Draft or Author Comment / Changes from Prior Version
Final>
1.0 5/10/17 Final Lohitha Initial Version
Ravi
Final Lohitha Modified the document to exclude the
1.1 11/21/17
Ravi requirement of a mobile app for this project
Final Removed references to accessories reports as
Lohitha
1.2 12/19/17 it is out of scope of initial delivery of the
Ravi
SMWR application
Final Nishtha Added the requirement for VRS 03 and VRS
1.3 02/02/18
Sachan 04
Final Nishtha Updated Business owner
1.4 02/12/18
Sachan Added a new section - Appendix D
Template Version 1.1 Company Confidential
[CLIENT]: Business Definition Document (BDD)
Final Nishtha
1.5 02/16/18 Updated Appendix C and Appendix D
Sachan
Final Added Appendix E to include rules for VRS03
report
Nishtha
1.6 02/23/18 Updated Appendix B
Sachan
Updated the functional requirements FR01,
FR02, FR11, FR29
4
[CLIENT]: Business Definition Document (BDD)
Sign Off
Glossary of Terms
Term Meaning
ADD Architecture Definition Document
DMP Damager Manager Portal – US and Canada application
EDW Enterprise Data Warehouse
Maintenance Damage Manager System – EMEA
MDMS
application
Motor Vehicle Asset to uniquely identify [CLIENT]
MVA
vehicles
MSI Market Segment Indicator
PM Preventive Maintenance
RA Rental Agreement
SMWR Station Manager Weekly Report
TCU Telematics Control Unit
TDD Technical Definition Document
VAB Virginia Beach
VIN Vehicle Identification Number
Vehicle Reporting System – Mainframe based
VRS
application
Supporting Documents
5
[CLIENT]: Business Definition Document (BDD)
Document Purpose
This document is used to capture business, functional and non-functional requirements for the given
project as agreed with the Project Sponsors.
The target audience of the document are the Business Sponsor and Stakeholders as identified in Clarity.
The approved version of this document will be passed to the Technical teams. The Technical team will
prepare and share Technical Design for business stakeholders and IT systems teams review and
approval.
This is a mandatory document for all projects in accordance with [CLIENT] SDLC
6
[CLIENT]: Business Definition Document (BDD)
1. Project Overview, Objectives and Impact
1.1. Overview
The current Station Manager Weekly report consists of 13 plus different reports which the global
Operations team works as part of their daily work flow and for audit requirements. The report is time
consuming, manual, print/paper heavy and often the actions taken by Operations are reactive than
proactive as most of the reports are not real time and lag by several days. It requires extensive amount of
time to reconcile reports, thereby preventing Operational Managers from focusing on [CLIENT]’s associates
and the customer’s overall experience.
This project aims to build a live, globally supported portal that will consolidate multiple data points for
Contracts and Fleet and allow Operational Managers to access in real time key operational information
across all brands, research and take immediate action.
Licensee:
US* CA LAC APAC EMEA Sub Global
Licensees
[CLIENT
BRAND 1]
[CLIENT
BRAND 2]
[CLIENT
BRAND 3]
[CLIENT ☐
BRAND 4] ☐ ☐ ☐ ☐ ☐ ☐
[CLIENT ☐
BRAND 5] ☐ ☐ ☐ ☐ ☐ ☐
[CLIENT
☐ ☐ ☐ ☐ ☐ ☐
BRAND 6]
[CLIENT ☐
BRAND 7] ☐ ☐ ☐ ☐ ☐ ☐
9
[CLIENT]: Business Definition Document (BDD)
3. Business Processes
10
[CLIENT]: Business Definition Document (BDD)
Process Role Process Description Impact of change Related
Functional
Requirement
application application and reports necessary access
based on the logon will not be able
credentials and user role log in, view
reports or take
action on the
reports
Easy research New SMWR The application will pull in Users will not FR03, FR07,
application information for contract, have to log in to FR11, FR15,
and vehicle from multiple other FR17, FR18,
sources applications to FR22, FR23,
obtain vehicle, FR24, FR30
contract
information in
order to make
decisions
Make New SMWR The application will Users can take FR10, FR15,
recommendations application execute a pre-defined set actions based on FR30
of rules based on vehicle the
or contract parameters recommendation
and make made by the
recommendations application
Notifications New SMWR Alert operational This will help FR09, FR19
notification managers about issues or operational
process policy violations managers
manage their
staff and vehicles
more efficiently
Corrective action Operational Review reports on the This will help FR08, FR04,
Manager SMWR application and reconcile the FR30, FR13,
take necessary action (like SMWR reports FR17, FR18
email checklists, update
RA, update notes, perform
manual checks) based on
the recommendations
Audit review [CLIENT] Review audit reports Ensure timely FR14, FR25
Internal generated by the SMWR action is taken by
Auditor application Operational
managers to
reconcile SMWR
reports
11
[CLIENT]: Business Definition Document (BDD)
3.4. ‘To Be’ Business Process
Operational Manager will log in to the new SMWR application to view reports for locations he /
she has access to.
The application will pull in vehicle / contract data from multiple sources and display relevant
information on each of the reports. Color coding or indicators will be used to allow easy
identification of records that need to be researched by the manager.
The application will perform automatic verification of business rules for vehicles / contracts and
make recommendations for actions to be performed by the manager – like email checklists,
update the RA, assign the record to another employee, enter processing notes etc.
Audit trail will be maintained for all actions performed via the SMWR application so that an
internal auditor can review audit reports to ensure SMWR reports are reconciled regularly.
Notifications/alerts will be generated for issues or policy violations. This will enable managers
take immediate action when needed.
12
[CLIENT]: Business Definition Document (BDD)
4. Business Requirements
13
[CLIENT]: Business Definition Document (BDD)
5. Functional Requirements
Functional Business Detailed Description MoSCoW Criteria For
Requirement Requireme Evaluation (or
# nt(s) Acceptance
Covered Criteria)
Fleet Report Requirements
FR01 BR01 Build a live fleet view that is a combination M Compare the
of the rules for the present day VRS 01, 21 result with that
and 29 screens. Provide indicators on the of the VRS
report to clearly identify vehicles that only screens
satisfy the criteria for the 21 report. Pilot
for one location.
14
[CLIENT]: Business Definition Document (BDD)
Functional Business Detailed Description MoSCoW Criteria For
Requirement Requireme Evaluation (or
# nt(s) Acceptance
Covered Criteria)
4. Last Vehicle Movement
a. If rental agreement, also SEC from
203/806 screen
b. Was the MVA modified?
c. Was last movement a minilease or
extended rental?
5. Miles / KM
6. PM Miles
7. Registration and Inspection Date
8. Title Status (is it active?)
9. MSI (conditions – turnback facilities
etc.)
10. Car Group
11. TCU Connected or Zipcar Device
12. Last Gate Exit Scan
13. Button to Request Connected Car Last
recording of Data within a Geo Fence
facility
Notes section - Notes from ERS, VAB,
Supply Chain, Manager’s Comments, etc.
FR04 BR08 Provide the ability to search by MVA, VIN M Verify the result
or license plate number with that of the
313 screen
FR05 BR09 User Roles M Log in for each
1. Country Manager / AVP type of user
role to verify
2. Regional Manager / Operational
the access
Director
privileges
3. District Manager / City Manager /
Front Line Manager / Airport Manager
4. Security Manager
5. Supply Chain
6. Finance
7. Auditor
8. Operations
9. VAB, Budapest
10. Reservation Center
11. L&D, SPM
12. WHQ, Bracknell management
15
[CLIENT]: Business Definition Document (BDD)
Functional Business Detailed Description MoSCoW Criteria For
Requirement Requireme Evaluation (or
# nt(s) Acceptance
Covered Criteria)
Types of Access
for user roles
1. Add notes to vehicle
2. Send emails
3. Fill in missing vehicle report and
4. Add access to employees
5. Give temporary full access to an
employee
6. Email missing vehicle report to Security
only by specific roles
FR06 BR12 Provide the ability to assign individuals to C Verify if all user
each work group like Supply Chain, Area roles are able to
Security, Fleet Distribution etc. Integrate make
with Workday for employee hierarchy assignments to
information. all applicable
work groups
FR07 BR02 MVA records on the report should be M Verify the last
marked with green, amber and red color revenue date
based on the following rules and inventory
date for all
No Dot vehicles on the
No revenue in 71 hours report and
determine if
No inventory in 71 hours
colour coding is
Green
correct
Revenue within 71 hours (under 3
days)
Inventoried within 71 hours (under 3
days)
Yellow
Inventory or not inventory (click on dot
to see)
No revenue from 72-144 Hours (6
days)
Red
7 days idle with no revenue
Not inventoried in 7 days
FR08 BR05 Provide the ability to update notes for a M Enter notes for
vehicle and view notes entered by all a vehicle and
16
[CLIENT]: Business Definition Document (BDD)
Functional Business Detailed Description MoSCoW Criteria For
Requirement Requireme Evaluation (or
# nt(s) Acceptance
Covered Criteria)
users. Notes should be retained for 60 verify it is
days. displayed
FR09 BR06 Provide the ability for a manager to M Add notes to a
receive an alert on the application every vehicle owned
time another user updates notes/missing by another
vehicle checklist for a vehicle owned by location, log in
the manager’s location as manager for
that location to
view the alert
FR10 BR03, BR04 Provide the ability to view, run and update M Verify the
(enter notes and status) a checklist for a results of the
missing vehicle. Wherever applicable, checklist with
automatically verify checklist items and vehicles that
make recommendations. Complete satisfy the
checklist is available in Appendix A. checklist
criteria
FR11 BR03, BR04 For a connected car, provide the ability to M Verify the
request last recording of data within a geo information of
fenced facility the connected
car
FR12 BR04 Provide the ability to email the filled out M Verify email
Missing Vehicle report to content and if it
1. Operation Manager, Supply Chain is received by
Manager, Security Manager (these the intended
would be defined by user in profile recipient
settings)
2. Audit Team
3. Finance Team
4. Any email address that is manually
entered
FR13 BR10 Provide the ability to assign an MVA S Verify that a
record to another employee/user for user is able to
research assign a record
to another user
FR14 BR07 Maintain a daily snap shot of the actions M Verify if audit
taken on all the MVAs included in the fleet trail is
report. maintained for
actions
performed on a
vehicle
FR15 BR06 Generate notifications. Method of delivery M Verify
17
[CLIENT]: Business Definition Document (BDD)
Functional Business Detailed Description MoSCoW Criteria For
Requirement Requireme Evaluation (or
# nt(s) Acceptance
Covered Criteria)
and frequency to be determined by notifications are
business. A complete list of notifications is received for
in Appendix B. each condition
FR16 BR03 Changes to Inventory process: M Verify if
1. Inventory should be performed for inventory
every check-in and Readyline date/time is
transaction. Exclusions are auto void, updated after
[CLIENT BRAND 1] now, delayed check- each a check in
in and contract exchange. and ready line
transaction.
2. If a car is scanned by a hand held
Verify
device - Rover, MDMS app, Quintiq
indicators on
app - for a check-in or Readyline or
MDMS.
inventory transaction, indicate if the
MVA was manually entered
3. Build in MDMS and SMWR portal
indicators associated with the
inventory date – source system
(Wizard/GUI/Pronto/Zelda or hand
held app), source transaction
(Readyline, check-in, inventory) and if
MVA was manually entered.
FR17 BR05, Build a real-time fleet overdue report M Verify the
BR08, BR07 similar to the VRS 03 report and display results of the
the below information report.
1. MVA
2. License Plate Enter notes for
3. Movement a vehicle and
4. Checkout date verify it is
5. Due date displayed with
6. Due Station the timestamp
7. Wiz St
8. Model Verify audit trail
9. MOP type is maintained
10. Con Ext for all actions
11. Owner taken
12. Processing Notes
20
[CLIENT]: Business Definition Document (BDD)
Functional Business Detailed Description MoSCoW Criteria For
Requirement Requireme Evaluation (or
# nt(s) Acceptance
Covered Criteria)
1. If manual authorization is checked marked as
against merchant services. System Closed
2. If RA has only one entry on the report
and Requested Amount matches the
Authorized Amount
3. If the difference in amount Request
Amount and Authorized Amount
matches the difference in T&M
(excluding upsell) from the first
attempt
4. If FAN is the first attempt with
subsequent attempt by preferred
agent and Authorization Amount for
both RA entries is the same
5. If first card attempted is Debit card
with no CID and second card presented
and authorized is credit card and
authorization amount difference is
equal to additional authorization
amount required for debit card
6. If difference between authorization
obtained and authorization needed is
less than + or – 10
FR23 BR02, Decline transactions that do not meet the M Verify that all
BR03, BR04 criteria for a “system closed” situation declined
should be marked open for user review. transactions
Provide the ability to enter processing that satisfy the
notes against the transaction, changing criteria are
status to in progress or closed (after marked for
appropriate action has been taken offline). review
1. If required amount is not the same as
authorized amount, mark RA entry as
"Possible Phishing"
2. If there are multiple declines on a card
for different Agent IDs and an hour or
more between attempts, mark all
entries as "Possible Customer
Phishing"
3. If there are multiple declined entries
for a debit card, mark all entries as
"Improper Debit Card Use"
21
[CLIENT]: Business Definition Document (BDD)
Functional Business Detailed Description MoSCoW Criteria For
Requirement Requireme Evaluation (or
# nt(s) Acceptance
Covered Criteria)
FR24 BR07 Maintain a periodic audit trail for M Verify audit trail
contracts that were actioned by a user. is maintained
Auditors should be able view these for all actions
reports. taken on a
declined
transaction
FR25 BR04 Provide the ability to upload policy C Verify user is
documentation and to send it to an agent able to email
in the event of a policy violation. Maintain uploaded policy
a record of repeated defaulters. documentation.
Exception Report Requirements
FR26 BR01 Build a daily Exception Report that is M Verify the
similar to the present day WRSCEX report. content of this
report matches
with WRS
screen
FR27 BR01 Include 203 adjustments of the previous M Verify that all
day in the Exception report 203
adjustments for
the location
selected appear
on the report
FR28 BR02, Make recommendation based on contract M Verify the
BR03, BR04 parameters. A complete list of application
recommendations is in Appendix C. displays correct
recommendatio
n for the
exceptions that
satisfy the rule
criteria
Common Requirements for all Reports
FR29 BR08, BR09 Provide the ability to extract reports for M Verify report
for the correct
1. A single location/brand a user has
location and
access to
brands is
2. All locations/brands a user has access displayed
to
3. A combination of locations/brands a
user has access.
Note: A location can be a rental station,
district, fleet owner, region or division
Detailed Reports will not be provided for
22
[CLIENT]: Business Definition Document (BDD)
Functional Business Detailed Description MoSCoW Criteria For
Requirement Requireme Evaluation (or
# nt(s) Acceptance
Covered Criteria)
Hierarchy locations. Instead Summary
information can be provided for Hierarchy
locations.
FR30 BR07 Provide the ability for Internal Auditor to M Verify weekly
view weekly a snapshot of all reports and snapshot of all
manager activity on reports for the last 6 reports are
months. available for the
last 6 months
23
[CLIENT]: Business Definition Document (BDD)
6. Non Functional Requirements
6.1. Performance
NFR Subject Description MoSCoW Acceptance Criteria
# (identify Business Owners if
required)
NFR01 Retrieval of basic Response time for retrieval M Response time
information of basic information for should be as
fleet, contracts deemed
appropriate by
business
NFR03 Front end processing Front end processing on M Portal front end
EMEA VDI terminals should not have
high CPU usage
6.2. Security
NFR Subject Description MoSCoW Acceptance Criteria
# (identify Business Owners if
required)
NFR04 Access to SMWR The application should only M Users without the
application be available to users who necessary access
are logged into [CLIENT] should not be able
network with valid to log in.
credentials.
NFR05 Access to SMWR reports The application should M Users should not be
display reports only for able to view
locations and brands the reports their sign-
user’s sign-on has access to on does not have
access to
NFR06 Customer sensitive data Payment card information M Users should be
must never be displayed or able to view only
stored in clear text the last 4 digits of
the payment card
number
NFR07 Inactive user Lock portal when user is M Lock the portal if
inactive user is inactive for
more than 15
minutes
NFR08 Access to web services Web service will be secured M Only authorized
using client authentication applications will
24
[CLIENT]: Business Definition Document (BDD)
NFR Subject Description MoSCoW Acceptance Criteria
# (identify Business Owners if
required)
methods with valid have access to the
credentials. web service
6.3. Capacity
NFR Subject Description MoSCoW Acceptance Criteria
# (identify Business Owners if
required)
NFR09 Data Retention Retention for report data M Data will be
and audit trail retained for 6
months only
6.4. Availability
NFR Subject Description MoSCoW Acceptance Criteria
# (identify Business Owners if
required)
NFR10 Hours of operation The SMWR application and M Available 24/7
supporting databases
available 24 hours a day / 7
days a week with the
exception of planned down
time as agreed with the
business owner
6.5. Reliability
NFR Subject Description MoSCoW Acceptance Criteria
# (identify Business Owners if
required)
NFR11 Disaster recovery Disaster recovery team M SMWR application
(PM: Peter Bonacasa) should be include
in Disaster
Recovery
6.6. Compliance
NFR Subject Description MoSCoW Acceptance Criteria
# (identify Business Owners if
required)
NFR12 Sox Compliancy SMWR application will meet M Project should pass
☒ Is this project in requirements set out by health check and
scope for SOx? SOX Security requirements. SOx audit
25
[CLIENT]: Business Definition Document (BDD)
NFR Subject Description MoSCoW Acceptance Criteria
# (identify Business Owners if
required)
storage, display, last 4 digits of the payment
transmission or card (credit or debit card)
processing of credit card
data?
NFR14 PII Compliancy Yes M SMWR application
☒ Does project require will display name,
storage, contact information
display, transmission or for renters and
processing of PII data? operational
managers which
can be viewed only
by authorized users
26
[CLIENT]: Business Definition Document (BDD)
7. C.R.A.I.D
7.1. Constraints
# Constraint Stakeholder Area
Change in business requirements or project scope will impact the cost
1 Business
and timeline.
Completion and signoff on the BDD, ADD and TDD before portal
2 Business, IT
development commences.
7.2. Risks
# Risk Stakeholder Area
1 Delay in availability of infrastructure and licenses needed for the IT Architecture, IT
SMWR portal will result in schedule and cost overrun Project Manager,
Business
2 Non-availability of key IT resources will result in schedule slippage. IT
7.3. Assumptions
# Assumption Stakeholder Area
1 Any change in the scope of engagement after the sign-off would be IT, Business
treated as a Change Request and addressed through the Change
Management Process.
2 SMWR portal for EMEA will be web based, no install required on IT, Business
rental station equipment
3 Following requirements have been excluded from estimation and will IT, Business
not be delivered as they are either not feasible or not recommended
1. FR05 – Provide ability to add access to employees and give
temporary full access to an employee
2. FR10 – Fleet report recommendations for possible mini
lease/extended rental, possible auto void reopen, possible
incomplete rental match and manual rental agreement not
entered
3. FR21FR22 - Check manual authorization against merchant services
4. FR24FR25 – Maintain a record of repeated defaulters for payment
card decline report
4 FR18- Open vehicle movement report will be a daily feed instead of IT, Business
real time but the processing notes entered will be real time.
7.4. Issues
# Assumption Stakeholder Area
1 No issues reported at this time
27
[CLIENT]: Business Definition Document (BDD)
7.5. Dependencies
# Dependency Stakeholder Area
1 Resource availability from all participating teams IT, Business
2 Timely completion of TDD and ADD IT
3 Prioritization of project requirements Business
4 Signoff on user acceptance testing before production deployment IT, Business
5 Timely availability of infrastructure and licenses IT Architecture
6 Delivery of Wizard GUI for EMEA Corporate Locations project to scale IT, Business
up performance of rental station VDI in EMEA
7 Appropriate communication and training before portal rollout Business – L&D
28
[CLIENT]: Business Definition Document (BDD)
Appendix A
29
[CLIENT]: Business Definition Document (BDD)
16. Possible Incomplete Rental Match
a. Look at IRs on the 404 screen for same amount of days car was idle from last revenue movement
at location. Show key indicators on rental agreement
Date and time out
Car group reserved
Day of week
b. Match 408 scans to an MVA showing it left lot with NO rental agreement attached
c. Connected Car has broken the GEO Fence and have last reading with mileage not matching
17. Connected Car Data recommends car maybe on a Rental Agreement, MFC, Licensee rental one way not
on Wizard, etc.
a. Received connected car data at midnight from data warehouse showing off lot, no movement
and mileage discrepancy from 01/29 report
18. Manual Rental Agreement not entered is recommended as possible scenario for a missing vehicle(s)
a. Verify RA range is loaded in Wizard on /FOR P613
b. When that range has a missing number or range to highlight that to
c. Take into account any RA ranges that were removed from the /FOR WZTRALOG screen
d. State Date and time of ranges and between ranges to find a correlation on time used.
19. If a location is using shuttling solutions the movements within these systems need to be visible within
SMWR.
30
[CLIENT]: Business Definition Document (BDD)
Appendix B
6. IF vehicle was considered a Red Dot (7 days idle with no revenue | Not inventoried in 7 days) OR
Missing from Control in Wizard and is inventoried at another location OR shows up on a revenue
movement to
Notify: Location managers where vehicle was reported originally as a Missing From Control OR was
listed on a particular location’s idle report.
Delivery Method: Portal inbox or email
31
[CLIENT]: Business Definition Document (BDD)
Appendix C
1. No Charge
a. IF Reason Code = "SY/" THEN match new RA number after "SY/" to 203
IF name of cancelled RA matches name of active 203 RA THEN Leave off report
ELSE Prompt message for "Manager Review"
c. IF Reason Code = "RC" THEN Display remarks AND check 502-screen to see if rental honored
IF Rental honoured THEN Display new RA
ELSE Prompt message for "Manager Review"
d. IF Reason Code = "MB" THEN link MVA(s) to ERO System to match any RO made for MVA after C/I
date; display link to applicable RO(s). *NICE TO HAVE REQUIREMENT*
2. Voids
a. IF Voided-RA's reservation is re-honored THEN Display remarks
IF Rental honoured THEN Display new RA
ELSE Prompt message for "Manager Review"
3. Walk-up / No Show
a. Need the ability to check across [CLIENT BRAND 1], [CLIENT BRAND 2] & [CLIENT BRAND 3].
Need to have system match names better; too many obvious “non-deviations” making it to the
report.
IF WIZARD finds a match THEN
IF LOR of 203 = LOR of 502THEN
IF ILC Field of 203 = ILC of 502 THEN
IF Car Class of 203 = EQP of 502 THEN Populate RA on the report along
with RMK Field
ELSE Do not populate RA onto the report
4. Manual Rates
a. IF Reason Code = “RD” THEN match T&M of 203 against T&M of 502
IF 203 = 502 THEN Do not populate on the report
ELSE Prompt “Manual Rate Not Matching Reservation Rate”
b. IF Reason Code = “UP” THEN match T&M of 203 against T&M of 502
IF 203 > 502 THEN Prompt “Verify Upsell With Signature Copy”
*NICE TO HAVE REQUIREMENT: A link that is clickable to print/view signature copy*
ELSE Prompt “Invalid Reason Code/Manager Review Needed”
32
[CLIENT]: Business Definition Document (BDD)
c. IF Reason Code = “MC” THEN match the “HRY/DLY/WKY” of 203 against “HRY/DLY/WKY” of 502
IF 203 = 502 THEN
IF MLG of 502 > 0 THEN Do not populate of the report
ELSE Prompt “Invalid Reason Code/Manager Review Needed”
ELSE Prompt “No Mileage Cap/Manager Review Needed
d. IF Reason Code = "MA" THEN Link ID given for Rate Default to Agent ID who entered the Manual
Rate AND WIZARD verify ID number a Manager
IF all matches THEN Do Not Populate of the Report
ELSE Prompt “Manual Rate Not Approved By Manager/Need Review”
*NICE TO HAVE REQUIREMENT*
In meantime, Reason Code “MA” should follow same logic as “RD” Reason Code
5. Connected Cars
a. IF FLO =/= “G8” THEN
IF TCU DEVIC GAS OUT < TCU DEVIC GAS IN THEN Connected Car adjustment; Do not
populate on report
ELSE Display the RA on the report with the amount of fuel adjusted from the F/O field
along with anything in remarks field
33
[CLIENT]: Business Definition Document (BDD)
ELSE IF ADJ = ACC sold THEN Prompt “Adjustment Matching Counter Product” and display
RMK field
ELSE IF ADJ = BFL field THEN Prompt “Adjustment Matching Fuel Proceeds” and display
RMK field
END IF
9. Fuel adjustment
a. *Run Connected Car Logic to Filter Those Out First*
IF F/O field has value in it
IF F/O = “D0/G “
IF Value after “D0/G “ = BFL field THEN Prompt “Improper Fuel Adjustment” and
display RMK field
ELSE Prompt “Verify Fuel Adjustment” and display RMK field
ELSE Prompt “On Road Expense Adjustment Made” display value of the adjustment and
display RMK field
34
[CLIENT]: Business Definition Document (BDD)
Appendix D
35
[CLIENT]: Business Definition Document (BDD)
Appendix E
The following rules will apply for generating the VRS03 Overdue Vehicle report
1) A vehicle will appear on this report when it’s more than three (3) days overdue on non-cash rentals and one
(1) day overdue on Cash rentals.
3) Any vehicle which has rental that has been checked out for more than 45 days.
4) Include the overdue previous movement of a vehicle only if the current vehicle is NRT and is closed.
36
[CLIENT]: Business Definition Document (BDD)
VRS04 Open movement report
37